MSM460 Clients getting wrong IP

[BGraham_1]

Hi,

We have a MSM765zl controller (V5.5.2.14) managing multiple MSM422 APs. There are multiple VSC's (none access controlled) associated with different VLANs. All of these are getting IP via a DHCP server and the IP-helper address is configured for each VLAN on the core switch. We recently added some MSM 460's to our network.

Some clients on these new APs are getting an IP in the range of the management VLAN of the AP (the untagged VLAN). I checked to make sure the client VLANs are tagged on the AP switch ports. The most baffling part is that only some clients are having problems.

Any ideas?

Thanks in advance

[MortenM]

A client of mine also had this problem, but it disappeared after upgrading to 5.5.2.14-01-10104

They are still experiecing other problems though - clients disconnecting, etc... I think this release has some bugs...

[BGraham_1]

That is actually the same version we are running.

We are also experiencing other  issues with clients disconnecting and getting self assigned IPs (169.254.x.x). This has been going on since version 5.5.1 (see thread titled "Losing access to network"  http://h30499.www3.hp.com/t5/E-Series/Losing-access-to-network/m-p/5326923#M309) Maybe if we can all share what we are  seeing, we can get enough information to HP to get these issues resolved.

[MortenM]

I have a support case going on with HP care pack support, regarding these issues.

I sent them all the logfiles, etc, and the case has now been elavated.

I also referenced this thread as well as the "Losing access to network"  http://h30499.www3.hp.com/t5/E-Series/Losing-access-to-network/m-p/5326923#M309) thread.

I will update this thread when I have more info.

[Stephen Swain]

I've had a similar problem after upgrade to 5.5.2.4 (and continued on 5.5.2.14) on the MSM765zl and MSM422s.

The fix?

Go into AP Configuration, Provisioning, Discovery and manually set the discovery to use No VLAN and the correct port.

I suspect default discovery behaviour changed after 5.4, and any untagged or tagged vlan on the AP may get a DNS response first for the Discovery Hostname (Default cnsrv1, then cnsrv2, then cnsrv3).

If you manually give the No VLAN (or appropriate tagged VLAN) the job, then the APs won't boot into the wrong management VLAN, and consequently the clients won't fail Radius (if AP is egress), or the clients that do authenticate won't end up on wrong vlan.

Hope this helps.

Regards,

Steve.

[Stephen Swain]

Can I just explain that "boot into wrong vlan" and radius issue I saw?

If the management vlan moves to wrong vlan, the AP gets DHCP address on user vlan, and the AP VSC Profile/SSID in question has Radius configured to run from the AP to Radius Servers, then the Radius server will not respond due to invalid client IP and shared secret.

Until my problem was fixed, I ended up adding a temporary radius key for that user vlan. :)

[BGraham_1]

When I go to change the discovery settings as you described, it is already set to use "Port 1" and "No VLAN as part of the inherited configuration. There is a note at the top of the page that states:

"Provisioning of controlled APs is currently disabled. The provisioning configuration will not be applied to APs. You can enable provisioning by going to the Controller>>Controlled APs>Provisioning page"

When I go to this page, ther is a checkbox for "Replace any existing AP provisioning with controller-based provisioning settings". When I check it, I get a pop-up window with

"Doing so will replace any existing provisioning ont APs with controller-based provisioning settings".

What will be the impact of doing this? Should I do this after hours? How will this affect AP prorvisioning moving forward?

Side note: I found the clients getting IP Addresses from the AP managemetn VLAN were all on Radio 2 (802.11n/b/g). Once I turned on Band Steering, they associated with Radio1 (802/11n/a). Any ideas?

Thanks

[Stephen Swain]

> When I go to change the discovery settings as you described, it is already set to use "Port 1" and "No VLAN as part of the inherited configuration.

Yes, was same for me. But the "default" didn't actually work. So I had to control privisioning and set my own options.

> When I go to this page, ther is a checkbox for "Replace any existing AP provisioning with controller-based provisioning settings". When I check it, I get a pop-up window with "Doing so will replace any existing provisioning ont APs with controller-based provisioning settings".

Yes, I forgot to mention that is also required to implement this change.

> What will be the impact of doing this?

It only affects the client AP boot discovery phase. When you change provisioning mode and sync, it shouldn't affect current AP operation. You would need to reboot the APs to have them try the new setting. What you could do as a test is only sync the setting to a single AP whilst pinging a client on that AP, and confirm there are no interruptions.

If you packet capture on the test AP, you will see the results in the change of DHCP behaviour - which should show DHCP requests only coming from the untagged vlan [however, your packet capture tools may not distinguish which vlan, but the IP address response will indicate the management vlan].

> Should I do this after hours?

As per above, I don't think it will affect normal operation.

> How will this affect AP prorvisioning moving forward?

Good question. I'm pretty new to MSMs, and there is a lot of behaviour hidden behind the GUI and CLI that isn't clear. We'd have to ask the developers this question. I only had the fix from about three weeks ago, and haven't had the time to look into provisioning since then.

Btw, I didn't figure out the root cause or the fix/workaround - that was from a HP Tech - and what informed us about the problem was basically packet captures and reboots of the controller (which caused the AP boot problem everytime).

I accidentally came across this forum yesterday and saw the thread, thought you would like to know. :)

Regards,

Steve.

[Stephen Swain]

> Side note: I found the clients getting IP Addresses from the AP managemetn VLAN were all on Radio 2 (802.11n/b/g). Once I turned on Band Steering, they associated with Radio1 (802/11n/a). Any ideas?

Did the clients on radio 1 also get the wrong IP address, or did they end up on the correct vlan? Band steering shouldn't affect the underlying vlan operation, that would be tied to profiles.

When I first had the problem, I found "reset to default" on the APs got them communicating back on the correct vlans. Later on a restart of the AP was sufficient. The problem always reappeared whenever I rebooted the controller.

Regards,

Steve.

[BGraham_1]

I will try this tonight and see if this helps other issues we are having as well. I wonder if this is why I see pulling IP addresses from the tagged VLANs as well as the untagged (management) VLAN.

Thanks,

Bob

[Stephen Swain]

>  Go into AP Configuration, Provisioning, Discovery and manually set the discovery to use No VLAN and the correct port.

Correction:

IT should have been Controlled APs -> Provisioning -> Connectivity -> Base Group

Tick Port 1 and select No VLAN.

I should have checked my answer last night before posting. :)

Regards,

Steve.

[MortenM]

Thank you for your tip, Stephen!

I will also try this today, and post the results here.

Regards,

Morten Marstrander

[BGraham_1]

I tried the teh solution suggested and I stil am seeing clients with IPs from the management VLAN. The band steering did not affect this issue as I had thought earlier. I am now seeing this issue on radio 1 as well.

I had another case open with HP and asked them about this issue. They said it sounded like a configuration issue and had me send the controller config and a "show tech" of the host switch. Since this is only happening on the MSM460s and all APs are in the same configuration group, I don't see how, but we will see....

Stay Tuned!

[Stephen Swain]

Sorry my tip didn't help - it worked for my 422s.

You should be able to capture dhcp packets and determine what is going wrong. When you do troubleshoot with hp techs, they are probably going to do that anyway.

Btw, I've just recently started testing msm460s, and I did notice something strange with the provisioning and discovery manual settings. I tried to force one 460 via discovery to use an alternate 765zl, and the setting did not work at all. On the 422s it did. I haven't had a chance to troubleshoot yet, but I might do some further testing on the 460s and the Connectivity settings and try and figure out if it is a 460 specific problem.

[Stephen Swain]

ps. I retested the 460s, and they do act as required.

What's the vlan setup look like on the switch, "sh vlan ports XX det" will show it?

Do you run gvrp at all? I've had problems in past with gvrp and trunk ports to ip phones or APs, it's more stable turned off.

[Stephen Swain]

> I tried the teh solution suggested and I stil am seeing clients with IPs from the management VLAN

Just thinking about this again, did you sync the change, then restart the AP?

Can you also try for a problem AP the Maintenance>Factory Reset, then try the testing again?

I find settings sometimes don't apply fully until I factory reset the AP and reapply the config.

Thanks,

Steve.

[BGraham_1]

I only synced the APs afterward. I will reset the m to factory defaults tonight and see how it goes tomorrow.

Thanks,

Bob

[Fredrik Lönnman]

Connectivity settings (changing ip address, from dhcp->static, vlan etc) will always need a reboot of the AP to take effect. Its noted in the operations PDF but sadly not in the webgui.

[ISoliman]

I have a customer reporting the same issue of Clients disconnection, all the APs are MSM460 and running the same version mentioned above in the other posts, there is a new version 5.5.3 did anybody try that one? and any update regarding the case opened with the support ?? I really appreciate any update on this issue.

Thanks in Advance for the help

[tasel]

We have the same issue - client  obtain wrong ip on MSM760 controller + MSM430 AP. Our's firmware verison is

5.7.0.2.

Did you find any solution.

Regards.

[gglater]

@BGraham_1, the case you opened for this issue indicates that support was able to help resolve the DHCP issues that you were having with a software fix.  These issues include self-assigned addresses and clients getting DHCP addresses from the untagged VLAN of the MSM460 APs.

I'm glad that support was able to help.

I encourage anyone experiencing a problem to please open a case with HP Networking support so that we can help you to solve the problem that you are having.

Thank you.

--glen

[gglater]

Reading through this thread, I see several different problems described.  Some seem like mis-configurations, and some seem like they might indicate the need for software fixes. 

Other problems described here were solved months ago by the poster opening a case with support.

I encourage you to call HP Networking support and open a case if you are having a problem.   That way, you can get the assistance that you need.

Thank you.

--glen

[acohenssv]

I've found it also helps to set the Colubris DHCP options (check the end of the Configuration Guide), but only on the relevant scope/vlan that the APs should be picking up an address from.

[Dom_User]

Hi Guys

I have been fighting with the same issue since last week and just today found this forum.

My MSM720 configured with 2 VLANs (VLAN 50 & VLAN 60 ) and AP MSM460.

I have 3 DHCP scopes configured on my controller.

Managment VLAN: 192.168.100.10 - 30

VLAN 50: 50.50.50.10-30

VLAN 60: 60.60.60.10-30

All APs are getting the IP Address from Managment VLAN.

I can see the problem once DHCP Scope for VLAN 50 or VLAN 60 is disabled.

Non of the clients connecting to the AP shouldn't get the IP Address as the scope has been disabled but it is getting the IP Address from the Managment scope which is not right.

The managment VLAN is untagged, VLAN 50 & 60 are both tagged.

Any fix or should I contact HP Support??

[smacstech]

I can cofirm we had this problem - our MSM460s were throwing out IPs on the management VLAN.

updating the firmware on the MSM765 to 

5.7.1.0-12379

solved the problem

our MSM460 Clients are now getting their correct IPs.