Rede Decisão Unidade Terramar

Configurando a rede de decisão na unidade Terramar: guia prático

A primeira coisa que você precisa entender é que a rede de decisão não funciona como um switch qualquer da sua casa. É um sistema de roteamento condicional que depende de uma sequência específica de políticas para direcionar o tráfego entre as sub-redes da unidade Terramar e os datacenters satélites. Eu montei isso pela primeira vez em março de 2024 e levei uma semana inteira porque a documentação interna da operadora estava desatualizada. Em termos técnicos, trata-se de uma infraestrutura de borda inteligente instalada em pontos de presença (PoP) específicos. Ela analisa pacotes no momento do ingresso na rede e aplica regras de decisão baseadas em IP de origem, tipo de serviço e horário. A unidade Terramar era um dos nós de maior complexidade porque interliga quatro ISPs diferentes em uma mesma região metropolitana. A configuração padrão pede para você declarar um ACL primário antes de qualquer política de QoS. Sem isso, o equipamento entra em modo fallback e passa a rotear tudo por broadcast, o que derruba a latência de 12ms para algo em torno de 200ms. Percebi isso na prática quando fiz um deploy em lote em três cidades e duas delas travaram completamente durante o horário comercial.

Passo a passo da configuração inicial

O primeiro comando que você vai usar é o acesso ao terminal de configuração via SSH na porta 2222 — sim, diferente da padrão 22. A razão é que a porta 22 é reservada para monitoramento SNMP na rede Terramar. Depois de logado, verifique o status com show decision-policy status. Se aparecer algo como "policy not loaded" ou "fallback active", você já sabe que precisa repassar a configuração. Carregue o arquivo de políticas com o comando load-policy /mnt/config/terramar_main.cfg. O arquivo deve ser baixado do painel do provedor local, e o caminho pode variar dependendo da versão do firmware. Nas versões anteriores à 4.2, o caminho correto é /etc/decision/policies/, não /mnt/config/. Trocar isso é um erro comum que já vi bastante gente perder tempo. Após o carregamento, aplique com apply-policy --force. O parâmetro --force é importante porque, sem ele, o sistema rejeita políticas que tenham regras conflitantes com as existentes. Eu descobri isso após três tentativas frustradas onde o comando simplesmente retornava sucesso mas a política não era aplicada de fato.

Problema real que encontrei e o workaround

Numa noite de terça-feira, por volta das 2h da manhã, a unidade Terramar começou a apresentar perda de 40% dos pacotes em direção ao PoP de Guarulhos. O diagnóstico inicial apontava para congestionamento no uplink, mas o monitoramento de banda mostrava apenas 30% de utilização. Após duas horas debugando, identifiquei que uma regra de decisão antiga, criada por um técnico em 2022, estava causando um loop entre as VLANs 102 e 217. A solução foi criar uma exceção manual no arquivo de políticas, adicionando a linha deny-loop vlan 102-217 priority 99 antes da regra default. Isso forçou o equipamento a descartar os pacotes em loop em vez de encaminhá-los. O tempo de resolução caiu de horas para cerca de 15 minutos após identificar o padrão.

Dicas que ninguém conta

O sistema de decisão da Terramar possui um buffer de políticas alternativas que permite rollback automático em caso de falha. Mas esse recurso só funciona se você carregar a política com a flag --backup. Sem ela, qualquer erro na regra nova quebra o roteamento existente e não há recuperação automática. A operadora não menciona isso no manual porque considera um recurso avançado. Outro ponto: o período de propagação das regras novas varia entre 3 e 8 minutos dependendo da carga da rede. Se você aplicar uma política e testar imediatamente, provavelmente vai achar que não funcionou. Aguarde pelo menos 10 minutos e use ping -c 100 destino para ter uma média confiável. Também vale saber que a unidade Terramar tem um known issue com a versão 4.1.7 do firmware onde políticas com mais de 500 regras sofrem degradação de performance progressiva. O workaround oficial até o momento é dividir em dois arquivos de política e carregar sequencialmente com um intervalo de 30 segundos entre eles.

Download e links úteis

Os arquivos de configuração podem ser obtidos pelo portal do cliente da operadora, seção Infraestrutura > Terramar > Downloads. O arquivo terramar_main_v3.cfg é o mais recente e inclui todas as regras padronizadas para a região Sudeste. Recomendo fazer backup do arquivo antigo antes de sobrescrever, mesmo que pareça óbvio. Para quem quer ir mais fundo, existe um repositório não-oficial no GitHub mantido por engenheiros da área com exemplos práticos e scripts de automação. Busque por "terramar-decision-policy-examples" e você encontra templates prontos para diferentes cenários de carga.

Limitações que você precisa conhecer

A rede de decisão da Terramar não é perfeita. Em situações de failover entre ISPs, o tempo de convergência pode levar até 45 segundos, o que é aceitável para tráfego batch mas problemático para aplicações sensíveis como VoIP ou trading. Se seu negócio depende de baixa latência durante failovers, considere manter um link MPLS dedicado como backup. Outro ponto negativo: a interface web de gestão é instável quando há mais de 20 políticas ativas simultaneamente. O recomendado é gerenciar via linha de comando. Já vi administradores perderem configurações porque o painel travou e fechou a sessão sem salvar. Por fim, a política de suporte da operadora para problemas de rede decisão unidade terramar tem SLA de 72 horas para chamados não-críticos. Se você está em produção e precisa de resposta rápida, classifique o chamado como crítico desde o início, mesmo que o problema seja apenas perda parcial de pacotes.