Do I need LDP-IGP Synchronization to make MPLS VPN fault tolerant?

[Greg Focaccio]

Hello,

In a seperate discussion [https://supportforums.cisco.com/thread/2211187] I found it unusual that even if a prefix is present in a VRF routing table, it does not mean the prefix is reachable.  This was odd to me because of my being accustomed to standard IGP routing tables, where one finds that if the prefix is present than it is reachable.

The phenomena of the prefix being present in the VRF routing table without being reachable can happen if there is a break in the MPLS Label Switched Path.   This phenomena is noticable [see attached diagram] when "mpls ip" is removed from the P2 interface that connects to CORE2.  CORE1 still has a VRF Table route for prefix 154.0.0.154 with next hop 54.54.54.54, but it is unreachable because CORE1 chooses the path to 54.54.54.54 through P1 and P2 instead of directly to CORE2 due to the OSPF cost.

By administratively shutting the interface at P2 going to CORE2 then OSPF reconverges and CORE1 reaches CORE2 directly across 99.12.  After this happens then VRF IT prefix 154.0.0.154 on CORE2 is again pingable from CORE1.

Seems like MPLS VPN is not fault tolerant in this network scenario, when the fault is lost LDP adjacency between P2 and CORE2.  I'm thinking this is why LDP-IGP synchronization exists: to help make MPLS VPN fault tolerant. 

Would using LDP-IGP synchronization in this network prevent lost VRF connectivity between CORE1 and CORE2 in the case when LDP Adjacency between P2 and CORE2 is down?   If so, where and how should it be configured.

Thanks,

Greg

[Harold Ritter · Accepted solution]

Hi Greg,

This is exactly the purpose of LDP-IGP sync. If the LDP session goes down on a specific link, OSPF start advertising this link with a cost of 65535, making any alternate path preferred. I have seen many service providers running into the issue of putting a new link in service and forgetting to activate LDP altogether on that link or having the wrong password for LDP authentication and therefore causing outages. A vast majority of the large MPLS service providers I have the opportunity to work with, deploy LDP-IGP sync.

Hope this helps

[Muhammad Thanveer]

Hello Harold,

Thanks for the information,

"If the LDP session goes down on a specific link, OSPF start advertising this link with a cost of 65535, making any alternate path preferred."

Is this only in the case at the interfaces where I enable both LDP and IGP.

If I intentionally didn't enable LDP on any of the interfaces then ospf  on that particular interface is not going to affect, am i correct?

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Harold Ritter]

Hi Thanveer,

This is the case for all interfaces that have LDP-IGP sync enabled. If you intentionally disable LDP on an interface where LDP-IGP sync is enabled, OSPF will advertise that interface with a cost of 65535 to make sure the link is only use as a last resort. It is not recommended to disable LDP on any interface in an MPLS core as it will obviously cause outages if labeled traffic starts traversing the interface.  

Hope this helps

[Muhammad Thanveer]

Thanks Harold,

I undersatnd the command mpls ldp sync will enable all the interfaces running ospf or ISIS for ldp igp synchronisation.

if I put the command to enable the process globally and then if i disable it for a particular interface by no mpls ldp igp sync then there should be no issues with ospf where I didn't want to enable ldp, am I right?

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Harold Ritter]

That is correct. In such a case OSPF will advertise with the cost configured on the interface as it normally does.

Hope this helps

[Muhammad Thanveer]

Thanks Harold.

Thanks Greg for such a question...

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Greg Focaccio · Accepted solution]

Harold and Thanveer, Thanks for the input.

Harold,  Nice insight about Service Providers. Thanks.

I knew something was missing something before I found LDP-IGP Sync.  The thought of having a prefix in a table, and then have it not be reachable was hard for me to accept.

After adding "mpls ldp sync" in the OSPF process on P1 and P2 [see updated attached diagram], the network became fault tolerant and responded dynamically to removing "mpls ip" from the interface of CORE2 connecting to P2.  As Harold explained the failure of LDP on a link resulted in the (costed) "removal" of the faulted link thus allowing use of non-faulted alternate OSPF / LSP paths.

This output shows the recognition of failed LDP Adjacency and thus failed Sync on the P2 interface conneting to CORE2 after "mpls ip" had been removed on the CORE2 interface conecting to P2:

P-2#show mpls ldp igp sync

[output omitted]

    FastEthernet0/12:

        LDP configured; LDP-IGP Synchronization enabled.

        Sync status: sync not achieved; peer reachable.

        Sync delay time: 0 seconds (0 seconds left)

        IGP holddown time: infinite.

        IGP enabled: OSPF 65525

This output show the new dynamic response on CORE1 after implementing LDP-IGP Sync. 

CORE-1#sir 54.54.54.54

Routing entry for 54.54.54.54/32

  Known via "ospf 65525", distance 110, metric 4, type intra area

  Last update from 86.1.0.3 on FastEthernet0/11, 00:00:23 ago  [the path through P1 and P2]

  Routing Descriptor Blocks:

  * 86.1.0.3, from 54.54.54.54, 00:00:23 ago, via FastEthernet0/11

      Route metric is 4, traffic share count is 1

["mpls ip" removed from CORE2 inpterface connected to P2]

CORE-1#sir 54.54.54.54

Routing entry for 54.54.54.54/32

  Known via "ospf 65525", distance 110, metric 10001, type intra area

  Last update from 99.12.0.54 on FastEthernet0/1, 00:01:00 ago [the alternate path directly to CORE2]

  Routing Descriptor Blocks:

  * 99.12.0.54, from 54.54.54.54, 00:01:00 ago, via FastEthernet0/1

      Route metric is 10001, traffic share count is 1

[Muhammad Thanveer]

Thanks for sharing Greg.

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Giuseppe Larosa]

Hello Greg,

you have been very kind in providing a meaningful feedback to the Harold's suggestion.

@Harold:  we are honored to have you again in the forums

Best Regards

Giuseppe

[Harold Ritter]

Thanks Giuseppe. It is good to be back.