Booting a full debian on a Lego robot is quite impressive, and opens a myriad of possibilities. I fimd quite amusing that the first idea of the author was “Hey, can I make this robot a BGP router ?!”
As a network guy, I would love the idea of a robot crawling my home, while routing all the family traffic to the internet or neighbours’ networks ! Pretty cool project !
Ironically, BIRD is one really inflexible routing protocol stack architecture. OpenBGPD is exactly a BGP implementation, I get it. It’s what it is: a solution for an IX route server for example.
BIRD is a “worst of both worlds” thing. It’s a monolithic daemon that keeps the common RIB and each protocol in one process. But, we have two versions of the IP protocol: IPv4 and IPv6. And so does BIRD: its source compiles into two monolithic daemons, one for IPv4, one for IPv6.
And so you have two BGP processes, even though there are valid (if marginal) use cases for advertising IPv6 NLRIs over an IPv4 session or vice versa, e.g. bogon route services, or again IX route servers.
Zebra was the original Lego of routing protocol stacks: it has a common RIB and an API that allows anyone to write a new protocol daemon and use it with that RIB, without having to get it accepted in the mainline or maintaining a fork of the whole stack. FreeRangeRouting is the most actively developed fork now.
That’s sure an improvement. I do like BIRD’s ability to re-read the config atomically. Quagga/FRR makes that a quite headache. I hope at some point in the future we’ll be able to have both extensibility and atomic reloads in some project. If we are ok with per-daemon atomic reload, they aren’t mutually exclusive features.
Booting a full debian on a Lego robot is quite impressive, and opens a myriad of possibilities. I fimd quite amusing that the first idea of the author was “Hey, can I make this robot a BGP router ?!”
As a network guy, I would love the idea of a robot crawling my home, while routing all the family traffic to the internet or neighbours’ networks ! Pretty cool project !
Thanks! :3
Ironically, BIRD is one really inflexible routing protocol stack architecture. OpenBGPD is exactly a BGP implementation, I get it. It’s what it is: a solution for an IX route server for example.
BIRD is a “worst of both worlds” thing. It’s a monolithic daemon that keeps the common RIB and each protocol in one process. But, we have two versions of the IP protocol: IPv4 and IPv6. And so does BIRD: its source compiles into two monolithic daemons, one for IPv4, one for IPv6.
And so you have two BGP processes, even though there are valid (if marginal) use cases for advertising IPv6 NLRIs over an IPv4 session or vice versa, e.g. bogon route services, or again IX route servers.
Zebra was the original Lego of routing protocol stacks: it has a common RIB and an API that allows anyone to write a new protocol daemon and use it with that RIB, without having to get it accepted in the mainline or maintaining a fork of the whole stack. FreeRangeRouting is the most actively developed fork now.
BIRD 2 can do both protocols in one process. There is still some duplication in the configuration, however.
That’s sure an improvement. I do like BIRD’s ability to re-read the config atomically. Quagga/FRR makes that a quite headache. I hope at some point in the future we’ll be able to have both extensibility and atomic reloads in some project. If we are ok with per-daemon atomic reload, they aren’t mutually exclusive features.