[c-nsp] 2 x "new" ME3600's, 1 fails to reach one PE only in VRF's

[CiscoNSP List]

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: Adam.Vitkovsky at gamma.co.uk
> To: cisconsp_list at hotmail.com; cisco-nsp at puck.nether.net
> 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:cisconsp_list at hotmail.com]
> 
> 
> Sent: 20 April 2015 22:49
> 
> To: Adam Vitkovsky; cisco-nsp at puck.nether.net
> 
> 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: 
> cisconsp_list at hotmail.com
> 
> > To: adam.vitkovsky at gamma.co.uk;
> cisco-nsp at puck.nether.net
> 
> > 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: Adam.Vitkovsky at gamma.co.uk
> 
> > To: cisconsp_list at hotmail.com; 
> cisco-nsp at puck.nether.net
> 
> > 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 cisco-nsp at puck.nether.net
> 
> > 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/