Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> Hello Michael,
>
> Wednesday, October 2, 2002, 12:29:12 PM, you wrote:
>
> MS> Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> >> Daniel,
> >> I've just subscribed, but on Sat, 10 Aug 2002 23:11:41 +0200 you
> >> replyed to Loic Cuguen regarding the non existence of a roadmap with:
> >> > There are certainly some larger goals that have not been achieved yet,
> >> > like redundancy/failover, load balancing, proxies for further
> >> > protocols, altq integration, etc.
> >> I've always thought about the failover/load balancing by making an
> >> extension to rdr, something like
> >>
> >> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
> >> {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
> >> [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
> >>
> >> For this to work you'd need to keep state on the tcp connection and
> >> do something sane on udp. So when a Syn packet comes to the rdr-load
> >> address/port, you evaluate the balance algorithm (in this case I
> >> proposed round robin and some fix weight) decide some of the given IPs
> >> and so you make a rdr to that IP. I haven't taken a look at the pf code
> >> (not that I'm good enough to understand it) but I though this wouldn't
> >> kill performance (may be double the lookup time for the rdr packets) and
> >> shouldn't be too invasive. I've given #idnum so you could eventually
> >> change the weight or add/takeout IP from the pool for a given rule.
> >> A second option would be to create a pseudo device that does the
> >> balancing, and have a whole syntax just for that, but then we would be
> >> duplicating information and processing time.
> >> I haven't evaluated how would this interact with the route-from
> >> extension (if it's going to be merged :-) but any of the two alternative
> >> shouldn't be incompatible.
> >> This is just a proposal, if has been discused before, apologies. If
> >> you find it stupid or uninformed just tell me where can I get more info
> >> to make better proposals.
>
> MS> ah, uh, my eyes.
> MS> this is an ugly hack that violates the whole concept of the networking.
> MS> we've discussed this w/ daniel a few times already.
> MS> there are a few different approaches here.
> MS> one might be to use a vrrp and a state sync between two pf boxens.
> MS> the other, in case there are two uplinks from one pf box
> MS> is to teach the networking stack about multiple routes to the same
> MS> destination and make it do the ballancing or whatever.
> MS> both this cases are doable and allow a whole bunch of other usefull
> MS> things to be implemented beyond one "useful" pf hack.
> MS> i find route-from a very bad idea myself.
>
> I didn't understand what specifically you didn't like. Could you
> give me some specific part that you think is so brain dead. I'm not
> saying that my idea is right. But at least point out what's the problem.
> Are you aware that I'm proposing a solution to presenting a farm of
> servers as a single IP/port to the outside world? Because from your
> responce it seems more like if I was talking about the multiple ISP load
> balancing (which I'm not).
argh, i was reading the route-from thread and by the end
of your post got hooked up onto it again since you mentioned it as well (;
it means for the route-from, of course.
but, incoming load-balancing is a completely separate
task, it needs no knowledge of the filtering rules and
requires a lot of userland action as well.
therefor it has to be implemented outside of the pf or
network stack in general for that matter.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
