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----- > From: cisco-nsp [mailto:[email protected]] On Behalf Of > Richard Hartmann > Sent: Wednesday, March 26, 2014 12:32 PM > To: [email protected] > 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 > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
