Multicast - Auto-rp filtering and multiple RPs

Overview

Configuring multiple RP can be beneficial to provide redundancy in the event of an RP failure. It is also possible to filter which RP's map to a group to provide a method to load balance multicast traffic across multiple RPs.
 
Concepts tested

• IP PIM Sparse dense mode configuration
• Configuring multiple RPs via auto RP
• Controlling groups mappings to RPs

Topology

Lab Tasks

• Assume R1 as the receiver and R4 as the source
• Configure multicast PIM on all paths appropriate for this lab
• Using Cisco's auto-rp configure both R2 and R3 as RPs with the following restrictions
• R4 should be the mapping agent
• R2 should be the RP and mapping agent for the group 224.0.0.0 /5
• R3 should be the RP and mapping agent for the group 232.0.0.0 /5
• The group 239.1.1.1 should use dense mode only
• Verify your configuration:
• R1 should join the group 224.0.10.10 which should use R2 as its RP
• R1 should join the group 232.0.10.10 which should use R3 as its RP
• R1 should join the group 239.1.1.1 which should be dense mode only
• R4 should ping each of these groups

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1(config)#ip multicast-routing
R1(config)#int g0/0
R1(config-if)#ip pim sparse-dense-mode
R2(config)#ip multicast-routing
R2(config)#int lo 0
R2(config-if)#ip pim sparse-dense-mode
R2(config)#int g0/0
R2(config-if)#ip pim sparse-dense-mode
R2(config-if)#int g1/0
R2(config-if)#ip pim sparse-dense-mode
R2(config)#ip pim send-rp-discovery loopback 0 scope 10

R2(config)#ip access-list standard R2_GROUPS
R2(config-std-nacl)#deny 239.1.1.1
R2(config-std-nacl)#permit 224.0.0.0 7.255.255.255
R2(config)#ip pim send-rp-announce loopback 0 scope 10 group
R2(config)#ip pim send-rp-announce loopback 0 scope 10 group-list R2_GROUPS
R3(config)#ip multicast-routing
R3(config)#int loopback 0
R3(config-if)#ip pim sparse-dense-mode
R3(config-if)#int g0/0
R3(config-if)#ip pim sparse-dense-mode
R3(config-if)#int g1/0
R3(config-if)#ip pim sparse-dense-mode
R3(config)#ip access-list standard R3_GROUPS
R3(config-std-nacl)#deny 239.1.1.1
R3(config-std-nacl)#permit 232.0.0.0 7.255.255.255
R3(config)#ip pim send-rp-discovery loopback 0 scope 10
R3(config)#ip pim send-rp-announce loopback 0 scope 10 group-list R3_GROUPS
R4(config)#ip multicast-routing
R4(config)#int g0/0
R4(config-if)#ip pim sparse-dense-mode
R4(config-if)#int g1/0
R4(config-if)#ip pim sparse-dense-mode
R4(config-if)#int g2/0
R4(config-if)#ip pim sparse-dense-mode

R5(config)#ip multicast-routing
R5(config)#int g0/0
R5(config-if)#ip pim sparse-dense-mode


Verification

R5#ping 224.0.10.10 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.0.10.10, timeout is 2 seconds:
Reply to request 0 from 120.0.0.1, 192 ms
Reply to request 1 from 120.0.0.1, 124 ms
Reply to request 2 from 120.0.0.1, 92 ms
Reply to request 3 from 120.0.0.1, 124 ms


R1#sh ip mroute 224.0.10.10


(*, 224.0.10.10), 00:15:25/stopped, RP 2.2.2.2, flags: SJPL
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.2
  Outgoing interface list: Null

(120.0.45.5, 224.0.10.10), 00:00:12/00:02:47, flags: PLT
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3
  Outgoing interface list: Null
R5#ping 232.0.10.10 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 232.0.10.10, timeout is 2 seconds:
Reply to request 0 from 120.0.0.1, 192 ms
Reply to request 0 from 120.0.0.1, 228 ms
Reply to request 1 from 120.0.0.1, 128 ms
Reply to request 2 from 120.0.0.1, 84 ms


R1#sh ip mroute 232.0.10.10


(*, 232.0.10.10), 00:16:44/stopped, RP 3.3.3.3, flags: SJPL
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3
  Outgoing interface list: Null

(120.0.45.5, 232.0.10.10), 00:00:07/00:02:52, flags: PLT
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3
  Outgoing interface list: Null
R5#ping 239.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 120.0.0.1, 192 ms
Reply to request 0 from 120.0.0.1, 224 ms
Reply to request 1 from 120.0.0.1, 92 ms
Reply to request 2 from 120.0.0.1, 124 ms
Reply to request 3 from 120.0.0.1, 120 ms



R1#sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:19:01/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/0, Forward/Sparse-Dense, 00:19:01/00:00:00

(120.0.45.5, 239.1.1.1), 00:00:31/00:02:28, flags: PLT
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3*
  Outgoing interface list: Null

R1#sh ip mroute 239.1.1.1 count
IP Multicast Statistics
11 routes using 3658 bytes of memory
5 groups, 1.20 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 20
  Source: 120.0.45.5/32, Forwarding: 0/0/0/0, Other: 20/0/20

R2#deb ip pim auto-rp
PIM Auto-RP debugging is on
*Nov 25 08:40:38.359: Auto-RP(0): Build RP-Discovery packet
*Nov 25 08:40:38.359: Auto-RP(0):  Build mapping (224.0.0.0/5, RP:2.2.2.2), PIMv2 v1,
*Nov 25 08:40:38.363: Auto-RP(0):  Build mapping (232.0.0.0/5, RP:3.3.3.3), PIMv2 v1.
*Nov 25 08:40:38.367: Auto-RP(0):  Build mapping (-239.1.1.1/32, RP:3.3.3.3), PIMv2 v1.
R3#deb ip pim auto-rp
PIM Auto-RP debugging is on
*Nov 25 08:40:43.143: Auto-RP(0): Build RP-Discovery packet
*Nov 25 08:40:43.147: Auto-RP(0):  Build mapping (224.0.0.0/5, RP:2.2.2.2), PIMv2 v1,
*Nov 25 08:40:43.151: Auto-RP(0):  Build mapping (232.0.0.0/5, RP:3.3.3.3), PIMv2 v1.
*Nov 25 08:40:43.151: Auto-RP(0):  Build mapping (-239.1.1.1/32, RP:3.3.3.3), PIMv2 v1.





 

Multicast - Auto-RP

Overview

The Cisco auto rp features allows for the election one or more RP's rather then having to statically map the address. To configure the autorp feature two commands are needed.

• ip pim send-rp-discovery interface_address scope number
• ip pim send-rp-announce interface_address scope number

The first command is to establish the mapping agent which is responsible for listening to the group 224.0.1.39 for rp announcements and caching the rp to group mappings and sending those rp to group mappings to the 224.0.1.39 group. The second commands is configured on the rp candidate and is elected based on high ip address.

  

Concepts tested

• Pim sparse dense mode configuration
• Configuring single auto-rp router
• Verifying configuration

Topology

  

Lab Tasks

• Configure ip pim sparse-dense-mode on the paths between the receiver and source routers.
• Using Cisco's autorp make R4 the RP for all groups.
• Configure the receiver to join the group 239.1.1.1 on its g0/0 interface and confirm your configuration by having the source router ping this group successfully.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Receiver(config)#ip multicast-routing
Receiver(config)#int g0/0
Receiver(config-if)#ip pim sparse-dense-mode
Receiver(config-if)#ip igmp join-group 239.1.1.1

 

R2(config)#ip multicast-routing
R2(config)#int loopback 0
R2(config-if)#ip pim sparse-dense-mode
R2(config)#int g0/0
R2(config-if)#ip pim sparse-dense-mode
R2(config)#int s2/0
R2(config-if)#ip pim sparse-dense-mode
R2(config)#ip pim send-rp-discovery loopback 0 scope 10

R3(config)#ip multicast-routing
R3(config)#int g0/0
R3(config-if)#ip pim sparse-dense-mode
R3(config-if)#int g1/0
R3(config-if)#ip pim sparse-dense-mode
R3(config-if)#int loopback 0
R3(config-if)#ip pim sparse-dense-mode
R3(config)#ip pim send-rp-discovery loopback 0 scope 10

R4(config)#int g1/0

R4(config-if)#ip pim sparse-dense-mode

R4(config)#int g2/0

R4(config-if)#ip pim sparse-dense-mode

R4(config)#int loopback 0

R4(config)#ip pim sparse-dense-mode

R4(config)#ip pim send-rp-announce loopback 0 scope 10

R4(config)#ip pim send-rp-discovery loopback 0 scope 10

  

Verification

Source#ping 239.1.1.1 rep 20
Type escape sequence to abort.

Sending 20, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 120.0.0.1, 196 ms

Reply to request 1 from 120.0.0.1, 64 ms

Reply to request 2 from 120.0.0.1, 72 ms

Reply to request 3 from 120.0.0.1, 84 ms

Reply to request 4 from 120.0.0.1, 104 ms

Reply to request 5 from 120.0.0.1, 56 ms

...

R4#sh ip mroute 239.1.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:00:14/stopped, RP 0.0.0.0, flags: D

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Sparse-Dense, 00:00:14/00:00:00

(120.0.45.5, 239.1.1.1), 00:00:14/00:02:46, flags: T

  Incoming interface: GigabitEthernet2/0, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Sparse-Dense, 00:00:14/00:00:00

 

 

Multicast - Multicast tunneling

Overview

Tunneling multicast over a GRE tunnel or other overlay technology is sometimes necessary to over come a lack of support in the underlying network. GRE tunnels can be used to send multicast traffic across a network that doesn't support multicast. Configuration is straightforward and multicast traffic can be routed via the tunnel either by static routes or by manipulating IGP to send traffic over the tunnel. The ip mroute source-address source-mask next-hop can be used to manipulate just the multicast packets without having to change how unicast traffic routes.

Concepts tested

• PIM Sparse mode
• Sparse mode over GRE tunnels
• Static RP addressing

Topology

 

 

Lab Tasks

• Enable PIM sparse mode on the interfaces between receiver and R1
• Enable PIM sparse mode on the interfaces between R4 and the source.
• Do not configure multicast or PIM on R2 and R3
• Configure R4 as the RP using it's loopback 0 interface.
• Configure a GRE tunnel between R1 and R4 and enable PIM sparse mode on the tunnel
• Configure the reciever to join the group 239.0.0.1 and have the source router successfully ping this group.
• Make sure that multicast traffic uses the GRE tunnel

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution


Receiver(config)#ip multicast-routing
Receiver(config)#ip pim rp-address 4.4.4.4
Receiver(config)#int g0/0

Receiver(config-if)#ip pim sparse-mode

Receiver(config-if)#ip igmp join-group 232.0.0.1

R1(config)#ip multicast-routing

R1(config)#ip pim rp-address 4.4.4.4

R1(config)#int g1/0

R1(config-if)#ip pim sparse-mode

R1(config)#int tunnel 10

R1(config-if)#ip address 10.1.1.1 255.255.255.0

R1(config-if)#tunnel source loopback 0

R1(config-if)#tunnel destination 4.4.4.4

R1(config-if)#ip pim sparse-mode

R1(config-if)#exit

R1(config)#ip mroute 0.0.0.0 0.0.0.0 tu 10

R1(config)#router ospf 1

R1(config-router)#passive-interface tunnel 10

R4(config)#ip multicast-routing

R4(config)#ip pim rp-address 4.4.4.4

R4(config)#int loopback 0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g2/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#exit

R4(config)#int tunnel 10

R4(config-if)#ip address 10.1.1.2 255.255.255.0

R4(config-if)#tunnel source loopback 0

R4(config-if)#tunnel destination 1.1.1.1

R4(config-if)#ip pim sparse-mode

R4(config-router)#passive-interface tunnel 10

Source(config)#ip multicast-routing

Source(config)#int g0/0

Source(config-if)#ip pim sparse-mode

Verification

If we have everything in place we should be able to ping our receiver and see our *,G and S,G on the RP.

Source#ping 239.1.1.1 rep 500
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 120.0.10.254, 224 ms
Reply to request 1 from 120.0.10.254, 156 ms
Reply to request 2 from 120.0.10.254, 140 ms
Reply to request 3 from 120.0.10.254, 152 ms
Reply to request 4 from 120.0.10.254, 160 ms
 R4#sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:07:21/00:03:01, RP 4.4.4.4, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel10, Forward/Sparse, 00:07:21/00:03:01

(120.0.45.5, 239.1.1.1), 00:02:16/00:00:43, flags: T
  Incoming interface: GigabitEthernet2/0, RPF nbr 120.0.45.5
  Outgoing interface list:
    Tunnel10, Forward/Sparse, 00:02:16/00:03:12


 

Multicast - PIM Accept register

Overview

PIM Accept-register is a security feature that allows control over which sources and groups can register with the RP. The command is configured in addition to the RP configuration and includes an access list option that controls sources and groups based on the access list configuration below:

ip access-list extended ip source source_wildcard_mask group group_wildcard_mask

The access list above is included in the ip pim accept-register command or optionally a route-map can also be used.

Concepts tested

• Configuring PIM-SM 
• DR election and placement
• PIM accept register

Topology

Lab Tasks

• Configure all devices with PIM-SM on connected interfaces
• Configure R1 as the RP
• Configure R1 so that it only accepts source registrations from the source IP 4.4.4.4 for the group 239.0.0.0/24.
• Test your configuration by having R1's g0/0 join the group 239.0.0.1 and ping the group from R4 sourcing from its loopback 0 interface which should be successful.
• Test your configuration again by having R1's g0/0 interface join the group 239.1.1.1 and have R4 ping the group sourcing it from its loopback 0 interface which should fail.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 1.1.1.1
R1(config)#int g0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#int g1/0

R1(config-if)#ip pim sparse-mode
R1(config)#ip access-list extended ALLOWED_GROUPS
R1(config-ext-nacl)#permit ip host 4.4.4.4 239.0.0.0 0.0.0.255
R1(config-ext-nacl)#deny ip any any <== So we can look at the counters and confirm its working

R1(config-ext-nacl)#exit

R1(config)#ip pim accept-register list ALLOWED_GROUPS

R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 1.1.1.1
R2(config)#int g0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int g1/0

R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 1.1.1.1
R3(config)#int g0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#int g1/0

R3(config-if)#ip pim sparse-mode

R4(config)#ip multicast-routing

R4(config)#int g0/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g1/0

R4(config-if)#ip pim sparse-mode

Verification

R1#deb ip pim 239.0.0.1

R1(config-if)#ip igmp join-group 239.0.0.1

R4#ping 239.0.0.1 source loopback 0 rep 5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

.

Reply to request 1 from 120.0.0.1, 140 ms

Reply to request 2 from 120.0.0.1, 112 ms

Reply to request 3 from 120.0.0.1, 120 ms

Reply to request 4 from 120.0.0.1, 112 ms

Extended IP access list ALLOWED_GROUPS

    10 permit ip host 4.4.4.4 239.0.0.0 0.0.0.255 (5 matches)

*Nov 20 07:24:26.167: PIM(0): Received v2 Register on GigabitEthernet0/0 from 120.0.24.4

*Nov 20 07:24:26.167:      for 4.4.4.4, group 239.0.0.1

*Nov 20 07:24:26.175: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (4.4.4.4, 239.0.0.1).

*Nov 20 07:24:26.179: PIM(0): Send v2 Register-Stop to 120.0.24.4 for 4.4.4.4, group 239.0.0.1

Now lets try a group that isn't in our access list.

R4#ping 239.1.1.1 source loopback 0 rep 5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

.....

R1:

*Nov 20 07:26:23.643: %PIM-4-INVALID_SRC_REG: Received Register from 120.0.24.4 for (4.4.4.4, 239.1.1.1), not willing to be RP

Multicast - PIM DR election

Overview

The PIM DR in a sparse mode environment is responsible for source and receiver registration with the RP. The DR receives IGMP query report notices from interested receivers and encapsulates those messages into unicast packets and forwards them to its configured RP. Since sources don't notify they simply start sending traffic, the DR when it receives an initial multicast packet for a *,G entry for its configure RP, it will encapsulate the packet and forward it to the RP for registration via unicast. This lab will focus on DR election and placement.

Concepts tested

• IP PIM-SM DR placement
• IP PIM RP
• IP PIM-SM configuration and troubleshooting

Topology

Lab Tasks

• Configure PIM sparse mode on all interfaces in the path between the source and receiver hosts
• Configure PIM sparse mode on R3's g0/0 interface
• Configure R1 and R2 so that the host RP becomes the RP. 
• Do not configure source, receiver, or R3 as static RPs.
• Test your configuration by having receiver join its g0/0 interface to the 239.1.1.1 group then have source ping the group.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Receiver(config)#ip multicast-routing
Receiver(config)#int g0/0
Receiver(config-if)#ip pim sparse-mode

R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 5.5.5.5

R1(config)#int g0/0

R1(config-if)#ip pim sparse-mode
R1(config-if)#int g1/0
R1(config-if)#ip pim sparse-mode

RP(config)#ip multicast-routing

RPconfig)#ip pim rp-address 5.5.5.5

RP(config)#int lo 0

RP(config-if)#ip pim sparse-mode

RP(config)#int g0/0

RP(config-if)#ip pim sparse-mode

RP(config-if)#int g1/0

RP(config-if)#ip pim sparse-mode

R2(config)#ip multicast-routing

R2(config)#ip pim rp-address 5.5.5.5

R2(config)#int g0/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#int g1/0

R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing

R3(config)#int g0/0

R3(config-if)#ip pim sparse-mode

Source(config)#ip multicast-routing

Source(config)#int g0/0

Source(config-if)#ip pim sparse-mode

Verification

Lets begin our verification by joining receiver to the group 239.1.1.1 and attempting to ping it.

Receiver(config)#int g0/0

Receiver(config-if)#ip igmp join-group 239.1.1.1

Source#ping 239.1.1.1 rep 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

...........

It failed, why? lets investigate.

Lets first make sure our PIM domain is properly configured between receiver and source. A quick way to check this is with mtrace at the reciever toward the source. This tool verifies SPT via RPF to the source. Keep in mind this doesn't necessarily verify the shared tree from receiver to RP and RP to source. In our case they are the same path.

Receiver#mtrace 120.0.45.1

Type escape sequence to abort.

Mtrace from 120.0.45.1 to 120.0.0.254 via RPF

From source (?) to destination (?)

Querying full reverse path...

 0  120.0.0.254

-1  120.0.0.254 None  [120.0.45.0/24]

-2  120.0.0.1 None  [120.0.45.0/24]

-3  120.0.12.5 None  [120.0.45.0/24]

-4  120.0.13.2 PIM  [120.0.45.0/24]

-5  120.0.45.1

Looks OK. Now lets look at our *,G and S,G tables.

R1#sh ip mroute 239.1.1.1

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:02:01/00:02:38, RP 5.5.5.5, flags: SP

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.12.5

  Outgoing interface list: Null

RP#sh ip mroute 239.1.1.1

Group 239.1.1.1 not found

R2#sh ip mroute 239.1.1.1

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:01:55/stopped, RP 5.5.5.5, flags: SP

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.13.5

  Outgoing interface list: Null

(120.0.45.1, 239.1.1.1), 00:01:55/00:01:03, flags: PT

  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.45.1

  Outgoing interface list: Null

So the obvious issue appears to be that the RP does not know about 239.1.1.1. So the RP has not been notified of the receiver or the source.

In this case based on our multicast design the next hop routes R1 and R2 should be notifying the RP but they are not. 

For a receiver in a sparse mode environment the next hop PIM router is responsible for sending join/prune messages to the RP for registration. On a LAN that responsibility falls to the elected DR. lets see who are the DRs.

R1#sh ip pim int g0/0 det

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 120.0.0.1/24

  Multicast switching: fast

  Multicast packets in/out: 0/442

  Multicast TTL threshold: 0

  PIM: enabled

    PIM version: 2, mode: sparse

    PIM version: 2, mode: sparse

    PIM DR: 120.0.0.254

    PIM neighbor count: 1

    PIM Hello/Query interval: 30 seconds

    PIM Hello packets in/out: 721/741

    PIM State-Refresh processing: enabled

    PIM State-Refresh origination: disabled

    PIM NBMA mode: disabled

    PIM ATM multipoint signalling: disabled

    PIM domain border: disabled

    PIM neighbors rpf proxy capable: TRUE

  Multicast Tagswitching: disabled

R2#sh ip pim int g0/0 det

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 120.0.45.2/24

  Multicast switching: fast

  Multicast packets in/out: 591/0

  Multicast TTL threshold: 0

  PIM: enabled

    PIM version: 2, mode: sparse

    PIM version: 2, mode: sparse

    PIM DR: 120.0.45.254

    PIM neighbor count: 2

    PIM Hello/Query interval: 30 seconds

    PIM Hello packets in/out: 1460/744

    PIM State-Refresh processing: enabled

    PIM State-Refresh origination: disabled

    PIM NBMA mode: disabled

    PIM ATM multipoint signalling: disabled

    PIM domain border: disabled

    PIM neighbors rpf proxy capable: TRUE

  Multicast Tagswitching: disabled

The reciever and R3 our the DR's for their respective LANs. But they are not configures as RPs nor do they know about the DR.

Receiver#sh ip pim rp map

PIM Group-to-RP Mappings

R3#sh ip pim rp map

PIM Group-to-RP Mappings

So for the receiver LAN the host receiver is responsible for taking IGMP membership reports and turning them into PIM join/prune messages and forwarding them to the RP for the appropriate *,G entry. But it is not configured with an RP so it can't do this.

The same is essentially true for R3 accept sources don't notify they just send traffic. But the DR with a source on its local LAN is responsible for taking the mcast packets and encapsulating them and forwarding them on to the RP as unicast packets for registration, but again its not configured with an RP so it can't do this.

The solution is to either configure these devices with RP information or simply change the DR for each LAN. We will change the DR.

R1(config-if)#ip pim dr-priority 2

R1(config-if)#

*Nov 18 23:30:14.358: %PIM-5-DRCHG: DR change from neighbor 120.0.0.254 to 120.0.0.1 on interface GigabitEthernet0/0

R2(config-if)#ip pim dr-priority 2

R2(config-if)#

*Nov 18 23:30:52.618: %PIM-5-DRCHG: DR change from neighbor 120.0.45.254 to 120.0.45.2 on interface GigabitEthernet0/0

Now lets ping our group again and see what happens. It may be necessary to clear your mroute cache and re-join the group on the receiver to ensure everything gets registered properly.

Source#ping 239.1.1.1 rep 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 120.0.0.254, 220 ms

Reply to request 1 from 120.0.0.254, 128 ms

Reply to request 1 from 120.0.0.254, 196 ms

Reply to request 2 from 120.0.0.254, 72 ms

Reply to request 3 from 120.0.0.254, 112 ms

Sources:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/multicast/configuration_guide/b_mc_3se_3850_cg/b_mc_3se_3850_cg_chapter_01101.html#GUID-8A53F572-FFF7-47B0-BBC9-67C2E3F15CF3

Multicast - Accept-RP

Overview

PIM Accept-RP is a security feature allows a router to accept join and prune messages from specific RP's and if configured a list of defined groups in a ACL. The features consists of a single command ip pim accept-rp [ rp-address ] [ acl ] that is best configured across the entire multicast domain. But at a minimum is needed on the RP itself.

Concepts tested

• Control group joins in a sparse mode environment
• Configuring sparse mode
• verify *,G filtering

Topology

Lab Tasks

• Configure sparse mode on all paths between the source and destination
• Configured R4 as a static RP
• Configure R4 so that its loopback address is the only RP and that only the group 231.1.1.1 can send multicast.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link

Solution


Receiver(config)#ip multicast-routing

Receiver(config)#int g0/0

Receiver(config-if)#ip pim sparse-mode

R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 4.4.4.4 1
R2(config)#int s2/0
R2(config-if)#ip pim sparse-mode

R2(config)#int g0/0

R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 4.4.4.4 1

R3(config)#int g0/0

R3(config-if)#ip pim sparse-mode

R3(config-if)#int g1/0

R3(config-if)#ip pim sparse-mode

R4(config)#ip multicast-routing
R4(config)#int g0/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g1/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g2/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int s3/0

R4(config-if)#ip pim sparse-mode
R4(config)#int loopback 0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#access-list 1 permit 231.0.0.0 0.255.255.255
R4(config)#access-list 1 permit 224.0.1.40
R4(config)#ip pim rp-address 4.4.4.4
R4(config)#ip pim accept-rp 4.4.4.4 1

Source(config)#ip multicast-routing

Source(config)#int g0/0

Source(config-if)#ip pim sparse-mode

Verification

R4:

Lets test that our configuration works first by making sure we can receive traffic for the 231.0.0.1 group. Enable Debug ip pim on R4 and join Recievers g0/0 interface to the 231.0.0.1 group and then ping the group from the source router.

*Nov 18 05:30:44.315: PIM(0): Received v2 Join/Prune on GigabitEthernet1/0 from 120.0.34.3, to us
*Nov 18 05:30:44.319: PIM(0): Join-list: (*, 231.0.0.1), RPT-bit set, WC-bit set, S-bit set
*Nov 18 05:30:44.323: PIM(0): Update GigabitEthernet1/0/120.0.34.3 to (*, 231.0.0.1), Forward state, by PIM *G Join
*Nov 18 05:30:45.159: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 231.0.0.1

Souce:

Source#ping 231.0.0.1 rep 25

Type escape sequence to abort.

Sending 25, 100-byte ICMP Echos to 231.0.0.1, timeout is 2 seconds:

Reply to request 0 from 120.0.0.1, 184 ms

Reply to request 1 from 120.0.0.1, 104 ms

Reply to request 2 from 120.0.0.1, 112 ms

OK, looks good. 

Now lets test that we have limited joins to just the groups we defined. Add the following to R4's configuration so that we can watch the ACL counters.

R4(config)#access-list 1 deny 239.0.0.1

Now join Receiver's G0/0 to the group 239.0.0.1

R4:

*Nov 18 05:41:15.531: PIM(0): Received v2 Join/Prune on GigabitEthernet1/0 from 120.0.34.3, to us

*Nov 18 05:41:15.535: %PIM-6-INVALID_RP_JOIN: Received (*, 239.0.0.1) Join from 120.0.34.3 for invalid RP 4.4.4.4

R4#

*Nov 18 05:41:15.539: PIM(0): Join-list: (*, 239.0.0.1),, ignored, invalid RP 4.4.4.4 from 120.0.34.3

R4#sh ip mroute 239.0.0.1

Group 239.0.0.1 not found

Source:

Source#ping 239.0.0.1 rep 25

Type escape sequence to abort.

Sending 25, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

........

Multicast - PIM Sparse Mode with Static RP

Overview

PIM sparse mode uses the concept of a rendezvous point to centralize the registration of sources and receivers as well as create a shared tree for initial multicast traffic once a sources begins sending traffic.

Today's lab will be focused on basic configuration of sparse mode and static configuration of a central rendezvous point and the verification of the configuration and that its working properly.

Concepts tested

• Multicast PIM sparse mode configuration
• Static RP configuration
• Verification

Topology

Lab Tasks

• Enable PIM sparse-mode on the paths between the source and destination hosts
• Configure R4 as a static RP
• for testing have the reciver join the group 231.0.0.1 and the ping the group from the source host

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R2:

R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 4.4.4.4
R2(config)#int g0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int s2/0
R2(config-if)#ip pim sparse-mode

R3:

R3(config)#ip multicast-routing

R3(config)#ip pim rp-address 4.4.4.4

R3(config)#int g0/0

R3(config-if)#ip pim sparse-mode

R3(config-if)#int g1/0

R3(config-if)#ip pim sparse-mode

R4:

R4(config)#ip multicast-routing

R4(config)#ip pim rp-address 4.4.4.4

R4(config)#int g0/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g1/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g2/0

R4(config-if)#ip pim sparse-mode

Source:

Source(config)#ip multicast-routing

Source(config)#int g0/0

Source(config-if)#ip pim sparse-mode

Receiver:

Receiver(config)#ip multicast-routing

Receiver(config)#int g0/0

Receiver(config-if)#ip pim sparse-mode

Receiver(config-if)#ip igmp join-group 231.0.0.1

Verification

R4#sh ip mroute 231.0.0.1

(*, 231.0.0.1), 00:01:54/00:02:34, RP 4.4.4.4, flags: S

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Sparse, 00:01:54/00:02:34

R3#sh ip mroute 231.0.0.1

(*, 231.0.0.1), 00:02:31/00:02:23, RP 4.4.4.4, flags: SJC

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.34.4

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Sparse, 00:02:31/00:02:23

R2:

R2#sh ip mroute 231.0.0.1

(*, 231.0.0.1), 00:03:05/00:02:47, RP 4.4.4.4, flags: SP

  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3

  Outgoing interface list: Null

R2#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

    RP: 4.4.4.4 (?)

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

    RP: 4.4.4.4 (?)

R4 Debug:

*Nov 16 17:29:33.182: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (120.0.45.5, 231.0.0.1).

*Nov 16 17:29:33.198: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface of (120.0.45.5, 231.0.0.1).

*Nov 16 17:29:33.202: PIM(0): Installing GigabitEthernet2/0 as accepting interface for (120.0.45.5, 231.0.0.1).

*Nov 16 17:29:33.206: PIM(0): Insert (120.0.45.5,231.0.0.1) join in nbr 120.0.45.5's queue

*Nov 16 17:29:33.210: PIM(0): Building Join/Prune packet for nbr 120.0.45.5

*Nov 16 17:29:33.210: PIM(0):  Adding v2 (120.0.45.5/32, 231.0.0.1), S-bit Join

R4#

*Nov 16 17:29:33.214: PIM(0): Send v2 join/prune to 120.0.45.5 (GigabitEthernet2/0)

*Nov 16 17:29:33.294: PIM(0): Received v2 Join/Prune on GigabitEthernet1/0 from 120.0.34.3, to us

*Nov 16 17:29:33.298: PIM(0): Join-list: (120.0.45.5/32, 231.0.0.1), S-bit set

*Nov 16 17:29:33.302: PIM(0): Update GigabitEthernet1/0/120.0.34.3 to (120.0.45.5, 231.0.0.1), Forward state, by PIM SG Join

*Nov 16 17:29:33.466: PIM(0): Send RP-reachability for 231.0.0.1 on GigabitEthernet1/0

Source:

Source#ping 231.0.0.1 rep 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 231.0.0.1, timeout is 2 seconds:

Reply to request 0 from 120.0.0.1, 208 ms

Reply to request 1 from 120.0.0.1, 100 ms

Reply to request 2 from 120.0.0.1, 112 ms

Reply to request 3 from 120.0.0.1, 112 ms

Reply to request 4 from 120.0.0.1, 104 ms

Multicast - PIM Assert

Overview

When multiple multicast devices attempt to simultaneously send multicast traffic onto the same LAN segment the potential for packet duplication can occur. PIM employees a mechanism called PIM assert to prevent this scenario by electing a designated sender for the LAN segment responsible for forwarding multicast traffic onto the shared LAN segment. This lab will focus on this mechanism

Concepts tested

• PIM dense mode configuration
• PIM assert election metric manipulation

Topology

Lab Tasks

• Enable PIM dense mode on all interfaces from the receiver to the source
• Ensure the R3 is elected the PIM assert winner on the 120.0.0.0/24 shared network
• Do not modify any dynamic routing configuration or metrics to do this.
• For testing purpose have the reciever join the group 232.0.0.2 on its G0/0 interface
• Have the source ping the group 232.0.0.2 and confirm R3 win's the assert election and the ping is successful.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Begin by configuring our PIM neighbors.

Source(config)#ip multicast-routing
Source(config)#int g0/0
Source(config-if)#ip pim dense-mode
Source(config-if)#ip igmp join-group 232.0.0.2

R4(config)#ip multicast-routing

R4(config-if)#int g1/0

R4(config-if)#ip pim dense-mode
R4(config-if)#int g2/0
R4(config-if)#ip pim dense-mode
R4(config-if)#int s3/0
R4(config-if)#ip pim dense-mode

R3(config)#ip multicast-routing

R3(config)#int g0/0

R3(config-if)#ip pim dense-mode

R3(config-if)#int g1/0

R3(config-if)#ip pim dense-mode

R2(config)#ip multicast-routing

R2(config)#int g0/0

R2(config-if)#ip pim dense-mode

R2(config-if)#int s2/0

R2(config-if)#ip pim dense-mode

Receiver(config)#ip multicast-routing

Receiver(config)#int g0/0

Receiver(config-if)#ip pim dense-mode

Verification

You can confirm PIM neighbor with the following command.

Receiver#sho ip pim neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

120.0.0.2         GigabitEthernet0/0       00:22:38/00:01:43 v2    1 / S P G

120.0.0.3         GigabitEthernet0/0       00:47:59/00:01:44 v2    1 / DR S P G

Do this for the remaining routers and confirm you see neighbors for every interface on each router where PIM was enabled.

Next you can confirm that the reciever has successfully registered with the following command.

Now lets test our receiver is properly getting multicast packets via our preferred path.

Source#ping 232.0.0.2 rep 500

Type escape sequence to abort.

Sending 500, 100-byte ICMP Echos to 232.0.0.2, timeout is 2 seconds:

Reply to request 0 from 120.0.45.5, 48 ms

Reply to request 1 from 120.0.45.5, 8 ms

Reply to request 1 from 120.0.0.1, 244 ms

Reply to request 2 from 120.0.45.5, 12 ms

Reply to request 2 from 120.0.0.1, 116 ms

Below indicates that R2 has actually won the election so it is forwarding multicast traffic onto the 120.0.0.0/24 network which is not what we want.

R2#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:33:53/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:11:57/00:00:00

    Serial2/0, Forward/Dense, 00:33:53/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:33/00:02:26, flags: T

  Incoming interface: Serial2/0, RPF nbr 120.0.24.4

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:33/00:00:00, A

We can see this if we enable debug.

R3#debug ip pim

R$#debug ip pim

R2 output:

*Nov 15 16:53:39.623: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [90/2170112]

*Nov 15 16:53:39.627: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.631: PIM(0): We win, our metric [90/2170112]

*Nov 15 16:53:39.631: PIM(0): (120.0.45.5/32, 232.0.0.2) oif GigabitEthernet0/0 in Forward state

R3 output:

*Nov 15 16:53:39.251: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.2

*Nov 15 16:53:39.255: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.255: PIM(0): We lose, our metric [110/2]

*Nov 15 16:53:39.259: PIM(0): Prune GigabitEthernet0/0/232.0.0.2 from (120.0.45.5/32, 232.0.0.2)

So how do we fix this to meet the lab requirements?

When a multiple routers attempt to simultaneously send multicast traffic onto the same network with the same (S,G) each router will immediately send a PIM assert message to prevent duplication of traffic. The election is won based on the following criteria.

First, the IGP AD is compared, with the better AD winning the election

If the AD is equal then the metric is compared the better metric winning the election

If both AD and Metric are equal then the router with the higher IP address wins.

The loser of the election it will remove its (S,G) state and prune its interfaces.

So to fix this issue we need to get R3 to win this election. So to do this and meet the lab requirements we need to have R3 have a better multicast route with a better AD. 

R3(config)#ip mroute 120.0.45.0 255.255.255.0 120.0.34.4

The above command should fix this problem.

R3#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:49:13/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Dense, 00:49:13/00:00:00

    GigabitEthernet0/0, Forward/Dense, 00:49:13/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:37/00:02:22, flags: T

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.34.4, Mroute

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:37/00:00:00, A


R2:

*Nov 15 17:08:55.835: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.3
*Nov 15 17:08:55.835: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:55.835: PIM(0): We lose, our metric [90/2170112]

R3:

*Nov 15 17:08:56.367: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [0/0]
*Nov 15 17:08:56.367: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:56.367: PIM(0): We win, our metric [0/0]

Lab 1 - Multicast PIM RPF Failures

Overview

Reverse path forwarding is the loop prevention mechanism for PIM. PIM relies on the underlying IGP and local routing table to know how to forward packets. One check to ensure that it does not loop packets is to check the source address of an incoming multicast packet by looking up the source IP in the local routing table and confirm that its path back to the source address is the same path that the packet was received through. This is referred to as the reverse path forwarding check. If this check fails then the packet is dropped. RPF failures can happen for several reason usually related to multi-path environments where either PIM is not enabled on all or the correct paths from the source to the reciever or there is an underlying issue where the multicast packet's source IP doesn't not match the interface it arrived on.

Concepts tested

• IGP routing
• PIM RPF Verification
• Enabling PIM

Topology

Lab Tasks

• Enable PIM on the path between R1 to the client device on the Gigabit Ethernet interfaces only.
• Test the configuration by joining the group 239.0.0.1 via the Clients G0/0 interface
• Ping the 239.0.0.1 group sourcing it from R1's loopback 0 interface to confirm multicast packets reach the receiver.
• Resolve any issues using the simply method and with modify routing or the topology.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

To begin lets configure our PIM neighbors.

R1(config)#ip multicast-routing
R1(config)#interface gig0/0
R1(config-if)#ip pim dense-mode

R2(config)#ip multicast-routing
R2(config)#interface gigabitEthernet 0/0
R2(config-if)#ip pim dense-mode
R2(config)#interface gigabitEthernet 1/0
R2(config-if)#ip pim dense-mode



R3(config)#ip multicast-routing
R3(config)#int g0/0
R3(config-if)#ip pim dense-mode
R3(config)#interface g1/0
R3(config-if)#ip pim dense-mode

With our PIM DM configuration in place we should see our PIM neighbor come up.

*Nov 14 14:05:35.559: %PIM-5-DRCHG: DR change from neighbor 120.0.12.1 to 120.0.12.2 on interface GigabitEthernet0/0

*Nov 14 14:05:37.127: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.12.2 on interface GigabitEthernet0/0

*Nov 14 14:07:45.799: %PIM-5-DRCHG: DR change from neighbor 120.0.23.2 to 120.0.23.3 on interface GigabitEthernet1/0

*Nov 14 14:07:48.363: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.23.3 on interface GigabitEthernet0/0

*Nov 14 14:07:59.111: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.30.3 on interface GigabitEthernet1/0

Now lets test our configuration:

Client(config)#ip multicast-routing
Client(config)#int g0/0
Client(config-if)#ip pim dense-mode
Client(config-if)#ip igmp join-group 239.0.0.1

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.......

Client#sh ip mroute 239.0.0.1

(*, 239.0.0.1), 00:02:19/00:02:41, RP 0.0.0.0, flags: DCL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:02:19/00:00:00

We can't ping our receiver, notice the incoming interface on the client is Null. lets look upstream to see what else we notice.

R2#sh ip mroute 239.0.0.1

(*, 239.0.0.1), 00:00:34/stopped, RP 0.0.0.0, flags: D

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Dense, 00:00:34/00:00:00

    GigabitEthernet0/0, Forward/Dense, 00:00:34/00:00:00

(1.1.1.1, 239.0.0.1), 00:00:34/00:02:25, flags: PT

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.23.3

  Outgoing interface list:

    GigabitEthernet0/0, Prune/Dense, 00:00:33/00:02:26

R3#sh ip mroute 239.0.0.1

(*, 239.0.0.1), 00:15:46/00:02:13, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Dense, 00:15:46/00:00:00

    GigabitEthernet0/0, Forward/Dense, 00:15:46/00:00:00

So we can see that the RPF check is working on R2 since we can see our S,G entry for our source on R2 but R3 does not have a S,G. lets look at that.

R2#sh ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
  RPF interface: GigabitEthernet1/0
  RPF neighbor: ? (120.0.23.3)
  RPF route/mask: 1.1.1.0/24
  RPF type: unicast (eigrp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

R3#show ip rpf 1.1.1.1

 failed, no route exists

lets debug on R3 to see what might be going on.

R3(config)#int g0/0

R3(config-if)#no ip mfib cef input

R3(config-if)#no ip mfib cef out

R3(config-if)#int tu 0

R3(config-if)#no ip mfib cef input

R3(config-if)#no ip mfib cef out

* you must turn off fast switching in order to see the debug output below.

R3#deb ip mfib pak

*Nov 14 14:41:36.343: MFIBv4(0x0): Pkt (1.1.1.1,239.0.0.1) from Tunnel0 (PS) Acceptance check failed - dropping

*Nov 14 14:41:37.399: MFIBv4(0x0): Pkt (120.0.23.2,224.0.0.10) from GigabitEthernet0/0 (PS) copying to an internal member from GigabitEthernet0/0

*Nov 14 14:41:37.403: MFIBv4(0x0): Pkt (120.0.23.2,224.0.0.10) from GigabitEthernet0/0 (PS) Acceptance check failed - dropping

*Nov 14 14:41:38.287: MFIBv4(0x0): Pkt (120.0.13.1,224.0.0.10) from Tunnel0 (PS) copying to an internal member from Tunnel0

*Nov 14 14:41:38.291: MFIBv4(0x0): Pkt (120.0.13.1,224.0.0.10) from Tunnel0 (PS) Acceptance check failed - dropping

*Nov 14 14:41:38.315: MFIBv4(0x0): Pkt (1.1.1.1,239.0.0.1) (TS) input interface cannot forward, punting

We are not passing RPF, lets look out our routing tables.

Routing entry for 1.1.1.0/24
  Known via "eigrp 1", distance 90, metric 27008000, type internal
  Redistributing via eigrp 1
  Last update from 120.0.13.1 on Tunnel0, 00:42:02 ago
  Routing Descriptor Blocks:
  * 120.0.13.1, from 120.0.13.1, 00:42:02 ago, via Tunnel0
      Route metric is 27008000, traffic share count is 1
      Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1476 bytes
      Loading 1/255, Hops 1
R3#sh ip route multicast 1.1.1.1
Routing Table: multicast
Routing entry for 1.1.1.0/24
  Known via "eigrp 1", distance 90, metric 27008000, type internal, replicated
  Last update from 120.0.13.1 on Tunnel0, 00:42:10 ago
  Routing Descriptor Blocks:
  * 120.0.13.1 (default), from 120.0.13.1, 00:42:10 ago, via Tunnel0
      Route metric is 27008000, traffic share count is 1
      Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1476 bytes
      Loading 1/255, Hops 1

But we don't have PIM enabled on the tunnel. The lab tasks say we can't change routing or the topology so the only thing that remains is to make TU 0 PIM enable so multicast packets from 1.1.1.1 the come down the interface pass RPF.



R3(config)#int tunnel 0
R3(config-if)#ip pim dense-mode

R1(config)#int tunnel 0
R1(config-if)#ip pim dense-mode

R1#ping 239.0.0.1 source loopback 0 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

Reply to request 0 from 120.0.30.1, 152 ms
Reply to request 2 from 120.0.30.1, 88 ms
Reply to request 3 from 120.0.30.1, 108 ms
Reply to request 4 from 120.0.30.1, 108 ms
Reply to request 5 from 120.0.30.1, 140 ms
Reply to request 6 from 120.0.30.1, 120 ms

Now we can ping our receiver.