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

[CiscoNSP List]

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/