OpenBSD Journal

OpenBSD gets its own BGP daemon

Contributed by jose on from the internet-routing dept.

Henning has imported a BGP daemon for OpenBSD. For those of you that don't know, BGP is an exterior gateway routing protocol used between large networks. Here is the commit message:

CVSROOT:        /cvs
Module name:    src
Changes by: 2003/12/17 04:46:54

Added files:
        usr.sbin/bgpd  : Makefile bgpd.c bgpd.h buffer.c config.c 
                         ensure.h imsg.c log.c mrt.c mrt.h parse.y rde.c 
                         rde.h rde_decide.c rde_prefix.c rde_rib.c 
                         session.c session.h 

Log message:
welcome, bgpd
started by me some time ago with moral support from theo, the proceeded up to
the point where the session engine worked correctly. claudio jeker joined
then and did a lot of work in the RDE.
it is not particulary usefull as application right now as parts are still
missing but is imported to enable more people to work on it.
BGP sessions get established fine, OPEN messages and then KEEPALIVEs
exchanged etc. session FSM works fine; NOTIFICATIONs are handled fine, and
all connection drops etc I provoked get handled fine.
Incoming UPDATE messgages are parsed well and the data entered to the RIB,
the decision process is not yet there, neither is outgoing UPDATEs or sync
to the kernel routing table.

not connected to the builds yet.

BGPd has undergone a lot of activity this past week and could use some testing.

(Comments are closed)

  1. By Anonymous Coward () on

    The OpenBSD guys are just exciting!
    Especially Henning, whom I've met once, knows what he does and when they get this done it will for sure be a good piece of work and one more step towards OpenBSDs ability to replace many expensive routers with definitely more flexible OpenBSD boxen.

    Keep up the good work!

  2. By Christophe Prévotaux () on

    Nice to hear someone is working on BGP4.
    But what is the goal of this ?

    Will there be OSPF as well ?

    Are you trying to replace Zebra (support of Zebra has to say the least flaky).

    Other things of great need would be:

    1) Kernel PPPoE (with very good perfs) server mode (with radius support and bandwidth throttling (symetrical and asymetrical per PPPoE session) maybe even some Built in PF/ALTQ magic (like automatic rules insertion)

    2) MPLS stack (VPN-MPLS, MPLS-TE etc..)

    3) a UDLR implentation

    That will be all for my Xmas wish list :)

    1. By Anonymous Coward () on

      And I bet the dev guys could code this till christmas ;-)

    2. By Bryan () on

      Definately Zebra is pretty crappy. So crappy that I stick with hand-building static-routes on my OBSD systems. But Zebra AFAIK is RIP. So unless I'm missing something, this won't be a replacement if you are using RIP on your network :-/

      1. By Anonymous Coward () on

        According to Zebra's homepage they support BGB4 as well.
        And - suprise, surpise - it seems they're still active. Lates release is 0.94 from 2003/11/27 !

        1. By MotleyDawg () on

          Maybe because Quagga has been active lately, Zerba decided to release something?


          Quagga 0.96.4 contains a fix for a remote DoS in the vty layer, ie the telnet CLI. Please see [quagga-users 906] for further details.

      2. By Anonymous Coward () on

        routed is a daemon invoked at boot time to manage the network routing tables. It uses Routing Information Protocol, RIPv1 (RFC 1058), RIPv2(RFC1723), and Internet Router Discovery Protocol (RFC1256) to maintain the kernel routing table ...

      3. By Anonymous Coward () on

        So maybe you should not say how crappy it is.

      4. By Gernot () on

        These two lines pretty much sum it up. You don't appear to have the slightest clue what you are talking about. I bet that never in your life you have ever installed zebra nor do you have a clue about RIP's operation. Of course, on PC and a gateway are certainly fine with a static route of last resort.

      5. By sthen () on

        This reads much better if you s/Zebra/routed/g, I wonder if perhaps you were momentarily confused between them? A popular 'replacement' for RIP is OSPF - BGP solves a rather different problem.

        But all of these protocols (IGPs) are really better suited for a network where it's not feasible to maintain static routes, e.g. dialup/ISDN/wireless/ADSL/leased-line users connecting across multiple access-servers at a POP.

        BGP is used to manage the routing to different AS on a multi-homed network, quite a different thing. It would be run between routers which already have basic IP connectivity between them (either by a dynamic IGP like RIP or OSPF), on the same ethernet, or by static routes.

        There are few possibilities if you'd like to talk BGP reliably without an Expensive router, especially if you'd like enough RAM for a couple of full BGP feeds, so I think many will welcome a worthwhile entry to this area. I can see a certain amount of demand for something which relieves aging Ciscos of BGP and packet-filtering duties, leaving them to run OSPF and push packets between POPs ...

    3. By djm () on

      I don't think MPLS makes as much sense as OSPF. Perhaps someone could take a crack at the Kame OSPF (semi-)implementation and get it working...

      But doesn't IBM have a major patent over OSPF? (IIRC, could be wrong)

      1. By Anonymous Coward () on

        OSPF is an open protocol designed by the IETF.

        1. By Anonymous Coward () on

          just because it is designed by the IETF does not mean there are no patents covering the protocols they set forth. VRRP is a good example.

    4. By mirabile () on

      Nobody needs kernel PPPoE.
      Especially, I don't think it would ever get
      (im)ported because the BSD guys tend to think
      that userland ppp(8) has advantages over
      partial-kernel-land pppd(8) [which I've used
      when I had a modem, no ADSL].

    5. By Henning () henning@ on mailto:henning@

      well, the goal is to have a free, good and working bgpd daemon.
      each of those requirements rules zebra out.
      yes, frustration with the existing bgp daemons was a a strong point in starting that.
      i have some evil ideas that i am not going to disclose yet, that would take all the fun out of it. of course this abuses teh fact that we have a whole OS under control.
      an ospfd is not planned yet but certainly possible.
      mpls would be cool cool to have but i haven't even thought about that yet. there's enough work left in bgpd for some time.

      1. By cruel () on

        the most evil idea is already here: openbsd is going to replace expensive cisco boxes :)

        let me guess... the next logical step after the CARP and pf state sync is routing table sync ;) after all of these we can get two boxes connected via cross-over cable and ready to handle all of each other tasks: redundant connections handling and redundant routing table handling.

        oh, sorry, plus bgpd of course :)

        1. By djm () on

          You should use a routing daemon to keep the route tables in sync. Anyway it isn't always desirable - e.g. you may want to use equal-cost routing to load balance between two boxes, so you would *want* the routing table to be (slightly) different.

          1. By cruel () on

            this is not about load balancing, but failover and redundancy, when you have two devices configured almost equally. when primary fails, secondary takes all the job until primary's restore.

            agreed, this is routing daemons' level of interoperability to keep routing tables in sync.

            in case of bgpd it can be some way to cast routing table changes to another bgpd and vice versa: when primary box getting alive after failover, primary's bgpd may request secondary's for current routing table state (if configured so), sync and than advertise itself as a master.

      2. By Pete () on

        My guess is pf/bgpd intercommunication ! imagine if you could filter/QoS etc on AS path/origin or whatever from the bgp tags in pf ;-)

        p.s. MPLS would be super sweet !

      3. By Anonymous Coward () on

        zebra is free. it is working. "good" is subjective.

        this is so typical of obsd think-style. go ahead and code your bgpd, lol.

        1. By gwyllion () on

          The goal of OpenBSD is to provide "source code that anyone can use for any purpose , with no restrictions ". See OpenBSD project goals

          So described in the OpenBSD copyright policy , the GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.

          Conclusion: Zebra is not free enough to be included in the OpenBSD tree. And yes, it IS free according to the FSF definition.

        2. By henning () henning@ on mailto:henning@

          > zebra is free. it is working.

          sorry, but you obviously never tried to use it for more than two peers...

          1. By Anonymous Coward () on

            sorry, you're wrong.

            i use it for 8 peers in a local IXP. full routes on each (~130k routes)

            and it works fine.

            you're just reciting anti-zebra fud you heard elsewhere, you've obviously never used it yourself.

            1. By henning () henning@ on mailto:henning@

              > you're just reciting anti-zebra fud you heard
              > elsewhere, you've obviously never used it
              > yourself.

              you are so wrong, it couldn't be worse.

              zebra plain sucks. that it works for you is beyond me, you're probably very easy to satisfy.

              anyway, this is just pointless, you obviously just wanna flame.

              1. By Anonymous Coward () on

                yep, pointless discussing it with someone like you who knows nothing about bgp.

                1. By Anonymous Coward () on

                  Zebra has numerous known issues with its bgpd. Try actually reading the mailing lists.

    6. By Anonymous Coward () on

      Imagine if you could set a "metric" on a route, and routes with a lower metric would be used over routes with a higher metric.

  3. By Giacomo Cariello () on

    One important feature that Zebra is missing is BGP resiliency (please take a look at this article for details). Now that redundancy protocols are hitting the core of OpenBSD, it would be cool to offer a complete High-availability suite for IP.

    1. By Hroi Sigurdsson () hroi at on mailto:hroi at

      Achieving what is described in that article requires special hardware design. I can hardly imagine OpenBSD proper being used in any important core router role where sub-second convergence time is required.

  4. By Mike () on

    kewl!! that´s cool!! i´m been using zebra on a linux box for bgp routing... i´ll try the bgp deamon on a obsd box! :D


  5. By Deckland () on

    Is there any room for coding help ?! just interested...

    1. By henning () henning@ on mailto:henning@

      look at what's missing and send diffs ;-)
      nexthop handling will probably done within the next few hours and filter language is a longer discussion, but there's several stuff - read, understand, and send diffs I'd say ;-)

      one area not even remotely touched yet is status reporting. we'll need a bgpdctl or somesuch that connects through a named pipe to bgpd and gets you list of active peers ("show ip bgp summary" in cisco speak) and this stuff.

  6. By Anonymous Coward () on

    Would be nice to see this on slashdot to get more attention and maybe some recruits to help develope this further.

    Just a thought.

    1. By Anonymous Coward () on

      Slashdork is not helpful in any way shape or form.

Latest Articles


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]