Make sense to do that, right now I am thinking of writing an article on RR design which will include Add Path and a few other things and then bring this to closure. > How about Next article on EIGRP/BGP Add Path to summarize the whole series started with MPLS TE ? □ From a future perspective, I think SR makes things lot simpler and could be a good alternative for providing FRR. IP FRR is a great solution in situations where you don’t have any protection at all and after enabling IP FRR even if you get only 50% coverage it’s still better than what you have today. IP FRR is a lot simpler, but the problem is that since we are always fighting with the metrics we may not get always 100% coverage. How Large SPs and Enterprises deal with that part of the equation.Īs you might have already seen that depending on your intention for deploying TE FRR, it can get quite complicated compared to IP FRR. > What’s your opinion on MPLS TE FRR & IP FRR from Complexity and MTTR standpoint in a large scale network. For IP FRR SPF computation, modern CPU’s should be able to handle it just fine and many implementations give priority to main SPF computation over IP FRR SPF computation.Also Per-Prefix computation is complex compared to Per-Link computation so that can also be a factor in terms of CPU tax. Though if it’s an issue or not greatly depends on the kind of hardware(CPU and Memory) and IGP size and probably the best answer is ” it depends” □. > What should be consideration for sizing the HW for IP FRR Deployment since it’s gonna add additional CPU and Memory requirementsĮnabling IP FRR definitely adds CPU and Memory tax and should be part of consideration while deploying LFA. Yes, both Cariden and Wandl provide support for LFA’s. > Are there any offline tools from Cisco and Juniper in order to see what level of protection I would get with LFA & RLFA Now think parallelly what would OSPF/IS-IS would do in those situations and that should clear things up □ Take a look at the section 3.6 of which goes through DUAL operation for a square topology one case where it has a feasible successor and another case where it doesn’t. > How EIGRP solves the same problem of Micro-Loops.ĮIGRP avoid Micro-Loops by dropping the packets rather than looping the packets. In General LFA/rLFA is a great and simple solution for NSP POP’s and RSVP-TE’s are still the best solution for backbone network where 100% coverage is needed. We also looked at various topologies and their applicability to LFA’s. We looked at Microloops and how LFA and Remote LFA tries to mitigate them. So as you can see that LFA/RLFA doesn’t completely eliminate MicroLoops. Ordered FIB is one solution which can solve this problem and I will leave that research to the reader. But WASH FIB is still pointing to NYC for DEN traffic until WASH receives the LSP update, runs the SPF and programs the new route. Till then we will have a MicroLoop between NYC-WASH. Let’s assume LSP update reaches NYC first, it runs the SPF and programs the new route (Which will be through WASH) and start sending the traffic towards WASH. So what other events will occur as a result of KYC to STL link failure? STL will send an LSP update to the other nodes about the failure of STL-KYC. Please recall that ATL isn’t a valid LFA as ATL’s best path goes through STL for DEN (Inequality#1 is false 180 < 60 + 120). HSTN in our case and tunnels the traffic towards him. Now assume that we have IP FRR enabled in the network and we have a link failure between STL and KYC. So let’s look at a POP with a ring topology like below. As you can see in Fig.15, R3 doesn’t meet inequality#1 (3 CHI->STL->KYC-DEN path as shown in the diagram. This kind of multi-hop repair paths are more complicated than single hop repair paths as computations are needed to determine if a path exists (to begin with) and then a mechanism to send the packet to that hop. This problem can be solved if we can find a router which is more than one hop away from the calculating router, from which traffic will be forwarded to the destination without traversing the failed link and somehow we tunnel the packet to that router. Reason is simple i.e.in many cases backup next hop best path goes through the router calculating the backup next hop. This is a continuation from Part 1 Remote LFAĪt this point we already know that simple LFA doesn’t always provide full coverage and its very topology dependent.
0 Comments
Leave a Reply. |