Dear BIRD users, it took us a very long time, but we are moving towards 2.0.x branch. Main feature of this branch is IPv4 and IPv6 integration. Please note, 2.0.x will be an _experimental_ branch. We will not guarantee configuration stability etc. And today we release 2.0.0-pre0. So that's experimental version of experimental branch. Keep this in mind and DO NOT USE IT IN PRODUCTION ENVIRONMENT. On the other hand, testers are more than welcome. Please use it and report (either positive or negative)! We will not provide packages for any distribution. Version 2.0.0-pre0 (2016-12-07) o Integrated IPv4 + IPv6 design o Major BGP protocol redesign o BGP multicast support (SAFI 2) o BGP flowspec support (RFC 5575) o New RPKI-Router protocol o New build system o Unit tests Notes: Protocols and tables are now connected using explicit channels, most related protocol options (table, import, export, ...) are now channel options. See doc/bird.conf.example2 for configuration examples. Ondrej
On Wed, Dec 07, 2016 at 08:43:08PM +0100, Ondrej Filip wrote:
On the other hand, testers are more than welcome. Please use it and report (either positive or negative)!
Notes:
Protocols and tables are now connected using explicit channels, most related protocol options (table, import, export, ...) are now channel options. See doc/bird.conf.example2 for configuration examples.
Hi As configuration changes are not yet reflected in documentation, here is a summary for adventurous testers: 0) Most features are presented in doc/bird.conf.example2 : https://gitlab.labs.nic.cz/labs/bird/blob/int-new/doc/bird.conf.example2 1) There are (currently) 8 network/route classes: ipv4, ipv6 - regular IP networks/routes vpn4, vpn6 - VPN networks/routes (IP networks with additional VPN distinguisher) roa4, roa6 - RPKI ROA records flow4, flow6 - BGP Flowspec records 2) Each routing table is defined with class (above) and contains just routes of that class (instead of 'table xxx;' use e.g. 'ipv4 table xxx;'). 3) Two tables are predefined, ipv4 table 'master4' and ipv6 table 'master6'. 4) For each network class, the first defined table of that class is considered default. 5) Protocols are connected to tables using explicitly configured channels, each channel connects the protocol to one table. Like tables, channels has class. 6) Channel is specified by a keyword, which is usually (but not always) the keyword of channel class (e.g., ipv4, ipv6, ...), and block with options. These options were moved from protocol to channel: table, import, export, all limits, preference, import keep filtered. 7) Channel may be specified without options, with expected meaning: default table (by channel class), import all, export none. 8) Some protocols require one channel of fixed class (e.g. ipv6 for ripng), Some protocols required one channel of selectable class (e.g. static), Some protocols may have multiple channels (e.g. BGP). 9) BGP supports these channels (keywords) for these AFI/SAFI pairs: ipv4 - AF 1/1 ipv6 - AF 2/1 ipv4 multicast - AF 1/2 ipv6 multicast - AF 2/2 flow4 - AF 1/133 flow6 - AF 2/133 Multicast (SAFI 2) channels connects to regular ipv4/ipv6 tables. 10) BGP channels also have these options (that were moved from BGP protocol): next hop self, next hop keep, next hop address, missing lladdr, gateway, secondary, graceful restart, add paths, igp table. 11) As usual, pipe protocol is exception - the syntax is same as in the old BIRD, two channels (to 'table' and 'peer table') are defined implicitly. 12) Some protocols were splitted and use new keywords: There is rip (for RIPv2) and ripng (for RIPng), ospf2 (for OSPFv2) and ospf3 (for OSPFv3). There is no ospf. Note that automatic naming and numbering of multiple protocols is still shared between these variants. 13) Note that with ospf2, ospf3 keywords collide with automatic names for second and third OSPF protocol. Use always explicit protocol names in these case to avoid this issue. Questions, comments and suggestions are welcome. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
❦ 8 décembre 2016 02:44 +0100, Ondrej Zajicek <santiago@crfreenet.org> :
flow4, flow6 - BGP Flowspec records
Hey! What's the "recommended" way to handle flowspec additions? As I see it, the only way would be to change BIRD configuration, then reload. Moreover, retrieving flowspec routes is possible only through the client, which may not be practical (but maybe in the future, it would be possible to listen to route changes?). Or MRT dumps maybe. Or just use ExaBGP as a peer and do all the dynamic stuff from here. -- Go not to the elves for counsel, for they will say both yes and no. -- J.R.R. Tolkien
On Thu, Dec 08, 2016 at 08:36:38AM +0100, Vincent Bernat wrote:
❦ 8 décembre 2016 02:44 +0100, Ondrej Zajicek <santiago@crfreenet.org> :
flow4, flow6 - BGP Flowspec records
Hey!
What's the "recommended" way to handle flowspec additions? As I see it, the only way would be to change BIRD configuration, then reload.
That is true, currently you can just define it in static protocol and receive or announce it by BGP. I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
My note on this: network people are used to do this interactively, this is possibly reason guys from GoBGP are doing it the same way (only from CLI/API). Netflow rules are not very persistent in nature, much less than usual routes. r.
That is true, currently you can just define it in static protocol and receive or announce it by BGP.
I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration?
Hello, world!\n
I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration?
Maybe define a separate protocol which exports routes added/removed online? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Q: How many mathematicians does it take to screw in a lightbulb? A: 0.999999...
On 12/08/2016 04:42 PM, Martin Mares wrote:
Hello, world!\n
I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration? Maybe define a separate protocol which exports routes added/removed online?
I really like this idea! A protocol called "interactive" or "runtime" or somesuch. It keeps the configuration clean, without having to complicate the static protocol, or having strange unintuituve behaviors. The "interactive" protocol would only have routes learned online, so its behavior is well defined. On bootup it has no routes, and during the lifetime of Bird, it will learn or forget routes manually through the CLI or other APIs. A few new CLI/API commands, to "add", "remove" and "clear". This makes the question of reconfiguration simple: it should not touch the "interactive" routes. If the user wants to clear them he will use the "clear" command at runtime. Regards, Israel
On 08/12/2016 18:19, Israel G. Lugo wrote:
On 12/08/2016 04:42 PM, Martin Mares wrote:
Hello, world!\n
I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration? Maybe define a separate protocol which exports routes added/removed online?
I really like this idea! A protocol called "interactive" or "runtime" or somesuch. It keeps the configuration clean, without having to complicate the static protocol, or having strange unintuituve behaviors. The "interactive" protocol would only have routes learned online, so its behavior is well defined. On bootup it has no routes, and during the lifetime of Bird, it will learn or forget routes manually through the CLI or other APIs. A few new CLI/API commands, to "add", "remove" and "clear". This makes the question of reconfiguration simple: it should not touch the "interactive" routes. If the user wants to clear them he will use the "clear" command at runtime.
Regards, Israel
As long as each "record" is at most 512 bytes the protocol could just offer a named pipe to add new records. That would be crude because there is simple way to acknowledge writes, but trivial to interface with. A better way would be to replace the pipe with a unix domain sequential packet socket and simple protocol to report success/failure.
On Thu, Dec 08, 2016 at 05:42:01PM +0100, Martin Mares wrote:
Hello, world!\n
I think that we should expand static protocol to allow adding or deleting routes interactively. There are some problematic behavioral details in it; e.g., how we should handle interactive removal of a route from configuration. Should we have two independent sets of routes, one added/removed by reconfiguration, one interactively? Or should we allow to remove interactively one from configuration? If so, should it respawn during reconfiguration?
Maybe define a separate protocol which exports routes added/removed online?
Hi That was one of early ideas, but such protocol would share ~80% of code with static protocol and behavior-wise it is just equivalent to the first case (two independent sets) with one more protocol in config file. Two independent sets is a simple model, i would prefer that. But i wonder whether it isn't just unnecessary restrictive. For example a user currently sets some static routes in a boot script using ip command, it can also change or remove them interactively without changing the persistent state (the boot script). If the user replaces that with BIRD, it loses that ability [*]. Another alternative would be to have two behaviors (either configurable for a static protocol, or static and another protocol), where the first would be like a static protocol, could be modified interactively, but would always reset to configured state during reload, while the second would initialize routes from config only during the start, not during reconfigure, so routes could be added/removed interactively without losing them due to reconfiguration. [*] Disregarding some clumsy ways like copy config file to /tmp, edit it and reconfigure from that copy; or use some script to preload static routes to BIRD instead of specifying them in the config file so they could be changed interactively later. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Ondrej Filip <feela@network.cz> writes:
Dear BIRD users, it took us a very long time, but we are moving towards 2.0.x branch. Main feature of this branch is IPv4 and IPv6 integration.
So has anything more happened with this? I would like to try to get a working dual-stack version of Babel in Bird, but, well, in 2.0.0-pre0 the Babel protocol is broken entirely. Any plans to fix that? -Toke
On Thu, Feb 23, 2017 at 04:32:20PM +0100, Toke Høiland-Jørgensen wrote:
Ondrej Filip <feela@network.cz> writes:
Dear BIRD users, it took us a very long time, but we are moving towards 2.0.x branch. Main feature of this branch is IPv4 and IPv6 integration.
So has anything more happened with this? I would like to try to get a working dual-stack version of Babel in Bird, but, well, in 2.0.0-pre0 the Babel protocol is broken entirely. Any plans to fix that?
Hi, you could get it from our git (branch int-new). Babel was already fixed in commit 5e8df049fbf53220735a2eeb6c751e1758869a18, but it is still IPv6-only. BTW, Direct protocol (nest/rt-dev.c) could be a simple example how to setup a protocol with (optional) two channels. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Thu, Feb 23, 2017 at 04:32:20PM +0100, Toke Høiland-Jørgensen wrote:
Ondrej Filip <feela@network.cz> writes:
Dear BIRD users, it took us a very long time, but we are moving towards 2.0.x branch. Main feature of this branch is IPv4 and IPv6 integration.
So has anything more happened with this? I would like to try to get a working dual-stack version of Babel in Bird, but, well, in 2.0.0-pre0 the Babel protocol is broken entirely. Any plans to fix that?
Hi, you could get it from our git (branch int-new). Babel was already fixed in commit 5e8df049fbf53220735a2eeb6c751e1758869a18, but it is still IPv6-only.
Ah, awesome! I was poking around in the git repo but didn't know where to look, so guess I missed that. I'll have a look at it. And yeah, 'working but v6-only' is a fine starting point as far as I'm concerned :)
BTW, Direct protocol (nest/rt-dev.c) could be a simple example how to setup a protocol with (optional) two channels.
Cool, thanks! -Toke
participants (8)
-
Israel G. Lugo -
Jan Bramkamp -
Martin Mares -
Ondrej Filip -
Ondrej Zajicek -
Rasto Rickardt -
Toke Høiland-Jørgensen -
Vincent Bernat