AP only communicates with HiveManager on Access Port

  • 1
  • Question
  • Updated 2 years ago
  • Answered
We recently purchased a number of AP 230s after being a Cisco WLC shop. When we connect the AP to the access ethernet port it picks up a DHCP provided IP address, but won't hand out IP addresses itself (The diagnostic says it's sending offers, but then nothing.) We have attempted to put the port in Trunk mode (see picture) but at that point we lose all connectivity to the AP from the Hive Manager online component, and have to revert back to our original access VLAN



Any ideas?
Photo of Support

Support

  • 4 Posts
  • 1 Reply Like
  • Confused

Posted 2 years ago

  • 1
Photo of Will Rhodes

Will Rhodes

  • 45 Posts
  • 9 Reply Likes
you need to specify the "native vlan" when switching it to a trunk port. Try the following command:


switchport trunk native vlan 11
(Edited)
Photo of Will Rhodes

Will Rhodes

  • 45 Posts
  • 9 Reply Likes
Which version of HiveOS are you running? There is a known DHCP issue with the AP230s.

From the release notes for 6.5r4:

"CFD-1722 After upgrading AP230 access points to HiveOS 6.5r3, some client devices would
intermittently not receive DHCP offers, despite the DHCP offers being sent by the DHCP
server."
Photo of Support

Support

  • 4 Posts
  • 1 Reply Like
Hello, thank you for your replies.

Our 230s are currently running HiveOS 6.5r3a Honolulu build2530

The user profiles setup have the VLAN traffic going to 20 for the 802.3, and 21 for the PSK.

I've looked for the VLAN probe in both the help section and for the tools section, but can't find it in my version of HiveManager NG. Is that located in the Monitor tab or in the Troubleshoot section? I didn't see it under AP > Utilities. Also, what do you mean 'Are you tagging that VLAN on that trunk port as well as all the way upstream to your DHCP Server' ? I'll admit I'm not as fluent in VLAN navigation as I should be, but I was under the impression that putting the port in trunking mode meant that all vlans were able to cross the threshold.
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
The VLAN probe is not in HiveManager NG sadly.  If you have SSH access directly into the AP, you could try the command "int mgt0 dhcp-probe vlan-range x - y" (where x is the starting range and y is the ending range, e. g. probe from VLAN 10-20).  It may not even work if the code on the APs functionally changes when gear is connected to HM NG.

I'm not Cisco expert, but I believe you to be correct in when you set a port to trunk, it allows all VLANs unless explicitly told specific ones.  But what about upstream further?  This port is a trunk, is the uplink port from this switch to the next?  And so on?  All the way out where your DHCP server is located?  

I guess a simple way to test this would be to set the port as an access port on your "client VLAN".  This would put the AP on that VLAN and if it gets an IP, the answer to the above would be yes.  If no, than I'd dig more into the VLANs on the LAN and/or the DHCP server.  Where/what does DHCP take place?  I do not believe you can do it at the Cisco WLC (I doubt you are, but want to make sure).
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Trunk ports have a native VLAN, on which all traffic MUST be untagged (most switches will discard tagged packets that ingress with a VLAN tag of the native VLAN, though some allow it - traffic going out of the switch port for the native VLAN will always be untagged though, and will be assigned to whatever the native VLAN is on the Aerohive device). You can also optionally specify an allowed VLAN list on the trunk port, which is recommended to constrain broadcast packets - allow only the VLANs which you need to have on that port.

In the Aerohive configuration, you can specify the management VLAN ID and native VLAN ID. If the management VLAN ID and native VLAN ID are the same, then management traffic will be untagged and be assigned to whatever VLAN is defined as native on the switch *whether or not that is the same VLAN ID*.

One thing that catches people out is that if you leave the management and native VLAN in Aerohive set to its default value (1), then this means management traffic will be untagged and management will work even if the native VLAN configured on the switch is different (as untagged is untagged). But if you have that configuration and also have a user profile specifying the VLAN ID which IS configured as the native VLAN on the switch, then you have a conflict, as Aerohive will tag the user traffic with that VLAN (as it doesn't match the configured native VLAN of 1) and the switch will drop it or, if that doesn't happen, the replies will come back untagged and not be assigned to the right VLAN on the AP. So you must either configure the user traffic to be in VLAN 1 (even though that's not the "real" VLAN ID) or configure the management and native VLANs to match what is configured on the switch - I would always do the latter to avoid confusion.

You don't mention what you have configured as the user VLAN ID or what your Aerohive policy has as the native/management VLANs, so that is the first thing that springs to mind.

The most likely cause of the symptoms you've described is that you have a mismatch between the native/management/user VLAN IDs between the switch and the AP.

The symptoms you describe do not appear to be consistent with the DHCP issue in 6.5r3a, as your client monitor doesn't show the DHCP OFFER (the issue in 6.5r3a was that the DHCP OFFER got as far as the AP and showed in the client monitor tracebut didn't get received by the client). However I'd still upgrade to 6.5r4 as there are a number of fixes in there - in our experience, the DHCP issue will probably bite you even after you get your immediate problem fixed.

If your VLAN configuration IS correct, another common problem is where DHCP relay is being used, but the port that the DHCP server is connected to is configured as a trunk port. In this scenario, the DHCP server receives the DHCP discover from the client as a broadcast before it receives the relayed DHCP packet, and this can cause the DHCP offer not to be received by the client as it is broadcast out on the wrong VLAN rather than being sent to the relay agent. But if your DHCP server is on the same VLAN as the AP and the users then that shouldn't be an issue.
Photo of Ho Ka Lok

Ho Ka Lok

  • 27 Posts
  • 4 Reply Likes

FYR, we're using the 1st method, i.e. native/management LAN is NOT VLAN 1, but we didn't config HM to match the real VLAN, still using default VLAN 1. For user profile assigning another VLAN, say, VLAN 10, 11, 12, for different SSID ( Guest, PPSK ....etc),

    If the AP can use both eth0 and eth1, we'll seperate native/management VLAN on eth0 only, and eth1 use VLAN 10, 11, 12 ( AP Optional Settings->Advanced Port Settings, Native VLAN & Allowed VLAN Settings ) and do VLAN Routing ( AP Optional Settings->Routing->Multiple Network Default Routing add the VLAN ID)

   If the AP can only use eth0, after making sure the User Profile VLAN ID match the real VLAN ID in cisco switch, then default AP setting will tag VLAN ID(non VLAN 1 ) through the truck port to cisco switch for processing.

  My office deployment have both config, and some floor with single lan port for AP, will have POE injector, Cisco switch, h3c switch or AeroHive SR series POE switch depends on budget, follow these 2 config we don't have any DHCP problem with firmware 6.6r3, 6.6r4, and now 6.8r1