[c-nsp] Asymmetric routing

Phil Mayers p.mayers at imperial.ac.uk
Fri May 19 12:49:01 EDT 2006


Michael Robson wrote:
>>
> 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

It's not a problem.

Multipath is a problem with various solutions, but plain old asymmetry 
should in principle NEVER cause issues because the explicit join flows 
up an unambiguous path, creating explicit and unambiguous egress state 
as it goes (excepting after a routing flap of course).

> 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)

Load sharing (equal cost) is definitely an issue. "ip multicast 
multipath" is the command to research.

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

Broadly:

       internet
          |
         [e0]
        border
       [e1][e2]
        /    \
       /      \
     [e0]     [e0]
[e2]core1   core2
  |  [e1]     [e1]
  |    \      /
  |     \    /
  |    [e1][e2]
  |     core3
[e1]
edge
[e0]
  |
client

Let's say client's default route is edge-core1-core3-core2-border and 
border has border-core1-edge-client.

In this case a join for (s,g) goes up the left leg then anti-clockwise 
around the network, creating the forwarding state:

edge   - (s,g) input=e1 output=[e0,]
core1  - (s,g) input=e1 output=[e2,]
core3  - (s,g) input=e2 output=[e1,]
core2  - (s,g) input=e0 output=[e1,]
border - (s,g) input=e0 output=[e2,]

...and the packets come into border and follow that reverse path just fine.

Hopefully you can see that there are no issues here. Since border 
doesn't know what receiver the packet is going to, only what source it 
came from, the route to edge/client is irrelevant - all that matters is 
that a join for that (s,g) came into an interface, therefore data 
packets will go out of that interface.

Multiaccess network (i.e. not point-to-points) are a little more complex 
and make use of PIM asserts but basically the same thing happens.


More information about the cisco-nsp mailing list