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..."

Re:BSD License

[Anonymous Coward]

And also in Linux.

Doesn't compile on Linux

[quigonn]

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.

Re:Doesn't compile on Linux

[dmiller]

Interfacing with the kernel routing table is highly platform-dependant, there is not avoiding that. Beyond this, if someone wants to make a port, most of the necessary glue can be lifted from OpenSSH's libopenbsd-compat or Darren Tucker's OpenNTPd port - someone just needs to do the work :)

OpenBSD projects

[pchan-]

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 [openssh.org], who's box doesn't have this?
OpenNTPD [openntpd.org], a network time protocol daemon and server, recently released.
OpenBGPD [openbgpd.org], 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 [openbsd.org] 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 [openbsd.org] even though i am not an openbsd user. these sales help keep these projects going.

Re:For a broader knowledge see also this

[Anonymous Coward]

Hasn't Zebra been succeeded by Quagga [quagga.net]? [quagga.net]

I ask out of curiosity more than anything else - Debian unstable and testing use Quagga instead of Zebra...

Re:Doesn't compile on Linux

[Anonymous Coward]

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.

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 ;) If anybody steps up and makes one, why not?

henning

Re:BSD License

[Anonymous Coward]

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.

Re:Doesn't compile on Linux

[ripleymj]

Not only the routing table, but I believe OpenBGPd has hooks into pf. Henning mentioned being able to filter and/or queue in the future based on labels assigned to packets in OpenBGPd. You might be able to strip that away for a portable version, but it certainly won't drop nicely into IPTables.

Re:BSD License

[Anonymous Coward]

GPL people are welcome to import BSD code: actually, they really should do it. [slashdot.org]
Of course, provided they learn to give proper credits. [feyrer.de]

Re:BSD License

[OttoM]

In "open source" world you would probably have had N fixes from X different people, each claiming that theirs is the best. If you want to see a real open source mess, check out Zaurus - just as an example there is a large number of libSDL ports, each different, each having different problems, each compatible with different games, none fully usable.

This is not how OpenBSD works. There's only one place for official errata [openbsd.org], 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.

Re:BSD License

[Anonymous Coward]

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.

Re:Throughput, Expansion Slots, Network Size, Mark

[SorcererX]

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.

Cisco routers use PCI bus

[puzzled]

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.

Re:Throughput, Expansion Slots, Network Size, Mark

[Anonymous Coward]

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.

Re:Throughput, Expansion Slots, Network Size, Mark

[arivanov]

The only justification for the project existence are exchange points and load balancing. The reason is that neither of these requires any IGP.

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.

Re:Why not work on a current project, I dont get i

[ArbitraryConstant]

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.

Re:Throughput, Expansion Slots, Network Size, Mark

[ingvar]

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.

Re:Throughput, Expansion Slots, Network Size, Mark

[kc5deb]

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.

Re:OpenBSD projects

[NickHolland]

What is your goal?
If it is to run an app with the maximal buzzword compliance, ok, fine, go run ntp.org's ntpd, and enjoy it. No one is attempting to take it away from you.

If your goal is to have a clock set within any meaningful accuracies for normal people, openntpd is great. Most computers now are not running any kind of time sync program, and probably wander several seconds (or minutes) a day, assuming they were ever set within a minute or two in the first place.

WHY IN THE WORLD should OpenNTPD be bloated out to get that last few milliseconds of accuracy? MOST people don't need it. Those that do have long been running (and maintaining) ntp.org's ntpd, and they don't care about openntpd, and that's great.

If you are running a clock in pool.ntp.org, you better understand all the issues, and probably you really want to go after those last few milliseconds. For 95% of the rest of the world, OpenNTPD is a "activate and forget" tool which will enable them to do things they aren't even trying to do now, simply, safely and securely. How is that bad?

OpenNTPD is not here to eliminate ntp.org's work, it is here to complement it, and bring it to the masses. The authors do NOT intend for it to become another piece of bloatware.As for whether OpenNTPD is "SNTP" or "NTP"...WHO CARES? IF it works for you, use it. IF it doesn't don't. The world is plenty big for two options here.

Re:Throughput, Expansion Slots, Network Size, Mark

[PDXRedcat]

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.

I think you may be confusing switches with routers. Cisco has some nice switches like the 3550-48. These switches contain basic routing capabilities. The Cisco switches work well with BSD routers, and OpenBGPD fits in here. If you are talking about Cisco 10000, and 12000 models, then it's a totally different ballgame. These things when fully loaded cost more than most houses. They're generally limited to full-on service providers, not medium sized businesses with 500 employees.

No more Intel

[Santana]

FYI, buying from Intel is discouraged [theaimsgroup.com]

Re:care to elaborate?

[NickHolland]

oops, I didn't answer the other part about pool.ntp.org:
http://www.pool.ntp.org/#news [ntp.org]
see the "2004-09-07" entry.

Re:BSD License

[Anonymous Coward]

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.