- IOS-XR MPLS TE Auto Tunnel Backup Bandwidth Protection
- Current Implementation of MPLS TE Auto Tunnel Backup
- Potential issue with current implementation of MPLS TE auto tunnel backup
- Enhancement to MPLS TE auto backup in IOS XR 7.5.1
- Supported Hardware
- Config Example
- Acronyms and definitions for terms used throughout this section:
- Topology
- Base configuration
- Configuring Auto Tunnel Backup Bandwidth Protection
- Soft-preemption
- Node Protection
- MPLS TE Auto Tunnel Backup Bandwidth Protection on transit router
- Config Summary
- Auto Backup Bandwidth Protection and NSR
- Related Show Commands
- Logs to provide to Cisco TAC for MPLS TE Auto Tunnel Backup Bandwidth Protection issues
- Article change log
IOS-XR MPLS TE Auto Tunnel Backup Bandwidth Protection
Current Implementation of MPLS TE Auto Tunnel Backup
In an MPLS-TE network, LSPs can be protected by FRR link protection (a.k.a. "NHop protection") or node protection (a.k.a. "NNHop protection").
This is achieved by creating backup LSP protecting links or nodes that the LSP passes.
The node which redirects the traffic onto the backup LSP is called the Point of Local Repair (PLR), and PLR can be the primary LSP head-end itself, or transit router along the path.
Figure 1: FRR link protection
Figure 2: FRR node protection
When the protected link or node goes down, traffic will switch from the primary LSP to the backup LSP, resulting in a very minimal traffic loss.
Traffic will be forwarded using this backup LSP until the primary LSP can be signaled again using the original path.
When the original path becomes available again, traffic will switch back to primary LSP without any packet loss.
In some cases, a particular primary LSP can be protected by both link protection and node protection.
The current implementation of IOS XR FRR is that node protection is preferred to link protection, meaning when a particular primary LSP can be protected by either node protection or link protection, IOS XR will select node protection for use. When this selection happens, link protection LSP will not be used and will eventually be aged out and removed.
Figure 3: node protection is preferred to link protection
Backup LSP can either be statically created by operator or automatically created by the router.
Both static and auto backup are existing IOS XR functionalities.
When the backup LSP is configured to be automatically created, IOS XR will auto create:
1. One backup LSP for link protection per protected link.
2. One backup LSP for node-protection per protected node.
As it's currently implemented in IOS XR, these auto-tunnels will be signalled with zero RSVP bandwidth.
Potential issue with current implementation of MPLS TE auto tunnel backup
When a link/node down event is taking place, it is possible that many primary LSPs will all fall back to a same backup LSP. When this many primary LSPs are each carrying a significant amount of traffic, this will potentially cause a traffic bottleneck on the back up physical link, affecting many other unrelated traffic streams using that link.
Figure 4: FRR causes a traffic bottleneck on the back up physical link
There is a need to control how much bandwidth can be protected by a particular auto backup LSP in the control plane. If such control exists, then a link/node down event will less likely to saturate a backup link since only certain amount of bandwidth will be consumed by the backup LSP on that link.
Let's refer to this particular need as need #1 "a need to control how much bandwidth can be protected".
Now let's take one step further. Even if such control exists, the auto backup LSP is signalled with 0 RSVP bandwidth. Meaning the auto backup LSP will always be successfully signalled over a particular physical link even if that link's RSVP bandwidth has been heavily used already (say by other unrelated LSPs using that link).
When a link/node down event is taking place, we will still be facing an issue where a traffic bottleneck might occur on the back up physical link.
There is a need for an auto backup LSP to signal a specific bandwidth value instead of just 0 value.
Let's refer to this particular need as need #2 "a need for an auto backup LSP to signal a specific bandwidth".
Finally, when an auto backup LSP becomes capable of signalling a specific bandwidth, then there will now be a need for a network operator to soft-preempt these backups in case the bandwidth they are reserving is needed by a higher priority LSP. Soft-preemption will allow the backups to keep on carrying traffic while the control plane is trying to find other path to create a new backup, instead of the control plane bringing down (hard-preempt) the backups right away.
Let's refer to this particular need as need #3 "a need to soft-preempt auto backups".
Figure 5: auto backup LSPs being soft pre-empted
Enhancement to MPLS TE auto backup in IOS XR 7.5.1
Disclaimer:
7.5.1 might not be a GA (general availablity) release.
Starting with IOS XR 7.5.1, with regards to auto backup LSPs, the following model is introduced:
- Create 1 link-protection auto-tunnel backup per protected-link providing bandwidth protection.
- Create 1 node-protection auto-tunnel backup per protected-node providing bandwidth-protection.
- Use the bandwidth protection backups only to protect LSPs that are requesting bandwidth-protection.
- Limit the amount of protected bandwidth per backup tunnel through configuration.
This is addressing need #1 "a need to control how much bandwidth can be protected" described in the previous section. - If there is no more room to protect LSPs requesting bandwidth protection, then use the regular auto-tunnel backups to provide FRR protection.
- Support signalled-bandwidth configuration under the attribute sets for auto-tunnel backups.
This is addressing need #2 "a need for an auto backup LSP to signal a specific bandwidth" described in the previous section. - Signal the auto-tunnel backups with ZERO bandwidth in case no path is found with the configured bandwidth.
If this happens, keep trying to reoptimize to satisfy the bandwidth requirement. - Support soft-preemption configuration in the auto-tunnel backup attribute set.
This is addressing need #3 "a need to soft-preempt auto backups" described in the previous section.
Note that as a result of the new feature:
- In case of a link needing protection,
Two link protection auto backup LSPs will be brought up:
one to provide link-protection with bandwidth protection, and one to provide link-protection without bandwidth protection. - Likewise, in case of a node needing protection,
Two node protection auto backup LSPs will be brought up:
one to provide node-protection with bandwidth protection, and one to provide node-protection without bandwidth protection.
Three new CLI configuration is introduced as part of this feature:
- Limit the amount of protected bandwidth per backup tunnel.
- Signalled-bandwidth configuration under the attribute sets for auto-tunnel backups.
- Soft-preemption configuration in the auto-tunnel backup attribute set.
Please refer to section "Config Summary" for sample CLI configuration.
Users can pick and choose which configuration they want to use.
I.e. there is no requirement to have all three new CLI configuration active at the same time.
For instance, users can limit the amount of protected bandwidth per backup tunnel without having the backup tunnel to signal any specific bandwidth value.
Or maybe a user configures protected bandwidth limit with bandwidth signaling, but without configuring soft-preemption.
Please refer to "Config Example" section for more CLI config details along with relevant show command output.
Supported Hardware
"MPLS TE auto backup Bandwidth Protection" is an IOS-XR platform independent feature.
As such you can configure this feature on IOS-XR platforms such as ASR9000, NCS5500, and so on, as long as it runs IOS XR 7.5.1 or above.
Config Example
Acronyms and definitions for terms used throughout this section:
- NHOP+BW : Link protection backup auto tunnel that is bandwidth protected
- NHOP-BW : Link protection backup auto tunnel that is NOT bandwidth protected
- NNHOP+BW : Node protection backup auto tunnel that is bandwidth protected
- NNHOP-BW : Node protection backup auto tunnel that is NOT bandwidth protected
- PT+BW : Primary tunnel that is requesting for FRR bandwidth protection
- PT-BW : Primary tunnel that is NOT requesting for FRR bandwidth protection
"Tunnel" and "LSP" refers to same thing and are being used interchangeably.
Topology
Figure 6
Base configuration
IGP is ISIS, RSVP and mpls traffic-eng are configured in all relevant interfaces.
We have two primary LSPs:
- tunnel-te1 which is a PT+BW.
- tunnel-te2 which is a PT-BW.
LSP head end is on R1, tail end is on R2.
Both LSPs are using path S1-S2-S3.
Relevant config on R1-ichitaka:
|
ipv4 unnumbered mpls traffic-eng Loopback0 interface tunnel-te1 interface tunnel-te2 |
All primary LSPs are up:
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
Each primary LSP is consuming 1G of RSVP bandwidth along the path:
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh rsvp interface *: RDM: Default I/F B/W % : 75% [default] (max resv/bc0), 0% [default] (bc1) Interface MaxBW (bps) MaxFlow (bps) Allocated (bps) MaxSub (bps) |
Note that both primary LSPs are using same segment HundredGigE0/1/0/0.1 (S1 in figure 7).
We will create link protection over this sub-interface later.
Now let's create the auto backup with no bandwidth protection, which is an existing feature.
Let's do link protection for segment S1.
| mpls traffic-eng interface HundredGigE0/1/0/0.1 auto-tunnel backup ! ! |
NHOP-BW tunnel-te65005 becomes active.
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
Tunnel-te65005 head end is R1, and tail-end is R9. It's protecting segment S1 by taking backup path S4.
Moreover, it is signalled with 0 bandwidth, as per existing feature.
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65005 Name: tunnel-te65005 Destination: 200.1.1.9 Ifhandle:0x20ab0a0 (auto-tunnel backup) path option (autob_nhop_te65005), preference 20, type explicit (autob_nhop_te65005) (Basis for Setup, path weight 10) Path info (IS-IS main level-1): |
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng auto-tunnel backup summary AutoTunnel Backup Summary: Cumulative Counters (last cleared 2d23h ago): |
From the above output, it looks like the router keeps on trying to create NNHOP-BW too (15x NNHOP creation/removal), this will keep on failing due to topology constraint.
We can configure the router to create auto backup for link protection only:
| mpls traffic-eng interface HundredGigE0/1/0/0.1 auto-tunnel backup nhop-only ! ! ! |
Configuring Auto Tunnel Backup Bandwidth Protection
So far so good, now let's configure our new feature.
Let's configure 5G as maximum bandwidth that can be protected by the auto backup LSP.
We will configure the auto backup LSP to signal 5G as well during LSP bring up.
Note:
Users are free to configure different value for maximum bandwidth and signalled bandwidth.
These values do not need to be the same.
Examples in this article are using same value for maximum bandwidth and signalled bandwidth to prefent confusion.
| mpls traffic-eng interface HundredGigE0/1/0/0.1 auto-tunnel backup nhop-only attribute-set auto_bkup_5000M bandwidth-protection maximum-aggregate 5000000 <--- new feature, auto backup LSP to protect only up to a specific aggregate bandwidth. ! ! attribute-set auto-backup auto_bkup_5000M signalled-bandwidth 5000000 class-type 0 <--- new feature, auto backup LSP to signal specific bandwidth during LSP bring up. ! ! |
now we see additional auto backup tunnel being created.
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
Here is a show output for existing NHOP-BW tunnel-te65005:
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65005 Name: tunnel-te65005 Destination: 200.1.1.9 Ifhandle:0x20ab6a0 (auto-tunnel backup) path option (autob_nhop_te65005), preference 20, type explicit (autob_nhop_te65005) (Basis for Setup, path weight 10) |
Note that now this tunnel is signalled with 5G bandwidth, previously it was signalled with 0 bandwidth.
This is because the new config "signalled-bandwidth <>" is applied to every auto backup under segment HundredGigE0/1/0/0.1 (S1 in figure 6).
And as for the newly created NHOP+BW tunnel-te65006:
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65006 Name: tunnel-te65006 Destination: 200.1.1.9 Ifhandle:0x20ab6e0 (auto-tunnel backup) path option (autob_nhop_te65004), preference 20, type explicit (autob_nhop_te65004) (Basis for Setup, path weight 10) Path info (IS-IS main level-1): Displayed 1 (of 4) heads, 0 (of 0) midpoints, 0 (of 0) tails |
Several things to note from above output (see the output that is marked bold):
1. This tunnel is signalled with 5G bandwidth
2. This tunnel is a link protection LSP with bandwidth protection ("NHOP+BW").
3. It's using same path as existing NHOP-BW tunnel-te65005.
Let's see what the protection looks like.
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels backup auto-tunnel tunnel-te65005 (auto-tunnel backup) <--- NHOP-BW |
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng auto-tunnel backup AutoTunnel Backup Summary: Cumulative Counters (last cleared 3d01h ago):
|
How about if there is no more room to protect LSPs requesting bandwidth protection? Then we will use the regular auto-tunnel backups to provide FRR protection.
Let's see this in action.
At this moment NHOP+BW tunnel-te65006 is protecting up to 5G of bandwidth.
PT+BW tunnel-te1 is consuming 1G out of that 5G already, leaving 4G remaining for other PT+BW.
Now what happens if there's a new PT+BW coming up requesting bandwidth protection of 5G?
Now let's check the outcome.
| interface tunnel-te666 ipv4 unnumbered Loopback0 ipv6 enable signalled-bandwidth 5000000 destination 200.1.1.2 fast-reroute protect bandwidth path-option 10 explicit name R1_vlan1_R9_R6_R2 ! |
Newly added PT+BW tunnel-te666 is up, but note that it's being backed up by NHOP-BW tunnel-te65005.
This is because NHOP+BW tunnel-te65006 can't support additional 5G protected bandwidth.
| RP/0/RSP0/CPU0:Jul 1 17:05:43.884 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-FRR_STATE : tunnel-te666 (signalled-name: R1-Ichitaka-ASR9904_t666, LSP Id: 2, Dest: 200.1.1.2) FRR state changed to FRR-Ready, backup tunnel (tunnel-te65005, LSP Id: 2), protection type (link). RP/0/RSP0/CPU0:Jul 1 17:05:43.885 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-S2L_SIGNALLING_STATE : tunnel-te666 (signalled-name: R1-Ichitaka-ASR9904_t666,T:666, LSP id: 2, Role: Current, src: 200.1.1.1, dest: 200.1.1.2): signalling state changed to Up |
|
RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng auto-tunnel backup AutoTunnel Backup Summary: Cumulative Counters (last cleared 00:14:13 ago):
|
Now let's step back and see the case where auto-tunnel backups finds no path that can satisfy the configured signalled bandwidth.
| mpls traffic-eng interface HundredGigE0/1/0/0.1 auto-tunnel backup nhop-only no attribute-set auto_bkup_5000M attribute-set auto_bkup_10000M ! ! attribute-set auto-backup auto_bkup_10000M signalled-bandwidth 10000000 class-type 0 <--- now asking for 10G instead of 5G ! ! |
We see that the router signals 0 value as bandwidth in order to keep the auto backup operational, afterwhich it will keep on trying to reoptimize to satisfy the bandwidth requirement:
| RP/0/RSP0/CPU0:Jul 1 21:20:13.603 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_BW_CHANGE : Bandwidth change on tunnel-te65006 (signalled-name: autob_R1-Ichitaka-ASR9904_t65006_Hu0_1_0_0.1, LSP id: 3): new bandwidth 0 kbps RP/0/RSP0/CPU0:Jul 1 21:20:13.603 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_REOPT : tunnel-te65006 (signalled-name: autob_R1-Ichitaka-ASR9904_t65000_Hu0_1_0_0.1, old LSP Id: 2, new LSP Id: 3) has been reoptimized; reason: Bandwidth CLI Change. RP/0/RSP0/CPU0:Jul 1 21:20:13.604 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_BW_CHANGE : Bandwidth change on tunnel-te65005 (signalled-name: autob_R1-Ichitaka-ASR9904_t65005_Hu0_1_0_0.1, LSP id: 3): new bandwidth 0 kbps RP/0/RSP0/CPU0:Jul 1 21:20:13.604 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_REOPT : tunnel-te65005 (signalled-name: autob_R1-Ichitaka-ASR9904_t65005_Hu0_1_0_0.1, old LSP Id: 2, new LSP Id: 3) has been reoptimized; reason: Bandwidth CLI Change. |
| RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65006 | i Bandwidth Req Bandwidth Requested: 0 kbps CT0 RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65005 | i Bandwidth Req Bandwidth Requested: 0 kbps CT0 |
Soft-preemption
Soft-preemption configuration in the auto-tunnel backup attribute set is now supported.
Since auto backups now reserve bandwidth, it is important to be able to soft-preempt these backups in case the bandwidth they are reserving is needed by a higher priority tunnel.
We configure soft-preemption through the following config.
| mpls traffic-eng interface HundredGigE0/1/0/0.1 auto-tunnel backup attribute-set auto_bkup_5000M ... ! ! attribute-set auto-backup auto_bkup_5000M soft-preemption <--- configure soft-preemption for auto-tunnel (newly supported config in this release) ... ! soft-preemption <--- configure soft-preemption for general traffic engineering (existing feature) ! ! |
After configuring the above, we see that soft-preemption is now enabled on both NHOP+BW and NHOP-BW.
| RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65005 | i empt Soft Preemption: Enabled, Current Status: Preemption not pending RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65006 | i empt Soft Preemption: Enabled, Current Status: Preemption not pending |
Now let's try to preempt our existing auto backups by bringing up a new LSP.
| interface tunnel-te777 ipv4 unnumbered Loopback0 ipv6 enable signalled-bandwidth 10000000 destination 200.1.1.9 path-option 10 explicit name R1_vlan2_R9 priority 3 3 soft-preemption <--- This config will make head-end router to indicate to all the intermediate nodes that existing LSP is to be softly preempted when needed ! |
| RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_SOFT_PREEMPT : Tunnel 65005 (autob_R1-Ichitaka-ASR9904_t65005_Hu0_1_0_0.1, LSP Id: 6) has been soft preempted at interface Hu0/1/0/0.2 (100.6.0.1), timeout after 60 seconds. RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-S2L_SIG_ERR : Signalled error received on tunnel-te65005 (signalled-name: autob_R1-Ichitaka-ASR9904_t65005_Hu0_1_0_0.1, Dest: 200.1.1.9, LSP: 6): SigErr(34,1)-(Error: reroute (34), Suberror: flow soft-preempted (1)) at 100.6.0.1 RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_SOFT_PREEMPTED : Tunnel 65005 (autob_R1-Ichitaka-ASR9904_t65005_Hu0_1_0_0.1, LSP Id: 6) has been soft preempted at 100.6.0.1 RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_SOFT_PREEMPT : Tunnel 65006 (autob_R1-Ichitaka-ASR9904_t65006_Hu0_1_0_0.1, LSP Id: 6) has been soft preempted at interface Hu0/1/0/0.2 (100.6.0.1), timeout after 60 seconds. RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-S2L_SIG_ERR : Signalled error received on tunnel-te65006 (signalled-name: autob_R1-Ichitaka-ASR9904_t65006_Hu0_1_0_0.1, Dest: 200.1.1.9, LSP: 6): SigErr(34,1)-(Error: reroute (34), Suberror: flow soft-preempted (1)) at 100.6.0.1 RP/0/RSP0/CPU0:Jul 2 14:55:44.896 GMT+7: te_control[1085]: %ROUTING-MPLS_TE-5-LSP_SOFT_PREEMPTED : Tunnel 65006 (autob_R1-Ichitaka-ASR9904_t65006_Hu0_1_0_0.1, LSP Id: 6) has been soft preempted at 100.6.0.1 |
The pre-empted auto backup later will re-signal with 0 bandwidth since it can't find any alternative link to use.
| RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65005 | i Bandwidth Req Bandwidth Requested: 0 kbps CT0 RP/0/RSP0/CPU0:R1-Ichitaka-ASR9904#sh mpls traffic-eng tunnels 65006 | i Bandwidth Req Bandwidth Requested: 0 kbps CT0 |
In the absence of soft-preemption, the auto backups will be torn down right away (i.e. hard preempted) as tunnel-te777 comes up.
Node Protection
So far we have described about how an auto-tunnel backup can provide link protection with bandwidth protection, now let's see how it can provide node protection as well.
Back to our diagram in Figure 6, we can create new PT+BW LSP with head end R2 and tail end R1, with path S3-S2-S1.
Then we will have R2 to create an auto-tunnel backup on S5 that provide node protection for R6.
Base configuration on R2:
|
explicit-path name R2_R6_R9_R1 interface tunnel-te101 |
tunnels are up:
|
RP/0/RP0/CPU0:R2-Aiko-NCS5502SE#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
Now let's create the auto tunnel backup.
We're aiming to node protect R6 so we need to configure auto-tunnel backup on the interface facing R6, which is S3 Fo0/0/0/40.1.
| mpls traffic-eng interface Fo0/0/0/40.1 auto-tunnel backup attribute-set auto_bkup_5000M bandwidth-protection maximum-aggregate 5000000 ! ! attribute-set auto-backup auto_bkup_5000M signalled-bandwidth 5000000 class-type 0 ! ! |
The auto-tunnel backup are now created:
|
RP/0/RP0/CPU0:R2-Aiko-NCS5502SE#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
Note from the output above that we're creating 4 auto-tunnel backup in one shot:
- tunnel-te65000 which is an NNHOP+BW.
This is the one that we want to have. - tunnel-te65001 which is an NNHOP-BW.
This is unused since we don't have PT-BW to protect. - tunnel-te65002 which is an NHOP+BW.
This is down and unused since we don't have alternate link between R2_R6 for link protection. - tunnel-te65003 which is an NHOP-BW.
This is down and unused since we don't have alternate link between R2_R6 for link protection.
|
RP/0/RP0/CPU0:R2-Aiko-NCS5502SE#sh mpls traffic-eng auto-tunnel backup AutoTunnel Backup Summary: Cumulative Counters (last cleared 4d03h ago):
|
The unused tunnels will eventually age out and removed:
|
RP/0/RP0/CPU0:R2-Aiko-NCS5502SE#sh mpls traffic-eng tunnels tabular Tunnel LSP Destination Source Tun FRR LSP Path |
|
RP/0/RP0/CPU0:R2-Aiko-NCS5502SE#sh mpls traffic-eng auto-tunnel backup AutoTunnel Backup Summary: Cumulative Counters (last cleared 4d03h ago):
|
MPLS TE Auto Tunnel Backup Bandwidth Protection on transit router
Config example given so far is when you configure the feature on head-end router.
The feature can also be configured on transit router.
For example, in Figure 6 with PT+BW having head end router of R1 and path of S1_S2_S3, R9 is a transit router where we can configure the feature as well.
On R9, we can protect the PT+BW by doing node protection for R6, by creating auto tunnel backup on alternate path S5.
When R6 goes down, R9 can switch the traffic from original path S2_S3 to S5.
Configuration is the same as when we configure on head-end router:
config "bandwidth-protection maximum-aggregate" on interface S2 and so on.
Config Summary
The following is a sample of configuration needed to activate Auto Backup Bandwidth Protection feature.
The line that is marked bold is new supported CLI config introduced with the feature.
|
ipv4 unnumbered mpls traffic-eng Loopback0 ! explicit-path name R1_vlan1_R9_R6_R2 interface Loopback0 router isis main |
Auto Backup Bandwidth Protection and NSR
NSR RP switchover is hitless for both MPLS TE control and data plane, provided all underlay protocol (BGP, ISIS, OSPF, etc) has been configured for NSR.
Related Show Commands
show mpls traffic-eng auto-tunnel backup
show mpls traffic-eng tunnels tabular
show mpls traffic-eng tunnels summary
show rsvp interface
Logs to provide to Cisco TAC for MPLS TE Auto Tunnel Backup Bandwidth Protection issues
Gather the following set of logs from the router.
Replace "NAME_OF_ROUTER"with the name of your router.
Logs/info to grab:
- Timestamp when the problem occurs (e.g. Jul 2 10:55:47.015 GMT+7), the more exact, the better.
It's best if the timestamp can be copied from a specific line of "show log" output. - show tech mpls traffic-eng file harddisk:/NAME_OF_ROUTER_sh_tech_mpls_traffic_eng
- show log | file harddisk:/NAME_OF_ROUTER_show_log.txt
(showing the events when the problem occurs)
Article change log
2021/06/03: First post of this article.
2021/06/07: Putting a note in "Configuring Auto Tunnel Backup Bandwidth Protection" section that maximum bandwidth and signalled bandwidth don't need to be same value.