We have some of the new Cisco 1810W access points. We're trying to set them up with the following configuration but having difficulties:
The Deployment Guide for 1810W suggests it is possible. It was certainly possible to do it on the older 702W access points that we already use.
During our testing we are doing the following (as per the Deployment Guide):
When we convert the switchport to trunk mode, the access point cannot get an IP address using DHCP and seems unable to discover the local gateway using ARP.
Wireshark shows frames being sent out from the AP as untagged frames (DHCPDISCOVER, ARP, etc) and the replies coming back (DHCP OFFER, etc) on the native VLAN - but the AP ignores the replies and is therefore unable to obtain an IP address or discover the gateway.
Ultimately, this means we can use it as a standalone access point, or use it with wired ports tunnelled to the controller but we haven't been able to succeed with the wired ports switched locally in trunk mode.
Has anyone achieve the above configuration who could offer any tips?
Does the AP get a lease when the port is in access mode? I'm just wondering if something like ip dhcp snooping trust is missing from your Trunk port towards your DHCP server (not on the AP Port).
If you plug something else like a laptop into that port do you get a lease? Trying to rule out switch/wired config before checking the AP config.
Thanks for your reply.
Yes, the AP gets a lease when the port is an access mode.
A laptop or other device will also obtain a lease if the port is in access mode and a laptop also works when the port is in trunk mode.
It's only the 1810w that fails.
in Trunk mode:
We see the 1810w send the DHCP Discover. We log receipt of it on our DHCP server. We also see the DHCP Offer return to the access point. Then nothing.
1810w will then repeatedly send DHCP Discover as it tries to obtain an IP. The DHCP server sends DHCP Offers. We know those offers arrive at the AP Uplink port but nothing happens with them.
We think it has something to do with how the AP evaluates the VLAN tags on the replies.
That is quite frustrating! You could try altering the AP IOS file directly to see if that resolves a potential bug?
We discovered that if the access point is plugged into a switch with a very minimal configuration, it works as expected.
If we plug the access point into one of our own production switches, which has a comprehensive configuration - the AP fails to connect.
We have worked out that the AP connectivity is broken by the following global configuration line that appears on our switches:
vlan dot1q tag native
If this line is removed from the global configuration, the AP works fine. If it is present, the access point won't work properly in trunk mode.
I post this here for anyone else who happens to have the same issue - but we need to understand the purpose of this line in our configuration and the implications of removing it.
Having spoken to our Cisco representative on this, we've been told that the issue 'should' be resolved in code versions from 8.5 and upwards.
The workaround given to us is to tunnel all LAN traffic up to the controller, to be routed at the network subnets local to the controller (rather than local to the user).
The ability to do this will depend on your controller, your network capacity and security requirements.
I've got it working with 184.108.40.206, no problem other than the config is colossally complicated.
You have to create an RLAN, turn on Flex with VLANs in the RLAN, map that RLAN to an AP Group, add the AP to the group, then map the RLAN to the port, and the AP has to be in Flex mode.
The issue is due to bug CSCva41204. Currently categorised as "enhancement".
Tagged Management VLAN Option Broken for 1800/3800
"VLAN Tagging" for 2800/3800 in advanced settings does not work as for IOS AP
Dont use the feature (capwap traffic remains untagged)