OpenBSD Project Announces OpenBGPD 241
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..."
nice (Score:5, Interesting)
Zebra (Score:1, Interesting)
Re:Throughput, Expansion Slots, Network Size, Mark (Score:1, Interesting)
- Experimentation
- Small ISPs that cannot afford cisco
- Competition is good
- etc. etc.
Re:Throughput, Expansion Slots, Network Size, Mark (Score:5, Interesting)
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:OpenBSD projects (Score:3, Interesting)
From what I can gather from various NTP mailing lists, this is an SNTP-implementation, not an NTP-implementation. SNTP is just a subset of NTP, and not a fully functional NTP daemon.
If I'm not entirely mistaken, you're not allowed to join into the pool.ntp.org -pool if you're running OpenNTPD
Hope the OpenNTPD developers will address this and make the service fully compliant.
Re:Throughput, Expansion Slots, Network Size, Mark (Score:4, Interesting)
Now small networks need BGP as well. It's the best way to have multiple redundant links to providers while running servers beyond mail. I have a small pile of clients some as small as a couple T1's running BGP between two providers.
Re:For a broader knowledge see also this (Score:3, Interesting)
But since nobody is mentioning it... I thought GateD was a BGP routing thingie too, but I am not sure of that....
Re:"BSD is dyning" (Score:5, Interesting)
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
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 (Score:5, Interesting)
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
8gbits is quite a lot (Score:1, Interesting)
Cheers,
Reports of Cisco's Death... (Score:3, Interesting)
I case you really are stuck in 1987, Cisco does a couple more things than routing these days.
Why just a few weeks ago, I setup a multi-site network using Cisco switches and multiple VLAN's and I typed in the appropriate commands (yes, cryptic until you bother to learn) and it worked. No fuss, no troubleshooting, free documentation - this is why people buy Cisco..
Yes, they're market-dominant, yes, they're expensive (hint: buy refurb) and yes, they're into certifications and the like, but that doesn't make them Microsoft. Imagine if Microsoft made rock-solid products and wasn't always trying to screw the rest of the world.
Now, start setting up VOIP networks, dynamic VLAN's and fully-meshed WAN networks, stuff a dozen or more pieces in a rack, and you'll start to see that a PC with a FOSS OS isn't always the right answer.
Re:OpenBSD projects (Score:1, Interesting)
> mailing lists, this is an SNTP-implementation,
> not an NTP-implementation.
This is FUD spread by an idiot who completely fails to understand the protocol and, more importantly, completely misses why the majority of machines these days still have unsynchronized clocks...
Re:BSD License (Score:5, Interesting)
Re:Throughput, Expansion Slots, Network Size, Mark (Score:1, Interesting)
Now the catch is that we were running our tweaked version of NetBSD on the x86 control plane, which was running the routing daemons. So if there is a BSD licenced BGP out there, it is possible to deploy it on the above mentioned box.
So my point is that we actually have rather fancy boxes out there running *BSD.
Re:Throughput, Expansion Slots, Network Size, Mark (Score:2, Interesting)
Re:care to elaborate? (Score:2, Interesting)
http://bradknowles.typepad.com/considered_harmful
And yes, I consider it nonsense, but rather than name calling, I'll happily share it and let you decide how not matching every feature of another program is "harmful". If you agree, don't run OpenNTPD. That simple.
Re:Throughput, Expansion Slots, Network Size, Mark (Score:3, Interesting)
Re:Throughput, Expansion Slots, Network Size, Mark (Score:1, Interesting)
Re:BSD License (Score:3, Interesting)
Well, OK, but I'd bet your life ;-)
Sorry, it's that time of year and I've got NMBC on my mind...I like HP better for access switches (Score:4, Interesting)
1) Cost. We could buy NEW HP layer 2 switches for the price of refurb/used Cisco l2 switches. And the HP kit comes with a product lifetime warranty.
2) Support cost. We're planning to replace our Cisco 12000 GSRs with Foundry or Juniper stuff. The maintenance contract cost alone justifies trashing the old equipment and buying new. WTF?
3) IOS/CatOS variety Ever read a nightmarish vulnerability alert and had to figure out if it applied to you? And if so, what you need to upgrade to? There are THOUSANDS of versions, most of which are described generically. And at least once I've been told that a fix was backported, so the version number didn't increment.
4) Usability - HP kicks their asses at the access switch level. It is much easier to set up a bunch of inter-tied VLANS. The syntax is clearer and cleaner. I think every config I've tried to do is easier on the HP family. We updated a bunch of equipment all at once, mostly one model (HP2524, with a few HP4108gl's). It may be that other members of the product line are lame.
I will grant that Cisco tech support is good, and their stuff is good. But there are definitely elements of "We're No. 1, so open your wallet"
Re:I like HP better for access switches (Score:5, Interesting)
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!
Re:Why not work on a current project, I dont get i (Score:3, Interesting)
Look at the BSD tools versus GNU tools. They do fundamentally the same things, but GNU tools are usually tens of times larger because they do lots of things only one or two people alive would want. This means those one or two people find GNU tools more convenient, while the rest of us like being able to compile the whole *BSD world in 1 hour on a slow machine, where a GNU-based system takes an hour to compile JUST glibc on the same hardware.
In the running system, GNU tools are handier, since they have more modern defaults, more convenient shortcuts to doing things (default of . for find(1), default output of stdout instead of the tape device for tar, and so on), etc. but the BSD tools are usually a load easier to know the full functionality of. Look at BSD indent versus GNU indent (which is a fork of BSD indent). The latter has every feature under the sun, many of which never will be used. The former hasn't changed much in years and still does what it always did well, nobody complains. The latter can be more convenient, but at the cost of code size, sometimes even cleanliness... no thanks.
But yeah, that's my point. The BSDs focus on the functionality something is meant for, and do it as cleanly as possible. The 'other' software doesn't have this focus. Which you consider 'better' is all about your priorities I suppose.
Re:Doesn't compile on Linux (Score:4, Interesting)
But yeah, something like this does sound like a kernel task as much as user. But if Linux users now endorse udev, anything can happen. Personally I think it's a terrible idea but that's just me. Thank root Linux devs don't engineer security.
OpenBSD always seem to work out the Right Way for these things, they haven't failed at a project yet. Don't anybody bring up those flawed scalability benches, who really cares? If you want scalability, you know where to find it. OpenBSD brings practically flawless security and quality where they step, and they have pioneered a lot of development in security that has made modern unices what they are renowned for.
And yet, I've never run OpenBSD