Wireless Access

Is there a CLI command that I can see which VLAN is in use for which AP-group/VAP we have a lot of vlans and AP-groups.

Well, there is the show wlan virtual-ap <vap name> command which will show the vlan assignment.  

Another alternative is to migrate to vlan names and assign those names to each VAP.  Then, you can issue the show vlan mapping command to show how they all map out in a name to VLAN ID output.  

Instead of assigning a VLAN ID to the VAP, you assign the VLAN name to the VAP and on each controller, that same name can map to the same or different VLAN ID numbers.  

For example, you may have 2 controllers.  In location A, the "employee" VLAN maps to VLAN 10.  In location b, the "employee" VLAN maps to VLAN 20.  

By moving to VLAN names, it may help to create an easier to understand config.

Use of VLAN names instead of VLAN ID#'s where do you setup the use of VLAN names? I remember that from the 3 day training seemed to be the best practice way to setup what your talking about.

Too bad I have to select a VAP I would like to see all VAPS and which VLAN ID# they are using We have a different VAP for each AP group because we have split subnets in to /24 each location we are using OSPF. 

kell490,

The fact that you are using OSPF is interesting.  Does that mean that the controller is the default gateway for all of your wireless devices?

Yes each controller is the default gateway is the AP's that are assisnged to that controller. We have our network split up and spread over 3 local controllers and one master. The system is replacing older controllers that were using VRRP the person that setup the new system used OSPF with LMS backup and vlans setup on the master in case the backup is down also. We plan on adding 2 more 7220's for redundecy on the ones with the highest loads we support about 900 ap's right now plan on going up to 1500 in the future. The person that setup the controllers left shortly after he got them setup and I was handed the enviroment I had no experince with wireless so it's been a steep learning curve. I'm happy to have gotten it otherwise I would never had the opertunity to learn. I'm looking at the HA configuration for redundancy after we get rid of our old AP65's and 70's everything 105 and up should be compatable. 

Since you are making changes, would you consider just bridging user traffic layer-2 to layer 3 switches, so that you will not have to run OSPF or do static routing?  It could be simpler.  In addition, every building or area does not require its own VLAN or AP group.   There are campuses where everyone is on the same layer 2 VLAN...  That would eliminate the "waste" from assigning say a /24 to each building.  Less Vlans...no OSPF.... idea?

In addition, if you are using Airwave, you could use it to manage your configuration and it is easier through Airwave to tell what the dependencies on each profile, role, ACL exist..

 I thought it's a good idea to break up vlans seems that was how the "old days" we had a bunch of VLANS but now we break everything up using layer 3 keeping mac tables smaller and less devices see arp requests? Would it not be faster if we had smaller VLANS and less end user devices in them?

So, it really depends on your infrastructure and your goal:  If you had 3 buildings, each with a VLAN, it would require 3 virtual APS and 3 AP-Groups  and 3 /24s (768 ips reserved) to serve those 3 buildings.  If 3 buildings shared one subnet, it would require a single ap-group for all the access points in those three buildings.  The configuration on your controller would be a single VLAN on a trunk and the configuration on the controller would be a single ap-group.  With broadcast suppression applied to that Virtual AP (broadcast filter all) only ARP requests NOT in the ARP table and DHCP would be propagated.  From an ARP table perspective on your layer 3 switch, it all depends on how many entries your layer 3 switch can handle in the ARP table.  If it can handle a sizeable amount, you do not have to run a routing protocol between your controller and layer 3 switch:  You would make the layer 3 switch the default gateway for your clients.  

That has three benefits:

1. You can provide redundancy for wireless clients by trunking a VLAN to two controllers; if one controller failed, the access points could flip over to the second one and the second controller would just bridge user traffic to the same layer 2 vlan, and no ip address reassignment would be necessary.

2.  In the Cisco world, HSRP provides redundancy for subnets (VRRP in the rest of the switching world) and your HSRP/VRRP address could be the default gateway for your clients, to provide switch-level redundancy 

3.  You would not have to run OSPF, since your layer 3 switch would just redistribute VLAN interfaces directly connected to your layer 3 switch.

So in your opionon ospf on the controller does not gain any speed or effeicecy to our clients with broadcast suppresion, and the only reason to use OSPF on the controller is if our switch was not capible of handling a large ARP table. Our switch is a cisco 6513 it should have large enough arp table. 

Historically, the addition of OSPF on the controller was to enable HA between two controllers in different datacenters, if they were serving up remote APs.  In the Campus LAN environment, it is not hard to co-locate a controller and its backup controller in the same datacenter, with access to the same user vlans; in that case, we would trunk the user vlans to both controllers, and when one fails the access points would fail over to the other, and the user would not have to re-ip.  With RAP, it is understood that the controllers may be in different datacenters, so the active controller would be the default gateway for those clients, and advertise reachability for that specific subnet via OSPF.  If the active controller fails, it no longer advertises reachability, the access points fail over to the controller in the other datacenter, and the new controller advertises reachability for the RAP client subnet.

In the LAN campus environment, it is fairly straightforward to just trunk the VLANs to a layer 3 switch, where the layer 3 switch is the default gateway, so that routing updates are not another thing we have to wait for to establish client connectivity.  A possible routing update delay is probably more acceptable in a RAP/Remote environment, than the campus one.

I hope what I wrote makes sense....

That makes a lot of sense our current design was to use a controller backup datacenter to backup 2 other local controllers using the LMS backup IP, so OSPF makes since in this configuration.  The backup datacenter controller is only supporting about 100 AP's all of our controllers are 7220's so it should be able to handle the other 2. We plan on either moving to HA adding 1 controller at each site we have 3 total and setup each as a HA backup for the other site. That way each controller is covered by the other datacenter. Can we use VRRP at each site with 2 controllers at each of the datacenters then HA between those datacenters?