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