Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Linux Admins By James Joyner IV · · 10 min read

Linux Error: Cannot assign requested address — Cause, Fix, and Troubleshooting Guide

How to fix the Linux 'Cannot assign requested address' (EADDRNOTAVAIL) error: bind to a missing IP, ephemeral port exhaustion, wrong interface, and IPv6 binds.

  • #linux
  • #troubleshooting
  • #networking

Summary

Cannot assign requested address maps to EADDRNOTAVAIL (99). The kernel returns it when a process tries to bind() (or connect() with an explicit source) to an address that is not present on any local interface, or when the pool of ephemeral source ports for a given tuple is exhausted. In short: you asked the kernel to use a local address it does not own, or has no free port for.

Common Symptoms

  • A daemon fails to start with bind: Cannot assign requested address.
  • A high-throughput client (load generator, proxy) fails intermittently under load with the same error at connect().
  • The service binds fine on one host but fails on another after an IP change or failover.
  • IPv6 binds fail while IPv4 works, or a bind to a VIP fails before the VIP is attached.

Most Likely Causes of the ‘Cannot assign requested address’ Error

Common production causes of the Cannot assign requested address error, most frequent first:

  1. Binding to an IP the host doesn’t have — a config points at a VIP/floating IP or an old address that is not on any interface yet.
  2. Ephemeral port exhaustion — a client opening many outbound connections to the same destination runs out of source ports in net.ipv4.ip_local_port_range.
  3. Binding before the interface/VIP is up — the service starts before keepalived/DHCP/the cloud NIC attaches the address.
  4. Wrong address family — binding an IPv6 literal on a host with no IPv6 address, or vice versa.
  5. Binding to a non-local address without IP_FREEBIND — HA setups that need to bind a not-yet-present VIP.

Quick Triage

# Is the address the service wants actually on this host?
ip addr | grep 10.0.0.50

# For port exhaustion: how many sockets to the busy destination?
ss -tan state established | wc -l

# What port range does the kernel hand out?
sysctl net.ipv4.ip_local_port_range

If ip addr does not list the IP the app is trying to bind, that is the cause. If it is present, suspect ephemeral port exhaustion.

Diagnostic Commands

# All local addresses (v4 + v6) — the bind target must appear here
ip -br addr
ip addr show

# Listening/known sockets with owning process
ss -tulpn

# Established connection count + source-port usage to a hot destination
ss -tan 'dst 10.0.0.9' | wc -l
ss -tan state time-wait | wc -l

# Ephemeral port range and TIME-WAIT reuse settings
sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_tw_reuse

# Which interface/source the kernel picks for an outbound dest
ip route get 10.0.0.9

# Confirm a VIP is (or isn't) attached
ip addr show | grep -w secondary

ss -tan state time-wait | wc -l climbing toward the size of your local port range is the classic exhaustion signature for a client hammering one destination.

Fix / Remediation

  1. Bind to a valid address. Point the service at an IP that exists on the host, or 0.0.0.0 / :: to bind all interfaces:

    ip -br addr            # pick a real address
    # e.g. in the app config: bind_address = 0.0.0.0
  2. Attach the missing VIP before the service binds (temporary):

    sudo ip addr add 10.0.0.50/24 dev eth0

    Persist via netplan (Ubuntu/Debian) or nmcli con mod eth0 +ipv4.addresses 10.0.0.50/24 (RHEL/Rocky). In HA, let keepalived/pacemaker own the VIP and order the service after it.

  3. Enable non-local bind if the app must bind a VIP that is not yet present (HAProxy pattern):

    sudo sysctl -w net.ipv4.ip_nonlocal_bind=1
    echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/99-nonlocal.conf
  4. Widen the ephemeral port range to fix client-side exhaustion:

    sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
    echo 'net.ipv4.ip_local_port_range = 1024 65535' | sudo tee /etc/sysctl.d/99-ports.conf
  5. Allow TIME-WAIT reuse for outbound-heavy clients (safe for clients, not for NAT’d servers):

    sudo sysctl -w net.ipv4.tcp_tw_reuse=1

Warning: net.ipv4.ip_nonlocal_bind=1 lets any process bind addresses the host does not own — scope it to HA nodes and never enable it broadly on multi-tenant hosts, as it can mask misconfigured binds and enable spoofed source binds.

Validation

ip addr | grep 10.0.0.50                 # the bind IP is present
ss -tulpn | grep :8080                   # the service is now listening
sysctl net.ipv4.ip_local_port_range      # widened range applied

Seeing the service in ss -tulpn bound to the expected address, or the client no longer erroring under load, confirms the fix.

Prevention

  • Bind services to 0.0.0.0/:: or use systemd After=network-online.target and Wants= the VIP-owning unit so binds never race the interface.
  • For HA VIPs, standardize on ip_nonlocal_bind only on the nodes that need it, managed via /etc/sysctl.d/.
  • Baseline the ephemeral port range and monitor TIME-WAIT/established counts on connection-heavy clients.
  • Reuse connection pools instead of opening a fresh outbound socket per request to avoid source-port churn.

Final Notes

Cannot assign requested address is EADDRNOTAVAIL: either the local address you asked to bind is not on the host, or you have run out of ephemeral source ports for the tuple. Check ip addr first — if the IP is missing, attach it or bind 0.0.0.0; if it is present, look at TIME-WAIT and the local port range. Do not confuse it with Address already in use (EADDRINUSE), which means the address exists but the port is taken.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.

Free download · 368-page PDF

Download the Free 500-Prompt DevOps AI Toolkit

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.