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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

MPLS TE fast-reroute swicth time?


I always heard we can achieve 50ms switch time by FRR, when applying to VPLS, make Metro Ethernet using VPLS without STP reduce the covergence time greatly to 50ms too. But I wonder if it's ture? The 50ms switch time could be achieved when SDH is used because FRR can detect alarm from SDH, but how can FRR dectect ethernet link failure faster?

Your comments are appreciated!

Cisco Employee

Re: MPLS TE fast-reroute swicth time?

The 50ms assumes Sonet/SDH in the core.

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
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
New Member

Re: MPLS TE fast-reroute swicth time?

how do you think about Gb Ethernet connection? for example, core routers are connected by GE directly?


Re: MPLS TE fast-reroute swicth time?


there are mainly two contributions to FRR time as far as I know.

First you have to detect the failure, second the router switches over to the predefined backup LSP.

The second portion is only a local rewrite of the LFIB and should be practically instantaneous.

The first one is the major contribution. In SONET/SDH a failure condition in the optical network is propagated in the SONET/SDH frames, thus it is rather quick to detect failures.

With ethernet that might be different. Assume two routers connected through a LAN switch. In this case a link-down event in one router will only be detected by means of keepalives. Those might be your routing hellos or in MPLS TE also RSVP messages. With standard timers that means several seconds. However f.e. in IS-IS we can lower keepalive timers to less than a second and hold timer to one second. This should be designed carefully not to introduce unwanted instability into your routing.

In any case you cannot reach 50ms in this scenario.

The question should be really which convergence time is acceptable in your environment, i.e. which applications require much less than a second outage and does it justify the efforts.



CreatePlease login to create content