Dimensionamento de CGNAT para provedor: portas, capacidade e logging

Dimensionar CGNAT para provedor não é apenas dividir assinantes por endereços IPv4. A proporção escolhida afeta a experiência do cliente, a capacidade da borda, o volume de logs e o risco de exaustão de portas em horários de pico.

Este guia mostra quais dados levantar, como raciocinar sobre portas e blocos PBA, quais métricas acompanhar e quando vale revisar o desenho. Para uma implantação ou revisão completa, conheça o serviço de CGNAT para provedores da Baronix e combine o projeto com consultoria especializada em ISP.

O que significa dimensionar CGNAT?

CGNAT, também chamado de Carrier-Grade NAT ou NAT444, permite que vários assinantes compartilhem um conjunto limitado de endereços IPv4 públicos. O dimensionamento define os limites técnicos e operacionais desse compartilhamento.

Um projeto consistente precisa responder, pelo menos, a estas perguntas:

• Quantos assinantes estarão simultaneamente atrás do CGNAT?
• Quantos endereços IPv4 públicos estão disponíveis para a tradução?
• Qual é o consumo médio e de pico de portas por assinante?
• O equipamento suporta sessões, novas conexões por segundo e throughput com folga?
• Como os eventos de tradução serão armazenados, indexados e consultados?
• Quais métricas alertarão o NOC antes de uma falha perceptível?

Dados necessários antes de calcular a proporção

A proporção de assinantes por IP público deve partir de dados da operação, não de um número padrão copiado de outro provedor. Levante uma amostra que represente dias úteis, finais de semana e os horários mais carregados.

• Base ativa e simultaneidade: quantidade de clientes contratados, online e efetivamente navegando.
• Perfil de uso: streaming, jogos, IoT, câmeras, VPNs e aplicações com muitas conexões persistentes.
• Pool IPv4: endereços públicos utilizáveis, reservas, faixas por região e necessidade de expansão.
• Consumo de portas: média, percentil de pico e casos extremos por assinante.
• Plataforma: fabricante, modelo, licença, capacidade de sessões, throughput, CPS e recursos de alta disponibilidade.
• Logging: formato, destino, retenção, volume diário e tempo de consulta por IP, porta e horário.
• IPv6: plano de migração e serviços que já podem ser entregues nativamente, reduzindo pressão sobre o IPv4.

Como calcular portas no CGNAT

Cada IPv4 possui 65.536 portas TCP/UDP, mas nem todo o espaço deve ser tratado como capacidade operacional disponível. É necessário descontar reservas, políticas da plataforma e manter margem para picos, manutenção e comportamento desigual entre assinantes.

Como raciocínio inicial, use:

Exemplo didático: se a operação considerar 64 mil portas como referência operacional e dividir um IP entre 32 assinantes simultâneos, a conta de partida será de aproximadamente 2 mil portas por assinante. Esse resultado não é uma recomendação universal: aplicações, horários de pico, distribuição geográfica e política de alocação podem exigir uma proporção diferente.

O objetivo do cálculo é encontrar uma proporção que tenha margem. Uma operação que funciona apenas na média, mas esgota portas no pico, continuará apresentando falhas mesmo que o throughput contratado pareça suficiente.

PBA ou log por conexão: qual modelo considerar?

O Port Block Allocation (PBA) entrega ao assinante um bloco de portas durante uma janela definida. Em vez de registrar cada tradução individualmente, o provedor registra a associação entre bloco, IP público, assinante e período.

Na prática, o PBA pode reduzir muito o volume de logs e facilitar o planejamento de armazenamento. Porém, blocos grandes demais desperdiçam portas quando o assinante usa pouco; blocos pequenos demais podem provocar novas alocações, aumentar o volume de eventos e pressionar o equipamento.

O log por conexão oferece mais granularidade, mas pode gerar um volume elevado de dados. A escolha deve considerar a plataforma, o método de consulta, os requisitos de identificação da operação e a capacidade de manter os registros de forma íntegra. Para aprofundar a parte de compliance, leia também CGNAT e Marco Civil da Internet: logs e compliance para provedores.

Capacidade do equipamento e alta disponibilidade

Portas são apenas uma parte do dimensionamento. O equipamento ou cluster precisa suportar o crescimento de sessões e novas conexões sem operar constantemente no limite.

• Sessões simultâneas: acompanhe o uso atual e a capacidade licenciada ou suportada pelo fabricante.
• Novas conexões por segundo: picos de reconexão podem ser mais críticos que a média de tráfego.
• Throughput e pacotes por segundo: tráfego alto e pacotes pequenos podem pressionar recursos diferentes.
• Memória e CPU: observe tendências e não apenas o valor instantâneo.
• Redundância: avalie sincronização de estado, convergência e comportamento em falha.
• Expansão: deixe claro como adicionar IPs, nós ou capacidade sem redesenhar toda a borda.

Logging, retenção e consulta operacional

O logging precisa entrar no projeto desde o início. Em uma solicitação de identificação, não basta saber que um IP público estava em uso: a operação precisa conseguir cruzar IP público, porta, horário, protocolo e o identificador do assinante de acordo com o modelo adotado.

Defina o destino dos registros fora do roteador, o volume diário, a retenção aplicável, a rotação, o controle de acesso, o backup e o tempo máximo de resposta. O Marco Civil da Internet deve ser considerado junto às orientações jurídicas e às políticas de segurança da organização.

Uma arquitetura de monitoramento e observabilidade deve acompanhar tanto o plano de dados quanto a qualidade do logging. Se a consulta é lenta ou os registros não chegam ao destino, o problema é operacional mesmo que o CGNAT ainda esteja traduzindo tráfego.

Checklist de dimensionamento de CGNAT

Quando revisar o projeto de CGNAT

O dimensionamento deve ser revisado quando a base cresce, quando o perfil de consumo muda ou quando o provedor adiciona aplicações sensíveis a conexões. Também é um bom momento para revisar quando aparecem:

• reclamações concentradas no horário de maior utilização;
• falhas intermitentes em jogos, VPNs, câmeras ou notificações;
• crescimento de sessões sem aumento proporcional de capacidade;
• alertas tardios de uso de portas, CPU ou memória;
• logs difíceis de consultar ou sem correlação confiável;
• mudança de fabricante, topologia, pool IPv4 ou política de IPv6.

Para incidentes complexos ou mudanças de borda, o suporte N2/N3 para redes críticas ajuda a investigar causa raiz, validar o plano de mudança e reduzir o risco de indisponibilidade.

Perguntas frequentes

Conclusão

Um bom dimensionamento de CGNAT para provedor combina portas, sessões, throughput, pool IPv4, logging e observabilidade. A proporção entre assinantes e IPs públicos é apenas o começo: o projeto precisa suportar o pico, crescer com a base e permitir uma resposta operacional confiável.

Se o seu provedor está ampliando a base, enfrentando exaustão de portas ou precisa revisar o logging, solicite um diagnóstico de CGNAT com a Baronix. A equipe atua com redes de provedores, ambientes multivendor e suporte técnico especializado.