A Store That Drops POS Every 40 Minutes, and 339 More Like It
Store #212 of a 340-store retail chain runs six Instant APs in one cluster, managed through Aruba Central. The POS SSID is bridged locally on 2.4 GHz, and payments go to a cloud endpoint over the store broadband link. For three days, POS terminals have dropped for 20 to 40 seconds roughly every 40 minutes. Central shows the cluster virtual controller changing twice, one AP's uptime resetting, and the POS clients re-associating to a different AP each time. The store has a 90 W PoE budget on a 24-port switch that also powers cameras. The AP above the stockroom sits on a 60 m cable run installed before the refit. No configuration changes were made in that period.
1. Rank the hypotheses and name the single piece of evidence that most quickly separates a reboot problem from a coverage problem.
Read the worked answer
The evidence contains a causal chain: an AP's uptime resets, the cluster re-elects a virtual controller, and POS clients re-associate. A 20-40 second outage is exactly what a VC election plus re-association looks like. So the reboot is the primary event and coverage is secondary.
Ranked hypotheses:
- PoE power starvation on the long run. A 60 m cable, a 90 W total budget shared with cameras, and an AP whose draw rises when both radios are busy is the classic recipe for a brownout and reboot.
- Switch port or cable fault: marginal link, errors, or a port that renegotiates.
- AP hardware fault or firmware watchdog: less likely, easy to rule out.
Fastest discriminator: the recorded reboot reason for that AP (Central AP details or local system status), read together with the switch PoE log for that port. 'Power loss' or a PoE class/over-current event points at power. A watchdog or kernel panic points at the AP. No reboot at all, only retries and low RSSI, would point at coverage.
Do this before touching RF settings; tuning channels while an AP is rebooting wastes everyone's time.
2. If the cause is power, what do you change at store #212, and what do you standardise so the other 339 stores do not repeat it?
Read the worked answer
At this store:
- Move the AP off the 60 m run or shorten it, or feed it from a higher PoE class port, or use a local power injector.
- Check what the switch actually negotiates; an 802.3at AP fed by an 802.3af port will be starved under load without ever logging a clean failure.
- Relieve the budget by moving cameras to another switch or a separate power source.
- Confirm the AP stays up through a busy trading period and that the virtual controller stops changing.
Chain-wide, the value is in prevention:
- Pull PoE budget and per-port negotiated class for every store from Central, and flag any store where AP maximum draw multiplied by AP count approaches the switch budget.
- Alert on AP reboot reason and on virtual controller changes. Both are leading indicators that a store is about to report POS drops.
- Add a cabling maximum run and a required AP power class to the store build standard, so future refits do not add APs to an already saturated switch.
- Track the count of stores in the flagged list as a programme metric, not as a one-off ticket.
3. The chain plans to move to AOS10 with gateways in two data centres. Should POS traffic be bridged at the store or tunnelled to a gateway? What actually decides it?
Read the worked answer
This is an availability and policy question, not a doctrinal one.
- Tunnel everything: every store's traffic then depends on the WAN and on gateway availability, and all 340 stores share a failure domain. For cloud payment traffic that dependency already exists, so tunnelling adds little availability risk there, but it adds a hop and centralised blast radius.
- Bridge: local devices (receipt printers, back-office server, IoT controllers) keep working when the WAN or gateway is unreachable, and you avoid tromboning store traffic through a data centre.
What decides it:
- Which flows must survive a WAN failure. Anything purely local argues for bridging.
- Which flows need central inspection. Cardholder-adjacent traffic argues for tunnelling.
- Whether the gateway pair is sized and HA'd for 340 stores of combined throughput and tunnel counts.
A practical design is mixed: tunnel the corporate and guest SSIDs for consistent policy, bridge the POS and IoT SSIDs with a locally enforced role and firewall policy, and manage the whole estate from Central. Then prove it: pull the WAN at one pilot store and confirm POS, printers and back-office behave the way the business expects.