Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

MVPN RPF: traffic-eng multicast-intact + forwarding-adjacency rpf failure

Hello all,

Am going through a bit of pain at the moment trying to get around TE tunnels breaking RPF checks for multicast.

The common wisdom seems to be to use the "mpls traffic-eng multicast-intact" command, however this only seems to work for TE auto-route.

Is it reasonable to expect that this should work for forwarding-adjacency also?

The documentation says that by using the multicast-intact command, that it will not consider TE tunnels in the RPF check. It seems to me that this should work for forwarding-adjacency as well as auto-route.

This is on 7600s running RSP720s (SRB).

Any hints?

I can provide more details on the design if necessary.

Regards,

Anton

1 ACCEPTED SOLUTION

Accepted Solutions

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

The reason is the same, subtlv's are assigned for TE tunnels without FA, and with FA they are not. Autoroute is more a method of using that TE tunnel to route traffic. Instead of autoroute you can try using a static route pointing to the Tunnel Destination, even then with multicast intact the RPF would pass. So from observation I feel the multicast intact feature is more to do with the sub-tlv being assigned or not. Thats how it can differentiate.

Now loop may not be the appropriate term here, its kind of a loop or assymetric routing.

For eg if they are advertised with TE extensions as well, other TE tunnels will use the FA TE tunnel to reach their destination and when you

have explicity set superior FA metric to the tunnel destinations compared to the physical link metric this is aggravated. And may beat the purpose of

having FA tunnels with customized metrics.

HTH-Cheers,

Swaroop

11 REPLIES

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

Anton, When using forwarding adj the link is advertised with TLV22 excluding any TE extensions. For the unicast routing table the entry is as good as any other unicast IPv4 entry. There is no way for it to distinguish it as a TE tunnel. (Although it is built using existing TE extensions of physical links, it it self doesnt have any TE extensions, if it had it would lead to loops or assymetric routing)

So I believe multicast intact feature would not work with forwarding adjacency for now .

Although we have implemented MTR for similar reasons for some customers.

Here is a link for MTR and configuration details.

http://www.cisco.com/en/US/products/ps6922/products_feature_guide09186a00807c64b8.html

Do note that, you will have to remove multicast-intact when configuring MTR. MTR build its own mcast topology using the links which you specify, while doing this you can explicity exclude the TE tunnels from the MTR topology, hence avoiding those TE tunnels from RPF checks. (use MTR only for multicast)

HTH-Cheers,

Swaroop

Community Member

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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.

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

The reason is the same, subtlv's are assigned for TE tunnels without FA, and with FA they are not. Autoroute is more a method of using that TE tunnel to route traffic. Instead of autoroute you can try using a static route pointing to the Tunnel Destination, even then with multicast intact the RPF would pass. So from observation I feel the multicast intact feature is more to do with the sub-tlv being assigned or not. Thats how it can differentiate.

Now loop may not be the appropriate term here, its kind of a loop or assymetric routing.

For eg if they are advertised with TE extensions as well, other TE tunnels will use the FA TE tunnel to reach their destination and when you

have explicity set superior FA metric to the tunnel destinations compared to the physical link metric this is aggravated. And may beat the purpose of

having FA tunnels with customized metrics.

HTH-Cheers,

Swaroop

Community Member

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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

Cisco Employee

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

Anton,

The "mpls traffic-eng multicast-intact" is indeed only applicable to autoroute announce.

You can use an "ip mroute" as a work around.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Community Member

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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

Cisco Employee

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

Anton,

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

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Community Member

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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

Community Member

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

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

Cisco Employee

Re: MVPN RPF: traffic-eng multicast-intact + forwarding-adjacenc

Anton,

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

Regards,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
548
Views
15
Helpful
11
Replies
CreatePlease to create content