Failover Clarification

[Benjamin Wiechman]

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of Simon Hobson
Sent: Tuesday, May 08, 2007 5:20 PM
To: dhcp-users at isc.org
Subject: RE: Failover Clarification

Benjamin Wiechman wrote:
>This is the problem. Put three access points on the tower, and throw a /24
>on it and run all three access points on that network. Realistically we can
>put about 150-200 subscribers on that tower and still provide QOS. So we
>have about 60% utilization (multiply this by 15-20 sites) - not going to
get
>more IPs. That is the management/ARIN problem. Say we use a /25 instead,
>this will improve overall IP utilization, but we still are in the same boat
>once we get to 120+ subs off that site.
>
>We can run slightly larger networks, say a /26 per access point, but
>multiply this by about 75 access points. This would lower out IP
utilization
>to less than 50%, and our upstream provider already drags their feet when
we
>come begging for more IPs. No way are they handing us almost 5000 IPs.

I see the problem - oh for IPv6 eh ?

I wait impatiently....

>Or the bigger problem is that now if a subscriber on AP1 sends a broadcast
>packet it is being retransmitted on AP1, and AP2, and AP3, possibly more
>than once. There is no way to filter broadcast in the APs - they are simply
>bridges (and not an 802.11 system). PPS limitation is about 2500... so
there
>isn't a lot of available overhead. Yes, if we could filter broadcast at the
>access point this wouldn't be such a big deal.

What's between the APs and the backhaul ? Could you insert a bridge 
or router (one port per AP) that can do filtering - or is this some 
'black box' of a system with APs on one side and a telco data line on 
the other ? I guess you've already thought about this.

We have Foundry FES2402 Layer 3 switches at each site. This obviously kills
any kind of broadcast on a per port basis. However if we run larger subnets
we still run into the utilization issues. We try to keep each AP under 50-60
subscribers, which would allow us to run a /26 if we wanted to, however then
as I said our utilization is so low we'd never get another IP address... 

We could try and run one subnet on the entire site, but then to control
broadcast storms you're looking at trying to determine what to do with every
nucast packet that comes in and you're doing a lot of work with ACLs and
other control measures to do what is more easily and cleanly done by simply
using a smaller VLAN per AP per port, and adding another subnet and virtual
interface as required. 

We do run some subnets across more than one AP, but we see a dramatic
increase in nucast packets coming through.

>So, to limit broadcast traffic we place each AP on its own VLAN and break
up
>the address space. This way if we do have a subscriber that is hammering
our
>network with broadcast traffic it is contained to one access point, not
>every access point at the site.
>
>Between a rock and hard place... IP management and ARIN vs QOS...
>
>Back to the original question... how well is a failover configuration going
>to handle this type of network?

 From my limited knowledge of failover, not at all. Firstly the 
balancing algorithms don't work well with very few available 
addresses. Secondly IIRC there are issues where the surviving server 
needs additional addresses when one server goes down - but I don't 
deal with failover personally so I don't know the details.

This is what I'm afraid of. If one server goes down, as far as I understand
what I am reading, the remaining server will only hand out its share of
addresses unless it is specifically placed into a partner-down state, at
which point it will start using all the addresses in the pool. With only a
couple of spare addresses this would have to done fairly quickly, or the max
lease time would have to be lowered to an almost unmanageable time period.

I also have not been able to determine whether the two peer servers will
communicate to determine how many addresses are actually free. For example,
if one server has 0 free leases and it receives a request for an IP, does it
simply report that there are no free leases, or does it communicate with the
other peer to determine if there truly are any free leases available?

Basically what I am seeing is that we would likely want to increase our pool
size to a point where we would have 5-10 available leases out of the pool.