Solved: MPLS LDP - NSR N/A

Pedro Morais · ‎01-04-2013

Hello all,

After upgrading an ASR9K from 4.0.1 to 4.2.3 I noticed that NSR didn't came up, showing N/A in the output of "sh mpls ldp neighbor brief":

RP/0/RSP0/CPU0:A9K-LAB01#sh mpls ldp neighbor brief

Fri Jan 4 14:19:52.393 WET

Peer GR NSR Up Time Discovery Address IPv4 Label

----------------- -- --- ---------- --------- ------- ----------

172.25.200.7:0 Y Y 6w2d 2 3 10 <- IOS

172.25.200.2:0 Y Y 3w4d 3 12 10 <- IOS

172.25.200.10:0 Y Y 2w0d 2 4 31 <- IOS-XR 4.0.1

172.25.200.11:0 Y N/A 20:55:55 1 4 31 <- IOS-XR 4.2.3

172.25.200.6:0 Y N/A 02:08:11 1 7 31 <- IOS-XR 4.2.3

172.25.200.15:0 Y N/A 00:12:37 2 3 31 <- IOS-XR 4.2.3

Routers have connectivity to each other, and configurations are pretty much the same in all of them:

RP/0/RSP0/CPU0:A9K-LAB01#sh run mpls ldp

Fri Jan 4 15:45:12.164 WET

mpls ldp

router-id 172.25.200.5

discovery hello holdtime 45

discovery hello interval 15

nsr

graceful-restart

backoff 5 10

holdtime 80

session protection

neighbor 172.25.200.2 password encrypted

neighbor 172.25.200.7 password encrypted

neighbor 172.25.200.10 password encrypted

neighbor 172.25.200.15 password encrypted

igp sync delay 10

label

allocate for LLAF

!

log

neighbor

graceful-restart

session-protection

nsr

!

interface GigabitEthernet0/4/0/0.2

!

interface TenGigE0/0/0/1.2

!

interface TenGigE0/0/0/2.2

!

interface TenGigE0/1/0/0.2

!

interface TenGigE0/1/0/1.2

!

RP/0/RSP0/CPU0:A9K-LAB01#

When debugging "mpls ldp nsr" in 4.2.3 I don't see any event, however in 4.0.1 I can see all the events. Anyone could help me to go further in my troubleshooting?

Thanks,

Pedro

Alexei Kiritchenko · ‎01-04-2013

Hello Pedro,

may you look at show mpls ldp neighbour output and verify if these are targeted LDP sessions?

NSR on targeted LDP is supported from 4.3.0.

Regards,

/A

View solution in original post

Alexei Kiritchenko · ‎01-04-2013

Hello Pedro,

may you look at show mpls ldp neighbour output and verify if these are targeted LDP sessions?

NSR on targeted LDP is supported from 4.3.0.

Regards,

/A

Pedro Morais · ‎01-07-2013

Thx Alexei,

Yes, I'm aware of that detail, however this are directly connected routers.

Any other idea?

Regards,

Pedro

Alexei Kiritchenko · ‎01-07-2013

Hi Pedro,

Do you have l2vpn between these directly connected rotuers for example? If so, then even on these directly connected links we run targeted ldp and hence no NSR.

Here is the example from my lab on a directly connected link:

RP/0/RSP0/CPU0:sisters#show mpls ldp neighbor brief

Mon Jan 7 13:55:10.143 CET

Peer GR NSR Up Time Discovery Address IPv4 Label

----------------- -- --- ---------- --------- ------- ----------

138.187.93.66:0 Y N/A 1w5d 2 25 89

10.0.1.25:0 Y Y 4d02h 2 24 81

RP/0/RSP0/CPU0:sisters#show mpls ldp neighbor 138.187.93.66

Mon Jan 7 13:55:29.449 CET

Peer LDP Identifier: 138.187.93.66:0

TCP connection: 138.187.93.66:49647 - 138.187.93.64:646

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)

Session Holdtime: 180 sec

State: Oper; Msgs sent/rcvd: 20234/20274; Downstream-Unsolicited

Up time: 1w5d

LDP Discovery Sources:

TenGigE0/2/0/0

Targeted Hello (138.187.93.64 -> 138.187.93.66, active)

RP/0/RSP0/CPU0:sisters#show running-config l2vpn

Mon Jan 7 13:55:42.462 CET

l2vpn

!

xconnect group XX

p2p YY

interface Bundle-Ether9400.91040

neighbor 138.187.93.66 pw-id 901040

!

Regards,

/A

Pedro Morais · ‎01-07-2013

Hi Alexei,

Yes, we do have L2 VPNs between those routers. Also, I checked the output of "show mpls ldp neighbor" and targeted ldp is running in all of them. That is what got me confused. I believe that we might be facing any kind of cosmetic bug in the routers running 4.0.1...

RP/0/RSP0/CPU0:A9K-LAB01#sh mpls ldp neighbor brief

Mon Jan 7 15:02:07.376 WET

Peer GR NSR Up Time Discovery Address IPv4 Label

----------------- -- --- ---------- --------- ------- ----------

172.25.200.11:0 Y N/A 2d23h 1 4 31

172.25.200.2:0 Y Y 2d23h 3 12 10

172.25.200.7:0 Y Y 2d23h 2 3 10

172.25.200.10:0 Y Y 2d23h 2 4 31 <- 4.0.1

172.25.200.6:0 Y N/A 2d20h 1 7 31 <- 4.2.3

172.25.200.15:0 Y N/A 02:15:40 2 3 31

RP/0/RSP0/CPU0:A9K-LAB01#sh mpls ldp neighbor

Mon Jan 7 15:02:18.219 WET

Peer LDP Identifier: 172.25.200.11:0

TCP connection: 172.25.200.11:19136 - 172.25.200.5:646

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 180 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 11180/11165; Downstream-Unsolicited

Up time: 2d23h

LDP Discovery Sources:

Targeted Hello (172.25.200.5 -> 172.25.200.11, active)

Addresses bound to this peer:

172.25.7.36 172.25.7.94 172.25.7.161 172.25.200.11

Peer LDP Identifier: 172.25.200.2:0

TCP connection: 172.25.200.2:646 - 172.25.200.5:29821; MD5 on

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 180 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 11129/11093; Downstream-Unsolicited

Up time: 2d23h

LDP Discovery Sources:

TenGigE0/1/0/0.2

TenGigE0/0/0/1.2

Targeted Hello (172.25.200.5 -> 172.25.200.2, active)

Addresses bound to this peer:

172.25.7.25 172.25.7.81 172.25.7.85 172.25.7.101

172.25.7.113 172.25.7.121 172.25.7.125 172.25.7.153

172.25.7.157 172.25.7.173 172.25.7.177 172.25.200.2

Peer LDP Identifier: 172.25.200.7:0

TCP connection: 172.25.200.7:39798 - 172.25.200.5:646; MD5 on

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 120 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 11133/11086; Downstream-Unsolicited

Up time: 2d23h

LDP Discovery Sources:

GigabitEthernet0/4/0/0.2

Targeted Hello (172.25.200.5 -> 172.25.200.7, active)

Addresses bound to this peer:

172.25.7.106 172.25.7.110 172.25.200.7

Peer LDP Identifier: 172.25.200.10:0

TCP connection: 172.25.200.10:41025 - 172.25.200.5:646; MD5 on

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 180 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 11125/11133; Downstream-Unsolicited

Up time: 2d23h

LDP Discovery Sources:

TenGigE0/0/0/2.2

Targeted Hello (172.25.200.5 -> 172.25.200.10, active)

Addresses bound to this peer:

172.25.7.34 172.25.7.90 172.25.7.97 172.25.200.10

Peer LDP Identifier: 172.25.200.6:0

TCP connection: 172.25.200.6:25373 - 172.25.200.5:646

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 11349/12751; Downstream-Unsolicited

Up time: 2d20h

LDP Discovery Sources:

Targeted Hello (172.25.200.5 -> 172.25.200.6, active)

Addresses bound to this peer:

172.25.7.31 172.25.7.86 172.25.7.93 172.25.7.109

172.25.7.169 172.25.7.178 172.25.200.6

Peer LDP Identifier: 172.25.200.15:0

TCP connection: 172.25.200.15:63213 - 172.25.200.5:646; MD5 on

Graceful Restart: Yes (Reconnect Timeout: 120 sec, Recovery: 0 sec)

Session Holdtime: 80 sec

State: Oper; Msgs sent/rcvd: 384/384; Downstream-Unsolicited

Up time: 02:15:51

LDP Discovery Sources:

TenGigE0/1/0/1.2

Targeted Hello (172.25.200.5 -> 172.25.200.15, active)

Addresses bound to this peer:

172.25.7.166 172.25.7.170 172.25.200.15

RP/0/RSP0/CPU0:A9K-LAB01#

Any place in the documentation were I can found more info about targeted LDP?

Thanks,

Pedro

Alexei Kiritchenko · ‎01-07-2013

Yes, indeed, officially NSR is not supported on targeted LDP, so even if it works, we can consider it as a bonus

There is not much difference between LDP and tLDP. tLDP neighbour discovery differs from normal discovery only in the addressing of hello packets. Hello packets use unicast IP addresses instead of multicast addresses. When a neighbour is discovered, the mechanism to establish a session is the same.

Regards,

/A

Pedro Morais · ‎01-09-2013

Thx for your help Alexei!!!