Contributed by jose on from the internet-routing dept.
CVSROOT: /cvs Module name: src Changes by: henning@cvs.openbsd.org 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. status: 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)
By Anonymous Coward () on
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!
By Christophe Prévotaux () c.prevotaux@hexanet.fr on mailto:c.prevotaux@hexanet.fr
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 :)
Comments
By Anonymous Coward () on
By Bryan () on
Comments
By Anonymous Coward () on
And - suprise, surpise - it seems they're still active. Lates release is 0.94 from 2003/11/27 !
Comments
By Ray () ray@cyth.net on http://ray.cyth.net/
Wrong RIP .
By MotleyDawg () dawg@notle.org on mailto:dawg@notle.org
http://www.quagga.net/
2003-11-17:
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.
By Anonymous Coward () on
By Anonymous Coward () on
By Gernot () on
By sthen () on
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 ...
By djm () on
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/bgpd/
But doesn't IBM have a major patent over OSPF? (IIRC, could be wrong)
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By mirabile () mirabile@bsdcow.net on https://mirbsd.bsdadvocacy.org:8890/
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].
By Henning () henning@ on mailto:henning@
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.
Comments
By cruel () on
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 :)
Comments
By djm () on
Comments
By cruel () on
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.
By Pete () on
p.s. MPLS would be super sweet !
By Anonymous Coward () on
this is so typical of obsd think-style. go ahead and code your bgpd, lol.
Comments
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.
By henning () henning@ on mailto:henning@
sorry, but you obviously never tried to use it for more than two peers...
Comments
By Anonymous Coward () on
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.
Comments
By henning () henning@ on mailto:henning@
> 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.
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By Giacomo Cariello () jwk@bug.it on mailto:jwk@bug.it
Comments
By Hroi Sigurdsson () hroi at asdf.dk on mailto:hroi at asdf.dk
By Mike () miguel@pedaton.com on http://www.pedaton.com
mike
By Deckland () rado@netless.org on www.netless.org
Comments
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.
By Anonymous Coward () on
Just a thought.
Comments
By Anonymous Coward () on