VLAN probe
The VLAN probe tells you whether a VLAN is actually reachable over the air at a venue — even when no WLAN carries that VLAN yet. For each VLAN you name, it puts up a temporary SSID on that VLAN, has RUCKUS Service Guard run a virtual client from every online AP (associate, take a DHCP lease, ping the gateway), reports a verdict per VLAN with a per-AP breakdown, and then removes everything it created.
What question does it answer?
Section titled “What question does it answer?”Wireless VLAN reachability where no WLAN exists to test with. It is not general “VLAN validation”, and the difference matters:
| Tool | What it tests | From where |
|---|---|---|
| R1 Service Validation → Wired tab | VLANs | Switches |
| R1 Service Validation wireless test | An existing WLAN | APs |
| VLAN probe | A VLAN with no WLAN on it | APs, over a temporary SSID |
A VLAN that no WLAN carries cannot be tested over wireless natively at all. That gap is what this feature fills. If a VLAN already has a WLAN, R1’s own wireless test covers it; if you want the switch view, use the Wired tab.
How do I turn it on?
Section titled “How do I turn it on?”VLAN probe is an Early Access feature: unlock Early Access with the password, then turn on VLAN Probe in the Early Access card of the dashboard.
It is Early Access on purpose. The feature is new, and because a run broadcasts at a live site, the password is a deliberate speed bump before anyone can start one.
Where do I run it?
Section titled “Where do I run it?”From the r1-mcp companion extension, not from Claude. The extension’s card runs the preflight, starts the run and shows its progress. The run itself is driven by the R1-MCP server, so teardown doesn’t depend on your browser tab staying open.
What happens during a run?
Section titled “What happens during a run?”For each VLAN row — a venue, a VLAN id and the gateway IP to ping — the run works through the same steps, in order:
- Create a WLAN — WPA2-PSK, carrying the row’s VLAN.
- Activate it on the venue. This is the moment the SSID goes on the air from every AP of the venue.
- Create a Service Guard spec, scoped to the venue’s online APs, with a virtual client that associates, takes a DHCP lease and pings the row’s gateway.
- Run it and poll the results.
- Tear down — delete the spec, deactivate the WLAN, delete the WLAN.
Reaching the run’s deadline, or aborting it, goes straight to the same teardown. There is no way to stop a run that leaves the SSID up.
Why it takes minutes. Service Guard can take up to 3 minutes before a new test is visible at all. An AP runs only one virtual-client test at a time, so rows are run in rounds whose AP sets don’t overlap. All rows’ WLANs exist at the same time. A handful of VLANs at one venue takes several minutes, not seconds.
Before a run: the preflight
Section titled “Before a run: the preflight”The extension calls a preflight first, and the preflight writes nothing, so re-running it costs nothing. It reports the names the run would create, a time estimate, SSID capacity, what your connection’s credential looks like, warnings, and blockers.
| Blocker | Why it stops the run |
|---|---|
venue_not_found | The connection can’t see a venue with that id |
venue_name_ambiguous | Another venue in the tenant has the same name. The test is scoped by venue name, so it could test the wrong one |
venue_check_unavailable | The venue list couldn’t be read, so uniqueness is unknown |
aps_unreadable | The venue’s AP list couldn’t be read |
no_eligible_aps | No AP is online with a MAC to scope a test to — a run would broadcast and answer nothing |
A confirmation token is issued only when there are no blockers, and it is valid for 10 minutes. A read-only credential produces a warning, not a blocker. Sending the same token twice doesn’t start a second run.
The deadline
Section titled “The deadline”Every run has a deadline, and reaching it tears the run down:
| Rule | Value |
|---|---|
| Deadline | Three times the preflight estimate |
| Never less than | 15 minutes |
| Never more than | 60 minutes |
A run stopped by its deadline ends interrupted, never failed — its VLANs
were not answered, which is not the same as failing. An abort is a teardown too:
the run shows aborted once the teardown has actually run, not when you ask.
Reading the result
Section titled “Reading the result”One verdict per VLAN. Four of the five are ways of not being a failure — don’t read them as one.
| Verdict | Means |
|---|---|
pass | A client associated, got a lease on the VLAN, and pinged the gateway cleanly |
partial | The VLAN answered — a lease and some replies — but not everywhere or not cleanly. Not a failure |
fail | A stage genuinely failed, or every ping was lost |
inconclusive | The VLAN was never answered, for a known reason — for example every scoped AP was offline, the test never became visible, or the run was aborted. Nothing is claimed about the VLAN |
errored | Something broke, or a retry the run owed never ran. Not a statement about the VLAN |
Each verdict comes with per-AP outcomes: pass, partial-ping, fail,
did-not-run, transient and rerun-alone. did-not-run is an offline AP,
never a failure. transient and rerun-alone describe the test — for
example two tests colliding on one AP — not the VLAN.
Every run also reports onAir: how many of its objects may still be on the
air, read from the run’s own record of what it created. On any run that didn’t
finish cleanly, read that first. A teardown that didn’t complete doesn’t fail the
run, but it is named in the run’s error, because something is still broadcasting.
Finding anything left behind
Section titled “Finding anything left behind”The names are the recovery mechanism. Everything a run creates carries its run id:
| Object | Name |
|---|---|
| WLAN name and SSID | R1PP-VLAN<vlan>-<runId> |
| Service Guard spec | R1PP-<runId>-v<vlan> |
The extension’s leftovers scan sorts every R1PP- object into four groups:
yours from a finished run, yours from a run that is still live, not created
by this feature, and unattributable. Cleanup takes named ids only — there is
no wildcard delete in any form — and it always refuses to delete an object
from a run that is still live, with no override. Objects the feature didn’t
create are removed only if you explicitly acknowledge them.
From Claude, the vlan_probe_strays prompt sweeps a tenant for R1PP-
WLANs, and Service Guard specs too if you also have the
GraphQL feature on, decodes which run each came
from, and reports what is still on the air. It is read-only by default:
Claude can’t see the run records, so it can’t tell an abandoned object from one
belonging to a run in progress, and it tells you to remove strays with the
extension’s cleanup. If you ask Claude to delete one directly instead, it first
confirms the specific object with you and checks its run is not one you still
have open.
Claude can also fetch the vlan-probe reference guide with get_reference
to explain verdicts, per-AP outcomes and preflight results in depth.
Limits
Section titled “Limits”| Limit | Value |
|---|---|
| VLANs per run | 15 — every row’s WLAN exists at the same time, and R1 documents 15 WLANs per AP (7 on the R310) |
| VLAN ids | 1–4094 |
| Confirmation token | 10 minutes after the preflight |
| Cleanup request | Up to 50 named ids |
| Run records | 30 days after the run ends, and kept longer while anything it created is not yet deleted |
The WLAN ceiling is a documented firmware figure, not a limit the API enforces, so the preflight counts against it and says so. All limits are on the limits page.