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…
Hi @Zaman.rubd
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:
https://networklessons.com/wp-content/uploads/2015/08/mpls-lib-lfib.png
R2 will have the IP address of R1 installed as the next hop for 1.1.1.1/32, that won’t change:
R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/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 11.11.11.11, 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: 1.1.1.1/32, rev 16
local binding: label: 19
remote binding: lsr: 11.11.11.11:0, label: imp-null
remote binding: lsr: 33.33.33.33: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 33.33.33.33/32 0 Gi0/2 192.168.23.3
17 Pop Label 3.3.3.3/32 0 Gi0/2 192.168.23.3
18 Pop Label 11.11.11.11/32 0 Gi0/1 192.168.12.1
19 Pop Label 1.1.1.1/32 0 Gi0/1 192.168.12.1
Rene
Hi Guys,
Should every route from my RIB always be replicated in my FIB? Should both of these tables always be an identical size?
Thanks,
Gareth.
Hi Gareth,
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
224.0.0.0/4 drop
224.0.0.0/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, 224.0.0.0/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!
Rene
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?
Thanks
Hello Chris
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!
Laz
1 Like
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.
Hello Subhajit
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!
Laz
Hi Laz ,
Quick question
who will distribute the VPN labels ? LDP does for outer or transport label only
Hello Tanmoy
The distribution of the VPN labels is done by MP-BGP. VPN labels are propagated in the MP-BGP VPNv4 routing updates.
I hope this has been helpful!
Laz
Hi Laz ,
Yes … MP-BGP does this by assigning VPNV4 address family.
I have one more question
what is the role of route reflector , how this can be utilized in SP’s Network ?
Thanks
Hello Tanmoy
The Route Reflector (RR) used in MP-BGP within an ISP’s MPLS network is used in a similar way to it’s purpose within a regular BGP AS. Within an AS, iBGP requires that all iBGP routers have full mesh neighbor adjacencies. This means that in an AS with, say, 10 iBGP speakers, we’ll need N(N-1)/2 or 10*(10-1)/2 = 45 adjacencies. As AS networks increase, these adjacencies increase in number almost exponentially, which is a problem for scalability. The solution for this is an RR. The RR will collect all of the information about routes from all routers, and share this information with all the BGP routers in the AS. Although the mechanisms are different, the principle is similar to that of a DR for a network segment of an OSPF network. More information about RRs can be found at this lesson:
Although the above lesson focuses on conventional BGP AS’es, the principle is the same when applied to MP-BGP within an MPLS network.
I hope this has been helpful!
Laz
Hi Lazaros, in your drawing, you show the edge router as “Egress LSR”. Is this the same thing as the LER? If not, how does the LER differ from the Egress LSR?
Thanks,
Buck
Hello Buck
Unfortunately, terminology is not always kept constant across documentation. In this case, the term Ingress/Egress LSR in the Cisco documentation is used to refer to the PE routers, also commonly referred to as LERs. So Egress and Ingress LSR is the same as LER.
In context, you can see that the Ingress and Egress LSRs are those routers that “ingress” traffic into, and “egress” traffic out of the MPLS network, which in Rene’s lessons are referred to as LERs or PEs.
Sometimes you just have to look at the context to get a clear idea of what is being described.
I hope this has been helpful!
Laz
while am reading above topic i found a repeated word you have typed the pronoun “you” twice as below:
note: you can delete the post once you see it … thnx
Hello Ziad
Thanks for pointing that out, I will let Rene know to make the fix…
Laz
Hello Ziad
Thanks for pointing this out and for contributing to making this site even better! I’ll let Rene know…
Laz