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/
                                          
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to