OpenBSD Project Announces OpenBGPD
44BSD writes "As noted at undeadly, the OpenBSD Project has announced an BSD-licensed implementation of the Border Gateway Protocol, BGP. Project details, design goals, documentation, and more are at the project web site. BGP is documented in RFC 1771.
Lucky for Cisco, BSD is dying..."
Unfortuantely, even the fanciest boxes running BSD can't complete on a pure throughput basis with good Cisco routers. An twenty-four port gigabit Cisco router has a 48 Gbps backplane, but a PC running BSD will be limited by its bus--the fastest servers have a 64 bit 133 MHz bus with PCI-X. That's 8 Gbps. And you can't put more than a handful of network cards in even the largest BSD-capable server--there simply aren't the expansion slots. So this really couldn't be used for core Internet routers.
And, of course, you don't need to be running BGP on small networks--it's only when you've got a number of large networks joined together, at a chokepoint, where you need to use BGP to properly route traffic. So there's no point to it for small businesses with who might be trying to save money over a Cisco router--they don't need BRP.
I wonder, then: where is the market for this....?
Just because it's BSD doesn't mean that it's going to be limited to PC Architecture.
This project could give a boost to manufacturers of competing kit by having a code base that it doesn't have to start from scratch and can be run on a minimal BSD distribution.
There's nothing to stop A.N.Other manufacturer creating their own arcitecture and running this ontop.
Matt Thompson - Actuality - Insert product here.
the openbsd team has branched off quite a few projects where they saw the security and/or license was insufficient and needed to be redone.
OpenSSH, who's box doesn't have this?
OpenNTPD, a network time protocol daemon and server, recently released.
OpenBGPD, the border gateway protocol daemon.
They were pioneers in the use of stack protection software on the i386 platform (kernel and compiler), as well as privilage seperated daemons (it's in your sshd now), and randomized library linking locations.
(i think i'm missing a few, anyone care to fill them in?)
they have implemented (a far better implementation over the old one that they didn't write) their i.p. filter, PF (which has now made it into netbsd, freebsd, and hopefully linux soon enough). this includes INSANE amounts of configurability options, with integrated routing and traffic shaping.
many people grumble about how the project is run and its priorities. but we all benefit from their efforts. i think i'm going to buy a cd even though i am not an openbsd user. these sales help keep these projects going.
unfortunately the interfacce to the kernel routing table is not standardized, so this is highly platform dependent by the nature of the problem beeing solved.
;) If anybody steps up and makes one, why not?
Moreover, seeing BGP as a pure userland task ist far off reality. While that is technically speaking mostly true, you need a lot of kernel support. In fact, we did modify our kernel routing table structures to linder kvm pressure and thus fit a full-mesh table (> 140000 enties) into an GENERIC kernel. You need network stack modifications for tcp md5. The ipsec integration required changes to the IPsec kernel implementation as well as isakmpd - and there's more...
So, while strictly speaking bgpd is a userland thing, you need more than that for a BGP router. OpenBSD and OpenBGPD offer this.
That said, I am in no way opposed to a portable version. Just like for OpenNTPD I won't do it tho
henning
As opposed to a security hole in a closed-source router... like a Cisco?
A default username/password pair is present in all releases of the Wireless LAN Solution Engine (WLSE) and Hosting Solution Engine (HSE) software. A user who logs in using this username has complete control of the device. This username cannot be disabled. There is no workaround.
Golly, if you had the source, you might be able to do something like... hmmm... I dunno... disable the default password, maybe?
GPL people are welcome to import BSD code: actually, they really should do it.
Of course, provided they learn to give proper credits.
I think it is a good choice for the OpenBSD cases. It allows development to be done at better development speed and with cleaner code than something trying to be completely portable. This makes it easier to track security and work with the code.
I'll also note that most software that is "portable" today is written using GNU autotools, which makes it, on average, less portable than software was before autoconf. Either it works at once (this happens reasonable often), or there is a significant amount of pain to make it work. Ten to fifteen years ago, there was usually some work involved, but the average was less, and it was spread out.
Separating the porting part from the initial clean codebase means that it is possible to debug them separately, and when autotools fails, it is easier to go around them.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.