Wireless Access

We have a virtual AP profile setup in bridge mode with settings:-

VLAN:13-14, Forward mode:bridge

The controllers are on vlan 12

Do I need to define all the VLANs in each of the controllers- configuration/VLANs/VLAN ID to get it to work properly?

Vlan 12 has been defined in the controllers for the GE1/0 port, and APs are connected on the vlan 12.  Do I need to associate vlan 13, vlan 14 to the controllers? It is working without vlan14 defined but is that right?

The APs are connected to network switches and those connected ports are with vlan 12 untagged and vlan 13-14 tagged. 

Thanks in advance for any help.

To the best of my knowledge, you don't NEED the VLANs defined in the controller's own configuration no.

However, you might like to put them in for clarity when using the GUI (so they appear in dropdown lists etc)? If you do, I usually recommend then putting a vlan allowed list on your controller physical port/s so that the controller isn't subject to extra unecassary background traffic coming up at it from the network (improves security and performance a bit).

Thanks.

---

@RAuser wrote:

We have a virtual AP profile setup in bridge mode with settings:-

VLAN:13-14, Forward mode:bridge

The controllers are on vlan 12

 

Do I need to define all the VLANs in each of the controllers- configuration/VLANs/VLAN ID to get it to work properly?

Vlan 12 has been defined in the controllers for the GE1/0 port, and APs are connected on the vlan 12.  Do I need to associate vlan 13, vlan 14 to the controllers? It is working without vlan14 defined but is that right?

 

The APs are connected to network switches and those connected ports are with vlan 12 untagged and vlan 13-14 tagged. 

 

 

Thanks in advance for any help.

---

RAuser,

Is there a reason why you are bridging user traffic?  It is much more troublesome to have to configure trunk ports on access points than to tunnel the user traffic back to the controller and to just have the controller put the user traffic on the correct vlan.

If you need to bridge user traffic, Here is a shortcut:

When using bridge mode, just set Vlan in the Virtual AP to 1.  Why?  By default if you are using bridging, the access points  will determine whether it puts an 802.1q tag on client traffic by comparing the VLAN in the Virtual AP to the VLAN in AP-Group> AP> System Profile> Native VLAN.  If the Virtual AP VLAN matches that value, it will bridge the traffic out of the access point, but not tag it.  If it does not match that value, it bridge the traffic, and tag it with the Virtual AP vlan.  Since the Value in the Ap-Group> AP> System Profile> Native VLAN by default is 1, you will always get client traffic bridged without tagging if you make the Virtual AP 1.  It will not matter what VLAN your access point is physically on: it will simply bridge the client traffic without issue.

When would you want to make the Virtual AP VLAN something other than 1?  If your access points are physically on trunk ports and you always want to put the client traffic on that VLAN that is tagged.

Thanks guys for your reply.

We were advised to use bridge mode for domain computer for its efficiency by the external vendor and I believe so.

I want to ask...how is having to configure each port as a trunk efficiency?  That does not make sense.  Tunneling would make it so that you do not care what port or VLAN an access point is on...

I agree with CJ.

I can only assume you were advised it's more efficient in terms of throughput/traffic? I.e. as all traffic isn't going through the controller it isn't a potential bottleneck. However, this conflicts slightly in terms of where you're at today, general approach and what we usually see in customer environments.

For instance, if that was the design stance, I'm unsure why you don't have Instant APs instead of a controller based solution (which would have reduced cost)? But as CJ states, this is a pain as you have to do what you're doing now in terms of VLANs to AP ports.

One of the key benefits of your controller based architecture is that you shouldn't HAVE to do this (ergo admin efficiency goes up). And I'd be suprised if you actually ever hit a tipping point of the controller throughput. Very very few customers do. I've seen thousands of clients coming through single controllers without issue (broadly speaking). How many APs and users do you have, and how are the controllers connected to the LAN?

Bridge AP setups are handy with small remote sites (with private WANs) in certain deployments. Generally, we don't put that setup into a single medium/large site (when a controller is used). You need a good compelling constraint type reason to do that.

I assume this is one site/campus?

Thanks guys, yes it is not efficient to add the trunk port, may be  a bit good for traffic.