Switch Management

PrivateLAN gives you a central place to register your network switches, organize them into groups, and keep track of their status — without logging into each switch individually.

Supported switches

The following switch platforms are currently supported:

• Cisco IOS
• Aruba OS
• Aruba OS-CX

Adding a switch

When you add a switch, you provide the following information:

The number of switches you can add is limited by your license.

Password or SSH key

PrivateLAN can log in to a switch in two ways, selected per switch with the Authentication field:

• Password — the username and password you fill in on the switch's page.
• SSH key — an SSH private key you paste on the switch's page, optionally protected by a passphrase.

For SSH key authentication, paste the private key (PEM or OpenSSH format; RSA, ECDSA and Ed25519 are all supported) together with its passphrase, if it has one. PrivateLAN checks that the key can be read before saving it, so a wrong passphrase or a damaged key is reported immediately instead of failing later on the switch.

After saving, the matching public key is shown on the same page. Install that public key on the switch for the username you configured — that is what allows PrivateLAN to log in without a password. The private key itself is never shown again.

An enable password can still be filled in alongside an SSH key: on platforms that ask for one, it is used after the SSH session is established.

All switch credentials — passwords, enable passwords, SSH keys and their passphrases — are stored encrypted, and are never displayed back after saving.

Switch groups

Switches are organized into switch groups (for example "Data Center" or "Floor 3"). Groups make it easier to manage many switches at once: VLANs and other settings can be applied to an entire group instead of switch by switch.

Interfaces (ports)

Each switch's interfaces (ports) can be tagged to describe what they are used for:

• [P0] … [P8] — highest PoE class the port can supply; leave the tag off when it supplies no PoE
• [ND] — Not used for end devices
• [SERVICE] — Service port for temporary maintenance access (see below)
• [TRUNK] — Trunk port (carries multiple VLANs)
• [SFP] — Fiber/SFP uplink port
• [LAGx] — Link aggregation group member

These tags help PrivateLAN apply the correct VLAN configuration automatically.

PoE class

A [P0] to [P8] tag records the highest IEEE PoE class the port can supply. A port with no such tag supplies no PoE at all.

The tag configures nothing on the switch. It is compared against the PoE class of a device group: an interface can only be assigned to a device when it can supply at least the class that device's group requires, and a port that cannot is shown in red on the device page and refused. The PoE configuration a port actually receives still comes from the device group's configuration templates, so an explicit power inline never for, say, a server on a PoE-capable port stays authoritative.

Because an untagged port counts as "no PoE", a device group only starts checking once you give it a PoE class — new and existing groups require none by default. See Device Management.

[TRUNK] marks an uplink to another switch: such a port is configured by hand, cannot be assigned to a device, is never programmed from a device template, and the configuration compliance check leaves it alone. A device port that has to be an 802.1Q trunk — a hypervisor carrying virtual devices in several VLANs — is not tagged [TRUNK]. It stays a device port, and its device group is put in Trunk port mode so that its templates configure the trunk; see Device Management.

Service ports

A service port gives an engineer temporary access to the network during maintenance, without having to configure a switch port by hand every time — and without that port staying open afterwards.

Tag an interface with [SERVICE] to turn it into a service port. Such a port is always a non-device port, so no device can be assigned to it.

Under Switches > Service every service port is listed with its current link status, and can be activated for a fixed session of 4, 8, 12 or 24 hours in a VLAN of your choice. Only VLANs that are available on that port's own switch are offered. When the session expires the port is shut down automatically; you can also close it earlier with Disable.

The configuration applied to a port at activation is set once under Switches > Service, and applies to every service port. A working default for all supported switch types is supplied, so the feature can be used straight away; adjust it where your network needs something different. A single port can also be given its own configuration if one switch differs from the rest. Removing the [SERVICE] tag from a port also removes that configuration, and closes the port if a session was still running.

While a service port is open it is listed on the Inspection page, and the dashboard shows a Service ports open tile with how many are open and when the first one closes — so a port left open is never invisible.

Activating, closing and reconfiguring a service port is recorded in the audit log, including who did it. Two separate permissions control the feature: one to view the page, and one to actually open and close ports.

Switch stacks

When several physical switches are stacked together (for example, via stacking cables on Cisco, or VSF on Aruba OS-CX), the stack behaves as a single logical switch on the network. Add the stack as one switch entry, using the stack's shared management IP address.

PrivateLAN automatically detects when a switch is part of a stack and marks it with an icon in the switch overview. The individual physical members are shown underneath the stack, each with their own model, serial number, firmware, uptime, CPU load, temperature and PoE usage.

When entering interfaces, specify each member's ports with its unit number, for example: Gi1/0/1-24, Gi2/0/1-24, Gi3/0/1-24.

Keeping switches up to date

• Program VLAN — pushes the current VLAN configuration to a switch
• Reload switch — re-applies the switch's configuration

Remote SSH

Not everything is a VLAN change. Sometimes you need the switch's own command line: a show that PrivateLAN does not display anywhere, a one-off setting, or a write memory after a maintenance window. Switches > Remote SSH gives you that command line from inside PrivateLAN, so you do not have to open a separate SSH session to every switch. The SSH icon in the switch overview opens the same page with that switch already selected.

What you type is sent to the switch unchanged. PrivateLAN does not check, complete or correct it, and a configuration command takes effect the moment it is sent — exactly as if you were typing it on the switch yourself. What you can do is decided by the account the switch grants PrivateLAN, no more and no less.

Selecting several switches sends them all the same commands, one switch after the other. That is what makes this useful beyond a single session: the same show across a whole switch group to compare the answers, or a write memory on every switch you just changed. A switch that is not answering, or that PrivateLAN cannot log in to, is greyed out in the list and cannot be selected.

Per run you can address up to 25 switches with up to 50 commands. Raise the timeout for a command that returns a lot of output, such as a full configuration or the MAC address table of a busy switch.

Reading the result

Each switch gets its own block below the form, showing every command with the switch's answer underneath it, as a terminal transcript. Copy puts that switch's complete transcript on the clipboard, ready to paste into a ticket or a message.

If a switch stops answering, the remaining commands for that switch are not sent — after a timeout the session is left at an unknown point in the switch's command line, so sending the rest blindly would be worse than stopping. The run continues with the next switch, and the failed command is marked in the transcript.

A run also has an overall limit on time and on the amount of output it collects. When one of those is reached the run stops and names the switches it did not get to, so you know exactly what to repeat in a second run.

Who may use it, and what is recorded

Remote SSH is controlled by its own permission, separate from being allowed to edit a switch, and only an administrator can grant it — it hands out everything the switch account can do, past every check the rest of PrivateLAN applies.

Every run is recorded in the audit log per switch: who sent it, to which switch, and which commands. It is recorded as a warning rather than an ordinary change so that it stands out, and if you forward security events to your own syslog collector, these entries are forwarded along with them. What the switch sent back is deliberately not logged: a configuration output contains community strings, keys and password hashes, and the audit log is the wrong place to keep a second copy of those.

Configuration versioning

PrivateLAN reads each switch's running configuration every few minutes anyway, as part of its regular polling. Switches > Versioning puts that reading to a second use: each time the configuration read from a switch differs from the one stored before it, the new one is kept as a version. The last ten versions of every switch are kept, and the oldest is dropped as an eleventh arrives.

The page lists every switch that has at least one stored configuration, the switch whose configuration changed most recently at the top, with its hostname, address, type, model and serial number, how many versions are kept for it and when it last changed. Clicking a row opens that switch's configuration.

From the list itself you can also download the newest configuration of every switch at once, as a single ZIP archive — enough to keep a backup of the whole site outside the appliance.

Two things this deliberately does not do. PrivateLAN sees that a configuration changed, never who changed it: a change made on the switch's own command line leaves nothing behind that identifies the person who made it, so the page does not pretend otherwise. And a reading that is obviously incomplete — a connection that dropped halfway through printing — is discarded rather than stored. A half-read configuration that still looks like a configuration is worse than no version at all, because it would both report a change that never happened and push a good version out of the ten that are kept.

Lines that a switch prints differently on every read, such as a build banner or a "last changed" timestamp, are ignored when deciding whether the configuration changed. A changed password is not one of those: that is a real change, and it is kept.

Who may use it

A running configuration contains the credentials configured on the switch — community strings, RADIUS keys and password hashes. It is stored and shown exactly as the switch printed it, because a version with parts blanked out could not be used to restore a switch, which is the point of keeping it.

Viewing this page therefore has its own permission, separate from being allowed to edit a switch, and only an administrator can grant it. Nobody has it until you give it to them. Every download is recorded in the audit log: who downloaded which switch's configuration, and which version.

Status monitoring

For every switch, PrivateLAN shows live status information, including:

• Reachability (ping and SSH status)
• CPU load
• Temperature
• Uptime
• PoE power usage

For switch stacks, this information is also shown per physical stack member — see the "Switch stacks" section above.