One thing to beware of (as Colin likely knows) is broadcast/multicast saturation at WiFi Basic Rate. Simply put, the more hosts in a single layer-2 broadcast domain, the slower any WiFi-like system will get... at least quadratically. ARP packets (and other bcast/mcast traffic, although ARP is the usual culprit) begin taking up all the airtime, in a temporally disproportion manner compared to volumetric. I would go so far as suggesting that each WiFi access point should be its own independent broadcast domain, which implies its own subnet. Simple solution: route, don't NAT. And route at something reasonably fast, not the AP itself. -Adam
On Dec 7, 2013 6:12 PM, Mark Jenkins <m...@parit.ca> wrote: > > On 07/12/13 12:46 PM, Colin Stanners wrote: > > I've set the router to start giving out 172.30.6.100-240 IPs, and will > > send server owners request to change to new IPs to help us move out of > > the overused 192.168.1.x range. Both networks are routed so everything > > can talk to each other while we do the migration. > > > Shoot, I hope I'm not too late to complain but the new Skullspace LAN is > only going to be a /24 (172.30.6.0/24) like it is right now > (192.168.1.0/24)? Personally I'd like a bigger subnet as assigned by > DHCP that includes a broader static portion shared with that subnet. > > Reason being, I'd like the ability for people to put virtual machines on > the Skullspace LAN and then access them with personal laptops, > workstations through our gigabit switchs for optimal routerless access. > > Which isn't to say that all virtual machines need this, and many will be > fine for Skullspace with folks reaching them through routing, but I'm > feeling like 172.30.6.x 40-.49 isn't much of a range for virtual > machines to have shared with the main LAN. > > I have three uses of the VM server where fast switched access from the > LAN makes a difference compared to having to go through a local router: > * graphical RDP / VNC over ssh / X access to the vm server host OS for > VM panel management > > * graphic RDP access to the Ubuntu 12.04 install I have > (this was part of my MUMD [multi-user, multi-distro] concept, but I'm > going to scale it down to just latest Ubuntu) > > * iSCSI stuff to workstations (haven't played with this in awhile, but > I definitely want LAN ip space for it) > > So that's 3 out of 9 right there. > > > My Skullhost concept (still a work in progress) is an example of a > virtual machine service of mine that doesn't need a LAN IP, I'd be fine > with that reachable from the LAN through local routing. > > Though, I notice that there isn't even a chunk of 172.16.0.0/12 set > aside for virtual machines. On the wiki I have added 172.16.0.0/22 as a > reserved range for this. If this is a go what I'd end up doing is > encouraging most VM users to assign themselves addresses there instead > of taking up static space on whatever subnet our main LAN consists of > unless there's a performance case to be made. > > (allocation idea here being that we would assign /22 subnets from the > bottom of 172.16.0.0/12 and up and /24s from the top of 172.16.0.0/12 on > down ) > > Time to subscribe to netops... > > > Mark > _______________________________________________ > SkullSpace Discuss Mailing List > Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss > Archive: https://groups.google.com/group/skullspace-discuss-archive/ _______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
