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]<mailto:[email protected]> > To: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[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]<mailto:[email protected]> > To: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[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]<mailto:[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/
