When working with EC2 instances or other cloud VMs, you might encounter this scenario after running:

sudo dhclient
RTNETLINK answers: File exists

Despite the message, dhclient exits with status 0, indicating successful lease renewal. So what's happening?

This message originates from the Linux kernel's networking subsystem when dhclient attempts to:

• Add a route that already exists in the routing table
• Create duplicate network interface configurations
• Modify existing ARP cache entries

In cloud environments like AWS EC2, this typically occurs because:

1. The instance already has a valid DHCP lease
2. Cloud-init or other provisioning tools configured networking
3. Multiple DHCP clients might be running (check with ps aux | grep dhclient)

To diagnose the exact cause, try these commands:

# Check existing routes
ip route show

# Verify DHCP leases
cat /var/lib/dhcp/dhclient.leases

# Inspect network interfaces
ip addr show

# Check for multiple dhclient processes
pgrep -fl dhclient

While usually benign, these situations warrant investigation:

- The message appears in loops (possible DHCP client conflict)
- Network connectivity issues occur after the message
- You see multiple DHCPACK packets in tcpdump:

sudo tcpdump -i eth0 port 67 or port 68 -vv

For AWS EC2, these approaches often work better:

# Preferred method for EC2
sudo dhclient -r eth0  # Release current lease
sudo dhclient eth0     # Request new lease

# Alternative cloud-init approach
sudo cloud-init clean
sudo cloud-init init

Remember that EC2 instances typically use the Amazon-supplied DHCP client configuration in /etc/dhcp/dhclient-eth0.conf with specific AWS options.

To prevent recurring messages, consider:

# Edit dhclient.conf
sudo nano /etc/dhcp/dhclient.conf

# Add these lines:
supersede domain-name-servers 8.8.8.8, 8.8.4.4;
supersede routers 10.0.0.1;

Or for systemd-networkd users:

[Match]
Name=eth0

[Network]
DHCP=yes
LLDP=yes
LinkLocalAddressing=yes

---

When working with Amazon EC2 instances or any Linux server, you might encounter this output after running sudo dhclient:

RTNETLINK answers: File exists

Despite the message, the command exits with status 0 (success), leaving many administrators wondering about its significance.

This message occurs when the DHCP client attempts to add a route that already exists in the kernel's routing table. It's not actually an error - just an informational message indicating the system detected a duplicate route entry.

The complete sequence looks like this:

$ sudo dhclient
RTNETLINK answers: File exists
$ echo $?
0

Amazon's Elastic Network Interface (ENI) configuration creates specific routing scenarios that often trigger this condition:

• The default route via the ENI already exists
• DHCP tries to add the same route again
• The kernel detects the duplicate and responds with "File exists"

At the kernel level, this happens because:

netlink_sendmsg() -> netlink_unicast() -> netlink_attachskb()
returns -EEXIST (which translates to "File exists")

The DHCP client's route addition attempt hits this kernel code path when the route already exists in the routing table.

To confirm this is what's happening, check your routes before and after DHCP renewal:

$ ip route show
default via 10.0.0.1 dev eth0 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.123

Consider investigating further if:

• The message appears repeatedly in logs
• Network connectivity issues occur simultaneously
• You see actual errors (non-zero exit status)

If the message is purely cosmetic and you want to suppress it:

$ sudo dhclient 2>/dev/null

Or more selectively:

$ sudo dhclient 2> >(grep -v "RTNETLINK answers: File exists")

For production systems, consider modifying the DHCP client script to handle this gracefully. Example for Debian/Ubuntu:

# Create custom script
$ sudo tee /etc/dhcp/dhclient-exit-hooks.d/noremove <<'EOF'
#!/bin/sh
case $reason in
    BOUND|RENEW|REBIND|REBOOT)
        # Prevent route removal that can trigger the message
        exit 0
        ;;
esac
EOF
$ sudo chmod +x /etc/dhcp/dhclient-exit-hooks.d/noremove

If using NetworkManager, you can configure it to avoid these scenarios:

$ nmcli connection modify eth0 ipv4.never-default yes
$ nmcli connection up eth0