Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-16 Thread Adam Vitkovsky
Do you folks experience this only in scenarios without backup please?

My understanding is that this should not be happening if the prefixes are 
maintained in the FIB by means of switching from backup NH back to primary NH

But I recognize it is a problem even with a single NH
I'm thinking if the NH disappears do all these routes actually need to be 
deleted?
Can't they be just marked inactive and reactivated once the eBGP session comes 
up? Something like graceful restart.

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@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 postmas...@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.
---
 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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread heasley
Thu, Sep 15, 2016 at 03:08:18PM +0300, Saku Ytti:
> Hey Octavio,
> 
> > We are noticing our ASR 1002 is propagating BGP-learned routes to its
> > neighbors after the path is chosen but before the route gets installed
> > in the FIB.
> >
> > With the increasing size of the BGP table, this is causing race
> > conditions that turn into traffic loops during convergence. The router
> > attracts traffic but returns it back to somebody else because the route
> > is not yet in the FIB or it is outdated in the FIB.
> >
> > Is there a way to force the router to wait until a route is installed
> > all the way in the FIB before having it propagated to the neighbors?
> 
> I don't think so. This is issue which has plagued Juniper RPD for years.
> 
> Technically I believe fix would be to add flag to FIB entries
> signalling HW presence. Then when HW installs it, it should raise
> interrupt or such, to get this flag inserted. But it might be that HW
> does not support this (At any reasonable performance).

increasing the advertisement-interval might improve the probability that
routes are installed before being adverstised...but will increase AS-wide
convergence time.
___
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/


Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread John East
On Wed, Sep 14, 2016 at 8:03 PM, Octavio Alvarez 
wrote:

> Hello.
>
> We are noticing our ASR 1002 is propagating BGP-learned routes to its
> neighbors after the path is chosen but before the route gets installed
> in the FIB.
>
> With the increasing size of the BGP table, this is causing race
> conditions that turn into traffic loops during convergence. The router
> attracts traffic but returns it back to somebody else because the route
> is not yet in the FIB or it is outdated in the FIB.
>
> Is there a way to force the router to wait until a route is installed
> all the way in the FIB before having it propagated to the neighbors?
>
> Thanks.
> ___
>

I've had to engineer around this, as we had 4 ASR1002s taking in full
routes from several providers and ran into this very issue.  This also was
a catalyst to replace them with ASR9001s at the edge.  It seems like a flaw
in the ASR1000 series.

John
___
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/


Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread Youssef Bengelloun-Zahr
One is never too precautious I guess ;-)

Y.



> Le 15 sept. 2016 à 14:15, Gert Doering  a écrit :
> 
> Hi,
> 
>> On Thu, Sep 15, 2016 at 03:08:18PM +0300, Saku Ytti wrote:
>> I don't think so. This is issue which has plagued Juniper RPD for years.
>> 
>> Technically I believe fix would be to add flag to FIB entries
>> signalling HW presence. Then when HW installs it, it should raise
>> interrupt or such, to get this flag inserted. But it might be that HW
>> does not support this (At any reasonable performance).
> 
> IOS XR has "update wait-install", which supposedly does this: only forward
> updates when they've been successfully installed into the forwarding 
> hardware.
> 
> (Supposedly this is only needed on gen1 line cards, because gen2 "are fast
> enough", but it still sounded like a good idea to me :-) )
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>   //www.muc.de/~gert/
> Gert Doering - Munich, Germany g...@greenie.muc.de
> fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
> ___
> 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/

Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread Gert Doering
Hi,

On Thu, Sep 15, 2016 at 04:47:28PM +0200, Youssef Bengelloun-Zahr wrote:
> One is never too precautious I guess ;-)

Well... people tell me I shouldn't enable stuff I do not need - in this
case, on IOS XR 4.3.4 on ASR9001, this can lead to "the FIB process 
deadlocks", and subsequently BGP locks up, waiting for FIB, and then the 
machine starts acting seriously weird...

(Fixed now, in SP4 or so)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
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/

Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread Lukas Tribus
Hi,

> I've personally not seen this yet (in bothersome level) in any Cisco
> gear, so this is very interesting observation, I sort of assumed what
> every Cisco is doing, they're doing in manner that they are protected
> from this problem. Thanks for the heads up!

This definitely is a problem. Like mentioned before in the other thread, my 
ASR1000-RP1 needs 30 minutes to programm the full table in a VRF into the HW.


I reduced the impact in my network by making sure the ingress PE is the only 
node actual doing an IP lookup (per-ce label assignment).


Lukas
___
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/


Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread Gert Doering
Hi,

On Thu, Sep 15, 2016 at 03:08:18PM +0300, Saku Ytti wrote:
> I don't think so. This is issue which has plagued Juniper RPD for years.
> 
> Technically I believe fix would be to add flag to FIB entries
> signalling HW presence. Then when HW installs it, it should raise
> interrupt or such, to get this flag inserted. But it might be that HW
> does not support this (At any reasonable performance).

IOS XR has "update wait-install", which supposedly does this: only forward
updates when they've been successfully installed into the forwarding 
hardware.

(Supposedly this is only needed on gen1 line cards, because gen2 "are fast
enough", but it still sounded like a good idea to me :-) )

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
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/

Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

2016-09-15 Thread Saku Ytti
Hey Octavio,

> We are noticing our ASR 1002 is propagating BGP-learned routes to its
> neighbors after the path is chosen but before the route gets installed
> in the FIB.
>
> With the increasing size of the BGP table, this is causing race
> conditions that turn into traffic loops during convergence. The router
> attracts traffic but returns it back to somebody else because the route
> is not yet in the FIB or it is outdated in the FIB.
>
> Is there a way to force the router to wait until a route is installed
> all the way in the FIB before having it propagated to the neighbors?

I don't think so. This is issue which has plagued Juniper RPD for years.

Technically I believe fix would be to add flag to FIB entries
signalling HW presence. Then when HW installs it, it should raise
interrupt or such, to get this flag inserted. But it might be that HW
does not support this (At any reasonable performance).

I've personally not seen this yet (in bothersome level) in any Cisco
gear, so this is very interesting observation, I sort of assumed what
every Cisco is doing, they're doing in manner that they are protected
from this problem. Thanks for the heads up!

-- 
  ++ytti
___
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/