Today a simple but sometimes time consuming topic, when it comes to troubleshooting. MPLS LDP neighbor relationships with password authentication.
So we have quite a simple topology. Lets only use two neighboring routers because usually LDP is only used between to neighbors to exchange MPLS labels.
Here is the topology:
– Configure two routers to establish a LDP session between each other and use password authentication.
Well we start from theground up. So we are putting the two neihgboring interfaces online and configure an ip address.
R1(config)#int fa0/0 R1(config-if)#ip add 172.16.21.1 255.255.255.252 R1(config-if)#no shut ! R2(config)#int fa0/0 R2(config-if)#ip add 172.16.21.2 255.255.255.252 R2(config-if)#no shut
Then for getting LDP to work we need to establish a TCP connection between those two devices on port 646. So as the two routers are neighboring and there is no device inbetween that could prevent them from doing this, we just need to activate mpls on the interfaces.
R1(config-if)#mpls label protocol ldp R1(config-if)#mpls ip ! R2(config-if)#mpls label prot ldp R2(config-if)#mpls ip
Then we should see the session come up.
*Mar 1 00:24:28.567: %LDP-5-NBRCHG: LDP Neighbor 172.16.21.2:0 (1) is UP
When two routers are forming a LDP neighbor relationship, then you MUST BE SURE that the routers can reach each others MPLS LDP router-id. If this is not the case then the relationship will not form. Lets have a look at the current router-id.
R1#sh mpls ldp neigh Peer LDP Ident: 172.16.21.2:0; Local LDP Ident 172.16.21.1:0 TCP connection: 172.16.21.2.64452 - 172.16.21.1.646 State: Oper; Msgs sent/rcvd: 4/4; Downstream Up time: 00:00:29 LDP discovery sources: FastEthernet0/0, Src IP addr: 172.16.21.2 Addresses bound to peer LDP Ident: 172.16.21.2
Here you can see the local used router-id “aka LDP ident”. Of course R1 reaches R2´s router-id-address because they are directly connected. Lets change the router-ids and create some loopback interfaces.
R1(config)#int lo0 R1(config-if)#ip address 126.96.36.199 255.255.255.255 R1(config-if)#exit R1(config)#mpls ldp router-id lo0 force ! R2(config)#int lo0 R2(config-if)#ip address 188.8.131.52 255.255.255.255 R2(config-if)#exit R2(config)#mpls ldp router-id lo0 force
Lets see what happens.
*Mar 1 00:26:35.783: %LDP-5-NBRCHG: LDP Neighbor 172.16.21.1:0 (1) is DOWN (TCP connection closed by peer)
Well on both routers we get messages that the LDP relationship is down. That is because the TCP session of LDP on port 646 is sourced by the router-id-interface which is loopback0 of both routers. And as both routers dont know a way back to the opposite loopback address (we did not configure a routing protocol)…
R1#sh ip route 184.108.40.206 % Network not in table ! R2#sh ip route 220.127.116.11 % Network not in table
…we cannot get it to work. What we need to do is to let the routers know about the other loopback address or “ldp router-id” respectively. Lets do it the quick way and enable ospf everywhere.
R1(config)#router ospf 1 R1(config-router)#network 0.0.0.0 255.255.255.255 are 0 !
R2(config)#router ospf 1 R2(config-router)#network 0.0.0.0 255.255.255.255 are 0
Lets check the routing tables.
*Mar 1 00:33:04.067: %OSPF-5-ADJCHG: Process 1, Nbr 18.104.22.168 on FastEthernet0/0 from LOADING to FULL, Loading Done R1#sh ip route 22.214.171.124 Routing entry for 126.96.36.199/32 Known via "ospf 1", distance 110, metric 11, type intra area Last update from 172.16.21.2 on FastEthernet0/0, 00:00:02 ago Routing Descriptor Blocks: * 172.16.21.2, from 188.8.131.52, 00:00:02 ago, via FastEthernet0/0 Route metric is 11, traffic share count is 1 ! R2#sh ip route 184.108.40.206 Routing entry for 220.127.116.11/32 Known via "ospf 1", distance 110, metric 11, type intra area Last update from 172.16.21.1 on FastEthernet0/0, 00:00:36 ago Routing Descriptor Blocks: * 172.16.21.1, from 18.104.22.168, 00:00:36 ago, via FastEthernet0/0 Route metric is 11, traffic share count is 1
And almost directly after OSPF has converged we get our message that LDP has succeeded.
R1# *Mar 1 00:33:09.599: %LDP-5-NBRCHG: LDP Neighbor 22.214.171.124:0 (1) is UP ! R2# *Mar 1 00:33:00.739: %LDP-5-NBRCHG: LDP Neighbor 126.96.36.199:0 (1) is UP
Ok so far so good. Then lets do some authentication here. We will use the password “cisco” to authenticate both machines to each other.
When configuring the neighbor authentication with LDP you need to specify the neighboring router-id address, not the interface address you are neighboring to!
AND as soon as you configure a password the session will be cleared, so pay attention when you are in a production network and take a maintenance outage window.
R1(config)#mpls ldp neighbor 188.8.131.52 password CISCO123 R1(config)# *Mar 1 00:36:36.887: %LDP-5-NBRCHG: LDP Neighbor 184.108.40.206:0 (1) is DOWN (Session's MD5 password changed) ! R2(config)#mpls ldp neighbor 220.127.116.11 password CISCO123 R2(config)# *Mar 1 00:37:30.939: %LDP-5-NBRCHG: LDP Neighbor 18.104.22.168:0 (1) is UP
As soon as both machines are properly configured, the LDP session is back again!
I hope you enjoyed it.
Check out part 2, where I will show you some debugs and some troubleshooting action with LDP in combination with passwords.
Feel free to comment!