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

10 of 241 comments (clear)

  1. nice by zozzi · · Score: 4, Interesting
    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!

    --
    ---
  2. Re:Throughput, Expansion Slots, Network Size, Mark by ctr2sprt · · Score: 4, Interesting
    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.

  3. Re:Throughput, Expansion Slots, Network Size, Mark by silas_moeckel · · Score: 3, Interesting

    I agree with you on throughput limitations. But lets look at some facts. The second biggest router company manages there rotuers with a BSD kernel (Juniper) and runs the routing bits in that kernel (with hooks to move everything into hardware once the desision is made) PC's make good general purpose routing procs they make poor packet shufflers if you take a felable platform with a lot of headroom you can make a great administrative box and if it's coupled with a good hardware asic to push packets it can scale.

    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.

    --
    No sir I dont like it.
  4. Re:For a broader knowledge see also this by Skinkie · · Score: 3, Interesting

    Too bad that the BGP part of Quagga is actually working well and the OSPF part is dieing like hell. So personally I hope for an OpenOSPF too.
    But since nobody is mentioning it... I thought GateD was a BGP routing thingie too, but I am not sure of that....

    --
    Support Eachother, Copy Dutch Property!
  5. Re:"BSD is dyning" by setagllib · · Score: 4, Interesting

    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.

    --
    Sam ty sig.
  6. Re:Throughput, Expansion Slots, Network Size, Mark by Gadzinka · · Score: 4, Interesting

    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

    --
    Bastard Operator From 193.219.28.162
  7. Re:BSD License by aminorex · · Score: 4, Interesting

    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.

    --
    -I like my women like I like my tea: green-
  8. I like HP better for access switches by JimmytheGeek · · Score: 3, Interesting

    I have some complaints about Cisco.

    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"

    1. Re:I like HP better for access switches by JimmytheGeek · · Score: 4, Interesting

      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!

  9. Re:Doesn't compile on Linux by setagllib · · Score: 3, Interesting

    henning = phk? Good work on devfs!

    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 :)

    --
    Sam ty sig.