A Linux service that opens many short-lived outbound TCP connections to a single backend address starts failing with "cannot assign requested address". What resource has run out, what governs its size, and how would you fix it?

## The four-tuple is the resource TCP identifies a connection by four values: source IP, source port, destination IP, destination port. Two live connections may not share all four. When an application calls `connect()` without first calling `bind()`, the kernel silently chooses a source port on its behalf — an *ephemeral* port — and that choice must keep the four-tuple unique. The available pool is a sysctl: ``` sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999 ``` That is roughly 28,000 ports. Note carefully what the constraint is: the port must be unique *for that destination*, so 28,000 is not a global connection limit for the host. A machine can hold far more than 28,000 connections in total if they go to different destinations. Exhaustion is a per-destination phenomenon, which is exactly why it shows up when a service hammers one backend — one database, one internal API, one proxy — and never shows up in aggregate connection counts. ## Why TIME_WAIT makes it much worse In the request-per-connection pattern, the client is typically the side that closes, which makes it the active closer — and the active closer holds TIME_WAIT for 60 seconds on Linux. During that minute, that source port is unavailable for a new connection to the same destination. The arithmetic follows immediately: about 28,000 ports divided by 60 seconds gives roughly 470 new connections per second to a single destination before exhaustion. Cross that rate and `connect()` starts returning `EADDRNOTAVAIL`, which C reports as "Cannot assign requested address" and higher-level runtimes surface with wording of their own. The failure looks like a network or backend problem in application logs, which is what makes it a good interview scenario: the backend is perfectly healthy, and nothing on the network is wrong. The client has run out of a local kernel resource. ## The remedies, in order of how much they buy **Reuse connections.** This is the real answer and should be said first. An HTTP keep-alive pool, a database connection pool, a gRPC channel — anything that carries many requests over one connection — collapses the connect rate by orders of magnitude and removes the pressure entirely rather than deferring it. Every other measure is headroom. **Widen the range.** Lowering the bottom of `net.ipv4.ip_local_port_range` toward 1024 gains a few thousand ports. Do not overlap ports your host's own services bind, and remember it is a linear improvement against a problem that grows with traffic. **`net.ipv4.tcp_tw_reuse`.** Setting this allows the kernel to reuse a socket sitting in TIME_WAIT for a new *outgoing* connection when TCP timestamps show the old connection's segments cannot be confused with the new one. It targets precisely this client-side case. Its removed cousin `net.ipv4.tcp_tw_recycle` is not an option: it was deleted in Linux 4.12 for breaking clients behind NAT, and recommending it is a red flag. **Add source or destination addresses.** Because uniqueness is over the whole four-tuple, a second source IP doubles the space, and a backend reachable on several addresses or ports multiplies it the same way. If the application binds a specific source address before connecting, set `IP_BIND_ADDRESS_NO_PORT` on the socket — it tells the kernel not to pick a port at `bind()` time, when the destination is still unknown and the port must be globally unique, but to defer the choice to `connect()`, when the destination is known and the port only needs to be unique for that four-tuple. Without it, an explicit source bind can exhaust the range far earlier than necessary. **Change who closes.** If the server can be the one to close, TIME_WAIT accumulates there instead, where it does not consume a scarce client-side resource. This is often not under your control, but it is worth naming. ## Distinguishing the neighbouring failure Do not confuse this with `EADDRINUSE` ("Address already in use"), which is a `bind()`-time failure on a listening socket. `EADDRNOTAVAIL` at `connect()` time on an outbound-heavy client means ephemeral ports; the same client can also hit file-descriptor limits, which produce `EMFILE` ("Too many open files") instead. Three different resources, three different errnos — naming the right one is most of the diagnosis. ## The design lesson Ephemeral port exhaustion is almost always a symptom of a connection-per-request architecture that outgrew its traffic. Sysctl tuning raises the cliff; it does not remove it. The engineer who says "pool the connections, then tune for headroom, and alarm on the connect rate to each single destination" is answering at the level the question is really asked.