Routing and Redundancy Delima

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



My setup:

LAN A
 |
 |-- Wireless-r1 --|
 |-- Wireless-r2 --|
 ..................|
 .................LAN B

 
LAN A is my primary (external) LAN. LAN B is my wireless LAN. LAN A does
iBGP and OSPF routing. Each wireless router does the following:

2 Bridged Ethernet + STP connections to LAN A
2 Bridged Ethernet + STP connections to LAN B
2 VLANs on LAN A
5 VLANs on LAN B
UCARP on each wireless VLAN (5). 
Quagga - zebra, bgpd, ospfd (on LAN A)

UCARP provides a virtual IP address for the gateway for each VLAN on the
wireless side. The goal is to provide complete, hot-failover redundancy
to wireless-r2 in the event wireless-r1 goes down (maintenance, failure,
etc). Ideally, the system should not loose a single packet in the event
of a failure. UCARP can accomplish this (already tested). If traffic is
being routed from the Internet to the wireless side by going through
wireless-r2, there is no issue with bringing down the interfaces on the
wireless side of wireless-r1 -- traffic reroutes accordingly with no
packet loss. If the traffic is being routed through wireless-r1 by
default, we loose (at most) 2 packets, but sometimes none, when we bring
down the ethernet connectivity on the wireless side of wireless-r1. 

My real issue comes in with the fact that sometimes, OSPF chooses
wireless-r2 as the default route from the Internet to the customer and
UCARP uses wireless-r1 for the reverse direction. The iptables rules and
bandwidth shaping rules ruly on connection tracking and marking to limit
bandwidth and do statistics and things. Since half of each flow is going
through the other router, things do not get handled entirely correctly.
Also, in certain circumstances, it is possible to get the wireless
bridged interfaces to stop passing traffic while not triggering a route
down message through OSPF, which basically causes the traffic to come to
a dead stop as OSPF thinks the route still exists, but UCARP does not.
UCARP fails over in this instance, but not the routing. 

So, my real question in all of this is how do I get UCARP and Quagga to
talk to each other and update each other on their state. Essentially, I
would like to get UCARP to turn off actual routing (but not route
updates) through the machine if UCARP is in slave mode. Also, when UCARP
goes to master mode, it should turn the routing back on. I think I can
accomplish this much by modifying my vip-up and vip-down shell scripts
to change the metric on the route so that the slave metric is higher
than the master metric. Unfortunately, going the other way is much more
difficult. How in the world do I get Quagga to put UCARP in slave mode
if the OSPF routing goes down, and then put UCARP in master mode when
OSPF comes back up? I've seen times when Quagga looses its OSPF
neighbors and needs ospfd to be restarted. When something like this
happens, UCARP should go into slave mode and the backup router should
kick in. I'm not sure how to pull this off short of a cronjob, which
seems like a hack, and probably won't react fast enough to prevent an
outage. 

Anyone have any suggestions on solving these issues? 

PS. I'm also going to try the Quagga and UCARP lists, but I thought I
would pose this question here, too, since it is for advanced routing and
traffic control, which is precisely what I'm trying to do.


Thanks in advance.

Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux