White Sand Luxury Villas & Spa

The property runs dual-WAN with automatic failover. WAN1, the primary link, is fiber from Liquid Intelligent Technologies (gateway 154.127.0.158, static route, metric 1). WAN2 is a Starlink satellite backup on CGNAT (metric 200), which only a handful of specific devices are policy-routed onto directly. Recent usage over the sampled window was roughly 679 GB (≈572 GB down, 106 GB up).

Sampled 99 of ~190 adopted devices: roughly 86 online, ~12 offline (≈12%, a common baseline rather than a fresh alarm). Access points range from legacy WiFi-5 hardware (U6 Lite, AC Pro, AC Lite, UAP-LR, AC Mesh Pro) still in the majority, through to a newer WiFi-7 rollout (U7 Lite, U7 Pro Max, U7 Pro Wall, U7 Outdoor). Switches are mostly US-8-60W, US-8, and USW Flex/Lite/Pro models, named by location — one switch and one-plus AP per numbered villa (V3–V23), plus dedicated switches for CCTV cameras and the main gate.

Correction from an earlier pass of this report: both devices were initially thought to be physically at or near the UDM Pro Max itself, based on being learned on the gateway's own switch0.1 interface. The controller's client-detail UI gives a more precise answer: both are attached to Switch TVs ServerRoom (192.168.1.233) — port 5 and port 8 respectively, both negotiated at gigabit. That earlier "near the gateway" read was wrong; the loop is physically at this one switch, not the gateway itself.

Two client ports on the same physical switch, both flooding broadcast/multicast at a near-even ~50/50 split, is the textbook signature of a single patch cable connecting port 5 back to port 8 on Switch TVs ServerRoom (directly, or through one unmanaged device/hub sitting between them) — with no spanning-tree protection anywhere on this network to block the resulting loop. Both devices show an unrecognized/generic hardware vendor (no clean OUI match), consistent with unmanaged/no-name equipment rather than a UniFi-known client.

A forensic clue on when this started: the controller's own client records show both devices' "last seen" timestamp frozen at exactly 2026-05-17 22:59:32 UTC — within five minutes of the very first network-wide outage event recorded anywhere in this survey (§07, 2026-05-17 22:54:34). That's consistent with this loop condition beginning around that first outage and the controller losing normal visibility into these two devices from that point on, even though they're clearly still very much alive and transmitting.

No loop protection is active to contain it. Every VLAN bridge on the gateway itself reports STP disabled (stp_state=0 on br0, br10, br11, br20, br30, and br40), and this survey didn't find switch-side STP status confirmed either (swctrl stp show returned empty on every switch tested — an open item, not a confirmed "on"). The "RSTP" setting noted in the network's global config most likely governs the UniFi switch fleet's own mesh in principle, but with the loop sitting on Switch TVs ServerRoom itself, the practical fact is that nothing is currently blocking it.

This is a strong candidate explanation for the "flip-flopping between clean and severely jittery" pattern documented across a dozen-plus switches in §09 — a storm that ebbs and shifts in intensity would plausibly hit whichever switch happens to be under load at the moment it's tested, then clear moments later. It doesn't rule out Pro V8's own hardware issue (§05) — that's independently confirmed by empty-port PoE failures a storm can't explain — but it may well be inflating the apparent scope of jitter elsewhere.

IGMP snooping is enabled and correctly scoped to exactly Management LAN and TV VLAN, matching the network's design intent. A live 90-second capture on the TV VLAN bridge confirms it's actually working: 10 IGMP general queries, 24 join/reports, and 9 leaves were observed — real channel-change activity, not a dead protocol. The multicast group 233.89.188.1 (a GLOP-addressed range, consistent with IPTV content) was seen alongside standard housekeeping groups (224.0.0.1, 224.0.0.2, mDNS's 224.0.0.251).

Two things worth a closer look, neither urgent: the general queries were sourced from 10.0.0.1 — an address that doesn't belong to any configured subnet on this network, worth tracing since something on the TV VLAN is answering queries under an unexpected identity. And the network's IGMP configuration designates 31 switches as eligible queriers, three of which are switches already flagged elsewhere in this report as broken: Switch V3 and Switch BeachResta Cameras (both down, §09) and Switch Pro V8 itself (§05) — worth confirming querier failover is actually working now that those are compromised, rather than assuming it is.

The site-wide device SSH credential was recovered from the controller's console, giving direct terminal access to every switch and access point for the first time in this survey — not just the gateway. A full health pull (uptime, load average, memory, kernel log, port/PoE status) was run against all 60 switches and all 94 APs. Two results reshape the picture above.

Elevated CPU load is fleet-wide, not unique to Pro V8. Ranked by load average, a dozen-plus switches — office Store, Kitchen, V8 - Bottom Bedroom, V7, GM office, V1, Battery house, Tailor, Kiteschool, Middlestaff - Rooms — sit in the same 1.5–2.7 range as Pro V8 (2.68, the highest), and several APs (Beach_umbrella V2 at 3.08, V7 - Bottom Bedroom at 2.60) show the same thing. Many different physical devices running hot at the same time points at a shared cause hitting the whole fabric — almost certainly the broadcast storm above — rather than each device independently failing. This revises §05: Pro V8 is the worst-hit point of a shared problem, not a uniquely broken switch.

No catastrophic failures anywhere. Every device's kernel log was checked for kernel panics, out-of-memory kills, watchdog resets, and crashes — zero matches across all 154 devices. Whatever's degrading performance here, it isn't hardware dying outright.

A real but harmless SSH quirk on `USW-Flex-Mini` switches. 8 switches on that model (shown as USMINI) rejected SSH mid-handshake (kex_exchange_identification: Connection closed by remote host) while pinging perfectly clean — a model-class limitation on this lightweight hardware, not a health problem. One switch, switch V16, refused SSH on a different model with no other explanation yet — a small open lead.

A live process snapshot points at the switching hardware itself, not a third-party process. Filtering out this survey's own SSH overhead, the CPU on loaded switches is being spent by the switch OS's own core processes — switchdrvr (the switching-ASIC driver, seen as high as 57%) and the port-statistics-collection kernel thread, recurring across several different switches, plus an IGMP-processing thread on Pro V8 specifically. That's a direct mechanistic link: a switch forced to forward, count, and drop far more traffic than normal (exactly what a broadcast storm does) will show precisely this signature on its own driver and counter threads — on many switches at once, not because each is independently failing.

Full per-device output (uptime, memory, firmware version, kernel log, port/PoE status, and a live process snapshot) is saved as individual markdown files for further analysis — see the methodology section (§14) for the file locations.

Pulled Pro V8's own port table directly — every port, not just the flagged one:

The cabling is fine, and — correcting an earlier read of this same table — most of the "PoE failed" ports were never supposed to carry power in the first place. Ports 1, 2, and 8 connect to other switches (switch-to-switch links don't draw PoE; those units have their own wall power), and 5–7 have nothing plugged in. Only port 3, the one actual client device on this switch, is a genuine open question — its AP isn't drawing power, worth a physical check on-site. There's no evidence of a switch-wide power-supply failure once the uplink ports are correctly excluded; total PoE budget usage was 5.92W out of a 120W budget, nowhere near exhausted.

What direct access into the switch actually showed: 94 days of uptime, and a live snapshot at 51% user + 48% system CPU, 0% idle — genuinely maxed out, not inferred. Its kernel log also shows a real history of intermittent physical link flaps on ports 1 and 8 scattered across that uptime (each triggering a brief STP forwarding/blocking cycle on multiple ports at once) — a real, if secondary, physical-layer symptom. Fleet-wide testing (§04) found a dozen-plus other switches sitting in the same elevated-load range at the same time, which points to the broadcast storm as the shared driver of most of this rather than Pro V8's hardware uniquely failing — though the 94-day uptime and the port-3 PoE question are worth addressing on their own regardless.

This switch also acts as an aggregation point: Switch Middlestaff - Rooms (192.168.1.47) and New carpentry (192.168.1.61) uplink directly through it. Every time WallBOX drops, both of those go down with it — which is likely also the explanation for some of the "here-then-gone" instability noted elsewhere in this report (§09): a downstream ripple from this one device, not independent faults.

Because each drop only lasts a few seconds, a snapshot ping test can easily miss it entirely — in fact it did: WallBOX pings perfectly clean in every spot-check sweep run for this survey. Only the controller's long-run event log caught it. That's worth keeping in mind for any future troubleshooting here: a clean ping test is not proof a device is healthy.

The switch itself is mains-powered (not PoE-input), so the leading candidates are a failing internal power supply, or an unstable electrical circuit/outlet feeding it. It is not explained by the core uplink flapping in §07 — that only accounts for 4 incidents in 19 days, nowhere near 211 in one day — this is a separate, distinct fault local to this one device.

Physically visit Switch Middlestaff WallBOX. Check: (1) the power brick/PSU and outlet — swap the power adapter first as the cheapest test; (2) if flapping continues on a known-good outlet and power adapter, replace the switch unit itself; (3) while there, also check the uplink cable back to Switch POWER House (192.168.1.17) port 3 — reseat or replace it as a low-cost second step.

The gateway's own kernel log tells a clear story on interface eth9, the SFP-based uplink into the switch fabric: it keeps renegotiating between 10 Gbps optical and 1 Gbps mode, and every time it does, all six VLAN bridges — management, guest, TV, senior staff, kite school, middle staff — briefly go into a disabled state together. This isn't a segment losing signal; it's the property's one shared trunk misbehaving.

Physically inspect and reseat or replace the SFP module and fiber patch on the gateway's eth9 uplink, and check the matching transceiver at the far-end switch — the log implicates both ends.

The controller keeps a WAN-level downtime log going back a month. Almost every entry is brief (under 5 minutes) — WAN2/Starlink flaps occasionally, as expected for satellite. But WAN1, the primary fiber link, had two exceptions:

That's the primary internet link down for most of two consecutive days, last week. This is a different question from WAN quality (§12 below shows no bufferbloat when the link is up) — this is about WAN availability, and it's worth escalating directly with the ISP, Liquid Intelligent Technologies. Nothing on-site cabling work can fix an upstream fiber outage of that length.

5 switches are consistently unreachable. 2 switches show severe jitter on every single sweep — the closest thing to an individually-implicated link. A further 8 show it intermittently, which — combined with the WallBOX finding above — is more likely a symptom of shared upstream instability than 8 separate bad cables. The remaining 45 are clean and consistent throughout.

One port is an unambiguous fault: Switch office Store (192.168.1.174), port 4, is linked at just 10 Mbps — no current PoE device legitimately negotiates that low, regardless of age, so this points to a damaged cable, connector, or port. Trace and replace that specific run first.

Beyond that single case, dozens of ports across many different switches are linked at 100 Mbps rather than gigabit. Some of that is expected — several legacy AP models on this network (UAP-LR, U2Lv2, BZ2LR) are 100 Mbps-only by hardware design. The pattern is only worth acting on where a newer, gigabit-capable device is the one showing 100 Mbps — those specific pairs are the real candidates, and should be checked against the device model before anyone re-terminates a cable.

Read as a whole, this looks like distributed cabling wear rather than one bad switch — plausible for Cat5e runs in a humid, coastal, salt-air environment over years of service.

Rather than guess from datasheets, each flagged port's own advertised hardware capability was pulled from the controller — not just what speed it negotiated, but what it's physically capable of — and checked against the switch model. This separates "the switch can't do better" from "the switch can, but something's degrading the link."

Speed: the switches are not the bottleneck, anywhere. Every port sampled across all seven switch models in the flagged-port list — US8, US8P60, USC8, US16P150, USL8LP, USF5P, USMINI — reports the identical hardware capability mask, and it includes gigabit on every single port. There is no 100 Mbps-only switch or port in this fleet. So when a modern, gigabit-capable AP negotiates down to 100 Mbps, the switch on the other end was capable of better — that points at the cable, connector, or patch panel in between, not the hardware.

PoE is a mixed answer — some of it is the switch by design, the rest is a real fault. Two switch models in this fleet structurally can't deliver PoE to some or all ports, confirmed against Ubiquiti's own published specs:

• USW-Flex-Mini (shows as USMINI) — zero PoE output on any port by design; it only accepts PoE to power itself. Every AP hanging off a Flex Mini that needs PoE was never going to get it there, regardless of cable condition — that's a switch-selection issue (wrong switch for a PoE device), not a cable fault.
• USW-Lite-8-PoE (shows as USL8LP / USLP8P / USL8LPB) — only 4 of its 8 ports carry PoE by design. The controller's own per-port data confirms this split cleanly: on Switch V9 new and Senior staff specifically, some ports report no PoE wiring at all (port_poe: false) while others on the same physical switch report it fine — that's the model's fixed 4-of-8 layout, not inconsistent hardware.

Filtering those two cases out, 6 ports are on hardware that is proven PoE-capable and still failed negotiation — these are the real faults: Switch V4 port 6, Switch V2 port 7, Switch V14 new port 2, Switch Reception port 3, and Senior staff ports 3 and 4. Since the port itself is confirmed capable, the likely causes are a marginal cable (voltage drop under load), a switch-wide PoE budget being exceeded, or a failing power delivery negotiation at the AP — worth a cable swap first, since that's the cheapest test.

24 access points are gigabit-capable models currently wired at 100 Mbps or with failed PoE negotiation on their switch port (cross-referenced against §10, filtered to each AP's current connection — historical/stale port records were excluded). A guest standing under one of these will correctly report "bad Wi-Fi," but the fix is a cable or port, not the radio. A further 15 APs show the same 100 Mbps pattern on legacy 100 Mbps-only hardware (BZ2LR, BZ2, U2Lv2) — that's expected for those models and not a fault. §10 confirms this isn't a switch limitation either: every switch model in this fleet supports gigabit on every port, so all 24 speed shortfalls are cabling, not hardware. Of the 6 PoE failures in this list, all are on ports independently confirmed PoE-capable — genuine faults, not a switch-design limit.

Only two ping passes were run against the APs (versus four for switches), so treat this as a first read rather than a confirmed pattern. Middlestaff - Outdoor (new) (192.168.1.58) showed mild, consistent jitter on both passes (~2.4ms mdev) — worth a second look but not severe. Battery house (192.168.1.227) spiked hard on one pass (35ms max) and was clean on the other — more likely a shared-cause echo from elsewhere on the network (§07) than a fault local to that AP. Every other reachable AP held sub-millisecond, consistent latency on both passes.