Template Strategy for a Three-Site Retail Rollout with Local Guest Egress
Northwind Retail operates three sites in one Mist organization: a flagship store with 180 APs, and two stores with 25 APs each. There are 14,000 daily clients and six planned SSIDs: corporate, store ops, guest, IoT, scanner, and a temporary event SSID. Corporate IT wants to manage all WLANs centrally, but store managers need to change the guest VLAN and event SSID locally. The two small stores have a 4-hour WAN outage every Tuesday for maintenance; during that time, guest traffic must still egress locally and employees must still authenticate. The company has no data center and wants to avoid on-premises appliances unless clearly justified. A recent org-level WLAN template push removed the guest SSID from one store because a site variable was left blank. The security team also asks whether Mist Edge is required for guest traffic or for RADIUS traffic.
1. Recommend how to structure the WLAN configuration across the organization and sites. Identify which SSIDs should be org-level templates, which should be site-level, and how variables should be used. Explain the failure after the template push.
Read the worked answer
Use a three-layer model: org-level WLAN templates for SSIDs that must be identical (corporate, store ops, IoT, scanner), and site-level WLANs for guest and event SSID where VLAN or egress differs. Do not put site-specific VLAN IDs directly in the org template; define site variables such as guest_vlan, event_vlan, and radius_server, then reference them in the template. Assign templates only to sites that should receive them. The missing guest SSID is consistent with a blank required variable: Mist will not render a WLAN with an unresolved variable, or the template assignment was removed. Validate by opening the site's WLANs, checking variable resolution, and comparing template assignment. For the small stores, either create a site-level guest WLAN or use a template with a default variable and an explicit override. Keep the event SSID site-level because it is temporary and local. This gives central control without forcing local changes through org-wide pushes.
2. Evaluate whether Mist Edge is needed. Address guest local egress, RADIUS during WAN outages, and the no-on-premises constraint.
Read the worked answer
Mist Edge is not required just to break guest traffic out locally. Mist APs can bridge a WLAN to a local VLAN; guest traffic then egresses at the store's own firewall. Mist Edge is justified when you need to tunnel user traffic to a central data plane, enforce centralized policy, meet data-residency requirements, or aggregate very large guest deployments. Here there is no data center; adding an edge at HQ would pull guest traffic across the WAN, which is the opposite of local egress. For RADIUS, Mist Edge can proxy authentication, but it does not create connectivity if the WAN to HQ is down. If employee 802.1X must survive the Tuesday outage, put a local RADIUS server or a local authentication fallback at each store, or use a separate PSK-based store-ops WLAN with rotation. Mist Edge at HQ would not solve the outage.
3. During the Tuesday outage, what still works and what fails? Recommend a design change to keep employee authentication working.
Read the worked answer
During the outage, the APs can keep forwarding traffic using their last cloud-delivered configuration, and locally bridged guest traffic can still egress if the local VLAN, DHCP, and firewall are up. What fails is anything that requires the cloud or the HQ WAN: new config changes, cloud guest portal, RADIUS to HQ, and Mist telemetry/alarms. Employee 802.1X will fail if the only RADIUS is at HQ. Design change: deploy a small local RADIUS server at each store for 802.1X, or configure a store-ops WLAN with a unique PSK and a documented rotation process. Keep guest local and do not tunnel it. Test by simulating WAN loss and confirming authentication, DHCP, and egress. This keeps security reasonable without requiring on-premises appliances everywhere.