[Xorp-users] Problems with bootstrap and rp selection in pimsm

[Dan Rosenqvist]

Hi David,

This problem was discovered by a friend who tried setting up a network with multiple paths from sender to receiver (this was unicast traffic). As he changed the interface cost of one of the interfaces, he actively created asymmetric routing, causing rp_filter to start dropping packets. He tipped me that I could test this for mcast as well, and it worked.

The question now is why this is happening for multicast packets? My best guess is that it has to do with the register message encapsulation. When rp_filter is run in strict mode (1), my rp is receiving the register messages. As the rp in this case is directly connected to the receiver, the message should be decapsulated and forwarded to the receiver, but this never happens. Could it be that the rp_filter is blocking these messages? Upon decapsulation, the message is once again treated as a multicast packet, but it wasn't received from any interface (as it was recreated in the node itself) and thus blocked by rp_filter. So basically, the RP in this case is spoofing messages as a part of the protocol.

Regarding the list of RPs, I've found that all cand-rps are listed, but if you'd have a look at "show pim mfc" in order to see which rp is used for the current groups (showing the correctly chosen RP).

Regards,
Dan

________________________________
Från: David Davidson [david at commroom.net]
Skickat: den 19 juni 2012 07:31
Till: Dan Rosenqvist
Kopia: xorp-users at xorp.org
Ämne: Re: [Xorp-users] Problems with bootstrap and rp selection in pimsm

Hi Dan:

That's an excellent find! I also discovered your finding to be correct. How did you find that? So that's an excellent find - thank you for sharing this.

And so in my testing I found the same thing. First, I used udpcast instead of iperf. You will notice how I did these in the attachment. I had host1 be one of the receivers AND the sender, since udpcast requires there to be 2 (or more) real receivers in order to send a real multicast stream (if there is only one receiver, it will unicast the stream to the one receiver which doesn't help our test).

By default, my test machines all had "net.ipv4.conf.all.rp_filter = 1" set in the /etc/sysctl.conf file.

And then I couldn't join any groups (specifically, host2's join would not be propagated through the PIM domain, toward the RP and ultimately, never toward the sender). As soon as I set "net.ipv4.conf.all.rp_filter = 0" in the /etc/sysctl.conf file, and then doing a sysctl -p, it worked. That would be a permanent solution, or simply doing an echo of zero to it, meaning, doing a "echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter" then it also worked perfectly, but this obviously this wouldn't survive a reboot without modifying /etc/sysctl.conf.

Before noticing this, I did still go ahead and test your configuration in a vacuum. I like set commands, so please check over my attachment - I am pretty certain that it's what you're also using on your routers.

After reading what you wrote (and testing it) I found at least one production XORP machine that I have, that is definitely being used for multicast, in which the init script (the startup script for XORP) has "echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter" in the script, which leads me to believe that there once was a time when I discovered this myself (I wrote pieces of this particular init script). It puzzled me because this line was commented in my script, but as it turns out that this machine has another process that sets this to zero (doing a cat /proc/sys/net/ipv4/conf/all/rp_filter on that machine returns a zero on this production machine that I was looking at this evening). So I discovered this one other time, but I certainly do not recall the why or the how. Maybe you could share with us how you found this and what led you to it.

However, I still think that this should work, even with RP checking being enforced. Many systems enforce reverse path checking, and for a very good reason. It seems like it would be less secure to have this RP checking turned off throughout one's routing domain. Often times, many network vendors implement 2 options for RP checking, one less stricter than the other; 1 option is just to make sure that the return route is in the routing table, no matter what the next-hop interface for that route, while the other option would enforce the next-hop interface for that route. Some refer to these as "loose" and "strict" RP checking. Notice how the first option, being less strict, and more flexible, would definitely qualify under a default route; for example, having a 0.0.0.0/0 route on the system would pass the RP check for the less strict option, even if the route wasn't explicitly configured (as long as 0/0 was there, this would cover it for the "loose" option).

That said, I am still puzzled as to why this RP checking would affect multicast numbers. So then I thought, maybe we need to have this set to a "2" which would make your default route (the 0.0.0.0/0 route you have resolving to the "my_discard" interface) qualify for the RP check (the "loose" RP check). Still, this is less than secure in many instances, depending on the network security policies for a particular organization - and, it didn't really matter anyway because, during my testing, this still didn't do the trick. rp_filter = 0 was the only thing that worked.

Also I wanted to share that I also found that regardless of the RP check (whether set to zero, one, or two) I always had converged on 1 elected bootstrap router, and there were 3 active RP's, but Router3 was always the elected BSR. The RP with the priority of 191 always bubbled to the top of the list when I did a "show pim rps" or "show pim bootstrap rps" So here again, this should fit the scenario you described - having a single BSR choose which RP to use for a particular sender.

What do you think? If you find out anything else, please let us know.

Thanks again for testing and reporting!

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120619/796fce9b/attachment.html