Date: Sat, 8 Apr 2006 09:53:15 +0200 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: freebsd-net@freebsd.org Subject: Re: OT - Quagga/CARP Message-ID: <20060408075338.GB1984@diehard.n-r-g.com> In-Reply-To: <024601c65a8d$5199f290$020b000a@bartwrkstxp> References: <21DCE1FA-4A7E-443F-8EFA-9E3CC7CE1C30@staff.openaccess.org> <024601c65a8d$5199f290$020b000a@bartwrkstxp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 07, 2006 at 11:50:37PM +0200, Bart Van Kerckhove wrote: > Michael DeMan <michael@staff.openaccess.org> wrote: > > Hi, > Hi gents and ladies, > > > > See inline... > ditto > > > > On Mar 30, 2006, at 11:11 PM, Dima Dorfman wrote: > > > >> Michael DeMan <michael@staff.openaccess.org> wrote: > >>> So, if you already have a route to 10.100.100.0/24 via OSPF to > >>> another machine, then try to... > >>> > >>> ip address 10.100.100.55/24 > >>> > >>> You get an error. > >> > >> Is that the only problem? Someone was talking about funding > >> development to fix something--surely there must be something more > >> severe than the inability to use the "ip address" interface command? > >> I thought the problem was about encoutering broken ingress paths if > >> one of the routers loses connectivity to the destination network. > Hmm no, it is not the inability to use "ip address" inside any quagga soft, > afaik the freebsd userland tools can't get the route-setting done eiter. Not > when an alternate route for the same prefix is in the kernel route table. This is not true. For some reasons there is "route change". The problem is that quagga just does a stupid RTM_DELETE/RTM_ADD combo to change a route (btw. this is not an atomic operation and could be raced). Now if you add a new interface the kernel does mostly the same. It tries to add a route to that interface via RTM_ADD and gives up if that fails. It probably should do a RTM_CHANGE (if the RTM_ADD failed) to force a update. > >> > > > > My understanding is that my issue is just one symptom of a general > > limitation in the kernel routing tables or something, and that fixing > > this problem would also allow multi-path routing for FreeBSD, which > > is probably a bigger 'win' for the community overall. > This is exactly the thing we need to get around. > Multi-path (and notably equal-cost multipath) would be a major gain. Yes it > is possible currently, but it requires ugly hacks (ipfw comes to mind). > ECMP does not belong in a firewall imHo - but that's just me ;o) > This is a place where freebsd really is lagging behind the other BSD's (and > to not state the obvious, that tux o/s). > Is this because there is no general need for these features? Lack of > development time? (hence the sponsoring proposal...) > FreeBSD has a nice rep going for it with regards to its ipstack ... ;-> Multipath routing is not that simple to implement unless you like to break a lot of software. > > > >> Does the combination of CARP and quagga OSPF work once it's > >> configured using system tools? > > > > Yes, it will work then. However, I still have to kill and restart > > the zebra and ospf processes entirely for them to pick things up > > correctly. > My understanding is that restarting en ospfd daemon is bad. restarting zebra > is even worse - and must not be done. > You can not restart zebra without restarting all other daemons that depend on it. Just as a side note neither OpenBGPD nor OpenOSPFD suffer from this problem. In both daemons you are able to resync the kernel routing table. This is mostly a zebra/quagga design problem. > > > >> > >>> It is possible to force the interface configuration via 'ifconfig' > >>> on the UNIX command line, but for this equipment I want all > >>> interface configuration and routing driven out of Quagga. > >> > >> It would be cool if that was possible, but it's not really practical. > >> My systems tend to have a lot of very custom configuration that > >> quagga will never be able to express. If I had a cookie-cutter > >> configuration, I'd probably be using a C or J box. > >> While I've found bgpd and ospfd to be very stable, the zebra part > >> that interacts with the kernel has had various problems over > >> time--routes not being installed correctly, or going away, or having > >> incorrect flags. I wouldn't trust it to configure the entire network > >> subsystem. > I don't use zebra to configure anything on our production machines. It > merely reads out routes that are already set, and adds ospf/bgp ones. Especially I would not trust quagga. New features added to FreeBSD will take a long time till they are supported by the quagga CLI. -- :wq Claudio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060408075338.GB1984>