Mailing List Archive

Hi Marcin,
There was a thread on the topic of slow FIB download/upload on this forum
some time back.

Yes BGP will advertise the best path regardless of the FIB state by default.
I'd recommend enabling it. (though subject to testing on your code version
as always)

adam
> -----Original Message-----
> From: cisco-nsp <cisco-nsp-bounces@puck.nether.net> On Behalf Of Marcin
> Kurek
> Sent: Friday, February 21, 2020 10:40 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency
>
> Hi all,
>
> During a recent MW I ran into a fishy situation.
>
> Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it
went
> back online I noticed slow route installation in FIB. It took around 20
minutes
> to install > 700k prefixes.
>
> Apparently, some customers experienced problems at that time, so I'm
> suspecting some RIB/FIB inconsistency here.
>
> I've been researching this topic for a while and now I'm even more
confused.
>
> Can someone help me answer below questions, please?
>
> Assuming our router has established its e/iBGP sessions and finished
> receiving updates from its neighbors, will it advertise its best paths
even
> though FIB programming is still in progress?
>
> Common sense answer would be "no", because if it starts advertising
> prefixes that are not installed in FIB, it also starts attracting and
possibly
> blackholing traffic.
>
> But I discovered the command "update wait-install" as part of BGP RIB
> feedback mechanism introduced in XR 4.3. When it's enabled, routes that
> have not been installed in FIB are not advertised. Looks like that it's
turned
> off by default though.
>
> If so, the answer to my 1st question should be "yes", although to me, it
> doesn't make much sense.
>
> I've been trying to find best practices / recommendations for that
command,
> but without luck.
>
> Can anyone shed some light on that, please?
>
> Thanks,
>
> marcin
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 26/Feb/20 15:13, adamv0025@netconsultings.com wrote:

> Hi Marcin,
> There was a thread on the topic of slow FIB download/upload on this forum
> some time back.
>
> Yes BGP will advertise the best path regardless of the FIB state by default.
> I'd recommend enabling it. (though subject to testing on your code version
> as always)

So our ASR9001's have reached their end of their usefulness.

We had 5 running peering, and 3 of them were struggling with local BGP
updates, CPU handling of the BGP process, slow convergence, e.t.c.

Swapped those out with MX204's recently, and the remaining 2 are to be
done in about a month or so.

We've sent them to same place we sent our MX80's and MX104's. They're done.

Hopefully, these will be the last non-x86 boxes we ever see these
vendors pushing out :-).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi Adam,

Thanks for the reply. I'm still in doubt though.

If we look here for example:

https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/

we see that BGP programming speed is always faster than FIB programming
speed.

If best path is advertised regardless of the FIB state by default, this
would always mean a potential for longer/shorter blackhole...

Thanks,
Marcin

W dniu 26.02.2020 o 14:13, adamv0025@netconsultings.com pisze:
> Hi Marcin,
> There was a thread on the topic of slow FIB download/upload on this forum
> some time back.
>
> Yes BGP will advertise the best path regardless of the FIB state by default.
> I'd recommend enabling it. (though subject to testing on your code version
> as always)
>
> adam
>> -----Original Message-----
>> From: cisco-nsp <cisco-nsp-bounces@puck.nether.net> On Behalf Of Marcin
>> Kurek
>> Sent: Friday, February 21, 2020 10:40 AM
>> To: cisco-nsp@puck.nether.net
>> Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency
>>
>> Hi all,
>>
>> During a recent MW I ran into a fishy situation.
>>
>> Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it
> went
>> back online I noticed slow route installation in FIB. It took around 20
> minutes
>> to install > 700k prefixes.
>>
>> Apparently, some customers experienced problems at that time, so I'm
>> suspecting some RIB/FIB inconsistency here.
>>
>> I've been researching this topic for a while and now I'm even more
> confused.
>> Can someone help me answer below questions, please?
>>
>> Assuming our router has established its e/iBGP sessions and finished
>> receiving updates from its neighbors, will it advertise its best paths
> even
>> though FIB programming is still in progress?
>>
>> Common sense answer would be "no", because if it starts advertising
>> prefixes that are not installed in FIB, it also starts attracting and
> possibly
>> blackholing traffic.
>>
>> But I discovered the command "update wait-install" as part of BGP RIB
>> feedback mechanism introduced in XR 4.3. When it's enabled, routes that
>> have not been installed in FIB are not advertised. Looks like that it's
> turned
>> off by default though.
>>
>> If so, the answer to my 1st question should be "yes", although to me, it
>> doesn't make much sense.
>>
>> I've been trying to find best practices / recommendations for that
> command,
>> but without luck.
>>
>> Can anyone shed some light on that, please?
>>
>> Thanks,
>>
>> marcin
>>
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi Marcin,

Well yes you’re right, hence the path in form of a “update wait-install” feature,

Though the best remedy to this slow FIB programming problem is to maintain the FIB entries no matter what,

Opt1 Having two sessions on a single box in case one fails the other will keep the FIB entries in place -just NH changes would follow -which in todays hierarchical FIBs is a single pointer change operation.

Opt2 “advertise best external” feature so in case you have a box with just a single eBGP session it learns prefixes via iBGP from some other border node with the “advertise best external” feature enabled.



adam



From: Marcin Kurek <md.kurek@gmail.com>
Sent: Friday, February 28, 2020 1:19 PM
To: adamv0025@netconsultings.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency



Hi Adam,

Thanks for the reply. I'm still in doubt though.

If we look here for example:

<https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/> https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/

we see that BGP programming speed is always faster than FIB programming speed.

If best path is advertised regardless of the FIB state by default, this would always mean a potential for longer/shorter blackhole...

Thanks,
Marcin

W dniu 26.02.2020 o 14:13, adamv0025@netconsultings.com <mailto:adamv0025@netconsultings.com> pisze:

Hi Marcin,
There was a thread on the topic of slow FIB download/upload on this forum
some time back.

Yes BGP will advertise the best path regardless of the FIB state by default.
I'd recommend enabling it. (though subject to testing on your code version
as always)

adam

-----Original Message-----
From: cisco-nsp <mailto:cisco-nsp-bounces@puck.nether.net> <cisco-nsp-bounces@puck.nether.net> On Behalf Of Marcin
Kurek
Sent: Friday, February 21, 2020 10:40 AM
To: cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net>
Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

Hi all,

During a recent MW I ran into a fishy situation.

Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it

went

back online I noticed slow route installation in FIB. It took around 20

minutes

to install > 700k prefixes.

Apparently, some customers experienced problems at that time, so I'm
suspecting some RIB/FIB inconsistency here.

I've been researching this topic for a while and now I'm even more

confused.


Can someone help me answer below questions, please?

Assuming our router has established its e/iBGP sessions and finished
receiving updates from its neighbors, will it advertise its best paths

even

though FIB programming is still in progress?

Common sense answer would be "no", because if it starts advertising
prefixes that are not installed in FIB, it also starts attracting and

possibly

blackholing traffic.

But I discovered the command "update wait-install" as part of BGP RIB
feedback mechanism introduced in XR 4.3. When it's enabled, routes that
have not been installed in FIB are not advertised. Looks like that it's

turned

off by default though.

If so, the answer to my 1st question should be "yes", although to me, it
doesn't make much sense.

I've been trying to find best practices / recommendations for that

command,

but without luck.

Can anyone shed some light on that, please?

Thanks,

marcin




_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Fri, Feb 28, 2020 at 02:18:56PM +0100, Marcin Kurek wrote:
> If best path is advertised regardless of the FIB state by default, this
> would always mean a potential for longer/shorter blackhole...

Unless you do stuff like labeled unicast which does not need the
prefix to be in the local FIB, as long as the label is programmed...

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de