OT - Quagga/CARP

[Michael DeMan]

Hi,

The issue I have is that FreeBSD will not allow quagga to configure  
an additional interface on the local system if already exists in the  
routing table.

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.


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.



Michael F. DeMan
Director of Technology
OpenAccess Network Services
Bellingham, WA 98225
michael at staff.openaccess.org
360-647-0785

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?