FreeBSD Networking Internals: Interfaces, Routing, and netstat

FreeBSD’s networking stack predates Linux’s, tracing back through BSD’s original TCP/IP implementation — the reference stack most other operating systems’ TCP/IP was modeled on or directly derived from. Its userland tooling reflects that lineage: ifconfig and netstat rather than ip, and a driver-name-plus-unit-number interface naming convention rather than enp0s3-style predictable names.

Interface naming: driver plus unit number

FreeBSD names interfaces after the driver that handles them, followed by a unit number: em0 for the first Intel em-driver NIC, igb0 for an Intel igb-driver NIC, re0 for Realtek, vtnet0 for VirtIO network devices under virtualization. There’s no abstraction layer renaming these to something hardware-agnostic — the name tells you directly which driver is in play, which is often the fastest first clue when debugging a hardware-specific issue.

ifconfig -a
pciconf -lv | grep -B4 network

Configuring interfaces

Interface configuration happens in two places: interactively via ifconfig, and persistently via /etc/rc.conf.

# Interactive, non-persistent
ifconfig em0 inet 192.168.1.10/24
ifconfig em0 up

# /etc/rc.conf — persists across reboots
ifconfig_em0="inet 192.168.1.10/24"
defaultrouter="192.168.1.1"

For DHCP, dhclient is invoked automatically at boot when ifconfig_em0="DHCP" is set, and can be run manually to renew or debug a lease:

dhclient em0

Bridges, VLANs, and lagg

FreeBSD builds compound network configurations from the same small set of pseudo-interface types used elsewhere in the system. A bridge interface joins multiple interfaces into a single Ethernet segment (used heavily with bhyve and jails); vlan interfaces tag traffic to a specific 802.1Q VLAN; lagg aggregates multiple physical links (LACP, failover, round-robin) into one logical interface.

ifconfig bridge0 create
ifconfig bridge0 addm em0 addm tap0 up

ifconfig em0.100 create vlan 100 vlandev em0

ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1

Each of these is itself just another interface as far as ifconfig -a and the rest of the networking stack are concerned — a VLAN or lagg interface can have its own IP address, participate in a bridge, or be handed to a jail, exactly like a physical NIC.

The routing table

FreeBSD exposes its kernel routing table through netstat -r, and modifies it through route:

netstat -rn

Destination        Gateway            Flags     Netif
default             192.168.1.1        UGS       em0
192.168.1.0/24      link#1              U         em0

Adding a static route for a specific destination network follows the same shape as the default route entry:

route add -net 10.0.0.0/24 192.168.1.254

# /etc/rc.conf — a persistent static route
static_routes="internal"
route_internal="-net 10.0.0.0/24 192.168.1.254"

Multiple routing tables (setfib) let a single host maintain entirely separate routing views — useful for jails or processes that need to route traffic differently from the host’s default table, without the complexity of network namespaces.

netstat: more than just connections

netstat is the umbrella tool for inspecting nearly every layer of the networking stack, not just open connections:

netstat -an              # all sockets, numeric addresses
netstat -s -p tcp         # per-protocol statistics
netstat -I em0 -w 1       # live interface throughput, refreshed every second
netstat -m                # mbuf (kernel network buffer) usage

netstat -m in particular is worth knowing under load — mbuf exhaustion is a classic (if now rarer) FreeBSD networking failure mode on high-throughput systems with an undersized kern.ipc.nmbclusters.

tcpdump for packet-level inspection

For anything netstat’s aggregate view doesn’t answer, tcpdump (present in the base system) captures raw packets directly:

tcpdump -i em0 -n port 443
tcpdump -i em0 -n -w capture.pcap

Putting it together: diagnosing a connectivity problem

A methodical FreeBSD networking diagnosis tends to follow the stack upward: ifconfig to confirm the interface is up and has the expected address, netstat -rn to confirm a route exists to the destination, ping/traceroute to confirm reachability, and tcpdump when something in between is dropping or mangling packets that shouldn’t be. Because every one of these tools reports on a specific, well-defined layer, working through them in order rarely leaves the actual fault ambiguous for long.