[c-nsp] IOS XR on ASR9001: Some LDP on Interfaces stuck in xmit

[Richard Hartmann]

Dear all,


I am having issues bringing up LDP on several interfaces on an ASR9001
with IOS XR 4.3.4. All other machines I am referring to in this email
and in the rest of our backbone are happily talking with each other.

In the context of this setup two ASR9001 and two ME3600x are relevant.
All four machines use different IOS versions, so I will designate them
as:


Machines:
* ASR-4.3.4
* ASR-4.3.0
* ME-15.3(2)S1
* ME-15.3(1)S

Relevant interconnections:
ASR-4.3.4 Te0/0/2/1 <> Te0/2 ME-15.3(2)S1
ASR-4.3.4 Te0/0/2/2 <> Te0/1 ME-15.3(1)S
ASR-4.3.4 Te0/0/2/3 <> Te0/0/2/3 ASR-4.3.0



Now the problem is that TenGigE0/0/2/2 and TenGigE0/0/2/3 are stuck in
xmit, while TenGigE0/0/2/1 goes into xmit/recv as it should:

RP/0/RSP0/CPU0:ASR-4.3.4#sh mpls ldp discovery
Local LDP Identifier: ASR-4.3.4:0
Discovery Sources:
Interfaces:
TenGigE0/0/2/1 : xmit/recv
LDP Id: ME-15.3(2)S1:0, Transport address: ME-15.3(2)S1
Hold time: 15 sec (local:15 sec, peer:15 sec)

TenGigE0/0/2/2 : xmit

TenGigE0/0/2/3 : xmit

Targeted Hellos:
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

ASR-4.3.4 -> ME-15.3(1)S (active/passive), xmit/recv
LDP Id: ME-15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

ASR-4.3.4 -> different ME with 15.3(1)S (active/passive), xmit/recv
LDP Id: different ME with 15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

ASR-4.3.4 -> ASR-4.3.0 (active/passive), xmit/recv
LDP Id: ASR-4.3.0:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

RP/0/RSP0/CPU0:ASR-4.3.4#sh run
<snip>
ipv4 access-list mpls-ldp-advertisement
10 permit ipv4 Loopbacks any
20 permit ipv4 Interconnects any
30 deny ipv4 any any
</snip>
<snap>
mpls oam
!
mpls ldp
discovery targeted-hello accept
label
allocate for mpls-ldp-advertisement
!
interface TenGigE0/0/2/1
discovery transport-address interface
!
interface TenGigE0/0/2/2
discovery transport-address interface
!
interface TenGigE0/0/2/3
discovery transport-address interface
!
!
</snap>

mpls-ldp-advertisement is the same on all machines and allows the
relevant loopback and interface IPs.
Adding/removing `discovery transport-address interface` does not have
any effect.
The other sides of the interconnects are happily talking LDP among
each other. All interconnects are configured to accept MPLS

Other than an upgrade of ASR-4.3.0 and ME-15.3(1)S I am out of ideas,
but I would prefer to do this _after_ I got the above to work if at
all possible...


Thanks,
Richard
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jason Lixfeld]

I have a 4.3.4 ASR9010 (RSP4G/Trident based, up-to-date fpd versions) directly connected to the following with no issues:

2 x RSP4/Trident based XR 4.3.1
2 x ME3600 15.3(3)S
3 x ME3600 15.1(2)EY1a
1 x ME3600 15.3(1)S

My config is a little more generic tho:

mpls ldp
router-id Loopback0
graceful-restart
session protection
log
neighbor
graceful-restart
session-protection
!
mldp
make-before-break delay 0
logging notifications
!
interface TenGigE0/0/0/0
!
interface TenGigE0/0/0/3
!
interface TenGigE0/0/0/4
!
interface TenGigE0/0/0/6
!
interface TenGigE0/0/0/8
!
interface TenGigE0/0/0/9
!
interface TenGigE0/0/0/12
!
interface TenGigE0/1/0/0
!
!

Are your fpd versions up to date too?

Post by Richard Hartmann
Dear all,
I am having issues bringing up LDP on several interfaces on an ASR9001
with IOS XR 4.3.4. All other machines I am referring to in this email
and in the rest of our backbone are happily talking with each other.
In the context of this setup two ASR9001 and two ME3600x are relevant.
All four machines use different IOS versions, so I will designate them
* ASR-4.3.4
* ASR-4.3.0
* ME-15.3(2)S1
* ME-15.3(1)S
ASR-4.3.4 Te0/0/2/1 <> Te0/2 ME-15.3(2)S1
ASR-4.3.4 Te0/0/2/2 <> Te0/1 ME-15.3(1)S
ASR-4.3.4 Te0/0/2/3 <> Te0/0/2/3 ASR-4.3.0
Now the problem is that TenGigE0/0/2/2 and TenGigE0/0/2/3 are stuck in
RP/0/RSP0/CPU0:ASR-4.3.4#sh mpls ldp discovery
Local LDP Identifier: ASR-4.3.4:0
TenGigE0/0/2/1 : xmit/recv
LDP Id: ME-15.3(2)S1:0, Transport address: ME-15.3(2)S1
Hold time: 15 sec (local:15 sec, peer:15 sec)
TenGigE0/0/2/2 : xmit
TenGigE0/0/2/3 : xmit
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> ME-15.3(1)S (active/passive), xmit/recv
LDP Id: ME-15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> different ME with 15.3(1)S (active/passive), xmit/recv
LDP Id: different ME with 15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> ASR-4.3.0 (active/passive), xmit/recv
LDP Id: ASR-4.3.0:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
RP/0/RSP0/CPU0:ASR-4.3.4#sh run
<snip>
ipv4 access-list mpls-ldp-advertisement
10 permit ipv4 Loopbacks any
20 permit ipv4 Interconnects any
30 deny ipv4 any any
</snip>
<snap>
mpls oam
!
mpls ldp
discovery targeted-hello accept
label
allocate for mpls-ldp-advertisement
!
interface TenGigE0/0/2/1
discovery transport-address interface
!
interface TenGigE0/0/2/2
discovery transport-address interface
!
interface TenGigE0/0/2/3
discovery transport-address interface
!
!
</snap>
mpls-ldp-advertisement is the same on all machines and allows the
relevant loopback and interface IPs.
Adding/removing `discovery transport-address interface` does not have
any effect.
The other sides of the interconnects are happily talking LDP among
each other. All interconnects are configured to accept MPLS
Other than an upgrade of ASR-4.3.0 and ME-15.3(1)S I am out of ideas,
but I would prefer to do this _after_ I got the above to work if at
all possible...
Thanks,
Richard
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Richard Hartmann]

Post by Jason Lixfeld
2 x RSP4/Trident based XR 4.3.1
2 x ME3600 15.3(3)S
3 x ME3600 15.1(2)EY1a
1 x ME3600 15.3(1)S

Close enough to what I have, I guess...

Post by Jason Lixfeld
Are your fpd versions up to date too?

Yes:
Node 0/RSP0/CPU0 [RP] [SDR: Owner]
Boot Device: disk0:
Boot Image: /disk0/asr9k-os-mbi-4.3.4/0x100000/mbiasr9k-rp.vm
Active Packages:
disk0:asr9k-mini-px-4.3.4
disk0:asr9k-doc-px-4.3.4
disk0:asr9k-fpd-px-4.3.4
disk0:asr9k-mcast-px-4.3.4
disk0:asr9k-mgbl-px-4.3.4
disk0:asr9k-mpls-px-4.3.4
disk0:asr9k-optic-px-4.3.4
disk0:asr9k-k9sec-px-4.3.4
disk0:asr9k-9000v-nV-px-4.3.4

Node 0/0/CPU0 [LC] [SDR: Owner]
Boot Device: mem:
Boot Image: /disk0/asr9k-os-mbi-4.3.4/lc/mbiasr9k-lc.vm
Active Packages:
disk0:asr9k-mini-px-4.3.4
disk0:asr9k-mcast-px-4.3.4
disk0:asr9k-mpls-px-4.3.4
disk0:asr9k-optic-px-4.3.4


Richard
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jason Lixfeld]

show hw-mod fpd loc all

Just because you have the fpd pie installed, doesn't necessarily mean the fpds are up to date.

Sent from my iPhone

Post by Richard Hartmann

Post by Jason Lixfeld
2 x RSP4/Trident based XR 4.3.1
2 x ME3600 15.3(3)S
3 x ME3600 15.1(2)EY1a
1 x ME3600 15.3(1)S

Close enough to what I have, I guess...

Post by Jason Lixfeld
Are your fpd versions up to date too?

Node 0/RSP0/CPU0 [RP] [SDR: Owner]
Boot Image: /disk0/asr9k-os-mbi-4.3.4/0x100000/mbiasr9k-rp.vm
disk0:asr9k-mini-px-4.3.4
disk0:asr9k-doc-px-4.3.4
disk0:asr9k-fpd-px-4.3.4
disk0:asr9k-mcast-px-4.3.4
disk0:asr9k-mgbl-px-4.3.4
disk0:asr9k-mpls-px-4.3.4
disk0:asr9k-optic-px-4.3.4
disk0:asr9k-k9sec-px-4.3.4
disk0:asr9k-9000v-nV-px-4.3.4
Node 0/0/CPU0 [LC] [SDR: Owner]
Boot Image: /disk0/asr9k-os-mbi-4.3.4/lc/mbiasr9k-lc.vm
disk0:asr9k-mini-px-4.3.4
disk0:asr9k-mcast-px-4.3.4
disk0:asr9k-mpls-px-4.3.4
disk0:asr9k-optic-px-4.3.4
Richard

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Hilliard]

Post by Jason Lixfeld
Are your fpd versions up to date too?

the command for this is:

RP/0/RSP0/CPU0:router#admin show hw-module fpd location all

If you see any "Yes" in the "Upg/Dng?" column, then you need to manually
upgrade:

RP/0/RSP0/CPU0:router#admin upgrade hw-module fpd all location all

fpd upgrades are service affecting and often require either line card or
RSP reboots, so upgrades are maintenance window territory. Some people use
fpd autoupgrade. I got stung once, so usually do manual upgrades even
though it takes longer.

As Adam mentioned, 15.3(1) is pretty ancient and it would be advisable to
upgrade to the latest 15.3 on your me3600 boxes. There are some
hilariously awful mpls bugs, which are slowly being ironed out. E.g. port
based l3vpn doesn't work at all on 15.3(1).

Nick

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Richard Hartmann]

Post by Nick Hilliard
RP/0/RSP0/CPU0:router#admin show hw-module fpd location all

As stated off-list, they all say "No". By this point, I would actually
be happy if it was something as simple (and embarrassing) as this.


Richard
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Vitkovský Adam]

Hello Richard,

First of all ME-15.3(1)S is ancient.
What does the debug says please? Is the other side xmitting discovery hellos or it's just the ASR-4.3.4 that does not see the incoming hellos?

I understand this is just a test setup so far but be careful with the "discovery targeted-hello accept".
As it means anybody can create LDP session to the box.
So in production you might want to limit that with an ACL and neighbor password.
Also a good practice is to manually specify the router-id for the ldp process.

adam

-----Original Message-----
Richard Hartmann
Sent: Wednesday, March 26, 2014 12:32 PM
Subject: [c-nsp] IOS XR on ASR9001: Some LDP on Interfaces stuck in xmit
Dear all,
I am having issues bringing up LDP on several interfaces on an ASR9001 with
IOS XR 4.3.4. All other machines I am referring to in this email and in the rest
of our backbone are happily talking with each other.
In the context of this setup two ASR9001 and two ME3600x are relevant.
All four machines use different IOS versions, so I will designate them
* ASR-4.3.4
* ASR-4.3.0
* ME-15.3(2)S1
* ME-15.3(1)S
ASR-4.3.4 Te0/0/2/1 <> Te0/2 ME-15.3(2)S1
ASR-4.3.4 Te0/0/2/2 <> Te0/1 ME-15.3(1)S
ASR-4.3.4 Te0/0/2/3 <> Te0/0/2/3 ASR-4.3.0
Now the problem is that TenGigE0/0/2/2 and TenGigE0/0/2/3 are stuck in
RP/0/RSP0/CPU0:ASR-4.3.4#sh mpls ldp discovery Local LDP Identifier: ASR-
TenGigE0/0/2/1 : xmit/recv
LDP Id: ME-15.3(2)S1:0, Transport address: ME-15.3(2)S1
Hold time: 15 sec (local:15 sec, peer:15 sec)
TenGigE0/0/2/2 : xmit
TenGigE0/0/2/3 : xmit
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> ME-15.3(1)S (active/passive), xmit/recv
LDP Id: ME-15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> different ME with 15.3(1)S (active/passive), xmit/recv
LDP Id: different ME with 15.3(1)S:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> C6500 (active/passive), xmit/recv
LDP Id: C6500:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
ASR-4.3.4 -> ASR-4.3.0 (active/passive), xmit/recv
LDP Id: ASR-4.3.0:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
RP/0/RSP0/CPU0:ASR-4.3.4#sh run
<snip>
ipv4 access-list mpls-ldp-advertisement
10 permit ipv4 Loopbacks any
20 permit ipv4 Interconnects any
30 deny ipv4 any any
</snip>
<snap>
mpls oam
!
mpls ldp
discovery targeted-hello accept
label
allocate for mpls-ldp-advertisement
!
interface TenGigE0/0/2/1
discovery transport-address interface
!
interface TenGigE0/0/2/2
discovery transport-address interface
!
interface TenGigE0/0/2/3
discovery transport-address interface
!
!
</snap>
mpls-ldp-advertisement is the same on all machines and allows the relevant
loopback and interface IPs.
Adding/removing `discovery transport-address interface` does not have any
effect.
The other sides of the interconnects are happily talking LDP among each
other. All interconnects are configured to accept MPLS
Other than an upgrade of ASR-4.3.0 and ME-15.3(1)S I am out of ideas, but I
would prefer to do this _after_ I got the above to work if at all possible...
Thanks,
Richard
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Richard Hartmann]

Post by Vitkovský Adam
First of all ME-15.3(1)S is ancient.

I know, but as you can see, others still have a few machines with that
version, as well.

Post by Vitkovský Adam
What does the debug says please? Is the other side xmitting discovery hellos or it's just the ASR-4.3.4 that does not see the incoming hellos?

debug mpls ldp interface TenGigE0/0/2/2
debug mpls ldp interface TenGigE0/0/2/3
show nothing

debug mpls ldp messages sent all
debug mpls ldp messages received all
show traffic over TenGigE0/0/2/1


ME-15.3(2)S1:
TenGigabitEthernet0/2 (ldp): xmit/recv
LDP Id: ASR-4.3.4:0; IP addr: <interface IP>

ME-15.3(1)S
TenGigabitEthernet0/1 (ldp): xmit/recv
LDP Id: ASR-4.3.4:0; IP addr: <interface IP>

ASR-4.3.0
TenGigE0/0/2/3 : xmit

Post by Vitkovský Adam
I understand this is just a test setup so far but be careful with the "discovery targeted-hello accept".
As it means anybody can create LDP session to the box.

We are filtering to prefixes which are allowed to talk to that box.

Post by Vitkovský Adam
Also a good practice is to manually specify the router-id for the ldp process.

It uses the router ID by default, but I added that stanza.


Thanks,
Richard

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.neth

[Richard Hartmann]

On Wed, Mar 26, 2014 at 2:49 PM, Dimitris Befas

Do you have ip/tcp connectivity between the IP/tcp endpoints of your LDP sessions ?

I do, fwiw, they speak OSPF just fine.

You may give it a try telneting between your LDP session IPs and towards tcp 646.

That is not a bad idea. I can not connect:

#telnet <peer interface> 646
Trying <peer interface>...
telnet: Unable to connect to remote host: Connection refused

This does not work for loopback IP, either.

I can connect to another ASR running 4.3.0 from the one running 4.3.0
just fine, though.

I am not 100% sure if I should be able to connect while the connection
is still not established, though. LDP sessions are established via
UDP, after all.


Before you ask, I did try running without an ACL, yes.


Thanks a lot!
Richard
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Dimitris Befas]

Richard, the UDP protocol is being used for LDP hellos exchange. The initial LDP session should be established first via TCP.
It is a good thing you get a connection refused on tcp 646, this means you get an answer from the remote router. Indeed you won't see an "open" message through this telnet, but the aim of this telnet is to see an answer from tcp, even if this answer is "connection refused". If you had a timeout, then it should be a problem.

Do you use the same router IDs for LDP as for your successfully established OSPF neighbors ?

Regards,
Dimitris

-----Original Message-----
From: Richard Hartmann [mailto:***@gmail.com]
Sent: Wednesday, March 26, 2014 3:58 PM
To: Dimitris Befas
Cc: Vitkovský Adam; cisco-***@puck.nether.net
Subject: Re: [c-nsp] IOS XR on ASR9001: Some LDP on Interfaces stuck in xmit

Do you have ip/tcp connectivity between the IP/tcp endpoints of your LDP sessions ?

I do, fwiw, they speak OSPF just fine.

You may give it a try telneting between your LDP session IPs and towards tcp 646.

That is not a bad idea. I can not connect:

#telnet <peer interface> 646
Trying <peer interface>...
telnet: Unable to connect to remote host: Connection refused

This does not work for loopback IP, either.

I can connect to another ASR running 4.3.0 from the one running 4.3.0 just fine, though.

I am not 100% sure if I should be able to connect while the connection is still not established, though. LDP sessions are established via UDP, after all.


Before you ask, I did try running without an ACL, yes.


Thanks a lot!
Richard


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive

[Dimitris Befas]

Do you have ip/tcp connectivity between the IP/tcp endpoints of your LDP sessions ? You may give it a try telneting between your LDP session IPs and towards tcp 646.

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Richard Hartmann
Sent: Wednesday, March 26, 2014 3:24 PM
To: Vitkovský Adam
Cc: cisco-***@puck.nether.net
Subject: Re: [c-nsp] IOS XR on ASR9001: Some LDP on Interfaces stuck in xmit

Post by Vitkovský Adam
First of all ME-15.3(1)S is ancient.

I know, but as you can see, others still have a few machines with that version, as well.

Post by Vitkovský Adam
What does the debug says please? Is the other side xmitting discovery hellos or it's just the ASR-4.3.4 that does not see the incoming hellos?

debug mpls ldp interface TenGigE0/0/2/2
debug mpls ldp interface TenGigE0/0/2/3
show nothing

debug mpls ldp messages sent all
debug mpls ldp messages received all
show traffic over TenGigE0/0/2/1


ME-15.3(2)S1:
TenGigabitEthernet0/2 (ldp): xmit/recv
LDP Id: ASR-4.3.4:0; IP addr: <interface IP>

ME-15.3(1)S
TenGigabitEthernet0/1 (ldp): xmit/recv
LDP Id: ASR-4.3.4:0; IP addr: <interface IP>

ASR-4.3.0
TenGigE0/0/2/3 : xmit

Post by Vitkovský Adam
I understand this is just a test setup so far but be careful with the "discovery targeted-hello accept".
As it means anybody can create LDP session to the box.

We are filtering to prefixes which are allowed to talk to that box.

Post by Vitkovský Adam
Also a good practice is to manually specify the router-id for the ldp process.

It uses the router ID by default, but I added that stanza.


Thanks,
Richard

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-n

[Vitkovský Adam]

Hello Richard,

Would you please issue:

debug mpls ldp discovery hello send interface TenGigE0/0/2/2
debug mpls ldp discovery hello receive interface TenGigE0/0/2/2
debug mpls ldp discovery hello send interface TenGigE0/0/2/3
debug mpls ldp discovery hello receive interface TenGigE0/0/2/3
debug mpls ldp errors

And let me know the outputs please.

Thank you.


adam

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Vitkovský Adam]

Hello Richard,

Would you please issue:

debug mpls ldp discovery hello send interface TenGigE0/0/2/2.
debug mpls ldp discovery hello receive interface TenGigE0/0/2/2.
debug mpls ldp discovery hello send interface TenGigE0/0/2/3.
debug mpls ldp discovery hello receive interface TenGigE0/0/2/3.
debug mpls ldp errors.

And let me know the outputs please.

Thank you.


adam

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Richard Hartmann]

I fixed the issue by reloading the whole machine.

To quote Nick Hilliard: "honestly though, rebooting usually doesn't
fix things in XR" and up to a few minutes ago, I think we both agreed
on that. The rest of what we said can not be quoted in polite
conversation.

As a data point, I installed the FPD pie after the initial boot, but
to the best of my knowledge, this should not matter.


I will now find a 2x4 to chew on,
Richard

PS: I tried all the various combinations of removing config stanzas,
ACLs, interface shut/no shut, and all the other usual suspects first.
It really was the reload... argh...
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Vitkovský Adam]

Yeah sometimes when feature is enabled on an interface in SW it is not propagated to the HW
There's a command that displays enabled features on a particular interface to check that out


adam

-----Original Message-----
Richard Hartmann
Sent: Wednesday, March 26, 2014 3:16 PM
Subject: Re: [c-nsp] IOS XR on ASR9001: Some LDP on Interfaces stuck in xmit
I fixed the issue by reloading the whole machine.
To quote Nick Hilliard: "honestly though, rebooting usually doesn't fix things
in XR" and up to a few minutes ago, I think we both agreed on that. The rest
of what we said can not be quoted in polite conversation.
As a data point, I installed the FPD pie after the initial boot, but to the best of
my knowledge, this should not matter.
I will now find a 2x4 to chew on,
Richard
PS: I tried all the various combinations of removing config stanzas, ACLs,
interface shut/no shut, and all the other usual suspects first.
It really was the reload... argh...
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Richard Hartmann]

Post by Vitkovský Adam
Yeah sometimes when feature is enabled on an interface in SW it is not propagated to the HW
There's a command that displays enabled features on a particular interface to check that out

That sounds incredibly evil. Do you happen to know that command by
heart? Else, I will put it on my bucket list to find out ASAP...


Thanks,
Richard

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp

[Vitkovský Adam]

Post by Vitkovský Adam
Yeah sometimes when feature is enabled on an interface in SW it is not
propagated to the HW There's a command that displays enabled features
on a particular interface to check that out

That sounds incredibly evil. Do you happen to know that command by heart?
Else, I will put it on my bucket list to find out ASAP...

Finally got some time to look for the command:

sh uidb data loc 0/0/CPU0 Te0/0/0/0 ?
egress Egress Data
extension Extension Data
ing-extension Ingress Extension Data
ingress Ingress Data

The "MPLS Enable" flag in particular can be found in the output of the cmd. with "ingress" keyword.


I think it's good that such commands do exist, XR and ME3600 with sdcli, are very well equipped for deep HW troubleshooting they are just lacking the documentation to these tools.

adam


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jason Lixfeld]

Can you actually make heads or tails out of sdcli?

Sent from my iPhone

Post by Vitkovský Adam

Post by Vitkovský Adam
Yeah sometimes when feature is enabled on an interface in SW it is not
propagated to the HW There's a command that displays enabled features
on a particular interface to check that out

That sounds incredibly evil. Do you happen to know that command by heart?
Else, I will put it on my bucket list to find out ASAP...

sh uidb data loc 0/0/CPU0 Te0/0/0/0 ?
egress Egress Data
extension Extension Data
ing-extension Ingress Extension Data
ingress Ingress Data
The "MPLS Enable" flag in particular can be found in the output of the cmd. with "ingress" keyword.
I think it's good that such commands do exist, XR and ME3600 with sdcli, are very well equipped for deep HW troubleshooting they are just lacking the documentation to these tools.
adam
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether

[Vitkovský Adam]

Post by Jason Lixfeld
Can you actually make heads or tails out of sdcli?

Me? Not really. But I've seen developer to fix an MPLS bug on the fly.
To be honest I haven't had the time to play with it.


adam

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

On Wednesday, March 26, 2014 05:23:17 PM Vitkovský Adam

Post by Vitkovský Adam
Yeah sometimes when feature is enabled on an interface in
SW it is not propagated to the HW There's a command that
displays enabled features on a particular interface to
check that out

That we even have this command is disturbing. But it is what
it is :-).

As a friend once said about the old 5ESS switches, "Half the
code runs the box. The half keeps the first half in check".

Mark.