How to Use ip Command in Linux: The Modern Network Tool Every Admin Needs

If you’ve been managing Linux systems for any length of time, you’ve probably typed ifconfig more times than you can count. I certainly did for years. But here’s the thing: that command has been deprecated since 2009. The modern replacement? The ip command. And honestly, once you get comfortable with it, you’ll wonder why you waited so long to make the switch.

The ip command in Linux does everything ifconfig did and much more. It handles your network interfaces, IP addresses, routing tables, and neighbor discovery. All through one unified, consistent tool. Let me walk you through exactly how to use it.

What is the ip Command in Linux?

The ip command is part of the iproute2 package, which became the standard for network configuration on Linux distributions back in 2009. Unlike the scattered collection of tools in the old net-tools package (ifconfig, route, arp, netstat), iproute2 gives you one command that handles it all.

Ubuntu actually stopped installing ifconfig by default on desktop editions. That caught a lot of people off guard. But it was the right move. The old tools simply can’t handle modern networking features like namespaces and certain advanced configurations.

Why ip Replaced ifconfig and net-tools

The technical reason comes down to how these tools talk to the kernel. ifconfig uses an outdated mechanism called ioctl for kernel communication. The ip command uses netlink protocol documentation instead. Netlink is faster, more flexible, and supports features that ioctl simply cannot handle.

From a practical standpoint, here’s what you gain:

• Network namespaces: Essential for containers and advanced isolation
• Multiple IP addresses: No more workarounds to add secondary IPs
• Consistent syntax: One command structure for everything network-related
• Better statistics: More detailed interface data when you need it

How ip Command Works with netlink

When you run an ip command, it creates a netlink socket to communicate directly with the kernel’s networking subsystem. This is faster than the old ioctl method and allows for asynchronous operations. You don’t need to understand the internals deeply, but knowing this explains why ip can do things ifconfig never could.

Basic ip Command Syntax and Structure

The ip command follows a clean, logical structure. Once you understand the pattern, every subcommand makes sense. Check the official ip command manual for the complete reference, but here’s what you’ll use daily:

ip [OPTIONS] OBJECT COMMAND

Understanding ip Command Objects

The ip command organizes everything by network objects. This follows the OSI model nicely:

• link: Layer 2 properties (MAC addresses, interface state, MTU)
• addr: IP addresses assigned to interfaces
• route: Routing table entries
• neigh: Neighbor discovery cache (ARP and NDP entries)

Each object has similar commands: show, add, delete, set. Learn one, and the others feel familiar.

Common Options You’ll Actually Use

Three options save me time constantly:

• -c: Adds color to output. Makes scanning long outputs much easier.
• -s: Shows statistics. Packet counts, errors, dropped frames.
• -br: Brief mode. Condensed, table-format output that’s perfect for quick checks.

I use ip -c -br a constantly. It shows all interfaces with their IPs in a clean, colorized table.

Viewing Network Interface Information

Let’s get into the commands you’ll use every day. Viewing your current network configuration is the starting point for any troubleshooting session.

ip link show – Layer 2 Interface Properties

This shows your interfaces at the data link layer. MAC addresses, MTU settings, whether the interface is up or down:

ip link show

To check a specific interface:

ip link show dev eth0

You’ll see output showing the interface state (UP/DOWN), the MAC address, MTU, and queue discipline. When an interface shows NO-CARRIER, it means there’s no physical connection. That’s your first clue when comprehensive network interface troubleshooting leads you down the hardware path.

ip addr show – IP Address Configuration

This is probably the command you’ll run most often. It shows IP addresses (both IPv4 and IPv6), broadcast addresses, and scope:

ip addr show

For a quick overview, use brief mode:

ip -br addr show

This gives you a clean table: interface name, state, and IP addresses. Perfect for quickly confirming your configuration matches what you expect.

Managing IP Addresses with ip Command

Now we’re getting into changes. Adding and removing IP addresses is straightforward, but there’s one critical thing to understand first.

Adding IP Addresses to Interfaces

Use CIDR notation when adding addresses. You’ll need root privileges:

sudo ip addr add 192.168.1.100/24 dev eth0

The /24 specifies the subnet mask (255.255.255.0). This is cleaner than the old ifconfig syntax that required separate netmask parameters.

Removing IP Addresses

The syntax mirrors the add command:

sudo ip addr del 192.168.1.100/24 dev eth0

Be careful here. Remove the wrong IP on a remote server, and you’ve just locked yourself out.

Multiple Addresses on Same Interface

Unlike ifconfig, which required awkward workarounds for secondary addresses, the ip command handles multiple IPs naturally:

sudo ip addr add 192.168.1.100/24 dev eth0
sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip addr add 10.0.0.50/8 dev eth0

All three addresses work simultaneously. This is essential for servers hosting multiple services or websites on different IPs.

Bringing Network Interfaces Up and Down

Sometimes you need to restart an interface. Maybe you’ve made configuration changes, or you’re troubleshooting a connection issue. The ip link set command handles this:

sudo ip link set dev eth0 down
sudo ip link set dev eth0 up

Keep in mind this affects all services using that interface. If you’re connected via SSH over eth0, running that first command ends your session immediately. Ask me how I learned that one.

This is also useful when you’re testing changes. Make a modification, bring the interface down and up, then verify with testing connectivity with ping. If something breaks, you know exactly where to look.

When bringing interfaces up and down, you might affect dependent services. Check them afterward with techniques for managing network services to ensure everything came back properly.

Working with Routing Tables

Routing determines where your traffic goes. The ip route command replaces the old route utility and gives you full control over your system’s routing decisions.

Viewing Routes with ip route show

See your current routing table:

ip route show

The output shows each route: destination network, gateway, interface, and various flags. The default entry is your default gateway. Traffic that doesn’t match any specific route goes there.

To see the route for a specific destination:

ip route get 8.8.8.8

This tells you exactly which interface and gateway will handle traffic to that address. Incredibly useful for troubleshooting routing issues.

Adding and Deleting Static Routes

Add a route to a specific network through a gateway:

sudo ip route add 10.10.0.0/16 via 192.168.1.1 dev eth0

Delete it when no longer needed:

sudo ip route del 10.10.0.0/16

Static routes are critical for multi-homed systems, VPN configurations, and complex network setups. If you manage servers with multiple network interfaces pointing to different networks, you’ll use these commands regularly.

Checking ARP Cache with ip neigh

The neighbor cache holds mappings between IP addresses and MAC addresses. This is the ARP protocol RFC in action for IPv4, and NDP (Neighbor Discovery Protocol) for IPv6.

ip neigh show

Each entry shows the IP address, interface, MAC address, and state (REACHABLE, STALE, FAILED, etc.).

When you see FAILED entries, something’s wrong at Layer 2. Maybe the device is offline, maybe there’s a VLAN mismatch, maybe there’s a hardware issue. This is your first stop when ping fails but the interface is up.

Clear a specific entry and let it refresh:

sudo ip neigh del 192.168.1.50 dev eth0

Next time your system needs to reach that IP, it’ll perform fresh ARP resolution.

Practical Examples Every Admin Should Know

Theory is fine, but let’s talk about real-world workflows. These are the patterns I use constantly.

Quick Network Diagnostics Workflow

When something’s wrong with network connectivity, here’s my quick diagnostic sequence:

This sequence moves from Layer 2 to Layer 3 systematically. If the interface shows DOWN, that’s your problem. If the interface is UP but has no IP, configuration issue. IP present but can’t reach gateway? Routing or ARP problem.

Common Troubleshooting Scenarios

Here’s a scenario I hit recently. A server couldn’t reach external hosts, but local network was fine. Running ip route show revealed the default gateway was missing. Someone had flushed the routes during maintenance and forgot to restore the default.

sudo ip route add default via 192.168.1.1

Problem solved in seconds. Without understanding ip route, this could have taken much longer to diagnose.

For application-layer issues after network configuration looks good, try curl for testing HTTP connectivity. And always combine your ip troubleshooting with ss command for socket statistics. They’re companion tools from the same iproute2 package.

When connectivity works but services don’t respond, verify your ports are listening. The guide on checking open ports walks through that process. And if something seems wrong with networking services themselves, checking system logs with journalctl often reveals the root cause.

Making Network Changes Permanent

Everything I’ve shown you so far disappears on reboot. That’s actually a feature, not a bug. It lets you test changes safely. If something goes wrong, just reboot and you’re back to known-good configuration.

But once you’ve confirmed your changes work, you’ll want to make them permanent. This is where things get distribution-specific.

For Debian/Ubuntu, you edit /etc/network/interfaces or use netplan (newer versions). For RHEL/CentOS/Fedora, configuration files live in /etc/sysconfig/network-scripts/. Arch Linux typically uses systemd-networkd or NetworkManager.

The pattern I follow: test changes with ip commands first. Once confirmed working, translate those changes to your distribution’s configuration format. This approach has saved me from many late-night emergency sessions.

For those interested in diving deeper into the iproute2 development, the iproute2 source repository is available for exploration.

Wrapping Up

The ip command isn’t just a replacement for ifconfig. It’s a complete upgrade. Once you internalize the object-based syntax (link, addr, route, neigh), you’ll move through network troubleshooting faster than ever.

Start by replacing your muscle-memory ifconfig calls with ip addr. Use the brief mode (-br) for quick checks. Add color (-c) because it genuinely helps. Then expand to ip route and ip neigh as you need them.

The commands you learned today handle 95% of daily network administration tasks. For the remaining edge cases, the man pages are comprehensive. But you’ve got the foundation now. Go configure some networks.