Vlans for VSC's not taking in MSM765zl

[elfordty]

Hi there,

I am trying to reconfigure my wireless network so each VSC is run on it's own VLAN.  I work at a school and we have lots of students that use the wireless network and I would like to segregate the traffic.

What I have done so far is setup these VLANs

Vlan 16 - Devices

Vlan 20 - Staff Wireless

Vlan 2011 - Student Wireless 1

Vlan 2012 - Student Wireless 2

Vlan 2013 - Student Wireless 3

The idea is that each device, for example, the AP's get an address in the Vlan 16 subnet and the client machines get an address in their respective Vlan subnet.

My DHCP server has scopes for each Vlan and when I test this on the wired network I am able to get the correct Vlan subnet for each one.  For example, if I untag my laptop port for Vlan 16, I get an address in the 16 subnet.  Like wise with the others.

On my controller I have setup a network profile and VLAN mappings on the LAN port for VLAN 16 and the AP's now get in address in the Vlan 16 subnet. I can confirm with checking the dhcp server and seeing the IP address in the Controlled AP's section of the controller software.

I did this by untagged the port the AP is plugged into as well as tagging the LAN port on the controller.

The next step is where I am having issues.  When the clients connect to a VSC I would like them to receive a different address from one of the other Vlans.

What I have done is created a new VSC, setup WPA PSK on it, turned off access control. 

Then I binded the VSC to the access point including egress Vlan for that VSC.  So for the Staff Wifi I have Vlan egressed on Vlan 20.

I then tagged the AP with Vlan 20 as well as the LAN port on the controller.

What I am getting is that the client machine that connects to that VSC is getting an IP address on the vlan 16 range instead of the vlan 20 range.

Is there anyway to fix this issue?  Or does anone have any ideas?

Thanks

Tyson

[Glen Willms]

Where are you specifying the VLAN? My guess is that you're doing it in the VSC config.

I suspect that you want the traffic to egress out on the WAP itself and not on the controller. If you want the traffic to egress from the WAP you'll want to specify the VLAN on the group VSC binding's and not the VSC.

[elfordty]

Yes, that it how I currently have it setup.

When I add the VSC to the controlled AP Group (not default), the VSC bindings page says that Staff Wifi is on Egress Network Staff Wifi (20).

There is no mention of the Vlan in the actual VSC setup page it self because I have turned off access control.

[elfordty]

I think I may have it figured out.

For some reason my DHCP setup acts a bit strange.

Let's say that a laptop connects to a wired network with and untagged port of Vlan 20.  Then if I change the port to be untagged Vlan 16,  it doesn't get a new DHCP address in the 16 range.  I am still yet to figure this out...

So when I connected my first client to the network I hadn't setup the Staff Wifi portion yet and it connected to the devices Vlan (Vlan 16).  Then when I setup the Staff Wifi Vlan it is hanging onto it's original IP from the devices vlan (Vlan 16).

Now I have connected new devices and they are working on the vlan 20 addresses.

Strange but coming together.  I don't know if there is an issues with my DHCP server or if this is just the way this are, but I am currently building a new DHCP server as part of the whole process so we will see if this fixes the issues.

Thanks for you help

Tyson

[Glen Willms]

Are you using DHCP relay or does your DHCP Server have an IP address in each VLAN? 

If you're using DHCP relay you need to ensure that the switch has an IP address in each VLAN it is relaying traffic for. 

[_Lemmy_]

we are seeing the same behavior on our setup.

before I explain, let me state that the MSM765 is by far the worst piece of hardware/software I've ever used. what a bugged up management interface. We've had nothing but problems with this. I will never roll out another wireless network with HP gear again.

Here is what we are seeing :  user connects to internal wlan on vlan 10. disconnects, reconnects to our guest wlan on vlan11, but is still getting an IP address on vlan 10. this is even with a release/renew on the device.

HP supports keeps blaming the DHCP server. Well done.

if you are considering buying a MSM, dont. Go Cisco.

[Peter_Debruyne]

Hi,

There are 2 ways to bring corporate users (not access-controlled) into vlans:

1/ via controller (need premium/mobility controller license) : Mobility Traffic Manager. This would be similar to what most vendors do, but is (in my opinion) a bit complicated to setup.

2/ via the APs (supported by all controllers) : my preferred method, simple and proven.

1/ traffic from the wireless client is sent to controller via a tunnel between AP and controller. Once traffic reaches the controller, admin must configure the controller, so it knows via which interface (LAN or INTERNET) the traffic must be tagged to the external wired network. AP will include the expected vlan in the tunneled traffic, so the controller will just respect what the AP tells it to do. Radius based vlans can be used as well, these steps only cover the manual config.

1.1 Add network profile

Controller - Network - Network Profiles : add profile "vlan 20" - vlan 20

1.2 Bind the network profile to a physical interface on the controller, so controller knows via which interface to transmit this vlan

Controller - Network - VLANs - Bind network profile "vlan 20" as tagged on LAN/INTERNET port

1.3 Configure switch with vlan tag on LAN/INTERNET port (sample for procurve switch)

vlan 20

 tag x

1.4 Define VSC

Controller - VSCs - new VSC

  Use controller for Auth: yes

  Use controller for Access Control : no

  Mobility Traffic Manager : yes

1.5 Bind VSC to AP Group. The egress binding here will be used by the APs for the tunneld traffic to be marked with this vlan. So when the controller gets the traffic marked with this vlan id, it will use the VLAN Mapping port (step 1.2) to forward the traffic tagged on that port.

Controller - Controlled APs - APGroupx - VSC Bindings

 Add Binding - Egress : Network profile "vlan 20"

With this setup, the controller behaves like a L2 bridge between the wireless client and the wired network. All traffic will pass the controller, so CPU load on controller should be considered. The controller is NOT involved with L3/DHCP with this setup, so the upstream routing switch for vlan 20 must be the dhcp relay.

Controller is SPOF, when using teaming, failover can be done, but takes the discovery time of the AP (about 90seconds).

Advantage is that switch ports connecting the APs do not need to know the vlans.

2/ VSC is bound to the APs, and the APs will directly send the wireless traffic tagged on the ethernet port of the AP. The tunnel between AP and controller is only used for management/auth, not for data forwarding.

1.1 Add network profile

Controller - Network - Network Profiles : add profile "vlan 20" - vlan 20

1.2 Do not bind the network profile to a physical interface on the controller : traffic does not pass the controller.

1.3 Configure switch with vlan tag for EVERY AP switch port (sample for procurve switch)

vlan 20

 tag x

Ensure the Access switches have their uplinks tagged as well to the core switch, which is doing L3 routing and dhcp relay for vlan 20.

1.4 Define VSC

Controller - VSCs - new VSC

  Use controller for Auth: yes

  Use controller for Access Control : no

  Mobility Traffic Manager : no

1.5 Bind VSC to AP Group. The egress binding here will be used by the APs to send the traffic on the local AP ethernet port with this vlan tag.

Controller - Controlled APs - APGroupx - VSC Bindings

 Add Binding - Egress : Network profile "vlan 20"

1.6 verify

on the switch port of the AP, verify mac-address of the wireless clients can be learned in the vlan 20

show mac-address x (x = AP interface port)

@Lemmy : I agree that the product can be challenging (specially for the access-controlled/mtm setups), but scenario 2 above is the most common used scenario, which just works.

Using Chrome/Firefox for management typically works better than IE for me.

If you post a bit more about your setup (VSC - access-control/MTM etc), we may be able to find a solution.

I hope this helps,

Best regards,Peter

[elfordty]

Sorry for the late reply but for me the solution to this problem was with my DHCP Server.

I did a complete re-build of my DHCP server and all my problems went away.  Fortunately for me rebuilding DHCP was in the cards anyways.

Just to give some details, I had a Windows Server 2003 doing DHCP originally and it was running for years.  I moved DHCP for all scopes to a new Windows Server 2012.  I have all VLAN's running from that server with the help of the ip helper-address command on my main routing switch.

My AP's are all connected on Vlan 16 and get an IP in that range.

I have clients that connect to which ever VSC and get an IP for the proper VLAN

-Staff get VLAN 20

-Students get either VLAN 2011, 2012, or 2013 depending on which year they are apart of.

The AP's handle the VLAN's themselves.  The controller does not.  When adding the VSC bindings to an AP group, all that was needed to do is Egress the VLAN for the particular VSC.  The AP needed to be untagged on the IP that the AP get (VLAN 16 in my case) and tagged for all other VLANs.

Also, _Lemmy_ I agree that MSM765 is crap.  It is very slow. Click, wait 20 seconds, see new menu.  It is also not the most intuitive way of dealing with AP's.  It took me a looong time to figure out how to use this software and the user guides are not helpful.