Thanks for your post on the site!! I am not able however to find the configurations you are referring to in this particular lesson. Could it be that you are referring to another lesson? Take a look, and if so, let us know the lesson so that we can help you further, and correct any omissions that may be on the lessons…
VPN labels are exchanged between PE routers using MP-BGP. However, this in itself is not enough to get an MPLS/VPN topology working. Although MP-BGP is enough to exchange labels, you still need to determine a Label Switched Path (LSP) to route those labels through the topology. MPLS is still necessary for this. You can find out more about this in detail at the following Cisco community thread:
The thread is quite old, but it is still valid.
It would be helpful if you let us know what it is that you want to achieve. Is there something specific that you need to do? If you let us know, we may be able to help you further.
Why is the holdtime from sh mpls ldp neighbor detail is showing infinite.
R1 is configured with static targeted LDP session.
But, if I look from the passive LDP neighbor side, the holdtime is showing 90 seconds.
There’s a good chance that the specific router is configured using MPLS LDP Session Protection. This is a feature that uses targeted hellos to protect LDP sessions. This is explained well in the following Cisco documentation:
Although the targeted hello timer is set to the default of 90 seconds (which is what you see in the LDP parameters output), protection is set up so that this becomes infinite, and that is what you see in the output of the show mpls ldp neighbor detail command.
MPSL labels are not locally significant, because they are shared and used by neighboring routers. They are however locally generated. What does that mean? Well, R1 will look at all the prefixes it has in the routing table and will assign a label to each. That label is generated by R1 without any external influence. However, that label and its associated prefix are shared with its neighbors. That means that if neighbor R2 wants to send a packet to a destination of 126.96.36.199/24 which is a prefix shared by R1, R2 must use the label value advertised by R1 of that particular destination to route it.
For each label mapping, you can see the prefix being shared under the FEC → FEC Elements section of the label mapping message, but you won’t be able to see the actual label because they are encoded as type length values (TLVs).
in your conclusion you said “First we send UDP multicast hello packets to discover other neighbors. Once two routers decide to become neighbors, they build the neighbor adjacency using a TCP connection”
However you mentioned comms is formed using udp 646 at the begining. Which is correct?
The hello packets are indeed sent to the 188.8.131.52 multicast address using UDP as the transport layer protocol with a port of 646. Within the hello packet, there is an IPv4 Transport Address TLV. This value is the IP address that is to be used by the router to establish a TCP connection with its neighbor. Once the hello packet is received, the routers create a TCP connection using that IP address.
So the UDP multicast hello using port 646 is just for the hello. Once that’s done, a TCP session is established for all subsequent neighbor communications. Does that make sense?
Typically, the reason for not using LDP for BGP prefixes is due to the use of BGP itself for label distribution in MPLS networks, more specifically through an extension of BGP known as Multiprotocol BGP or MP-BGP.
MP-BGP is used when MPLS is employed over BGP because it supports multiple network layer protocols, not just IPv4. This includes the distribution of label information using BGP NLRIs.
For the specific case of VPNs, BGP is used to distribute VPN label information between PE routers, enabling MPLS VPN services over BGP.
The key reason behind this is control and flexibility. BGP allows more control over path selection based on policy (as opposed to just shortest-path), and allows the network to scale to larger sizes. When running MPLS in conjunction with BGP, network engineers have greater flexibility and control over traffic engineering, quality of service, and other advanced features. BGP also allows for complex scenarios like inter-AS MPLS VPNs.
So to conclude, labels aren’t generated for BGP prefixes with LDP because BGP itself (more specifically, MP-BGP) is used to handle label distribution for these prefixes. Does that make sense?
I have three short questions when it comes to LDP. Why does LDP specifically prefer a loopback interface IP over a physical interface? This isn’t like BGP where we can form a remote adjacency, wouldn’t most LDP routers be directly connected?
When it comes to these LDP packets, why are apart from the prefixes and the labels the local router associated with them also included the IP addresses of the interfaces?
Where in the LDP packet does a PE router indicate that the P router should perform PHP? I didn’t find that anywhere.
LDP prefers a loopback interface IP over a physical interface IP for stability reasons. In a typical network, physical interfaces can go down due to various reasons (cable issues, hardware failure, etc.), but a loopback interface is a virtual interface that is always up unless it is manually shut down. Since LDP sessions are tied to the router ID, using a loopback interface ensures that the LDP session remains stable even if a physical interface goes down. However, it is possible to change the source of LDP sessions if you have a specific requirement or reason for that.
You can explicitly configure the interface that LDP should use as its source for establishing sessions. On a Cisco IOS device, you’d use the following command in global configuration mode:
The above commandwould make the Gi0/0 interface the source and destination for its the exchange of LDP messages with neighbors.
If I’m not mistaken, you’re asking why the IP addresses of the local router are included in the LDP message as shown in your wireshark capture. Well, the IP addresses of the interfaces are included in the LDP packets to identify the source of the LDP labels. This is important in MPLS networks where multiple LDP sessions may exist between routers. The receiving router needs to know which interface the LDP label came from to correctly forward traffic.
The PHP is not directly indicated in the LDP packets. PHP is a function performed by the P router just before the egress PE router in an MPLS network. The P router removes the MPLS label before forwarding the packet to the PE router. This is done to reduce the load on the PE router. The decision to perform PHP is typically based on the configuration of the P and PE routers and not indicated in the LDP packets.