Hello my friend,
The last article I’ve covered two possible options how you can increase the robustness of your network. It was done via introducing FRR/LFA (Fast Reroute / Loopfree alternative) for pure IPv4/IPv6 addresses and for LDP. Now let’s see the most scalable option – topology independent LFA (TI-LFA) based on SPRING (segment routing).
1 2 3 4 5 | No part of this blogpost could be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical or photocopying, recording, or otherwise, for commercial purposes without the prior permission of the author. |
Disclaimer
I’m starting now to write this article without understanding how to show you operation of TI-LFA at Nokia (Alcatel-Lucent) SR OS router, just because my tests were still not successful. Nevertheless, I hope to find solution till the end of the article. In any case I’m already able to show you Cisco IOS XR part, what is in general sufficient for me to begin.
Brief overview
The discussion that was started in the previous article shew some problems with traditional IP FRR / LFA (IP fast reroute / loopfree alternative) and even remote LFA approach. “Ordinary” LFA has problems of working with loop topologies, therefore its applicability is quite low. Remote LFA provides the mean to overcome it, but it isn’t standardized, what leads to very complex configuration in interoperable scenario. You remember, I had to manually configure RSVP-TE tunnels with explicit hops in order to make remote LFA protection in Nokia (Alcatel-Lucent) SR OS routers. Not very scalable solution at all.
Topology independent loopfree alternative (TI-LFA) is wonderful tool from SPRING (Segment Routing) toolbox that provides us capability to deploy really quick, solid and interoperable mechanism for local restoration. It’s really topology independent, so it suits mesh, ring and fabric topologies.
Though it isn’t obvious in Nokia (Alcatel-Lucent) SR OS at a glance.
All the calculation of primary and protection nodes is done via SPF algorithm, what is essential both for OSPF and ISIS protocols, and the protection is done via label stacking.
What are we going to test?
It’s easier to understand TI-LFA at the example. I’m gonna to show you its operation both in partial-mesh and ring topology for IPv4 addresses for both vendors, which I’m writing about, Nokia (Alcatel-Lucent) and Cisco.
Topology
The physical setup of my lab consists of four routers (2x Nokia (Alcatel-Lucent) VSR (virtual SR 7750) and 2x Cisco IOS XRv (virtual ASR 9000)).
This is the default setup for the recent labs, though previously I’ve used only 3 routers due to limitation of my laptop.
Both logical topologies in this article will be just the same as they were in the previous one. The initial topology has a partial mesh architecture:
The routing protocol is ISIS, though you can deploy OSPF if you want. Initial configuration are the same as in the previous article, but for your convenience you can find it here as well: initial_xr4 initial_xr3 initial_sr2 initial_linux initial_sr1
Configuration of SPRING (Segment Routing) in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR
A couple of months ago I’ve written a separate article that shows the configuration of SPRING (Segment Routing) in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, I won’t get into details here. Just for the sake of clarity you can find brief configuration of SPRING for the topology above:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
We can check the operation of Segment routing just by looking into LFIB. Let’s take LFIB from SR1, which is Nokia (Alcatel-Lucent) SR OS router, for example:
|
A:SR1# show router tunnel-table |
You see that you have MPLS LSPs to all of the prefixes that’s what we are looking for. Now let’s make check at Cisco IOS XR router (i.e. XR4):
|
RP/0/0/CPU0:XR3#show mpls forwarding |
Now it’s time to activate protection, which is topology independent loopfree alternative (TI-LFA) for this lab.
Configuration of TI-LFA in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR
Frankly speaking, the configuration of TI-LFA is pretty simple and straightforward, after you have activated SPRING (Segment Routing):
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
The interesting point here is that configuration in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR is done completely at different levels. In Nokia VSR (SR 7750) you just activate remote LFA globally for ISIS, whereas in Cisco IOS XRv (ASR 9000) you configure it only at interface level.
Nokia (Alcatel-Lucent) SR OS has per-interface LFA commands, as well as Cisco IOS XR has global LFA commands, but they are necessary only for fine tuning.
TI-LFA in mesh topology
If you have read my previous article about FRR/LFA for IPv4/IPv6, you already know the commands that are necessary to be used to check state of the backup. If not, it’s not a problem, take a look at the commands below. Nokia (Alcatel-Lucent) SR OS router SR1 can be checked as followed:
|
A:SR1# show router isis lfa-coverage |
We have 100% LFA coverage for all prefixes, meaning that all the prefixes, which can have backup, have it. You remember, we have a partial mesh topology now, so backup next-hop for both protected links are XR4.
Now let’s check Cisco IOS XR router XR4:
|
RP/0/0/CPU0:XR4#show isis fast-reroute |
It looks good, isn’t it? With IP FRR/LFA for IPv4/IPv6 addresses previously we had the same result. What if we have ring topology? The things is going to be more interesting.
TI-LFA in ring topology
Let’s bring down link SR1-XR4 in order to get ring topology:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR4 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
In the previous article Cisco IOS XR shew better (or easier) operation in terms of LFA, so I will start providing output from XR4 as well:
|
RP/0/0/CPU0:XR4#show isis fast-reroute |
You see that the backup paths (as well as their type) have changed, but in general you have full LFA coverage further. To be more precise, let’s analyse which labels are pushed at the path from XR4 to SR2 at primary and backup path:
|
RP/0/0/CPU0:XR4#show cef ipv4 10.0.255.2/32 |
You see that you have one MPLS label at primary path (500022) at the interface pointing directly to SR2. At backup path you have two labels: first is 16011 and the second is 500022. At the backup path the next-hop points to XR3, that’s shy topmost label is 16011 (11 is SID of SR1 and 16000 is label block for segment routing at XR3). The LFA works as follows:
- XR4 pushes two labels (16011, 500022) and sends packet to XR3.
- XR3 swaps 16011 with 500011 and sends packet to SR1. Label 500022 is untouched.
- SR1 pops the topmost label as it refers to this router. Then it looks at another label, which is 500022 and sends packet further to SR2
This is the TI-LFA in the nutshell. I guess, you understand now it’s logic. The only question, why SR1 is chosen as backup node (its label is the first in the transport stack). Answer to this question can be found here. In short words, it’s calculated automatically.
Let’s check now, what’s is going on at SR in terms of backup paths. If you take a look into lfa-coverage information, you might be disappointed:
|
A:SR1# show router isis lfa-coverage |
You see that there is no coverage for backup prefixes. I was very mad about this issue. Why does it work perfectly in Cisco IOS XR, but no way for Nokia (Alcatel-Lucent) SR OS? Well, the main problem is lack of documentation for Nokia (Alcatel-Lucent) SR OS, or poor quality of such documentation. Fortunately, I’ve found some information at the presentation that was shown at SReXperts event in the last year. There is one magic command that shows real label stack for the outgoing traffic including backups:
|
A:SR1# show router fp-tunnel-table 1 |
You see here that all the prefixes for loopback 0 / system interfaces have primary and backup paths and labels stacks. It follows just the same logic as Cisco IOS XR, and the only difference is the consequence how the prefixes are written.
In command “show router fp-tunnel-table 1”, the last number is number of the slot, just the same as “show router fib 1”
The answer to the question, why there is no protection in routing table (and FIB) as well for IP prefixes you can find in tunnel-table:
|
A:SR1# show router tunnel-table 10.0.255.2/32 detail |
You see that these tunnels aren’t used for “IGP shortcut” meaning for forwarding traffic that is not assigned to any service instance (it doesn’t matter whether this service is Layer 2 (VPWS, VPLS, E-VPN) or Layer 3 (VPRN/VRF)).
So you may be calm, your MPLS services are protected with topology independent loopfree alternative (TI-LFA) both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR world.
Final configuration files are provided for your reference as usual:
Lessons learned
The key take away is that official documentation (and information from courses) doesn’t allow you to get full understanding what is going on in your Nokia (Alcatel-Lucent) VSR (SR 7750) and why. Probably this is caused by perception to sell professional services as much as possible, because if the information is known to the client then they will do everything themselves. That’s my personal opinion, I don’t know the real reason for that. I hope that reading my block helps you find answer to your questions.
Conclusion
We have covered all the possible ways of MPLS infrastructure protection. When we discussing MPLS based in RSVP-TE, we briefly reviewed TE fast reroute (TE-FRR). In the previous article we talked about IP FRR for IPv4/IPv6 addresses and for MPLS (MPLS FRR). Discussin touched both LFA and Remote-LFA, which extends possibility for protection. The most scalable and robust LFA option can be achieved with SPRING (Segment Routing) and is called TI-LFA. And that was the topic for today. I’m moving to the next exciting topics. Take care and good bye!
Support us
BR,
Anton Karneliuk
