You are on page 1of 14
osiosi2023, 22:42 Multicast RPF (Reverse Path Forwarding) Search Q © Multicast RPF (Reverse Path Forwarding) One of the key differences between unicast and multicast is that for unicast routing, we only care about where the destination is located and how to get there, For multicast routing, we care about where the source is located. PIM (Protocol independent Multicast) uses the unicast routing table to check what interface will be used to reach the source. PIM will only accept multicast packets on an interface we use to reach the source. If we receive multicast, packets on an interface we don't use to reach the source, we will drop the multicast packets! This is called an RPF failure, and its the #1 issue why multicast isn’t working for many networking students. Let me demonstrate this using a very simple topology: N 1 = = o 8 a & gl wo 7 3 Rn F.2 a 192.168.23.0 /24 4 » Fa0/1- Fao/t 2 L w © 380 2s ; Ne . +s 192.168.32.0 /24 © cere Above, you see three routers. R1 will be the source for our multicast traffic. Between R2 and R3, we have ‘two links... slow serial link and a Fastéthernet link. R3 has a loopback interface we will use as the receiver hllps:inetworklessons.com/mullicastmullicastrpt-reverse-path-forwarding on (091052023, 22:42 Muleast RPF (Reverse Path Forwarding) a R1(config)#router ospf 1 R1(config-router)#network 0.0.0.0 255.255.255.255 area ® R2(config)#router ospf 1 R2(config-router)#network 0.0.0.0 255.255.255.255 area 0 R3(config)#router ospf 1 R3(config-router)#network @.0.0.0 255.255.255.255 area @ | will enable OSPF on all interfaces quickly using the network command above. OSPF will prefer to use the FastEthernet link and won't use the serial link: R2#tshow ip route ospf 3.0.0.0/32 is subnetted, 1 subnets 0 3.3.3.3 [110/11] via 192.168.23.3, 00:00:02, FastEtherneto/1 ‘As you can see we don't use the serial link because the Fastéthernet link has a lower cost. Now I'm going to configure multicast on all routers, but | will only activate it on the serial link between R2 and R3: Ri(config)#ip multicast-routing R1(config)#interface fastEthernet 0/2 R1(config-if)#ip pim dense-mode R2(config)#ip multicast-routing R2(config)#interface fastEthernet 0/8 R2(config-if)#ip pim dense-mode R2(config)#interface serial 0/0 R2(config-if)#ip pim dense-mode @ R3(config)#ip multicast-routing R3(config)#interface serial 0/0 hitpstnetworklessons.com/mulicastmulicastrp-raverse-path-forwarding ana (091052023, 22:42 Muleast RPF (Reverse Path Forwarding) a R3(config)#interface loopback @ R3(config-if)#ip pim dense-mode | activated PIM dense mode, so we don't have to worry about an RP (Rendezvous Point). This is what we have right now: * We use the FastEthernet link between R2 and R3 for ut ast traffic. * We use the serial link between R2 and R3 for multicast traffic. Let's send some multicast traffic from R1 and receive it on R3: R3(config)#interface loopback @ R3(config-if)#ip pim dense-mode R3(config-if)#ip igmp join-group 239.1.1.1 Ri#ping 239.1.1.1 repeat 9999 Type escape sequence to abort. Sending 9999, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds: 3 will join the 239.1.1.1 multicast group address, and R1 will send some pings...as you can see, they are failing. Why? Let's find out: R2itshow ip mroute 239.1.1.1 IP Multicast Routing Table Flags: D L t x u z y Outgoing Timers: ~ Dense, $ - Sparse, B - Bidir Group, s - SSM Group, C - Connected, = Local, P = Pruned, R= RP-bit set, F - Register flag, ~ SPT-bit set, ) - Join SPT, M - MSDP created entry, ~ Proxy Join Timer Running, A - Candidate for MSOP Advertisement, ~ URD, I - Received Source Specific Host Report, @ - Multicast Tunnel, z - MOT-data group sender, - Joined MDT-data group, y - Sending to "OT-data group interface flags: H - Hardware switched, A - Assert winner Uptime/Expires hitpstnetworklessons.com/mulicastmulicastrp-raverse-path-forwarding ana (091052023, 22:42 Muleast RPF (Reverse Path Forwarding) a (*, 239.1.1.1), 08:00:03/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 outgoing interface list: FastEthernet@/@, Forward/Dense, 00:00:03/00:00:00 Serial@/@, Forward/Dense, @0:00:03/00:00:00 (192.168.12.1, 239.1.1.1), 00:00:03/00:02:56, flags: T Incoming interface: FastEthernet@/®, RPF nbr 192.168.12.1 outgoing interface list: Serial@/@, Forward/Dense, 8:00:03/00:00:00 ‘Above, you can see that R2 is forwarding the multicast traffic toward R3. Let's enable multicast debugging on R3 to find out why it is not accepting this traffic: R3(config)#interface serial 0/0 R3(config-if)#no ip mroute-cache Ifyou want to debug multicast traffic, you have to disable multicast route caching, The ip mroute cache command is deprecated since 10S 15. The no ip mfib cef input andno Bip mfib cef output commands in combination with debug ip m#ib ps should work in 10S 15 and later versions. | will do this on the serial interface. Let’s enable that debug: R3idebug ip mpacket IP multicast packets debugging is on IP(@): s=192.168.12.1 (Serial@/@) d=239.1.1.1 id-84, tt1=253, prot=1, len=104(100), not RPF interface Here is the magic answer..."not RPF interface”, Here's what is going on: 8 R3itshow ip route ospf hitpstnetworklessons.com/mulicastmulicastrp-raverse-path-forwarding ana (091052023, 22:42 Muleast RPF (Reverse Path Forwarding) a R3vshow 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, - SPT-bit set, J - Join SPT, M - MSDP created entry, - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, - URD, I - Received Source Specific Host Report, = Multicast Tunnel, z = MDT-data group sender, - Joined MDT-data group, y - Sending to MDT-data group R

You might also like