Recommended way to shutdown a working BGP session -- ordered bgp session stop -- bgp session shutdown

[Francis Brosnan Blázquez]

Hello Ondrej,

Thanks for the response. Ok to bgp locl preference propagation. 

Also confirm that removing bird upstream configuration triggers
instantly traffic to be directed/received over the rest of BGP
sessions.

Best Regards.

El lun, 10-12-2018 a las 14:57 +0100, Ondrej Zajicek escribió:

> On Mon, Dec 10, 2018 at 10:47:32AM +0100, Francis Brosnan Blázquez wrote:
> > Hello Kurt.
> > 
> > By your solution, would it be possible to announce no prefix over the
> > upstream that you want to shutdown (export none;)?  
> 
> Hello
> 
> Generally it does not matter if you announce no prefixes, withdraw old ones,
> or just shutdown the BGP session.
> 
> Announcing your prefixes with artificially increased path first before
> shutting the session altogether could make it more smooth, i.e. it could
> avoid some transient packet loss during convergence to a new upstream,
> but you cannot force all the traffic away - e.g. traffic from that
> upstream and its other clients would be most likely directed through
> that link any way due to bgp_local_pref configured by the upstream.
> 
> That is the advantage of announcing more specific routes by the new
> upstream link - it will override even the bgp_local_pref of the
> upstream ISP.
> 
> 
> > About "local preference", I thought it is only applicable for IBGP not
> > for EBGP but it seems it can now be used for eBGP neighbors (as
> > described by allow bgp_local_pref switch at bird BGP doc).
> 
> bgp_local_pref is applicable to both EBGP and IBGP routes, but it is not
> *propagated* over EBGP sessions. Essentially you mark an incoming route
> with bgp_local_pref on EBGP session and then propagate it unmodified on
> IBGP sessions, so all your routers have routes with consistent
> bgp_local_pref values.
> 
> 
> > Considering this, could we say BGP is faster removing routes when
> > session is lost/closed/shut down than when they are added?
> > 
> > Even though you start receiving traffic right away you setup a BGP
> > session, we have seen it takes hours (even days) to fully propagate new
> > BGP upstream we added in the past.
> 
> Both adding and removing should be fast (e.g. at most minutes). If it
> takes hours or days than it is most likely that prefixes were blocked by
> filters and there was a manual intervention or a periodic reconfiguration
> of filters from public databases.
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181217/30edea83/attachment.html>