@Au Wireless wrote:
We run a flat network. 6 APs on 3 towers and a single core router doing the work at our headend. This works with our small size. We have a management VLAN and all networking gear has a static private IP on that VLAN.
We then have 7 customer VLANs, each has its own /24 of private space. Currently, customers on the same AP are on the same VLAN and that VLAN is different from the AP next to it. Allows us some customer separation and we 1:1 NAT a public IP to each VLAN so not every customer is hitting the Internet from the same public IP.
Back when I did all the installs, managing this was OK. I would use the Data VLAN setting in the radio to set the VLAN for the customer router (radios are in bridge mode).
Now that we have contracted out installs, this is getting problematic. If an installer points a radio with Data VLAN 31 to a tower that is wanting VLAN 21 attached to it, it will obviously train up but won't serve an IP address to the customers router. I have to then login and manually change the Data VLAN (the installers tend to screw this part up).
There is a better way to handle a small flat network like this... My new current thought is to not use the Data VLAN setting on the SM at all - leave it off by default. Use my switch at the tower to tag VLAN 5 (management) and un-tag the VLAN that should be used for those customers to eash AP. Now I can get at the mgt IP and the customer router should get an IP from the un-tagged VLAN on the tower switch. If I need to tag a data VLAN (we do for lack of payment or static public IPs), I then log into the SM, turn on Data VLAN and enter the VLAN I want to pass through (which is also tagged at the tower switch port for the AP).
Is this a better solution? Is there a better way to handle a flat network (other than making it not flat)? We are small enough that our core router can handle this load and it really makes our management of the network easier to remain flat. It's just the VLANs that are causing us issues.
Would love to hear how other smaller WISPs handle their networks.
if you run without a data VLAN, that would be easier for the installers to grab and go. if you've got a common management vlan IP then you would also be set. there are some downsides to going without a data vlan, if your network key or auth method gets compromised, having to guess a VLAN on top of it can help deter curious kids that saw something they shouldn't have. or a contractor from telling his buddy something they shouldn't. if your switches are capiable of briding VLANs then you can have all of your CPEs configured with the same data vlan and they will still remain diffrent in your BH back to the core router you have.
we started with a similar setup as you described and ran into the same problems your worried about hitting. we ended up standardizing everything.
each tower has its own router, and behind that same router, everything is repeated exactly the same.
VLAN 2: mgt, vlan 3 data vlans over x number are for customers private carry.
we started to generic the AP labels as colors and added the number 5 for 5ghz, 3 for 3ghz device and 2 for 2 ghz.
DHCP is used everywhere, even for our management devices. doing all of this allowed us to cookie cutter the entire network as far as managements concern. customers CPEs get setup with thier name as the hostname and then .cpe is added to to, so john-doe.cpe will open up john does device for us. the tower he is attached to is noted in our CRM and its also done via flat config. red, green, yellow and blue are the colors we use, and always face the same colors the same directs. so if we want to get into the red radio in sometownusa then we open red.sometownusa.mgt and we are there.
the 2nd nice part about this, the default EPMP host name is EPMP_last6ofmac so when you send someone out in the field it can be accessed by the office team EPMP_last6ofmac.cpe for network security and installer safely purpose, our contracts are not allowed in the devices. they are required to call after getting a radio lock and we give them the green light to install there or not. sometimes cell service makes this step not possible, but for us it works well and we don't have to worry about the network information getting compromised.
routers serve another nice purpose, congestion control. eventually you'll hit a brick wall and will have a hard time pushing performance past that point. using routers to break down the amount of L2 devices you have existing in the same area stop that from happening. after you've got many many slow connections moving say 3 mbps, the TCP sessions that send more than 3 mbps to the AP, then have to get pushed down on can cause a couple pause frames to kick in some of your devices, and that happens more and more then the effect gets bigger and bigger. routers help to contain that push down and keep congestion to a minimum.
with every network comes a day you are almost forced to get away from being flat. some sooner than others, but if you think you will see that day in your network, the sooner you start the easier that pain will be.
you can still let your core router handle all of your NAT services etc. just use smaller routers out on the network to make your life eaiser.
and of course, there are plenty of different ways to do this. this is what has worked nicely for us, its very scalable. very simple to replicate and expand on. and in case we've lost documentation, easy to lookup and find the information we are missing via DHCP, and repeatable practices.