The main point above I didn’t illustrate real well is R3 has a new loopback9 Interface with 9.9.9.9/32 that is NOT in the OSPFv2 Domain, so its fellow R2 and R4 will not be able to reach it.
Honestly I don’t plan to spend a lot of time on this topic (famous last words), as this is a very straight forward concept, however it does underscore an important topic to take note even if not studying for or worth with MPLS.
First lets take a look at LDP Router-ID, and the LDP Transport Address
First and foremost, across any platform vendor around (Cisco included), the “Transport Address” significance is that this IP Address is used in keep the LDP Session alive on the TCP Port 646 and random high Port # on the Active router.
That is a pretty big responsibility to keep LDP Adjecencies up, so Transport Addresses only purpose (that I am aware of at this point), is to keep that LDP Session alive!
Router-ID’s (and LDP is no different) will use the RID in the following order:
- Hard coded Router-ID
- Highest Loopback Interface IPv4 Address
- Highest Interface IPv6 Address
Had cording a RID always takes precedence over router IP Addresses, despite them needing to be in IPv4 Address format, which I find kind of funny.
If your device is running pure IPv6 and there is absolutely no IPv4 addressing on the node, the only way to get a RID is to hard code it, as RID’s can only be IPv4 addresses!
LDP Router-ID works the same way, as demonstrated within Wireshark Packet captures in my LDP post, the Transport Address matched the Loopback Addresses, and that is because Transport Addresses will match the LDP Router-ID unless hard coded not to!
To demonstrate this anarchy, I will now configure what wrote up in this Topology:
Note that Lo9 9.9.9.9/32 has the highest Loopback IP of all 3 routers now, and is not participating in OSPF, so this is really going to sour some grapes in the network!
Before ( “sh mpls ldp neighbor detail” )
After!
R3-P(config)#no mpls ip
R3-P(config)#
*Nov 25 02:15:14.441: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (2) is DOWN (LDP unconfigured globally)
*Nov 25 02:15:14.449: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is DOWN (LDP unconfigured globally)
R3-P(config)#mpls ip
R3-P(config)#
*Nov 25 02:15:18.681: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (3) is UP
*Nov 25 02:15:18.849: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (4) is UP
*Nov 25 02:15:19.049: %LDPLIB-5-RELLABEL: 4.4.4.4/32, peer 4.4.4.4:0; label 300; Unexpected LDP label release; specified label not in TIB
R3-P(config)#
I didn’t really expect those to form actually, but that last error, LDP Label release? :
R3-P(config)#do sh mpls ldp binding 5.5.5.5 32
lib entry: 5.5.5.5/32, rev 10
local binding: label: 309
remote binding: lsr: 2.2.2.2:0, label: 209
remote binding: lsr: 4.4.4.4:0, label: 402
R3-P(config)#
Ahhh yes, if you want to switch your labels around in your lab, do a few quick disable / re-enables on your MPLS LSR’s globally, and it will re-label routes dynamically so your not staring at the same ones the entire course. However, I digress, as usual.
Why is LDP still working?
Ahh yes, I forgot to apply the command that forces an interface to be either a Router-ID interface, and another be a Transport Address Interface!
Check it out:
R3-P(config)#
R3-P(config)#mpls ldp router-id lo9 force
R3-P(config)#
*Nov 25 02:26:49.893: %LDP-5-INFO: default: LDP ID removed
*Nov 25 02:26:49.905: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is DOWN (LDP Router ID changed)
*Nov 25 02:26:49.909: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (2) is DOWN (LDP Router ID changed)
R3-P(config)#
To take a look at this one more in our LDP Neighbor Discovery detail:
Note the LDP Router-ID and Transport Address is both 9.9.9.9, which is a problem because R2 and R4 cannot reach 9.9.9.9 as it is not being propagated via OSPF, or we would need some static routes to assist with the issue.
However the Transport Addresses can be changed and the RID left the same!
Think about that for a minute:
If we can successfully change the Transport Address required to build and maintain that LDP Session, but keep the higher # LDP Router-ID on R3, we are essentially “Engineering the Network” by making R3 the “LDP Alive” router sending all LDP Sessions to remote routers TCP Port 646!
Before we get too far though, I wanted to take a look at some tables around the network to see how sad things are looking, again always using 5.5.5.5/32 as an exmaple:
Traceroute from R1 1.1.1.1/32 to R5 5.5.5.5/32
R1-PE#traceroute 5.5.5.5 source 1.1.1.1
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 10.12.0.2 [MPLS: Label 209 Exp 0] 40 msec 52 msec 56 msec
2 10.23.0.3 52 msec 52 msec 48 msec
3 10.34.0.4 68 msec 52 msec 80 msec
4 10.45.0.5 68 msec * 68 msec
R1-PE#
Because R1 and R2 are still LDP buddies they exchanged their remote bindings, but because R3 has LDP Down currently, no routers will form an Adjacency because they just cannot reach that Router-ID Loopback Address of 9.9.9.9/32!
Lets check out R2 and his label mapping situation going to 5.5.5.5/32 specifically:
R2 Label Bindings / CEF / LFIB
R2-P#sh mpls ldp binding 5.5.5.5 32
lib entry: 5.5.5.5/32, rev 10
local binding: label: 209
remote binding: lsr: 1.1.1.1:0, label: 102
R2-P#sh ip cef 5.5.5.5
5.5.5.5/32
nexthop 10.23.0.3 FastEthernet1/0
R2-P#
Outgoing Label = No Label which is not the same as PHP or Penultimate Hop Popping the MPLS Label off, it just has literally “No Label” to impose before sending to R3 so it sends the packet “naked” or “native” in IPv4 which is how it get routs the rest of the way.
Back to the inner MPLS Engineers within us to finish our task!
That task being configuring working and reachable Transport Addresses, but keeping the Router-ID of 9.9.9.9 on via Lo9 on R3 so we know it sends TCP Port 646 sessions to all other LDP Neigbors directly attached to its Ethernet interfaces!
This is a very long winded command done at the MPLS Enabled interface level:
R3-P(config)#int fa2/0
R3-P(config-if)#mpls ldp discovery transport-address interface
R3-P(config-if)#int fa1/0
R3-P(config-if)#mpls ldp discovery transport-address interface
R3-P(config-if)#
*Nov 25 02:47:54.053: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is UP
R3-P(config-if)#
*Nov 25 02:47:56.657: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (2) is UP
R3-P(config-if)#
Not my idea, I think it could have been a bit shorter, but who am I to tell cisco developers how to structure their commands 🙂
Now to look at this again from our “sh ldp disc det” :
No each physical interface is the “Transport Address” to handle LDP Session traffic, and R3 now is the Active LDP router for both these LSR Neighbors, because it still has the highest # Loopback Address of the 3 routers!
That wrap up this discussion of LDP RIDs and Transport Addresses for MPLS
Any deeper than that is really wading into CCNP Service Provider waters that I do not intend to, there is only for a fundamental MPLS understanding of Network Engineers!
Until next time!
The DEVNET GRIND! 