MPLS FRR

Jon Marshall · ‎03-17-2008

Apologies for the very basic diagram. I am trying to get MPLS FRR working in my lab and have a couple of questions

The 7200 routers do support MPLS FRR whereas the 2621XM routers support MPLS TE but not MPLS FRR.

1) With the equipment shown in the diagram will it work. I read in one of the Cisco docs that the tail-end router also needs to support FRR but i'm not entirely sure what router they are referring to.

2) All the connections are ethernet.

Without FRR ie.

tunnel100 is just another tunnel and fa0/1 is not configured with the "mpls traffic-eng backup-path tunnel 100" when I shut down int fa0/1 then traffic goes via tunnel 100 as expected.

While it is switching across i get 1 or 2 "request timed out" on my pings.

3) I'm assuming that if i can get FRR working i shouldn't lose any pings - is that correct ?

When i do configure FRR ie.

int tunnel1

tunnel mpls traffic-eng fast-reroute

int fa0/1

mpls traffic-eng backup-path tunnel100

and then shut down fa0/1 i still get 1 or 2 "request timed out". When i do a

"sh mpls traffic-eng fast-reroute database" this is the output i get

7206vxr2#sh mpls traffic-eng fast-reroute database

Tunnel head end item frr information:

Protected tunnel In-label Out intf/label FRR intf/label Status

Prefix item frr information:

Prefix Tunnel In-label Out intf/label FRR intf/label Status

LSP midpoint item frr information:

LSP identifier In-label Out intf/label FRR intf/label Status

192.168.70.5 1 [18] 67 Fa0/1:25 Tu100:25 ready

7206vxr2#

There is no entry under the "Protected tunnel" line.

Could anyone help me on this.

Many thanks

Jon

mheusing · ‎03-17-2008

Hi,

can you post the output from "show mpls traffic-eng fast-reroute database state active", when the int fa0/1 is shut?

This should list the FRR active tunnels.

I relate your outage of 1 or 2 pings to the detection time of the interface down event and the resulting corrective actions for the return traffic.

To get "uninterrupted" traffic flow, you would need FRR on both ends of your Fa0/1.

Hope this helps!

Regards, Martin

Jon Marshall · ‎03-17-2008

Martin

Here you go

7206vxr2#sh mpls traffic-eng fast-reroute database state active

Tunnel head end item frr information:

Protected tunnel In-label Out intf/label FRR intf/label Status

Prefix item frr information:

Prefix Tunnel In-label Out intf/label FRR intf/label Status

LSP midpoint item frr information:

LSP identifier In-label Out intf/label FRR intf/label Status

192.168.70.5 1 [18] 67 Fa0/1:25 Tu100:25 active

7206vxr2#

So without FRR i would get 1 or 2 pings missed.

With FRR on both ends i would not get any missing pings ?. If so looks like i need to find another 7200 :-)

In the docs when you run the "sh mpls traffic-eng fast-reroute database" it shows the protected tunnel but it isn't on my 7200. Is this what you would expect.

Jon

Jon Marshall · ‎03-17-2008

Martin

One further question. You mention that i need FRR on the other end of the fa0/1 link. I have found a spare 7200 which i can use temporarily but will this be enough ?

The 2621XM does not support FRR so if i replace the 21621XM at the other end of the fa0/1 interface with a 7200 what about the router on the far left of the diagram. This will still be a 2621XM and this router will not take the "tunnel mpls traffic-eng fast-reroute" command.

Thanks

Jon

mheusing · ‎03-18-2008

Hi Jon,

a traceroute to destinations routed across the protected tunnel should show you the labels in use and reveal if FRR is working or not. If you can prove that FRR is working, the only remaining task is to understand, if the output of "sh mpls traffic-eng fast-reroute database" is consistent across all platforms and versions ;-)

The output shown, tells you, that there is a protected LSP (hence tunnel).

Side notes:

1) an explicit path containing the protected link would make sure the protected tunnel is not resignalled, if the protected link is down.

2) the use of "mpls label range" with distinct ranges (R1: 1000 1999; R2: 2000 2999; ...) usually helps me a lot in a lab environment.

If FRR is working correctly then there should be no more than 1 or two missing ping packets - you could kill a packet by "cutting it" with your interface shutdown. The default 2 sec timeout should be more than enough to rewrite the LFIB.

Last, if the protection of a TE tunnel is not requested by the head end during setup, then it would not be protected. The head end router needs to "understand" the concept of FRR, as he will be informed by the PLR - "Keep forwarding traffic onto your tunnel despite the fact that the path is not valid (link down), as the tunnel is protected".

Hope this helps! Please use the rating system.

Regards, Martin

P.S.: In case you run out of physical 7200 routers: dynamips will allow you to setup your complete topology with 7200 routers only :-)

Jon Marshall · ‎03-18-2008

Martin

Many thanks

Jon

mmelbourne · ‎03-26-2008

Hi,

Would you be willing to share your lab configs, as I'm just trying to work out how all this FRR stuff fits together.

Jon Marshall · ‎03-26-2008

Hi Matthew

I would gladly have shared configs but they have all been wiped a while back. I never had enough 7200's to do FRR both ways so i never really got it tested the way i wanted.

However much of it is still fairly fresh in my head so is there something specific you were looking for ?

Jon

mmelbourne · ‎03-26-2008

Once consideration is the relative merits of protecting a specific end-to-end tunnel with a specific backup tunnel versus AutoTunnel Primary (where all traffic is routed through one-hop protected Primary TE tunnels) together with an AutoTunnel next-hop backup?