Hi, thank you very much for your reply.

Can you please give an example of how a loop might form if it advertised the link with TE extensions? I'm finding it a little hard to visualise.

I understand that routers surrounding a router with a TE tunnel are not aware that the link is a tunnel, however, shouldn't the router with the head-end be easily able to make the distinction? How does it make the distinction locally (with multicast intact) when using auto-route, and why doesn't this mechanism work (locally) for forwarding-adjacency?

Thank you very much for the MTR link, I'm pretty sure we will go ahead with this.

Hi Swaroop,

Very insightful.

However here is a bit of food for thought: what if the box with the head end did not advertise TE extensions for the FA tunnel link, but was still able (itself/locally) to distinguish (through internal record keeping) that it was a TE tunnel?

For example, a separate table in memory that it could check against when doing things such as RPF checks. Or another field/flag in its unicast routing table, something that is not advertised anywhere but is simply local.

I know this might be wishful thinking for now, but in our case it would have solved our problem if the box could locally detect and ignore TE tunnels for multicast RPF.

Best regards,

Anton

Anton,

Definately a food for thought and a good idea. Only thing is there is no such standard which specifies this. So this can be done, and when done would be based upon each vendor.

As its more of a manipulation in the software.

And when done this method could be implemented only when its all a single vendor setup. In terms of interop this may not be feasible (if the other vendor supports only MTR as an option for FA then we also have to run MTR only for mcast routing).

But overall should be very much possible to have this kind of a tweak, but again depends on how many people are requesting for it and how important is it. As any vendor would look for a feature requests feasibility and its demand.

HTH-Cheers,

Swaroop

Hi Hritter,

Thanks for the response. Unfortunately ip mroute is not an option for us because it is a ring topology, and we need a dynamic solution.

Thanks again,

Anton

Anton,

But won't your tunnel be dynamic? Please explain.

Regards,

Yes, our tunnel will be dynamic also.

It is a ring based off our main core. I'm going to try a bit of ascii art..

http://www.huge.geek.nz/ascii.txt

We are using TE tunnels with FA from R2/R3 back to C3/C4 to control traffic on our ring (we have congestion so we need to spread the traffic around using TE).

At the moment, we also have multicast flooding in both directions around the ring. Each of the ring PEs needs to receive the multicast.

Our TE tunnels have a deliberate lower metric than the ring so that they will draw all traffic to/from the core to/from the ring PEs. They are also running ldp over rsvp.

This breaks multicast because it arrives on a physical interface but has a route back through the TE tunnels.

If we add a static mroute pointing in the usual arrival direction of the multicast then it will fix the problem, until that leg of the ring breaks. If we point the static at a recursive target then it will most likely choose the tunnel and we have the same RPF problem again. Hope this explains it.. otherwise I can provide more detail.

Regards,

Anton

Hi again,

Sorry, I should elaborate - our tunnels are not dynamic, we are using affinity (east/west) to control which direction they go around the ring.

Regards,

Anton

Anton,

Sorry, I misunderstood your question. The workaround I proposed is not applicable in this case.

Regards,