Hello folks,
In continuation of my previous blog on MPLS TE configuration, I have setup fast-reroute for MPLS TE tunnel so that if a designated primary link fails then the tunnel will take up the alternate path and the traffic loss will be avoided. Please check my previous blog for basic MPLS TE config in this network.
MPLS TE Configuration : GNS3 LAB Cisco : Quick Configuration MPLS TE (traffic engineering).
If you have seen the above post then it will be easy for you to understand the overall setup and configs. Let’s get started with the FRR part. In the below network I have TE(Traffic Engineering) tunnel setup between PE1 and PE3. On PE1 I have setup the explicit path for the tunnel which is taking the link gi4/0-gi1/0 between P1 – P3(check network diag for details). From P1 we have an alternate path to PE3 over P2 as well. Hence, I will be using this alternate path to setup the FRR tunnel so that if the link between P1 and P3 fails then we still have a path to the TE tunnel endpoint and data loss can be avoided. Now let’s see this in action with the help of config.
Configuration:
To setup the backup path we need to have a backup tunnel configured, it’s like an additional virtual link that we provide when the primary one fails. And this backup link needs to be configured at the place from where we need to setup the backup path, in this case, we have P1 from where we can see a redundant path, and since we are protecting the link on P1 so it makes sense if we have an alternate path starting from P1. The link which is breaking is connected between P1 and P3. So we need an alternate path that starts from P1 and terminates at P3. So this gives us clue that we need to configure backup tunnels on P1 and P3. Below you will see the config from P1 and P3.
P1 Configurations: ! ip cef mpls traffic-eng tunnels ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface GigabitEthernet1/0 ip address 20.20.20.2 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface GigabitEthernet2/0 ip address 20.20.20.6 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface GigabitEthernet3/0 ip address 30.30.30.1 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface GigabitEthernet4/0 ip address 30.30.30.5 255.255.255.252 mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel100 ip rsvp bandwidth 512 512 ! router ospf 1 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 router-id 4.4.4.4 network 0.0.0.0 255.255.255.255 area 0 ! interface Tunnel100 description "Link Protection Tunnel" ip unnumbered Loopback0 tunnel destination 6.6.6.6 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name P1-P3 no routing dynamic ! ip explicit-path name P1-P3 enable next-address 30.30.30.2 next-address 40.40.40.10 ! P3 Configurations: ! ip cef mpls traffic-eng tunnels ! interface Loopback0 ip address 6.6.6.6 255.255.255.255 ! interface GigabitEthernet1/0 ip address 30.30.30.6 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface GigabitEthernet2/0 ip address 40.40.40.5 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface GigabitEthernet3/0 ip address 40.40.40.10 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth 512 512 ! interface Tunnel100 description "Link Protection Tunnel" ip unnumbered Loopback0 tunnel destination 4.4.4.4 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name P3-P1 no routing dynamic ! router ospf 1 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 router-id 6.6.6.6 network 0.0.0.0 255.255.255.255 area 0 ! ip explicit-path name P3-P1 enable next-address 40.40.40.9 next-address 30.30.30.1 !
With the above configurations on P1 and P3 we have setup a backup tunnel and associated it with the gi4/0 failure. However, there is another step needed for this to work. We need to enable fast-reroute on our original TE tunnel which is configured on PE1. So let’s see how to do it…
PE1 Configuration : ! interface Tunnel13 tunnel mpls traffic-eng fast-reroute !
Alright, now the configuration part is complete. Let me quickly summarize the configuration.
- MPLS TE was already configured between PE1-PE3
- Link protection backup tunnel Tun100 was enabled on P1 and P3.
- Associated the physical interface (gi 4/0) with the backup tunnel on P1, so that whenever the link fails tunnel gets activated.
- Enabled fast-reroute on PE1 which is tunnel headend.
Now let’s move to the verification section to see if the setup working.
Verification.
On P1 router :
P1#sh mpls traffic-eng fast-reroute database
Headend frr information:
Protected tunnel In-label Out intf/label FRR intf/label Status
LSP midpoint frr information:
LSP identifier In-label Out intf/label FRR intf/label Status
2.2.2.2 13 [93] 213 Gi4/0:409 Tu100:409 ready
Here we see that the tunnel is in the “ready” state which means it is activated and monitoring the link which it needs to protect. Here the link is gi4/0. The above output also tells us that the packet will come to the router with the label 213 and then it should be forwarded with label 409, but in case of failure it cannot happen because the path to label 409 router (P3) is broken. With the backup tunnel, we are protecting that path so we will have a virtual path to P3 but when the packet will reach P3 it is still expecting label 409. So the summary is that we also need to protect the label 409. Hence the packet will have two labels while taking the backup path (409 + the label imposed by tun100). You can use the below command to check the label. This will make more sense when you will see the traceroute when I test the link failure at the end of this blog.
P1#sh mpls traffic-eng tun tun 100
Name: "Link Protection Tunnel" (Tunnel100) Destination: 6.6.6.6
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit P1-P3 (Basis for Setup, path weight 2)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet3/0, 308
RSVP Signalling Info:
Src 4.4.4.4, Dst 6.6.6.6, Tun_Id 100, Tun_Instance 14
RSVP Path Info:
My Address: 30.30.30.1
Explicit Route: 30.30.30.2 40.40.40.9 40.40.40.10 6.6.6.6
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 2 (TE)
Explicit Route: 30.30.30.1 30.30.30.2 40.40.40.9 40.40.40.10
6.6.6.6
History:
Tunnel:
Time since created: 2 hours, 11 minutes
Time since path change: 2 hours, 10 minutes
Number of LSP IDs (Tun_Instances) used: 14
Current LSP:
Uptime: 2 hours, 10 minutes
Prior LSP:
ID: path option 1 [11]
Removal Trigger: path error
Now let’s move to more action and see how it works when the link actually fails. I am going to shutdown the link gi4/0 on the P1 router. On PE1 and PE3 I have a loopback configured which is simulating the customer network. The IP addresses on loopbacks are 192.168.1.0/24 and 192.168.2.0/24 respectively. Please check my blog for this configuration and more detail about it GNS3 LAB Cisco: Quick Configuration MPLS TE (traffic engineering).
Before the link failure on P1.
Ping and Traceroute from PE1 to 192.168.2.1 which is loopback configured on PE3:
PE1#ping 192.168.2.1 sou lo 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/47/68 ms
PE1#traceroute 192.168.2.1 source lo 1
Type escape sequence to abort.
Tracing the route to 192.168.2.1
1 20.20.20.2 [MPLS: Label 213 Exp 0] 32 msec 48 msec 40 msec
2 30.30.30.6 [MPLS: Label 409 Exp 0] 44 msec 48 msec 56 msec
3 40.40.40.6 [MPLS: Label 514 Exp 0] 76 msec 48 msec 48 msec
4 50.50.50.2 48 msec 72 msec 52 msec
PE1#
you can verify if the path is right as per the TE config with the explicit route configured in below command. Also match the labels in the RSVP Resv info with the traceroute info. This test tells us that the traffic is indeed forwarded over MPLS TE path.
PE1#sh mpls traffic-eng tun tun 13
<Output snipped>
Explicit Route: 20.20.20.2 30.30.30.5 30.30.30.6 40.40.40.5
40.40.40.6 50.50.50.1 50.50.50.2 8.8.8.8
RSVP Resv Info:
Record Route: 4.4.4.4(213) 6.6.6.6(409)
7.7.7.7(514) 8.8.8.8(0)
Now , I will shutdown the link gi 4/0 on P1.
After the link failure on P1. Outputs from P1 router: The FRR tunnel moved to ready->active state. P1#sh mpls traffic-eng fast-reroute database Headend frr information: Protected tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status 2.2.2.2 13 [93] 213 Gi4/0:409 Tu100:409 active P1#sh mpls traffic-eng tun tun 100 Name: "Link Protection Tunnel" (Tunnel100) Destination: 6.6.6.6 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit P1-P3 (Basis for Setup, path weight 2) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : GigabitEthernet3/0, 308-------> Notice the label RSVP Signalling Info: Src 4.4.4.4, Dst 6.6.6.6, Tun_Id 100, Tun_Instance 14 RSVP Path Info: My Address: 30.30.30.1 Explicit Route: 30.30.30.2 40.40.40.9 40.40.40.10 6.6.6.6 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 2 (TE) Explicit Route: 30.30.30.1 30.30.30.2 40.40.40.9 40.40.40.10 6.6.6.6 History: Tunnel: Time since created: 2 hours, 11 minutes Time since path change: 2 hours, 10 minutes Number of LSP IDs (Tun_Instances) used: 14 Current LSP: Uptime: 2 hours, 10 minutes Prior LSP: ID: path option 1 [11] Removal Trigger: path error P1# Outputs from PE1 router: Ping is still working, it will fail if we do not have backup tunnel. PE1#ping 192.168.2.1 sou lo 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 48/53/64 ms PE1#traceroute 192.168.2.1 source lo 1 Type escape sequence to abort. Tracing the route to 192.168.2.1 1 20.20.20.2 [MPLS: Label 213 Exp 0] 40 msec 48 msec 28 msec 2 30.30.30.2 [MPLS: Labels 308/409 Exp 0] 52 msec 16 msec 64 msec-------> The extra label 308 belongs to backup TE tunnel. 3 40.40.40.10 [MPLS: Label 409 Exp 0] 44 msec 40 msec 40 msec 4 40.40.40.6 [MPLS: Label 514 Exp 0] 40 msec 48 msec 52 msec 5 50.50.50.2 52 msec 56 msec 48 msec PE1#
And now here is how the backup path will look like, notice the label assignments.
Great !!! this proves that our backup TE tunnel is working like a charm, and it is nothing less than magic when you will see this working in the production setup. These things make our (network engineer’s) world more beautiful :D.
Conclusion.
With this blog, I have covered the link protection scenario. We also need to cover equally important “node protection.” For example what if the node P3 itself fails. In that case, we need to have a backup tunnel that can skip P3 from the path. Stay tuned to keep learning on this topic. Please share and subscribe to my blog.
Check the Youtube video for MPLS TE , FRR Link Protection and Node protection Demo:
Which IOS image did you use to demonstrate MPLS TE on GNS3?
Hi David, these are IOSv routers.