[c-nsp] LDP sessions established to non directly connected routers, when new link is activated

CiscoNSP List CiscoNSP_list at hotmail.com
Mon Sep 28 17:21:56 EDT 2015


Hi Everyone - Just an update to this - Spent some time with TAC, and they agreed it appeared to be the bug that has been mentioned on the list(So thanks very much!!), so disabled FRR on the ME's vlan Interface, and returned ospf to default settings on the new link, and no more BGP drops etc - So happy with that!

Now I face another "interesting" issue.

POPA with 2 x ASR10001s now have 2 links(one into each router) to the rest of the network....the problem is that now ASR1(that has a direct link to ME3600 @ POPB) now sees ASR2 as a better path to the rest of the network via ASR2's "new" link...the only POP it is the preferred path to is POPB(With the 2 x ME3600's)

Now this wouldnt be a huge issue, apart from the latency hit...

i.e. POPA -> POPC, which used to go via POPB B has latency of 4/msec

Now from POPA->POPC as it is preferring the path via ASR2->POPD, latency has increased to 15-20m/sec

Example of a route @ POPC (From ASR1 @ POPA)

Routing entry for xxx.xxx.xxx.249/32
  Known via "ospf 100", distance 110, metric 5, type intra area
  Last update from yyy.yyy.yyy.237 on GigabitEthernet0/1/0, 00:41:25 ago
  Routing Descriptor Blocks:
  * yyy.yyy.yyy.247, from xxx.xxx.xxx.249, 00:41:25 ago, via GigabitEthernet0/0/3
      Route metric is 5, traffic share count is 1
      Repair Path: yyy.yyy.yyy.237, via GigabitEthernet0/1/0
    yyy.yyy.yyy.237, from xxx.xxx.xxx.249, 00:41:25 ago, via GigabitEthernet0/1/0
      Route metric is 5, traffic share count is 1
      Repair Path: yyy.yyy.yyy.247, via GigabitEthernet0/0/3

route metric is the same, so I can understand why the new link is "equal" to the original link, but I would much prefer prefixes "local" to POPC go via the original link(ASR1), and prefixes "local" to POPD go via the new link(ASR2)

Is there anyway to achieve this?  If I adjust ospf cost, it would then just prefer one path correct?

Cheers

________________________________________
From: Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
Sent: Saturday, 26 September 2015 1:22 AM
To: CiscoNSP List; cisco-nsp at puck.nether.net
Subject: RE: LDP sessions established to non directly connected routers, when new link is activated

Hi Michael,

Yeah the link can run fine the problem manifests only when the vlan interface is computed/programed as LFA backup interface for some primary link.
So while you are changing topology -i.e. adding new links, like you did  then OSPF computes different primary and associated backup interfaces.

Which also leads me to the question you raised regarding the rLFA tLDP sessions.
As you introduce new links then the topology changes requiring re-computation of primary and backup paths and that might result in new tLDP backup tunnels to be created to remote LFA nodes in the network.
So that's why you see the new tLDP sessions being created all of a sudden when you enable a new link.

And regarding the mpls ping failing
Let's do mpls traceroute to see where it fails
Or you can check output of the show mpls forwarding | i x.x.x.x <-where that would be the destination/source loopback
To see whether labels are allocated and distributed for the loopbacks
If you see no label along the path somewhere that's where the LSP is broken


adam
>

        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-----Original Message-----
> From: CiscoNSP List [mailto:CiscoNSP_list at hotmail.com]
> Sent: Friday, September 25, 2015 3:24 AM
> To: Adam Vitkovsky; cisco-nsp at puck.nether.net
> Subject: Re: LDP sessions established to non directly connected routers,
> when new link is activated
>
>
> Hi Adam,
>
> Good to hear your enjoying the new Job - And Im certainly looking forward
> to summer also! :)
>
> To answer your question - Yes - The ME02, that connects to the ASR1006 has
> a vlan interface....so we may be getting hit with this bug, although, we are
> using the link that runs through the 2 ME3600's(MPLS/OSPF/BGP) currently,
> without issue?
>
> re MPLS ping - Very strange - It is saying it is up on both routers(sh mpls ldp
> nei, and logs report LDP nei is up on both routers, once mpls ip is enabled on
> each Int), but I cannot mpls ping the loop (From ASR2 POPA -> ASR1006
> POPD)?
>
>
> Cheers
>
> ________________________________________
> From: Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> Sent: Thursday, 24 September 2015 10:52 PM
> To: CiscoNSP List; cisco-nsp at puck.nether.net
> Subject: RE: LDP sessions established to non directly connected routers,
> when new link is activated
>
> Hi Michael,
>
> Yeah it's been a while :) I'm doing good, enjoying my new job.
> And how are you, I envy you the upcoming Summer :)
>
> I'm wondering whether you have some VLAN interfaces that are configured
> as MPLS interfaces on the MEs.
> There's this bug where if VLAN interface/mpls link is computed as LFA backup
> link then forwarding on the ME box is disrupted.
> That could explain the BGP sessions but that would affect other traffic going
> through the box.
>
> Also if you could perform mpls ping over the new link does it work please?
>
> adam
> >
>
>         Adam Vitkovsky
>         IP Engineer
>
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk
> W:      www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or forward
> all or any of it in any form (unless otherwise notified). If you receive this
> email in error, please accept our apologies, we would be obliged if you would
> telephone our postmaster on +44 (0) 808 178 9652 or email
> postmaster at gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales,
> with limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
> -----Original Message-----
> > From: CiscoNSP List [mailto:CiscoNSP_list at hotmail.com]
> > Sent: Wednesday, September 23, 2015 10:28 AM
> > To: Adam Vitkovsky; cisco-nsp at puck.nether.net
> > Subject: Re: LDP sessions established to non directly connected
> > routers, when new link is activated
> >
> > Hi Adam - Long time no speak...how have you been?
> >
> > Yes - Checked all routers, no tLDP sessions configured(To the routers
> > the "new" LDP sessions establish), we have xconnects from the ME3600's
> > in POPB -> ME3600's in POPA, but none from POPA -> POPC ASR1006 - And
> > as you mention, they would come come up over the existing path, but
> > only come up when this new link is activated.
> >
> > Once BGP fails to the three routers(Which is almost immediately after
> > the "new" LDP sessions establish), it stays down, and only recovers
> > once I re- apply the high OSPF cost to the new link...mtu's are
> > definitely different(As we purchase them from different
> > carriers)....but as soon as the LDP sessions establish, I am not even able to
> ping the routers that lose BGP.
> >
> > POPC(ASR1006) -> POPB (ME3600) mtu 1552
> > POPB(ME3600)->POPA(ASR1001) mtu 3000
> > POPA(ASR1001-2) -> POPD(ASR1006) mtu 1950
> >
> >
> > Very strange one indeed :)
> >
> >
> >
> > ________________________________________
> > From: Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> > Sent: Wednesday, 23 September 2015 6:11 PM
> > To: CiscoNSP List; cisco-nsp at puck.nether.net
> > Subject: RE: LDP sessions established to non directly connected
> > routers, when new link is activated
> >
> > Hi,
> >
> > Have you checked both ends if either end has a tLDP session configured
> > it would come up.
> > Also xconnects are using targeted LDP sessions, isn't there some
> > forgotten xconnect pointing to these routers somewhere?
> > But then the question is why the session wouldn't be formed over the
> > existing path.
> >
> > With regards to BGP failing are the sessions then re-established or
> > they remain down please?
> > I suspect it could be an MTU problem that is some of the links on the
> > new path ASR2(POPA) to ASR1(POPD) to ASR1(POPC) -have lower MTU
> than
> > the links on the existing path via POPB.
> >
> >
> > adam
> > >
> >
> >         Adam Vitkovsky
> >         IP Engineer
> >
> > T:      0333 006 5936
> > E:      Adam.Vitkovsky at gamma.co.uk
> > W:      www.gamma.co.uk
> >
> > This is an email from Gamma Telecom Ltd, trading as “Gamma”. The
> > contents of this email are confidential to the ordinary user of the
> > email address to which it was addressed. This email is not intended to
> > create any legal relationship. No one else may place any reliance upon
> > it, or copy or forward all or any of it in any form (unless otherwise
> > notified). If you receive this email in error, please accept our
> > apologies, we would be obliged if you would telephone our postmaster
> > on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk
> >
> > Gamma Telecom Limited, a company incorporated in England and Wales,
> > with limited liability, with registered number 04340834, and whose
> > registered office is at 5 Fleet Place London EC4M 7RD and whose
> > principal place of business is at Kings House, Kings Road West, Newbury,
> Berkshire, RG14 5BY.
> >
> >
> > -----Original Message-----
> > > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
> > > Of CiscoNSP List
> > > Sent: 22 September 2015 23:59
> > > To: cisco-nsp at puck.nether.net
> > > Subject: [c-nsp] LDP sessions established to non directly connected
> > > routers, when new link is activated
> > >
> > > Hi Everyone,
> > >
> > >
> > >
> > > Bit of a strange one.
> > >
> > >
> > >
> > > 2 x ASR1001's (ASR1 and ASR2) directly connected (POPA), with OSPF,
> > > MPLS and BGP established
> > >
> > >
> > >
> > > ASR1 connects to POPB (ME36001), also with OSPF, MPLS and BGP
> > > established
> > >
> > >
> > >
> > > ME36001 connects to ME36002 at POPB, also with OSPF, MPLS and BGP
> > > established
> > >
> > >
> > >
> > > ME36002 connects to an ASR1006 at POPC, also with OSPF, MPLS and BGP
> > > established
> > >
> > >
> > >
> > > We have a new link connecting to ASR2(POPA) that goes to POPD, also
> > > with OSPF, MPLS and BGP established - but OSPF cost set high so that
> > > it is not used...due to a strange outage it causes when OSPF is set
> > > to no
> > cost.
> > >
> > >
> > >
> > > As soon as the new link on ASR2(POPA) and ASR1006(POPD) OSPF is set
> > > to no cost, ASR2(POPA) for some reason establishes LDP to
> > > ME36002(POPC) - but it has no direct connection to this device, nor
> > > is targetted LDP enabled to this device, and ASR1(POPA) establishes
> > > LDP to
> > > ASR1006(POPC) - but it also has no direct connection to this device,
> > > nor is targetted LDP enabled to this device....result of these LDP
> > > sessions establishing is ASR1(POPA) losing BGP neighbourships to
> > > three other routers that are connected via the ASR1006(POPC).
> > >
> > >
> > >
> > > Ive opened a TAC case, but if anyone can explain how/why the LDP
> > > sessions would establish when this new link is "activated" it would
> > > be greatly appreciated!
> > >
> > >
> > >
> > > Cheers.
> > > _______________________________________________
> > > 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/


More information about the cisco-nsp mailing list