Hello my friend,
We have talked a lot about services that run on IP/MPLS network, but we have only once talked (link) about how to assure the service level. There are really lots of thinks we can do in this field, but one of the first and most important is the speed of restoration. That’s what I want to cover in current article.
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. |
Brief overview
During discussing MPLS forwarding plane built with RSVP-TE we have reviewed the configuration and operation of fast reroute. It’s one of the most robust (probably the most robust) mechanism that can be implemented in the network. But what if you don’t have RSVP-TE? Does it mean that you can’t achieve fast convergence and service restoration in case of failure? The answer will be “it depends”. But generally we have a plenty of possibilities, what we can do to achieve fast convergence without RSVP-TE.
The first option is IP FRR (IP fast reroute) that can be implemented even without MPLS. The main idea is that router that makes protection performs SPF calculation also from the point of view of its adjacent routers (valid both for OSPF and ISIS) and if it can find alternative route (to the best one) to destination, and this route doesn’t pass our router, then we have backup route that is precalculated and installed in FIB. In case of failure, our router will immediately use the backup route without performing additional SPF. This feature is also called LFA (loop free alternative).
But what if our adjacent router doesn’t satisfy the criteria above? This case is valid especially for ring topologies, where we have numerous devices in the chain on the one hand and therefore limited option for backup route calculation. In RSVP-TE based MPLS we could build FRR tunnel and that’s it. Well, in the pure IP world there is no such solution, but LDP has such solution, which is called RLFA (Remote LFA). Unfortunately, this feature isn’t standardized, so each vendor has its own implementation. We’ll see further how to deal with it.
What are we going to test?
We’ll deploy and test configuration of IP FRR/LFA for IPv4/IPv6 prefixes in the mixed Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR scenario. Then we’ll move to the IPv4/MPLS network and will test remote LFA (RLFA) in the same environment, but with a bit different topology to outline the use case for it.
Topology
Thanks to the enhancement to my test lab mentioned in the previous article (link) I will use 4 virtual routers (2 Nokia (Alcatel-Lucent) VSRs and 2 Cisco IOS XRv:
The following logical topology I’m gonna to configure for this FRR/LFA/RLFA lab:
As the routing protocol (IGP) IS-IS is used, though you can use OSPF, if you want. All the links have equal cost with the value of 10. For the first scenario, where we test fast reroute (FRR) / loopfree alternative (LFA) for IPv4 and IPv6, the provided topology is enough.
In order to save your time, take these configuration files to build the initial topology: initial_sr1 initial_sr2 initial_xr3 initial_xr4 initial_linux
Case 1 – IP FRR/LFA for IPv4/IPv6 addresses
The main prerequisite for building any advanced mechanism of resiliency, regardless of dealing with Nokia (Alcatel-Lucent) SR OS or Cisco IOS XR, is up and running IGP. As it’s already done, all we need is just to activate FRR with a couple of commands.
| 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 |
For any Cisco platform (IOS, IOS XE, IOS XR, NX-OS) the recommended mode is “per-prefix”, because it provides much more flexibility than “per-link”. In today’s reality the CPU and memory capacity isn’t usually the case so I don’t want to go in that discussion. For Nokia (Alcatel-Lucent) SR OS you don’t have possibility to choose the type for FRR calculation, so it isn’t applicable. By the way Nokia (Alcatel-Lucent) SR OS implements by default per-link calculation.
Let’s start our check with Nokia (Alcatel-Lucent) SR OS router. There is one nice command that shows you in percentage, how good you are protected. Certainly our goal is to see 100% here:
|
A:SR1# show router isis lfa-coverage |
The routes themselves you can see with the following command.
|
A:SR1# show router route-table ipv4 alternative |
At Cisco IOS XR you can see all the backup routes either in route table:
|
RP/0/0/CPU0:XR3#show route ipv4 |
Or in specific output of “show isis… “ command:
|
RP/0/0/CPU0:XR3#show isis fast-reroute |
The most important is to see backup route to be installed in FIB. In Nokia (Alcatel-Lucent) SR OS router you can do it by issuing the following command:
|
A:SR1# show router fib 1 |
In Cisco IOS XR you have just the same overall FIB tables:
|
RP/0/0/CPU0:XR3#show cef ipv4 |
Well, what happens after we have configured IP FRR/LFA and got all the backup routes calculated? As soon as router detected that peer isn’t available (like down interface, expiration of BFD of IGP hold timers), the backup FIB entry is marked as active without new SPF calculation and traffic is forwarded further without disruptions. Further in background new SPF is being done, and after its completion new best route (and backup route as well) can be chosen.
Unfortunately, it isn’t possible to configure BFD in Cisco IOS XR to show high speed convergence in action.
Just trust me, it works well. Frankly speaking, the only meaningful option to measure the performance with and without IP FRR/LFA is to use traffic generator (i.e. IXIA), which can timestamp test traffic.
For IPv6 addresses all the commands are the same, you just need to add keyword “ipv6”. I will provide only output of the FIB. For Nokia (Alcatel-Lucent) SR OS router it looks like:
|
A:SR1# show router fib 1 ipv6 |
For Cisco IOS XR it’s very similar:
|
RP/0/0/CPU0:XR3#show cef ipv6 |
Here are the configuration files of the devices for the first scenario: case_1_sr2 case_1_xr3 case_1_xr4 case_1_sr1
Case 2 – Remote LFA for MPLS
The next point in our journey is configuration of Remote LFA for our network. But before doing this, let’s first of all disable link SR1 – XR4 so that our topology has the following structure:
Now let’s check LFA coverage for one Nokia (Alcatel-Lucent) SR OS router and for one Cisco IOS XR router:
|
A:SR1# show router isis lfa-coverage |
You see that due to changes in the topology the LFA coverage right now is much worse that it was. So that’s case, where remote LFA (RLFA) comes into play. But the realization of RLFA is different between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. In Nokia (Alcatel-Lucent) SR OS you have to configure RSVP-TE tunnel that is used for backup, whereas Cisco IOS XR uses automatic targeted LDP session to establish session with node protection. Frankly speaking, realization of remote LFA in Cisco is much easier to configure than in Nokia.
As we have a slightly different topology, here is the initial configuration file for the second case: initial_2_sr1 initial_2_sr2 initial_2_xr3 initial_2_xr4
Remote LFA – Cisco IOS XR configuration
As Cisco approach is easier to deploy, let’s start with it:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg>config>router# 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 |
Cisco IOS XR automatically calculates to which device it need to build targeted LDP session in order to achieve remote LFA convergence. At Nokia (Alcatel-Lucent) SR OS we need manually configure these sessions (after we check at Cisco, what are the corresponding peers):
|
RP/0/0/CPU0:XR3#show mpls ldp discovery |
And here is the desired picture that shows full LFA convergence in our network:
|
RP/0/0/CPU0:XR3# show isis fast-reroute |
Now let’s see how the things going on in Nokia (Alcatel-Lucent) world.
Remote LFA – Nokia (Alcatel-Lucent) SR OS configuration
A I’ve already said, in Nokia (Alcatel-Lucent) SR OS we have to configure backup manual RSVP-TE tunnels to the IPv4 addresses that we want to protect. In our case, it’s IPv4 addresses of system / loopback 0 interfaces. Here is the configuration:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg>config>router# 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 |
When these configuration is done, you will see the new entries in LFIB:
|
A:SR1# show router tunnel-table |
Due to the fact that we configured RSVP tunnels are “lfa-only”, these tunnels aren’t used in the normal operation. They are used only when normal operation is broken, so you can see them as backup entries in FIB:
|
A:SR1# show router fib 1 |
That’s it. Now we have achieved full remote LFA convergence in our network.
There are the configuration files for the second case: case_2_sr1 case_2_sr2 case_2_xr3 case_2_xr4
Lessons learned
During writing this article the absence of BFD was very annoying point, as I wasn’t able to quickly test topology changes and routers reaction (actually, LFA itself) in the whole scale. But I’ve used BFD on the link SR1-SR2, as Nokia (Alcatel-Lucent) VSRs fully support BFD comparing to Cisco IOS XRv. Though it isn’t provided in my configuration, you are still able to perform some tests.
Conclusion
Quick responses to the failure in the network is one of the corner stone of the current networks. When decades ago even service providers had separate TDM (time division multiplexing) voice services, the demands to IP networks were not so high, as they are now. Now we have to assure that IP/MPLS networks not only provide rich feature-set in terms of services (L2/L3 VPNs, traffic engineering), but also they are resilient and restore quick in case of failures. IP fast-reroute (FRR) or loopfree-alternative (LFA) are one of the possible in this tool set. Use it wisely, Take care and good bye!
Support us
BR,
Anton Karneliuk
Hi Anton,
Thank you for your detailed explanation on topic. I have also focused on the same topic for a while. I have completed all of my LFA test with success. But not same result for remote-LFA. Is that possible can you please share your test results to see the convergence time of remote-LFA?
On my setup; I have created a ring topology and performed all of required config for remote-lfa. When I check the route-table, I may able to see my repair tunnel (RSVP LSP tunnel) as below;
10.10.10.1/32 Remote ISIS 00h52m14s 18
10.1.3.1 10
10.10.10.6 (LFA) (tunneled:RSVP:3) 50
And I have started a rapid ping from this node to another node which on the ring. While rapid ping packets are going, I shutdowned one of interface on the node to see the convergence time of remote-LFA. But on VSR, the convergence time is apprx. 1,1 sec. (110 packet lost on rapid ping). Can you please also share your test results? I guess I am missing one point. 🙂
Thanks in advance,
-Burak
Hi Burak,
I haven’t done tests to check the convergence speed, as it makes no sense in my case: IOS XR doesn’t support BFD, what is must if we want to reach the low convergence time. Also isis timers should be tuned to lower the event response time. Hope this helps.
BR,
Anton
Hi Anton,
Many thanks for your post.
BFD Works on IOS XR, I use image ASR 9K 6.4.1.
Cheers.
Hi Joel,
You are absolutely right. I mention in the article Cisco IOS XRv, it’s important. The XRv doesn’t have a lot of data plane functions, and BFD doesn’t work there as well. On the real HW, as you said, BFD is working just fine.
BR,
Anton