Slashdot Mirror
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..."
Lucky for everyone else, a BSD license will make it easy to implement in every other router box and make it cheap. Or so I hope.
No sig
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.
Many, many sites use BGP at less that 8Gbps aggregate throughput - hell I know of several sites that still run partial feeds over ISDN BRI. I just don't see where you get the idea that BGP is only for core routers.
>I wonder, then: where is the market for this....?
Perhaps when hackers start using the vulnerabilities in the BGP protocol to attack the Internet and those vulnerabilities are not found to be present or are fixed faster in the open BSD code, that'll justify the project's existence.
I mean we've already seen that open-source has fewer vulnerabilites than closed-source in general (Think I.I.S. vs Apache), so this will just become another way to secure the Internet.
I don't know the meaning of the word 'don't' - J
It appears that a lot of good stuff keeps coming out of OpenBSD. They truly focus on the things that matter (for them). Not gadgets or eye candy, but clean, solid, secure network implementations. Kudos again!
Please correct me if I got my facts wrong.
Yes, and a Boeing 747 can carry a hell of a lot more passengers than a Citroen CX. Guess which one is most cost-effective and works best for a 40-mile commute?
we don't need Linux 8-), we have {Free,Open,Net}BSD Why someone else will need a Linux ??
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.
Another thing to be mindful of are Linuxisms, like /bin/sh being a link to /bin/bash; and, for that matter, all programs being in either /bin or /usr/bin. Everyone except Linux, more or less, puts stuff in /usr/local or /opt or God knows where else. So when writing scripts, set the interpreter as the actual interpreter: if you're using bashisms in your script, don't set the interpreter as /bin/sh. Don't put in any paths at all to the interpreter, either. Do #!/usr/bin/env bash instead, which will invoke the first bash on the caller's command line. That way you don't have to care if bash is in /bin/bash, /usr/bin/bash, /usr/local/bin/bash, or /opt/bin/bash. Or, in the case of qmail, /var/bash/bin/bash.
And that improves internet speeds for everyone. So we all win. Kudos to the BSD team :)
For the love of God, please learn to spell "ridiculous"!!!
Actually, you're looking at it from the wrong perspective. For one thing, it's a work in progress. For another thing, in the same way the 'pure' OpenBSD OpenSSH was as stripped and system-dependent as possible, this will be maximally secure and hardened. When you add glue to make it stick to other systems, the glue can develop holes in it. That's the harsh fact.
:)
When this is properly out of the oven, it'll be portable (or rather will have a gluey version) and it will be great. Every project OpenBSD devs undertake is hugely successful and gets integrated into other things very quickly. OpenSSH, PF, and now this will be too. Just you watch
Sam ty sig.
You clearly have great ideas there (this is not sarcasm). You should actually tell people this. I've seen so many Linuxisms it hurts. Seeing the valiant efforts of ports/pkgsrc maintainers in trying to work around these annoying oversights is heart-breaking. Otherwise good (well, not always, but at least irreplacable software like hpoj) software ends up being very hard to get compiled and running without a lot of Makefile and script hacking.
It's not much better that people say "The X for Linux" (e.g. MPlayer) when it works just as well, sometimes better, on many other platforms, the BSDs being the closest but not only. Tip for devs: just because you wrote it on Linux doesn't mean it's FOR Linux. Linux is not the only platform that benefits from more software being written, and this should be credited. If it'll only work on POSIX-like platforms, "The X for POSIX" may sound less hype-worthy but at least it's accurate. Even so, it's better just to have "Another X" or "Yet Another X" (yacc, anyone?), since this is even more true these days, as most things people want have already been written at least once.
Open Source should be about sharing between its different platforms, not just with Linux then porting things to other systems as an afterthought. This is disgusting. Think of the quality products other systems have brought (just in this thread, for instance!) that are made properly portable because that's the Right thing to do, not out of sympathy for "those poor X users who don't have our superior layout and system calls" as Linux devs seem to take it very often.
(When I say 'X' I don't mean X11 or anything, I mean a general wildcard for any system/software name).
Sam ty sig.
are you sure?
a 1ghz athlon can forward >150k 64byte packets/sec. an opteron can do >550k/sec. this is commodity pc hardware, cheap and easy to come by.
i am quite certain a 3620 cannot do that.
also, if a part in your 3620 dies (power supply, etc) you are totally screwed unless you have a spare on-hand.
inexpensive parts huh. thats why an intel gigabit pci card costs $50 while a cisco NM-1FE-TX costs $1100? is the cisco card really 22 times better than the intel card?
not to mention you're fucked if cisco EOLs the hardware.
The pf integration is quite self-contained. It could be easily disabled or modifed to work with iptables, though I don't think iptables supports the fast radix-tree table lookups that pf does (maybe there is a module though).
Also I think the criticism about portability is not warranted. At the time that article was written OpenNTPD already supported Solaris (it was the 2nd target I did) and HP-UX support has since been added. I don't think it's valid to criticise a project that's only existed for a couple of months for "only" running on Linuxes, 4 *BSD's including OSX, and Solaris which covers the 3 main *nix families in use today (Linux, BSD, SysV). The split between OpenBSD and Portable is quite clean and the differences in the common code are small (~50 lines, the diff is in the Portable tarball).
The comment about clock disciplining is a fair point. Right now OpenBSD doesn't permit changing of tickadj at the default securelevel so another mechanism is needed in the kernel. In the mean time I've been experimenting with clock disciplining via Linux's adjtimex syscall (implemented with *zero* changes to the common code).
The comment about crypto depends on what your threat profile is. Relying on large crypto libraries means that you're less vulnerable to active attacks of the "make your clock wrong" type, possibly at the expense of being more vulnerable to attacks of the "0wnd ur b0x" type. Admittedly, in some cases (time sensitive authentications like Kerberos) the former may lead to the latter, but in many cases it can't.
Anyway, decide for yourself. You now have another option (which is why I embarked on -Portable in the first place).
$ find
The way I see it the OpenBSD wanted a slick and simple BGP daemon, not the kitchen sink.
It's much better to do one thing very well than to try and do ok with every routing protocol under the Sun.
ANYTIME you have a project that uses any software that can be bought in a box set, always buy from the project. Your employer, customer or grandma will not scoff at the tens and tens of dollars that you give to these guys to help them out.
Hell, even if you spark up a mailserver in a pinch using downloaded ISOs, always go back and buy the damned box set later on. Make it a line item on your bill, include it in the budget, do whatever you have to do.
I have purchaced a fair amount of packaged CD sets from Slackware, OpenBSD, Redhat, Debian, etc. and have never spent a single dime of my own money.
-ft
use your turn signal! you people act like it's divulging information to the enemy
They're unstable, incompatible, bloated, insecure, and quite importantly, virally bound to the GPL, which is most definately contrary to the BSD philosophy. PF was created (mainly) because the license was not acceptable.
To fix inherent problems, you almost always have to fork because of the incompatibilities. Plus, what advantage would it provide over starting from scratch? They're already screwed in the license department, since it's GPL'd.
What would you rather do... Build a house from the ground up, or take someone's completely trashed and poorly built house, and try to repair the entire thing? Often times, starting from scratch is the better option.
To you, but you aren't among the developers, so you get no say. They wanted something for BSD, just like they did with OpenSSH, just like they did with OpenNTPD, and PF.
If someone wants to put the effort into porting it, they can. If you want to import much of the code into Quagga, go right ahead. They see no benefit from doing that, though plenty of drawbacks for them, so they didn't do things that way.
<LICENSE_RANT>
I'd like to remind people that nothing has ever become a standard, with a GPL license attached to it. Things like TCP/IP, NFS, FTP, SMTP, DNS, all BSD (or even less restrictive) licensed, so others could actually use it, without having to sign the restrictive license that is the GPL. If nothing else, being BSD-licensed may give OpenBGPd a big audience of companies looking to integrate it.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant