A worked deployment for a small store network — a customer Wi-Fi peak of roughly 200 devices and about 20 staff on wired and wireless — using a Huawei AR6300 router as the Internet gateway, an S5731-S switch for VLANs, DHCP and access control, and an AC6605 wireless controller for guest and staff Wi-Fi, brought up in the order that actually avoids rework: VLANs first, then the gateway, then DHCP, then wireless.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Get the sequence wrong here and you end up re-touching every box in the stack at least once.
This is a three-box small-store build: a Huawei AR6300 router as the Internet-facing gateway, an S5731-S switch doing the VLAN, DHCP and access-control work, and an AC6605 wireless controller running two separate SSIDs — one for customers, one for staff — across a set of AP6050DN access points. It's sized for a store with a customer Wi-Fi peak around 200 devices and roughly 20 staff on wired and wireless combined, which is enough scale that "just plug it all in and configure whatever's in front of you" reliably produces rework.
What follows is the configuration in the order that avoids that rework — VLANs, then the gateway, then DHCP, then wireless — with the CLI taken directly from the underlying configuration files, five gotchas this exact configuration quietly depends on, and how to actually confirm each piece is working rather than just assuming it is.
One gateway, one switch, one wireless controller — six VLANs between them.
Diagram labels are kept in English for engineering clarity.
VLAN Plan
| VLAN | Role | Notes |
|---|---|---|
| VLAN100 | AC / management link | The AC's wireless-management VLAN — also what the switch uses to talk to the AC. |
| VLAN102 | Access point VLAN | The VLAN the AP6050DN units sit in; DHCP option 43 here points every AP at the AC. |
| VLAN103 | Switch-to-router uplink | Carries traffic between the S5731-S switch and the AR6300 gateway. |
| VLAN2000 | Guest wireless access | Customer Wi-Fi, Portal-authenticated, rate-limited per client. |
| VLAN2100 | Staff wireless access | Employee Wi-Fi, WPA-WPA2 authenticated, no rate limit. |
| VLAN2200 | Staff wired access | The wired desktop in this example. |
Addressing
| Interface | Address | Role |
|---|---|---|
| AR6300 Dialer1 (WAN) | PPPoE-negotiated | Internet-facing interface; the address comes from the ISP. |
| AR6300 Vlanif1 | 10.103.1.2/24 | LAN-side gateway facing the switch. |
| S5731-S Vlanif100 | 10.100.1.1/24 | Gateway for the AC / management VLAN. |
| S5731-S Vlanif102 | 10.102.1.1/24 | Gateway + DHCP for the AP VLAN. |
| S5731-S Vlanif103 | 10.103.1.1/24 | Uplink toward the AR6300 gateway. |
| S5731-S Vlanif2000 | 192.168.200.1/24 | Gateway + DHCP for guest Wi-Fi. |
| S5731-S Vlanif2100 | 192.168.210.1/24 | Gateway + DHCP for staff Wi-Fi. |
| S5731-S Vlanif2200 | 192.168.220.1/24 | Gateway + DHCP for the wired desktop. |
| AC6605 Vlanif100 | 10.100.1.2/24 | The AC's own management / source address. |
Devices and Software Versions in This Example
| Device | Role | Software version |
|---|---|---|
| AR6300 | Internet gateway | V300R019C10 |
| S5731-S | Access / aggregation switch | V200R019C10 |
| AC6605 | Wireless controller | V200R019C10 |
| AP6050DN | Access point (×9) | V200R019C00 |
Each stage below only works because the previous one is already in place — that's why the order matters.
Every VLAN in this deployment is created and given its VLANIF address on the S5731-S switch before anything is trunked toward the AC or routed toward the AR6300 gateway.
[S5731-S] vlan batch 100 102 to 103 2000 2100 2200
#
interface Vlanif100
ip address 10.100.1.1 255.255.255.0
#
interface Vlanif102
ip address 10.102.1.1 255.255.255.0
#
interface Vlanif103
ip address 10.103.1.1 255.255.255.0AR6300 is the only device in this design that talks to the Internet directly. It dials out over PPPoE, applies NAT outbound so every private VLAN can share that single public address, and carries a static route back to each VLAN sitting behind the switch.
#
acl name GigabitEthernet0/0/0 2999
rule 5 permit
#
interface Dialer1
link-protocol ppp
ppp chap user admin
ppp ipcp dns admit-any
ppp ipcp dns request
ip address ppp-negotiate
dialer user arweb
dialer bundle 1
dialer number 1 autodial
dialer-group 1
nat outbound 2999
#
interface Vlanif1
ip address 10.103.1.2 255.255.255.0
#
interface GigabitEthernet0/0/0
pppoe-client dial-bundle-number 1
#
interface GigabitEthernet0/0/2
portswitch
#
ip route-static 0.0.0.0 0.0.0.0 Dialer1
ip route-static 10.102.1.0 255.255.255.0 10.103.1.1
ip route-static 192.168.200.0 255.255.255.0 10.103.1.1
ip route-static 192.168.210.0 255.255.255.0 10.103.1.1
ip route-static 192.168.220.0 255.255.255.0 10.103.1.1The PPP CHAP/PAP cipher password lines and the dialer-rule block are omitted from this excerpt — set your own PPPoE credentials and dialer-rule 1 ip permit as usual.
The switch, not the router, hands out addresses on every VLAN a client can actually sit in: the AP VLAN, both wireless VLANs, and the wired VLAN.
[S5731-S] dhcp enable
#
interface Vlanif102
dhcp select interface
dhcp server dns-list 114.114.114.114
dhcp server option 43 sub-option 3 ascii 10.100.1.2
#
interface Vlanif2000
ip address 192.168.200.1 255.255.255.0
dhcp select interface
dhcp server dns-list 114.114.114.114
#
interface Vlanif2100
ip address 192.168.210.1 255.255.255.0
dhcp select interface
dhcp server dns-list 114.114.114.114
#
interface Vlanif2200
ip address 192.168.220.1 255.255.255.0
dhcp select interface
dhcp server dns-list 114.114.114.114AC6605 runs two SSIDs on the same set of access points: guest, Portal-authenticated and rate-limited, and employee, WPA-WPA2 authenticated with no rate limit.
[AC6605] portal local-server ip 10.100.1.3
[AC6605] portal local-server url 10.100.1.3
[AC6605] portal local-server https ssl-policy default_policy port 20000
#
[AC6605] authentication-profile name guest
[AC6605-authentication-profile-guest] portal-access-profile guest
[AC6605-authentication-profile-guest] authentication-scheme guest
#
[AC6605] portal-access-profile name guest
[AC6605-portal-access-profile-guest] portal local-server enable
#
wlan
traffic-profile name guest
rate-limit client up 1000
rate-limit client down 2000
security-profile name guest
security-profile name employee
security wpa-wpa2 psk pass-phrase Example@123 aes-tkip
ssid-profile name guest
ssid guest
ssid-profile name employee
ssid employee
vap-profile name guest
service-vlan vlan-id 2000
ssid-profile guest
security-profile guest
traffic-profile guest
authentication-profile guest
vap-profile name employee
service-vlan vlan-id 2100
ssid-profile employee
security-profile employeeThe WPA-WPA2 pass-phrase shown is the source example's own placeholder — always set a unique pass-phrase of your own.
Every one of these lives inside a single line of the configuration above — easy to miss, expensive to debug blind.
SYMPTOMWireless clients associate fine, but devices land on VLANs you didn't expect, or an AP won't settle onto the VLAN you planned for it.
CAUSEBy default, a Huawei switch trunk port allows VLAN 1 and treats it as the native VLAN. Left at its defaults, untagged traffic — and anything that happens to match VLAN 1 — rides along on every AP-facing or AC-facing trunk, right next to the VLANs you intentionally isolated.
FIXEvery AP-facing and AC-facing trunk in this deployment explicitly removes VLAN 1 and sets both a PVID and an explicit allowed-VLAN list.
[S5731-S-GigabitEthernet0/0/1] port link-type trunk
[S5731-S-GigabitEthernet0/0/1] port trunk pvid vlan 102
[S5731-S-GigabitEthernet0/0/1] undo port trunk allow-pass vlan 1
[S5731-S-GigabitEthernet0/0/1] port trunk allow-pass vlan 102 2000SYMPTOMAn AP powers up on the AP VLAN, pulls an IP address, but never registers to the AC — it just sits there.
CAUSEThe AP and the AC (Vlanif100, 10.100.1.2) are on different VLANs and subnets, so the AP has no way to discover the AC's address by broadcast alone — that address has to be handed to it inside the DHCP response.
FIXThe DHCP pool serving the AP VLAN carries the AC's address as DHCP option 43, sub-option 3, so every AP gets it automatically the moment it gets an IP address.
[S5731-S-Vlanif102] dhcp select interface
[S5731-S-Vlanif102] dhcp server dns-list 114.114.114.114
[S5731-S-Vlanif102] dhcp server option 43 sub-option 3 ascii 10.100.1.2SYMPTOMAn ACL gets added to the trunk port carrying guest traffic, expecting it to block guest-to-staff traffic — and it doesn't behave the way an interface ACL normally would.
CAUSEIn this design, guest isolation is enforced by binding the ACL to VLAN 2000 itself, not to a physical interface — it has to catch guest traffic no matter which physical port the guest device happens to be associated through.
FIXDefine the deny rules in a named ACL, then bind it with traffic-filter vlan 2000 inbound — not on any single GigabitEthernet interface.
[S5731-S] acl name vlan2000 3999
[S5731-S-acl4-advance-vlan2000] rule 5 deny ip source 192.168.200.0 0.0.0.255 destination 192.168.220.0 0.0.0.255
[S5731-S-acl4-advance-vlan2000] rule 10 deny ip source 192.168.200.0 0.0.0.255 destination 192.168.210.0 0.0.0.255
[S5731-S] traffic-filter vlan 2000 inbound acl name vlan2000SYMPTOMGuest devices associate to the guest SSID and get an IP address, but the Portal login page never appears — the connection just looks stuck before authentication.
CAUSEAn unauthenticated guest device still needs to resolve DNS before it can be redirected to the Portal page, so the free-rule template explicitly permits reaching the DNS server address before authentication. If the DNS address in the DHCP pool is ever changed without updating this rule, the two fall out of sync and the redirect breaks silently.
FIXKeep the free-rule destination address and the DHCP-assigned DNS server address as the same IP — 114.114.114.114 in this example — every time either one changes.
[AC6605] free-rule-template name default_free_rule
[AC6605-free-rule-default_free_rule] free-rule 1 destination ip 114.114.114.114 mask 255.255.255.255SYMPTOMReading the AAA scheme for the guest authentication profile for the first time, it looks like guest Wi-Fi has no authentication at all — but users still see a login/notice page.
CAUSEauthentication-mode none tells the AAA scheme not to layer 802.1X or MAC-address authentication on top of what's already happening — it does not mean unauthenticated. The actual authentication challenge for guest traffic is handled entirely by the Portal profile referenced in the same authentication-profile.
FIXRead authentication-scheme and portal-access-profile together, not authentication-scheme in isolation, before concluding an SSID is or isn't authenticated.
[AC6605] aaa
[AC6605-aaa] authentication-scheme guest
[AC6605-aaa-authen-guest] authentication-mode none"Connected" on a phone's Wi-Fi icon is not the same as "on the right VLAN, behind the right ACL".
If an AP never shows up at the AC at all, the first two things to check are always the same: is the AP-to-AC route actually reachable across VLAN100/VLAN102, and does the AP's DHCP lease actually carry option 43 with the AC's real address.
The questions that come up most once engineers actually try to reproduce this build.
This design puts a dedicated AC6605 in the stack specifically because its 9 AP6050DN units sit on VLAN102 while the AC sits on VLAN100 — a routed L3 boundary between them. Once APs are spread across more than a handful and register across a routed network rather than one flat VLAN, a controller earns its place; a smaller single-VLAN Wi-Fi setup might not need one.
In this design, the S5731-S switch is the DHCP server for Vlanif102 (APs), Vlanif2000 (guest), Vlanif2100 (staff Wi-Fi) and Vlanif2200 (staff wired) — the AR6300 router only handles NAT and PPPoE and forwards a default route. Centralizing DHCP at the switch keeps every address pool right next to the Layer-3 gateway that actually serves it.
The named ACL vlan2000 (rules 5 and 10, both deny) is bound inbound on VLAN 2000, blocking guest-to-staff-wireless and guest-to-staff-wired traffic, while the default route through AR6300 still lets guest traffic reach the Internet.
VLAN2200, with its own dedicated VLANIF gateway and DHCP scope, on a plain access port (not a trunk) toward the desktop — kept separate from every wireless VLAN in the design.
This exact build is sized for roughly 200 peak guest Wi-Fi devices, about 20 staff, and 9 access points on one AC. A meaningfully bigger site — more APs, more switches, redundant controllers — starts to look like a full campus design rather than a variation on this store build; see the related solution designs below.
This note is built around one worked example: a single AR6300 gateway, a single S5731-S switch and one AC6605 controller serving nine AP6050DN access points, sized for a store with a customer Wi-Fi peak around 200 devices and about 20 staff. A bigger store, multiple aggregation switches, a redundant controller, 802.1X instead of a shared WPA-WPA2 pass-phrase, or a wired WAN uplink instead of PPPoE all shift enough details that they deserve their own configuration, not a variation bolted onto this one.
Router, switch or wireless controller — tell us which piece and what you're seeing, and we'll help you work through it.