In almost all cases, the CE device will be completely unaware of MPLS. This means that CE and PE communicate normally–almost always using BGP. Often times, the provider will have a VRF defined for the CE, but the CE is also unaware of this.
Hi Rene, one quick question. Don’t we have security issues when sending IP traffic between P3 and PE2? Do ISP’s have IPSEC tunnels over the penultimate hop path?
I am asking this question because, the traffic is no longer MPLS between P3 and PE2 right?
Having an MPLS label inserted into a packet doesn’t increase or decrease its security, so traffic not having the label wouldn’t be any more or less secure.
As far as traffic between P3 and PE2, if traffic is destined for PE2, and the default behavior of penultimate hop popping is enabled, then there would be not be label used for traffic between P3 and PE2. Traffic in the opposite direction, however, would be using a label imposed by PE2 before it is passed on to P3.
So the penultimate is enabled on the last hop before the PE device? What if they are multiple P hops that have routes to PE, which one will get used? Is that still based on routing or MPLS tags?
PHP (Penultimate Hop Popping) occurs one hop before the PE device yes. Your routing decides the path that is used, labels will be generated for the entries in your routing table.
If you have two equal paths then it’s possible that both P routers deliver traffic. Both will perform PHP then.
Thanks for the great lesson. Can you explain about the implicit and explicit null labels used in MPLS
These have to do with PHP (Penultimate Hop Popping).
Imagine you have a couple of routers like this:
CE1 - PE1 - P1 - P2 - PE2 - CE2
Let’s say CE1 sends an IP packet meant for CE2. What happens is that PE1 adds a label and then it gets label switched from PE1 to P1 > P2 > PE2.
To save PE2 a label lookup, we use PHP. This means that P2 will remove the label before forwarding it to PE2. This will save PE2 a label lookup.
P2 knows that it has to do PHP because PE2 will tell it to. This is done with the implicit NULL label which has a value of 3. This is the default behavior btw.
The problem with PHP is QoS…In the MPLS header, we can use the EXP bits for marking. When P2 pops the label, how does PE2 know what marking the packet should have? It doesn’t have a clue…
To prevent this from happening, we can use the explicit NULL label which has a value of 0. The PE2 will use this to signal P2 to use label value 0 where we can store the EXP bits. The label won’t be popped and PE2 will receive the marking.
Hope this helps!
Rene, they say it is not EXP field but TC now.
What do you think?
Hope you are doing great …
I have some questions …
- What is the advantage Using PHP over Ultimate HOP popping . I am facing some confusion regarding why we will use PHP.
- Suppose 3 ldp Router connected serially … R1+R2+R3 , R1 has a prefix 188.8.131.52 that tag: imp-null and advertise to R2 . R2 also created Tag :16 for 184.108.40.206 and advertise to R1, R3 . Also R3 created Tag:20 for 220.127.116.11 and advertise to R2. So, R2 got those Tags for 18.104.22.168 : 1. Tag :imp-null from R1, 2. Tag: 16 (own creation), 3. Tag:20 from R3 . So my questions is how R2 create LFIB where 3 tags available for same Prefix .
- When PE will receive regular IP packect ,then it will add Label, right ?My questions is why MPLS will kick in . It can forward packet based on IP . What is the lookup process behind this .
Hi @marcin.wielgus That is correct, officially it is called the Traffic Class Field (since 2009). For some reason, EXP bits has been stuck in most people’s minds…
Let’s look at an example of PHP first. Take a look at this picture:
In this example, P3 pops the label and forwards only the IP packet to PE2. The advantage here is that we saved a lookup for PE2. It only has to route the packet, not another lookup for the label.
Without PHP, (that’s Ultimate Hop Popping), the egress router (PE2) has to pop the label and do a lookup in the IP routing table.
PHP helps to move some of the load (label lookup / pop) from the PE2 to the P3 router. Keep in mind the PE routers have more work to do than the P routers…
About the LFIB, keep this picture in mind:
R2 will have the IP address of R1 installed as the next hop for 22.214.171.124/32, that won’t change:
R2#show ip route 126.96.36.199 Routing entry for 188.8.131.52/32 Known via "ospf 1", distance 110, metric 2, type intra area Last update from 192.168.12.1 on GigabitEthernet0/1, 00:03:17 ago Routing Descriptor Blocks: * 192.168.12.1, from 184.108.40.206, 00:03:17 ago, via GigabitEthernet0/1 Route metric is 2, traffic share count is 1
Here you can see the labels that were created/advertised:
R2#show mpls ldp bindings lib entry: 220.127.116.11/32, rev 16 local binding: label: 19 remote binding: lsr: 18.104.22.168:0, label: imp-null remote binding: lsr: 22.214.171.124:0, label: 20
And the LFIB:
R2#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 126.96.36.199/32 0 Gi0/2 192.168.23.3 17 Pop Label 188.8.131.52/32 0 Gi0/2 192.168.23.3 18 Pop Label 184.108.40.206/32 0 Gi0/1 192.168.12.1 19 Pop Label 220.127.116.11/32 0 Gi0/1 192.168.12.1
Should every route from my RIB always be replicated in my FIB? Should both of these tables always be an identical size?
Each routing protocol has its own “RIB”. The OSPF LSDB can be called the OSPF RIB and the EIGRP topology table is the EIGRP RIB.
The routing table can be considered the “main” RIB of the router.
The FIB is your forwarding table, on Cisco routers, this is the CEF table. It doesn’t only contain L3 information like the RIB does but also L2 information (needed to reach the next hop).
Here’s the main RIB of a router:
R1#show ip route 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.12.0/24 is directly connected, GigabitEthernet0/1 L 192.168.12.1/32 is directly connected, GigabitEthernet0/1
It only has directly connected subnets. Here is the CEF table of this router:
R1#show ip cef Prefix Next Hop Interface 0.0.0.0/0 no route 0.0.0.0/8 drop 0.0.0.0/32 receive 127.0.0.0/8 drop 192.168.12.0/24 attached GigabitEthernet0/1 192.168.12.0/32 receive GigabitEthernet0/1 192.168.12.1/32 receive GigabitEthernet0/1 192.168.12.2/32 attached GigabitEthernet0/1 192.168.12.255/32 receive GigabitEthernet0/1 18.104.22.168/4 drop 22.214.171.124/24 receive 240.0.0.0/4 drop 255.255.255.255/32 receive
As you can see, there are some additional entries here (for example, 126.96.36.199/4 for multicast traffic). This router knows how to reach 192.168.12.2, a host on the 192.168.12.0/24 subnet:
R1#show ip cef 192.168.12.0 255.255.255.0 longer-prefixes Prefix Next Hop Interface 192.168.12.1/32 receive GigabitEthernet0/1 192.168.12.0/32 receive GigabitEthernet0/1 192.168.12.255/32 receive GigabitEthernet0/1 192.168.12.2/32 attached GigabitEthernet0/1
Here you can see the IP address and the interface, but there’s more. The MAC address to reach 192.168.12.2 is in the ARP table:
R1#show ip arp 192.168.12.2 Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.12.2 46 fa16.3ec1.417c ARPA GigabitEthernet0/1
The FIB also has a section where L2 information is stored, the adjacency table:
R1#show adjacency 192.168.12.2 detail Protocol Interface Address IP GigabitEthernet0/1 192.168.12.2(7) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 0 Encap length 14 FA163EC1417CFA163E7A27560800 ARP
Above you can see the IP, interface, and the MAC address (FA163EC1417C).
To answer your question, the routes from the main RIB are copied to the FIB but the FIB has additional information that is needed for forwarding (like the L2 information).
I hope this helps!
That’s a great answer - thank you!
Seems strange that we need two separate commands for the FIB - ‘show cef’ and ‘show adjacency.’
I guess there isn’t one command which encompasses both?
You are welcome =)
I don’t think there is a command that shows you everything in one go. It’s probably because the adjacency and FIB table are really two seperate tables.
Question about PHP
- Would you describe it as the top label or bottom label that gets removed?
- In the case of MPLS VPN, there are 2 labels. Are both removed?
In PHP, it is more appropriate to refer to the outer and inner label, although the top and bottom labels are also used as terminology. The top label is the outer and the bottom is the inner. So in PHP, it is the outer label that is removed by the Label Switch Router (LSR) before the packet is passed to the adjacent Label Edge Router (LER).
In the case of MPLS VPN, a packet consists of two labels, the inner one is the VPN label and the outer one is the common MPLS label. So when PHP will be performed by an LSR it will remove only the outer label. The LER will then pop the VPN label before sending it to the CPE.
I hope this has been helpful!
Hi,hope you are doing great.
I have doubt on mpls implicit null label.
Is this label used only when we are using rsvp ?and how we use explicit null ?
If implicit null provides the indication to do the pop operations,then what is the function of s bit in MPLS? I am confused.please explain.
The implicit null label is not used only for RSVP but more generally used to eliminate double lookups. This excerpt from Cisco documentation describes it quite well:
The implicit NULL label is the label that has a value of 3. An egress LSR assigns the implicit NULL label to a FEC if it does not want to assign a label to that FEC, thus requesting the upstream LSR to perform a pop operation. In the case of a plain IPv4-over-MPLS network, such as an IPv4 network in which LDP distributes labels between the LSRs, the egress LSR—running Cisco IOS—assigns the implicit NULL label to its connected and summarized prefixes. The benefit of this is that if the egress LSR were to assign a label for these FECs, it would receive the packets with one label on top of it. It would then have to do two lookups. First, it would have to look up the label in the LFIB, just to figure out that the label needs to be removed; then it would have to perform an IP lookup. These are two lookups, and the first is unnecessary.
The solution for this double lookup is to have the egress LSR signal the last but one (or penultimate) LSR in the label switched path (LSP) to send the packets without a label. The egress LSR signals the penultimate LSR to use implicit NULL by not sending a regular label, but by sending the special label with value 3. The result is that the egress LSR receives an IP packet and only needs to perform an IP lookup to be able to forward the packet. This enhances the performance on the egress LSR.
The use of implicit NULL at the end of an LSP is called penultimate hop popping (PHP). The figure below show this penultimate hop popping.
This was taken from the following Cisco documentation:
Now the S bit is used not for penultimate hop popping, but to indicate that the label in question is indeed the bottom and final label.
I hope this has been helpful!