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:
vsr running config# / vrf main interface physical eth2 port pci-b0s5
vsr running config# / vrf main routing mpls ldp router-id 5.5.5.5
vsr running config# / vrf main routing mpls ldp address-family ipv4 discovery transport-address 5.5.5.5
vsr running config# / vrf main routing mpls ldp address-family ipv4 interface eth2
Note
You can also disable LDP, either by suppressing the configuration:
vsr running config# del / vrf main routing mpls ldp
Alternatively, if you don’t want to lose the configuration, and disabling LDP configuration, you can use following command:
vsr running config# / vrf main routing mpls ldp enabled false
This method can be used if the user wants to force the reset of LDP configuration.
vsr running config# / vrf main routing mpls ldp enabled false
vsr running config# / vrf main routing mpls ldp enabled true
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
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 6.6.6.1/24
rt1 running config# / vrf main interface physical eth1 ipv6 address 600::1/64
rt1 running config# / vrf main interface loopback loop1 ipv4 address 5.5.5.5/32
rt1 running config# / vrf main interface loopback loop1 ipv6 address 5:5::5:5/128
rt1 running config# / vrf main routing static ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
rt1 running config# / vrf main routing static ipv6-route 10:10::10:10/128 next-hop 600::2
rt1 running config# / vrf main routing mpls ldp router-id 5.5.5.5
rt1 running config# / vrf main routing mpls ldp dual-stack transport-preference ipv4
rt1 running config# / vrf main routing mpls ldp address-family ipv4 discovery transport-address 5.5.5.5
rt1 running config# / vrf main routing mpls ldp address-family ipv4 interface eth1
rt1 running interface eth1# / vrf main routing mpls ldp address-family ipv6 discovery transport-address 5:5::5:5
rt1 running interface eth1# / vrf main routing mpls ldp address-family ipv6 interface eth1
rt2
rt2 running config# / vrf main interface physical eth1 port pci-b0s4
rt2 running config# / vrf main interface physical eth1 ipv4 address 6.6.6.2/24
rt2 running config# / vrf main interface physical eth1 ipv6 address 600::2/64
rt2 running config# / vrf main interface loopback loop1 ipv4 address 10.10.10.10/32
rt2 running config# / vrf main interface loopback loop1 ipv6 address 10:10::10:10/128
rt2 running config# / vrf main routing static ipv4-route 5.5.5.5/32 next-hop 6.6.6.1
rt2 running config# / vrf main routing static ipv6-route 5:5::5:5/128 next-hop 600::1
rt2 running config# / vrf main routing mpls ldp router-id 10.10.10.10
rt2 running config# / vrf main routing mpls ldp discovery hello holdtime 2
rt2 running config# / vrf main routing mpls ldp discovery hello interval 2
rt2 running config# / vrf main routing mpls ldp dual-stack transport-preference ipv4
rt2 running config# / vrf main routing mpls ldp address-family ipv4 discovery transport-address 10.10.10.10
rt2 running config# / vrf main routing mpls ldp address-family ipv4 interface eth1
rt2 running interface eth1# / vrf main routing mpls ldp address-family ipv6 discovery transport-address 10:10::10:10
rt2 running interface eth1# / vrf main routing mpls ldp address-family ipv6 interface eth1
After having executed the two configurations, the status of the LDP discovery can be obtained, by using following command:
rt1> 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:
eth1:
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::dced:1ff:fe71:ffb2
Transport address: 10:10::10:10
Hello hold time: 15 secs (due in 10 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:00:01
Also, it is possible to visualise the configured interfaces.
rt1> show mpls ldp interface
AF Interface State Uptime Hello Timers ac
ipv4 eth1 ACTIVE 00:00:22 5/15 1
ipv6 eth1 ACTIVE 00:00:21 5/15 1
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 6.6.6.0/24 10.10.10.10 imp-null imp-null no
ipv4 10.0.2.0/24 10.10.10.10 imp-null imp-null 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
ipv6 600::/64 10.10.10.10 imp-null imp-null no
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
ipv6 600::/64 10.10.10.10 imp-null imp-null no
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, N - NHRP, T - Table
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF default:
K>* 0.0.0.0/0 [0/0] via 10.0.2.2, ens3, 00:00:35
C>* 5.5.5.5/32 is directly connected, loop1, 00:00:11
C>* 6.6.6.0/24 is directly connected, eth1, 00:00:11
C>* 10.0.2.0/24 is directly connected, ens3, 00:00:35
S>* 10.10.10.10/32 [1/0] via 6.6.6.2, eth1, label implicit-null, weight 1, 00:00:10
5 routes displayed.
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,
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF default:
C>* 5:5::5:5/128 is directly connected, loop1, 00:00:13
S>* 10:10::10:10/128 [1/0] via 600::2, eth1, label implicit-null, weight 1, 00:00:12
C>* 600::/64 is directly connected, eth1, 00:00:12
C * fe80::/64 is directly connected, eth1, 00:00:12
C * fe80::/64 is directly connected, ens3, 00:00:35
C>* fe80::/64 is directly connected, fptun0, 00:04:03
4 routes displayed.
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 600::2.
rt1> show mpls table
Inbound Label Type Nexthop Outbound Label
----------------------------------------------
16 LDP 6.6.6.2 implicit-null
17 LDP 600::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
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 6.6.6.1/24
rt1 running config# / vrf main interface loopback loop1 ipv4 address 5.5.5.5/32
rt1 running config# / vrf main routing static ipv4-route 10.10.10.10/32 next-hop 6.6.6.2
rt1 running config# / vrf main routing mpls ldp router-id 5.5.5.5
rt1 running config# / vrf main routing mpls ldp dual-stack transport-preference ipv4
rt1 running config# / vrf main routing mpls ldp address-family ipv4 discovery transport-address 5.5.5.5
rt1 running config# / vrf main routing mpls ldp address-family ipv4 label local advertise explicit-null
rt1 running explicit-null# / vrf main routing mpls ldp address-family ipv4 interface eth1
rt2
rt2 running config# / vrf main interface physical eth1 port pci-b0s4
rt2 running config# / vrf main interface physical eth1 ipv4 address 6.6.6.2/24
rt2 running config# / vrf main interface loopback loop1 ipv4 address 10.10.10.10/32
rt2 running config# / vrf main routing static ipv4-route 5.5.5.5/32 next-hop 6.6.6.1
rt2 running config# / vrf main routing mpls ldp router-id 10.10.10.10
rt2 running config# / vrf main routing mpls ldp discovery hello holdtime 2
rt2 running config# / vrf main routing mpls ldp discovery hello interval 2
rt2 running config# / vrf main routing mpls ldp dual-stack transport-preference ipv4
rt2 running config# / vrf main routing mpls ldp address-family ipv4 discovery transport-address 10.10.10.10
rt2 running config# / vrf main routing mpls ldp address-family ipv4 label local advertise explicit-null
rt2 running explicit-null# / vrf main routing mpls ldp address-family ipv4 interface eth1
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 6.6.6.0/24 5.5.5.5 exp-null exp-null no
ipv4 10.0.2.0/24 5.5.5.5 exp-null exp-null no
ipv4 10.10.10.10/32 5.5.5.5 exp-null 16 no
rt2> show mpls table
Inbound Label Type Nexthop Outbound Label
--------------------------------------------------
16 LDP 6.6.6.1 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 :
vsr running config# / vrf main routing mpls ldp dual-stack cisco-interop true
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