OT - Quagga/CARP

[Bart Van Kerckhove]

Michael DeMan <michael at 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 at 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.
>>
>
> 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 ... ;->
>
>> 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.

>
>>
>>> 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.
>>
>
> I've noticed some oddities with zebra too, but never anything that is
> a show-stopper.  There was some kind of bug with notifications of
> interface 'up/down' not getting propogated correctly between zebra/
> kernel, but that seems to be fixed.
There's lots of fixes being implemented on a daily basis, that much I know 
(from regular contact with the guys).
>
<snapped>

Met vriendelijke groet / With kind regards,

Bart Van Kerckhove
bart at it-ss.be