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

[Ondrej Zajicek]

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.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181210/43778df4/attachment.sig>