IP FRR provides similar fast recovery methods in LDP based networks, but a lot simpler to implement from a complexity perspective.
LFA is similar to MPLS FRR i.e. it pre-installs the backup next-hop into the forwarding plane. LFA’s doesn’t introduce any protocol extensions and can be implemented on a per router basis, which makes it a very attractive option.
FRR OPTIONS :
LFA (Loop Free Alternative) FRR pre compute a loop fee alternate path and installs into the forwarding place LFA are calculated based on route in equality.
Loop Free Alternative
Inequality 1: D(N,D) < D(N,S) + D(S,D)
“Path is loop-free because N’s best path is not through local router.” Traffic sent to backup next hop is not sent back to S
Inequality 2: D(N,D) < D(S,D)
“Neighbor router is closer to the destination than local router.” Loop-free is guaranteed even with multiple failures (if all repair-paths are downstream path)
Inequality 3: D(N,D) < D(N,E) + D(E,D)“N’s path to D must not go through E.”
“The distance from the node N to the prefix via the primary next-hop is strictly greater than the optimum distance from the node N to the prefix.”
Loop free link protecting for broadcast Link
Inequality 4: D(N,D) < D(N,PN) + D(PN,D)
The link from S to N should not be the same as the protected link
The link from N to D should not be the same as the protected link
Advantages of LFA and rLFA
- Simplified Configuration
- Link and Node Protection
- Link and Path Protection
- LFA paths
- Support for both IP and LDP
- LFA FRR is supported with equal cost Multipath (ECMO)
Disadvantage of LFA and rLFA
- LDP must be enabled Everywhere
- Enabled Target LDP Everywhere
- No other tunnelling mechanisms other than MPLS are supported.
- PQ Node is link protecting only, not node protection
- PQ Node calculations are only executed if there are unprotected paths for protectable Prefixes.
- A targeted LDP session to PQ Node will only be built if none exits yet
- No remote LFA for per-link
LFA does not provide full coverage and its very topology dependent. Reason is simple i.e. in many cases backup next hop best path goes through the router calculating the backup next-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.
This kind of multi-hop repair paths are more complicated than single hop repair paths as computations are needed to determine if a path exits (to begin with) and then a mechanism to send the packet to that hop.
So lets look at a POP with a ring topology. As per the below mentioned ring structure.
R3 does not meet inequality # 1 (3 < 1 + 2)
So R3 best path is through the failed link.
If we find a node from which traffic will be forwarded to the destination without traversing the failed link and send it to that node we can achieve FRR without causing a loop.
P Space :
The P Space of a router with respect to a protected link is the set of routers reachable from that specific router using the pre-convergence shortest paths, without any of those paths, transiting that protected link.
P-Space is set of routers that R2 (Source) can reach without using the R2 (S) – R1 link which is R3 (P-Space) and R4 ( P Space) nodes.
Extended P Space :
The extended P space of the protecting router with respect to the protected link is the union of the P Space of the neighbours in that set of neighbor with respect to the protected link is the union of the P spaces of the neighbours in that set of neighbours with respect to the protected link.
Extended P space contains the routers that are R2 direct neighbor, R3 can reach without using the R2 – R1 link which is R4 and R5 node. Point behind Extended P space is that it helps in increasing the coverage.
Q SPACE :
Q-Space of a router with respect to a protected link is the set of routers from which that specific router that can be reached without any path (including ECMP splits) transiting that protected link.
Q Space contains the routers that normally reach R6 without using the R2 (S) R1 link which is R1, R5 and R4 nodes.
PQ Node :
A router that is both Extended P Space and Q Space is a PQ node.
Any router which is a PQ node can be remote LFA candidate. The candidate router to whom R2 (S) can send the packet it will forward the packet to the destination without traversing though R2(S) R1 link. In our case R4 and R5 are the PQ nodes and are considered remote LFA candidates for R2 (S).
There are various ways to tunnel the traffic like IPinIP, GRE and LDP etc. But the most common form of implementation is LDP tunnel.
In Case of IP Traffic Protection :
If we are protecting IP traffic, then R2 (s) pushes an LDP label on top of IP packet to reach R4 (assuming R2 (S) picket R4 as a Remote LFA node. When R3 receives the packet, it forwards the packet to R4 as a plain IP packet because of normal PHP behaviour. When R4 receives the packet destined to R6 (D), it forwards the packet upstream towards R5 node.
In Case of Protecting LDP Traffic :
In this case a stack consisting of two LDP labels is used by R2(S).
Outer LDP label x, is the label to reach R4 and inner LDP label Y, is label to reach R6 (D) from R4.
Now the question is how does R2 (S) know that R4 is using LDP label Y for sending traffic towards R6(D). In order for the protecting node to node know what label a PQ node is used to forward the destination (D), it has to establish Targeted LDP session with a PQ node to get the FEC to label mapping. This bring up the point that TLDP sessions should be enabled on the all the nodes for Remote LFA.
Benefits of RLFA over LFA
- RLFA improve the LFA coverage in ring and poorly meshed topology
- It improves the consistency on selecting the remote tunnel endpoint
- May work with RSVP with very little operational and computational overhead
- RSVP can be used to complement LFA/eLFA and vice versa
- When used in conjunction with MPLS LDP, there is no need of additional protocol in the control plane.
- The data plane for MPLS use of label stacking to tunnel the packets to the PQ node from there, traffic will flow to the destination without returning to the source or traversing the protected link.
LAB DETAILS For Protecting LDP Traffic :
Configuration Details :
ISIS Configuration :
router isis 10
metric-style wide level-1
fast-reroute per-prefix level-1 route-map LFA >>>>>>>>>>> rLFA Configuration
fast-reroute remote-lfa level-1 mpls-ldp >>>>>>>>>>>>>>>>> rLFA Configuration
mpls ldp autoconfig level-1
MPLS Mandatory Configuration :
mpls ldp explicit-null
fast-reroute remote-lfa level-1 mpls-ldp
mpls ldp router-id Loopback0
To display the remote LFA tunnels for ISIS.
R1#sh isis fast-reroute remote-lfa tunnels
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
No time source, *11:28:59.528 UTC Wed Jan 3 2018
Tag 20 – Fast-Reroute Remote-LFA Tunnels:
MPLS-Remote-Lfa1: use Gi2/0, nexthop 10.3.1.4, end point 10.0.4.5
MPLS-Remote-Lfa2: use Gi3/0, nexthop 10.3.1.3, end point 10.0.4.5
To check the IOS programming for a given prefix, please run the CLI
R1#sh ip cef 10.0.4.5
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
No time source, *11:32:04.857 UTC Wed Jan 3 2018
nexthop 22.214.171.124 GigabitEthernet3/0 label [17|17]
repair: attached-nexthop 10.3.1.4 GigabitEthernet2
nexthop 10.3.1.4 GigabitEthernet2/0 label [17|17]
repair: attached-nexthop 10.3.1.3 GigabitEthernet3
In the above output, you could see primary and backup labels [17|17] respectively. The repair path is going via a remote LFA tunnel. It is not necessary that all the prefixes should be protected using remote LFA tunnel. Based on the possibility of looping, the LFA logic will choose to go over either normal backup path or a tunneled backup path.
R1#show ip route repair-paths 10.0.0.12
Load for five secs: 1%/0%; one minute: 0%; five minutes: 0%
No time source, *11:39:07.467 UTC Wed Jan 3 2018
Routing entry for 10.0.0.12/32
Known via “isis”, distance 115, metric 30, type level-1
Redistributing via isis 10
Last update from 10.3.1.4 on GigabitEthernet2/0, 1d12h ago
Routing Descriptor Blocks:
* 10.3.1.4, from 126.96.36.199, 1d12h ago, via GigabitEthernet2/0
Route metric is 30, traffic share count is 1
Repair Path: 188.8.131.52, via MPLS-Remote-Lfa2
[RPR]10.0.0.4, from 10.0.0.12, 1d12h ago, via MPLS-Remote-Lfa2
Route metric is 20, traffic share count is 1