This final article in the series pulls everything together: a complete, practical walkthrough of configuring TCP/IP networking on a Linux system from scratch — assigning an IP address, setting a default gateway, configuring DNS, and verifying every layer works correctly. Whether you’re setting up a new server, troubleshooting a broken configuration, or just want a solid mental model of the whole process, this article covers it end to end.
The TCP/IP Configuration Stack, End to End
flowchart TD
A[Physical Interface Detected] --> B[Assign IP Address + Subnet Mask]
B --> C[Configure Default Gateway]
C --> D[Configure DNS Resolvers]
D --> E[Verify Local Connectivity]
E --> F[Verify Gateway Reachability]
F --> G[Verify DNS Resolution]
G --> H[Verify Internet/Remote Connectivity]Step 1: Identify Your Network Interfaces
ip link show
Example output:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
Step 2: Understand the Addressing Plan Before Configuring Anything
Before typing a single command, decide:
- IP address: e.g.,
192.168.1.50 - Subnet mask / prefix: e.g.,
/24(255.255.255.0) - Default gateway: e.g.,
192.168.1.1 - DNS servers: e.g.,
8.8.8.8,1.1.1.1
flowchart LR
A["IP: 192.168.1.50/24"] --> B["Gateway: 192.168.1.1"]
B --> C["DNS: 8.8.8.8, 1.1.1.1"]Step 3: Assign an IP Address (Runtime, for Testing)
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip link set eth0 upVerify:
ip addr show eth0Remember: this is temporary and will not survive a reboot — persistent configuration is covered in Step 6.
Step 4: Configure the Default Gateway (Runtime)
sudo ip route add default via 192.168.1.1Verify:
ip route showStep 5: Configure DNS (Runtime, for Testing)
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee -a /etc/resolv.conf
Note: as discussed in our TCP/IP configuration files article, on systems using systemd-resolved, this may get overwritten — the persistent method in Step 6 handles this correctly.
Step 6: Make the Configuration Persistent
This is where the method depends on your distribution, as detailed in our dedicated boot-time networking article. Here’s the complete picture for each major approach:
Ubuntu (Netplan)
# /etc/netplan/01-netcfg.yaml
network:
version: 2
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.50/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
sudo netplan try
sudo netplan apply
RHEL/CentOS/Fedora (NetworkManager)
sudo nmcli connection modify eth0 ipv4.addresses 192.168.1.50/24
sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
sudo nmcli connection modify eth0 ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection modify eth0 ipv4.method manual
sudo nmcli connection up eth0
Legacy Debian/Ubuntu (/etc/network/interfaces)
auto eth0
iface eth0 inet static
address 192.168.1.50
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 1.1.1.1
sudo systemctl restart networking
Step 7: Verify Everything, Layer by Layer
7a. Verify the IP address is assigned correctly
ip addr show eth0
7b. Verify the default route exists
ip route show | grep default
7c. Verify local network connectivity (no gateway involved)
ping -c 4 192.168.1.17d. Verify DNS resolution
dig +short example.com
7e. Verify full end-to-end connectivity
curl -I https://example.com
This layered verification approach (matching the troubleshooting model from our connectivity-checking article) ensures that if something’s wrong, you know exactly which layer to investigate rather than guessing.
A Complete Worked Example: Configuring a New Ubuntu Server
Scenario: A freshly installed Ubuntu Server needs a static IP for its role as a web server.
Step 1: Identify the interface
ip link show
Output shows the interface is named ens160.
Step 2: Create the Netplan configuration
sudo nano /etc/netplan/00-installer-config.yaml
network:
version: 2
ethernets:
ens160:
dhcp4: no
addresses:
- 10.0.0.20/24
routes:
- to: default
via: 10.0.0.1
nameservers:
addresses: [10.0.0.1, 1.1.1.1]
Step 3: Set correct file permissions (Netplan is strict about this)
sudo chmod 600 /etc/netplan/00-installer-config.yaml
Step 4: Test safely (especially important over SSH)
sudo netplan try
Step 5: Apply once confirmed working
sudo netplan apply
Step 6: Full verification
ip addr show ens160
ip route show
dig +short example.com
curl -I https://example.com
Comparison Table: Configuration Methods Summary
| Distro Family | Persistent Config Tool | Config Location |
|---|---|---|
| Modern Ubuntu | Netplan | /etc/netplan/*.yaml |
| RHEL/CentOS/Fedora | NetworkManager (nmcli) | /etc/NetworkManager/system-connections/ |
| Legacy Debian/Ubuntu | ifupdown | /etc/network/interfaces |
Real-World Use Case: Migrating a Server From DHCP to Static IP
A server currently using DHCP needs a fixed IP so DNS records and firewall rules remain stable.
Step 1: Note the current DHCP-assigned settings
ip addr show eth0
ip route show
cat /etc/resolv.conf
Step 2: Reserve that same IP in your DHCP server (recommended) or choose a new one outside the DHCP pool
Step 3: Apply the static configuration using the appropriate persistent method (Netplan/nmcli/interfaces)
Step 4: Reboot and verify the configuration survives
sudo reboot
# after reboot:
ip addr show eth0
Best Practices
- Always plan your addressing scheme before configuring anything — IP, subnet, gateway, and DNS should all be decided together, not improvised.
- Test remote configuration changes with a safety net (
netplan try, or a scheduled revert job) to avoid losing SSH access. - Verify layer by layer after any change — IP assignment, then gateway, then DNS, then full connectivity — rather than assuming success.
- Keep static IP assignments documented in a central inventory (spreadsheet, IPAM tool, or configuration management system).
- Match static IP assignments with DHCP exclusions or reservations to avoid future address conflicts.
- Use configuration management tools (Ansible, etc.) for fleets of servers, so networking configuration is consistent, versioned, and repeatable rather than manually configured one server at a time.
Troubleshooting
Problem: Configuration applies but connectivity is broken
Work through the verification steps in order (Step 7 above) to isolate exactly which layer failed — IP assignment, gateway, or DNS.
Problem: Lost access after a remote configuration change
If you used netplan try, it auto-reverts after ~120 seconds. Otherwise, you’ll need out-of-band console access (cloud provider console, IPMI, physical access) to fix the configuration directly.
Problem: Static IP conflicts with another device
arping -D -I eth0 192.168.1.50
This checks for existing users of that IP address before you commit to using it.
Problem: Netplan apply fails silently or partially
sudo netplan --debug apply
Debug mode reveals detailed parsing and application errors, most commonly YAML indentation mistakes.
Problem: DNS resolves locally but not from applications
Some applications cache DNS or use their own resolver configuration; confirm with a generic tool first (dig), then check the specific application’s own DNS settings if the discrepancy persists.
Conclusion
Configuring TCP/IP networking in Linux comes down to a clear, layered process: assign an IP address and subnet, set a default gateway, configure DNS, make it all persistent through your distribution’s proper configuration system, and verify each layer methodically. Whether you’re using modern Netplan YAML on Ubuntu, NetworkManager’s nmcli on RHEL-family systems, or legacy interfaces files, the underlying TCP/IP concepts — addressing, routing, and name resolution — remain exactly the same. With the complete workflow in this article, you should be equipped to confidently configure, verify, and troubleshoot networking on any Linux system you encounter.
