cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
945
Views
0
Helpful
7
Replies

Odd WLC/Switch Connectivity Issue

frank.trampe
Level 1
Level 1

I installed a Cisco 4402 WLC and a Cisco 4948E-E switch together, with a single tagged non-LAG copper link from the first slot on the WLC to a port on the switch. For some reason, they are not able to pass any traffic or to ping each other, even on the default VLAN, but they can communicate perfectly if patched through another managed switch (a Netgear GS108E in this case) with relevant VLANs enabled and no other devices connected. It is all the more confusing since I have used exactly these models at several other sites with no problems. The switch is connected to the router and to another switch and is passing traffic correctly otherwise. Any idea what might be happening here?

 

All relevant VLANs are enabled on the switch.

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/1, Gi1/2, Gi1/3, Gi1/4
Gi1/7, Gi1/8, Gi1/9, Gi1/10
Gi1/11, Gi1/12, Gi1/13, Gi1/14
Gi1/15, Gi1/16, Gi1/17, Gi1/18
Gi1/19, Gi1/20, Gi1/21, Gi1/22
Gi1/23, Gi1/24, Gi1/25, Gi1/26
Gi1/27, Gi1/28, Gi1/29, Gi1/30
Gi1/31, Gi1/32, Gi1/33, Gi1/34
Gi1/35, Gi1/36, Gi1/37, Gi1/38
Gi1/39, Gi1/40, Gi1/41, Gi1/42
Gi1/43, Gi1/44, Gi1/47, Gi1/48
Te1/50, Te1/51, Te1/52
5 guest active
9 isp active Gi1/5, Gi1/6
10 wireless active
12 littleguest active
13 VLAN0013 active
101 testvlan active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup

 

The switch ports are configured as follows.

interface GigabitEthernet1/13
switchport trunk allowed vlan 1-6,9-12,1002-1005
switchport mode trunk

 

This is the network configuration on the WLC.

(Cisco Controller) >show interface summary

Interface Name Port Vlan Id IP Address Type Ap Mgr Guest
-------------------------------- ---- -------- --------------- ------- ------ -----
ap-manager 1 10 192.168.2.15 Static Yes No
ht3xx_vlan1 1 1 192.168.0.14 Dynamic No No
ht3xx_vlan12 1 12 192.168.4.14 Dynamic No No
management 1 10 192.168.2.14 Static No No
service-port N/A N/A 0.0.0.0 DHCP No No
virtual N/A N/A 192.168.254.254 Static No No
(Cisco Controller) >show interface detailed ht3xx_vlan1

Interface Name................................... ht3xx_vlan1
MAC Address...................................... 00:1d:70:20:34:63
IP Address....................................... 192.168.0.14
IP Netmask....................................... 255.255.255.0
IP Gateway....................................... 192.168.0.1
External NAT IP State............................ Disabled
External NAT IP Address.......................... 0.0.0.0
VLAN............................................. 1
Quarantine-vlan.................................. 0
Active Physical Port............................. 1
Primary Physical Port............................ 1
Backup Physical Port............................. Unconfigured
Primary DHCP Server.............................. 192.168.0.1
Secondary DHCP Server............................ Unconfigured
DHCP Option 82................................... Disabled
ACL.............................................. Unconfigured
AP Manager....................................... No
Guest Interface.................................. No
L2 Multicast..................................... Enabled

 

 

 

1 Accepted Solution

Accepted Solutions

I tested and investigated a bit more and finally figured out what was happening. The wireless controller has no concept of native VLAN on the trunk-designated link. It tags all traffic, expects all traffic to be tagged, and discards anything untagged. The switch, unless "vlan dot1q tag native" is set, does not tag any traffic on the native VLAN for the link, which means that the wireless controller ignores any native VLAN traffic from the switch. If "vlan dot1q tag native" is set, the switch acts like the wireless controller. It rejects rather than implicitly tags untagged traffic on trunk ports, including native VLAN traffic from other switches and routers not configured with that option. So using that option would have required a sitewide change. The only way I could find to make it work without doing that was to set the native VLAN on the trunk port to the wireless controller to one that was totally unused, such that all meaningful traffic on that link would be tagged.

 

Thanks Georg for suggesting switching the native VLAN.

 

View solution in original post

7 Replies 7

Hello,

 

judging from your output, the management VLAN is VLAN 10. Try and set that as the native VLAN on the trunk:

 

interface GigabitEthernet1/13
switchport trunk allowed vlan 1-6,9-12,1002-1005
switchport mode trunk
switchport trunk native vlan 10
spanning-tree guard root

Hmm. With the port guard enabled, setting the primary vlan to 10 makes vlan 1 work, and setting the primary vlan to 1 makes 10 work.

 

For what it's worth, the primary vlan on the intermediate switch that makes it work is 1.

 

I just realized that, at the other sites, we did not use the primary VLAN, so this (presumably a tag scheme mismatch) was probably happening but non-problematic. I'll experiment a bit more next week.

 

I tested and investigated a bit more and finally figured out what was happening. The wireless controller has no concept of native VLAN on the trunk-designated link. It tags all traffic, expects all traffic to be tagged, and discards anything untagged. The switch, unless "vlan dot1q tag native" is set, does not tag any traffic on the native VLAN for the link, which means that the wireless controller ignores any native VLAN traffic from the switch. If "vlan dot1q tag native" is set, the switch acts like the wireless controller. It rejects rather than implicitly tags untagged traffic on trunk ports, including native VLAN traffic from other switches and routers not configured with that option. So using that option would have required a sitewide change. The only way I could find to make it work without doing that was to set the native VLAN on the trunk port to the wireless controller to one that was totally unused, such that all meaningful traffic on that link would be tagged.

 

Thanks Georg for suggesting switching the native VLAN.

 

Leo Laohoo
Hall of Fame
Hall of Fame
Post the complete output to the command "sh interface Gi 1/13 trunk".

This is with the the WLC plugged directly into port 13.

ht3xx_dc_switch_1#show int Gi1/13 trunk

Port Mode Encapsulation Status Native vlan
Gi1/13 on 802.1q trunking 1

Port Vlans allowed on trunk
Gi1/13 1-6,9-12,1002-1005

Port Vlans allowed and active in management domain
Gi1/13 1,5,9-10,12

Port Vlans in spanning tree forwarding state and not pruned
Gi1/13 1

 

And this is with the WLC chained through another switch on port 46.

ht3xx_dc_switch_1#show int Gi1/46 trunk

Port Mode Encapsulation Status Native vlan
Gi1/46 on 802.1q trunking 1

Port Vlans allowed on trunk
Gi1/46 1-6,9-12,1002-1005

Port Vlans allowed and active in management domain
Gi1/46 1,5,9-10,12

Port Vlans in spanning tree forwarding state and not pruned
Gi1/46 1,5,9-10,12

 

Review Cisco Networking for a $25 gift card