Session 23 was dated 2026-09-01, and it's the session where the SG300-10 finally did something. It had been bought for the Network+ / SOC learning track and then left undeployed. This session put it in the path, built two VLANs, and proved isolation actually works. The parts worth keeping are the middle ones — a command I got wrong from memory, a test that would have lied to me, and one change I refused on purpose.
Getting in: a legacy switch meets a modern SSH client
The laptop's OpenSSH refused to connect at all — no matching key exchange method
found. The switch only offers the SHA1-based Diffie-Hellman key exchange methods, and
modern OpenSSH disables those by default because SHA1 is broken. That is not a
misconfiguration on either side; it's a fifteen-year gap in security defaults showing
up as a connection failure.
The way in is to add the old algorithms rather than replace the default list, which is
what the + prefix on an option means. I first did it as a one-off command line, then
made it permanent in the SSH client config as a single Host block.
Scoping matters more than the flags. A global key-exchange setting would re-enable SHA1
key exchange for every SSH connection from that laptop, including hosts reachable from
the internet. The Host block keeps the weakening on one LAN-only device that nothing
from outside can reach.
Two smaller notes from getting in: the vendor default account at the highest privilege
level was what actually authenticated, and custom users created in the GUI didn't work
until the password was saved to the startup config. Also, enable is unnecessary when
the prompt already ends in #.
The save command that isn't write memory
I pasted a config block and it failed, because write memory is invalid on this
switch's image. It's the save command burned into muscle memory from mainline IOS
material, and on this hardware it simply doesn't exist. Worse, the mid-paste output
showed Cold Startup, meaning an unsaved reboot was a real risk.
What works here is copy running-config startup-config, confirming Y at the
overwrite prompt.
Lesson: one vendor name is not one command set. Same name on the front of the box, different image underneath, and a command that tutorials treat as universal can just be absent. Verify the save command on the actual hardware before assuming a config survived.
The VLANs that stuck
In short: enter the VLAN database, define VLAN 10 and VLAN 20, set a hostname, enable
the SSH server, then put two ports into access mode — gi2 in VLAN 10, gi3 in VLAN 20.
The resulting layout: gi1 stays a VLAN 1 access port and stays the uplink to the
router; gi2 is VLAN 10 and reserved for the Proxmox node, not moved yet; gi3 is
VLAN 20, the isolated lab; gi4 through gi10 stay VLAN 1 as spares and management.
switchport mode access means the port carries exactly one untagged VLAN, which is the
right mode for an end device — a laptop, a server. A trunk is the other mode:
multiple tagged VLANs carrying traffic to another switch or router, which is what the
uplink will need later.
One small thing worth remembering: the clock was set by hand, and it reports UTC regardless of what I intended, with no NTP configured. Fine for now, but it matters when correlating switch logs against anything else.
Proving isolation, with the other path shut off
The test: turn WiFi off first, plug the laptop into the VLAN 20 port only, check the interfaces, then ping the gateway.
The Ethernet interface sat looking for an IP and never got one. That is a pass, not a failure. VLAN 20 has no DHCP server — the router only serves the flat VLAN 1 subnet, and nothing bridges the two VLANs.
WiFi off is the part that isn't optional. With WiFi still up, the laptop stays reachable over VLAN 1 the whole time, so a successful ping would prove nothing about the copper path; the test would pass while measuring the wrong thing. Same category of mistake as verifying a service with "systemctl says running". Confirm you are testing the path you think you are testing.
The step I said no to
With two VLANs defined, giving VLAN 20 a gateway so it could route looked like the
obvious next move. I went as far as entering the VLAN interface and adding an address,
and the switch answered: Would you like to apply this new configuration? (Y/N)[N].
I answered N, and that was the right call. This switch is working as a Layer 2 device with exactly one management interface. Assigning an IP to VLAN 20 would not add a second address — it would move management onto VLAN 20, and the admin laptop is on VLAN 1. That is an instant lockout, recoverable only at the console, physically.
I confirmed the safe state afterward: management interface still on its original VLAN,
DHCP lease still valid. The lesson worth the whole session: a confirmation prompt that
defaults to [N] is often the hardware warning you about exactly this. Read what the
change does to the path you are connected over before accepting it.
What's next, and why it's its own session
Making VLANs 10 and 20 actually routable runs through the router, not the switch: trunk the uplink port and serve DHCP for both VLANs from the router. High lockout risk, because it changes the link everything currently depends on.
Rules I set for that session while it's fresh:
- Back up the router config first.
- Do not move the Proxmox node onto its VLAN port while the router is still flat. It would land on a VLAN with no DHCP and no gateway, which takes both VMs off the network.
One more thing this session taught me, at my own expense: the switch sat undeployed until now, and the actual VLAN work took a single evening. 802.1Q, access versus trunk, L2 versus L3, management-plane risk — that is all directly Network+ material, which is what I bought the thing for. Deploy the thing you bought.
If one line survives from this session, it's the pair of near-misses: check which path you are actually testing, and check what the change actually does to the path you are on. Turn WiFi off before you call a VLAN isolated; read the prompt before you accept it.