Quick suggestion about enable/disable protocol
Hi, Is this list the place to discuss feature requests? Please let me know if there's somewhere more appropriate. Re enable/disable <prot> available in CLI, but not config: 1. Allow enable/disable to be part of the config, so that a protocol can be disabled by default, and needs a manual poke via CLI command to enable it. For example, a backup session that will only be enabled when the main link is down. 2a. When reloading config, preserve the current state of a protocol that has been disabled. (I'm trying to debug a config, which involves disabling a particular BGP session, but every time I reload config BIRD re-enables the session.) 2b. An explicit "enable" directive in config (see #1) could also be used to make it clear that a reload *should* enable this protocol regardless of its previous state. Thanks!
Hello!
Is this list the place to discuss feature requests? Please let me know if there's somewhere more appropriate.
Yes.
Re enable/disable <prot> available in CLI, but not config:
1. Allow enable/disable to be part of the config, so that a protocol can be disabled by default, and needs a manual poke via CLI command to enable it. For example, a backup session that will only be enabled when the main link is down.
This is already in config, use "enabled" and "disabled" keywords.
2a. When reloading config, preserve the current state of a protocol that has been disabled. (I'm trying to debug a config, which involves disabling a particular BGP session, but every time I reload config BIRD re-enables the session.)
2b. An explicit "enable" directive in config (see #1) could also be used to make it clear that a reload *should* enable this protocol regardless of its previous state.
We don't like to change what BIRD does by default as it may confuse others who aren't familiar with the changes and both variants of behavior have their appropriate use. Yet we may consider something like a "keep protocol states" option to explicitly disable protocol disabling/enabling on config reload. For now, you can set "enabled/disabled" in every protocol block and change that together with manual protocol enabling and disabling. We have also some rough ideas of configuration dumping which could also help with this, yet this kind of features still have quite a long path ahead. I hope this is helpful for you. Maria
Hi! On Wed, 1 Dec 2021, Maria Matejka wrote:
1. Allow enable/disable to be part of the config, so that a protocol can be disabled by default, and needs a manual poke via CLI command to enable it. [...]
This is already in config, use "enabled" and "disabled" keywords.
Aha! I didn't find that previously in the docs - of course now I can see it. I did try "disable" as per the CLI command, but obviously that slightly different directive doesn't work. Perhaps a note could be added to the CLI docs to mention that it can be set semi-permanently in the config?
2a. When reloading config, preserve the current state of a protocol that has been disabled. (I'm trying to debug a config, which involves disabling [...]
We don't like to change what BIRD does by default as it may confuse others who aren't familiar with the changes and both variants of behavior have their appropriate use. Yet we may consider something like a "keep protocol states" option to explicitly disable protocol disabling/enabling on config reload.
Yes, I did intend to mean that it would be an option, rather than a (potentially dangerous) change in default behaviour. For now, I'll just try to remember to uncomment "disabled" in the block before I start fiddling. :) Whilst I have your attention, there is one other thing that doesn't seem to be explicitly mentioned in the docs: what happens when you have multiple import/export filters listed for the one protocol? Does the first accept/reject win, and exit any further filter processing, or is there some other behaviour? Are the multiple filters evaluated in config order, or some other order? Initially I was trying to make separate filters for 0.0.0.0/0 and x.x.x.0/24, for import and export via BGP respectively, and combine them to allow both routes to be advertised locally (without needing a third filter)... but it doesn't work, possibly because both filters have an unconditional reject at the end. Thanks!
Hello!
1. Allow enable/disable to be part of the config, so that a protocol can be disabled by default, and needs a manual poke via CLI command to enable it. [...]
This is already in config, use "enabled" and "disabled" keywords.
Aha! I didn't find that previously in the docs - of course now I can see it. I did try "disable" as per the CLI command, but obviously that slightly different directive doesn't work. Perhaps a note could be added to the CLI docs to mention that it can be set semi-permanently in the config?
Well, yes. Patches are welcome.
2a. When reloading config, preserve the current state of a protocol that has been disabled. (I'm trying to debug a config, which involves disabling [...]
We don't like to change what BIRD does by default as it may confuse others who aren't familiar with the changes and both variants of behavior have their appropriate use. Yet we may consider something like a "keep protocol states" option to explicitly disable protocol disabling/enabling on config reload.
Yes, I did intend to mean that it would be an option, rather than a (potentially dangerous) change in default behaviour. For now, I'll just try to remember to uncomment "disabled" in the block before I start fiddling. :)
Fine, then we are on the same side. Or, it may be even better to make this an option of the "configure" CLI command, as we already have the "configure soft" which doesn't reload changed filters.
Whilst I have your attention, there is one other thing that doesn't seem to be explicitly mentioned in the docs: what happens when you have multiple import/export filters listed for the one protocol? Does the first accept/reject win, and exit any further filter processing, or is there some other behaviour? Are the multiple filters evaluated in config order, or some other order?
I think only the last one is used and executed. The parser just doesn't care about previous filters and overwrites them. There are some plans to allow filter chaining, yet for now, I suggest using functions instead.
Initially I was trying to make separate filters for 0.0.0.0/0 and x.x.x.0/24, for import and export via BGP respectively, and combine them to allow both routes to be advertised locally (without needing a third filter)... but it doesn't work, possibly because both filters have an unconditional reject at the end.
Something like this: function the_zero_route() { ... } function the_other_route() { ... } ... export filter { if the_zero_route() then accept; if the_other_route() then accept; reject; }; Maria
Hi, In the meanwhile, you can use my patch, so that bird shouldn't change protocol states when you do "configure soft". There is a link in my presentation (slide 6): https://ripe81.ripe.net/archives/video/479/ There are some other patches you might find interesting too. On Wed, Dec 1, 2021, 08:08 <bird21@sensation.net.au> wrote:
Hi!
On Wed, 1 Dec 2021, Maria Matejka wrote:
1. Allow enable/disable to be part of the config, so that a protocol can be disabled by default, and needs a manual poke via CLI command to enable it. [...]
This is already in config, use "enabled" and "disabled" keywords.
Aha! I didn't find that previously in the docs - of course now I can see it. I did try "disable" as per the CLI command, but obviously that slightly different directive doesn't work. Perhaps a note could be added to the CLI docs to mention that it can be set semi-permanently in the config?
2a. When reloading config, preserve the current state of a protocol that has been disabled. (I'm trying to debug a config, which involves disabling [...]
We don't like to change what BIRD does by default as it may confuse others who aren't familiar with the changes and both variants of behavior have their appropriate use. Yet we may consider something like a "keep protocol states" option to explicitly disable protocol disabling/enabling on config reload.
Yes, I did intend to mean that it would be an option, rather than a (potentially dangerous) change in default behaviour. For now, I'll just try to remember to uncomment "disabled" in the block before I start fiddling. :)
Whilst I have your attention, there is one other thing that doesn't seem to be explicitly mentioned in the docs: what happens when you have multiple import/export filters listed for the one protocol? Does the first accept/reject win, and exit any further filter processing, or is there some other behaviour? Are the multiple filters evaluated in config order, or some other order?
Initially I was trying to make separate filters for 0.0.0.0/0 and x.x.x.0/24, for import and export via BGP respectively, and combine them to allow both routes to be advertised locally (without needing a third filter)... but it doesn't work, possibly because both filters have an unconditional reject at the end.
Thanks!
participants (3)
-
Alexander Zubkov -
bird21＠sensation.net.au -
Maria Matejka