Re: Graceful shutdown request signal
Hi Erin, On Tue, Jun 20, 2023 at 08:20:50PM +0200, Erin Shepherd wrote: > I run bird on a system which uses systemd as a service supervisor, and > would like to implement graceful restart in a way which works well with > it. I'm also interested in getting this working. I'm wondering how graceful restart is supposed to behave to begin with though. Last time I just tried `birdc graceful restart` I was surprised that this actually makes bird exit with rv=0 instead of ... well actually restarting. Is that normal or a bug in the Debian packaging/systemd service? I suppose if you're supposed to use graceful restart just before rebooting the system it makes sense but at the time I just wanted to do a full restart to update the running bird executable without causing traffic disruption and was rather surprised when it didn't come back up. > In particular, what I'd like to do is: > • If I restart the bird service (e.g. for an upgrade), Bird performs a > graceful restart > • If I manually stop bird (systemctl stop bird2), shutdown the system, or > any other action which is liable to cause a longer period of downtime, > perform a graceful restart (for BGP at least) When you want to tickle special behaviour out of systemd I found it best to not try and do everything in one unit. Using the dependency system you can stop another unit before bird.service gets stopped, this can then call birdc graceful restart, like this: bird-graceful-restart.service: [Unit] After=bird.service Requires=bird.service [Service] Type=oneshot RemainAfterExit=yes ExecStop=birdc graceful restart [Install] WantedBy=bird.service That way you can enable/disable system wide graceful bird restart by `systemctl enable bird-graceful-restart.service`. The BindsTo+After means stopping bird.service (which is part of restart) will first stop bird-graceful-restart.service, which can then casually signal bird to perform graceful restart without a race (I think). WanteBy=bird.service is needed as ExecStop will only run when a service has actually been started. Also some special handling for the case where bird is already gone (crashed or exited) and birdc would fail might be needed. Excercise for the reader :) Doing some quick testing this actually seems to do what I want. Somewhat unexpectedly `systemctl restart bird.servce` with the above enabled does then actually do what you'd expect since restart is just stop+start. Bird will exit on getting the graceful restart command so systemd can't try to stop it some more but the subsequent start will make it come back up. Neat. On system shutdown only the stop part will happen so bird exiting is actully useful now and that too should work as expected. > Ideally systemd would have an ExecStopRestart option which could be used > to distinguish between stops and restarts, but unfortunately it doesn't > (I might submit a feature request for this regardless). However, it does > support `KillSignal and RestartKillSignal options.` I've been perplexed by this in the past also. Don't even get me started on the fact that ExecStop= runs even when a service already terminated on it's own, to like stop it some more... :) The semantics are really bonkers sometimes but it's actually rather flexible if you look at the nuaunces of the different dependency types a bit. --Daniel
Re: Graceful shutdown request signal
On 2023-06-20 21:07, Maria Matejka via Bird-users wrote: Well, it's a pity that systemd doesn't allow for custom operations – in such case you could call "systemd graceful bird2" or "systemd restart bird2"… It's still possible to use systemctl kill --signal=USR2 bird2
Re: Graceful shutdown request signal
Hello! Well, it's a pity that systemd doesn't allow for custom operations – in such case you could call "systemd graceful bird2" or "systemd restart bird2"… Anyway, feel free to implement it, it should be like 10 lines of code. Sigusr2 is probably ok. Then it'll be on anybody to choose whether to restart gracefully or hardly by systemd. Maria On 20 June 2023 20:20:50 CEST, Erin Shepherd wrote: >Hello, > >I run bird on a system which uses systemd as a service supervisor, and would >like to implement graceful restart in a way which works well with it. > >In particular, what I'd like to do is: > • If I restart the bird service (e.g. for an upgrade), Bird performs a > graceful restart > • If I manually stop bird (systemctl stop bird2), shutdown the system, or any > other action which is liable to cause a longer period of downtime, perform a > graceful restart (for BGP at least) >Ideally systemd would have an ExecStopRestart option which could be used to >distinguish between stops and restarts, but unfortunately it doesn't (I might >submit a feature request for this regardless). However, it does support >`KillSignal and RestartKillSignal options.` > >`So therefore I was wondering how the Bird developers and users would feel >about introducing a signal (SIGUSR2 maybe?) which can be used to request that >Bird perform a graceful restart?` > >`- Erin` -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Graceful shutdown request signal
Hello, I run bird on a system which uses systemd as a service supervisor, and would like to implement graceful restart in a way which works well with it. In particular, what I'd like to do is: • If I restart the bird service (e.g. for an upgrade), Bird performs a graceful restart • If I manually stop bird (systemctl stop bird2), shutdown the system, or any other action which is liable to cause a longer period of downtime, perform a graceful restart (for BGP at least) Ideally systemd would have an ExecStopRestart option which could be used to distinguish between stops and restarts, but unfortunately it doesn't (I might submit a feature request for this regardless). However, it does support `KillSignal and RestartKillSignal options.` `So therefore I was wondering how the Bird developers and users would feel about introducing a signal (SIGUSR2 maybe?) which can be used to request that Bird perform a graceful restart?` `- Erin`
Re: Best practice Route Reflector
Hello Douglas, ` Douglas Fischer writes: > - "I'm not going to use anything other than BGP. " I know where this is coming from, because we also came from there. Forget even the notion of next-hop self, in container (!) and application environments, BGP that gives you networking "for free". You can easily do things by "just deploying bgp". And why would you want to care about anything like OSPF or any other IGP in the first place? The problem you want to solve is: I have a couple of hosts that want to share their IP addresses (in link-local only scenarios) or their own attached routes. This works perfectly, especially if you do eBGP (!) within your network. Every node is simply an ASN. Obviously, this comes with the drawback of using tons of private ASN, but in practice, this works pretty well. If only ASN were 128 bit as well, then anyone could use their range of official/public ASNs ... Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Re: Best practice Route Reflector
>From what I could see from your questions, the issues you have been facing are more related to the good use of IGP (eg OSPF, ISIS) and redistribution of routes through BGP than with the use or not of route-reflector. If you don't have an IGP "to call your own", something you REALLY trust, that's the first thing you have to address. Comment: I don't know why, but in the last few months I've seen a lot of colleagues coming up with ideas like: - "I'm not going to use anything other than BGP. I don't need IGP for anything... I use next-hop-self everywhere.". And it scares me so much. If this is not your case, disregard! Next step is to decide what you are going to redistribute via IGP(OSPF or ISIS) and what you are going to redistribute via iBGP. Each case is different... But for ISPs and ITPs scenarios I usually suggest that OSPF redistribute EXCLUSIVELY the Loopacks subnets and the PTP subnets between the routers themselves (directly connected of internal networks). And in iBGP I recommend redistributing static routes (for specific cases) and external PTP Subnets (Customers, Providers, IXPs). Use, abuse, and trust on your own marking of BGP-Communities and OSPF tags to properly control the filtering and redistribution of these routes. After all this is well defined, here comes the intelligence part in filtering the routes that will or will not be redistributed to each RR-Client, and maybe some aggregation/summarization strategy. I apologize if I sounded too complacent or verbose. I wish your efforts bring good results. Em ter., 20 de jun. de 2023 às 09:05, Oliver Seufer via Bird-users < bird-users@network.cz> escreveu: > Hello, > > I would like to gather some thoughts on whether I should use a Route > Reflector > or not, and if I do need one, what would be the best practice. > > Let's begin with the setup. I have four BGP routers located in two > different data centers: > * Each router (r1, r2, r3, r4) has an iBGP session established with the > other BGP routers. > * Two routers (r1 and r2) receive a full table from transit providers. > * The other two routers (r3 and r4) receive the best routes (full table) > from r1 and r2. > * Additionally, r3 and r4 have peering connections with external parties > and > provide a default route via iBGP to other systems. > > Schematic representation of the setup > > data center 1 data center 2 > r1 -- r2 > \ / >-- > / \ > r3r4 > > Under normal conditions, I do not require a Route Reflector in this setup. > > However, there are situations where r3 can still reach r1 but not r2 and > r4. > Additionally, r1 can still reach r2. In this specific situation, r3 only > receives the best route from r1 and not the learned routes from r2. > > I am aware that I can use a Route Reflector to address this issue, but I > am not > entirely certain if it is a suitable solution for my setup. Currently, my > plan > is to use r1 and r2 as the Route Reflector Cluster (with next hop self), > while > r3 and r4 would connect as non-Route Reflector clients to r1 and r2. > > So, the requirement is for r3 and r4 to always receive a full table. > > Regarding the approach, using a Route Reflector seems like a reasonable > solution in this case. However, there might be alternative and potentially > better solutions available. > > Thanks, > > Oliver > -- Douglas Fernando Fischer Engº de Controle e Automação
Best practice Route Reflector
Hello, I would like to gather some thoughts on whether I should use a Route Reflector or not, and if I do need one, what would be the best practice. Let's begin with the setup. I have four BGP routers located in two different data centers: * Each router (r1, r2, r3, r4) has an iBGP session established with the other BGP routers. * Two routers (r1 and r2) receive a full table from transit providers. * The other two routers (r3 and r4) receive the best routes (full table) from r1 and r2. * Additionally, r3 and r4 have peering connections with external parties and provide a default route via iBGP to other systems. Schematic representation of the setup data center 1 data center 2 r1 -- r2 \ / -- / \ r3r4 Under normal conditions, I do not require a Route Reflector in this setup. However, there are situations where r3 can still reach r1 but not r2 and r4. Additionally, r1 can still reach r2. In this specific situation, r3 only receives the best route from r1 and not the learned routes from r2. I am aware that I can use a Route Reflector to address this issue, but I am not entirely certain if it is a suitable solution for my setup. Currently, my plan is to use r1 and r2 as the Route Reflector Cluster (with next hop self), while r3 and r4 would connect as non-Route Reflector clients to r1 and r2. So, the requirement is for r3 and r4 to always receive a full table. Regarding the approach, using a Route Reflector seems like a reasonable solution in this case. However, there might be alternative and potentially better solutions available. Thanks, Oliver
