On Fri, 7 Jul 2006, Roberto Nibali wrote:
how do they do that?
I was assuming that LVS would do this, I would like to have the options of
round robin
least connections
failover (send it to the primary unless it's down, then send to the backup,
it's not load balancing but it makes troubleshooting much easier)
Have VRRP running on the internet-side of your network path with a VSR using
persistent binding and RR scheduler. On the outgoing path of the packet
filters you won't exactly need a load balancer, the routing takes care of it.
the traffic out from the firewalls through the load balancers and routers to the
Internet doesn't need to be touched, however if the servers initiate traffic out
to the Internet through the firewalls the inside boxes need to load balance
across the firewalls (and the outside boxes handle the reply packets
appropriately) the same way the outside boxes need to load balance and the
inside boxes handle reply packets appropriately for inbound traffic.
Here's my take on what you've got.
A
/ \
FW1 FW2
\ /
B
Machinew A and B want to talk. They can talk through either of two routes,
both of which contain firewalls. The packets of interest are allowed
through the firewalls. As far as A and B are concerned the firewalls
aren't there. The rules of IP routing are such that any packet between A
and B can pick either route. You want packets between A and B to choose a
route dependant on the route chosen by previously transmitted packets.
right
... at least for a session. Which might put you into the suboptimal position
of the different session timing expiration regarding TCP sessions between
what the LB thinks is a session and what the PF thinks is a session.
as long as the timeouts are long enough that we are willing to chop off
connections that are idle past that value it should work (both firewalls and
load balancers need to have timeouts, if they just get set to the same thing you
don't have much trouble in practice)
o firewalls are designed to operate in a spot where all traffic goes
through them. They can then do their accounting
etc. Firewalls are not designed (at least yet) to cooperate.
They need to be fast, they can't be talking to other
firewalls to make decisions on what to do with a packet.
o your design is being wagged by the tail of the firewall. The firewall is
supposed to help you. Your firewall
doesn't work in the current setup. You could get one
that does, presumably by turning off stateful matching.
o you could rewrite IP routing.
or I can go and buy a commercial load balancing appliance (radware, BigIP,
nortel, foundry, etc) that supports this feature. Just about all of them
that aren't based on LVS do support this.
And they also do not work correctly, as I've seen in numerous ways. Just
right now I'm debugging an active/hotstandby firewall cluster system
implemented using 2208 NAS from Nortel. Same issue with F5 from BigIP,
although their session synchronisation is somewhat improved ... until you go
up to 1Gbit/s of filtering. I've never used radware, and I reckon we don't
have to talk about Cisco :).
they can be problems, but they can work, I've used them (with radware) for
several years with different types of firewalls.
Are you talking about a setup as described for example in chapter 19 of this:
http://www116.nortelnetworks.com/docs/bvdoc/alteon/appl_switch/315394-J.00.pdf
looking this up now...
I can't follow the link. I'll have to dig through the site to try and find it.
I am trying to find an option that doesn't have the firewall being a single
point of failure. yes, if these were linux firewalls I could use heartbeat
(linux-ha) to provide failover, but that can't load balance, and it doesn't
work if I use commercial firewalls instead of linux
If you buy a commercial firewall, you will most probably have some sort of
built-in failover.
there are a couple huge advantages of not useing the built-in failover for
commercial firewalls
1. with external boxes you can have firewalls of different types that you
failover/load balance between (avoiding vendor lock-in and you have a much
easier time dealing with major upgrades of a single vendors firewalls)
2. with external boxes you avoid the situation where traffic arrives at one
firewall and needs to be sent back out the wire to the other firewall (not a
problem for low traffic levels, but as you traffic levels appraoch wire speed it
becomes a problem)
Oh well, I was hopeing that LVS would support this now (it didn't in 2001
when the first post happened). at least now it's in the list
If back then it didn't support it, I would go as far as to stating that it is
not possible now either. I would say that all attempts to load balance
firewalls (be it based on commercial or OSS) using LVS ends up being a
hackerish setup which is prone to weird failures or features. This is just my
opinion, but then again I've intensively worked on the LVS code and also
wrote a packet filter :).
If LVS decides that this isn't worth supporting, then so be it, but it does work
with the commercial offerings so please don't pretend that it's not possible.
(Radware has an entire product line, their 'fireproof' boxes that are sold for
doing nothing but this task)
David Lang
archives that LVS will not support this with a later date then the 'yes it
does, just search the archives'. hopefully this will save someone else time
hunting for it.
Fair enough.
Regards,
Roberto Nibali, ratz
|