<!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 Ondrej,<BR>
<BR>
Thanks for the response. Ok to bgp locl preference propagation. <BR>
<BR>
Also confirm that removing bird upstream configuration triggers<BR>
instantly traffic to be directed/received over the rest of BGP<BR>
sessions.<BR>
<BR>
Best Regards.<BR>
<BR>
El lun, 10-12-2018 a las 14:57 +0100, Ondrej Zajicek escribió:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Mon, Dec 10, 2018 at 10:47:32AM +0100, Francis Brosnan Blázquez wrote:
<FONT COLOR="#737373">> Hello Kurt.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> By your solution, would it be possible to announce no prefix over the</FONT>
<FONT COLOR="#737373">> upstream that you want to shutdown (export none;)? </FONT>
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.
<FONT COLOR="#737373">> About "local preference", I thought it is only applicable for IBGP not</FONT>
<FONT COLOR="#737373">> for EBGP but it seems it can now be used for eBGP neighbors (as</FONT>
<FONT COLOR="#737373">> described by allow bgp_local_pref switch at bird BGP doc).</FONT>
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.
<FONT COLOR="#737373">> Considering this, could we say BGP is faster removing routes when</FONT>
<FONT COLOR="#737373">> session is lost/closed/shut down than when they are added?</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> Even though you start receiving traffic right away you setup a BGP</FONT>
<FONT COLOR="#737373">> session, we have seen it takes hours (even days) to fully propagate new</FONT>
<FONT COLOR="#737373">> BGP upstream we added in the past.</FONT>
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.
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>