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. >