I’ve a particular deployment in which I don’t know if the SM will be connected to the AP “A” or “B”, I’m using a different management vlan for each AP and its suscribers, and a different data vlan.
I’m trying to make installers life easier.
So, Can I set two management vlans to a SM? So that if it gets connected either AP “A” or “B” can get an IP from the DHCP server on that particular VLAN (same for the data vlan)?
Why do you have so many management vlans?
The AP will pass all vlans across to the vlan aware switch, this is where you add the additional vlan to allow SMs with the wrong management vlan to be managed.
Simpler to use a single management vlan or if you are having too many devices, place one vlan per tower/group of towers and route to a main management vlan. This will make your installers life easier.
If you must have so many management vlans then user radius and a common installer vlan, the SM will be on the common vlan until you push a config profile through radius, which means your installer has to call in with the ssid of the tower they connect to, its a bit more manual but then again the tower profile can be linked to the client profile and everything is configured automatically with two clicks. Also you get to evaluate the connection before committing it.
Thanks for the feedback, @Douglas_Generous.
At this point my plan is to have one single management vlan per tower (configured in the SM), and one vlan (untagged on the switch port) per each access point (I have two access point in a tower).
That way, all the SM will be pre-configured with the same management VLAN but I will not set a Data Vlan, I mean, Data Vlan is something I will handle at the switch port level, in which I will set an un-tagged data management per access point.
Please let me know your comments.
WARNING LONG WINDED:
What you plan will work but it will be very hard to administrator and prevent issues with.
By handling the sm data vlan at the tower switch you will have troubles providing sm to sm isolation and site to site bridging. It will work but you are setup backward from the normal way of doing things. You will also need to ensure that you always setup the allowed vlan for the right port. Screwing with a switch config remotely is ok, but deleting one vlan for that one sm could force a road trip to plug directly in via a console cable. This usually happens at a very bad time too. Another down side is you will have to route each vlan across your gateway, this means a much beefier router than normally required. Not to mention that you will be sort of stuck with a multi-level L2 network with a very expensive (both financially and time wise) change to be able to go full L3 later. Also consider 200 SMs per tower and 20 towers, this means you per switch vlan database will have to have between 210 and 4030 vlans ( each switch that a vlan must pass through needs to know about it or it gets ignored) with only 4096 available (protocol header limitation) which means getting q-in-q involved which can be another headache in its own right. This all leads to hard to manage and harder to fix networks that can not grow or expand.
Your management network should be on its own vlan, depending on the number of designed customers, having a management vlan per town and routing that vlan to the NOC management vlan is a good practice but all managed devices within that town must be on the same management vlan. Your AP management vlan should be the same as the SM management vlan unless you are letting competitors connect to your APs for a carrier service. Your SM data vlan should never be the management vlan and neither should be vlan 1 (thats a special one for spanning tree and other non ip protocols)
Your data vlans can be simple service based (we still have pppoe clients and we have two vlans for them, each providing a different gateway) or if you have 200+ SMs on a tower a data vlan per tower with dedicated vlans for a multi-site client bridging without requiring a vpn hairpin(which is nasty and hard to diagnose problems with). We have special vlans for our clients that pay for a SLA, which means their uptime, guaranteed data rate and in the case of a couple also latency across our network is part of the higher than normal (almost stupidly expensive) rate they pay so we provide vlan priority as well. (For this you will need a lawyer to ensure that you dont screw yourself nor leave yourself open to being screwed, well worth the few $$$ to ensure you are only responsible for what you have control of).
All of this all ties into how you plan to actually manage this network? Please dont say an excel spreadsheet and manual configuration! Start thinking about automation after about 30 SMs or two towers. Its nice to just need the MAC address and have the SM pre configured only with your radius and eap configs, the rest comes through radius on registration. The SM will configure itself and if its ever stolen then you can force it to a walled garden to prevent service theft. Also prevents ebay specials from connecting as all unauthorized SMs are placed in the walled garden if they can get connected to the AP (WPA security is good, but its a time thing. EAP-TTLS is a sure thing, not on the list, not connecting.) And all of this will need the management vlan to be the same as the AP that acts as the radius NAS.
Hi @Douglas_Generous, thanks again for your time, I’m actually planning a “configuration migration” soon, and I would like to define an action plan based on best practices.
By the way, I’ve a Switch-centric Network Design, with 3 routers: aggregator, core and border, and, a fourth router for the tower.
But still I’m defining the last details for the router tower, I’m a big fan of automation. I’ve sent you a private message to see if there is any chance to schedule a 1:1 call.
Thanks!