mpls: ldp neighbor relationship with md5 password authentication – part 2

Hi again and welcome to the second part of the LDP authentication section. This time we will configure some errors to have a look on the he behaviour of the routers and what we can do to troubleshoot it.behaviour of the routers and what we can do to troubleshoot it.

Prerequisites are:
– complete configuration from part 1

Topology:

Challenges:
– debugging of a successful ldp relationship
– only one side has authentication and a password set
– look at the router without authentication
– look at the router with the authentication set

Lets start with the first challenge. Well actually not a challenge but lets just have a look at the debug of a successful handshake between two ldp neighbors.

NOTE:
First of all you have to know about the initiation itself. It is quite the same like with BGP. Because a TCP session need one that initiates the session and the other has to respond, the routers have to choose who of them will participate in which role, the “initiator” or the “responder”. For determinig which one gets the “active” role (initiator), the two routers compare their transport addresses and the one with the HIGHER address wins.

Here is the debug of the TCP session of two routers WITHOUT PASSWORDS SET, so that we can see whats interesting and important in such a session creation. We take a look at router R2 so that we can see the side that is initiating the connection.

R2#debug ip tcp trans
R2#debug ip tcp transactions
TCP special event debugging is on
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int fa0/0
R2(config-if)#no shut
R2(config-if)#
*Mar  1 04:03:46.562: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 04:03:47.562: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R2(config-if)#
R2(config-if)#
*Mar  1 04:03:49.890: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
R2(config-if)#
*Mar  1 04:04:00.106: TCB6683EEF4 created
*Mar  1 04:04:00.106: TCB6683EEF4 setting property TCP_NONBLOCKING_READ (14) 650BBCA0
*Mar  1 04:04:00.110: TCB6683EEF4 setting property TCP_NONBLOCKING_WRITE (10) 650BBCA0
*Mar  1 04:04:00.110: TCB6683EEF4 setting property TCP_TOS (11) 650BBC88
*Mar  1 04:04:00.110: TCB6683EEF4 setting property TCP_MD5KEY (5) 0
*Mar  1 04:04:00.110: TCB6683EEF4 setting property unknown (23) 650BBC90
*Mar  1 04:04:00.110: TCP: Random local port generated 62134, network 1
*Mar  1 04:04:00.114: TCB6683EEF4 bound to 2.2.2.2.62134
*Mar  1 04:04:00.114: Reserved port 62134 in Transport Port Agent for TCP IP type 1
*Mar  1 04:04:00.118: TCP: sending SYN, seq 839339414, ack 0
*Mar  1 04:04:00.118: TCP0: Connection to 1.1.1.1:646, advertising MSS 536
*Mar  1 04:04:00.118: TCP0: state was CLOSED -> SYNSENT [62134 -> 1.1.1.1(646)]
*Mar  1 04:04:00.202: TCP0: state was SYNSENT -> ESTAB [62134 -> 1.1.1.1(646)]
*Mar  1 04:04:00.202: TCP: tcb 6683EEF4 connection to 1.1.1.1:646, peer MSS 536, MSS is 536
*Mar  1 04:04:00.574: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP
R2(config-if)#

You can see that R2 creates a new TCP session called “TCB6683EEF4” and creates a local random port for the source port of the session which is bound to 2.2.2.2. This means that the Packet looks like this: 2.2.2.2:62134 -> 1.1.1.1:646. The TCP states goes from CLOSED to SYNSENT to ESTABLISHED. This means that the TCP session is up and as soon as this is the case the LDP session comes up.

On the other side this handshake looks like this:

*Mar  1 04:13:50.482: TCB670CA260 created
*Mar  1 04:13:50.482: Reserved port 646 in Transport Port Agent for TCP IP type 1
*Mar  1 04:13:50.482: TCP0: state was LISTEN -> SYNRCVD [646 -> 2.2.2.2(62134)]
*Mar  1 04:13:50.482: TCP: tcb 670CA260 connection to 2.2.2.2:31842, peer MSS 536, MSS is 516
*Mar  1 04:13:50.486: TCP: sending SYN, seq 722091001, ack 4292994790
*Mar  1 04:13:50.486: TCP0: Connection to 2.2.2.2:62134, advertising MSS 536
*Mar  1 04:13:50.694: TCP0: state was SYNRCVD -> ESTAB [646 -> 2.2.2.2(62134)]
*Mar  1 04:13:50.698: TCB670C9D04 callback, connection queue = 1
*Mar  1 04:13:50.698: TCB670C9D04 accepting 670CA260 from 2.2.2.2.31842
*Mar  1 04:13:50.698: TCB670CA260 setting property TCP_NONBLOCKING_READ (14) 66CD058C
*Mar  1 04:13:50.702: TCB670CA260 setting property TCP_NONBLOCKING_WRITE (10) 66CD058C
R1#
*Mar  1 04:13:51.102: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP

Quite the same but only in the different direction. The TCP session is caled here “TCB670CA260” and the states go from LISTEN to SYN RECEIVED to ESTABLISHED and then the session comes up.

So far so good. We will now shutdown the connection and set a PASSWORD on R1.

R1(config)#int fa0/0
R1(config-if)#shut
R1(config-if)#mpls ldp neighbor 2.2.2.2 password CISCO123
R1(config)#do clear mpls ldp neigh *
!
R2#clear mpls ldp neigh *

We will bring up the connnection again and see what happens on both routers. On R2 it is quite easy to see whats going on:

R1(config)#int fa0/0
R1(config-if)#no shut
R1(config-if)#
*Mar  1 04:18:44.022: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 04:18:44.286: TCB670CA7BC created
*Mar  1 04:18:44.286: TCB670CA7BC setting property TCP_MD5KEY (5) 66CB7DC8
*Mar  1 04:18:44.286: TCB670CA7BC setting property TCP_TOS (11) 66CB7E30
*Mar  1 04:18:44.290: TCB670CA7BC setting property unknown (23) 66CB7E40
*Mar  1 04:18:44.290: TCB670CA7BC bound to UNKNOWN.646
*Mar  1 04:18:44.290: Reserved port 646 in Transport Port Agent for TCP IP type 0
*Mar  1 04:18:44.290: TCB670CA7BC listening with queue 1
R1(config-if)#
*Mar  1 04:18:45.022: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 04:18:47.350: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
R1(config-if)#
*Mar  1 04:18:52.514: %TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(11505) to 1.1.1.1(646)
R1(config-if)#
*Mar  1 04:18:52.514: TCP0: bad seg from 2.2.2.2 -- no MD5 string: port 646 seq 1613705961 ack 0 rcvnxt 0 rcvwnd 4128 len 0
R1(config-if)#
*Mar  1 04:18:54.462: %TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(11505) to 1.1.1.1(646)
R1(config-if)#
*Mar  1 04:18:54.462: TCP0: bad seg from 2.2.2.2 -- no MD5 string: port 646 seq 1613705961 ack 0 rcvnxt 0 rcvwnd 4128 len 0
R1(config-if)#
*Mar  1 04:18:56.790: TCP0: bad seg from 2.2.2.2 -- Application closed: port 646 seq 4292994996 ack 722091216 rcvnxt 4292994996 rcvwnd 3922 len 72
*Mar  1 04:18:56.790: TCP: sending RST, seq 722091216, ack 0
*Mar  1 04:18:56.794: Released port 646 in Transport Port Agent for TCP IP type 1 delay 240000
*Mar  1 04:18:56.794: TCP0: state was FINWAIT1 -> CLOSED [646 -> 2.2.2.2(31842)]
*Mar  1 04:18:56.794: TCB 0x670CA260 destroyed
R1(config-if)#
*Mar  1 04:18:58.430: %TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(11505) to 1.1.1.1(646)
R1(config-if)#
*Mar  1 04:18:58.434: TCP0: bad seg from 2.2.2.2 -- no MD5 string: port 646 seq 1613705961 ack 0 rcvnxt 0 rcvwnd 4128 len 0

We get the message in the normal log “%TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(11505) to 1.1.1.1(646)” and in the TCP transactions debug we get “TCP0: bad seg from 2.2.2.2 — no MD5 string: port 646 seq 1613705961 ack 0 rcvnxt 0 rcvwnd 4128 len 0”, so its actually quite easy to understand whats happening. We are using an MD5 password and the other side is not using one.

Lets have a look at the other side:

*Mar  1 04:22:37.178: TCB66D5F28C created
*Mar  1 04:22:37.178: TCB66D5F28C setting property TCP_NONBLOCKING_READ (14) 650BBC58
*Mar  1 04:22:37.178: TCB66D5F28C setting property TCP_NONBLOCKING_WRITE (10) 650BBC58
*Mar  1 04:22:37.182: TCB66D5F28C setting property TCP_TOS (11) 650BBC40
*Mar  1 04:22:37.182: TCB66D5F28C setting property TCP_MD5KEY (5) 0
*Mar  1 04:22:37.182: TCB66D5F28C setting property unknown (23) 650BBC48
*Mar  1 04:22:37.182: TCP: Random local port generated 30969, network 1
*Mar  1 04:22:37.186: TCB66D5F28C bound to 2.2.2.2.30969
*Mar  1 04:22:37.186: Reserved port 30969 in Transport Port Agent for TCP IP type 1
*Mar  1 04:22:37.186: TCP: sending SYN, seq 151278571, ack 0
*Mar  1 04:22:37.190: TCP0: Connection to 1.1.1.1:646, advertising MSS 536
*Mar  1 04:22:37.190: TCP0: state was CLOSED -> SYNSENT [30969 -> 1.1.1.1(646)]
*Mar  1 04:22:39.190: 2.2.2.2:30969  1.1.1.1:646   congestion window changes
*Mar  1 04:22:39.190: cwnd from 536 to 536, ssthresh from 65535 to 1072
*Mar  1 04:22:39.194: TCP0: timeout #1 - timeout is 4000 ms, seq 151278571
*Mar  1 04:22:39.194: TCP: (30969) -> 1.1.1.1(646)
*Mar  1 04:22:43.190: TCP0: timeout #2 - timeout is 8000 ms, seq 151278571
*Mar  1 04:22:43.190: TCP: (30969) -> 1.1.1.1(646)
R2#

With the knowledge that one side is using a password and the other is not it is quite easy to understand whats going on here. R2 sends a SYN (unencrypted) but does not get a response from R1 as R1 is expecting R2 to use a MD5 password. So the TCP connection on R2 just times out.

NOTE:
If maybe R2 is under your control and R1 is not then you will get into trouble as you have no possibility to troubleshoot this. You dont get a SYN/ACK of the other router that tells you “Hey come on use MD5!”. Your session just times out. Same effect would be present if you forgot to enable LDP on the other side.

I hope this small look into the TCP debug gives you an idea where to look when the LDP connection does not come up.
Feel free to comment and to aks questions. I will try to answer them.

Regards!
Markus

Advertisements

About markus.wirth

Living near Limburg in Germany, working as a Network Engineer around Frankfurt am Main.
This entry was posted in MPLS, Uncategorized and tagged , , , , , , , , , . Bookmark the permalink.

One Response to mpls: ldp neighbor relationship with md5 password authentication – part 2

  1. prash_spa says:

    The number of LDP session established is one on Ethernet (LAN) Network when compared to the session formed using ATM interface. On ATM i/f, each individual session is formed? Why is it so

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s