Experimental principle of reverse route forwarding for CISCO Multicast RPF

Technorati labels: CISCO, multicast, multicast, RPF, CCIE

RPF, reverse path forwarding.

It is an important foundation for multicast forwarding. 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:

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, the RPF check of loop multicast is enabled by default and cannot be disabled); for unicast, RPF check must be manually configured to prevent IP spoofing attacks)

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:

650) this. width = 650; "style =" background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; border-top: 0px; border-right: 0px; padding-top: 0px "title =" clip_image002 "border =" 0 "alt =" clip_image002 "height =" 202 "src =" http://www.bkjia.com/uploads/allimg/131227/015G52Q5-0.jpg "/>

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, configure ip pim sparse-mode under each interface.

F0/0 of R2 is used as rp candidate and bsr candidate.

At this time, the unicast and multicast parts of the entire network are 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 set up on R4 to simulate the connection to the multicast client receiver. The command ip igmp join 224.1.1.1 can be run under the interface.

650) this. width = 650; "style =" background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; border-top: 0px; border-right: 0px; padding-top: 0px "title =" clip_image004 "border =" 0 "alt =" clip_image004 "height =" 130 "src =" http://www.bkjia.com/uploads/allimg/131227/015G53438-1.jpg "/>

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.

650) this. width = 650; "style =" background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; border-top: 0px; border-right: 0px; padding-top: 0px "title =" clip_image006 "border =" 0 "alt =" clip_image006 "height =" 131 "src =" http://www.bkjia.com/uploads/allimg/131227/015G52324-2.jpg "/>

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.

650) this. width = 650; "style =" background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; border-top: 0px; border-right: 0px; padding-top: 0px "title =" clip_image008 "border =" 0 "alt =" clip_image008 "height =" 237 "src =" http://www.bkjia.com/uploads/allimg/131227/015G55R9-3.jpg "/>

The experiment starts here.R3OfF1/0Interface,No ip pim sparse-mode,Then the multicast traffic will be sent from the brown pathR3,HoweverR3The route shown above is a red line. At this timeRPFDetection fails because the interface for receiving multicast traffic is not the same as the interface for returning unicast routes.

On R3, we can see that:

Previously there was no interface f1/0 on R3 to delete the command ip pim sparse-mode:

R3 # show ip rpf 1.1.1.1

RPF information? (1.1.1.1)

RPF interface: FastEthernet1/0

RPF neighbor :? (3.1.1.1)

RPF route/mask: 1.1.1.0/24

RPF type: unicast (ospf 1)

RPF recursion count: 0

Doing distance-preferred lookups internal SS tables

After deletion, let's look at the rpf Detection:

R3 # show ip rpf 1.1.1.1

RPF information? (1.1.1.1) failed, no route exists

The reason is that R3 removes the pim protocol in f1/0, so it cannot establish a neighbor with the peer f1/0, and the natural multicast traffic will not be forwarded through the Ethernet, r3 receives multicast traffic only from s2/0. However, the route table on R3 uses the shortest path as ospf. Therefore, it uses the Ethernet port when going back, path mismatch, packet loss...

R3 # show ip route 1.1.1.1

Routing entry for 1.1.1.0/24

Known via "ospf 1", distance 110, metric 2, type intra area

Last update from 3.1.1.1 on FastEthernet1/0, 00:04:10 ago

Routing 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

This article is from the "thank-me, only focus on the principle" blog, please be sure to keep this source http://361531.blog.51cto.com/351531/911138