[c-nsp] Asymmetric routing

[Alexander Gall]

On Tue, 16 May 2006 22:10:55 +0100, "Michael Robson" <Michael.Robson at manchester.ac.uk> said:

>> Michael Robson wrote:
>> > Has anyone experienced asymmetric routing within their network that 
>> > caused multicast RPF checks to fail and so break multicast?
>> > More generally, what are people doing design-wise on their 
>> networks , 
>> > if anything, to avoid such problems on ever increasingly resilient, 
>> > meshed networks?
>> 
>> Michael,
>> 
>> Could you be a bit more specific about the problem you're having? 
>> Assuming PIM-SM, this ought not to be a problem - the normal 
>> propagation of joins towards a source should build a correct oif list.
>> 
>> What platform are you on?
>> 
> There isn't a problem yet, but with multiple links out of the network and
> a highly meshed network, I can reason through that it would be [almost]
> impossible to avoid asymmetric routing in all cases for the network I am
> currently designing. I haven't seen or heard of any real problems "in the
> wild"
> where multicast routing has been broken by 
> asymmetric routing, but I can only see problems if 2 links out of the
> network (both leading to the same network upstream but at different points)
> load share the traffic, especially if topology changes (down links etc)

Note that unicast equal-cost paths don't imply multicast
load-splitting.  PIM-SM specifies that if there are equal-cost unicast
paths, the actual RPF neighbor is the neighbor with the highest IP
address and only one link will be used for multicast.  However, there
is the "ip multicast multipath" feature in IOS that allows
load-splitting based on the source address.

> occur. I am trying to understand why m-RPF fails because of asymmetry isn't
> an issue.

This is simply because only one direction ever matters for *both*
directions, PIM-SM signalling (joins) and data forwarding: a
join/prune message is forwarded towards the source/RP.  Data packets
are forwarded based on the state created by the joins, which
guarantees that it is received on the RPF interface to the source/RP
on the downstream router (unless there is a routing change, of course,
in which case the tree will be re-established once the new topology is
stable).

Another way to think about it is that the routes from a source/RP to
the receivers are irrelevant for PIM-SM.  All receivers are labeled by
the multicast address and their unicast addresses are not carried in
PIM messages at all.  Therefore, asymmetry can never be a problem.

--
Alex