Experimental principle of reverse route forwarding for CISCO Multicast RPF

Reverse path forwarding is an important foundation for reverse route forwarding in CISCO Multicast RPF. Only after successful RPF detection can multicast traffic be correctly forwarded in the network. When you query the keyword "cisco rpf detection mechanism and working principle" in baidu or google, we can easily obtain the following principle: www.2cto.com RPF check principle: the router searches for the source address in the unicast route table to determine whether the interface to which the data packet arrives is located in the reverse path of the returned source. If yes, the RPF check is successful, if not, mark "RPF failed to discard" and discard the packet. Simply put, check the returned package based on the route table items, and confirm that the returned package is on the first line. Purpose: For multicast, loop protection can be prevented (RPF check is enabled by default and cannot be disabled); for unicast, IP spoofing attacks can be prevented (RPF check must be manually configured) in this simple sentence, I have not really understood the meaning of it many times. Cisco also has a dedicated ppt to explain this problem, but I am still very vague at the end. Yun, but I remember a concept: the direction or interface of multicast traffic, show ip route x. x. x. the route table to which x is returned must be consistent. Otherwise, RPF fails and multicast traffic is discarded. Today, I found an experiment from my colleague. After completing the experiment, I found that RPF is not so mysterious. Here is the experiment process. Let's verify whether it is what I understand above:

In this topology, the R1-R4 configures the interface ip address according to the label in the topology, and enables ip multicast-routing on each router, then configure the F0/0 of the ip pim sparse-mode.R2 under each interface as the rp candidate and bsr candidate. At www.2cto.com, the unicast and multicast parts of the entire network were already active. The configuration of multicast is very simple. Just a few commands. If you have any questions about the configuration of the topology, refer to the attachment. Here we don't need to talk about how to configure multicast. At this time, a loopback interface is created on R4 as an interface to simulate the connection to the multicast client (receiver). The command ip igmp join 224.1.1.1 can be run under the interface.

Then, the loopback0 interface of R4 sends (*, G) join packets to RP. then ping 224.1.1.1 from the R1 router to simulate that R1 acts as the multicast source to send multicast data of 224.1.1.1.

Here we can see. R1 can access ping224.1.1.1. Because R1 is a multicast source, it will be sent (S, G) to register with RP, and then R4 is the multicast client, it will send (*, G) to the rp, then the rp returns S to R4, and finally establishes the SPT (Shortest Path Tree). R4 obtains multicast traffic from R1. Well, the focus is on how RPF works. I have read the principles of online query. Here we use experiments to prove it. In the topology, there are actually two working paths from R1 to R4. The Ethernet ports and the serial ports are also connected. Ospf is enabled for the whole network. At this time, the shortest path based on ospf takes priority. It must be a small cost, so from R4 to R1, Ethernet interfaces are used.

The experiment starts here. If no ip pim sparse-mode is under the f1/0 interface of R3, the multicast traffic will be sent to R3 from the brown path, however, the route returned on R3 is a red line, and RPF detection fails at this time, because the interface for receiving multicast traffic and the interface for returning unicast routing are not the same interface. On R3, we can see that: www.2cto.com was not previously used to interface f1/0 on R3 to delete the command ip pim sparse-mode before: R3 # show ip rpf 1.1.1.1RPF information? (1.1.1.1) RPF interface: FastEthernet1/0RPF neighbor :? (3.1.1.1) RPF route/mask: 1.1.1.0/24RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups into SS tables after deletion, check rpf detection again: r3 # show ip rpf 1.1.1.1RPF information? (1.1.1.1) failed, no route exists because R3 removed the pim protocol in f1/0, so it cannot establish a neighbor with the peer f1/0, natural multicast traffic is not forwarded through the Ethernet. R3 receives multicast traffic only from s2/0. However, because the route table on R3 is ospf, it selects the shortest path, so when I went back, I went through the Ethernet port. The path did not match and packet loss... r3 # show ip route 1.1.1.1 www.2cto.com Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 2, type intra areaLast update from 3.1.1.1 on FastEthernet1/0, 00:04:10 agrouting Descriptor Blocks: * 3.1.1.1, from 3.1.1.1, 00:04:10 ago, via FastEthernet1/0 Route metric is 2, traffic share count is 1 in the RPF source detection standard, there can be only one input interface. The election method is as follows: lower AD & gt; longest match & gt; lower metric & gt; higher ip author hny2000