MPLS-TE and use of /31 addressing on backbone uplinks (P2P)

[Andrew WEISS]

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.

Thanks in advance,

Andrew

[Andrew WEISS]

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

Kind regards,

Andrew

[eduardopozo56]

Hi Andrew,

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.

Regards,