Ip

Right, so you’ve got a bunch of physical network links and a pile of virtual machines. You could just plug things in and hope for the best, but that’s like using a single, rickety plank to cross a chasm when you’ve got a whole stack of them right next to you. Let’s talk about combining those links for more throughput and reliability (bonding), and creating the virtual switches that your VMs will plug into (bridging). This is where your server stops being a passive endpoint and starts being the network.

Alright, let’s get our hands dirty with the granddaddy of Debian network configuration: /etc/network/interfaces. This file is the old guard, the seasoned veteran. It’s been around since before your favorite indie band sold out, and while it’s been largely superseded by the flashier systemd-networkd and Netplan for new installations, it’s still there, holding the fort on countless servers and older systems. Knowing how to talk to it is a fundamental skill. It’s like knowing how to drive a manual transmission—sure, automatics are more common, but when you need that control, nothing else will do.

Alright, let’s talk Netplan. If you’ve landed on a modern Ubuntu system and tried to go poking around in /etc/network/interfaces like it’s 2010, you were probably met with a polite, yet firm, suggestion to get with the times. Netplan is that suggestion. It’s not a network daemon itself; think of it as the diplomatic translator that sits between you (the human, writing clean YAML) and the low-level networking engines that do the actual heavy lifting (systemd-networkd and NetworkManager). Its entire reason for being is to provide a consistent, declarative network configuration across all Ubuntu flavors. And it does this by making us write YAML. I’m sorry. We’ll get through this together.

Alright, let’s talk about nmcli. If you’ve ever stared at a headless server or a minimal GUI-less install and wondered how to politely ask it to get on the internet, this is your tool. It’s the command-line face of NetworkManager, the sometimes-controversial but undeniably ubiquitous service that manages your network interfaces. Forget clunky old ifconfig; this is the new guard. And while it has a reputation for being a bit… verbose, once you understand its logic, it’s incredibly powerful.

Alright, let’s get our hands dirty with ip link, the Swiss Army knife for your network interfaces. Forget ifconfig; it’s the old guard, retired and living on a farm upstate. The iproute2 suite, which ip link is part of, is the modern toolkit, and it’s how the kernel actually thinks about your network devices. We’re going to talk to the kernel directly, no old-timey translators. First things first, let’s see what we’re working with. The most common command you’ll run is ip link show. It gives you the lay of the land.

Alright, let’s get our hands dirty with the routing table. Think of it as your computer’s internal map of the internet. When you want to send a packet to 8.8.8.8, your machine doesn’t just chuck it out the nearest door and hope for the best. It consults this map—the routing table—to find the best path. The ip route command is how you read and, crucially, redraw that map. Without any arguments, ip route or ip route show spills the beans on your current map. Let’s see what a typical one looks like.

Alright, let’s talk about ip addr. This is your new best friend, your go-to tool for figuring out why your brilliant server can’t seem to talk to anyone else. It replaces the old ifconfig command, which, while nostalgic, is about as useful as a dial-up modem for managing modern networks. The iproute2 suite of tools (which includes our star, ip) is just better. It’s more powerful, consistent, and actually maintained. So let’s get comfortable with it.