OT - Quagga/CARP

[Michael DeMan]

Hi,

See inline...

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

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.

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

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

We do some scripting for automation of firewall rules for the routers  
to protect themselves, but at this point I have no need of the UNIX  
command line on these machines on a regular basis.  The idea of using  
ifconfig, rc.conf and Quagga.conf to manage multiple machines,  
especially with automated management tools, is just impossible.

Long term manageability is the goal.  If everything is just in zebra/ 
quagga, then I just have one file to manage - Quagga.conf - for all  
backup, change control and managing lots of boxes in the field means  
I want much of the management driven straight out of our customer  
management application.  Basically, fast/easy to turn up/down an  
office suite, colocation box, microwave circuit, for a customer right  
off our internal management system.



> Dima.
>
>> On Mar 25, 2006, at 1:21 AM, Dima Dorfman wrote:
>>
>>> Michael DeMan <michael at staff.openaccess.org> wrote:
>>>> Anyway, thanks very much for the information.  I'm going to have to
>>>> figure out some kind of workaround on my architecture.  In the  
>>>> worst
>>>> case, I can shut off OSPF on the edge routers and use static routes
>>>> upstream and OSPF from there, but that is going to be a real
>>>> nightmare for network maintenance over the long haul.
>>>
>>> You're talking about using CARP and OSPF on the edge routers, right?
>>>
>>> Can you explain a little more why CARP and zebra/ospfd don't play  
>>> well
>>> together? I understand the problem about having two copies of the  
>>> same
>>> route in the FIB, but I don't think it should prevent redundancy  
>>> from
>>> working. I am planning to deploy FreeBSD-based access routers in the
>>> near future, and I'd like to have an idea of what issues I'll be
>>> facing.
>>>
>>> The scenario I have in mind is two FreeBSD boxes connected to the  
>>> rest
>>> of the network on one side and clients (using carp) on the other.  
>>> CARP
>>> is supposed to protect the client against one of the routers  
>>> failing.
>>> I tried this on some test boxes today, and it looks like it should
>>> work. Both boxes are configured as OSPF neighbors and share a CARP
>>> vhid. When both links are up, each router has a route through the
>>> physical interface (it also sees the OSPF route, but the connected
>>> route is better). If one of the links fails (any condition that  
>>> causes
>>> the physical interface to be down), the routes are withdrawn, the
>>> other box takes over the VIP, and the first box installs the OSPF
>>> route. Everything is still reachable.
>>>
>>> Am I missing an obvious problem or a case where this doesn't work?
>>