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

62 of 241 comments (clear)

  1. BSD License by secolactico · · Score: 4, Insightful

    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
    1. Re:BSD License by BJH · · Score: 5, Insightful

      As opposed to a security hole in a closed-source router... like a Cisco?

      A default username/password pair is present in all releases of the Wireless LAN Solution Engine (WLSE) and Hosting Solution Engine (HSE) software. A user who logs in using this username has complete control of the device. This username cannot be disabled. There is no workaround.

      Golly, if you had the source, you might be able to do something like... hmmm... I dunno... disable the default password, maybe?

    2. Re:BSD License by Anonymous Coward · · Score: 2, Informative

      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.

    3. Re:BSD License by Anonymous Coward · · Score: 5, Informative

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

    4. Re:BSD License by OttoM · · Score: 4, Informative
      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, 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.

    5. Re:BSD License by Anonymous Coward · · Score: 2, Informative

      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.

    6. Re:BSD License by Anonymous Coward · · Score: 2, Insightful

      > As opposed to a security hole in a closed-source router... like a Cisco?

      At least Cisco does not change the definition of "security hole" each time one is found on their routers. ;-)

    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. Re:BSD License by ulib · · Score: 2, Insightful
      Your post is very funny (that's why I'm answering to an AC). Now, back to the Land of Reason: the issue of course isn't rocket science, it's copyright infringement.
      Like a comment on this board pointed out, "Hubert's page shows portions of the scripts that are _character for character_ identical between g4u and g4l". And indeed, everybody can judge for themselves: I don't think the illicit ripoff can even be considered a debatable point.

      What's particularly vile is the fact that the "author" of g4l (the ripoff) keeps hiding behind anonimity - ..it's a *very big* AC. :)

    9. Re:BSD License by Rick+the+Red · · Score: 2, Interesting
      Um, no, not in "every other router box," only those that are willing to open their code. If Microsoft (to pick on a clearly closed-source company) were to make a router, I'd bet my life they'd never use GPL code in it.

      Well, OK, but I'd bet your life ;-)

      It's much more fun, I must confess, when lives are on the line.
      Not mine of course, but yours old boy, now that would be just fine.
      -- Oogie Boogie, "The Boogie Song"
      Sorry, it's that time of year and I've got NMBC on my mind...
      --
      If all this should have a reason, we would be the last to know.
  2. Throughput, Expansion Slots, Network Size, Market by Anonymous Coward · · Score: 5, Insightful

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

  3. 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!

    --
    ---
  4. Doesn't compile on Linux by quigonn · · Score: 3, Informative

    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.

    --
    A monkey is doing the real work for me.
    1. Re:Doesn't compile on Linux by Anonymous Coward · · Score: 4, Funny

      Yeah. Now you Linux users get to feel the pain the BSD users feel for EVERY FUCKING 3RD PARTY PIECE OF SOFTWARE UNDER THE SUN written by Linux weenies.

    2. Re:Doesn't compile on Linux by dmiller · · Score: 4, Informative

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

    3. Re:Doesn't compile on Linux by Anonymous Coward · · Score: 5, Informative

      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

    4. Re:Doesn't compile on Linux by agent+dero · · Score: 4, Funny

      What are you talking about?!

      I'm running FreeBSD on the desktop, and I've only had trouble getting the following binaries to compile and run: GTK, Qt, Firefox, Java 1, Java 2, Java 5, gaim, xchat, evolution, mozilla, thunderbird, open office, koffice, gedit....garsh, I don't know what the parent poster is talking about, sheesh

      .....at least xterm works! w00t!

      --
      Error 407 - No creative sig found
    5. Re:Doesn't compile on Linux by ripleymj · · Score: 3, Informative

      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.

    6. Re:Doesn't compile on Linux by Cargnini · · Score: 2, Insightful

      we don't need Linux 8-), we have {Free,Open,Net}BSD Why someone else will need a Linux ??

    7. Re:Doesn't compile on Linux by Eivind+Eklund · · Score: 5, Insightful
      Disclaimer: I'm a FreeBSD developer, with the bias that brings.

      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.
    8. Re:Doesn't compile on Linux by setagllib · · Score: 2, Insightful

      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.
    9. Re:Doesn't compile on Linux by dmiller · · Score: 3, Insightful

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

    10. 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.
  5. Re:Throughput, Expansion Slots, Network Size, Mark by matthew.thompson · · Score: 5, Insightful

    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.
  6. Re:Throughput, Expansion Slots, Network Size, Mark by dmiller · · Score: 4, Insightful

    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.

  7. Re:Throughput, Expansion Slots, Network Size, Mark by Progman3K · · Score: 4, Insightful

    >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
  8. OpenBSD projects by pchan- · · Score: 5, Informative

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

    1. Re:OpenBSD projects by arcade · · Score: 2, Interesting

      OpenNTPD, a network time protocol daemon and server, recently released.

      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.

      --
      "Rune Kristian Viken" - http://www.nwo.no - arca
    2. Re:OpenBSD projects by NickHolland · · Score: 2, Informative

      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.

  9. Go OpenBSD! by RAMMS+EIN · · Score: 4, Insightful

    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.
  10. Re:For a broader knowledge see also this by Anonymous Coward · · Score: 3, Informative

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

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

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

  12. That's the stupidest argument ever by Gordonjcp · · Score: 4, Insightful
    You *always* hear this when someone mentions using a PC as a router "Oh, PCs are too slow to route multi-gigabyte connections, Cisco are far better".


    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?

  13. 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.
  14. 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!
  15. Re:I feel your pain. Any suggestions... by Anonymous Coward · · Score: 4, Insightful
    Man pages. Seriously. GNU is good about documenting their extensions, and better yet, they explain why they wrote those extensions. Usually they say things like "SVR4 had a buggy implementation, so we rewrote it to work right." Well, the GNU folks probably aren't the only ones with that idea, so you may find that other OSes have "fixed" the implementation, deviating from the de facto standard. Those are all potential trouble spots, so you should stay away from them if you can.

    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.

  16. Re:luckily by Lifewish · · Score: 2, Insightful

    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"!!!
  17. Re:Throughput, Expansion Slots, Network Size, Mark by SorcererX · · Score: 2, Informative

    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.

    --
    Any sufficiently advanced technology is indistinguishable from magic.
  18. 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.
  19. Cisco routers use PCI bus by puzzled · · Score: 4, Informative



    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.

    --
    I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
    1. Re:Cisco routers use PCI bus by bani · · Score: 2, Insightful

      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.

  20. Re:Throughput, Expansion Slots, Network Size, Mark by Anonymous Coward · · Score: 2, Informative

    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.

  21. Re:I feel your pain. Any suggestions... by setagllib · · Score: 3, Insightful

    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.
  22. 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
  23. Re:Throughput, Expansion Slots, Network Size, Mark by arivanov · · Score: 3, Informative
    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.

    --
    Baker's Law: Misery no longer loves company. Nowadays it insists on it
    http://www.sigsegv.cx/
  24. Reports of Cisco's Death... by bill_mcgonigle · · Score: 2, Interesting

    Lucky for Cisco, BSD is dying...

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  25. Re:Why not work on a current project, I dont get i by ArbitraryConstant · · Score: 2, Informative

    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.

    --
    I rarely criticize things I don't care about.
  26. Re:Throughput, Expansion Slots, Network Size, Mark by ingvar · · Score: 2, Informative

    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.

  27. Re:Throughput, Expansion Slots, Network Size, Mark by kc5deb · · Score: 2, Informative

    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.

  28. Re:Throughput, Expansion Slots, Network Size, Mark by Anonymous Coward · · Score: 2, Interesting

    You don't know much about BGP and its real world uses, don't you? First of all, there are a lot of relatively simple, relatively slow WANs using BGP both internally and on their borders. For example, just being dual-homed the right way (TM) with 2 ISPs for resiliency, even with slow T1 links, means that you're doing BGP. Second, even in ISPs and large companies you could have lots of situations where you could appreciate having a cheap, flexible PC doing BGP. Route reflectors, non-core routers (relatively slow customers/PoPs/remote offices), routers injecting BGP-learned routes into OSPF or other internal protocols (and vice-versa), etc.

  29. Re:care to elaborate? by NickHolland · · Score: 2, Interesting

    Most probably, this:
    http://bradknowles.typepad.com/considered_harmful/ 2004/09/openntpd.html

    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.

  30. Re:Throughput, Expansion Slots, Network Size, Mark by PDXRedcat · · Score: 4, Informative
    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.
  31. No more Intel by Santana · · Score: 2, Informative

    FYI, buying from Intel is discouraged

    --
    The best way to predict the future is to invent it
  32. Re:care to elaborate? by NickHolland · · Score: 2, Informative

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

  33. Re:Throughput, Expansion Slots, Network Size, Mark by drinkypoo · · Score: 2, Interesting

    PCI will go away soon enough in PC-land. We'll be moving on to PCI-Express. You get to pick your bandwidth and it gets a lot faster than PCI in the top end. I figure Cisco will be moving to PCI-Express as well, to take advantage of preexisting designs.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  34. Re:care to elaborate? by Tuck · · Score: 3, Insightful
    When you're reading it, please note that the stratum and refid (the comment about ntptrace) things have been fixed in (in OpenBSD -current or portable snapshot).

    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 /pub -beer "James Squire Amber Ale" -drink
  35. 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!

  36. ALWAYS buy the CD when on projects by Loualbano2 · · Score: 2, Insightful

    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

  37. Re:Throughput, Expansion Slots, Network Size, Mark by 74nova · · Score: 3, Insightful
    Just because it's BSD doesn't mean that it's going to be limited to PC Architecture.
    isnt the fact that its bsd the exact reason why it isnt limited to pc architecture? im no bsd guru, but i know its available for almost every processor in existence.
    --
    use your turn signal! you people act like it's divulging information to the enemy
  38. Re:Why not work on a current project, I dont get i by setagllib · · Score: 2, Interesting

    That's the BSD Way, as far as I have seen. To do one thing and do it very well, and only add more functionality if people really want/need it.

    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.

    --
    Sam ty sig.
  39. Re:Why not work on a current project, I dont get i by evilviper · · Score: 4, Insightful
    Zebra and Quagga already exist.

    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.

    Improving the architecture of say Quagga will be more beneficial and probably welcome than forking out your own.

    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.

    sounds much better than an all OpenBSD suite.

    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