From: "Måns Nilsson" <mansaxel@besserwisser.org>
04:05:41PM +0000 Quoting Dylan Bouterse (dylan@corp.power1.com):
> I'm not sure if this is obvious for this list or not, but with your
> WiFi nodes, a good practice for that kind of density is more nodes,
> lower power. Keep the client connection load per AP as low as
> possible to improve overall performance. Jacking up the power in a
> small area like that will just step on the adjacent APs and cause
> issues.
It was. 
Of course, the propery may (read: probably does) have its
own conference areas and residential floors wifi, and those may or may
not be V-WLAN capable.
An enterprisey AP flock that perhaps even can talk to eachother about
power levels is a must.
At all possible cost, avoid login or encryption for the wireless.
Yes, and no.
Captive portals suck, especially if they try to be clever and keep an eye on
the link-state to each client. Tablets and smartphones turn their radios
off to conserve battery, and that means having to login all the time.
My plan is to have 3 VWLANs:
worldcon-guests, which will have one-time captive portal; I want the
controller to remember the MAC address everywhere, all week
worldcon-dealers, no captive portal (for credit card and other embedded
machines), and
worldcon-staff, which may have some relaxed outbound security compared to
the other networks.
(For example, I have no problems blocking outbound port 25 and redirecting
recursive DNS -- though I do want a system that permits me to whitelist
MACs on request. But I would do those on the guest and dealer nets, and
not on the staff one.)
While things have become much better, doing 802.1x on conference
wireless probably is a bit daring. OTOH eduroam does it all over Europe.
If I did try to do that, it would probably only be on the staff network;
it's a much more contrained environment.
Get lots of IP addresses. A /16 probably still can be borrowed for
this kind of event. I know RIPE had rules and addresses for this kind of
use a couple years ago, at least.
Indeed? I did not see that coming. Hell, perhaps Interop could be talked
into loaning me a /16.
And get v6.
Yeah, I assumed that, though it will be interesting to see how much play
it actually gets; these are SF geeks, not networking geeks.
Do not NAT. When all those people want to do social networking to the
same
furry BBS while also frequenting three social app sites simultaneously
you are going to get Issues if you NAT. So don't. (Keep in mind that
the
5-tuple for each TCP connection more often will become a 3-tuple if
the
demographic of the user base is skewed towards a focus group and NAT
is
in use. )
This, right here, is the kind of gritty advice that brought me to ask
this question in the first place. You're right; NAT is Right Out;
forget what I said earlier.
Lots of IP adresses will also enable you to set sensible DHCP lease
times on the failover-connected (because they are, right?) DHCP
servers. Nothing is so detrimental to connectivity experience as lost
leases from either crashed DHCP servers or short lease times.
Be very thorough and careful in setting DHCP up. It'll pay off.
Oh yeah. I'm fond of leases as short as 30 minutes, though if I have
a /16, I won't care as much.
Have DNS resolvers locally. Unbound is good. As is BIND.
Yep, with lots of RAM on the boxes.
It might be a good idea to have reverse DNS delegation set up,
perhaps via the BIND $GENERATE directive; just something like
wireless-node-47-11.world.con will do.
Hmmm.
Make sure that the whois contacts for the address block are proper.
Well, I do have 3 years to plan.
Try setting some monitoring up; it is good to be able to keep an eye
on client count per AP etc. This is also much easier if the wireless
solution is enterprisey.
I was planning on having a NOC, yes, albeit small.
Very nice, Måns; thanks.
Cheers,
-- jra
