# Home Lab Setup

Networking is learned by breaking things you own. This note is the cheapest path from a laptop to a lab where you can cause a loop, blackhole a route, and watch a packet die — without a support ticket.

## Choose your weapon

| Tool | Cost | What it is good for | Friction |
|---|---|---|---|
| **Linux namespaces (`ip netns`)** | Free, already installed | Routing, ARP, bridges, tunnels, no vendor images | No switch CLI |
| **containerlab** | Free | Real vendor/FRR images, reproducible topologies in YAML | Needs Docker, images |
| **Mininet** | Free | SDN, OpenFlow, rapid topologies | Python-centric |
| **GNS3 / EVE-NG** | Free software | Cisco/Juniper images, GUI topology | Image licensing, RAM |
| **Cisco Packet Tracer** | Free with NetAcad | CCNA-style switching and routing | Simulated, limited realism |
| **Wireshark + tcpdump** | Free | Seeing the truth | None |
| **FRR** | Free | Real OSPF/BGP on Linux | Config syntax learning curve |
| **A cheap VPS pair** | ~$10/mo | Tunnels, BGP with a real ASN, public IP behaviour | Money |

Start with namespaces and FRR. They cost nothing, run on any Linux box, and teach the same concepts as a $5,000 lab.

## Lab 1 — two hosts, one wire (10 minutes)

```bash
sudo ip netns add red
sudo ip netns add blue
sudo ip link add veth-red type veth peer name veth-blue
sudo ip link set veth-red netns red
sudo ip link set veth-blue netns blue

sudo ip netns exec red ip addr add 10.0.0.1/24 dev veth-red
sudo ip netns exec blue ip addr add 10.0.0.2/24 dev veth-blue
sudo ip netns exec red  ip link set veth-red up
sudo ip netns exec blue ip link set veth-blue up
sudo ip netns exec red  ip link set lo up
sudo ip netns exec blue ip link set lo up

sudo ip netns exec red ping -c2 10.0.0.2
sudo ip netns exec red ip neigh          # ARP cache, populated by that ping
```

Then break it deliberately:

```bash
# wrong mask on one side
sudo ip netns exec blue ip addr del 10.0.0.2/24 dev veth-blue
sudo ip netns exec blue ip addr add 10.0.0.2/25 dev veth-blue
sudo ip netns exec red ping -c2 10.0.0.2   # still works, but now think about why

# duplicate IP
sudo ip netns exec blue ip addr add 10.0.0.1/24 dev veth-blue
```

## Lab 2 — a router between two subnets (20 minutes)

Add a third namespace with two veth pairs and `net.ipv4.ip_forward=1`, or use a Linux bridge to attach several namespaces to one segment. Then:

```bash
sudo ip netns exec router sysctl -w net.ipv4.ip_forward=1
sudo ip netns exec red ip route add default via 10.0.0.254
sudo ip netns exec router iptables -t nat -A POSTROUTING -o veth-out -j MASQUERADE
```

You now have a network where NAT, routing and ARP all matter and you can watch each one with `tcpdump -ni any`.

## Lab 3 — real protocols with FRR (1 hour)

Install `frr` (package manager), enable `ospfd` and `bgpd` in `/etc/frr/daemons`, then configure in `vtysh`:

```text
router ospf
 network 10.0.0.0/24 area 0
!
router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 address-family ipv4 unicast
  neighbor 10.0.0.2 activate
```

Three namespaces running FRR can form an OSPF area, then two of them can peer BGP across it. That is a complete IGP-plus-EGP lab on one laptop.

## Lab 4 — a loop, on purpose (30 minutes)

```bash
sudo ip link add br0 type bridge
sudo ip link add br1 type bridge
# attach the same two namespaces to both bridges, or cable two Linux bridges twice
```

Without STP, a broadcast in that topology multiplies. Use `tcpdump -ni any -c 50` and watch the packet count explode, then `bridge link` and `bridge fdb` to see the MAC table flap. Pull a cable (delete a veth) and confirm the storm stops.

Linux bridges do run STP, but it is off by default (`ip link set br0 type bridge stp_state 1`).

## Lab 5 — tunnels and MTU (45 minutes)

Two namespaces and WireGuard (or `ipip`/`gre` for a header-only tunnel):

```bash
sudo ip netns exec red  ip link add wg0 type wireguard
sudo ip netns exec red  wg set wg0 listen-port 51820 private-key /path/red.key
sudo ip netns exec red  ip addr add 10.9.0.1/24 dev wg0
sudo ip netns exec red  ip link set wg0 up
```

Then set the MTU down to 1280, `ping -M do -s 1400`, and watch it fail while small pings succeed. That is a black hole you created and can now recognise in the wild.

## Lab hygiene

- **Snapshot before you break things.** Namespaces are cheap; rebuild them from a script.
- **Keep every lab in Git** as a `setup.sh` or a `topo.yml`. Reproducibility is the point.
- **Record the failure, not just the fix.** A lab notebook of "what I broke and how I found it" is worth more than a folder of working configs.
- **Do not lab on production.** Obvious, and the reason most people never lab at all.

## Where it goes wrong

- **Images and licensing.** GNS3/EVE-NG need vendor images you may not be licensed to run; Packet Tracer avoids this at the cost of realism.
- **Laptop RAM.** Four virtual routers with 2 GB each is 8 GB before the host. containerlab with FRR images is far lighter.
- **Lab that proves nothing.** Copying a working config teaches typing; breaking one teaches networking.
- **No baseline capture.** Learn what healthy looks like in Wireshark before you need to spot unhealthy.
- **Skipping the failure.** The most valuable lab step is the one where you deliberately misconfigure something.

## Teaching hook

Every lab in a course should end with a **deliberate break**: wrong mask, duplicate IP, missing route, MTU too small, expired certificate. Learners remember the repair, not the install.

## Related Notes

- [[Labs/Troubleshooting-Scenarios.md]] — the failures these labs reproduce
- [[Labs/Subnetting-Drills.md]] — the arithmetic you need before lab 2
- [[Automation-Observability/Packet-Analysis-Wireshark.md]] — capture setup
- [[Automation-Observability/NetDevOps-Fundamentals.md]] — lab as code