Re: BGP graceful restart for software update only?
Hi Vincent, On Thu, Oct 17, 2019 at 1:05 PM Vincent Bernat wrote: > ❦ 17 octobre 2019 11:29 +01, Neil Jerram : > > > In my setup, an instance of BIRD runs all the time, except for when it > > needs to be restarted for a software update. > > > > For that update scenario, I'd like BGP graceful restart to apply, so that > > the stop-update-restart process does not cause the routes advertised by > > this BIRD to be withdrawn from the rest of the BGP network. > > > > For all other scenarios, however, I don't want any graceful restart. > > Specifically, if there's a break in connectivity to a BGP peer, I want to > > detect that as quickly as possible (with BFD), locally to remove the > routes > > learned from that peer, and for that peer to remove routes learned from > me, > > all immediately. > > > > Is there some combination of configuration and procedure that can provide > > both of those desires? > > You should look at the long lived graceful restart alternative. It will > enable you to do software upgrades without impact without keeping routes > around when a BGP session is cut unexpectedly, as long as you have > alternative routes available. > I have indeed been looking at LLGR, and I'm very grateful for your blog about it. I'm not sure I'm persuaded by your argument, though, that LLGR is desirable because BFD could generate a false negative. Wouldn't it be better to eliminate those false negatives by allowing BFD to run a more slowly and/or with a larger multiplier? IIUC, the benefit of GR, for a planned software update, is that it can completely avoid any route flapping in the connected BGP peers - in terms both of the data path and the BGP control plane. With LLGR in that scenario, I believe there will be BGP control plane traffic, and other BIRDs updating their local kernel with least-preferred routes. I suppose it is still true that there is no data path flapping, but there *has* been a lot of control plane churn, which traditional GR would have avoided. Is that understanding all correct? Best wishes, Neil
Re: BGP graceful restart for software update only?
❦ 17 octobre 2019 11:29 +01, Neil Jerram : > In my setup, an instance of BIRD runs all the time, except for when it > needs to be restarted for a software update. > > For that update scenario, I'd like BGP graceful restart to apply, so that > the stop-update-restart process does not cause the routes advertised by > this BIRD to be withdrawn from the rest of the BGP network. > > For all other scenarios, however, I don't want any graceful restart. > Specifically, if there's a break in connectivity to a BGP peer, I want to > detect that as quickly as possible (with BFD), locally to remove the routes > learned from that peer, and for that peer to remove routes learned from me, > all immediately. > > Is there some combination of configuration and procedure that can provide > both of those desires? You should look at the long lived graceful restart alternative. It will enable you to do software upgrades without impact without keeping routes around when a BGP session is cut unexpectedly, as long as you have alternative routes available. -- Terminate input by end-of-file or marker, not by count. - The Elements of Programming Style (Kernighan & Plauger)
BGP graceful restart for software update only?
In my setup, an instance of BIRD runs all the time, except for when it needs to be restarted for a software update. For that update scenario, I'd like BGP graceful restart to apply, so that the stop-update-restart process does not cause the routes advertised by this BIRD to be withdrawn from the rest of the BGP network. For all other scenarios, however, I don't want any graceful restart. Specifically, if there's a break in connectivity to a BGP peer, I want to detect that as quickly as possible (with BFD), locally to remove the routes learned from that peer, and for that peer to remove routes learned from me, all immediately. Is there some combination of configuration and procedure that can provide both of those desires? Many thanks, Neil
Re: next-hop-self for non-reflected routes only?
On Mon, Oct 14, 2019 at 3:07 PM Ondrej Zajicek wrote: > On Mon, Oct 14, 2019 at 02:45:37PM +0100, Neil Jerram wrote: > > > We implemented extension for next-hop-self in version 2.0.3 that allows > > > to specify 'next hop self ebgp', this solves exactly this issue. > > > > > > For older versions, you would need to workaround that in filters, > > > something like: > > > > > > if proto = "bgpX" then > > > bgp_next_hop = A.b.C.D; > > > > > > > Thanks Ondrej. Am I right in thinking that I should do this in the > import > > filter? (From reading the code, it appears that "next hop self" takes > > effect on import.) > > No, in the export filter. You import the route with the original next hop > (e.g. one from AS 65001), but when exported to B,C it is reset to the > local value. > Many thanks, I'll try this. Neil
Re: How to enter static prefix with multiple nexthops but no ECMP?
On Wed, Oct 16, 2019 at 02:52:10PM +, Kenth Eriksson wrote: > On Wed, 2019-10-16 at 16:43 +0200, Ondrej Zajicek wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > On Wed, Oct 16, 2019 at 01:41:45PM +, Kenth Eriksson wrote: > > > Hi! > > > > > > Does bird support a static prefix with multiple nexthops, without > > > installing all of them in the kernel as ECMP? > > > > Hi > > > > I think that you are talking about multiple routes/paths with the same > > prefix. Static protocol currently does not support that (and behaves > > strangely when such multiple routes are defined). Simple workaround > > is to define multple static protocol instances. We have a patch for > > multiple static routes with the same prefix and different preference > > in one static protocol (commit 9861dba5230da539e6ce7d2b6baa4f2631556d09), > > but we plan to rewrite that significantly before merging to master. > > > > Ok, thanks for clarifying that. What is the target release for that > feature? Probably something like 2.0.8-9. The design of our protocol-table interface requires that if i have multiple routes with the same networks, there must be an u32 value that distinguishes them (that is inspired by BGP ADD-PATH design). In the patch above we used preference for this distinguisher, but later we got some feedback that it may be more useful to have IGP-comparable metric (i.e. igp_metric attribute) for this (so multiple routes with the same preference and different igp_metric can be used). Another possibility is to have separate 'id' argument for distinguisher unrelated to any real attribute, but that may be inconvenient for users. Yet another possibility is to have some automatic 'id' assignment based on all static route attribute through hash table, but that seems like a too much / unnecessary work. So i would like to get some feedback w.r.t. that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
