Ping, traceroute and routing tables
Claude can test reachability from the devices themselves: ping or
traceroute from an AP with wifi.ap_ping and wifi.ap_traceroute, ping or
traceroute from an ICX switch with switches.ping and switches.traceroute,
and read a switch’s routing table with switches.routing_table. All five are
read-only, open to every role, and need no confirmation. Ask in plain language,
for example “ping our RADIUS server from the lobby AP” or “show the routing
table of the core switch”.
Targets must be IP addresses
Section titled “Targets must be IP addresses”SmartZone pings and traces to IP addresses only. A hostname is refused
before anything is sent, with bad_target, so resolve the name first or give
Claude the address. IPv4 and IPv6 addresses are both accepted.
How long does each take?
Section titled “How long does each take?”Each test runs on the device, so it takes seconds, and Claude runs one test
per code_mode call to stay inside the 30-second run budget.
| Function | Runs | Takes | Gives |
|---|---|---|---|
wifi.ap_ping({ apMac, target }) | 5 packets from the AP itself (GET /tool/ping), so it tests the AP’s own path, e.g. to its gateway, DHCP or RADIUS server | About 7 s, about 15 s when nothing answers | sent, received, lossPercent, rttMs { min, avg, max }, replies |
wifi.ap_traceroute({ apMac, target, timeoutSeconds? }) | Up to 30 hops from the AP (GET /tool/traceRoute). timeoutSeconds defaults to 15, at most 20 | 5 s for 11 hops to the internet in testing | hops: [{ hop, replies: [{ ip, ms }], timeouts }], reached |
switches.ping({ switchId | serialNumber, target }) | 5 packets from the switch’s management interface (POST /switch/troubleshooting/ping, the controller UI’s switch ping) | About 8 s | switch, sent, received, lossPercent, rttMs, replies |
switches.traceroute({ switchId | serialNumber, target }) | Up to 30 hops from the switch (POST /switch/troubleshooting/traceroute) | 5–8 s to the internet in testing | switch, hops: [{ hop, replies, name, timeouts }], reached |
switches.routing_table({ switchId | serialNumber }) | sh ip route on the switch (GET /switch/troubleshooting/routingtable/{serialNumber}) | About 6 s | switch, total, routes: [{ destination, gateway, port, cost, type, uptime }], defaultRoute |
switchId is the switch’s MAC. A route’s type is connected, static,
ospf, bgp or rip, and defaultRoute is the 0.0.0.0/0 route or null.
When the output can’t be parsed, the raw text comes back as raw.
In a traceroute, hops that time out (*) are normal for routers that don’t
answer; a trace that stops early marks where the path breaks. On a switch
traceroute, a reply of “<1 ms” counts as 0.5 ms.
Errors
Section titled “Errors”error | From | Meaning |
|---|---|---|
bad_target | all but routing_table | The target is not an IP address |
bad_mac | AP tests | apMac is not a MAC address |
no_answer | all but routing_table | The controller answered with an empty result. From an AP, that is what an offline AP gets: check the AP is online |
ping_failed, traceroute_failed, routing_table_failed | each test | The controller refused the request; status and detail say why |
bad_request | switch tests | Neither a valid switchId (a MAC) nor serialNumber was given |
unknown_switch | switch tests | No switch with that MAC or serial number on this controller |
switch_offline | switch tests | The switch is not ONLINE; the test runs on the switch itself |
no_ip | switches.ping, switches.traceroute | The switch has no management IP in SwitchM, and the test needs it as its source |
no_serial | switches.routing_table | The switch has no serial number in SwitchM |
switch_list_failed | switch tests | The controller’s switch list could not be read |