How to Set Up a Layer 2 Aggregation Switch in Your Home Lab

I bought a cheap 16-port 10Gb switch for a homelab test rig and used it purely as a layer 2 aggregation switch. It does not route, but it glues faster uplinks and racks of 1Gb kit together neatly. This guide shows the practical steps I took, the checks that matter, and the simple tests I run to confirm VLAN configuration and network performance in a home lab setup.

Getting Started with Your Switch

Choosing the Right Switch
Pick a switch that matches your needs, not your ego. For an aggregation role I want:

• 10Gb uplink ports or SFP+ cages.
• Enough ports to aggregate access switches or servers.
• A manageable power draw for my rack and decent airflow.
  If the box is layer 2 only, confirm that LACP (802.3ad) and VLAN tagging (802.1Q) are supported. Check the firmware and licence status before plugging it in. If you buy secondhand, check the health of the fans and PSU.

Essential Tools for Setup
Have these ready before you start:

• A laptop with a serial console adapter or SSH client.
• SFP+ modules and short DACs for test links.
• A spare 1Gb switch or a couple of servers for traffic tests.
• iperf3 on two endpoints for throughput checks.
• A screwdriver and cable labels.
  Label ports and document MAC addresses. I use simple numbered labels on patch leads and a short CSV with port roles.

Initial Configuration Steps
Follow these steps on the switch console. I write them as a checklist and tick them off as I go.

1. Basic access

   • Set a management IP on a dedicated VLAN or the native VLAN.
   • Change default credentials and configure SSH access.
   • Configure NTP and syslog to a local collector on the network.

2. Port basics

   • Set each port speed and duplex explicitly if the switch supports it.
   • Disable auto-negotiation only if you have a reason; mixed settings cause problems.
   • Turn off unused ports or restrict them to the management VLAN.

3. LACP and aggregation

   • Create a link-aggregation group for the uplinks and set it to LACP active.
   • On the peer (server or access switch) set the same LACP mode.
   • Keep the member ports identical in speed and MTU.

4. Save and verify

   • Save the running config to persistent storage.
   • Run status checks: show interfaces, show lacp, show vlan.
   • If something is wrong, revert to the saved copy and try one change at a time.

Verification examples

• On a Linux endpoint: ip link show, ethtool , cat /proc/net/bonding/bond0.
• On the switch: show interfaces status; show lacp partner.

If a step changes the control plane, test reachability before moving on.

Configuring VLANs and Improving Network Performance

VLAN configuration on a layer 2 aggregation switch is simple, but it needs consistency across the fabric. I keep VLAN rules strict at the aggregation point and leave dynamic policies to edge devices.

VLAN configuration

1. Plan VLAN IDs and names in a tiny spreadsheet. Keep voice, management and lab/test traffic distinct.
2. On the aggregation switch, set trunk ports for uplinks and tag the VLANs that must pass. Use access mode for server ports that will carry a single VLAN.
3. Decide native VLAN policy. I avoid using the management VLAN as native; pick an unused ID for untagged traffic or disable untagged traffic completely.
4. Apply ingress/egress filters where available to stop accidental VLAN leakage.

Commands to verify

• show vlan brief or equivalent.
• show interfaces trunk to confirm allowed VLANs.
• From a tagged host: ip -d link show and tcpdump -i -e to see 802.1Q tags.

Testing network performance
I run two kinds of checks: link and aggregate behaviour.

Link checks

• Confirm each port reports the expected speed and duplex with show interfaces or ethtool.
• Test MTU with ping: ping -s -M do . If you plan to use jumbo frames, set MTU to 9000 on switch and NICs and test before heavy transfers.

Aggregate checks

• Use iperf3 with multiple streams: iperf3 -c -P 8. One TCP stream usually sticks to one physical member of the LACP group. Multiple streams let the hash distribute and show aggregate throughput near the sum of member links.
• Run parallel tests from several machines at once. That mimics real traffic and shows the true performance for an aggregation role.

Troubleshooting common issues
Mismatched MTU or speed

• Symptom: big transfers drop or perform poorly.
• Fix: set identical MTU and speed on both ends.

LACP not forming

• Symptom: ports stay individual.
• Fix: check LACP mode both sides; active on one end and passive on the other can work, but I run active-active to be explicit. Confirm all member ports use the same allowed VLANs.

VLAN leaks or missing VLANs

• Symptom: traffic from a VLAN does not pass.
• Fix: confirm trunk allowed lists and native VLAN on both sides. Use tcpdump with 802.1Q to inspect tags.

Single-flow limits

• Symptom: a single large copy or backup only reaches one link’s throughput.
• Explanation: most switches hash flows to a single member; single TCP streams will not sum across links.
• Mitigation: use multiple concurrent streams, or run the traffic across multiple hosts.

Physical problems

• Symptom: packet errors, CRCs, flapping.
• Fix: check cables, SFP compatibility, and cooling. Replace DACs or short fibres if a port behaves oddly.

Practical checks I run before calling it finished

• Run iperf3 tests with 4–8 streams from two hosts to the aggregation uplink and record throughput.
• Verify LACP with show lacp and inspect member state.
• Confirm VLAN tag presence with tcpdump on a tagged host.
• Check switch CPU and memory during tests; a cheap switch can hit a ceiling if it lacks hardware forwarding for certain features.

Final takeaways
A layer 2 aggregation switch does one job: move frames quickly between access and core. Keep configs simple, match MTU and speed, use LACP for resiliency, and test using multiple streams to confirm true aggregated throughput. I document port assignments and stick to small, repeatable tests. That saves time and avoids the usual surprises when mixing secondhand gear with newer kit.