<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5">
</HEAD>
<BODY>
Hello Michael.<BR>
<BR>
Just report our results.<BR>
<BR>
After removing BGP upstream configuration (commented out), run<BR>
"config", our traffic was instantly directed to the rest of BGP<BR>
sessions.<BR>
<BR>
We didn't lose any traffic (at least noticeable) during the transition.<BR>
This confirms your response and Ondrej's: it takes seconds or at most a<BR>
few minutes (not hours).<BR>
<BR>
Also confirm condition change you are describing: most of the traffic<BR>
was directed to a less preferable BGP session because it has same<BR>
As-path length and bigger uptime. <BR>
<BR>
We will have to increase as-path length by prepending (export filter {<BR>
... bgp_path.prepend .. } at the BGP session we want to have with less<BR>
weight).<BR>
<BR>
Given these results, it is not necessary to increase AS-path length<BR>
before shutting down the session: it is already fast and smooth.<BR>
<BR>
Best Regards.<BR>
<BR>
<BR>
El mar, 11-12-2018 a las 17:05 +0600, Michael Rack escribió:
<BLOCKQUOTE TYPE=CITE>
Correct, it will remove routes faster. This is because of the logic behind BGP.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
If you add a new upstream peer / transit peer the new route will not be in use if the as-path is the same as the old one. Traffic is directed to that port wich session that have longer uptime.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
The routes gets active when a condition will change.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
But back to your question in timeouting a BGP Session. When a BGP Session will timeoute, your neighbor will send withdraws to his neighbors. So after 20secs no neighbour will see the route to your shutted down interface anymore.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Correct: Shutdown Inferace after traffic disappears.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Am Mo., 10. Dez. 2018, 15:33 hat Francis Brosnan Blázquez <<A HREF="mailto:francis.brosnan@aspl.es">francis.brosnan@aspl.es</A>> geschrieben:<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Hello Michael.<BR>
<BR>
Thanks for the info; very useful. <BR>
<BR>
Considering this, could we say BGP is faster removing routes when<BR>
session is lost/closed/shut down than when they are added?<BR>
<BR>
Even though you start receiving traffic right away you setup a BGP<BR>
session, we have seen it takes hours (even days) to fully propagate new<BR>
BGP upstream we added in the past.<BR>
<BR>
Did you find this behavior too?<BR>
<BR>
Thanks Michael.<BR>
Best Regards.<BR>
<BR>
<BR>
PD: Just to clarify point 2) Another solution is to just shutdown BGP<BR>
session but leave upstream connected and configured (so outdated<BR>
routers we still reach us...) <B>AND unplug the cable after traffic disappears.</B><BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
We are using option number 2.<BR>
<BR>
<BR>
After 600 seconds, all routes via the shutted down peer will get invalid.<BR>
<BR>
<BR>
So just wait 10 Minutes and your inbound traffic should stop.<BR>
<BR>
<BR>
.........<BR>
<BR>
<BR>
But there was a another thread with a feature request to send withdraws to your peer, so you can immediatley shutdown your network interface after shutting down the bgp session.<BR>
<BR>
<BR>
<BR>
Am Sa., 8. Dez. 2018, 04:03 hat Francis Brosnan Blázquez <<A HREF="mailto:francis.brosnan@aspl.es">francis.brosnan@aspl.es</A>> geschrieben:<BR>
<BR>
<BLOCKQUOTE>
Hello.<BR>
<BR>
We are using bird with several upstream providers, all of them with a<BR>
share of traffic.<BR>
<BR>
We are in the process of shutting down one of them but we are unsure<BR>
how to proceed to minimize loss of traffic.<BR>
<BR>
We have been reading and looking for general recommendations but it is<BR>
not clear (besides using graceful shutdown which is not supported by<BR>
the upstream we want to shutdown).<BR>
<BR>
We have been looking at mailing list but we haven't found anything<BR>
treating this matter.<BR>
<BR>
So far, solutions we have come up are:<BR>
<BR>
1) Use AS-path prepend to increase metric on the uptstream to be<BR>
shutted down and once nearly no traffic comes in through that link, shutdown<BR>
BGP and unplug. Something like:<BR>
<BR>
export filter { <BR>
<BR>
if source = RTS_STATIC then { # Export only static routes <BR>
# Assign our community <BR>
bgp_community.add((65000,64501)); <BR>
# Artificially increase path length <BR>
# by advertising local AS number twice <BR>
if bgp_path ~ [= 65000 =] then <BR>
bgp_path.prepend(65000);<BR>
bgp_path.prepend(65000);<BR>
accept; <BR>
} <BR>
reject; <BR>
}; <BR>
<BR>
2) Another solution is to just shutdown BGP session but leave upstream<BR>
connected and configured (so outdated routers we still reach us...).<BR>
<BR>
3) And the obvious, just shutdown BGP session and unplug the cable.<BR>
<BR>
It would be great to know your opinion and what's the recommended way<BR>
to proceed. <BR>
<BR>
What do you think?<BR>
<BR>
Many thanks<BR>
Best Regards.<BR>
<BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Francis Brosnan Blázquez - ASPL
<A HREF="http://www.asplhosting.com/">http://www.asplhosting.com/</A>
<A HREF="http://www.aspl.es/">http://www.aspl.es/</A>
<A HREF="https://twitter.com/aspl_es">https://twitter.com/aspl_es</A>
<A HREF="https://twitter.com/asplhosting">https://twitter.com/asplhosting</A>
<A HREF="https://twitter.com/francisbrosnanb">https://twitter.com/francisbrosnanb</A>
<A HREF="https://es.linkedin.com/in/francis-brosnan-bl%C3%A1zquez-1353a218">https://es.linkedin.com/in/francis-brosnan-blázquez-1353a218</A>
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)
</PRE>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
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).
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>