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 and Services monitor are separate modules, 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, refresh on demand, and record subnets and reservations by hand
network.clients.view	See where a device was last seen. Read the section below first
network.config.view	Read stored configuration snapshots and compare versions. See configuration

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.

IP addresses

From 0.21.0, the IP addresses tab lists the school’s IPv4 subnets, what is using each address, and where two things disagree. It needs network.view, and it works with no network connector at all: a school that keeps its address plan in a spreadsheet can record subnets here by hand.

Source	What it adds
Cisco Meraki	Appliance VLANs (or the single LAN) and layer 3 switch interfaces, with VLAN ID and gateway
UniFi, local console	The console’s networks, with VLAN ID and gateway. Needs UniFi Network 10 or later; on 9.x the connector reports an error rather than an empty list
SNMP	Interface addresses and masks from IP-MIB. No VLAN ID or gateway, because the MIB does not say which address is a gateway
Recorded by hand	A subnet, with an optional VLAN, gateway and campus, for anything no connector sees

The UniFi Site Manager cloud connector does not report subnets. IPv6 is not shown.

Each subnet shows how many of its usable addresses are in use: network equipment management addresses, gateways and reservations. Client addresses are included only when client sightings are switched on and you hold network.clients.view, and only for devices seen in the last 30 minutes. Otherwise the tab says which of the two is missing, and utilisation counts equipment, gateways and reservations only. A DHCP pool hands the same address to many laptops over a week, so older sightings would only produce false conflicts.

Reservations and conflicts

A reservation records that an address belongs to something: Library printer, optionally with its MAC. Recording and releasing reservations, and recording or removing a subnet by hand, need network.manage and are recorded in the audit log. Reservations in your DHCP server stay in the vendor’s configuration; they are not imported as editable reservations here.

Address conflicts lists three problems:

Problem	Means
Same address, two devices	One address currently seen with two or more MACs
Reserved for another device	A reservation names a MAC, and a different one is using the address
Reserved address in use	A reservation with no MAC, and something is at that address, gateway included. Add the MAC to the reservation to clear it

Conflicts are worked out within each subnet, never across them. Two campuses behind separate routers can both run 192.168.1.0/24, and that is normal. Addresses no known subnet contains are listed separately; recording the subnet puts them in it.

Configuration

From 0.21.0, the Configuration tab keeps a read-only history of network configuration. It needs network.config.view, and the tab does not appear without it.

Connector	What is captured
Cisco Meraki	Per network: appliance VLANs, layer 3 firewall rules and wireless SSIDs, for the product types the network has. Per switch: its port settings
UniFi, local console	Per site: networks and wireless broadcasts. Site level only
SNMP	Nothing. Copying configuration off a switch needs a write community and a TFTP server, which Plugboard deliberately does not hold

The UniFi Site Manager cloud connector does not capture configuration.

Snapshots use only the key each connector already holds. Plugboard asks for no SSH, TFTP or enable credentials, and never pushes, restores or exports a configuration. This is a record of what changed, not a configuration backup you can restore from. Keep your vendor’s own backup for that.

Secrets are never stored. Passwords, pre-shared keys, RADIUS secrets, SNMP communities, API keys, tokens, private keys, credentials in URLs and webhook URLs are replaced with [redacted] in the connector, and again before Plugboard stores anything. The rule fails closed: a field whose name looks like a secret is hidden even if it is not one, so some harmless settings, such as a session timeout or a licence key, also read as redacted. That costs a line in a comparison; the opposite mistake would put a Wi-Fi password in every version. Because redaction happens first, changing only a secret, such as rotating a Wi-Fi password, does not create a new version and does not appear in a comparison.

Versions and comparing them

Configuration is read on an hourly inventory pass, separate from the five-minute estate sweep. A version is stored only when the redacted configuration differs from the last one; otherwise the existing version’s last confirmed unchanged time moves on. Thirty versions are kept for each network or switch, and a configuration larger than 512 KB is refused and shown as that connector’s error.

Choose a network or switch to see its versions. View opens one, and Changes from previous lists each setting added, removed or changed, matching list entries such as SSIDs and ports by their number or name so one inserted firewall rule does not show every later rule as changed.

Opening a version and comparing two are both recorded in the audit log. Refresh subnets and configuration, on the IP addresses tab, runs the inventory pass now; it needs network.manage, is limited to twice a minute, and is audited.

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.