Wireless Access

Hi all  

I have a setup with two VMCs running on a cluster under Mobility Master (MM). The cluster is built without any issues, and both VMCs are working fine within the cluster.

• Both MD running on the same vSphere host.

• Only Mgmt VLAN is trunked to the host. Unfortunately, I'm unable to trunk any other VLANs to the host.

• DHCP server in the same host and same mgmt vlan (Rechable on Both MD)

• default GW for both VMCs is on the management VLAN

my scenario

I'm trying to create a tunnel SSID that assigns IP addresses from a VLAN different from the mgmt VLAN. This VLAN is configured on the DHCP serve

I've configured the VLAN on the controller with the appropriate IP helper pointing to the DHCP server. However, clients connecting to the tunnel SSID are not getting IP addresses.

when I configure the SSID in bridge mode, clients are able to obtain IP addresses successfully-likely because the traffic does not return to the controller for forwarding.

seem the tunnel SSID case, the controller isn't properly redirecting the DHCP request on behalf of the internal VLAN

• Does Aruba support a DHCP smart relay agent or a GIADDR mechanism via the ip helper add command?

• Any ideas on how to get tunnel-mode DHCP working in a setup where only the management VLAN is available to the host?

Any advice or guidance is appreciated!

In tunnel mode, the VMC (Mobility Controller) acts as the gateway for the client traffic. The wireless client sends a DHCP request, the AP encapsulates this via GRE to the controller, the controller tries to forward the DHCP request out of the VLAN you specified. But since that VLAN is not trunked to the host, the VMC has no L2/L3 presence on that VLAN, and therefore can't, send a DHCP discover out via that VLAN, it can't et the proper giaddr (gateway IP) in the DHCP relay packet, it can't receive the DHCP offer back.

Maybe, three possible solutions, which you might try are:
1. Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is dirty and Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is not recommended in production, but it should work.

2. Bridge mode works only because the traffic wouldn't go through the controller. So, your AP is doing the forwarding directly to the VLAN, which it can reach via its uplink. But this defeats the purpose of tunneling (central control, firewalling, NAC, etc.). 

3. Also, if you can't trunk VLANs, you can enable the internal DHCP server on the controller for the tunnel SSID. The controller will assign IPs directly.

Hi all  

I have a setup with two VMCs running on a cluster under Mobility Master (MM). The cluster is built without any issues, and both VMCs are working fine within the cluster.

• Both MD running on the same vSphere host.

• Only Mgmt VLAN is trunked to the host. Unfortunately, I'm unable to trunk any other VLANs to the host.

• DHCP server in the same host and same mgmt vlan (Rechable on Both MD)

• default GW for both VMCs is on the management VLAN

my scenario

I'm trying to create a tunnel SSID that assigns IP addresses from a VLAN different from the mgmt VLAN. This VLAN is configured on the DHCP serve

I've configured the VLAN on the controller with the appropriate IP helper pointing to the DHCP server. However, clients connecting to the tunnel SSID are not getting IP addresses.

when I configure the SSID in bridge mode, clients are able to obtain IP addresses successfully-likely because the traffic does not return to the controller for forwarding.

seem the tunnel SSID case, the controller isn't properly redirecting the DHCP request on behalf of the internal VLAN

• Does Aruba support a DHCP smart relay agent or a GIADDR mechanism via the ip helper add command?

• Any ideas on how to get tunnel-mode DHCP working in a setup where only the management VLAN is available to the host?

Any advice or guidance is appreciated!

Thanks for your reply, much appreciated. At this time, I'm unable to trunk VLANs, and due to the limitations and risks associated with using internal DHCP in a clustered controller setup, that option isn't viable. I've explored all possible ways to make tunnel mode work, but without VLAN trunking, it's not feasible. If I go with bridge mode-no captive portal, each SSID on a separate subnet, with traffic routed to the firewall for policy enforcement-are there any limitations or risks I should expect in a deployment of ~700 APs and 1500+ users?

In tunnel mode, the VMC (Mobility Controller) acts as the gateway for the client traffic. The wireless client sends a DHCP request, the AP encapsulates this via GRE to the controller, the controller tries to forward the DHCP request out of the VLAN you specified. But since that VLAN is not trunked to the host, the VMC has no L2/L3 presence on that VLAN, and therefore can't, send a DHCP discover out via that VLAN, it can't et the proper giaddr (gateway IP) in the DHCP relay packet, it can't receive the DHCP offer back.

Maybe, three possible solutions, which you might try are:
1. Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is dirty and Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is not recommended in production, but it should work.

2. Bridge mode works only because the traffic wouldn't go through the controller. So, your AP is doing the forwarding directly to the VLAN, which it can reach via its uplink. But this defeats the purpose of tunneling (central control, firewalling, NAC, etc.). 

3. Also, if you can't trunk VLANs, you can enable the internal DHCP server on the controller for the tunnel SSID. The controller will assign IPs directly.

Hi all  

I have a setup with two VMCs running on a cluster under Mobility Master (MM). The cluster is built without any issues, and both VMCs are working fine within the cluster.

• Both MD running on the same vSphere host.

• Only Mgmt VLAN is trunked to the host. Unfortunately, I'm unable to trunk any other VLANs to the host.

• DHCP server in the same host and same mgmt vlan (Rechable on Both MD)

• default GW for both VMCs is on the management VLAN

my scenario

I'm trying to create a tunnel SSID that assigns IP addresses from a VLAN different from the mgmt VLAN. This VLAN is configured on the DHCP serve

I've configured the VLAN on the controller with the appropriate IP helper pointing to the DHCP server. However, clients connecting to the tunnel SSID are not getting IP addresses.

when I configure the SSID in bridge mode, clients are able to obtain IP addresses successfully-likely because the traffic does not return to the controller for forwarding.

seem the tunnel SSID case, the controller isn't properly redirecting the DHCP request on behalf of the internal VLAN

• Does Aruba support a DHCP smart relay agent or a GIADDR mechanism via the ip helper add command?

• Any ideas on how to get tunnel-mode DHCP working in a setup where only the management VLAN is available to the host?

Any advice or guidance is appreciated!

Hi Joe_Go,

with a VMC setup, it is very important that you follow all the steps in the Virtual Appliance Installation Guide. In particular, all security settings in the vSwitch must be set to Accept. Furthermore, the ReversePathFwdCheckPromisc option must be configured in the ESX host. You can read all the details in this guide. Please check if all settings are configured as in the guide. If not, the ESX host will not be able to handle the WLAN client traffic correctly. The VM network assumes that a VM only sends MAC addresses that belong to it - as a server would do. However, the Aruba VMC behaves like a switch - if you tunnel the WLAN. In the vSwitch, clients MAC addresses that do not belong to any VM are visible at once. The vSwitch can only handle this traffic if you follow all the settings in the guide.

Aruba recommends that the WLAN controllers function like switches. This means that the WLAN traffic should be tunneled from the AP to the controller, the controller tags the traffic with the corresponding VLAN and sends it on to the wired network. All L3 services such as DHCP, DNS, routing should be made available on the upstream devices.
In your case, the solution would be to trunk the WLAN clients VLAN in the vSwitch and bridge them into the wired network. If you cannot do this, you will run from one problem into another.

Configuring DHCP Relay is no problem, you do this in the VLAN interface.

In this example, VLAN 102 is not tagged to any port, it only exists in the controller. The controller will route the traffic. For DHCP relaying to work, the controller must reach the DHCP server IP (here 6.7.8.9) - either switched or routed. A DHCP range for the IP network 1.2.3.0/24 must exist in the DHCP server, the default gateway must be the IP address from the VLAN 102, i.e. here 1.2.3.4 If everything is set up correctly, the clients will connect to the WLAN and obtain an IP address from the DHCP server via DHCP relay.

In order for the user traffic to flow, however, you still have to change the routing in your network. You must inform the upstream router of your controller that the IP network 1.2.3.0/24 is located behind the Mgmt IP of the controller by routing the network 1.2.3.0/24 to the Mgmt IP of the controller. But you have a cluster with two controllers, with user and AP load balancing. Where do you want to route the network to? To the first controller or to the second?

You can of course use different IP networks for the same SSID in both controllers to solve the routing problem. However, different client IP networks result in IP problems during roaming or controller failover. Your WLAN clients remain associated with the WLAN, but the client IP address would not match the controller IP address, the WLAN client traffic will not flow.

You can of course activate SNAT in the VLAN 102. This masks all clients behind the controller Mgmt-IP. This solves the routing and IP addressing problem. But you are not able to handle the WLAN user traffic on the upstream firewall, because you only see the controller Mgmt-IP.

So I can only recommend that you configure the VM network accordingly, tag the user traffic and bridge it to the wired network.

Thanks for your reply, much appreciated. At this time, I'm unable to trunk VLANs, and due to the limitations and risks associated with using internal DHCP in a clustered controller setup, that option isn't viable. I've explored all possible ways to make tunnel mode work, but without VLAN trunking, it's not feasible. If I go with bridge mode-no captive portal, each SSID on a separate subnet, with traffic routed to the firewall for policy enforcement-are there any limitations or risks I should expect in a deployment of ~700 APs and 1500+ users?

In tunnel mode, the VMC (Mobility Controller) acts as the gateway for the client traffic. The wireless client sends a DHCP request, the AP encapsulates this via GRE to the controller, the controller tries to forward the DHCP request out of the VLAN you specified. But since that VLAN is not trunked to the host, the VMC has no L2/L3 presence on that VLAN, and therefore can't, send a DHCP discover out via that VLAN, it can't et the proper giaddr (gateway IP) in the DHCP relay packet, it can't receive the DHCP offer back.

Maybe, three possible solutions, which you might try are:
1. Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is dirty and Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is not recommended in production, but it should work.

2. Bridge mode works only because the traffic wouldn't go through the controller. So, your AP is doing the forwarding directly to the VLAN, which it can reach via its uplink. But this defeats the purpose of tunneling (central control, firewalling, NAC, etc.). 

3. Also, if you can't trunk VLANs, you can enable the internal DHCP server on the controller for the tunnel SSID. The controller will assign IPs directly.

Hi all  

I have a setup with two VMCs running on a cluster under Mobility Master (MM). The cluster is built without any issues, and both VMCs are working fine within the cluster.

• Both MD running on the same vSphere host.

• Only Mgmt VLAN is trunked to the host. Unfortunately, I'm unable to trunk any other VLANs to the host.

• DHCP server in the same host and same mgmt vlan (Rechable on Both MD)

• default GW for both VMCs is on the management VLAN

my scenario

I'm trying to create a tunnel SSID that assigns IP addresses from a VLAN different from the mgmt VLAN. This VLAN is configured on the DHCP serve

I've configured the VLAN on the controller with the appropriate IP helper pointing to the DHCP server. However, clients connecting to the tunnel SSID are not getting IP addresses.

when I configure the SSID in bridge mode, clients are able to obtain IP addresses successfully-likely because the traffic does not return to the controller for forwarding.

seem the tunnel SSID case, the controller isn't properly redirecting the DHCP request on behalf of the internal VLAN

• Does Aruba support a DHCP smart relay agent or a GIADDR mechanism via the ip helper add command?

• Any ideas on how to get tunnel-mode DHCP working in a setup where only the management VLAN is available to the host?

Any advice or guidance is appreciated!

Thank you for the clarification and for taking the time to explain it. I truly appreciate your effort

Hi Joe_Go,

with a VMC setup, it is very important that you follow all the steps in the Virtual Appliance Installation Guide. In particular, all security settings in the vSwitch must be set to Accept. Furthermore, the ReversePathFwdCheckPromisc option must be configured in the ESX host. You can read all the details in this guide. Please check if all settings are configured as in the guide. If not, the ESX host will not be able to handle the WLAN client traffic correctly. The VM network assumes that a VM only sends MAC addresses that belong to it - as a server would do. However, the Aruba VMC behaves like a switch - if you tunnel the WLAN. In the vSwitch, clients MAC addresses that do not belong to any VM are visible at once. The vSwitch can only handle this traffic if you follow all the settings in the guide.

Aruba recommends that the WLAN controllers function like switches. This means that the WLAN traffic should be tunneled from the AP to the controller, the controller tags the traffic with the corresponding VLAN and sends it on to the wired network. All L3 services such as DHCP, DNS, routing should be made available on the upstream devices.
In your case, the solution would be to trunk the WLAN clients VLAN in the vSwitch and bridge them into the wired network. If you cannot do this, you will run from one problem into another.

Configuring DHCP Relay is no problem, you do this in the VLAN interface.

In this example, VLAN 102 is not tagged to any port, it only exists in the controller. The controller will route the traffic. For DHCP relaying to work, the controller must reach the DHCP server IP (here 6.7.8.9) - either switched or routed. A DHCP range for the IP network 1.2.3.0/24 must exist in the DHCP server, the default gateway must be the IP address from the VLAN 102, i.e. here 1.2.3.4 If everything is set up correctly, the clients will connect to the WLAN and obtain an IP address from the DHCP server via DHCP relay.

In order for the user traffic to flow, however, you still have to change the routing in your network. You must inform the upstream router of your controller that the IP network 1.2.3.0/24 is located behind the Mgmt IP of the controller by routing the network 1.2.3.0/24 to the Mgmt IP of the controller. But you have a cluster with two controllers, with user and AP load balancing. Where do you want to route the network to? To the first controller or to the second?

You can of course use different IP networks for the same SSID in both controllers to solve the routing problem. However, different client IP networks result in IP problems during roaming or controller failover. Your WLAN clients remain associated with the WLAN, but the client IP address would not match the controller IP address, the WLAN client traffic will not flow.

You can of course activate SNAT in the VLAN 102. This masks all clients behind the controller Mgmt-IP. This solves the routing and IP addressing problem. But you are not able to handle the WLAN user traffic on the upstream firewall, because you only see the controller Mgmt-IP.

So I can only recommend that you configure the VM network accordingly, tag the user traffic and bridge it to the wired network.

Thanks for your reply, much appreciated. At this time, I'm unable to trunk VLANs, and due to the limitations and risks associated with using internal DHCP in a clustered controller setup, that option isn't viable. I've explored all possible ways to make tunnel mode work, but without VLAN trunking, it's not feasible. If I go with bridge mode-no captive portal, each SSID on a separate subnet, with traffic routed to the firewall for policy enforcement-are there any limitations or risks I should expect in a deployment of ~700 APs and 1500+ users?

In tunnel mode, the VMC (Mobility Controller) acts as the gateway for the client traffic. The wireless client sends a DHCP request, the AP encapsulates this via GRE to the controller, the controller tries to forward the DHCP request out of the VLAN you specified. But since that VLAN is not trunked to the host, the VMC has no L2/L3 presence on that VLAN, and therefore can't, send a DHCP discover out via that VLAN, it can't et the proper giaddr (gateway IP) in the DHCP relay packet, it can't receive the DHCP offer back.

Maybe, three possible solutions, which you might try are:
1. Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is dirty and Move the DHCP scope for the client VLAN to the mgmt VLAN (since it's the only routed network the controller has access to). Then relay DHCP over mgmt. This is not recommended in production, but it should work.

2. Bridge mode works only because the traffic wouldn't go through the controller. So, your AP is doing the forwarding directly to the VLAN, which it can reach via its uplink. But this defeats the purpose of tunneling (central control, firewalling, NAC, etc.). 

3. Also, if you can't trunk VLANs, you can enable the internal DHCP server on the controller for the tunnel SSID. The controller will assign IPs directly.

Hi all  

I have a setup with two VMCs running on a cluster under Mobility Master (MM). The cluster is built without any issues, and both VMCs are working fine within the cluster.

• Both MD running on the same vSphere host.

• Only Mgmt VLAN is trunked to the host. Unfortunately, I'm unable to trunk any other VLANs to the host.

• DHCP server in the same host and same mgmt vlan (Rechable on Both MD)

• default GW for both VMCs is on the management VLAN

my scenario

I'm trying to create a tunnel SSID that assigns IP addresses from a VLAN different from the mgmt VLAN. This VLAN is configured on the DHCP serve

I've configured the VLAN on the controller with the appropriate IP helper pointing to the DHCP server. However, clients connecting to the tunnel SSID are not getting IP addresses.

when I configure the SSID in bridge mode, clients are able to obtain IP addresses successfully-likely because the traffic does not return to the controller for forwarding.

seem the tunnel SSID case, the controller isn't properly redirecting the DHCP request on behalf of the internal VLAN

• Does Aruba support a DHCP smart relay agent or a GIADDR mechanism via the ip helper add command?

• Any ideas on how to get tunnel-mode DHCP working in a setup where only the management VLAN is available to the host?

Any advice or guidance is appreciated!