Hi,
See inline...
On Mar 30, 2006, at 11:11 PM, Dima Dorfman wrote:
Michael DeMan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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?
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
