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 rt3 configurations.
The basic neighbour discovery mechanism is used to make the peering work.
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.3
ipv6-route 10:10::10:10/128 next-hop 6000::3
..
..
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
..
..
rt3
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.3/24
ipv6 address 6000::3/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.3
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. local bindings are not installed to the underlying system.
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
Among the two remaining entries with the In Use Column, only the Remote Label
is of interest for local traffic, since this will be the label to be used when
forging IP traffic to reach the remote destination. The routing table of the
system shows the following:
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,
> - selected route, * - FIB route
[...]
S>* 10.10.10.10/32 [1/0] via 6.6.6.3, 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,
> - selected route, * - FIB route
[...]
S>* 10:10::10:10/128 [1/0] via 6000::3, eth0_0, label implicit-null, 00:08:19
LDP Disabling PHP¶
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.
vrf main
routing mpls ldp
router-id 10.10.10.10
address-family ipv4
discovery transport-address 5.5.5.5
label local advertise explicit-null
interface eth0_0
..
..
..
..
..
..
routing static
ipv4-route 11.11.11.11/32 next-hop 10.125.0.2
..
..
interface
loopback loop1
ipv4 address 10.10.10.10/32
..
physical eth0_0
port pci-b0s6
ipv4 address 10.125.0.1/24
..
..
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 10.10.10.10/32 10.10.10.10 16 exp-null yes
ipv4 10.125.0.0/24 10.10.10.10 exp-null exp-null no
ipv4 11.11.11.11/32 10.10.10.10 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,
> - selected route, * - FIB 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