MPLS TE Link Protection with FRR

[r.hew]

Hi Sir,

Due to inconsistent result during my customer UAT TE link FRR. All the 3 PEs (C7609) link are connected in triangular (three different POPs). From PE-to-PE it's interconnected via DWDM devices. In this scenario, how can we know what type of mechanism is being used to detect GE link failure?

From my understanding, the router can issues thru' an IGP advertisement or an RSVP message.

Need to clarify with your expertise on ip rsvp configuration below, whether can use in our environment and to improve the link detection or not?

# ip rsvp signaling refresh interval ... (default 20ms; 10-30,000ms)

# ip rsvp signaling hello interface

# ip rsvp signaling refresh misses (default 4)

# ip rsvp signaling hello dcsp

If not, what is the alternative or leave it default with FRR configuration as below;

!

interface Tunnel1

description *** Primary TE Tunnel to SKBMPLS1GW ***

ip unnumbered Loopback0

tag-switching ip

tunnel destination 172.18.255.3

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng path-option 1 explicit name path1_SKBMPLS1GW

tunnel mpls traffic-eng path-option 2 dynamic

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng fast-reroute

!

TQ

[swaroop.potdar]

Use the RSVP timers for fast TE Tunnel re-optimization, that is when your existing tunnel fails, then doing a state timeout and signalling a fresh LSP on a different path to the tail end.

FRR will depend on the Link failure and the moment a link falure is detected it switches to the pre-configured backup tunnel, as it cannot wait till the Tunnel re-optimization happens as it has to provide the healing in sub 50ms. And the sub 50 ms value cannot be achieved relying only on Tunnel Re-Optimization. So RSVP is used to signal that the specific primary Tunnel requires protection in the RSVP path messages.

So you can keep you current FRR configuration to what it is right now, and changing the default RSVP timers wont help you to achieve or reduce the FRR healover times (close to 50ms).

The kickin of FRR would depend on the interface status when it goes down, which is dependent on LOS to be received from your DWDM device. And this will happen much faster than the RSVP hello misses.

HTH-Cheers,

Swaroop

For Reference:

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

[mheusinger]

Hi,

do you have the GE config as well? The given tunnel config does not implement FRR. It just states, that this tunnel is allowed to be routed over a protection tunnel in case FRR kicks in. So I would assume you have something like this in your network:

interface Tunnel1

ip unnumbered Loopback0

tunnel destination 1.1.1.1

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng priority 0 0

tunnel mpls traffic-eng path-option 10 explicit ProtectPath 1

interface GigabitEthernet1/0

ip address 192.168.1.1 255.255.255.252

mpls traffic-eng tunnels

mpls traffic-eng backup-path Tunnel1

ip rsvp bandwidth 750000 750000

ip explicit-path ProtectPath 1 enable

next address 2.2.2.2

next address 3.3.3.3

next address 1.1.1.1

In case you cannot detect link failure through layer1 (like with POS) you nee f.e. RSVP hellos.

Regards, Martin