LDP configuration

There are a list of necessary elements to know when forging a LDP configuration.

Basic elements for configuration

When forging a LDP configuration, a router-id has to be defined. It is usually the IP address of one loopback interface. Then the address-family where LDP will operate the discovery has to be configured, as well as the interfaces, and the IP transportation to use.

Here below is an example on how to configure a sample LDP configuration with IPv4 address-family set:

vrf main
   routing mpls ldp
            router-id 5.5.5.5
            address-family ipv4
               discovery transport-address 5.5.5.5
               interface eth0_0
                  ..
               ..
            ..
         ..
      ..
   ..
   commit

Note

You can also disable LDP, either by suppressing the configuration:

vrf main
    del routing mpls ldp
    ..

Alternatively, if you don’t want to lose the configuration, and disabling LDP configuration, you can use following command:

vrf main
    routing mpls ldp
        enabled false

This method can be used if the user wants to force the reset of LDP configuration.

vrf main
    routing mpls ldp enabled false
    commit
    routing mpls ldp enabled true
    commit

Basic LDP configuration

Instantiating a basic back to back configuration setup between two devices is a first step towards understanding LDP but is not enough. Below configuration illustrates this, with rt1 and rt2 configurations. The basic neighbour discovery mechanism is used to make the peering work. You can note that LDP operates over loopback interfaces, like most IGP do. Following drawing illustrates the networking topology and information.

../../../../../_images/ldp-config-back-2-back.svg

LDP back to back topoloy between 2 LER

rt1

vrf main
  routing mpls ldp
    router-id 5.5.5.5
    dual-stack transport-preference ipv4
    address-family ipv4
      discovery transport-address 5.5.5.5
      interface eth0_0
        ..
      ..
      ..
    address-family ipv6
      discovery transport-address 5:5::5:5
      interface eth0_0
        ..
      ..
      ..
    ..
    ..
    ..
  routing static
      ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
      ipv6-route 10:10::10:10/128 next-hop 6000::2
      ..
    ..
  interface
    loopback loop1
      ipv4 address 5.5.5.5/32
      ipv6 address 5:5::5:5/128
      ..
    physical eth0_0
      ipv4 address 6.6.6.1/24
      ipv6 address 600::1/64
      ..
    ..

rt2

vrf main
  routing mpls ldp
    router-id 10.10.10.10
    dual-stack transport-preference ipv4
    discovery hello holdtime 2
    discovery hello interval 2
    address-family ipv4
      discovery transport-address 10.10.10.10
      interface eth0_0
        ..
      ..
      ..
    address-family ipv6
      discovery transport-address 10:10::10:10
      interface eth0_0
        ..
      ..
      ..
    ..
    ..
    ..
  routing static
      ipv4-route 5.5.5.5/32 next-hop 6.6.6.1
      ipv6-route 5:5::5:5/128 next-hop 6000::1
      ..
    ..
  interface
    loopback loop1
      ipv4 address 10.10.10.10/32
      ipv6 address 10:10::10:10/128
      ..
    ..
    physical eth0_0
      ipv4 address 6.6.6.2/24
      ipv6 address 6000::2/64
      ..
    ..
  ..

After having executed the two configurations, the status of the LDP discovery can be obtained, by using following command:

rt3> show mpls-ldp discovery detail
Local:
  LSR Id: 5.5.5.5:0
  Transport Address (IPv4): 5.5.5.5
  Transport Address (IPv6): 5:5::5:5
Discovery Sources:
  Interfaces:
    r1-eth2:
      LSR Id: 10.10.10.10:0
          Source address: 6.6.6.2
          Transport address: 10.10.10.10
          Hello hold time: 15 secs (due in 14 secs)
          Dual-stack capability TLV: yes
      LSR Id: 10.10.10.10:0
          Source address: fe80::d0fc:e8ff:fee0:86dd
          Transport address: 10:10::10:10
          Hello hold time: 15 secs (due in 11 secs)
          Dual-stack capability TLV: yes
  Targeted Hellos:

Also, to know about the status of the peering connections, there is a specific command for that (see below). You can note that the two neighbors successfully peered together, as you can see that the state of the connection is OPERATIONAL. The discovery process on UDP port 646 resulted in creating a TCP session between both sides. Subsequently, destination prefixes and labels were exchanged.

rt1> show mpls-ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 10.10.10.10     OPERATIONAL 10.10.10.10     00:01:32

Also, it is possible to visualise the configured interfaces.

rt1> show mpls ldp interface
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 eth0_0     ACTIVE 00:15:44 4/15           0
ipv6 eth0_0     ACTIVE 00:15:43 4/15           0

It is worth to be noted that the destination prefixes exchanges rely on the address family to be configured. Not configuring it will result in not having destination prefixes of that address-family. Also, if chosen, the discovery transport-address is necessary. Also, it is worth to be noted that LDP protocol plans to use ipv6 if both address-families are chosen. To mitigate this, an extra command has been added (dual-stack transport-preference ipv4) to the configuration so as to fallback over ipv4.

The above configuration results in having the following list of bindings. As said previously, the establishment of TCP sessions between ldp peers, leads to exchange of label mapping messages that permit exchange FEC. In our usage, the FEC stands for the relationship between a Label and a destination IP. The Local Label column stands for locally generated messages and outgoing label to be applied, while Remote Labels stand for received messages from peers. The remote label information is used to establish switching rules. Nexthop stands for the ldp remote peer IP address that sent the message.

rt1> show mpls-ldp binding
AF   Destination          Nexthop         Local Label Remote Label  In Use
ipv4 5.5.5.5/32           10.10.10.10     imp-null    16                no
ipv4 10.10.10.10/32       10.10.10.10     16          imp-null         yes
ipv6 5:5::5:5/128         10.10.10.10     imp-null    17                no
ipv6 10:10::10:10/128     10.10.10.10     17          imp-null         yes

rt1> show mpls-ldp binding ipv6
AF   Destination          Nexthop         Local Label Remote Label  In Use
ipv6 5:5::5:5/128         10.10.10.10     imp-null    17                no
ipv6 10:10::10:10/128     10.10.10.10     17          imp-null         yes

The In Use column tells if the system has routing or switching support to add label information or not. 5.5.5.5/32 and 5:5::5:5/128 are local networks, so do not need to be used with MPLS. However, as we have static routes for reaching 10.10.10.10/32 and 10:10::10:10/128 networks, the binding MPLS information will be used. Practically, an implicit-null label is appended to route entry.

rt1> show ipv4-routes
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route
[...]
S>* 10.10.10.10/32 [1/0] via 6.6.6.2, eth0_0, label implicit-null, 00:08:17

rt1> show ipv6-routes
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route
[...]
S>* 10:10::10:10/128 [1/0] via 6000::2, eth0_0, label implicit-null, 00:08:19

Also, an MPLS switching entry is put in place, so that incoming MPLS packets coming with a label of 16 or 17 be switched with an implicit-null label to go to respective nexthop 6.6.6.2 and 6000::2.

rt1> show mpls table
Inbound Outbound

Label Type Nexthop Label

——– ——- ————— ——–

16 LDP 6.6.6.2 implicit-null 17 LDP 6000::2 implicit-null

LDP Disabling PHP

Above example illustrates that back to back configurations, the label used is an implicit-null label. That label is used when the nexthop is adjacent, that is to say connected. This is called the penultimate hop popping feature. PHP feature avoids having an outermost label between the last LSR and the LER where traffic is heading to. However, that feature can be interesting to disable on some cases. For instance, when working on a back to back operating mode. Below example gives an example on how explicit-null labels can be configured instead of using implicit-null labels on the LER side.

rt1

vrf main
  routing mpls ldp
    router-id 5.5.5.5
    address-family ipv4
      discovery transport-address 5.5.5.5
      label local advertise explicit-null
      interface eth0_0
        ..
      ..
      ..
    ..
    ..
    ..
  routing static
      ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
      ..
    ..
  interface
    loopback loop1
      ipv4 address 5.5.5.5/32
      ..
    physical eth0_0
      ipv4 address 6.6.6.1/24
      ..
    ..

rt2

vrf main
  [..]
  routing mpls ldp
    router-id 10.10.10.10
    dual-stack transport-preference ipv4
    address-family ipv4
      discovery transport-address 10.10.10.10
      label local advertise explicit-null
      [..]

On the peer router receiving the LDP advertisements, an explicit-null label is received, associated with the 10.10.10.10 next-hop address.

rt2> show mpls-ldp binding
AF   Destination          Nexthop         Local Label Remote Label  In Use
ipv4 5.5.5.5/32           5.5.5.5         16          exp-null         yes
ipv4 5.5.5.5/32           5.5.5.5         exp-null    16                no

rt2> show mpls table
 Inbound                            Outbound
   Label     Type          Nexthop     Label
  --------  -------  ---------------  --------
     16      LDP       10.125.0.2  IPv4 Explicit Null

Note

explicit-null label must be only used if it is the last label, that is to say that the label will have BOS bit. In other case will trigger packet drops ( as per RFC 3032). Example scenario where that value can be used will only involve LDP, not L3VPN with multiple stacking.

LDP Interoperability

LDP specification stipulates to use ipv6 transporation when both address-families are negotiated. Adding to this, Cisco uses a non-compliant format to send and interpret the dual-stack capabilities TLV contained in LDP packets. For that, it is possible to align with cisco behaviour and a configuration command is available :

vrf main
  routing mpls ldp
    router-id 10.10.10.10
    dual-stack cisco-interop true
    address-family ipv4
      discovery transport-address 10.10.10.10
      interface eth0_0
        ..
      ..
      ..
    address-family ipv6
      discovery transport-address 10:10::10:10
      interface eth0_0
        ..
      ..
      ..
    ..

BackBone LDP configuration

../../../../../_images/ldp-backbone-configuration.svg

LDP backbone illustration with multiple nodes, and multiple paths

Following setup illustrates what a backbone looks like. Actually, to prevent from link failure or node failure, you can see that there are several paths available to link some nodes together. For instance, to link rt1 with rt2, either rt5 or rt4 can be used, thus preventing from link failure. Also, to prevent from r4 node failure, you can note that there is a path that links rt2 to rt3 by relying on rt5 instead.

By default, multipath is enabled. That implies that unless you rely on some IGP like OSPF to help in finding out some routing decisions, available paths will be equal. ( for example, lowering the bandwidth or configuring the cost of the interface between rt2 and rt5 will trigger in proposing only one route).

The above diagram relies on both OSPF and LDP routing daemons. OSPF is used for IP discovery, while LDP will allocate labels for LSR and LER. Below is shown the aggregated LDP and OSPF configuration.

rt1

routing ospf
  router-id 5.5.5.5
  network 5.5.5.5/32 area 0
  network 6.6.6.0/24 area 0
  passive-interface loop1
  ..
  ..
routing mpls ldp
  router-id 5.5.5.5
  address-family ipv4
    discovery transport-address 5.5.5.5
    interface eth0_0
      ..
    ..
    ..
  ..
  ..
  ..
interface
  loopback loop1
    ipv4 address 5.5.5.5/32
    ..
  ..
  physical eth0_0
    ipv4 address 6.6.6.1/24
    ..
  ..

rt2

routing ospf
  router-id 9.9.9.9
  network 9.9.9.9/32 area 0
  network 8.8.8.0/24 area 0
  network 16.16.16.0/24 area 0
  passive-interface loop1
  ..
  interface eth1_0
    ip ospf cost 100
    ..
  ..
routing mpls ldp
  router-id 9.9.9.9
  address-family ipv4
    discovery transport-address 9.9.9.9
    interface eth0_0
      ..
    interface eth1_0
      ..
    ..
    ..
  ..
  ..
  ..
interface
  loopback loop1
    ipv4 address 9.9.9.9/32
    ..
  ..
  physical eth0_0
    ipv4 address 8.8.8.2/24
    ..
  ..
  physical eth1_0
    ipv4 address 16.16.16.2/24
    ..
  ..

rt3

routing ospf
  router-id 10.10.10.10
  network 10.10.10.10/32 area 0
  network 6.6.6.0/24 area 0
  network 7.7.7.0/24 area 0
  passive-interface loop1
  ..
  ..
routing mpls ldp
  router-id 10.10.10.10
  address-family ipv4
    discovery transport-address 10.10.10.10
    interface eth0_0
      ..
    interface eth1_0
      ..
    interface eth2_0
      ..
    ..
    ..
  ..
  ..
  ..
interface
  loopback loop1
    ipv4 address 10.10.10.10/32
    ..
  ..
  physical eth0_0
    ipv4 address 6.6.6.3/24
    ..
  ..
  physical eth1_0
    ipv4 address 7.7.7.3/24
    ..
  ..
  physical eth2_0
    ipv4 address 14.14.14.3/24
    ..
  ..

rt4

routing ospf
  router-id 11.11.11.11
  network 11.11.11.11/32 area 0
  network 12.12.12.0/24 area 0
  network 7.7.7.0/24 area 0
  passive-interface loop1
  ..
  ..
routing mpls ldp
  router-id 11.11.11.11
  address-family ipv4
    discovery transport-address 11.11.11.11
    interface eth0_0
      ..
    interface eth1_0
      ..
    interface eth2_0
      ..
    ..
    ..
  ..
  ..
  ..
interface
  loopback loop1
    ipv4 address 11.11.11.11/32
    ..
  ..
  physical eth0_0
    ipv4 address 8.8.8.4/24
    ..
  ..
  physical eth1_0
    ipv4 address 7.7.7.4/24
    ..
  ..
  physical eth2_0
    ipv4 address 12.12.12.4/24
    ..
  ..

rt5

routing ospf
  router-id 15.15.15.15
  network 15.15.15.15/32 area 0
  network 12.12.12.0/24 area 0
  network 16.16.16.0/24 area 0
  network 14.14.14.0/24 area 0
  passive-interface loop1
  ..
  interface eth1_0
    ip ospf cost 100
    ..
  ..
routing mpls ldp
  router-id 15.15.15.15
  address-family ipv4
    discovery transport-address 15.15.15.15
    interface eth0_0
      ..
    interface eth1_0
      ..
    interface eth2_0
      ..
    ..
    ..
  ..
  ..
  ..
interface
  loopback loop1
    ipv4 address 15.15.15.15/32
    ..
  ..
  physical eth0_0
    ipv4 address 12.12.12.5/24
    ..
  ..
  physical eth1_0
    ipv4 address 16.16.16.5/24
    ..
  ..
  physical eth2_0
    ipv4 address 14.14.14.5/24
    ..
  ..

After having executed the above configurations, the status of the LDP connections can be obtained. The peerings between the devices can be visualised with the following command:

rt3> show mpls-ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 9.9.9.9         OPERATIONAL 9.9.9.9         00:13:15
ipv4 10.10.10.10     OPERATIONAL 10.10.10.10     00:13:15
ipv4 15.15.15.15     OPERATIONAL 15.15.15.15     00:13:05

It is possible to get the whole list of bindings that LDP made, on each IP route. As LDP obtains labels for all networks, those labels are bound and installed, upon availability of associated network entries on the underlying system. The redistributed OSPF routes are then useful for that.

rt2> show mpls-ldp binding
AF   Destination          Nexthop         Local Label Remote Label  In Use
ipv4 5.5.5.5/32           11.11.11.11     22          21               yes
ipv4 6.6.6.0/24           11.11.11.11     19          18               yes
ipv4 7.7.7.0/24           11.11.11.11     16          imp-null         yes
ipv4 8.8.8.0/24           11.11.11.11     imp-null    imp-null          no
ipv4 9.9.9.9/32           11.11.11.11     imp-null    16                no
ipv4 10.10.10.10/32       11.11.11.11     20          19               yes
ipv4 11.11.11.11/32       11.11.11.11     17          imp-null         yes
ipv4 12.12.12.0/24        11.11.11.11     18          imp-null         yes
ipv4 14.14.14.0/24        11.11.11.11     21          20               yes
ipv4 15.15.15.15/32       11.11.11.11     23          22               yes
ipv4 16.16.16.0/24        11.11.11.11     imp-null    17                no

Note that some entries are not in use, since OSPF did choose to prefer rt4 link over rt5 link. Subsequently, it is also possible what are the bindings currently installed on the system:

rt2> show ipv4-routes vrf main
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

O>* 5.5.5.5/32 [110/30] via 8.8.8.4, r2-eth2, label 21, 00:22:09
O>* 6.6.6.0/24 [110/30] via 8.8.8.4, r2-eth2, label 18, 00:22:16
O>* 7.7.7.0/24 [110/20] via 8.8.8.4, r2-eth2, label implicit-null, 00:22:16
O   8.8.8.0/24 [110/10] is directly connected, r2-eth2, 00:22:17
C>* 8.8.8.0/24 is directly connected, r2-eth2, 00:23:02
O   9.9.9.9/32 [110/0] is directly connected, lo, 00:23:01
C>* 9.9.9.9/32 is directly connected, lo, 00:23:02
O>* 10.10.10.10/32 [110/20] via 8.8.8.4, r2-eth2, label 19, 00:22:16
O>* 11.11.11.11/32 [110/10] via 8.8.8.4, r2-eth2, label implicit-null, 00:22:16
O>* 12.12.12.0/24 [110/20] via 8.8.8.4, r2-eth2, label implicit-null, 00:22:16
O>* 14.14.14.0/24 [110/30] via 8.8.8.4, r2-eth2, label 20, 00:22:16
O>* 15.15.15.15/32 [110/20] via 8.8.8.4, r2-eth2, label 22, 00:22:06
O   16.16.16.0/24 [110/100] is directly connected, r2-eth3, 00:23:01
C>* 16.16.16.0/24 is directly connected, r2-eth3, 00:23:02

It is also possible to dump the contexts of the LSR. For instance, on rt3 or rt4, one can see the LFIB:

rt4> show mpls table
 Inbound                            Outbound
   Label     Type          Nexthop     Label
--------  -------  ---------------  --------
      16      LDP          8.8.8.2  implicit-null
      17      LDP      12.12.12.12  implicit-null
      17      LDP          8.8.8.2  implicit-null
      18      LDP          7.7.7.3  implicit-null
      19      LDP          7.7.7.3  implicit-null
      20      LDP      12.12.12.12  implicit-null
      20      LDP          7.7.7.3  implicit-null
      21      LDP          7.7.7.3        21
      22      LDP      12.12.12.12  implicit-null