XCC VE6120 ports: admin, data, vswitch promiscious mode

[tfsnetman]

Hello,

I am installing a VE6120 and ended up with 3 interfaces (admin, data 1, data 2).
Admin is out of band - VLAN 10
Data 1, data 2 - VLAN 16.

While the documentation is stating that the vswitch should accept promiscious connections, this doesn't seem to make sense.

Please correct me if I am wrong:
- data interfaces are used by APs and controller to talk to each other
- user traffic is locally switched
- no ther VLANs required on data ports
- global default gateway applies to Admin topology, static routes might be required for subnets that should be reachable via data ports / topology.

Thank you,

Klaus

[Bill_Handler · Accepted solution]

Klaus,

Depending on your situation/design the configuration of the ports changes.  If, in your deployment, you are bridging all wireless client traffic at the AP you may not need to enable the 2nd data port. 

In most of our deployments, we do not use the Admin port for Out of Band management, and use the first data port for management, AP registration, etc.  We usually only use the 2nd data port if we have a need to bridge the traffic at the controller onto a separate VLAN; sometimes used for Guest traffic that is tunneled back to be put on a separate VLAN.

In the legacy Extreme/Enterasys-based controllers (V2110, C4110, C5210, etc.), we oftentimes did not use the Global Default Gateway, we bypassed that setting and just set a default route.  For the newer controllers (XCA/XCC) we use the Global Default Gateway - usually the Gateway for the subnet we will be managing the controller from - Data Port 1 in our case.  In the XCA/XCC this creates a default static route using the same gateway.

For nearly all of our deployments, routing between the different subnets/VLANs is done from a different location, so we do not need to add that information at the Controller level.  Again, depending on your network's configuration, you may or may not need to add those routes.  You could use the 'Diagnostics' feature under the 'Tools' menu.  From there you can ping and traceroute from your controller's specific interfaces.  If you're able to reach the different subnets from your data port(s) you shouldn't need to add the static routes.

I believe that the reason for the documentation stating the vSwitch needs to be in promiscuous mode is specifically for allowing tagged VLANs.  If your VMware host is on the same subnet, and no tagged VLANs are needed for any VM on that host, you should be able to leave promiscuous mode off.

I hope this helps, but if you have any additional questions, please feel free to ask.

Thanks,

Bill

[tfsnetman]

Hi Bill,

Thank you for explaining.

If traffic is bridged at the AP it can be mapped to different VLANs depending the radius attribute returned from the NAC.
What would be reasons to tunnel all traffic back to the controller other than having a more centralized configuration?

Thanks,

Klaus

[Bill_Handler]

Klaus,

Sorry about the delay, I've been out of pocket...

For some deployments bridging at the controller may be necessary for traffic/content filtering or shaping - there are other reasons, but those are what are the most prevalent in our experience with our customer base.  We've had some customers whose environments necessitated this.  We do try to shy away from it due to the potential load it can put on a Virtual Controller.

It all depends on the deployment and the needs/wants of the customer.

Thanks,

Bill