Build a Small Ubuntu LAN That You Can Actually Debug

The first tiny lab network I built had two green link lights and zero useful connectivity. I had treated the switch like a home router and waited for it to hand out addresses. It never would: an ordinary unmanaged switch moves Ethernet frames; DHCP, routing, DNS, and Internet access must come from somewhere else—or be deliberately omitted.

What each box is responsible for

Internet-connected LAN
 
Internet ── router (DHCP + gateway) ── unmanaged switch ── Ubuntu hosts
 
Isolated lab LAN
 
Ubuntu A (10.77.0.11/24) ── unmanaged switch ── Ubuntu B (10.77.0.12/24)
                                    │
                              Ubuntu C (10.77.0.13/24)

What the diagram tells you

• The switch learns MAC-address locations and forwards local Ethernet traffic; an unmanaged switch normally needs no host-side configuration.

• A router connects different IP networks and usually supplies a default gateway, DHCP, DNS forwarding, and Internet NAT in a home or small office.

• Hosts in one /24 subnet can communicate directly through the switch without a default gateway.

• The sample 10.77.0.0/24 network is only a planning example; verify it does not overlap Wi-Fi, VPN, containers, virtual machines, or another routed network.

Cable the network before editing Ubuntu

1. Power the switch and connect each Ubuntu system with a known-good Ethernet cable.

1. For DHCP and Internet access, connect one switch port to a LAN port on the router—not its WAN port.

1. Check link/activity LEDs on the host and switch, remembering that an LED proves physical link, not IP connectivity.

1. If the switch supports VLANs or management, confirm all selected access ports belong to the same intended VLAN.

1. Write down each cable, switch port, hostname, interface name, and planned IP address before configuring several machines.

Identify the actual Ethernet interface

$ ip -brief link
ip -brief address
ip route

How to recognize the correct interface

• Ubuntu predictable Ethernet names often begin with en, such as eno1 or enp0s31f6; never assume the interface is eth0.

• UP means administratively enabled, while LOWER_UP indicates a working lower-layer link.

• NO-CARRIER usually points to cable, port, switch power, negotiation, or driver state before IP configuration.

• Existing routes reveal subnets you must not reuse for the isolated LAN.

Path A: use the router’s DHCP service

On Ubuntu Desktop, the Ethernet connection normally uses NetworkManager and automatic IPv4 configuration already. Plugging into a router-connected switch may be enough. On a server using Netplan with networkd, DHCP can be declared explicitly.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true

What this Netplan file delegates

• version: 2 selects the current Netplan schema generation.

• renderer: networkd hands generated runtime configuration to systemd-networkd; Ubuntu Desktop commonly uses NetworkManager instead.

• The key beneath ethernets must exactly match the real interface.

• dhcp4: true requests IPv4 settings from a DHCP server; the switch itself does not answer that request.

Path B: plan an isolated static subnet

• Choose an unused RFC 1918 subnet after checking every host’s routes—for example, 10.77.0.0/24 only if it is genuinely unused.

• Reserve unique host addresses such as .11, .12, and .13; never assign the network address .0 or broadcast address .255 in this /24 example.

• Use the same prefix length on every host that should communicate directly.

• Do not invent a gateway address. An isolated switch has no router, so adding a fake default route only breaks route selection.

• Use IP addresses or /etc/hosts for names unless you operate a DNS server on the lab network.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: false
      addresses:
        - 10.77.0.11/24

Why gateway and DNS are absent

• dhcp4: false prevents this interface from waiting for a DHCP lease.

• addresses uses CIDR notation; /24 places 10.77.0.1 through 10.77.0.254 in the same local IPv4 subnet.

• No routes entry is needed for hosts on the directly connected subnet.

• No nameservers entry is needed for tests by address; add DNS only when a reachable resolver is part of the design.

Inspect existing Netplan ownership before adding a file

$ ls -l /etc/netplan
sudo netplan get
systemctl is-active NetworkManager systemd-networkd

What prevents configuration fights

• Netplan merges YAML files lexicographically; a new file can override or combine with installer and cloud-init configuration.

• netplan get shows the merged model rather than only one file.

• Desktop NetworkManager profiles and server networkd configuration should not compete for the same interface.

• Back up the relevant YAML and retain console access before changing a remote host.

Validate and apply with rollback

$ sudo netplan generate
sudo netplan try --timeout 120

What the safety sequence covers

• netplan generate catches schema and YAML problems without applying the generated network state.

• netplan try applies temporarily and asks for confirmation; lack of confirmation triggers rollback after the timeout.

• Rollback is valuable but not infallible for every virtual-device or remote-network scenario, so preserve console access.

• Confirm only after address, route, peer, and required remote-session tests succeed.

Test from the bottom of the stack upward

$ ip -brief link show dev enp0s31f6
ip -brief address show dev enp0s31f6
ip route get 10.77.0.12
ping -c 4 10.77.0.12
ip neighbour show dev enp0s31f6

How each result narrows the fault

• LOWER_UP establishes link; without it, stop and inspect cable, port, driver, and switch configuration.

• The address must be unique and in the planned subnet with the intended prefix.

• ip route get should select the Ethernet interface and local source address, not Wi-Fi or a VPN.

• Successful ping proves two-way IP and ICMP for that peer; failure does not automatically prove the link is down because firewalls can block ICMP.

• Neighbour states such as REACHABLE or STALE show an IP-to-MAC mapping; INCOMPLETE or FAILED points toward Layer-2, VLAN, or peer-address trouble.

Separate network reachability from service reachability

$ ss -lnt
sudo ufw status verbose
ping -c 4 10.77.0.12

Why ping is not the final application test

• ss -lnt shows local listening TCP ports; the intended server must bind to the LAN address or all appropriate addresses.

• ufw status verbose reports firewall policy but does not modify it.

• A successful ping can coexist with a blocked or absent SSH, HTTP, database, or file-sharing service.

• Open only the required service and source subnet instead of disabling the firewall for convenience.

Measure throughput only after correctness

For an actual performance test, run an iperf3 server on one host and a client on another. File-copy speed mixes disk, filesystem, protocol, encryption, and cache behavior with the network. First prove stable addressing and routes; then use a dedicated network benchmark and compare link rate, TCP throughput, retransmissions, and CPU load.

Symptoms that point to the real layer

• No carrier: cable, switch port, power, NIC driver, or negotiation problem.

• 169.254.x.x address: DHCP failed and link-local fallback occurred; verify a router/DHCP server exists.

• Duplicate-address warning or intermittent traffic: two hosts share an address; disconnect one and correct the plan.

• Peer works but Internet does not: isolated LAN has no router, or the default gateway and forwarding/NAT design is incomplete.

• Internet works but peer uses Wi-Fi: route overlap or metrics selected another interface; inspect ip route get PEER.

• Ping works but SSH does not: service is not listening, binds to another address, or a firewall blocks its port.

• Some switch ports cannot talk: managed-switch VLAN or port-isolation configuration differs.

Related Ubuntu networking work

• Configure a static IP address on Ubuntu for a routed production network.

• Measure network throughput with iperf after connectivity is correct.

• Inspect Linux interface and IP details when inventorying a more complex host.