----- Original Message -----
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274