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..."
And also in Linux.
Yesterday, I tried to compile OpenBGPD on Linux. Unfortunately, there is no "portable version" available (unlike OpenSSH), and the source code contains a lot of #includes and library function that are specific to (Open)BSD. That obviously doesn't help portability, and I'm a bit sad that the OpenBSD project doesn't go the portable way and makes its userland as easily compilable on other Unices as possible.
A monkey is doing the real work for me.
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.
Hasn't Zebra been succeeded by Quagga? [quagga.net]
I ask out of curiosity more than anything else - Debian unstable and testing use Quagga instead of Zebra...
The hole would be secured much faster than the bugs lurking in the proprietary implementations.
On top of that, BGPd is far from being your average daemon, it only needs to talk to predefined peers with which you need to have a relationship (often in the form of a written contrat).
OpenBGPd has some stuff in place that allows for easy implementation of the crypto enabled BGP sessions. So if you implement authentified peering you could only be crashed by one of your peers, who usually have better things to do.
GPL people are welcome to import BSD code: actually, they really should do it.
Of course, provided they learn to give proper credits.
This is not how OpenBSD works. There's only one place for official errata, and these patches are published only after carefull scrutiny.
While you may be right for some Open Source projects, the OpenBSD team applies sound engineering techniques.
In "open source" world you would probably have had N fixes from X different people, each claiming that theirs is the best.
You need to stop thinking in the low-quality terms that Linux has taught you. The BSDs are actually Open Source _and_ high quality.
there's always 8x PCI-E for transfering lots of data. That'd give you 20 Gbit in each direction. 16x PCI-E NICs and even 32x PCI-E NICs should be available in a not so distant future.
Any sufficiently advanced technology is indistinguishable from magic.
The Cisco 3600 series *does* use PCI for its bus. Those two or four or six slots on a 36xx series are good ol' PCI, they're just in a Cisco form factor, not the Wintel PCI form factor you're used to seeing. I do believe this means every NM form factor slot is a PCI - 26xx, 28xx, 36xx, 37xx, 38xx, and some other stuff all use it.
Cisco uses PCI because its a fast, competent bus, with lots of inexpensive parts due to PC volume driving chipset costs. They get more out of an 80MHz MIPS processor in a 3620 than you get out of a 1GHz Athlon because the hardware is tuned to do nothing but move packets from point A to point B.
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
Actually, if you look at the architecture of a Juniper Networks router, it is based on FreeBSD. The Routing Engine is a merely a normal PC motherboard running the Free BSD kernel and Juniper code to handle the routing protocols and system management. There are custom-built ASICs in the Packet Forwarding Engines that handle the packet processing. This architecture has proven to easily out perform the old monolithic architecture of Cisco.
Yes, a higher-end Cisco probably out performs my laptop running OpenBSD and OpenBGPD, but my laptop wasn't designed to be a high-end router.
BGP by itself is meaningless. You need at least OSPF for a small network and ISIS for a large one to be able to use it and you need them in a form where the BGP knows everything about an OSPF or ISIS route.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
The OpenBSD crowd often don't play well with others. They have a completely different set of priorities than other projects.
There was a discussion on the misc@ list, and it basically came down to completely different priorities plus lots of OpenBSD specific hooks.
I rarely criticize things I don't care about.
As long as you have enough of an IGP cloud so the BGP peer IPs are visible to all BGP peers, you can run BGP for (most) of your routing (and just duplicate the peering IPs between IGP-of-choice and iBGP).
Not that it's *necessarily* a good idea, mind you. But it does make *some* things way easier.
Aparantly you've never heard of Juniper Networks. They're router solutions beat the pants off of Cisco for throughput and price, and, they're running FreeBSD on their routers.
FYI, buying from Intel is discouraged
The best way to predict the future is to invent it
oops, I didn't answer the other part about pool.ntp.org:
http://www.pool.ntp.org/#news
see the "2004-09-07" entry.
Unless we're talking about buffer overflows and the likes, the amount of trust between BGP peers is fairly limited (at least when things are configured properly).
Back in the days when I was involved in looking after the peering of an ISP, that trust was limited to the peer announcing some routes, which our router would only use if they were already preconfigured as being expected from that particular peer. Anything else was logged, then discarded by the router.