From human mistake, duplicate p2p prefix occurred in the network.
A bypass lsp should have been established via the transit path, but due to duplicate the prefix this bypass lsp was incorrectly signaled and took the wrong path.
Under normal conditions, this duplicate P2P prefix did not cause service disruptions.
However, when the link between actual transit path became the Point of Local Repair (PLR), the traffic was rerouted via the bypass LSP.
Since this LSP was established along an incorrect path, traffic was dropped.
After removing the duplicate prefix, we observed that the bypass LSP did not automatically re-signal. The LSP only re-signaled after manually clearing the RSVP session (*).
So please help us clarify the following queries:
1. Is it abnormal that the bypass LSP (green LSP) was successfully established in this case?
2. Is the behavior described in (*) (the LSP does not re-signal after removing the duplicate prefix) a normal or abnormal behavior?
3. Why did the bypass LSP follow the wrong path, but the primary LSP still use it for PLR?
4. Are there any enhancements for the issue mentioned in the query no.3?
Required Path:
labroot@jtac-mx960dc-r2003-re0> show rsvp session name Bypass->113.171.33.30 extensive
<snip>
From: 123.29.4.75, LSPstate: Up, ActiveRoute: 0
Explct route: 113.171.5.164 113.171.34.144 113.171.27.206 113.171.14.62
Record route: <self> 113.171.5.164 113.171.34.144 113.171.27.206 113.171.14.62
56 Jun 13 17:33:39 Up
55 Jun 13 17:33:39 Record Route: 113.171.5.164(Label=86) 113.171.34.144(Label=61) 113.171.27.206(Label=78) 113.171.14.62(Label=3)
42 Jun 13 16:26:15 Up
41 Jun 13 16:26:15 Record Route: 113.171.5.164(Label=70) 113.171.34.144(Label=52) 113.171.27.206(Label=69) 113.171.14.62(Label=3)
IP Duplicaton:
labroot@jtac-mx204-r2051> show route logical-system hni-p2 113.171.33.31
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
113.171.33.30/31 *[Direct/0] 00:01:38
> via xe-0/1/2.57
Bypass formed on wrong path due to duplication:
123.29.4.8
Explct route: 113.171.5.164 113.171.34.144
Record route: <self> 113.171.5.164 113.171.34.144
There is nothing wrong with the existing behavior. Determining the presence of duplicate addresses (misconfigurations) is not within the scope of TE protocols/features/functionalities.
1. Is it abnormal that the bypass LSP was successfully established in this case?
[Answer] No. The determination of the merge point at the PLR is based on the facility (node or link) being protected, and the bypass path is computed accordingly. The successful setup of the bypass LSP does not depend on the presence of any protected LSP state at the egress of the bypass LSP. In this particular scenario, duplicated IP was determined to be the merge point address, and the computed bypass path ultimately terminated at wrong Node. It is worth noting that the duplicate address on this Node 5 is located on CE link, not on the link traversed by the bypass.
2. Is the behavior described in (*) (the LSP does not resignal after removing the duplicate prefix) a normal or abnormal behavior?
[Answer] It is normal behavior. The issue here is the duplicate address is on link to CE. Suppose the duplicate address was on the transit link (link traversed by the bypass LSP). In that case, the removal of the duplicate prefix should have toggled the interface, which in turn would have caused the signaling to fail on the bypass LSP (the bypass would have gone down and then resignaled). The only workaround is to either wait for the optimize-timer on the bypass LSP to fire (which would ensure that the path is computed correctly) or manually clear the bypass LSP.
In this particular scenario, the newly computed path isn't "better" than the old path (it is a longer path ? higher cumulative metric). So, the dynamic optimization doesn't help. The onus is on the user to manually clear the bypass after fixing the misconfiguration. The problem here is that the misconfiguration is not on an interface traversed by the bypass LSP. If it had been on an interface traversed by the bypass LSP, fixing the misconfiguration would have automatically reset the bypass LSP. For this particular scenario, the only workaround is to clear the bypass LSP manually.
[Answer] Please refer to the response for (1). While exploring paths for bypass computation, the path to Node 5 was deemed the best for the given destination address. Also, note that bypass LSPs provide facility protection (protection against a specific link or node) -- in other words, the same bypass LSP is used to provide protection for multiple primary LSPs traversing through the given facility.
[Answer] There is nothing to be enhanced here.
5. Do you think it would be better to strengthen this by adding an additional check for the merge point node and egress node of the bypass-lsp?
[Answer] There is nothing to strengthen here. If Nodes had the same Node-ID (due to misconfiguration), the same issue will be encountered.
6. Do you think that when the PLR triggers a switchover from the primary LSP to the bypass LSP, there should be a check to ensure that the merge point and the egress node are the same?
[Answer] There is nothing to be enhanced here. With FRR, the backup nexthop at the PLR is programmed in the forwarding plane before the protected facility goes down. There are no checks performed in the control plane at the time of the switchover. The PLR signals a backup path through the bypass LSP post-link-failure (this is orthogonal to the traffic being switched to the bypass). In this scenario, the backup path signaled through the bypass LSP would be rejected by the MP (due to the absence of primary path state), resulting in the PLR tearing down the primary LSP.