How to Reset the Linux Network Stack

A misbehaving network stack is one of the most disruptive problems on a Linux system. Stale routes, a poisoned DNS cache, a stuck DHCP lease, or a hung NetworkManager daemon can all cause connectivity failures that look superficially identical. Rather than rebooting, you can surgically reset each layer — DNS cache, DHCP lease, routing table, and the network management daemon itself — in a few minutes. This guide walks through every step, from a simple service restart to a full flush of routes and ARP entries.

Identify Your Network Manager

Before issuing any commands, determine which daemon manages your interfaces. Most desktop distros use NetworkManager; servers often use systemd-networkd; some systems use both for different interfaces.

systemctl status NetworkManager systemd-networkd

If a unit shows active (running), that daemon owns your interfaces. A inactive (dead) result means it is not in use on this machine. Everything below is labelled so you can skip sections that do not apply.

Step 1 — Restart the Network Management Daemon

NetworkManager

NetworkManager is the default on Ubuntu, Fedora, RHEL/Rocky, and most desktop Arch installs. A restart tears down and re-establishes all managed connections cleanly.

sudo systemctl restart NetworkManager

Give it five to ten seconds, then check whether your interfaces came back:

nmcli general status
nmcli device status

If you want to reload configuration without fully dropping connections (useful on a remote session), use reload instead of restart:

sudo systemctl reload NetworkManager

systemd-networkd

On servers running Debian minimal, Ubuntu Server with cloud-init, or any system configured with .network files under /etc/systemd/network/, restart systemd-networkd instead:

sudo systemctl restart systemd-networkd

If you use systemd-resolved alongside it (common on Ubuntu and Fedora), restart that too:

sudo systemctl restart systemd-resolved

Step 2 — Flush the DNS Cache

Stale DNS records can cause name resolution failures even when the interface is fully up. Which cache you flush depends on what is running.

systemd-resolved (Ubuntu, Fedora, Arch with resolved enabled)

sudo resolvectl flush-caches

Confirm the cache was cleared:

resolvectl statistics

Look for Current Cache Size: 0 in the output immediately after flushing.

nscd (older Debian/Ubuntu, some RHEL setups)

If your system runs nscd rather than (or alongside) resolved:

sudo systemctl restart nscd

dnsmasq (common on systems using NetworkManager with dnsmasq plugin)

sudo systemctl restart dnsmasq

NetworkManager can run an internal dnsmasq instance. Restarting NetworkManager as shown in Step 1 also restarts this plugin, so a separate step is usually unnecessary in that case.

Step 3 — Release and Renew the DHCP Lease

A stale or conflicting DHCP lease will give you a correct-looking IP address that nobody on the network will route traffic to. Releasing and renewing forces a fresh negotiation with the DHCP server.

With NetworkManager

Replace ens3 with your actual interface name (find it with ip link):

nmcli device reapply ens3

If reapply does not kick a stubborn lease, disconnect and reconnect the device explicitly:

nmcli device disconnect ens3
nmcli device connect ens3

With dhclient (Debian/Ubuntu without NetworkManager)

sudo dhclient -r ens3   # release
sudo dhclient ens3      # renew

With dhcpcd (Arch, Alpine, some Raspberry Pi setups)

sudo dhcpcd -k ens3   # release and exit
sudo dhcpcd ens3      # renew

Step 4 — Flush Routing Tables and ARP Cache

Stale routes or ARP entries can cause packets to be sent to the wrong gateway or a vanished MAC address. The ip command (from the iproute2 package) handles both. Run these only if you have console or out-of-band access, or you are certain the new routes will come back automatically — flushing routes on a remote session without NetworkManager or systemd-networkd to restore them will cut your SSH connection.

# Flush all routes (will disconnect remote sessions temporarily)
sudo ip route flush table main

# Flush the ARP/neighbour cache only (safe on remote sessions)
sudo ip neigh flush all

After flushing routes, bring routes back by restarting the network daemon (Step 1) or by re-running DHCP (Step 3). On a static-IP machine, re-add your default gateway manually if needed:

sudo ip route add default via 192.168.1.1 dev ens3

Step 5 — Bring Interfaces Down and Back Up

When a driver or firmware glitch freezes an interface at a level the daemon cannot see, a full link bounce using the ip command forces the kernel to reinitialise the device state.

sudo ip link set ens3 down
sudo ip link set ens3 up

On Wi-Fi interfaces, you may also need to re-associate. NetworkManager will detect the link-up event and reconnect automatically if it manages the interface.

Verify the Reset Worked

Run through this short checklist after any reset operation:

• Check interface state and IP assignment: ip addr show ens3
• Check the default route exists: ip route show default
• Test DNS resolution: resolvectl query example.com or dig example.com
• Test gateway reachability: ping -c 3 $(ip route show default | awk '/default/ {print $3}')
• Test external connectivity: ping -c 3 1.1.1.1 && curl -s https://example.com -o /dev/null -w "%{http_code}\n"

Troubleshooting

NetworkManager restarts but the interface stays disconnected

Check whether NetworkManager has marked the device as unmanaged. This happens when an interface is listed in /etc/network/interfaces (Debian) or a legacy ifcfg file exists. Run nmcli device status and look for unmanaged in the STATE column. Remove or comment out the conflicting static configuration, then run sudo nmcli device set ens3 managed yes.

DNS flush did not help — resolution still fails

Confirm which resolver /etc/resolv.conf actually points to. On resolved-managed systems it should be a symlink to /run/systemd/resolve/stub-resolv.conf. If it is a plain file with a third-party nameserver, your application may be bypassing resolved entirely. Check with:

ls -la /etc/resolv.conf
cat /etc/resolv.conf

DHCP renewal gets the same IP or fails entirely

Delete the stale lease file before renewing. Locations vary by client:

# dhclient
sudo rm /var/lib/dhcp/dhclient.ens3.leases

# dhcpcd
sudo rm /var/lib/dhcpcd/dhcpcd-ens3.lease

Then retry the renewal command from Step 3. If the DHCP server still does not respond, the problem is upstream — check the router or DHCP server directly.

ip route flush wiped my routes and nothing came back

Restart the managing daemon immediately: sudo systemctl restart NetworkManager or sudo systemctl restart systemd-networkd. If you are on a static configuration without a daemon, re-add your address, route, and gateway manually using ip addr add, ip route add, then investigate why your init configuration did not restore them (check journalctl -u networking).