Calcula la utilización de puertos SNAT por instancia o en un pool NAT, con la tabla de asignación publicada por Azure y los temporizadores reales.
Tomado de la tabla de asignación por defecto de Azure Load Balancer. Cada instancia del backend recibe estos puertos por cada IP de frontend, hasta un máximo de 1024: pasado ese punto, las IPs de frontend adicionales no suman nada. La propia guía de Microsoft desaconseja la asignación por defecto en producción.
| Tamaño del pool | Puertos por instancia y por IP de frontend |
|---|---|
| 1–50 | 1024 |
| 51–100 | 512 |
| 101–200 | 256 |
| 201–400 | 128 |
| 401–800 | 64 |
| 801–1000 | 32 |
Azure retiene un puerto SNAT 65 segundos después de que un TCP FIN cierre la conexión, y 16 segundos tras un TCP RST. Una conexión inactiva retiene su puerto hasta que expira el tiempo de inactividad, configurable entre 4 y 120 minutos, y Microsoft desaconseja subirlo precisamente porque los temporizadores largos hacen más probable el agotamiento. Una NAT gateway evita del todo el problema de la preasignación: agrupa 64.512 puertos por IP pública y los reparte bajo demanda.
También podrías encontrar útiles estas calculadoras
Red, difusión, máscara y hosts utilizables de una subred IPv4
Convierte CIDR en rango, divide un bloque o agrega bloques
Calcula el producto ancho de banda-retardo y la ventana TCP necesaria
Cuántos usuarios admite un servidor y qué lo limita
Las conexiones salientes fallan cuando un dispositivo NAT se queda sin puertos de origen que darles. En Azure eso ocurre por instancia del backend, no en el conjunto del balanceador, y por eso un pool con miles de puertos libres puede seguir rechazando conexiones nuevas desde una sola VM. Indica tu perfil de conexiones y esta calculadora calcula cuántos puertos ocupa de verdad cada host o instancia, incluidos los que siguen en retención tras cerrarse la conexión, que es donde se va la mayoría.
Cada conexión saliente necesita un puerto de origen único en la IP pública por la que sale. Una IP pública tiene 65.535 puertos; Azure habilita 64.000 para SNAT en un frontend de balanceador y 64.512 en una NAT gateway. Un puerto no queda libre en cuanto se cierra la conexión: Azure lo retiene 65 segundos tras un TCP FIN y 16 tras un TCP RST. Así que los puertos que ocupa una carga son las conexiones que tiene abiertas MÁS las que abrió y cerró hace poco, que con conexiones cortas es la mitad más grande.
Puertos ocupados
El síntoma son tiempos de espera hacia un destino mientras todo lo demás funciona. Comprueba si el límite es la asignación de una sola instancia.
Calcula cuántas IPs públicas necesita una carga antes de moverla, en vez de después de que empiece a fallar.
Compara una porción fija preasignada con un inventario agrupado y bajo demanda, con tu propio perfil de conexiones.
Mira qué parte de tu presupuesto de puertos se va en retención por culpa de las conexiones cortas: ese es el argumento para reutilizarlas.
Microsoft lo dice sin rodeos: una instancia del backend puede quedarse sin sus puertos asignados mientras al balanceador le sobran. Una media del conjunto no te enseña el fallo.
Un pool de 300 instancias recibe 128 puertos por instancia y por IP de frontend. No 64.000: 128. La tabla de esta página es la de Azure.
La asignación por defecto está limitada por instancia. Añadir una tercera IP de frontend a un pool pequeño no aporta absolutamente nada, y eso no se ve en el portal.
Una conexión que vive cinco segundos y luego retiene su puerto sesenta y cinco pasa cerrada casi toda la vida de ese puerto. Reutilizar conexiones es la solución, y por eso el campo de retención cambia la respuesta.
Demasiadas conexiones salientes simultáneas desde una misma instancia del backend hacia el mismo destino, frente a los puertos que esa instancia tiene asignados. Cada conexión a una IP y un puerto de destino distintos necesita su propio puerto SNAT, y el puerto queda inutilizable 65 segundos después de que un TCP FIN lo cierre. Las aplicaciones que abren una conexión nueva por petición en lugar de reutilizar una lo sufren primero: las conexiones serán breves, pero el puerto de cada una queda ocupado un minuto después.
Depende del método de salida. Con la asignación por defecto de un balanceador sale de la tabla de Azure según el tamaño del pool: 1.024 puertos por instancia para un pool de 1 a 50, 512 para 51-100, 256 para 101-200, 128 para 201-400, 64 para 401-800 y 32 para 801-1.000, por cada IP de frontend y con un tope de 1.024 por instancia. Una NAT gateway, en cambio, agrupa 64.512 puertos por IP pública y los reparte bajo demanda, sin preasignación.
En una NAT gateway sí: cada IP pública suma 64.512 puertos al pool compartido. En un balanceador con asignación por defecto, solo hasta cierto punto: la asignación por instancia está limitada a 1.024 puertos por muchas IPs de frontend que añadas, así que un pool pequeño que ya esté en el tope no gana nada. A partir de ahí, o asignas puertos a mano con una regla de salida o te pasas a una NAT gateway, que es lo que recomienda Microsoft.
Porque los puertos están preasignados por instancia. Microsoft lo afirma directamente: el agotamiento se produce cuando una instancia del backend se queda sin los puertos que le dieron, y el balanceador puede seguir teniendo puertos sin usar. La cifra del conjunto no es la que decide si tu próxima conexión funciona, y por eso el modo Azure de esta calculadora informa por instancia.
Sí, y subirlo empeora las cosas. Una conexión inactiva conserva su puerto SNAT hasta que expira el tiempo de espera, configurable entre 4 y 120 minutos. Microsoft desaconseja aumentarlo justo por eso y propone en su lugar keepalives de TCP, que refrescan una conexión larga sin retener puertos de más.