Why buy a managed switch instead of a UPS or more storage?

Because it was the purchase that most directly served a Network+ / SOC-analyst learning track. A UPS, another drive, or a second compute node would all have been useful, but none of them give hands-on practice with VLANs, 802.1Q and segmentation the way a managed switch does.

Why does `write memory` not work on this switch?

The firmware image running on this unit does not support it. Configuration is saved with `copy running-config startup-config` instead. That is a statement about this image, not about every SG300 or every firmware version.

Why is assigning an IP to a second VLAN a lockout risk?

In Layer 2 mode the switch has exactly one management interface. Giving an address to another VLAN moves management to that VLAN rather than adding a second way in, so the path you were using disappears. The confirmation prompt defaults to no for that reason.

Why re-enable SHA1 key exchange for SSH, and is that safe?

Modern OpenSSH refuses the connection by default because the switch only offers SHA1-based key exchange, giving a `no matching key exchange method found` error. The workaround is a per-host client config block re-enabling the legacy key exchange, host-key, public-key and cipher algorithms. SHA1 is weak, so the block is scoped to this one host: acceptable because the device is LAN-only and unreachable from the internet, and never to be reused for an internet-facing box.

Why must WiFi be off during the VLAN isolation test?

Otherwise the laptop stays reachable over the old wireless path and the test silently lies. With WiFi disabled (`nmcli radio wifi off`), a laptop on the isolated port never obtained an address, which is the passing result.

SG300-10: one management interface, and other ways to lock yourself out

The candidates were a UPS, more storage, or a second compute node. What I bought instead, in late August 2026, was a used SG300-10 managed switch for about thirty dollars — an SRW2008-K9, hardware revision V02.

The reasoning is the part worth writing down. Any of the other three would have been useful. The switch was the one purchase that directly served the Network+ / SOC-analyst track I'm working through: hands-on VLANs, 802.1Q, segmentation. That's the trade I made, and it's the one I'd make again.

What it actually is

Ten gigabit ports, gi1 through gi10. I'm running it as a Layer 2 managed switch. The SG300 line does support Layer 3 mode — I just haven't enabled it here, and that distinction matters later. Management is by web GUI or SSH/CLI.

First surprise, and a small one: the firmware image on this unit does not support write memory. You save with copy running-config startup-config. That's a fact about this image, not a claim about every SG300 out there, and it's the kind of thing that only bites until you've written it down.

One way in, and only one

This is the item I'd put at the top if I could only keep one line from the whole file.

In Layer 2 mode this switch has exactly one management interface. It takes its management address by DHCP on VLAN 1, from the travel router upstream. The instinct, once you have VLANs, is to give management an address on another VLAN too — a second way in, belt and braces.

That's not what happens. Assigning an IP to another VLAN moves management there. It doesn't add a path, it relocates the only one you have. So the belt-and-braces move is actually the lockout move.

The switch does ask before it commits: it prompts to apply the new configuration, and the prompt defaults to [N]. Typing Y at that prompt while adding an IP to a non-management VLAN is an instant lockout. That default is not the interface being timid. It's the interface knowing something about the shape of this mistake.

It's in the notes as a trap, not as a story. I'd like to keep it that way.

Getting SSH to connect at all

Modern OpenSSH won't talk to this switch out of the box. It only offers SHA1-based key exchange, so you get no matching key exchange method found and nothing else.

The fix is a client-side config block on the Mint laptop that re-enables the legacy algorithms — key exchange, host key, public key, ciphers:

# example — address and account lines omitted
Host <alias>
    KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa
    Ciphers +aes128-cbc,3des-cbc,aes256-cbc

The important word is Host. This is scoped to one target. The weakened crypto never applies to anything else I connect to, and that scoping is the entire reason it's acceptable.

Because it isn't fine in general. SHA1 is weak. I'm choosing to accept that here for one specific reason: this device is LAN-only and unreachable from the internet. The moment that reasoning gets copied to an internet-facing host, it stops being a workaround and starts being a vulnerability. Never reuse the block for the VPS — that's written in the notes in bold, which tells you what I thought the failure mode was.

The other management detail worth keeping: the vendor's default administrative account runs at privilege level 15, and custom users created through the GUI don't work until the password has been saved to startup-config. Which loops right back to copy running-config startup-config. Also: enable is unnecessary when the prompt already ends in #.

Three VLANs, one of which is supposed to be lonely

VLAN 1 — default and management, DHCP from the router.
VLAN 10 — production. gi2 is assigned to it and reserved for the Proxmox node. Nothing is plugged in yet.
VLAN 20 — lab. No DHCP, no gateway. That's deliberate.

Port map as it stands: gi1 is the uplink on VLAN 1 and stays that way; gi2 is the reserved VLAN 10 port; gi3 is VLAN 20 for isolated lab use; gi4–gi10 are VLAN 1 spare and management.

I verified VLAN 20 isolation on 2026-09-01 by putting a laptop on gi3 and confirming it never obtained an address. That's the passing result — nothing happening is the whole point.

But the methodology note is the thing that generalises. You have to turn WiFi off first (nmcli radio wifi off). If you don't, the laptop is still reachable over the old wireless path, and the test silently lies to you — it looks like it passed, and you've verified nothing. That failure mode isn't specific to VLANs. Any isolation test where the machine under test has a second route to the world can tell you a comfortable falsehood. Kill the other path or don't bother running it.

The order matters more than the tasks

Three things are still open, and the file records them in a specific order for a specific reason:

Configure an 802.1Q trunk on gi1 up to the router. Flagged high lockout risk — back up the router config first.
Serve DHCP for VLANs 10 and 20 from the router, because the switch is Layer 2 here and can't route or serve DHCP itself in this configuration.
Only after both of those, move the Proxmox node to gi2 on VLAN 10.

Do step three first and the Proxmox host lands on a VLAN with no DHCP and no gateway. Stranded, and both VMs go offline with it. That node is still on the flat network, not on gi2, and that's the correct place for it until the two steps above are done.

There's a fourth open item, smaller: NTP. The clock is set manually and reports UTC, but nothing keeps it honest. Configuring NTP would let switch timestamps correlate with logs from everything else, which is most of the reason to care about a switch clock at all.

Small things, written down so they stay written down

A mid-paste Cold Startup message means a reboot risk with unsaved config.
Don't paste a whole config block while already inside (config) mode.
clock set takes its arguments literally. It wants an actual time and date, not a placeholder format string.

None of these are interesting. All of them are the kind of thing that costs time until it's written down.

The topology, for the record: building-provided shared WiFi upstream, into a GL.iNet Beryl AX acting as a repeater with WiFi-as-WAN, into the switch. Modest. But it has VLANs in it, and one of them has been verified genuinely alone.