![]() There is one nice command that shows you in percentage, how good you are protected. Let’s start our check with Nokia (Alcatel-Lucent) SR OS router. By the way Nokia (Alcatel-Lucent) SR OS implements by default per-link calculation. For Nokia (Alcatel-Lucent) SR OS you don’t have possibility to choose the type for FRR calculation, so it isn’t applicable. In today’s reality the CPU and memory capacity isn’t usually the case so I don’t want to go in that discussion. Nokia (Alcatel-Lucent) SR OSįor 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”. As it’s already done, all we need is just to activate FRR with a couple of commands. 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. 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 For the first scenario, where we test fast reroute (FRR) / loopfree alternative (LFA) for IPv4 and IPv6, the provided topology is enough. All the links have equal cost with the value of 10. The following logical topology I’m gonna to configure for this FRR/LFA/RLFA lab:Īs the routing protocol (IGP) IS-IS is used, though you can use OSPF, if you want. 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: 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. 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. Unfortunately, this feature isn’t standardized, so each vendor has its own implementation. Well, in the pure IP world there is no such solution, but LDP has such solution, which is called RLFA (Remote LFA). In RSVP-TE based MPLS we could build FRR tunnel and that’s it. This feature is also called LFA (loop free alternative).īut 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 case of failure, our router will immediately use the backup route without performing additional SPF. 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. The first option is IP FRR (IP fast reroute) that can be implemented even without MPLS. But generally we have a plenty of possibilities, what we can do to achieve fast convergence without RSVP-TE. 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”. It’s one of the most robust (probably the most robust) mechanism that can be implemented in the network. Or otherwise, for commercial purposes without theĭuring discussing MPLS forwarding plane built with RSVP-TE we have reviewed the configuration and operation of fast reroute. ![]() Means, electronic, mechanical or photocopying, recording, Retrieval system, or transmitted in any form or by any No part of this blogpost could be reproduced, stored in a ![]()
0 Comments
Leave a Reply. |