Label Distribution Protocol (LDP)
Module Introduction
Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:
student@tour:~/trainings_resources/robot$ robot mpls_ldp/mpls_ldp_setup.robot|
We use IS-IS as IGP for the examples and exercises in this module. The choice of IGP is not important for understanding and configuration of LDP. However, if you prefer to run OSPF instead, you can alternatively load the setup using the |
In order to get a better understanding, the lab setup is shown in the picture below.
LDP Overview
Label Distribution Protocol (LDP) is defined in RFC 5036 and its focus is purely on label distribution as the name implies. Thus, LDP does not perform any routing decisions and only distributes label bindings. For routing decisions, LDP relies on an link-state IGP protocol (OSPF or IS-IS) which implies that LDP cannot traverse autonomous system boundaries. LDP-signaled LSPs always follow the shortest path. A router that receives a label binding from one of its LDP peers will use a particular MPLS label for forwarding only if the LDP peer is the next hop on the shortest path to the destination. During IGP re-convergence, traffic might be blackholed or looped.
| LDP does not have any loop prevention mechanism. |
Configuring LDP Neighbors
LDP establishes LDP sessions between neighboring LSRs and uses UDP for session discovery and TCP for exchange of LDP messages. The LDP discovery mechanism sends LDP Hello messages periodically on all active interfaces using UDP port 646 to the All_Router_Multicast address (i.e., 224.0.0.2). The LDP Link Hello messages carry the LDP identifier of the label space that should be used.
|
There are two types of label spaces:
|
The LDP Identifier is a six octet number where the first four octets represent the LSR (e.g., 32-bit router ID) and the last two octets represent the label space within the LSR. The per-platform label space always set the last octet to zero, e.g., 192.168.0.1:0.
After a LDP Hello adjacency is created, a LDP session using TCP port 646 is established in order to exchange label bindings between two label spaces.
|
There is always one LDP session between two label spaces. If per-platform label space is used, there is only one LDP session between two LSRs independent of the number of links between them. However, for each link there might be a LDP Hello adjacencies. |
Configure LDP in instance default. Activate LDP on all three interfaces (hostif-0/0/1/0, hostif-0/0/2/0, and lo-0/0/0/0). Are there any LDP neighbors and LDP sessions?
Click to reveal the answer
cfg> set instance default protocol ldp router-id 192.168.0.1
cfg> set instance default protocol ldp interface hostif-0/0/1/0
cfg> set instance default protocol ldp interface hostif-0/0/2/0
cfg> set instance default protocol ldp interface lo-0/0/0/0
cfg> commitAfter configuring the LDP interfaces, we can see that there are two LDP neighbors. The exchange of Hello messages have revealed the LSP ID and the transport IP address of both neighbors:
cfg> show ldp neighbor
Instance: default
Interface/Peer LDP ID Transport IP Up Since Expires
hostif-0/0/1/0 192.168.0.2:0 192.168.0.2 Tue Apr 25 11:40:25 in 12s
hostif-0/0/2/0 192.168.0.3:0 192.168.0.3 Tue Apr 25 11:40:25 in 12sThe transport IP address is used to setup the LDP session via TCP:
cfg> show ldp session
Instance: default
LDP ID Peer IP State Up/Down FECRcvd FECSent
192.168.0.2:0 192.168.0.2 Non-Existent Never - -
192.168.0.3:0 192.168.0.3 Non-Existent Never - -Although the LDP discovery process was successful in finding LDP neighbors, the LDP session establishment failed due to missing TCP authentication which is an optional feature.
Configure for both LDP neighbors TCP session authentication with type MD5, key-id 11 and password rtbrick.
Click to reveal the answer
cfg> set instance default tcp authentication LDP
cfg> set instance default tcp authentication LDP type MD5
cfg> set instance default tcp authentication LDP key1-id 11
cfg> set instance default tcp authentication LDP key1-encrypted-text $21e4946e31b406de98b3077aef03ed5a7
cfg> set instance default protocol ldp peer ipv4 192.168.0.2 authentication-id LDP
cfg> set instance default protocol ldp peer ipv4 192.168.0.3 authentication-id LDP
cfg> commit
cfg> show ldp session
Instance: default
LDP ID Peer IP State Up/Down FECRcvd FECSent
192.168.0.2:0 192.168.0.2 Operational 0d:00h:01m:02s 7 9
192.168.0.3:0 192.168.0.3 Operational 0d:00h:01m:04s 7 9LDP Label Exchange
LDP uses a Type Length Value (TLV) format to encode information which is carried in LDP messages, e.g., the Address List TLV that contains a list of all addresses of the LSR. These addresses are compared with the next hop addresses in the unicast routing table to select the correct LSR for packet forwarding.
cfg> show ldp address instance default ipv4
Instance: default, LDP Identifier: 192.168.0.2:0, AFI: ipv4
172.16.0.2
192.168.0.2
172.16.0.13
172.16.0.25
Instance: default, LDP Identifier: 192.168.0.3:0, AFI: ipv4
192.168.0.3
172.16.0.6
172.16.0.14
172.16.0.29The LDP label mapping messages contain at least two TLVs, the FEC TLV and the Label TLV which result in a database that contains label bindings, i.e., a mapping between FECs and labels.
cfg> show ldp binding
Instance: default, AFI: ipv4
Prefix In Label Out Label LDP ID Status
192.168.0.1/32 - label:3 - Best
label:20074 - 192.168.0.2:0 Non-best
label:20072 - 192.168.0.3:0 Non-best
192.168.0.2/32 label:3 label:20004 192.168.0.2:0 Best
label:20069 - 192.168.0.3:0 Non-best
192.168.0.3/32 label:3 label:20001 192.168.0.3:0 Best
label:20066 - 192.168.0.2:0 Non-best
192.168.0.4/32 label:20066 label:20006 192.168.0.3:0 Best
label:20067 192.168.0.2:0 Best
192.168.0.5/32 label:20065 label:20005 192.168.0.2:0 Best
label:20070 - 192.168.0.3:0 Non-best
192.168.0.6/32 label:20071 label:20002 192.168.0.3:0 Best
label:20070 - 192.168.0.2:0 Non-bestBy default, RBFS only advertises label binding for loopback addresses to it’s neighbors. Some LDP implementations also advertise bindings for directly connected interfaces. If you want to have he same behavior, you need to redistribute these interfaces into LDP.
Configure LDP to redistribute all directly connected interfaces. Hint, redistribution is done on a per-address family basis.
Click to reveal the answer
cfg> set instance default protocol ldp address-family ipv4 redistribution direct
cfg> commit
cfg> show ldp binding
Instance: default, AFI: ipv4
Prefix In Label Out Label LDP ID Status
172.16.0.0/30 - label:3 - Best
172.16.0.1/32 - label:3 - Best
label:20076 - 192.168.0.3:0 Non-best
label:20069 - 192.168.0.2:0 Non-best
<...>The LDP label bindings are combined with the result of the IGP SPF calculation to create the best path to each destination:
cfg> show ldp route
Instance: default, AFI: ipv4, SAFI: labeled-unicast
Prefix/Label Advertised label Received label Next Hop Interface Metric
192.168.0.1/32 3 - - - -
192.168.0.2/32 20004 - 172.16.0.2 hostif-0/0/1/0 100
192.168.0.3/32 20001 - 172.16.0.6 hostif-0/0/2/0 100
192.168.0.4/32 20006 20067 172.16.0.2 hostif-0/0/1/0
20066 172.16.0.6 hostif-0/0/2/0 300
192.168.0.5/32 20005 20065 172.16.0.2 hostif-0/0/1/0 200
192.168.0.6/32 20002 20071 172.16.0.6 hostif-0/0/2/0 200
Instance: default, AFI: ipv6, SAFI: labeled-unicast
Prefix/Label Advertised label Received label Next Hop Interface Metric
fc00:c0a8::192:168:0:1/1283 - - - -
Instance: default, AFI: mpls, SAFI: unicast
Prefix/Label Advertised label Received label Next Hop Interface Metric
20001 - - 172.16.0.6 hostif-0/0/2/0 -
20001,bos:1 - - 172.16.0.6 hostif-0/0/2/0 -
20002 - 20071 172.16.0.6 hostif-0/0/2/0 -
20002,bos:1 - 20071 172.16.0.6 hostif-0/0/2/0 -
20004 - - 172.16.0.2 hostif-0/0/1/0 -
20004,bos:1 - - 172.16.0.2 hostif-0/0/1/0 -
20005 - 20065 172.16.0.2 hostif-0/0/1/0 -
20005,bos:1 - 20065 172.16.0.2 hostif-0/0/1/0 -
20006 - 20066 172.16.0.6 hostif-0/0/2/0
20067 172.16.0.2 hostif-0/0/1/0 -
20006,bos:1 - 20066 172.16.0.6 hostif-0/0/2/0
20067 172.16.0.2 hostif-0/0/1/0 -The resulting routes are either of type ipv4/ipv6 labeled-unicast or mpls unicast. If the device is an ingress LER, then the labeled-unicast routes are used, i.e., an IPv4 or IPV6 FEC is associated with a LDP-established LSP. In this case the label referred to as Received label is used, because this is the one learned from the downstream neighbor. The labels shown in column Advertised label are the labels allocated by the local router and advertised to its neighbors and are for information only and not relevant during ipv4/ipv6 labeled-unicast route lookup.
If the device is a transit LSR, then the mpls unicast routes are used, i.e., the incoming labeli (see column Prefix/Label) is swapped with the corrsponding label from column Received label.
The resulting entries are used to populate the routing table:
cfg> show route ipv4 labeled-unicast source ldp
Instance: default, AFI: ipv4, SAFI: labeled-unicast
Prefix/Label Source Pref Next Hop Interface Label
192.168.0.2/32 ldp 9 172.16.0.2 hostif-0/0/1/0 -
192.168.0.3/32 ldp 9 172.16.0.6 hostif-0/0/2/0 -
192.168.0.4/32 ldp 9 172.16.0.2 hostif-0/0/1/0 20067
172.16.0.6 hostif-0/0/2/0 20066
192.168.0.5/32 ldp 9 172.16.0.2 hostif-0/0/1/0 20065
192.168.0.6/32 ldp 9 172.16.0.6 hostif-0/0/2/0
cfg> show route mpls label 20002 detail
Instance: default, AFI: mpls, SAFI: unicast
20002
Source: ldp, Preference: 9
Next Hop: 172.16.0.6
Covering prefix: 172.16.0.6/32
Next Hop type: mpls transit, Next Hop action: None
Resolved in: default-ipv4-labeled-unicast
Egress interface: hostif-0/0/2/0, NextHop MAC: 7a:00:3f:c0:00:02
MPLS-Label: 20071Summary
This module outlined the operation and configuration of Label Distribution Protocol (LDP). You should be able to understand how LDP sessions are established and how LDP bindings are exchanged.
If you have completed the exercise, you can check the results by executing
student@tour:~/trainings_resources/robot$ robot mpls_ldp/mpls_ldp_verify.robot