Re: Recommended way to shutdown a working BGP session -- ordered bgp session stop -- bgp session shutdown
Hello Kurt. By your solution, would it be possible to announce no prefix over the upstream that you want to shutdown (export none;)? 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). We will keep you updated with our results so others can take advantage of them too. Best Regards.
You could announce more specific routes on the upstream that you want to keep and make sure you're outgoing traffic goes via the upstream you want to keep by example higher local pref.
kurt
Op vr 7 dec. 2018 22:53 schreef Francis Brosnan Blázquez <francis.brosnan@aspl.es:
Hello.
We are using bird with several upstream providers, all of them with a share of traffic.
We are in the process of shutting down one of them but we are unsure how to proceed to minimize loss of traffic.
We have been reading and looking for general recommendations but it is not clear (besides using graceful shutdown which is not supported by the upstream we want to shutdown).
We have been looking at mailing list but we haven't found anything treating this matter.
So far, solutions we have come up are:
1) Use AS-path prepend to increase metric on the uptstream to be shutted down and once nearly no traffic comes in through that link, shutdown BGP and unplug. Something like:
export filter {
if source = RTS_STATIC then { # Export only static routes # Assign our community
bgp_community.add((65000,64501)); # Artificially increase path length # by advertising local AS number twice if bgp_path ~ [= 65000 =] then bgp_path.prepend(65000); bgp_path.prepend(65000);
accept; }
reject; };
2) Another solution is to just shutdown BGP session but leave upstream connected and configured (so outdated routers we still reach us...).
3) And the obvious, just shutdown BGP session and unplug the cable.
It would be great to know your opinion and what's the recommended way to proceed.
What do you think?
Many thanks Best Regards.
-- Francis Brosnan Blázquez - ASPL http://www.asplhosting.com/ http://www.aspl.es/ https://twitter.com/aspl_es https://twitter.com/asplhosting https://twitter.com/francisbrosnanb https://es.linkedin.com/in/francis-brosnan-blázquez-1353a218 91 134 14 22 - 91 134 14 45 - 91 116 07 57 Av. Juan Carlos I 13, 2ºC, Torre Garena 28806 - Alcalá de Henares (España) AVISO LEGAL En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). ASPL garantiza que los datos serán tratados con la finalidad de mantener las oportunas relaciones comerciales o promocionales con usted o la entidad que usted representa. No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a ASPL - Protección Datos, Av. Juan Carlos I 13, 2ºC, Alcalá de Henares (Madrid).
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@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."
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.
participants (2)
-
Francis Brosnan Blázquez -
Ondrej Zajicek