Apologies - that was "cant" see a label...not "can"!
> > Thanks Adam, > On the PE that the problem PE connects to, I can see a label: > > sh ip cef xxx.xxx.xxx.222/32 detail > xxx.xxx.xxx.222/32, epoch 0 > NetFlow: Origin AS 0, Peer AS 0, Mask Bits 32 > local label info: global/1737 > nexthop xxx.xxx.xxx Port-channel1.88 > > and for debugging, I have the following enabled(On ME3600), but not getting > anything "useful" in the logs...Is there another debug option that would > provide why the label is being dropped? > > MPLS: > MPLS events debugging is on > MPLS ldp: > LDP Label Information Base (LIB) changes debugging is on > LDP label and address advertisements debugging is on > LDP Configuration events debugging is on > > Cheers. > > > From: [email protected] > To: [email protected]; [email protected] > Subject: RE: [c-nsp] 2 x "new" ME3600's, 1 fails to reach one PE only in VRF's > Date: Mon, 20 Apr 2015 23:13:42 +0000 > > > > > > > > > > > On the ME you can debug why the label is being dropped/not accepted for the > “problem”PE’s loopback. > Or what label, if any, is allocated for the “problem”PE’s loopback by the > penultimate hop router. > > > adam > > > > > From: CiscoNSP List [mailto:[email protected]] > > > Sent: 20 April 2015 22:49 > > To: Adam Vitkovsky; [email protected] > > Subject: RE: [c-nsp] 2 x "new" ME3600's, 1 fails to reach one PE only in VRF's > > > > > One thing I do notice, is that the "problem" PE doesnt have a label(After > nexthop) when issuing "#sh ip cef xxx detail"...all other PE's do? > > > > > > > > eg. a "working" PE, from this ME3600: > > > > > > > > > > sh ip cef xxx.xxx.xxx.217/32 detail > > > > > > xxx.xxx.xxx.217/32, epoch 0 > > > > > > local label info: global/20661 > > > > > > 2 RR sources [heavily shared] > > > > > > nexthop xxx.xxx.xxx.232 GigabitEthernet0/3 label 333 > > > > > > > > vs > > > > > > > > > #sh ip cef xxx.xxx.xxx.222/32 detail > > > xxx.xxx.xxx.222/32, epoch 0 > > > local label info: global/20625 > > > nexthop xxx.xxx.xxx.232 GigabitEthernet0/3 > > > > > > > > > > > > From: > [email protected] > > > To: [email protected]; > [email protected] > > > Date: Tue, 21 Apr 2015 08:11:52 +1030 > > > Subject: Re: [c-nsp] 2 x "new" ME3600's, 1 fails to reach one PE only in > > VRF's > > > > > > Thanks Adam - shutdown int vlan36, but unfortunately the issue still > > persists...I also did a "clear ip route *" > > > > > > #sh ip cef xxx.xxx.xxx.222/32 detail > > > xxx.xxx.xxx.222/32, epoch 0 > > > local label info: global/20625 > > > nexthop xxx.xxx.xxx.232 GigabitEthernet0/3 > > > > > > > > > #ping vrf CUSTA 10.2.4.1 > > > Type escape sequence to abort. > > > Sending 5, 100-byte ICMP Echos to 10.2.4.1, timeout is 2 seconds: > > > ..... > > > Success rate is 0 percent (0/5) > > > > > > If it was due to this bug, wouldnt it impact on "all/most?" traffic...i.e. > > the box can get to all our other PE's in VRF+Global....it's only VRF > > traffic to this one PE that appears to fail...Global(as mentioned) to this > > PE works fine? > > > > > > Cheers. > > > From: [email protected] > > > To: [email protected]; > [email protected] > > > Subject: RE: [c-nsp] 2 x "new" ME3600's, 1 fails to reach one PE only in > > VRF's > > > Date: Mon, 20 Apr 2015 11:53:16 +0000 > > > > > > I'm sorry about that I did not follow up on this problem. > > > > > > > > > > > > IP LFA is not supported on VLAN interfaces (at least not on 15.3(3)S4) > > > > > > Bug: > > > > > > Whenever IP LFA is used and a backup path is computed via VLAN interface HW > > forwarding gets corrupted on the box. > > > > > > You are "lucky" though, as when we ran into this the box stopped forwarding > > all transit traffic (only traffic to the box was not affected fortunately) > > > > > > > > > > > > The workaround is to never use VLAN interfaces with IP FRR. > > > > > > > > > > > > So would you please try shutting down the VLAN36 interface if it helps > > (provided there are no other VLAN interfaces that can be used as LFA backup > > link)? > > > > > > > > > > > > > > > > > > > ME02: > > > > > > > #sh ip cef xxx.xxx.xxx.222/32 detail > > > > > > > xxx.xxx.xxx.222/32, epoch 0 > > > > > > > local label info: global/20625 > > > > > > > 2 RR sources [heavily shared] > > > > > > > nexthop xxx.xxx.xxx.232 GigabitEthernet0/3 label [none|674] > > > > > > > repair: attached-nexthop xxx.xxx.xxx.234 Vlan36 <========== > > > > > > > nexthop xxx.xxx.xxx.234 Vlan36, repair <======= > > > > > > > > > > > > > > > > > > > adam > > > > > > > > > > > > This email has been scanned for email related threats and delivered safely > > by Mimecast. > > > For more information please visit http://www.mimecast.com > > > > _______________________________________________ > > > cisco-nsp mailing list [email protected] > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > This email has been scanned for email related threats and delivered safely > by Mimecast. > For more information please visit http://www.mimecast.com > > _______________________________________________ > 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/
