A cena é conhecida por quase todo suporte técnico de provedor: um cliente liga dizendo que "a internet caiu", que páginas de bancos dão timeout ou que os jogos online desconectam a cada dez minutos. O atendente abre a tela de monitoramento do NOC e tudo parece impecável: a ONU está com sinal óptico de -19 dBm, o ping na CPE responde com 2 milissegundos e a interface da OLT tem banda de sobra.
Para a equipe de atendimento, parece reclamação de quem não entende de rede. Mas o assinante tem toda razão: a conexão física está de pé, mas a navegação quebrou no meio do caminho dentro da caixa de CGNAT.
Com o esgotamento global de endereços IPv4, o Carrier-Grade NAT (CGNAT) se tornou a espinha dorsal da entrega de internet no Brasil. No entanto, muitos provedores ainda operam o CGNAT no escuro, monitorando apenas o consumo de CPU do equipamento e a vazão de tráfego em gigabits. Quando as portas alocadas acabam, o cliente é desconectado e o NOC é o último a saber.
A matemática invisível do CGNAT
No modelo padrão de CGNAT regulado pela RFC 6888 e pelas recomendações do Ceptro.br/NIC.br, o provedor entrega aos clientes endereços privados do bloco reservado 100.64.0.0/10. Na saída para a internet, esses milhares de IPs privados compartilham uma quantidade limitada de IPs públicos válidos.
Cada endereço IPv4 público dispõe teoricamente de 65.535 portas TCP e UDP. Como as portas baixas (0 a 1.023) são reservadas e algumas faixas são preservadas pelo sistema operacional, sobram cerca de 64.000 portas utilizáveis por IP público.
Para garantir rastreabilidade jurídica (exigida pelo Marco Civil da Internet) sem sobrecarregar bancos de log a cada conexão, os provedores utilizam principalmente a alocação determinística ou por blocos fixos (Port Block Allocation - PBA):
- Se você aloca 1.000 portas por assinante, cada IP público atende 64 clientes.
- Se você aloca 2.000 portas por assinante, cada IP público atende apenas 32 clientes.
Parece muito, mas as aplicações modernas são predadoras de portas. Uma única página web pesada com dezenas de scripts, anúncios e chamadas de API abre facilmente de 80 a 150 sessões simultâneas. Some a isso uma TV conectada transmitindo vídeo em 4K, dois smartphones sincronizando fotos em segundo plano, um console de videogame e aplicações de mensagens, e uma residência comum pode esgotar seu bloco de portas em instantes de pico.
Quando o limite é atingido, o roteador de CGNAT não avisa o cliente com uma mensagem simpática: ele descarta o pacote silenciosamente (port allocation drop). Para o usuário, a sensação é de queda total ou lentidão severa.
As 4 métricas de CGNAT que seu Zabbix precisa coletar
Para transformar o CGNAT de um ponto cego em um serviço previsível, o NOC precisa monitorar quatro indicadores essenciais:
- Taxa de ocupação de blocos por pool público (%): quantos por cento dos blocos de portas disponíveis no pool de IPs públicos já foram alocados para clientes ativos. Se essa métrica passa de 80%, você está perto de deixar novos clientes sem navegação ao autenticarem.
- Sessões ativas por caixa (State Table): o total de conexões simultâneas abertas no hardware. Todo roteador ou servidor de CGNAT (seja MikroTik, Huawei NE40E, Cisco, DanOS ou appliances dedicados como A10) possui um limite físico de memória para armazenar a tabela de conexões.
- Descartes por falta de porta (Port Allocation Failures): o contador mais crítico de todos. Em condições normais, essa métrica deve ser rigorosamente zero. Se ela começar a registrar subidas contínuas, significa que clientes reais já estão tomando timeout e perdendo conexões.
- Clientes com consumo anômalo de conexões: identificar os assinantes que mais consomem sessões simultâneas na rede. Na maioria esmagadora das vezes, um cliente com 3.000 ou 4.000 conexões abertas não é uma família assistindo filmes, mas um computador ou roteador residencial infectado gerando varreduras de portas ou participando de ataques distribuídos.
Como estruturar os alarmes no NOC
Monitorar CGNAT com limiares genéricos não funciona. O ideal é estruturar a coleta no Zabbix via SNMP ou scripts de telemetria com gatilhos de múltiplos níveis:
- Alerta de Capacidade do Pool (Warning aos 75% | High aos 90%): avisa a engenharia de tráfego com dias ou semanas de antecedência sobre a necessidade de alocar novos blocos IPv4 ao pool ou reajustar o tamanho dos blocos de portas antes do próximo final de semana.
- Alerta de Falha de Alocação (Disaster se
rate > 10 drops/spor 3 minutos): se a caixa começa a descartar conexões por exaustão de portas, o plantão do NOC deve agir imediatamente, pois o impacto na base é generalizado. - Alerta de Saturação de Hardware (Average se a CPU da caixa passar de 75%): a criação e encerramento massivo de sessões de CGNAT exige processamento intensivo. Roteadores que operam no limite de CPU sofrem atrasos no processamento de pacotes (jitter) que prejudicam ligações VoIP e streaming.
Reduzir o peso do CGNAT: o papel do IPv6
A melhor estratégia para não sofrer com esgotamento de CGNAT é simples: fazer com que o tráfego do cliente nem precise passar por ele.
Hoje, os maiores geradores de tráfego da internet brasileira — Google/YouTube, Meta (Instagram/WhatsApp/Facebook), Netflix, TikTok, Cloudflare e Akamai — operam 100% em IPv6 nativo. Quando o seu provedor entrega IPv6 com prefixo /56 bem configurado até a CPE do assinante, mais de 60% a 70% de todo o volume de tráfego deixa de tocar o CGNAT e vai direto para a internet sem tradução de endereços.
Cada cliente navegando em IPv6 é um bloco de portas que sobra para os serviços legados que ainda dependem de IPv4.
Operação transparente
O diferencial de um provedor profissional é antecipar a falha antes que o cliente sinta. Medir a saúde dos seus pools de CGNAT no monitoramento garante que você saiba exatamente quando expandir infraestrutura sem depender de reclamações nas redes sociais.
Se você quer cruzar a telemetria do seu Zabbix com a localização real de cada POP e enlace de fibra, conheça como o NOC Geomap traz clareza geográfica para a operação.
Fontes: Ceptro.br / NIC.br — Boas Práticas para Redes com CGNAT, IETF RFC 6888 — Common Requirements for Carrier-Grade NATs, IPv6.br — Recomendações para Provedores de Acesso.