MPLS-TE and use of /31 addressing on backbone uplinks (P2P)
Hi, we're recently renumbered a number of our backbone links from /30 to /31.
Shortly after doing so, we noticed that a number of our MPLS-TE tunnels had gone down within portions of the network that were renumbered and I'm wondering whether or not 1) this is a simple coincidence? or 2), whether any of you have experienced the same thing as the result of a /30 to /31 migration?
The impacted devices are several CSR-3 pairs that are all running IOS-XR 4.2.4 which is fully compliant with RFC3021.
The problem and the solution have been identified. MPLS-TE is fully compatible with /31 addressing. For reasons that are beyond the scope of the current post (subject of a case), Cisco IOS / IOS XR maintain in the MPLS-TE dB (SPF) the old IP addresses as phantoms until such time that the "offending" interface is shut/no shut) at which time the MPLS-TE tunnels come back up.
Performing a debug mpls traffic-eng path lookup on either tunnel endpoint help identify the problem.
Oct 18 13:31:26: TE-PCALC-PATH: create_path_hoplist:ip addr A.B.C.D unknown (the old interface IP address)
Once you identify the address, you need to find the device's new IP address (hopefully you saved the before/after addresse are in a migration worksheet or equivalent), connect to the router and do a shut/no shut of the interface that was addressed using the old IP address that appears in your debug as "unknown.". You may need to perform the debug serveral times in order to find all the offending interfaces that still have the phantom IPs in their dBs (they jump from one interface to another when the explicit path is long). Once the entire chain is done, the tunnel will come back up
In researching this problem I was unable to find a single reference either on google or this forum. I'm hopeful that if anyone runs into this problem they'll find my post since it'll save them lots of time. In truth, L2VPN, VRF, L2VPN in VRF in VRF, VRF in VRF, logical-systems, etc all make networking hard enough, but when you add "phantom addresses" that shouldn't even be there to the equation, it makes things even harder
I agree that all the configuration in L2VPN, L3VPN, MPLS-TE, make this complicated enough, and sometimes the difference in IOS and XR platform doesn't help but:
I think it is a common practice to shutdown the interface before changing the ip address. This will help with IGP/BGP/LDP/TE convergence, clearing the old route/entry from the table and recalculating with the new IP when you do the no-shutdown.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...