Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet Operating Systems Security BSD

OpenBSD Project Announces OpenBGPD 241

Posted by timothy from the it's-a-border-not-a-barrier dept.
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..."
This discussion has been archived. No new comments can be posted.

OpenBSD Project Announces OpenBGPD More

OpenBSD Project Announces OpenBGPD

Comments Filter:

  • BSD License (Score:5, Insightful)

    by secolactico ( 519805 ) * on Tuesday November 09, 2004 @06:47AM (#10764558) Journal
    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.

  • Throughput, Expansion Slots, Network Size, Market (Score:5, Insightful)

    by Anonymous Coward on Tuesday November 09, 2004 @06:50AM (#10764572)
    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.
    • 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.

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:5, Insightful)

      by Progman3K ( 515744 ) on Tuesday November 09, 2004 @07:03AM (#10764615)
      >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.

      • Re:Throughput, Expansion Slots, Network Size, Mark (Score:4, Informative)

        by arivanov ( 12034 ) on Tuesday November 09, 2004 @09:49AM (#10765727) Homepage
        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.

        • 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.
          • Been there, done that as a result of not knowing how to configure IGP on a unix box 10 years ago with gated. No thanks.

            In btw, exchange points and load balancing are still more then enough to make a living off. And hopefully someone will at get an OSPF daemon working or get a good API to use this BGP daemon with a foreign OSPF implementation which lacks in terms of BGP.

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:5, Interesting)

      by ctr2sprt ( 574731 ) on Tuesday November 09, 2004 @07:30AM (#10764716)
      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.

    • That's the stupidest argument ever (Score:5, Insightful)

      by Gordonjcp ( 186804 ) on Tuesday November 09, 2004 @07:40AM (#10764753) Homepage
      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?

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

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:2, Informative)

      by Anonymous Coward
      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 Open

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:5, Interesting)

      by Gadzinka ( 256729 ) <rrw@hell.pl> on Tuesday November 09, 2004 @09:39AM (#10765623) Journal
      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
    • 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.

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:2, Interesting)

      by Anonymous Coward
      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 s

    • Re:Throughput, Expansion Slots, Network Size, Mark (Score:4, Informative)

      by PDXRedcat ( 29992 ) on Tuesday November 09, 2004 @11:32AM (#10766655)
      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.

    • How about a 32 lane PCI-E implementation with no lames or blinks devoted to Doom III? 40Gbps backplane, bidirectional.

      http://arstechnica.com/articles/paedia/hardware/ pc ie.ars/5

      PCIe's bandwidth gains over PCI are considerable. A single lane is capable of transmitting 2.5Gbps in each direction, simultaneously.

    • It is good for small ISPs who don't have a lot of peers. It obviously isn't meant for high bandwidth core inernet routers. Also, OpenBGPD might be good for businesses that need to manage multiple internet connections to different ISPs. BGP is the only way to go if you actually want to have real connectivity redundancy. It isn't uncommon.

      -matthew

  • nice (Score:5, Interesting)

    by zozzi ( 576178 ) on Tuesday November 09, 2004 @06:51AM (#10764574)
    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!

  • Doesn't compile on Linux (Score:3, Informative)

    by quigonn ( 80360 ) on Tuesday November 09, 2004 @06:58AM (#10764593) Homepage
    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.

    • Re:Doesn't compile on Linux (Score:4, Funny)

      by Anonymous Coward on Tuesday November 09, 2004 @07:01AM (#10764606)
      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.

      • Re:Doesn't compile on Linux (Score:4, Funny)

        by agent dero ( 680753 ) on Tuesday November 09, 2004 @07:37AM (#10764737) Homepage
        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!
        • While I sympathize, isn't that exaggerating a bit much?

          At home, I have a FreeBSD web/mail/DNS server that I use for personal domains and other lightweight purposes. I also had a Debian desktop that I used on the rare occasion that the wife and kids would let me play with it. Over the weekend, I decided that it made far more sense to consolidate the two than to maintain and power two similar underused computers.

          It would've been a complete nightmare to move all the services over to Debian (since there w

          • but I'm more than happy to let a nameless FreeBSD ports maintainer (I have a few myself) do the hard work for me

            You think slavery is fun, huh? Which maintainers are you hiding exactly? I will report you!

    • Re:Doesn't compile on Linux (Score:5, Informative)

      by dmiller ( 581 ) <djm@mindro[ ]rg ['t.o' in gap]> on Tuesday November 09, 2004 @07:06AM (#10764628) Homepage
      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 :)

    • Re:Doesn't compile on Linux (Score:5, Informative)

      by Anonymous Coward on Tuesday November 09, 2004 @07:27AM (#10764702)
      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
      • we don't need Linux 8-), we have {Free,Open,Net}BSD Why someone else will need a Linux ??

      • Re:Doesn't compile on Linux (Score:4, Interesting)

        by setagllib ( 753300 ) on Wednesday November 10, 2004 @03:37AM (#10774735)
        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 :)

    • Re:Doesn't compile on Linux (Score:5, Insightful)

      by Eivind Eklund ( 5161 ) on Tuesday November 09, 2004 @08:17AM (#10764958) Journal
      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.

      • Ten to fifteen years ago, there was usually some work involved, but the average was less, and it was spread out.

        Whenever I read the occasional flamewar about the GNU autoconf/automake/libtool suite, some people will claim that portability ten to fifteen years ago was awful and the these tools are a god-send, even though my own experience differs. I still don't understand the modern need for these tools, when a solid POSIX makefile and well-conceived header files are easier to get working on various platf
    • 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 un

  • OpenBSD projects (Score:5, Informative)

    by pchan- ( 118053 ) on Tuesday November 09, 2004 @07:20AM (#10764679) Journal
    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 [openssh.org], who's box doesn't have this?
    OpenNTPD [openntpd.org], a network time protocol daemon and server, recently released.
    OpenBGPD [openbgpd.org], 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 [openbsd.org] 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 [openbsd.org] even though i am not an openbsd user. these sales help keep these projects going.

    • Re:OpenBSD projects (Score:3, Interesting)

      by arcade ( 16638 )
      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.
      • even send in some links, so I can lazily NOT google for them... :-) please?
        • Most probably, this:
          http://bradknowles.typepad.com/considered_harmful/ 2004/09/openntpd.html [typepad.com]

          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.
          • oops, I didn't answer the other part about pool.ntp.org:
            http://www.pool.ntp.org/#news [ntp.org]
            see the "2004-09-07" entry.

          • Re:care to elaborate? (Score:4, Insightful)

            by Tuck ( 41529 ) on Tuesday November 09, 2004 @04:21PM (#10769720) Homepage
            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 [zip.com.au]).

            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 [zip.com.au] (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).

      • Re:OpenBSD projects (Score:2, Informative)

        by NickHolland ( 91075 )
        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 b
      • From what I understand it does do NTP, but probably not V3 or V4. The reason I removed it is that it doesn't have ntpdate, ntpq, et cetera, so you can't even check on its status, you just have to trust that it's working.
    • 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
      • That's actually a pretty good idea. Double-whammie - help them and get a 'free' (for you) copy of a great system.

        Personally if I like what I see of OpenBSD when I try it, I'll buy it anyway, my money or not. It's the kind of thing that is so great you feel good having the real set of, as opposed to Windows where you feel even having a 'free' (cough) CD provided by Dell or whoever is a waste of money manufacturing. Not that I'm bashing Windows per se, it has its uses, but the license of one key per 'owner'

  • Go OpenBSD! (Score:5, Insightful)

    by RAMMS+EIN ( 578166 ) on Tuesday November 09, 2004 @07:21AM (#10764683) Homepage Journal
    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!

  • Cisco routers use PCI bus (Score:5, Informative)

    by puzzled ( 12525 ) on Tuesday November 09, 2004 @08:56AM (#10765287) Journal


    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.

    • 1. It is PCI, but the modules do not use the standard PCI pinout and are not standard as per any of the available PCI standards (normal, mini or compact). You are correct - they use classic PCI chips. Early 36xx ethernet network modules used AMD lance, more recent ones use Intel.

      2. 72xxx is also PCI, once again with a different card form factor.

      3. The performance has nothing to do with tuning. It has to do with offloading heavily to cards various functions like checksumming and a lot of layer2 work.
    • 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 i


      • Cisco EOL is not an issue.

        http://www.optimumdata.com
        http://www.nhri.com
        http://www.whirled-routers.com
        http://www.quadra source.com

        and on and on and on and on ...

        and

        http://ebay.com

        • Thats all very nice. Gee, I would never have thought of looking on ebay. Pure genius. Really.

          However EOL most certainly is an issue if a new sploit or bug is discovered. IOS for EOL'd ciscos wont be updated. This is already an issue for many Cisco models. You are well and truly fucked if you are stuck with one. Only option -- upgrade to a newer model. Suddenly, Cisco isnt so cost effective anymore.

          nhri.com? quadrasource.com? you're quite sure about those URLs, are you?
      • He meant "inexpensive for Cisco", not "inexpensive for you". Markups, ya know.
      • Hey easy there, we get the idea :)

        PCs with free software are worlds of freedom. Embedded or otherwise 'specialty' hardware usually has less freedom and costs a ton more. Personally I don't want a router even though they're cheap and effective, because I like having complete control over my gateway (and being able to use it as an emergency internet client :))

        But I think you're exaggerating the 'danger' of CISCO kits. Are they really going to tell you to go f*ck yourself if you ask for part replacement
  • Zebra and Quagga already exist. They are supposed to provide BGP among other protocols. I just dont get why they dont join those projects to improve them rather than fork out a new one.

    Improving the architecture of say Quagga will be more beneficial and probably welcome than forking out your own. It would also keep the code portable while supporting rip, ospf isis etc. I'd love to see a secure version of Quagga for OpenBSD, sounds much better than an all OpenBSD suite.
    • 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.

    • Re:Why not work on a current project, I dont get i (Score:5, Insightful)

      by evilviper ( 135110 ) on Thursday November 11, 2004 @02:58AM (#10785462) Journal
      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.

  • Reports of Cisco's Death... (Score:3, Interesting)

    by bill_mcgonigle ( 4333 ) * on Tuesday November 09, 2004 @10:11AM (#10765885) Homepage Journal
    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.
    • Cisco IOS, and its single config file, absolutely rocks. I was just looking at the man page for the config file for this project, and it stuck me as absurd that they didnt use the same syntax.

      What I would love would be an IOS or IOS clone that ran on common x86 hardware, becuase, as you note, Cisco HW is expensive, even if you do buy used/refurb.
    • 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"

      • 4) Usability - HP kicks their asses at the access switch level. It is much easier to set up a bunch of inter-tied VLANS.

        I agree with all of your points but this one is perplexing. I'm running 802.1Q VLAN trunking and the configuration is 2 lines on each of the trunked ports and 2, maybe 3 lines on each member port. How does HP improve?

        I'm glad to hear there's good competition as my 3 biggest complaints with Cisco are Price, Price, Price. I already recommend other solutions where frequent updates/cont
        • 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!
  • "an BSD-licensed implementation of the Border Gateway Protocol, BGP"

    So I guess this now means Longhorn will support BGP.
    • >So I guess this now means Longhorn will support BGP.

      Short answer: hopefully.
      Longer answers: here [slashdot.org] and here [slashdot.org]
      (..i'm starting to think that a bot could come in handy ;)
      --
      Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

      • That's absolutely right ("hopefully"). The more secure and trustworthy (read: OpenBSD :P) code Microsoft and whoever else import, the safer the internet will be. I think security and quality should come before political agendas regarding defeating corporations. Microsoft is not going to go away any time soon, so it may as well gets its act together and release at least one secure product.

        As Theo himself said, their security is our security, since every compromised machine on the net is yet another drone

Slashdot Top Deals

Avoid strange women and temporary variables.

Close