Size of IP space supported by WiSM

[STUART KENDRICK]

We're currently servicing ~1000 clients between a pair of WiSM modules, hosted inside a single C6K,  living inside a single /21 (10.10.176.0/22).  We would like to service  more clients ... we're guessing another ~500 or so, perhaps more, as  time progresses.  So we plan to expand the IP space to a /21  (10.10.176.0/21).

Are there any best practices  / recommendations for how many clients  should live within a single IP range?  I suppose, for example, that we  could assign separate IP ranges to each WiSM, if we needed to shrink.   [We do 'mobility' in a limited sense, in that all the APs for a given  building are 'assigned' to a single WiSM, so that stations can roam  within a building without changing IP spaces.]

--sk

Stuart Kendrick

FHCRC

[Nicolas Darchis]

Broadcasts are not so much an issue on wireless because they are blocked by the WLC which takes care of proxying ARPs and dhcp. So it's safe to have large subnets but still is something you want to avoid in general. There is no precise best practice.

Rather than having a different subnet on each Wism (which is a totally good solution) you can also have several subnets on the same wism. Create different AP groups that have different interface for the same SSID. You can then group APS per floor and have a different /24 subnet on each floor.

Roaming will still be seemless and client will keep their subnet even if they move between floors.

Nicolas

===

Don't forget to rate answers that you find useful

[George Stefanick]

If its any help ... IBM did a deployment prior to me being hired at my current employer. They made a large subnet with 2,600+ clients (7921 and 7925) phones across our campus. Believe it or not, it working with little to no issues. This is not ideal, and we will either deploy AP groups or wait for 7 M1 code where we can use the new round robin function.

[STUART KENDRICK]

OK, so the WiSM performs magic with ARPs and DHCP, meaning that the broadcasts emitted by clients running these protocols don't get flooded to all WiFi clients.

Does this magic extend to any other broadcasts (multicasts)?

For example, we still support AppleTalk on our WiFi subnets, and AppleTalk employs multicasts to support Name Binding Protocol (NBP -- for looking up the names of printers and file servers).

And, I suppose, a troubled client could start emitting arbitrary broadcast frames -- does the WiSM in fact suppress *all* broadcast/multicast forwarding?  Or does this magic apply only to ARPs and DHCP?

[If the WiSM is good at suppressing broadcasts, then I'm less concerned about the size of the subnet.  If it doesn't, then I want to fall back to chunking the broadcast domain to a /23 or thereabouts, which is the size with which I'm comfortable.]

--sk