You got most of it in your last statement. Yes, the advantages of MPLS are that you can place multiple customers on your network and efficiently interconnect them over your own ISP network using MPLS, and these customers can run independently and separately from each other. MPLS will run on top of a network infrastructure which requires established interconnectivity between the ISP routers, which is achieved via a routing protocol.
Rene’s lesson called Introduction to MPLS describes these advantages in more detail with examples.
An MPLS router knows that it is a Label Edge Router because it has at least one interface with MPLS enabled and at least one interface where MPLS is not enabled. Whenever traffic comes in on an MPLS enabled interface and is sent out of an interface not enabled with MPLS, then it knows to pop the label.
Step 5 states:
P3 receives the labeled packet and will pop the label, forwarding the IP packet to PE2. This is called penultimate hop popping and is performed to save PE2 the trouble of looking at the MPLS label.
So the link between P2 and P3 will have mpls ip configured, but the link between P3 and P2 wont?
I think I get it now. Similar to an OSPF router having one interface in area 1 and one in area 2, the router knows which interface is which.
If you run command show mpls interfaces, the link between P3 and P2 will not be listed.
If you run command show mpls forwarding-table on P3, it will show pop
The case you are describing in your post is penultimate hop popping (PHP), which is a function performed by Label Switch Routers (LSR) before sending the packet to an adjacent Label Edge Router (LER). PHP is achieved because the LER advertises a label with a value of 3 to its neighbors. This is called an implicit-null and it is used for the LERs to inform the LSRs to perform PHP. Rene writes more about this in this post:
I can see in some outputs the network 192.168.34.0/24 (looks like it is directly connected to R3) though this is not present on the diagram. Perhaps this needs to be removed from the outputs.
A Forwarding Equivalence Class (FEC) is a term used to describe a set of packets with similar characteristics as far as how they are forwarded is concerned. Packets that are in the same FEC are bound to the same MPLS label.
There are specific characteristics that can be used to determine the FEC of a particular packet, of which the destination IP address is almost always one of them. But there are additional characteristics including DSCP values. Packets in the same FEC use the same Label Switched Path (LSP) which is essentially the specific path that is taken by MPLS labeled packets.
Generally speaking, an FEC is a set of packets that receives the same forwarding treatment by a single LSR. For simple MPLS unicast IP forwarding, each IPv4 prefix is an FEC. For MPLS VPNs, each prefix in each VRF is an FEC—making the prefix 10.3.3.0/24 in VRF-A a different FEC from the 10.3.3.0/24 prefix in VRF-B. Alternately, with QoS implemented, one FEC might be the set of packets in VRF-A, destined to 10.3.3.0/24, with DSCP EF in the packet, and another FEC might be packets in the same VPN, to the same subnet, but with a different DSCP value.
For each FEC, each LSR needs a label, or label stack, to use when forwarding packets in that FEC. By using a unique label or set of labels for each FEC, a router has the ability to assign different forwarding details (outgoing interface and next-hop router.)
They are essentially the same thing. The LSR ID is the ID that is issued to a router to be used by MPLS to identify the router and discern it from other routers. By default it will select the highest IP address on a loopback interface. If you don’t have any loopback interfaces then it will use the highest IP address on a physical interface. This functions the same way as the router ID in OSPF or EIGRP.
Now the mpls lsd router-id is simply the command that is used to manually configure the LSR ID to a specific value rather than have it go through the procedure described above. This is best practice, as the IP addresses of interfaces can change, or in the case of a physical interface, it can go down, thus changing the router ID and causing temporary downtime.
Yes, they are essentially the same thing. The way they are referenced can vary, but in all cases the words “router ID” are there, and those are the key words. So whether you refer to it as the Label Switch Router ID or the LDP Router ID, both refer to the same thing.
I see that the labels are exchanged between routers even if we are not advertising the prefixes between them through IGP. Is that the default behavior ? If so what if R1 has full internet table and we are not advertising all of them to R2. What is the need to send the labels for each of these prefixes to R2 ?
LDP allocates a local label for every route that is learned from the IGP. By default, all labels are advertised to and learned by LDP peers. You can however change this behaviour by implementing LDP Local Label Allocation Filtering. You can find out more about this at the following Cisco documentation:
holdtime - Period of time, in milliseconds (ms), a discovered LDP neighbor is remembered without receipt of an LDP hello message from the neighbor. Peer holdtime - The time, in milliseconds (ms), that the neighbor session is retained without the receipt of an LDP message from the neighbor.
So holdtime only takes into account the “hello” message sent while the Peer holdtime only takes into account the receipt of LDP messages from the neighbor. The first has to do with remembering or maintaining the neighbor in the table, while the second has to do with maintaining the neighbor session.
So LDP won’t allocate labels for routes learned over BGP - For example R1 learns all some prefixes from R2 over ebgp and then If R1 has a ldp neighborship with R3 , won’t it advertize the labels to R3 for the prefixes it learned over ebgp from R2?
And if thats true , could you please edit this in the MPLS LDP (Label Distribution Protocol) chapter. Currently it says the below.
When we use LDP, we locally generate a label for each prefix that we can find in the RIB. This information is then added to the LIB (Label Information Base).
It would be much clearer if we say:
When we use LDP, we locally generate a label for each prefix that we can find in the RIB except BGP prefixes.