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

Wed Apr 22 09:10:30 EDT 2015

Hi

I was just trying to understand which router drops the ball.
Because all other routers have working label switched paths to the remote PE it's just this one ME that has problems -so with that in mind the remote PE has to advertise label for its loopback correctly.
But at some point the label is lost and our problem ME doesn't get the label for this prefix.
So I wanted to know if it's the ME -not accepting the label for the remote PE's loopback for some reason.
Or if the ME is not even getting the label from the upstream router for some reason -so that is why I wanted to see mpls forwarding table from the router that is upstream to the ME to see if it allocated label for the remote PE's loopback.

ME<--PHP<--...<--PE

Can you please post output from the "sh mpls ldp nei det" -from ME and PHP for the session between them.
And also on PHP please issue "sh mpls forwarding" for the PE's loopback  --the PHP router should allocate a label for PE's loopback.

adam

From: CiscoNSP List [mailto:cisconsp_list at hotmail.com]
Sent: 21 April 2015 04:10
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

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<mailto:Adam.Vitkovsky at gamma.co.uk>
> To: cisconsp_list at hotmail.com<mailto:cisconsp_list at hotmail.com>; cisco-nsp at puck.nether.net<mailto: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<mailto: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<mailto:cisconsp_list at hotmail.com>
>
> > To: adam.vitkovsky at gamma.co.uk<mailto:adam.vitkovsky at gamma.co.uk>;
> cisco-nsp at puck.nether.net<mailto: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<mailto:Adam.Vitkovsky at gamma.co.uk>
>
> > To: cisconsp_list at hotmail.com<mailto:cisconsp_list at hotmail.com>;
> cisco-nsp at puck.nether.net<mailto: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<mailto: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<mailto: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
---------------------------------------------------------------------------------------