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.
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¶
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