The above Topology is how traffic say from Customer site Looped 1 would Label Switch traffic over to Looped2 on the right hand side of the Topology, and I will review exactly how the LSR’s know where to send a packet when it arrives with a local label but multiple neighbors advertising label bindings for that same network.
Being LSP Path Selection is pretty straight forward, I’ll jump right to the forwarding tables that work together to get an IP Packet from Point A to Point B, and review all the different tables and how they relate to each other.
Apologies for the screensnips instead of CLI copy pasta output, the tables for MPLS are just all horribly formatted from CLI to this webpage, and I don’t have the bandwidth to keep trying to format them correctly so I hope the screenshots are legible.
With that, lets get started with LSP Path Selection!
I want to look at this from the perspective of router R2 in the MPLS network, as the way MPLS works, it introduces an interesting question based on how LDP shares its Labels:
Given that R1 – R5 are in one big OSPF domain, both R1 and R3 are going to have a binding for 5.5.5.5/32, and they are both going to share their own remote label binding which R2 will have in its LIB, however when an MPLS Packet shows up its only going to have its Local Binding Label 201, and it has two choices available to Label Switch the packet based on the bindings it received from LDP:
R2-P#sh mpls ldp bindings 5.5.5.5 32
lib entry: 5.5.5.5/32, rev 10
local binding: label: 201
remote binding: lsr: 1.1.1.1:0, label: 102
remote binding: lsr: 3.3.3.3:0, label: 302
R2-P#
First to coin the term for the LIB containing multiple entries to the same network, this is called “Liberal Label Retention” (LLR) which can be thought of similar to the EIGRP Topology table, as it will contain both Successor routes and Feasible Successor routes that can be injected into the IP Route table if the Success route disappears – The same is true for LLR / MPLS Bindings as shown here.
Back to the question at hand – How does R2 know which Label to Impose / Push onto this packet and which interface to forward it out of?
In determining the answer, the router goes through a list of considerations:
- Who are my LSR neighbors and what info do I have from them?
- What does my LIB have installed for this network?
- How would this packet be forwarded via IP Routing?
Again though MPLS in operation itself is basically a psuedo-layer 2.5 in operation, it does need IP Connectivity end to end for traffic to reach its destination, so even if it only had one LDP Neighbor it would still need to refer to the IP Route to confirm this destination is reachable to assign it a Label to be Label Switched.
If an MPLS Packet shows up to an LSR with an incorrect Label #, much alike an IP Packet showing up at an IP Router with an incorrect IP Address, the packet will be dropped.
How all this information comes together as show by CLI table information
Who are my neighbors?
(Good way to quickly see which LDP Router is Active / Passive)
What does my LIB have installed for this network?
How would this packet be routed via IP Routing?
To unpack the decision making process we can almost work backwards from the tables as displayed here, as R2 will note that 5.5.5.5/32 is reachable via IP at 10.23.0.3 out Interface Fa1/0 (over to R3) from the IP Routing information.
We would then actually jump up to the LDP Neighbor table, and notice that the Peer LDP Ident 3.3.3.3 (R3) owns the IP Address (is directly connected) to 10.23.0.3, and the middle “Local Binding” table shows that the “Remote Binding” Label to be imposed will be 302, and then it will be kicked out Interface Fa0/1 so that R3 can Label Switch it onward.
Label Switched Paths are a one way ticket, or Unidirectional, so there is no confusion about “Well what if 5.5.5.5 is the source?” as MPLS doesn’t care who the source is.
There are no “Source Labels” or return paths with MPLS, unless IP Routing is involved for say a ping or traceroute, traffic flows in one direction only.
Of course all of these questions are answered immediately upon exchanging labels with neighbor LSR’s, and it can be seen in the mpls forward-table here:
I have not generated any traffic since turning on the lab nodes, so 1.1.1.1 and 5.5.5.5 traffic I assume is being generated from the Layer 3 VPN configurations, which will be covered a bit further into MPLS studies.
One last note with LSP “best” path selection is that it can and will change as IP Routing changes, the return path back to the source may be different than the LSP to that destination, though with my lab there is only one path for traffic to take.
A quick side note from Keith Barker @ CBT Nuggets on Upstream vs Downstream
Keith Barker took a breather from an MPLS Fundamentals course video I was watching to clarify one point about where you are in relation to “Upstream” and “Downstream” when referring to where one device is in relation to the network.
He used the analogy of a lake with two streams, Lake 5.5.5.5, with the two streams being IP Traffic either flowing towards or away from Lake 5.5.5.5:
Its all about perspective, relation, and direction.
If we are swimming in Lake 5.5.5.5, and we need to get the R2 as indicated here, we would be swimming “Upstream” to get there. Whereas if we were in our pond R1, and wanted to swim down river to reach Lake 5.5.5.5, we would need to swim “Downstream” to get to the lake – This is kind of a silly analogy but I thought was a really good way to look at the direction of the direction traffic flows as it can get confusing when discussing it in production networks and you REALLY need to be sure of direction / flow of traffic.
So that was just a side nugget that I wanted to pass along with any readers on this page 🙂
RIB, FIB, LIB, LFIB, and CEF
It would have almost made sense to cover this first since we looked at most of this during the LSP Best Path Selection, however I’ll review it here starting with the acronyms:
- RIB = Routing Information Base
- FIB = Forwarding Information Base
- LIB = Label Information Base
- LFIB = Label Forward Information Base
- CEF = Cisco Express Forwarding (Hardware Packet Switching)
Two of these tables contain ALL forwarding information at the “Control Plane”:
RIB
This is the equivalent of EIGRP’s Topology table, it can also be viewed by de-ciphering the “sh ip ospf database” LSA’s, however this is much easier to understand and is actually exactly like the BGP “best path” table as well – All paths here show as “best” but not all of them show as “installed” in this table.
That is due to there being better paths, whether it is directly connected, an IGP with a lower AD, perhaps there is some kind of path manipulation going on (like a Route-Map advertising lower AD’s for Redistributed routes).
These “Installed” paths are part of what makes up the FIB
The FIB is the IP Route Table, it is the optimal routes to all destination networks that a router knows about, if one route becomes unavailable a less desirable route is (hopefully) waiting to be injected into the IP Route Table.
For MPLS, we first have the LIB
Even with entries of “imp-null” where this router would perform PHP to Pop the MPLS Label off the IP Packet, it contains ALL MPLS Label to IP mappings learned of from its neighbors, much alike R2 knows of several just not optimal paths to all networks.
Then there is the LFIB
This same screen snip was used above when explaining how LSP Path Selection has its optimal MPLS layer 2.5 Forwarding Table, this is it!
Then finally there is the brains of the operation that knows about Layer 3 and Layer 2 forwarding information, CEF:
This shows the Layer 3 to Egress Interface mapping, which we can do a “sh adj detail” as shown in my LDP post to get Layer 2 information, however when honing in on CEF information about specific routes it actually will also show MPLS labels associated:
As can be seen we still would need “sh adj det” for Layer 2 info, however this provides us with our Layer 3 info, as well as our Layer 2.5 MPLS info 🙂
So the RIB populates the FIB, the LIB + FIB populates the LFIB, and CEF just knows everything about all possible routing because it is that good!
That will do it for this discussion of LSP and all our different Forward tables!
I’ve watched this video in the MPLS Fundamentals series about 8 times now along with the LDP video, so I really wanted to put pen to pad and get these documented, so I have these for later reference and move onto some new videos and material.
Not sure what is up next, however I am going to let my brain defrag, and I will be back with some more MPLS fun once I am able to sit myself in front of my lab!
The DEVNET GRIND! 