The network subsystem is refusing to send packets because it’s exhausted its available buffer space.

Common Causes and Fixes

1. TCP Connection Backlog Too Small

  • Diagnosis: Check the netstat -s output for segments reordered and segments dropped. If these are high, or if netstat -anp | grep LISTEN shows a large number of connections in SYN_RECV state for a listening service, the backlog might be too small. Also, check /proc/sys/net/core/somaxconn.
  • Fix: Increase the maximum backlog queue size. Edit /etc/sysctl.conf and add or modify these lines:
    net.core.somaxconn = 4096
    net.ipv4.tcp_max_syn_backlog = 2048
    
    Then apply with sysctl -p.
  • Why it works: This allows the kernel to queue more incoming connection requests (SYN packets) before accepting them, preventing drops when a service is temporarily overwhelmed.

2. Insufficient Socket Buffer Sizes

  • Diagnosis: Use sysctl -a | grep net.core.rmem_max and sysctl -a | grep net.core.wmem_max to see the current limits. High network latency or high bandwidth applications can exhaust these.
  • Fix: Increase the maximum receive and send buffer sizes. Edit /etc/sysctl.conf:
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    
    Apply with sysctl -p.
  • Why it works: Larger buffers give applications more room to accumulate incoming data before the application can process it, and more room to prepare outgoing data, reducing the chance of the kernel running out of space.

3. Too Many Open File Descriptors

  • Diagnosis: Check the ulimit -n for the user running the application. If this limit is low and the application is expected to handle many connections, it can lead to "no buffer space" errors indirectly as file descriptors are used for sockets.
  • Fix: Increase the open file descriptor limit. Edit /etc/security/limits.conf and add:
    * soft nofile 65536
    * hard nofile 65536
    
    Then, for systemd services, configure LimitNOFILE=65536 in the service unit file. Restart the service.
  • Why it works: Each network connection uses a file descriptor. A higher limit allows the system to maintain more simultaneous connections without running out of this fundamental resource.

4. Memory Pressure / OOM Killer

  • Diagnosis: Check dmesg for "Out of memory" or "Killed process" messages, especially related to kswapd0 or network-related daemons. Insufficient RAM can lead the kernel to reclaim memory aggressively, including network buffers.
  • Fix: Increase system RAM or reduce memory consumption by other processes. If immediate relief is needed, consider tuning vm.swappiness to a lower value (e.g., 10) in /etc/sysctl.conf to make the system less aggressive about swapping, but this is a temporary measure if RAM is truly insufficient.
  • Why it works: When the system is under severe memory pressure, the kernel may reclaim buffer memory to satisfy other critical processes, leading to the "no buffer space" error. More RAM or less consumption prevents this.

5. TCP Memory Limits (per socket)

  • Diagnosis: Check sysctl -a | grep net.ipv4.tcp_rmem and sysctl -a | grep net.ipv4.tcp_wmem. These define the min, default, and max buffer sizes for TCP sockets. If the default is too low and the application is creating many sockets, it can exhaust available memory.
  • Fix: Adjust the TCP socket buffer sizes. Edit /etc/sysctl.conf:
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096 16384 16777216
    
    Apply with sysctl -p.
  • Why it works: These parameters control the dynamic sizing of TCP send and receive buffers for each connection. Increasing the maximum allows individual connections to use more memory when needed for high-throughput or high-latency scenarios.

6. Network Interface Buffer Exhaustion (less common but possible)

  • Diagnosis: Use ifconfig -a or ip -s link show <interface_name> to check for dropped packets (RX-DRP, TX-DRP or similar counters). While this often indicates hardware issues or driver problems, very high traffic can saturate the buffers managed by the network driver.
  • Fix: This is harder to fix with sysctl. Sometimes increasing net.core.netdev_max_backlog can help:
    net.core.netdev_max_backlog = 2000
    
    Apply with sysctl -p. For persistent issues, driver updates or hardware upgrades might be necessary.
  • Why it works: This parameter sets the maximum queue length for packets that are received from the network device driver before the kernel processing starts. A larger backlog can absorb bursts of traffic.

After fixing these, you’ll likely hit "Too many open files" if you haven’t also addressed the ulimit settings.

Want structured learning?

Take the full Computer Networking course →