Redes geográficas na prática
O que sao redes geograficas é uma pergunta que todo engenheiro de redes ouça nos primeiros anos de carreira. A resposta curta existe em qualquer livro-texto, mas o que realmente importa acontece quando você coloca isso no chão de fábrica. Rede geográfica, ou WAN, é simplesmente a interligação de redes locais separadas por grandes distâncias — cidades, estados, países. O difícil não é entender o conceito. O difícil é lidar com o que acontece quando o enlace entre São Paulo e Recife tem 120ms de latência e 50Mbps assimétricos. Uma WAN conecta sites distintos usando técnicas que vão desde circuitos dedicados até túneis sobre a internet pública. As duas categorias principais hoje são MPLS e SD-WAN. MPLS é a tecnologia tradicional, aquela em que o provedor monta uma rede privada sobre sua própria infraestrutura e te vende um link com SLA garantido. SD-WAN é a evolução mais recente, onde você agrega múltiplos enlaces de internet (braço primário e backup) e uma camada de inteligência gerencia o tráfego dinamicamente entre eles.
o que sao redes geograficas e como funcionam no dia a dia
No nível mais básico, uma WAN usa roteamento para levar pacotes do ponto A ao ponto B. Mas o que diferencia uma implementação competente de uma que funciona apenas no papel é como você lida com três variáveis: largura de banda, latência e perda de pacotes. A maioria dos artigos ignora a latência. Ela é o fator que mais destrói a experiência do usuário em WAN. Para montar uma conexão MPLS tradicional, o processo padrão envolve solicitar circuito ao provedor, aguardar a instalação física (pode levar de 60 a 120 dias úteis), configurar os equipamentos de borda com rotas estáticas ou OSPF sobre o circuito point-to-point, e aplicar políticas de QoS. Cada site deve ter um router de borda com interface dedicada ao MPLS, geralmente encapsulamento 802.1Q para VLANs de serviço.
Já o SD-WAN segue um fluxo diferente. Você instala um appliance ou software em cada site, ele descobre automaticamente os links disponíveis, mede latência, jitter e perda em tempo real, e toma decisões de forwarding baseadas em application-aware policies. Um link de 100Mbps com boa qualidade pode receber todo o tráfego de voz e vídeo, enquanto um link secundário de 50Mbps com perda de 2% entra apenas para backup ou tráfego tolerante a atrasos. Aqui vai algo que quase ninguém explica direito: shaped QoS. Priorização sem shaping não funciona em enlaces assimétricos. Eu configurei QoS em uma filial no interior de Minas Gerais com uplink de 10Mbps e downlink de 50Mbps. O provedor entregava simétrico de 10Mbps. Configurei classes para Voz, Vídeo e Dados com pesos adequados. Testes de throughput mostravam que a voz funcionava bem em teoria, mas na prática as chamadas caíam durante horários de pico. O problema era simples: o buffer de egressa enchia porque o uplink real era menor que a soma das classes priorizadas. A solução foi configurar shaping de 8Mbps na saída, não 10. Deixei uma margem de 20% para overhead de protocolo e filas. A partir daí, o scheduler conseguia manter as filas ordenadas sem saturação. Isso resolveu as quedas instantaneamente.
Outro detalhe técnico que merece atenção é o bandwidth-delay product. Um enlace de 100Mbps com 150ms de RTT tem um BD de aproximadamente 1,875Mbytes. Isso significa que, sem window scaling adequado no TCP, o throughput efetivo de backups e transferências de arquivos pode cair para menos de 2Mbps mesmo em um link que tecnicamente oferece 100Mbps. A consequência é que sua política de backup noturno, que levaria 3 horas em LAN, passa a levar 18 horas em WAN. A solução não é aumentar banda. É usar appliances de deduplicação e compressão ou protocolos como rsync com deltas, que reduzem o volume em 80 a 90% antes de transitar pela rede. Várias implementações que eu vi falharam porque alguém aplicou políticas de QoS de campus diretamente em enlace WAN sem considerar a assimetria. O resultado é sempre o mesmo: buffers enchendo, latência subindo, aplicações sensíveis sofrendo. Configure sempre shape-rate junto com class-map e policy-map. Não confie em polices de priorização pura.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Limitações que nenhuma venda te conta
MPLS continua sendo a escolha certa para operações financeiras e setores regulados onde o SLA de disponibilidade e latência é contrato. Mas o custo é elevado. Um circuito MPLS punto a punto de 50Mbps no Brasil pode custar entre R$3.000 e R$8.000 mensais por trecho, dependendo da região e do provedor. A instalação leva meses. A expansão também. SD-WAN resolve parte desses problemas, mas introduz outros. A depender do provedor, a camada de orquestração cloud pode se tornar um ponto único de falha. Se o controller cair, novos sites não conseguem fazer auto-discovery e os appliances existentes operam em modo degradado por tempo limitado. A maioria dos provedores oferece HA no controller, mas isso encarece o pacote.
Link simétrico não é padrão no mercado brasileiro para conexões comerciais. A maioria dos planos de internet empresarial entrega proporção 5:1 ou até 10:1 a favor do downlink. Isso quebra qualquer configuração de QoS baseada apenas em priorização. Shaping é obrigatório nesses cenários. Protocolos legacy que usam conexões persistentes e não suportam multipath enfrentam problemas sérios em SD-WAN. Um sistema de ERP com connection pooling configurado para um IP fixo pode ter sessões caírem quando o overlay redireciona o tráfego para um link de backup. A resolução exige configuração de sticky sessions ou bind por interface no aplicativo.
Quando evitar WAN convencional
Se você tem mais de 20 sites e cada um precisa de conexão dedicada, MPLS puro pode inviabilizar o orçamento. Nesse caso, uma arquitetura híbrida com SD-WAN em links primários de internet e MPLS apenas para enlaces críticos entre datacenters centro-cidade tende a apresentar melhor custo-benefício. A manutenção também é menor, porque a camada de orquestração centralizada substitui configurações manuais em cada router. Para satélites, a latência é intrínseca. Geostacionário entrega 600ms de RTT no mínimo. Nenhuma política de QoS resolve isso. Aplicações que dependem de resposta interativa — como telnet, SSH longo, bancos de dados distribuídos — simplesmente não funcionam. A alternativa é mover o processamento para perto do usuário final e usar replicação síncrona apenas para dados críticos em enlaces terrestres.
Checklist prático antes de implementa
Meça a assimetria real dos seus enlaces. Anote latência, jitter e perda em horário comercial e fora dele. Não confie nas especificações do contrato. Teste com iPerf3 e OpenPath durante pelo menos uma semana. Aplique shaping de 80% da velocidade do enlace mais lento antes de configurar qualquer política de classificação. Deixe os buffers respirarem. Configure MTU de 1492 em túneis PPPoE para evitar fragmentação. Use BFD para detecção rápida de falha em enlaces MPLS. E teste failover regularmente. A maioria dos SLAs de WAN é inútil se o mecanismo de failover nunca foi validado em produção. Rede geográfica é infraestrutura crítica. O projeto que parece funcionar no laboratório frequentemente colide com a realidade dos enlaces quando colocado em produção. Entender como o tráfego realmente se comporta sob assimetria e latência alta separa quem implementa WAN de quem apenas configura roteadores e torce para dar certo.
