MPLS LDP IGP Synchronization

Introduction

LDP relies on IGP to discover IPv4 prefixes to bind label and advertise them to LDP peers. Under certain conditionals LDP might not be able to assign labels based on the shortest IGP paths. The loss of synchronization between IGP and LDP can cause blackholing and packet loss.

MPLS LDP IGP Lack of Synchronization

  • If IGP is pointing to any interface that does not have a LDP peer, by default no outgoing labels will exist and LSR will strip all labels. These packets will have to be forwarded using IP forwarding. That is not a big problem when all MPLS routers have full routes, but when using BGP route-free core, L3 VPNs or L2 VPNs, the core MPLS routers don't know about the tunneled destination. Therefore these packets can't be forwarded using IP forwarding and will be blackholed.
  • There are no implication if LDP peering establishes first before IGP, since LDP does not control forwarding.
  • LDP is not a routing protocol and can't modify the routing path. The only way is to have the IGP modify it.

Causes for Lack of Synchronization

  • There are a number of reasons that could cause IGP and LDP to be not synchronized. Below is a list of some of them:
    • Race condition where IGP adjacency comes up before LDP peering comes up.
    • LDP is disabled on a the interface that is in the shortest path for IGP.
    • There is an authentication issues between two LDP neighbors, while IGP adj is up.
    • Firewall's ACLs or other filtering of LDP packets either for TCP/646 or UDP/646.

Fixes for LDP IGP Synchronization Problem

  • There are a number of features that help with each problem.
  • MPLS LDP-IGP Synchronization feature helps with most of the identified causes.
  • The MPLS LDP-IGP Synchronization feature ensures that the Label Distribution Protocol (LDP) is fully established before the Interior Gateway Protocol (IGP) path is used for forwarding.
  • MPLS LDP IGP Sync behaves differently depending on the order of operations. Is OSPF enabled first or is LDP enabled first:
    • If OSPF is up and then you enable LPD (MPLS IP):
      • OSPF will send max metric for the interface until LDP comes up, but it will keep the IGP session up.
    • If OSPF is not up or enabled but LDP is configured:
      • OSPF will be kept down until LDP comes up. You can use the hold down to bring up the OSPF session after timer expires.
      • LDP comes up first, then IGP session is brought up.
  • The first condition will keep the OSPF or ISIS Adj session down (see outputs below for details).
  • The second condition does that by advertising a Max-metric in OSPF or ISIS for any links that are not fully synchronized. The main purpose is to influence shortest path away from effected interface and use other backup paths. If no other paths exists, regular IP forwarding will be performed, which could cause packet loss.
  • Some other features which help with some of the synchnorization issues:
    • LDP Autoconfiguration helps by automatically enabling LDP on IGP links. This feature prevents a race condition caused by order of operations when configuring IGP and LDP. If IGP is enabled first on an interface, traffic will start being forwarded once adj comes up, it will not wait for you to configure LDP on that interface.

LDP IGP Synchronization Example

  • To demonstrate the problem please see the topology below.
mpls%20ldp%20igp%20sync%20001.JPG


Figure 1 - Example topology for MPLS LDP IGP Sync.

  • I will artificially create an issue on the interface between R4.gi2/0 and R3.gi2/0 which will cause the LDP IGP synchronization problem. To do so, I have configured a VERY long hello and hold timer for LDP protocol on R4 and R3. This long timer will emulate a race condition between IGP and LDP, although there really is no race here with these timers ;)
  • R4 and R1 have a BGP peering sessions.
    • R1 is advertising a 192.168.1.0/24 prefix.
    • R4 is advertising a 192.168.4.0/24 prefix.
R4#sh mpls ldp discovery detail
 Local LDP Identifier:
    4.4.4.4:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet1/0 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 4.4.4.4
            LDP Id: 2.2.2.2:0
              Src IP addr: 10.1.24.2; Transport IP addr: 2.2.2.2
              Hold time: 15 sec; Proposed local/peer: 900/15 sec
              Reachable via 2.2.2.2/32
              Password: not required, none, in use
            Clients: IPv4, mLDP
        GigabitEthernet2/0 (ldp): (not ready)xmit        <--only transmitting, nothing received
            Enabled: Interface config
            Hello interval: 300000 ms; Transport IP addr: 4.4.4.4    <--hello 300 sec
            Clients: IPv4, mLDP
  • Configuration on R3 and R4 to cause race condition. Another method that would have worked could have been ACLs that block TCP/646.
mpls ldp discovery hello interval 300
mpls ldp discovery hello holdtime 900
  • Next let me verify the route to R1 192.168.1.0/24 prefix. It's next hop is a recursive lookup of 1.1.1.1.
R4#sh ip route 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 1.1.1.1 00:08:43 ago
  Routing Descriptor Blocks:
  * 1.1.1.1, from 1.1.1.1, 00:08:43 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none
  • Looking up 1.1.1.1, R4's IGP will use the interface R4.gi2/0 as the shortest path.
R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.1.34.3 on GigabitEthernet2/0, 00:08:57 ago
  Routing Descriptor Blocks:
  * 10.1.34.3, from 1.1.1.1, 00:08:57 ago, via GigabitEthernet2/0
      Route metric is 3, traffic share count is 1
  • The BGP next-hop for prefix 192.168.1.0/24, which is 1.1.1.1 does not have a label associated with it. It will have to be forwarded using IP forwarding and send to R3's interface gi2/0.
R4#sh mpls forwarding 1.1.1.1 32
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
18         No Label   1.1.1.1/32       54            Gi2/0      10.1.34.3
  • R3 does not have a route to 192.168.1.0/24 since it only knows about the next-hop address for that route 1.1.1.1, but any packets from R4 are forwarded using regular IP destionation and not using the MPLS label towards the BGP next-hop.
  • All traffic towards 192.168.1.0/24 is blackholed on R3 because of the issue with synchronization between LDP and IGP.
R3#sh ip cef 192.168.1.1 detail
0.0.0.0/0, epoch 0, flags default route handler, default route
  no route
  • Traceroute to display the packet loss.
R4#traceroute 192.168.1.1 source 192.168.4.4
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2  *  *  *
  3  *
  • The solution to this problem is to enable LDP-IGP Synchronization feature under the OSPF process. This feature changes the shortest path selection to make the problem link be least preferred for IGP routing and prevent LDP from using it if there is another path.
R4(config)#router ospf 1
R4(config-router)#mpls ldp sync
  • Synchronization is enable on all interfaces. Interface Gi2/0 is not in SYNC with LDP.
R4#sh mpls ldp igp sync
    GigabitEthernet1/0:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync achieved; peer reachable.            <<--archived
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        Peer LDP Ident: 2.2.2.2:0
        IGP enabled: 1
    GigabitEthernet2/0:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync not achieved; peer reachable.        <<--no archived
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        IGP enabled: 1
  • Check the OSPF parameters relating to MPLS LDP. Interface sending maximum metric cause R4.gi2/0 not to be preferred for IGP shortest path.
R4#sh ip ospf mpls ldp interface
...
GigabitEthernet2/0
  Process ID 1, Area 0
  LDP is not configured through LDP autoconfig
  LDP-IGP Synchronization : Required
  Holddown timer is not configured
  Interface is up and sending maximum metric        <<---sending max metric
GigabitEthernet1/0
  Process ID 1, Area 0
  LDP is not configured through LDP autoconfig
  LDP-IGP Synchronization : Required
  Holddown timer is not configured
  Interface is up
  • Looking in the OSPF database you can see that link R4.gi2/0 is advertise with metric of 65535.
R4#sh ip ospf database router 4.4.4.4

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 0)

  LS age: 98
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 4.4.4.4
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000011
  Checksum: 0xA1B
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 4.4.4.4
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.34.3
     (Link Data) Router Interface address: 10.1.34.4
      Number of MTID metrics: 0
       TOS 0 Metrics: 65535                        <<---max metric 65535 on Gi2/0

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.24.2
     (Link Data) Router Interface address: 10.1.24.4
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
  • Let's verify the original BGP route to 192.168.1.1 advertised from R1.
R4#sh ip route 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 1.1.1.1 00:32:19 ago
  Routing Descriptor Blocks:
  * 1.1.1.1, from 1.1.1.1, 00:32:19 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none
  • Same next-hop of 1.1.1.1, but this time it has a outgoing label 16 assigned to it.
R4#sh ip cef 1.1.1.1 detail
1.1.1.1/32, epoch 0
  local label info: global/18
  1 RR source [no flags]
  nexthop 10.1.24.2 GigabitEthernet1/0 label 16
  • LFIB shows local label 18 and outgoing remote label 16 out to R2.G1/0 interface which has network address 10.1.24.0/24.
R4#sh mpls forwarding 1.1.1.1
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
18         16         1.1.1.1/32       0             Gi1/0      10.1.24.2
  • Traceroute verifies routing bypassing the faulty link between R4.gi2/0 and R3.gi2/0.
R4#traceroute 192.168.1.1 source 192.168.4.4
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.24.2 [MPLS: Label 16 Exp 0] 64 msec 32 msec 60 msec
  2 10.1.12.1 120 msec *  60 msec

Relevant Commands

mpls ldp sync

Enables MPLS LDP IGP Sync feature per IGP protocol.

R1(config-router)#        mpls ldp sync

no mpls ldp igp sync

Disable LDP IGP Sync per interface.

R1(config-if)#        no mpls ldp igp sync

mpls ldp igp sync holddown

R1(config)#        mpls ldp igp sync holddown (sec)

show ip ospf mpls ldp interface

See the IGP's configuration for LDP. You can see features like LDP IGP Sync, Autoconfiguration,..etc.

show ip ospf mpls ldp interface

show mpls ldp igp sync

Shows the state of LDP IGP synchronization.

show mpls ldp igp sync

Additional Resources

RFC5543 - LDP IGP Synchronization

Comments

Add a New Comment
rating: 0+x
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License