Network

/network. Needs module.network.

The network estate the school already owns: access points, switches, gateways, firewalls and controllers, read from the vendors’ own APIs and shown in one place.

It is not a replacement for the Meraki dashboard or the UniFi console. Those are better network consoles than this will ever be. What they cannot do is know about your tickets, your campuses and your device fleet, and that join is the reason this pane exists.

It merges vendors rather than picking one

Every other connector category resolves one provider: one MDM, one ticketing system, one printing system. This one fans out across every enabled network connector and merges what comes back.

That is deliberate. The ordinary school runs Meraki wireless and a rack of Cisco or Aruba switches and something else again on the filter. Resolving one would show the wireless, drop every switch in the building, and look complete while doing it.

What the pane shows

Vendor networks	A Meraki network, a UniFi site, a group of SNMP devices, each with the campus it is mapped to
Devices	Grouped under their network: access point, switch, gateway, firewall, controller
Status	Up, down or unknown, with the age of the reading beside it
Model and firmware	As the vendor reports them
Management address	The device’s own IP and MAC
WAN uplinks	Shown on the gateway that terminates them, with interface, latency and loss
Ports and PoE	Ports up against ports fitted, and watts drawn, where the vendor reports them
Clients and uptime	How many are associated, and how long it has been up
Which connector said so	Every row names its source

A status is never shown without the age of the reading it came from. A green dot with no timestamp is a status somebody acts on hours late.

“Unknown” is not “down”. Where a vendor does not report a status, or reports a word we do not recognise, the device reads as unknown. Mapping the unrecognised case to down would take a whole school red the first time a vendor added a value to its own status vocabulary.

Refreshing

The estate is polled in the background. Refresh from every connector on the pane does it now, and needs network.manage.

That button is rate-limited far below the rest of the product, and the reason is worth knowing: a refresh spends your vendor API budget on your key. Meraki allows ten requests a second per organisation and shares that allowance with every other application touching the same organisation. A held-down refresh walks you out of your own dashboard, and the vendor’s rate limit lands on you rather than on us. The background sweep already polls without being asked.

Mapping a vendor network to a campus

Each vendor network can be pointed at one of your campuses, and that needs network.manage.

It is a pointer an administrator sets, not a name match. A school calls its Meraki network TSC-Senior and its campus Senior School, and guessing between them wrongly is worse than not guessing: this mapping is what confines a campus-scoped technician to their own campus, so a bad guess shows somebody a building they were scoped away from.

An unmapped network is visible to unscoped users only, which is the right answer for gear nobody has placed yet. Every change to a mapping is recorded in the audit log, as is every refresh.

It rides your existing alerting

A network device does not start a second alerting system. Where monitors is also on, every network device gets a monitor of its own, so a switch going down produces the same event, the same severity tag, the same throttling and the same status page entry as everything else you already watch.

Network sells one tier lower than monitors, so a school can have this pane and no monitor board. With module.monitors off the pane still shows status and still drives ticket correlation. There is simply nowhere for an alert to go, and inventing somewhere would be worse than not alerting.

Tickets find the gear on their own

Network device names join the ticket signals panel, with the campus name as an alias. A ticket saying “the Senior School wifi keeps dropping” therefore surfaces the access points on that campus, matched on the words rather than guessed at by a model.

Permissions, and why they are not monitor.*

Permission	Allows
network.view	See the estate
network.manage	Map a network to a campus, and refresh on demand
network.clients.view	See where a device was last seen. Read the section below first

Its own keys, on purpose. A monitor is a service the school chose to watch, and usually chose to publish. This is a map of the management addresses, firmware versions and layout of the network the school runs on, and that map is a reconnaissance package. Whoever gets handed the uptime board should not thereby be handed it.

The same argument runs the other way round from the printers page: a read-only SNMP string on a printer reads toner levels, and the same string on a core switch reads the shape of your network.

Client sightings

Optional, off, and the part of this module to read properly before switching on.

With it on, the sync also records where each MAC address was last seen: which access point or switch port, on which SSID, at what time. The device page can then answer “where was this laptop last seen”.

That is genuinely useful for a laptop that went missing over a weekend. It is also location data about children, so it is built to be the smallest thing that answers that question:

• Off by default. Nothing is recorded until an administrator turns it on, and the connectors are not even asked for clients while it is off, because a poll that fetches location data and then discards it has still fetched it.
• One row per device, not a history. Each sighting is updated in place. The data answers “where is it now”, and cannot be made to answer “where has this child been all term”.
• Seven days, capped at ninety. The window is yours to set between one and ninety days. There is no “keep forever” and there will not be one. Expiry runs on its own timer, so disabling the connector does not leave the rows behind.
• Never exposed to a portal. No student, parent or public surface reads it.
• Keyed on a MAC, never on a person. There is no query in the product that takes a person and returns places. The join runs the other way: from a device the school owns, on that device’s page.
• Its own permission. network.clients.view, granted deliberately rather than arriving with the estate map or the device list.
• Included in a subject access export, and removed by an erasure request. See data processing.

Before you turn it on

Ask who at your school gets to see it, what you would use it for, and whether that is written down somewhere a parent could be shown. The seven-day default exists because it is long enough to find a laptop left in a hall over a weekend and too short to reconstruct somebody’s week.

Then: Admin, Security, Record where devices were last seen on the network, and set the window beside it.

Not every connector can do this. Meraki and a local UniFi console report clients; the UniFi Site Manager cloud API does not expose them, and the SNMP connector deliberately does not claim to. A vendor that cannot answer is reported as not supported rather than as “nothing found”. The two must not look the same.

Getting the estate in

Three connectors feed this pane:

• Cisco Meraki. Cloud API, no agent needed.
• UniFi. The local console, or the Site Manager cloud.
• Network hardware over SNMP. Cisco, Aruba, HPE, Extreme, Fortinet and anything else that answers.

They share one connector slot between them, because a school running Meraki wireless and SNMP switches has one network, not two integrations.

Most of this gear answers on management addresses on your own LAN. A self-hosted install reaches it directly; a managed deployment needs a connector agent on your network. Each connector page says which.