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

Mon Apr 20 23:03:58 EDT 2015

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   		 	   		  