12-30-2011 07:33 AM - edited 11-18-2020 02:56 AM
This is a list of Cisco Wireless related facts that have evoked a “really? well I wish I knew that before…” moment for me and many others.
Hopefully this will help others save some time and frustration.
Please post suggestions for additions, as I’m sure there are other topics that fit these criteria.
Top 10 Cisco Wireless “Good to Know”
Cisco Switches by default do not tag the native Vlan. Also by default, the native Vlan is 1, therefore Vlan 1 is untagged.
When establishing a trunk to a Cisco Wireless LAN Controller, it's important to be aware of how tagged vs untagged are identified.
(4400-A) >show interface summary
Interface Name Port Vlan Id IP Address Type Ap Mgr Guest
--------------- ---- ---------- -------------- ----- ------ -----
ap-manager 1 untagged 1.1.1.118 Static Yes No
management 1 untagged 1.1.1.111 Static No No
When going through a WLC's initial startup wizard, if untagged for the Management Interface’s vlan is desired, enter '0' (zero) when prompted for the management interface's vlan, as this is equivalent to 'untagged':
(Cisco Controller)
Welcome to the Cisco Wizard Configuration Tool
Use the '-' character to backup
Would you like to terminate autoinstall? [yes]:
<snip>
Management Interface VLAN Identifier (0 = untagged): 0
ap image names:
w7 = standalone
w8 = lightweight
examples:
Lightweight/controller based/capwap/lwapp image:
Cisco IOS Software, C1130 Software (C1130-K9W8-M), Version 12.4(23c)JZ, RELEASE SOFTWARE (fc1) c1130-k9w8-mx.124-23c.JZ
Autonomous/IOS/Standalone image:
Cisco IOS Software, C1140 Software (C1140-K9W7-M), Version 12.4(21a)JY, RELEASE SOFTWARE (fc1)c1140-k9w7-mx.124-21a.JY
Most Cisco Access Points are available with two part numbers.
LAPxxx = shipped new from manufacturing with lightweight image
APxxx = shipped new from manufacturing with autonomous image
Same physical hardware.
Example:
Same physical ap's, the first is shipped with a lightweight image, the second with an IOS image:
AIR-LAP1142N-A-K9
AIR-AP1142N-A-K9
Most AP's can be converted between both modes.
Wireless LAN Controllers perform DHCP proxy' by default. The DHCP Server’ IP Address configured on controller interfaces acts the same way as an 'ip helper' statement on a Cisco router.
With this configuration in place, an IP Helper statement on the wireless clients’ default gateway router is not necessary.
DHCP Proxy can be configured via the WLC’s GUI in 6.x and 7.x code (Controller -> Advanced -> DHCP).
Earlier code requires CLI access for configuration:
(WLC) >show dhcp proxy
DHCP Proxy Behaviour: enabled
(WLC) >config dhcp proxy disable
(WLC) >show dhcp proxy
DHCP Proxy Behaviour: disabled
Bootp-Broadcast:disabled
Local mode Access Point: tunnels all traffic to controller, controller responsible for tagging packets and putting them on the wired network, AP's switchport configured in access mode/non trunk.
H-Reap mode Access Point: ap's function similarly to standalone ap's, tag their own traffic, AP's switchport configured as trunk. Vlan tagging requires configuration on each H-Reap mode AP (Via the controller’s Gui).
1500 Series, LAP-1505, LAP-1510: Last supported in 4.2.M controller code.
1000 Series, AP1010, AP1020, AP1030: Last supported in 4.2 controller code.
http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn601820.html#wp586876
These Access Points will not join a controller running code later than supported.
•9600 baud
•8 data bits
•1 stop bit
•No parity
*********No hardware flow control******
These are the same settings for other Cisco devices. It is essential that AP's console session have flow control disabled. Most other Cisco devices will tolerate this setting if not disabled, but AP's will not. The result is typically no display and/or keyboard response.
Those familiar with Cisco routing and switching may get the impression that Wireless LAN Controllers have routing capability. This may seem apparent due to the fact that multiple dynamic interfaces with ip addresses may be configured. WLC's do not route.
The ip addresses assigned to the dynamic interfaces are not used for client traffic passing through the controller.
Dynamic interfaces' IP addresses most useful function is to verify trunk tagging functionality.
For example, we've added a vlan 10 routed SVI on the connected L3 switch. The WLC is directly connected to the L3 switch, and the relevant port is configured to trunk.
Once we've added a WLC dynamic interface mapped to vlan 10, with a correct ip address, we should be able to ping it from the L3 switch. If not, ensure that vlan 10 is forwarding on the switch’s trunk port.
Another use for the dynamic interface IP address is for use with multicast. For wireless multicast receivers connected to local mode ap's, the controller will proxy/spoof IGMP reports to the wired network using the client's corresponding dynamic interface IP address.
By default, multicast traffic is not forwarded by Wireless LAN Controllers for local mode AP's.
A common source of confusion is that Autonomous Mode AP's will forward multicast just as they would unicast, so no configuration is required. In the instance of Autonomous AP's being converted to Controller Based/Lightweight, multicast will no longer work until configured on the controller.
Since Controller based H-Reap mode ap's forward their own traffic, multicast will behave as if the AP were a standalone AP, and no controller configuration is required.
For Layer 3 authentication, e.g. Web Auth, authentication handling occurs on the Anchor Controller.
For Layer 2 authentication, e.g. 802.1x, authentication handling occurs on the Foreign controller.
Good one Jeff!! +5
Nice! +5 ...
Great Information. Thanks for your contribution Jeff. 5+
Vinay Sharma
Community Manager
"Please post suggestions for additions, as I’m sure there are other topics that fit these criteria."
Maybe one to add:
Tagged/Untagged management access to the AP. Is it safe to say that one can access the AP via vty lines using ONLY untagged packets?
I've been experimenting with 'vlan dot1q tag native' on the switch and it seems as though taggin the native breaks access to the AP.
Can anyone confirm/deny/shed light?
TIA
Hi,
here is the best practise for WLC TAG/Untag..
WLC management int TAGged -- make sure the Switchport doesnt have NATIVE VLAN command
WLC management int UNTAGed -- Make sure the Switchport has the Native VLAN command
Regards
Surendra
Thanks for the quick reply!
Does this best practice apply to Autonomous APs as well?
Regards,
Trevor
Autonomous AP ---
Its slightly different..
Switchport Native on the Switch ---- On the AP make sure the right subinterface has BRIDGE GROUP 1 under it.
Regards
Surendra
With the 'vlan dot1q tag native' commnand applied, I lose management connectivity to the AP with
'no vlan dot1q tag native' applied, connectivity is restored. Why is this?
Is it safe to say that one can access the AP via vty lines using ONLY untagged packets?
SWITCH CONF
vlan dot1q tag native
!
interface GigabitEthernet0/1
description AIRONET
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2,4,8,16,32,48,64,128
switchport mode trunk
AIRONET CONF
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
no keepalive
!
interface GigabitEthernet0.2
encapsulation dot1Q 2 native
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: