IPAM de verdade: o fim da planilha de IP no provedor

Todo provedor começa com uma planilha de IP. Uma aba para o bloco IPv4 do upstream, outra para o /29 de gerência, uma cor para "em uso" e outra para "livre". Funciona até o dia em que para de funcionar: ninguém sabe se aquele endereço de CGNAT (100.64.0.0/10) está num cliente ativo ou num roteador desativado há meses, dois técnicos alocam o mesmo /30 de transporte e o link cai, e o IPv6 que o registro.br já entregou continua intocado porque "depois a gente organiza". A planilha não escala. Ela apenas adia o problema até ele virar incidente.

Este artigo é sobre por que isso acontece e o que um IPAM (IP Address Management) de verdade resolve no contexto de um ISP brasileiro.

Por que a planilha sempre desmorona

O problema da planilha não é o Excel. É o modelo mental. Uma planilha trata IP como uma lista de strings, quando endereçamento de provedor é, na prática, um sistema de relações:

• Um prefixo IPv4 ou IPv6 pertence a um bloco alocado pelo LACNIC (no Brasil, via registro.br), atrelado a um ASN e a responsabilidade legal por trás.
• Cada sub-rede vive dentro de uma VLAN, que vive numa interface, que vive num equipamento (Mikrotik, Cisco, Huawei, Juniper) numa POP específica.
• Blocos de transporte, loopbacks e gerência costumam estar em VRFs separadas. Na planilha, o 192.168.10.1 da VRF de gerência e o 192.168.10.1 de um cliente parecem o mesmo IP, mas não são.
• O que você anuncia no BGP para o IX.br e para os trânsitos é um recorte específico desse endereçamento, e ele precisa bater com o que está realmente em uso e com seus objetos de rota e ROAs (IRR/RPKI).

A planilha não modela nada disso. Ela não sabe que um /24 foi quebrado em quatro /26, não impede alocação duplicada, não avisa que você anunciou um prefixo sem rota interna, e não tem ideia de qual cliente ou circuito está na ponta. Toda essa inteligência fica na cabeça de uma ou duas pessoas. Quando elas saem de férias — ou da empresa — a rede vira caixa-preta.

O que "IPAM de verdade" significa

Um IPAM real não é uma planilha mais bonita. É uma fonte única de verdade onde o endereçamento é tratado como árvore hierárquica e relacional. Na prática:

• Hierarquia de prefixos: você cadastra o supernet (o bloco IPv4 e o IPv6 que o LACNIC/registro.br entregou) e quebra em sub-redes. O sistema sabe que o /26 é filho do /24, calcula a utilização real e mostra o que ainda está livre sem você contar octeto na mão.
• Estado por endereço: cada IP tem estado — reservado, alocado, em uso, depreciado —, o que elimina o clássico "achei que estava livre".
• Amarração com a rede física e lógica: o prefixo aponta para a VLAN, a interface, o equipamento e a POP. O IP de gerência sabe a qual roteador pertence.
• Separação por VRF / contexto: endereçamento de transporte, de gerência e de cliente convivem sem colidir, porque o IPAM entende contexto, não só o número.
• IPv6 como cidadão de primeira classe: nada de IPv6 como apêndice. Com o espaço que o registro.br entrega, planejar um /56 ou /64 por cliente só é sustentável com hierarquia automática.
• Visão de BGP junto: saber quais prefixos você de fato anuncia, para quem (IX.br, trânsitos), e cruzar isso com o que está alocado internamente fecha o ciclo entre "o que existe" e "o que o mundo vê".

A diferença prática: numa planilha você procura um IP livre; num IPAM você pede o próximo prefixo disponível e ele já nasce com dono, VLAN e equipamento amarrados.

VLAN, VRF e BGP no mesmo lugar — não em três planilhas

O que mais dói no provedor é que esses dados moram em silos. A planilha de IP é uma. O mapa de VLANs é outra (às vezes só na cabeça do projetista). As VRFs estão na config do roteador. O que é anunciado no BGP está num filtro de export que ninguém revisa desde a instalação. Quando algo quebra de madrugada, o plantonista do NOC tem que reconstruir essa relação no susto, abrindo SSH em cinco equipamentos.

Manter IP, VLAN, VRF e BGP no mesmo modelo de dados muda o jogo operacional:

• Diagnóstico fica mais rápido: a partir do IP do cliente que reclama, você chega à VLAN, à interface, ao equipamento e à POP em segundos.
• Mudanças ficam auditáveis: quem alocou, quando, para qual circuito.
• Onboarding de técnico novo deixa de depender de conhecimento tribal.
• Conformidade fica natural: o Marco Civil da Internet exige a guarda de registros de conexão, e amarrar IP a cliente e a janela de tempo de forma estruturada é parte de conseguir responder a uma ordem judicial sem virar a noite garimpando log.

É aqui que o NetPulse entra

O NetPulse, plataforma de NOC da CloudFace, foi desenhado para acabar com a planilha de IP sem virar mais uma ferramenta isolada. O IPAM não vive sozinho: ele compartilha o mesmo inventário (DCIM) que o monitoramento SNMP, a documentação e o cofre de credenciais com 2FA.

Na prática, isso significa que o prefixo alocado no IPAM já está ligado ao equipamento que o NetPulse monitora, à VLAN documentada e às credenciais de acesso daquela POP. Por ser multi-tenant, quem opera vários CNPJs, marcas ou clientes mantém cada endereçamento isolado, sem misturar blocos. O IPv6 entra com hierarquia desde o primeiro dia, e a relação entre o que está alocado e o que é anunciado deixa de ser exercício de fé.

Não é mágica: é parar de tratar IP como texto e começar a tratar como infraestrutura.

Por onde começar

A migração da planilha para um IPAM não precisa ser um big bang. O caminho que funciona é cadastrar primeiro os supernets que o LACNIC/registro.br entregou, importar o que já está em uso (mesmo que imperfeito) e ir corrigindo o estado conforme a operação toca em cada bloco. Em poucas semanas a planilha vira histórico.

Se o seu provedor ainda vive de planilha de IP — ou de várias planilhas que não conversam — a CloudFace pode ajudar nos dois ângulos: consultoria e NOC para estruturar endereçamento, VLANs e BGP, e o NetPulse para manter tudo isso vivo num lugar só. Chame no WhatsApp para um diagnóstico inicial gratuito do seu endereçamento. Sem compromisso, e você já sai sabendo onde está o caos.