MPLS TE/FRR on ME 3600X

Hi,
Can ME 3600X provides 50-ms rerouting time upon link failure with MPLS TE/FRR?
There are many failure detection mechanisms cause the routers to switch LSPs onto their backup tunnels:
1.Interface Down Notification
(When a router’s link or neighboring node fails, the router often detects this failure by an interface down notification.
On a Packet over SONET (POS) interface, this notification is very fast.)
2.Loss of Signal
(Unlike POS interfaces, Gigabit Ethernet does not have any alarms to detect link failures. If a link is down
due to a cut cable or because the remote end shuts its laser, the optics module (GBIC or SFPs) on the
Gigabit Ethernet card detects a loss of signal (LOS). The LOS is used as a mechanism to detect the
failure and begin the switchover.)
3.Notification from the RSVP hello that a neighbor is lost
4.Notification from the Bidirectional Forwarding Detection (BFD) protocol that a neighbor is lost
5.Notification from the Interior Gateway Protocol (IGP) that the adjacency is down
6.For point-to-point link, PPP or HDLC keepalives
I know the 1st and 6th failure detection mechanism can't be applied with ME 3600X. Which failure detection mechanisms
cause ME 3600X to switch LSPs onto their backup tunnels to achieve 50-ms rerouting time upon link failure with MPLS TE/FRR?
My customer want to implement Ring Topology with ME 3600X to provide MPLS L2/L3 VPN services with MPLS TE/FRR.
What is the best pracetice design for Ring Topology with MPLS TE/FRR to provide link protection?
Regards,
Pipatpong

Hello Pipatpong
Below are the answers to your questions:
2. Should be able to detect and cutover.
3. Should be able to detect based on timer configuration. However the recommended value for RSVP hellos is 200 msec
From the config guide :
(http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/12.2_52_ey/configuration/guide/swmpls.html#wp1183359)
To prevent false detection of a down neighbor and unnecessarily triggering fast reroute, we recommend configuring a minimum frequency of 200 ms.
4. BFD support not yet available
5.Dont think IGP will be able to do 50ms on any platform.

Similar Messages

Link Bundle - MPLS TE & FRR Support

Hi Sir,
Platform Cisco 12406 PRP, current running IOS 12.0(32)SY3.
May I know what is latest IOS that can support MPLS TE & FRR over link bundle (L3 Etherchannel) ?
Regards

Hi,
12.0(33)S is the last IOS version for GSR and doesn't support this feature. New development focus on XR only and only few of them like 4B ASN are ported to 33S.
Laurent.

MPLS TE FRR IOS support

Dear Sir!
Can you tell, is there some technology IOS for 36xx/37xx
to test MPLS TE FRR in our lab
(not in real network)?
Because we haven't 720x/7600 etc. in our lab.
Best regards,
Max

Hi Max,
In my opinion, MPLS FRR is not supported in 36xx/37xx.
Thanks,
Vikas

MPLS TE FRR IOS for 7200 platform

Hi,
I could not find in the feature navigation for 7200 platform that have mpls te frr. Does the services support on these platform?
thanks in advance.
maher

Yes, look for S train, and consider your NPE series.
Pls rate helpful posts
Best Regards,
Mounir Mohamed

MPLS-TE FRR NNHOP protection (positioning of the NNHOP node)

Hi All,
I have a conception question about MPLS-TE FRR NNHOP protection. Does the NNHOP need to be along the path of the originally protected TE LSP but just downstream of the protected node?
David

Hi David,
Yes thats Correct. The Next Hop in a FRR TE LSP needs to be a long the path of the Protected TE LSP from the Headend Label Switch router to the Tailend LSR of the TE LSP.
You would normally have more than one Path OR a TE tunnel between the Headend and Tailend LSRs with FRR enabled. The Priority assigned to those tunnels selects the Primary Tunnel. and with FRR feature, if the first tunnel experience failure along the path with ANY of the intermediate next hops to the Tailend LSR of that LSP, the Secondary TE tunnel takes place with faster convergence time.
Regards,
Mohamed

How to preempt MPLS TE FRR

Hi,
I have an Explicit Path configured on a tunnel as 1 and a dynamic path as 2.
If a link fails in the core FRR fails over, then after a while the tunnel takes teh dynamic path. However when the link recovers the tunnel stays on the dynamic path.
My question is: how can i force to take the explicit path again?
R1#show mpls traffic-eng tunnels tunnel 1
Name: R1_t1 (Tunnel1) Destination: 2.2.2.2
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 2, type dynamic (Basis for Setup, path weight 3)
path option 1, type explicit 1
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 [0] bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 2 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : FastEthernet0/1, 28
Next Hop : 10.15.0.5
RSVP Signalling Info:
Src 1.1.1.1, Dst 2.2.2.2, Tun_Id 1, Tun_Instance 32
RSVP Path Info:
My Address: 10.15.0.1
Explicit Route: 10.15.0.5 10.56.0.5 10.56.0.6 10.26.0.6
10.26.0.2 2.2.2.2
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: 5.5.5.5(28) 6.6.6.6(33)
2.2.2.2(3)
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 3 (TE)
Explicit Route: 10.15.0.1 10.15.0.5 10.56.0.5 10.56.0.6
10.26.0.6 10.26.0.2 2.2.2.2
History:
Tunnel:
Time since created: 1 hours, 48 minutes
Time since path change: 55 seconds
Number of LSP IDs (Tun_Instances) used: 32
Current LSP: [ID: 32]
Uptime: 58 seconds
Selection: reoptimization
Prior LSP: [ID: 30]
ID: path option 1 [30]
Removal Trigger: re-route path error
Last Error: RSVP:: Path Error from 10.13.0.3: Notify: Tunnel locally repaired (flags 0)
Thx!

Hi,
By default, the re-optimization is around 1 hour. You can use the below command to speed up the re-optimization,
mpls traffic-eng reoptimize timers frequence <seconds>
With this command, the router after the seconds mentioned will check for better path for existing LSP (to see if primary path option is available) and use it if available.
-Nagendra

MPLS TE FRR & some BFD

Hi,
I have a few questions:
1. If you have TE tunnel with FRR configured for it, what will trigger the switchover to backup tunnel?
In my mind:
a. Link Protocol down on the interface
b. RSVP signalling
Now two other problematic ones are:
c. IGP neighbor down over a protected link (will it trigger TE reroute WITHOUT using FRR, so IGP neighbors and FRR would be two completely different approaches?)
d. BFD. Is it activated on a specific protected link or on the LSP headend (tailend) to "test" the end-to-end LSP? It is mentioned in BFD docs that when used with TE FRR it can report tunnel down BEFORE the tunnel having sufficient time to be rerouted (because BFD would be acting so fast). Does this mean BFD allows end-to-end LSP testing?
2. More about BFD. The docs say that BFD itself just reports to the protocol employing its services (like IGPs and maybe TE) that the connectivity betweem two points BFD is responsible for is down. If BFD is configured over an interface, does this mean that when BFD senses lack of reachability but Link Protocol stays up (like Ethernet), will it actually bring down the Link Protocol on that particular interface?
If not, it is unclear why would docs also say that BFD is best deployed with Interface Dampening. Interface dampening would work in case Link Protocol flaps...
Thanks!
David

Hi David,
Pls see my what i feel inline...
a. Link Protocol down on the interface
b. RSVP signalling
1(a,b)
Here again RSVP hellos are used as a trigger to achieve the FRR rather than relying on the line protocol to go down.
Which provides us fast upto 50msec protection.
Afaik TE FRR can utilize BFD as its relatively less resource intensive than generating RSVP hellos.
c. IGP neighbor down over a protected link (will it trigger TE reroute WITHOUT using FRR, so IGP neighbors and FRR would be two completely different approaches?)
1(c)
Without using FRR the TE reroute would be pure Tunnel Reoptimization based on your IGP convergence towards your Tunnel TailEnd.
d. BFD. Is it activated on a specific protected link or on the LSP headend (tailend) to "test" the end-to-end LSP? It is mentioned in BFD docs that when used with TE FRR it can report tunnel down BEFORE the tunnel having sufficient time to be rerouted (because BFD would be acting so fast). Does this mean BFD allows end-to-end LSP testing?
1(d)
"BFD can help test end-to-end data plane only just like LSP ping, but there is currently no integration of the results and mapping of the same to control plane in MPLS. hence BFD with LSP ping is being preached. More details can be found at http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-03.txt."
2. More about BFD. The docs say that BFD itself just reports to the protocol employing its services (like IGPs and maybe TE) that the connectivity betweem two points BFD is responsible for is down. If BFD is configured over an interface, does this mean that when BFD senses lack of reachability but Link Protocol stays up (like Ethernet), will it actually bring down the Link Protocol on that particular interface?
If not, it is unclear why would docs also say that BFD is best deployed with Interface Dampening. Interface dampening would work in case Link Protocol flaps...
2.
No BFD would not involve itself into getting the link down, it will only enable the protocol bootstrapping or using it to declare a failure.
Now assume if the link is bouncing up and down, or there are intermittent losses because of link intergity. Then BFD would keep sending up down messages to the protocol employing it. Hence if the integration is with Dampening, then such UP or DOWN messages can be considered as flaps in the configured interval and the interface can be dampened. The Dampening as a process would utilize BFD triggers for calculating flaps rather than the Line protocol based UP or DOWN triggers. Thus enabling us to achieve the upto 50ms recovery time which is generally provided by POS/SONET with APS.
HTH-Cheers,
Swaroop

MPLS LDP FRR

HI all,
I'm aware that you can enable MPLS FRR with RSVP. But how do you achieve FRR capabilities with LDP ??
Many Thanks

Hi Per,
From RFC 4090 (Fast Reroute Extensions to RSVP-TE for LSP Tunnels):
"A protected LSP is an explicitly-routed LSP that is provided with protection. The repair methods described here are applicable only to explicitly-routed LSPs. Application of these methods to LSPs that dynamically change their routes, such as LSPs used in unicast IGP routing, is beyond the scope of this document."
So currently there is no standard covering the required functionality. Imho the underlying reason is avoidance of routing loops. As TE tunnels have fixed starting and endpoints, you might reroute them in any way without creating loops, if preventing loops for the backup tunnel. When it comes to IGP based LSPs the problems are not that easy to solve. Example: R1-R2-R3 Assume the link from R2 to R3 is protected by a tunnel from R2 to R1 ... In IGP based LSPs a routing loop will be created and is hard to detect/avoid.
In case you have a feature request for your customer, drop me an email and we can discuss things offline.
Regards, Martin

At which interfaces MPLS TE FRR supported?

Dear Sir!
In my last thread "Problem with FRR" I cannot to make FRR begin working.
So can you tell me (I cannot find it at www.cisco.com) at which interfaces are FRR supported?
Because in "Problem with FRR"
PE1 - 7204VXR with 12.0(29)S installed,
P1 - 7206VXR with 12.0(29)S installed, and use
Gi-interface to P2,
P2 - 3662 with 12.3.4(T) installed and use
Fa-interface to P1
Is it true, that FRR supports only on PoS interfaces?
Hope you help,
Maxim Denisov

FRR is supported on GigE interface. The issue is usually with failure detection. You need
to use RSVP Hellos or tune down the IGP hellos to ensure you quickly detect the link failure. Once you detect the failure, everything else works well.
Hope this helps,

Labels iin MPLS TE environment

I am trying to simulate a MPLS TE FRR with GNS3 and everything seems to work fine. However every time i simulate a failover, the labels seems to change
Is it something expected or a problem with the simualtion engine
When FRR is not active
R1-PE1#traceroute vrf abc 200.200.200.1
*Jan 28 20:32:21.735: %SYS-5-CONFIG_I: Configured from console by console
Type escape sequence to abort.
Tracing the route to 200.200.200.1
1 20.20.20.2 [MPLS: Labels 209/405/607 Exp 0] 560 msec 308 msec 360 msec
2 10.10.10.2 [MPLS: Labels 310/405/607 Exp 0] 268 msec 540 msec 204 msec
3 10.10.10.6 [MPLS: Labels 405/607 Exp 0] 312 msec 312 msec 392 msec
4 200.200.200.1 484 msec * 236 msec
R1-PE1#
When FRR is active
R1-PE1#traceroute vrf abc 200.200.200.1
Type escape sequence to abort.
Tracing the route to 200.200.200.1
1 20.20.20.2 [MPLS: Labels 209/405/607 Exp 0] 420 msec 1124 msec 712 msec
2 30.30.30.2 [MPLS: Labels 510/405/607 Exp 0] 516 msec 480 msec 408 msec
3 30.30.30.10 [MPLS: Labels 405/607 Exp 0] 328 msec 328 msec 220 msec
4 200.200.200.1 648 msec * 500 msec
R1-PE1#
When i bring up my interface again
R1-PE1#traceroute vrf abc 200.200.200.1
Type escape sequence to abort.
Tracing the route to 200.200.200.1
1 20.20.20.2 [MPLS: Labels 209/405/607 Exp 0] 372 msec 324 msec 248 msec
2 10.10.10.2 [MPLS: Labels 312/405/607 Exp 0] 256 msec 772 msec 736 msec .... i see lable 312 instead of 310 ??
3 10.10.10.6 [MPLS: Labels 405/607 Exp 0] 420 msec 328 msec 344 msec
4 200.200.200.1 312 msec * 264 msec
R1-PE1#
i have attached the configs
Ambi

Ambi,
Have you tried the protection setting for LDP/TDP?
This is possible with "mpls ldp session protection" command. I do not know if we have this command to TDP.
Sds,

MPLS TE - Record-route

Hi,
Can you tell me what is the purpose of the "tunnel mpls traffic-eng record-route".
Just for information (to have the record route in any show command) or mandatory for a particular configuration?
Thx.

Guillaume,
This command is used to force the inclusion of additional information in the route record object of the RESV message. This information is only required for MPLS TE FRR (Node Protection). This command is enabled automatically when FRR is requested on the tunnel interface using the "tunnel mpls traffic-end fast-reroute" command.
Regards

MPLS TE Fast ReRoute

Hi Experts,
I'm just getting started with MPLS TE and wondering on how fast the "fast reroute" feature can be.
I'm planning to create two tunnels for a specific traffic of my network, and looks like MPLS TE with FRR is the most reliable option if we are talking about a really 0% packet loss network.
I saw on some documentations that with MPLS TE is possible to reroute the traffic with 50 ms of RTT and no packet loss at all, considering that the backup tunnel is so reliable as the primary is.
Is this true? I'm new on this subject so I would like to know more about what I could achieve in terms of high availability.
Regards
Paulo Varanda

Hi,
Yes MPLS-TE with FRR gives faster convergence in range of 50ms (usually 50ms is standard convergence time for SDH/Sonet network). But there are some pre-requisities for MPLS-TE FRR to provide that faster convergence.
Tunnel Headend -- Router 1 --- Router 2 ---- Router 3--- Tunnel Tailend
-- Router 4 ---- Router 5----
MPLS-TE FRR protects a particular link or a particular node.
For link protection, the concept is to have a primary tunnel protected by a backup tunnel. The backup tunnel path should be on completely different and fault tolerant physical path when the primary tunnel path fails i.e. both the tunnels should not be in same SRLG links. In the above case if link between Router1-Router2-Router3 fails the tunnel should fallback over Router 4 and Router 5.
Detecting the link or node goes down should require a keepalive mechanism, usually RSVP hellos are used to detect the failure.
Node protection by default provides link protection. So when Router 2 goes down the traffic falls back over backup path.
MPLS-TE FRR wokrs by pre-signalling LSP over both primary and secondary paths even before the failure occurs. In normal conditions (with multiple path-option), only when primary LSP on primary path goes down, LSP gets signalled over secondary path option.
HTH
Arun

MPLS TE + IGP,BGP Convergence timers

Hi,
In case I am implementing MPLS TE FRR using RSVP hellos in my mpls backbone for speedy convergence against link/node failures. Do I still need to teak my IGP,BGP & LDP convergence timers or make my IGP,BGP,LDP to converge based on trigger from BFD in addition to implementation of MPLS TE FRR.

Hi,
Tuning IGP and BGP will help to improve convergence in other scenarios:
- Lost of a primary PE-CE link
- Lost of a primary PE
- Lost of a core link not protected by MPLS TE FRR.
FRR allows you to have a very fast data-plane convergence without waiting for your control-plane converge.
There is no need to tune LDP timers because by default the router is in liberal label retention mode meaning it stores the labels even if the LSR is not the IGP next-hop.
HTH
Laurent.

IOS XR Interface up/down trap

For interface up/down trap
In IOS it used to be:
Generic: 2; Specific: 0; Enterprise: .1.3.6.1.6.3.1.1.5;
Variables:
[1] mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex.34 (Integer): 34
[2] mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr.34 (OctetString): POS2/1/0
[3] mgmt.mib-2.interfaces.ifTable.ifEntry.ifType.34 (Integer): 171[4] private.enterprises.cisco.local.linterfaces.lifTable.lifEntry.locIfReason.34 (OctetString): Keepalive failed
Annotations:
In IOS XR we are missing ifDescr

Thanks Joe.
This solves the problem.
One more question. we do not see LDP traps coming from the XR router.
here is the config; when i enable LDP traps it just does not show up in the config:
snmp-server host 10.10.141.253 traps ovadmin
snmp-server view N ip included
snmp-server view N system included
snmp-server view N cpwVcMIB included
snmp-server view N entityMIB included
snmp-server view N interfaces included
snmp-server view N cpwVcMplsMIB included
snmp-server view N mplsTeStdMIB included
snmp-server view N ciscoCBQosMIB included
snmp-server view N ciscoPingEntry included
snmp-server view N ciscoProcessMIB included
snmp-server view N ciscoMemoryPoolEntry included
snmp-server view N ciscoEnhancedMemPoolMIB included
snmp-server community admin RO
snmp-server community admirw RW
snmp-server traps snmp
snmp-server traps config
snmp-server traps entity
snmp-server location Y
snmp-server trap-source MgmtEth0/8/CPU0/0
Tried to enable it:
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ?
frr          Enable MPLS FRR traps
l3vpn        Enable MPLS L3VPN traps
ldp          Enable MPLS LDP traps
traffic-eng Enable MPLS TE traps
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ldp ?
down       Enable MPLS LDP session down traps
threshold Enable MPLS LDP threshold traps
up         Enable MPLS LDP session up traps
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ldp ?
down       Enable MPLS LDP session down traps
threshold Enable MPLS LDP threshold traps
up         Enable MPLS LDP session up traps
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ldp down ?
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ldp down
RP/0/8/CPU0:P1(config)#snmp-server traps mpls ldp up
RP/0/8/CPU0:P1(config)#commit
RP/0/8/CPU0:P1(config)#end
does not show up in the config.

MPLS FRR

Hello:
I use IOS code 7200 Software (C7200-SPSERVICESK9-M), Version 12.2(33)SRC3
at default MPLS FRR works fine
when I shutdown pos interface on primary path, FRR works fine, but after I bring back pos interface, I noticed tu1 still use backup path
until I shut and no shut tu1
anyone could shred a light?
thx,
~mike

Hi Mike,
Instead of dynamic path option, configure an explicit path with "192.168.3.1" as strict hop and try the scenario.
In this case, when pos interface on primary path goes down the traffic will be rerouted via backup tunnel and the primary path will be retried for every 30 seconds. When the interface is back up, primary path signaling will succeed and tunnel will no longer use the backup path.
When tunnel uses the backup tunnel, "show mpls traffic-eng fast database" will display it's status as "active".
With dynamic path option, the tunnel will calculate a path which will be same as the backup tunnel path and it'll look like it's using the backup tunnel. To use the best path you've to trigger reoptimization (manual/periodic/event-linkUp).
Thanks,
Vijay

MPLS TE/FRR on ME 3600X

Similar Messages

Maybe you are looking for