ZoneDirector Accesspoint provisioning issues with nonstandard untag VLAN id
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-14-2015 10:46 AM
Hi,
we're running a ZD1200 (9.12.0.0) with a bunch of R500.
During provisioning we encountered an error with the following configuration:
ZD updates firmware & provisions config, Access Point group is configured as follows:
By monitoring the switches MAC address table I noticed that:
After reverting the "Untag VLAN ID" to 1 in the Access Point Group and configuring VLAN 120 as tagged VLAN provisioning now works as expected - after initial provisioning in the untagged VLAN all further communication flows over tagged VLAN 100 on eth0.
This seems like a bug and should be addressed in engineering, cost us the better part of two days to hunt that one down.
we're running a ZD1200 (9.12.0.0) with a bunch of R500.
During provisioning we encountered an error with the following configuration:
- Management VLAN 100 (on a tagged port on ZD)
- Provisioning VLAN 101
- Guest WiFi VLAN 120 (configured as default VLAN on a few SSIDs)
ZD updates firmware & provisions config, Access Point group is configured as follows:
- eth0: Trunk, Untag VLAN ID 120
- eth1: Disabled
- Management VLAN: 100
- IP: keep AP default (DHCP)
By monitoring the switches MAC address table I noticed that:
- during initial configuration the AP uses the MAC address ending with a 0, which is first seen on VLAN 101 (untagged port on the switch)
- after provisioning the AP uses the MAC address ending with a 3 on VLAN 101 (untagged port on the switch)
- The MAC address ending with a 0 doesn't appear on VLAN 100 as it should, ZD communication does not work, the AP is effectively unreachable
After reverting the "Untag VLAN ID" to 1 in the Access Point Group and configuring VLAN 120 as tagged VLAN provisioning now works as expected - after initial provisioning in the untagged VLAN all further communication flows over tagged VLAN 100 on eth0.
This seems like a bug and should be addressed in engineering, cost us the better part of two days to hunt that one down.
0 REPLIES 0

