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

Comments

nice

[zozzi]

I've been to the presentation of this @ Karlsruhe. From the looks of it, it looks really really well designed with a great K.I.S.S. principle all the way. Nice clean separation of userspace/kernel space and a real simple config file. I would give it a shot!

Re:Throughput, Expansion Slots, Network Size, Mark

[ctr2sprt]

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.

Most server motherboards support multiple PCI buses. At present there are usually either two or three and only one is 64/133; but in a few years I can easily see that changing as PCI bus speeds double yet again. There are already four-port ethernet NICs out there.

Right now, you're absolutely right: doing this in a PC would cost as much as or more than a dedicated solution, especially when you factor in the infamous TCO. And as you say later, small networks have no need for this sort of thing. But again, in a few years it may be affordable to do this on commodity hardware. Once the enormous cost of big iron from Cisco et al. comes down, I think a lot of those small networks might just find needs. Especially if we get into the much-touted Internet of the Future where everything has an IP address.

Re:"BSD is dyning"

[setagllib]

Pretty much. It's the same there too. Everyone wants their project to do better.

The truth is, Linux and BSD are meant to coexist, but not for the same purposes. BSDs are meant as code bases that serve purposes really very well, cleanly and with dedication. They won't just accept "any patch that compiles" as has happened in Linux a lot. They're mostly there for the developers' ideas and needs, and usually users end up with the same needs.

On the other hand, Linux is meant to be the kernel for everyone, and this seems to be the case. It runs on just about everything (even if not in the mainline kernel) and it runs pretty well for the most part. The code base is not clean, but it is functional, which is what matters scientifically. It gets contribution from unspeakable numbers of developers and research and this shows - it has something it does much better than every other system (but yes, every other system has at least one thing it does much better than Linux).

Right now I run NetBSD because I wanted production machines I could stake my life on (still living). I use Linux on my laptop mostly because it has an NVidia card for which NetBSD drivers don't exist (or at least aren't easily downloadable :)). I like Linux, it performs really well. But I don't like that it's pretty dirty and hackish, which is certainly enough to put me off it. I get the same technical advantages with NetBSD but cleaner and with less maintainance (Good Thing).

Matter of opinion though. These things change. Hell I dropped FreeBSD (see tag) after a long time of worshipping it, just because 5.3 has too many regressions to appeal to me.

Re:Throughput, Expansion Slots, Network Size, Mark

[Gadzinka]

So this really couldn't be used for core Internet routers.

Well, I believe that core Internet routers are about 1% of global router market, the rest of them rarely sees more than 100Mbit combined throughput on all WAN ports.

So, several good managed switches and couple of redundant routers on OpenBGPD would serve well over 90% of the market.

Robert

Re:BSD License

[aminorex]

You're responding to the implied criticism of OpenBSD instead of to the more direct and even more absurd criticism of open source in general. Allow me to cut to the chase: OpenZaurus is an amazing success story. Every Zaurus owner I know runs OpenZaurus instead of the Sharp software. The original poster is just a control freak who can't stand that people have the freedom to produce crap as well as gems. That's why Linux comes in commercial distributions: Crap filtering. Buy a nice OpenZaurus distribution if you want it crapfiltered.

Re:I like HP better for access switches

[JimmytheGeek]

Couple of examples:

on the HP, the command line to set ports 1,13, 22-24 for vlan 200 is:
config t (same as cisco)
vlan 200
untagged 1,13,22-24

All done. Imagine your joy setting this for 172 ports on a fairly typical HP4108gl, vs your misery doing it one port at a time on a cisco 3548. Probably should exit config mode and save, but that's not unique to HP. "Tag" is literally what vlan config does. If you are cisco-trunking (more than one vlan across a single physical link), the ethernet datagram gets a vlan tag to separate it from the 'native' vlan of the link. HP doesn't obfuscate that the way Cisco commands do.

switchport access native vlan foo
switchport trunk allowed vlan foo, bar
switchport trunk encapsulation dot1q
switchport trunk mode trunk

Plus pruning!

To make port 25 what cisco calls a trunk, and pass traffic for vlan 200 and 300 on it, vlan 200 native:

int vlan 200
untagged 25
int vlan 300
tagged 25

done. I've had some real problems getting the right config for a cisco switch to interoperate with the HP, but not vice-versa.

You can also use a text-based menu, and toggle the vlan state (untagged, no, forbid, tagged) for each port. You see them all side by side, and that helps make sure you got the config correct.

The cisco stuff just seemed crankier and less intuitive- on the cat2924, anyway, and to a lesser extent the 3548. I have two 3548s that will silently fail any vlan config commands - it accepts them, but no port behavior changes. Pending a catos update, they are basically netgears with a price tag.

I grant that it is a feature to offer vlan types besides dot1q, but not one I welcome.

Finally, on the higher end, we are burdened with VTP. I may be a luddite; I'm willing to grant that possibility for the sake of argument. But I hate automagic stuff like vtp. This just does not seem like the sort of thing we should trust our net infrastructure to work out as its whim dictates. This kind of thing just doesn't save enough sysadmin time to make up for the weird errors and such. And it's hard to turn vtp off.

This post took on a lecturing tone - sorry about that. I don't presume to have greater knowledge of cisco and vlan tech.

Oh - Snort rocks!