Geofeed: por que seus IPs aparecem na cidade errada e como começar a corrigir isso
Quem trabalha com provedor de Internet provavelmente já viu esse tipo de reclamação: “Meu cliente está no Paraná, mas o site acha que ele está em São Paulo.”“O streaming está dizendo que estou em outro país.”“O banco bloqueou o acesso porque achou estranho o local do IP.”“O Google está mostrando previsão do tempo de outra cidade.” É uma situação meio ingrata, porque na maior parte das vezes a rede está funcionando. O cliente navega, o BGP está ok, o DNS responde, o traceroute chega, a latência está aceitável. Mas, para o usuário final, a percepção é simples: alguma coisa está errada com a Internet dele. E, muitas vezes, está mesmo. Não na conectividade, mas na forma como aquele endereço IP está sendo geolocalizado por terceiros. IP não tem cidade gravada dentro dele A primeira coisa importante é entender que um IP não nasce com uma cidade dentro dele. Não existe, no protocolo IP, um campo dizendo: ou: A geolocalização por IP é uma inferência. Empresas de conteúdo, bancos, CDNs, plataformas antifraude, buscadores, serviços de streaming e bases comerciais tentam descobrir onde aquele IP provavelmente está sendo usado. Para isso, elas cruzam várias informações: dados de registros de Internet, comportamento de tráfego, medições, histórico, informações de usuários, bases comerciais, DNS, BGP, entre outras coisas. Na maioria dos casos funciona bem o suficiente. Mas quando erra, incomoda bastante. Um provedor pode receber um bloco novo, comprar ou transferir recursos, mudar prefixos entre cidades, ativar um POP novo, reorganizar CGNAT, dividir IPv6 por região, trocar upstreams ou simplesmente começar a usar um bloco que antes estava associado a outra localidade. Só que as bases externas podem demorar para aprender isso. E aí começam os chamados. Onde entra o geofeed O geofeed é uma forma padronizada do próprio operador da rede dizer: “Estes prefixos IP estão sendo usados nestas localidades.” Ele não muda o roteamento. Não mexe no BGP. Não anuncia nada para a Internet. Não é uma sessão com upstream. É só um arquivo CSV publicado em HTTPS, seguindo um formato definido na RFC 8805 [1]. Um exemplo simples: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Cada linha associa um prefixo a uma localização aproximada. O formato é: Na prática: quer dizer: A vírgula no final é importante. Ela representa o último campo, postal_code, vazio. O que cada campo significa O primeiro campo é o prefixo IP. Pode ser IPv4 ou IPv6, em formato CIDR. Exemplos: O segundo campo é o país, usando ISO 3166-1 alpha-2. Para Brasil, usamos BR. O terceiro campo é a região, usando ISO 3166-2. No caso dos estados brasileiros: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul A lista oficial pode ser consultada na plataforma da ISO [4]. Para consulta rápida, também existe a página ISO 3166-2:BR, que lista os códigos dos estados brasileiros [5]. O quarto campo é a cidade. O quinto campo é o código postal. Ele existe no formato, mas normalmente não recomendo usar para provedor. A própria RFC trata esse campo com cuidado, porque ele pode dar uma granularidade exagerada [1]. Para ISP, na maioria dos casos, país, estado e cidade já são suficientes. Geolocalização é aproximação, não GPS Esse ponto é mais importante do que parece. Quando falamos de geofeed, é fácil cair na tentação de tentar ser preciso demais. Mas geolocalização por IP não é GPS. Na NANOG 96, o Sid Mathur apresentou uma palestra chamada High-quality IP Geofeeds using AI Coding Assistants and MCP. Uma das mensagens mais úteis da apresentação é justamente essa: geolocalização IP é estatística e inexata. O ideal é pensar em regiões geográficas, não em um ponto exato no mapa [6]. Ele dá uma provocação boa: mais precisão nem sempre significa mais qualidade. Para um ISP fixo, que sabe que determinado prefixo atende uma cidade específica, faz sentido informar a cidade: Mas se o mesmo prefixo atende várias cidades próximas, talvez seja melhor parar no estado: Isso evita resolver o problema de um cliente e criar problema para outro. Na mesma apresentação, ele também comenta casos bem reais: usuários bloqueados por conteúdo regional, streaming achando que a pessoa está em outro país, site mostrando clima errado e ISPs recebendo reclamações por algo que, muitas vezes, está fora da camada de conectividade [6]. Quem vive operação sabe que isso acontece. O geofeed resolve tudo? Não. E é importante ser honesto aqui. Publicar geofeed não obriga Google, Netflix, bancos, MaxMind, IPinfo, Cloudflare ou qualquer outro consumidor a aceitar imediatamente aquela informação. A RFC 8805 trata o geofeed como uma fonte publicada pelo operador. Os consumidores podem coletar, validar, cruzar com outras bases e decidir se vão usar ou não [1]. Mesmo assim, publicar corretamente melhora muito sua posição. Antes, você dependia de abrir chamado manual em várias bases diferentes, cada uma com um processo. Com geofeed, você cria uma fonte pública, padronizada e descobrível automaticamente. Não é garantia de correção instantânea, mas é uma prática operacional muito melhor. Como os outros descobrem seu geofeed? Publicar o arquivo em uma URL é só parte da história. Você precisa indicar, nos registros do bloco IP, onde está esse arquivo. É aí que entra a RFC 9632 [2]. Ela define como associar um arquivo geofeed aos objetos de registro de recursos IP, como inetnum e inet6num. Existem duas formas principais. A forma mais nova é usar o atributo próprio: A forma compatível com ambientes que ainda não suportam o atributo específico é usar remarks: O importante é que o consumidor consiga olhar para o registro do bloco e descobrir que existe um arquivo geofeed associado a ele. E o RDAP? O RDAP é o caminho mais moderno para consulta de dados de registro. Enquanto o WHOIS tradicional retorna texto, o RDAP retorna JSON. Isso facilita muito para automação. A RFC 9877 define como um servidor RDAP pode informar links de geofeed dentro da resposta de um objeto IP [3]. Um exemplo seria algo assim: Ou seja: o consumidor consulta o RDAP de um IP, encontra o link geofeed, baixa o CSV e processa a informação. O mais específico vence Aqui a
Made4Flow 2.11.1: exportação de NetFlow para mitigação DDoS, novos alertas e muito mais
Veja o que há de novo no Made4Flow 2.11.1: exporte NetFlow V5, V9 e sFlow para plataformas de mitigação DDoS, configure alertas por roteador e integre com sistemas externos via API REST. Quem opera uma rede de médio ou grande porte sabe que visibilidade de tráfego não é diferencial — é sobrevivência. Identificar um ataque DDoS em andamento, saber de qual país está vindo o tráfego anômalo, ou integrar o analisador de NetFlow com a plataforma de mitigação da operadora sem precisar reconfigurar roteadores: essas são dores reais de times de NOC e segurança no dia a dia. A versão 2.11.1 do Made4Flow, disponível a partir de 27 de fevereiro de 2026, endereça exatamente essas demandas. Neste artigo, detalhamos cada novidade e o que ela resolve na prática. O que é o Made4Flow e para quem é esta atualização? O Made4Flow é um analisador de NetFlow e sFlow desenvolvido pela Made4it para provedores de internet, operadoras e equipes de NOC que precisam de visibilidade detalhada sobre o tráfego de rede. Ele coleta flows exportados pelos roteadores (NetFlow V5, V9, sFlow, IPFIX), aplica inteligência sobre esses dados e entrega gráficos, alertas e análises em tempo real. Esta atualização é relevante especialmente para quem: Como exportar NetFlow para uma plataforma de mitigação DDoS — sem mexer nos roteadores Esta é a novidade mais aguardada da versão 2.11.1 por equipes que operam plataformas de mitigação DDoS. O cenário anterior era assim: para enviar flows para uma solução de mitigação de terceiros, era necessário configurar o roteador para exportar simultaneamente para dois destinos — o coletor do Made4Flow e o coletor da plataforma de mitigação. Em muitos ambientes, isso não é simples, é arriscado ou simplesmente inviável. Com o novo replicador de flows do Made4Flow, o roteador continua exportando normalmente para o Made4Flow. A partir daí, a própria plataforma replica e encaminha os flows para qualquer destino externo, nos formatos: A configuração é feita diretamente na interface do Made4Flow — sem downtime, sem janela de manutenção nos roteadores, sem risco operacional. Para provedores que usam soluções como Wanguard, NSFOCUS, Arbor ou qualquer outra plataforma que consuma NetFlow ou sFlow, esta funcionalidade elimina uma dependência complexa e acelera a integração. Integre sua plataforma de mitigação DDoS ao Made4Flow e replique NetFlow V5, V9, IPFIX ou sFlow com apenas uma configuração. Análise de ameaças: nova visualização para identificar ataques internos A página de Análise de Ameaças do Made4Flow recebeu uma reformulação completa na versão 2.11.1. O novo layout consolida em uma única tela as principais métricas de segurança: total de ameaças detectadas, IPs suspeitos, volume de tráfego malicioso, distribuição temporal dos incidentes e os principais alvos. A visão geográfica de ameaças também foi aprimorada, facilitando a correlação entre origem do ataque e impacto na rede. Para times de segurança que precisam responder rapidamente a incidentes, isso representa menos cliques e mais contexto disponível no momento crítico. Descubra quem está causando ataques dentro da sua rede interna em UM CLIQUE. Alertas de sampling rate e por roteador: pare de analisar dados distorcidos Um dos problemas mais silenciosos no monitoramento com NetFlow é a incompatibilidade de sampling rate. Quando o valor configurado na ferramenta de análise é diferente do que o roteador está efetivamente aplicando, todos os gráficos de tráfego ficam distorcidos — e a equipe pode tomar decisões baseadas em dados errados sem perceber. A versão 2.11.1 adiciona dois tipos de alertas específicos para esse cenário: Alerta de incompatibilidade de sampling rate Notifica automaticamente quando o valor de amostragem configurado no Made4Flow diverge do que o roteador está reportando. Isso é especialmente útil em ambientes com múltiplos roteadores de fabricantes diferentes (Cisco, Huawei, MikroTik, Juniper), onde o padrão de sampling pode variar. Alertas explícitos por roteador Cada roteador cadastrado no Made4Flow agora pode ter seus próprios alertas ativos, visíveis diretamente na listagem de equipamentos e na página de edição. Isso facilita a gestão em ambientes com dezenas ou centenas de roteadores monitorados. Seja alertado antes que o problema afete seus dados — configure em minutos. Tráfego por país e App por prefixo: visibilidade geográfica em tempo real Para provedores de internet e operadoras, saber de onde vem o tráfego é tão importante quanto saber quanto tráfego existe. Um pico vindo de determinado país pode indicar um ataque volumétrico em andamento; um prefixo específico consumindo banda fora do padrão pode sinalizar um cliente comprometido. A versão 2.11.1 adiciona uma nova tela de visualização com gráficos de tráfego segmentados por: Essa visibilidade estava disponível nos dados brutos, mas agora ganha formato visual nativo, sem necessidade de exportar dados, cruzar planilhas ou usar ferramentas externas. Veja em segundos qual país ou prefixo está gerando tráfego fora do padrão — e aja antes que o ataque escale. Agregação por TCP Flags e países: detecte padrões de ataque DDoS com precisão Ataques DDoS modernos muitas vezes se disfarçam em volume de tráfego aparentemente normal. A análise de TCP Flags — como floods de SYN, ACK ou RST — é uma das formas mais eficazes de identificar tráfego malicioso antes que ele impacte os serviços. A versão 2.11.1 adiciona novas abas de agregação nos dados brutos do Made4Flow: Para equipes de segurança que investigam incidentes, a combinação de análise por flags e por origem geográfica é especialmente poderosa para correlacionar técnica de ataque com origem. Identifique ataques por padrão de TCP Flags e origem geográfica em segundos, sem ferramentas externas. API REST do Made4Flow: integre com qualquer sistema A versão 2.11.1 marca a chegada da API REST oficial do Made4Flow, abrindo a plataforma para integrações programáticas com outros sistemas. A API oferece: Na prática, isso possibilita integrações com Zabbix, Grafana, sistemas de ticketing, SIEM, painéis externos e qualquer sistema que consuma dados via HTTP. Conecte o Made4Flow ao seu ecossistema e automatize dados de rede com sua própria stack. Outras melhorias da versão 2.11.1 Correções da versão 2.11.1 Perguntas frequentes sobre o Made4Flow 2.11.1 O Made4Flow consegue exportar NetFlow para a minha plataforma de mitigação DDoS?Sim. A partir da versão 2.11.1, o
MC-LAG em roteadores Huawei
Como configurar MC-LAG na Huawei: E-Trunk, Eth-Trunk, LACP e BFD passo a passo. Aprenda MC-LAG em Huawei, hoje mostramos o porquê do E-Trunk (multi-chassis), quando usar Eth-Trunk (agregação), como ajustar LACP para portas ativas/backup e como o BFD encurta o MTTR. Incluímos recomendações de hash em cenários MPLS e um roteiro de testes para validar o comportamento em falhas. O link-aggregation (LAG), chamado de Trunk na Huawei (Eth-Trunk quando é Ethernet), é uma tecnologia que combina múltiplas interfaces físicas em uma única interface lógica. Com link-aggregation ganhamos: O LAG tradicional é sempre entre dois dispositivos, ponto a ponto: Tipos de LAG para Huawei De forma bem simples, na Huawei temos três jeitos principais de usar Eth-Trunk: No contexto de MC-LAG, o que importa pra nós são basicamente: Vamos simplificar: Manual Static LACP Como o Trunk balanceia o tráfego O Eth-Trunk não “soma portas” como uma porta gigante. O equipamento decide por qual membro mandar cada fluxo usando algoritmos de balanceamento. Isso define dois comportamentos principais: Load-balance baseado em hash É o padrão na maioria dos roteadores/switches. Funciona assim: O hash pode usar vários critérios, por exemplo: Com hash, o modo padrão é per-flow: Hash tem uma consequência importante: Nem sempre distribui banda de forma uniforme.Dependendo da distribuição dos fluxos (hash), um membro pode ficar no gargalo enquanto outro quase sem tráfego. Isso é normal. Load-balance dinâmico Alguns equipamentos suportam o modo dynamic, que monitora a carga instantânea de cada membro e realoca fluxos entre links que estejam subutilizados ou sobrecarregados. Um equipamento que usa esse tipo de balanceamento são os switches da Datacom. E o que os chips conseguem usar para o hash? Esse ponto quase ninguém fala, mas é crucial. Dependendo do ASIC, o roteador pode olhar: No caso de MPLS: Isso importa porque: Exemplos práticos: Em resumo: Quanto maior a profundidade MPLS que o ASIC enxerga, melhor será a distribuição dos fluxos MPLS no LAG. O que o LACP faz O LACP (Link Aggregation Control Protocol, IEEE 802.3ad) é o cara que: Na Huawei, quando o Eth-Trunk está em static LACP, as interfaces membros: O lado com maior prioridade de sistema (menor valor numérico) vira o Actor. A partir daí: O que precisa estar “OK” para o LAG subir direito Pra um Eth-Trunk com LACP funcionar como esperado, alguns pontos precisam estar alinhados entre os dois lados: O que o LACP faz é usar system priority + system ID + interface priority + interface number para: Entrando no MC-LAG Até aqui falamos de LAG “normal”, ou seja, entre dois dispositivos apenas. O MC-LAG (Multi-Chassis LAG) entra quando você quer ter: A ideia é simples: Objetivo principal do MC-LAG: É basicamente levar a ideia de redundância do nível de porta/link para o nível de dispositivo. Ativo/ativo vs ativo/backup Em muitos vendors você encontra MC-LAG em dois sabores: Na Huawei, para esse cenário específico com E-Trunk/mLACP, o comportamento é ativo/backup: MC-LAG na Huawei: E-Trunk vs mLACP Em Huawei, existem duas formas principais de implementar MC-LAG: A diferença está no mecanismo de controle entre os PEs: Neste artigo, vamos focar no E-Trunk, que é a forma “clássica” de MC-LAG em muitos cenários de PE–CE. Como o E-Trunk funciona Não confundir E-Trunk (a tecnologia de sync entre chassis) com o Eth-Trunk (o link-aggregation em si). Pense no seguinte cenário: Os PEs então: Com isso: Quando acontece uma falha: Opcionalmente, você pode: Conectividade CE ↔ PEs com E-Trunk Alguns pontos importantes de design: Casos de uso Na topologia abaixo, iremos abordar dois casos de uso para o MC-LAG (existem muitos outros). 1) MC-LAG protegendo VPLS (camada 2) No topo do desenho, o CE1 está multihomed em PE1 e PE2 usando MC-LAG, todos na mesma instância VPLS-1.Do lado da rede, PE1/PE2 fecham a VPLS com o PE3, que entrega o mesmo serviço para o CE2. É uma proteção L2 fim-a-fim da VPLS, com redundância de equipamento e de POP. 2) MC-LAG protegendo /30 L3 (camada 3) Na parte de baixo do desenho, o CE3 recebe um /30 L3 via MC-LAG, dual-homed em PE2 e PE3. Configurando o ambiente Agora que você já conhece todos os conceitos por trás do MC-LAG, vamos para o laboratório. Vamos utilizar o ambiente virtual PNETLAB, com a imagem Huawei NE40 V22. As portas físicas e ligações entre dispositivos estão descritas na topologia abaixo. A configuração dos CEs é simples: um mikrotik (ROS 7.6) usando interfaces bonding, com LACP fast (em 1s). O CE3 é simplesmente uma interface física com VLAN. CE1 CE2 CE3 A configuração dos PEs compreende as interfaces ponto a ponto, ativas com OSPF, MPLS. Nas interfaces de acesso, as configurações de LAG e de sincronização e-trunk. E na camada de serviços, colocamos o VPLS (VSI) e também o gateway L3 (com o macete do mac-address e mesmo IP). PE1 – Camada Core Serviço MLAG e E-trunk Aqui neste ponto está o grande diferencial do MLAG. Vamos primeiramente criar um Eth-Trunk comum, e depois associamos ele a uma configuração e-trunk, que faz a mágica do MLAG acontecer. Com o LAG criado, agora precisamos criar a configuração do e-trunk. Para configurá-lo, precisamos: No nosso laboratório, iremos fechar entre a loopback do PE1 com o PE2 – estes fazem parte do MLAG na perspectiva do CE1. A prioridade de master será do PE2, com prioridade 5. Os timers configurados são 9 para hello e 30 para hold-timer. Por fim, é hora de associar a interface LAG com o e-trunk, criando assim um MLAG na perspectiva do CE1. Serviços VPLS PE2 – Camada Core As configurações CORE e VPLS do PE2 são similares às do PE1 Serviço MLAG e E-trunk Serviços Gateway redundante Para o serviço de gateway redundante para o CE3, iremos: PE3 – Camada Core As configurações CORE do PE3 são similares às do PE1. Serviços VPLS Diferente dos PE1 e PE2 que tem um MLAG com o CE, neste caso a comunicação PE3xCE2 ocorre diretamente na interface física com a vlan 10. As configurações de VPLS permanecem iguais, a diferença está nos peers, que fechamos o VPLS com o PE1 e PE2 ao mesmo tempo. Serviços Gateway redundante Validando as configurações e redundância MC-LAG entre dispositivos Na visão do CE1, ele tem duas portas ativas no LAG bond2, sendo a porta ether2 – que fala com PE2 – a principal. A outra fica pronta
Como a Pontonet saiu do caos de servidores e reduziu custos com Proxmox
Descubra como a Made4it transformou um cenário de falha total em uma infraestrutura moderna, resiliente e mais barata. 16/09/2025 • Por Made4it A cena é familiar para qualquer gestor de TI: fim do mês, boletos a emitir, sistema rodando… até que tudo cai. Foi exatamente isso que aconteceu com a Pontonet, quando uma falha simultânea em um servidor físico colocou em risco todo o negócio. Pare e pense: se todos os seus discos quebrassem hoje, quanto custaria recuperar informações de um ano inteiro? Foi nessa hora que a Made4it entrou em ação para transformar o desastre em oportunidade. O problema: falha simultânea e ausência de backup Esse é o tipo de risco que muitas empresas ignoram até ser tarde demais. Soluções na mesa: manter VMware ou migrar? Diante do desastre, avaliamos duas alternativas: Continuar no VMware Migrar para Proxmox Por que Proxmox? O Proxmox é mais do que uma alternativa gratuita. Ele oferece: Quando comparado ao VMware, o Proxmox provou ser mais ágil, econômico e seguro. O papel da Made4it nessa virada A Pontonet já era cliente de redes e servidores da Made4it. Ao ocorrer a falha, tomamos as seguintes ações: Esse processo evidenciou nosso domínio técnico e capacidade de transformar crises em oportunidades de inovação. Resultados: segurança e economia Após a migração: Proxmox e Made4it: a combinação vencedora Essa história mostra que tecnologia e estratégia caminham juntas. De nada adianta investir em licenças caras se o projeto não contempla redundância e backup; da mesma forma, uma solução open source requer expertise para ser aplicada com segurança. A Made4it entrega ambos: conhecimento aprofundado e soluções acessíveis. Você conhece alguém que ainda depende de um servidor velho e sem backup? Envie este artigo! E se você não quer descobrir no susto que sua empresa está vulnerável, converse com nossos especialistas.
IPv6 para ISPs: Segurança, Performance e Escalabilidade
IPv6: A Chave para o Futuro da Conectividade em Provedores de Internet A internet global está passando por uma transição inevitável. Com a explosão de dispositivos conectados — de smartphones e IoT a aplicações 5G — o esgotamento dos endereços IPv4 deixou de ser uma previsão distante e passou a ser um gargalo real. Desde 2011, a IANA já alertava sobre o fim dos blocos IPv4, e no Brasil, desde 2020, não há mais endereços disponíveis para alocação. Diante disso, muitos ISPs recorreram ao CGNAT como solução paliativa. Funciona no curto prazo, mas cobra um preço alto: perda de conectividade fim a fim, impacto em aplicações sensíveis e sérios desafios de rastreabilidade e segurança. Nesse cenário, o IPv6 deixa de ser apenas uma alternativa tecnológica. Ele se torna o único caminho viável para garantir escalabilidade, estabilidade e competitividade na nova geração de redes. Por que o IPv6 é mais que necessário? É estratégico para o seu provedor! Adotar o IPv6 vai muito além de uma atualização técnica: é uma decisão estratégica que impacta diretamente o presente e o futuro do seu negócio. Ao eliminar as limitações do IPv4, o IPv6 libera um novo patamar de conectividade, com endereçamento amplo, mais segurança, menor latência e desempenho superior. Tudo isso com mais controle e escalabilidade da rede. Provedores que já migraram estão colhendo resultados: operações mais eficientes, menor dependência de soluções paliativas como o CGNAT e muito mais preparo para tecnologias como 5G, IoT, automação e aplicações em tempo real. O cliente final também sente a diferença com uma navegação mais rápida, conexões mais estáveis e uma experiência otimizada para jogos, chamadas, streamings e acesso remoto. IPv6 não é só o futuro. É vantagem competitiva agora. Como implementar o IPv6 com segurança e eficiência A migração para o IPv6 não precisa ser complexa. Com o planejamento certo, ela acontece de forma gradual, segura e sem impacto para os seus clientes. O segredo está em entender os ganhos reais, preparar sua equipe e seguir uma estrutura bem definida. Veja como o IPv6 entrega valor imediato ao seu provedor — e ao usuário final. Quais são os ganhos reais para o seu provedor? E para seus clientes? Experiência elevada. Como implementar na prática: Passo a passo simplificado Erros comuns que podem comprometer sua transição A transição já começou e quem lidera agora, sai na frente A migração para o IPv6 não é mais uma possibilidade futura. É uma realidade em curso e quem adota agora colhe os benefícios antes dos concorrentes. Mais performance. Mais segurança. Mais escalabilidade. Menos custos operacionais. Provedores que lideram essa mudança entregam mais valor aos seus clientes, evitam gargalos técnicos e se posicionam de forma sólida diante das exigências do mercado, cada vez mais conectado, automatizado e exigente. Com o suporte certo, planejamento técnico e execução estruturada, sua operação pode fazer essa transição de forma segura, gradual e eficiente sem comprometer a qualidade do serviço. A Made4it pode caminhar com você nessa jornada.Fale com nosso time e descubra como podemos acelerar sua evolução para uma infraestrutura pronta para o futuro.
SRv6 – Um sucessor do MPLS ?
Nós aqui na Made4it somos apaixonados por evolução e o SRv6 tem sido motivo de muita euforia e discussão com os nossos times e a comunidade. Um protocolo que tenta bater de frente com o MPLS com certeza precisa ser olhado com muito carinho. Vamos conhecer um pouco mais sobre ele, em uma série de artigos sobre o assunto. Nos últimos anos, a evolução das redes vem sendo impulsionada por demandas crescentes de escalabilidade, flexibilidade e eficiência. Nesse cenário dinâmico, tecnologias como MPLS (Multiprotocol Label Switching) surgiram como soluções dominantes para atender necessidades complexas de roteamento e encaminhamento de tráfego. No entanto, com o avanço das aplicações e serviços digitais, surgiram desafios que o MPLS tradicional não conseguia resolver de maneira eficiente. As necessidades constantes das redes, alinhadas a novas tecnologias como o 5G, IoT, carros autônomos e todo um ecossistema crescendo de forma exponencial EXIGEM que as redes de comunicação estejam alinhadas a novas demandas e necessidades. É aqui que o Segment Routing over IPv6 (SRv6) entra em cena como uma alternativa inovadora atendendo esses requisitos com simplicidade e elegância. MPLS: A Tecnologia Legada MPLS foi introduzido no final dos anos 1990 e rapidamente ganhou popularidade devido à sua capacidade de fornecer encaminhamento de pacotes baseado em rótulos (as famosas labels), permitindo maior controle sobre o fluxo de tráfego e melhor qualidade de serviço (QoS). Nos anos 2000, o MPLS tornou-se a escolha preferida para provedores de serviços e empresas que buscavam soluções robustas para redes de grande escala, data centers e interconexões entre redes. Para os provedores de serviço, a escalabilidade e facilidade que o MPLS entregava tornou inevitável implementá-lo em suas redes. Isso permitiu aos provedores de serviço desenvolverem e comercializarem novos produtos, o que culminou em empresas conectando suas matrizes e filiais de forma transparente, operadoras de telefonia móvel conseguindo expandir suas redes de forma massiva, dentre inúmeras outras inovações que aconteceram com o tempo enquanto a internet deixava de ser das grandes corporações e passava a ser das pessoas. Necessidades e Limitações do MPLS: Toda e qualquer tecnologia tem pontos positivos e negativos e são moldadas e concebidas para atender uma ou mais necessidades de um determinado ponto no tempo. Conforme o tempo passa, redes crescem e continuam a evoluir, isso implica em necessidades novas que surgem constantemente e talvez não sejam atendidas por tais tecnologias. No caso do MPLS não foi diferente, conforme as redes continuaram no seu crescimento e evolução, algumas limitações do MPLS começaram a se tornar muito aparentes. Complexidade Operacional: A gestão e configuração de redes MPLS, dependendo de seu tamanho e “features” que são necessárias para a rede, pode ser complexa e exigir expertise altamente especializada. Escalabilidade: À medida que as redes crescem, torna-se desafiador escalar infraestruturas MPLS sem aumentar significativamente os custos e a complexidade da rede. Existem técnicas e boas práticas para tais implementações, mas assim como toda e qualquer tecnologia o MPLS também tem suas limitações de escalabilidade. Em muitos casos, o preço da escalabilidade de uma rede MPLS é o uso cada vez mais alto de processamento em equipamentos de rede, tabelas de roteamento cada vez mais extensas, ambientes de rede cada vez mais delicados. Isso invariavelmente aumenta o CAPEX e OPEX da operação, chegando em pontos de tornar completamente inviável manter tal tecnologia em operação na rede e buscar arquiteturas de rede alternativas para manter o ambiente operável. Flexibilidade Limitada: MPLS foi projetado para cenários específicos e pode não ser facilmente adaptável às novas demandas de tráfego e serviços emergentes. Com novas tecnologias surgindo como o 5G e as novas necessidades que o IoT e inovações tecnológicas no campo de carros autônomos e telemedicina demandam, se faz necessário ter alternativas para segregação de rede a nível de topologia (Slicing) além da segmentação do tráfego seguindo priorizações como caminhos de baixa latência e alto tráfego, baixa latência e baixo tráfego, alto tráfego sem se importar com latência e assim por diante. O MPLS, hoje, não é capaz de entregar essas demandas emergentes com seus mecanismos legados. SRv6: A Inovação em Segment Routing O Segment Routing over IPv6 (SRv6) é uma tecnologia de nova geração que combina o Segment Routing (SR) e o IPv6, aproveitando dos mecanismos de encaminhamento já existentes no IPv6. Com o uso de uma extensão do cabeçalho IPv6 como meio para identificação e encaminhamento de informações dentro de uma rede, o SRv6 traz benefícios no plano de controle e plano de dados de equipamentos de rede onerando menos e entregando mais. O SRv6 foi concebido desde o início tendo em vista as necessidades constantes dos dias atuais e do futuro, sendo altamente programável e totalmente flexível para escalar redes legadas como também novos ambientes de rede. Com o conceito de “programabilidade” enraizado, o SRv6 traz a capacidade de uma rede de codificar instruções individuais para os pacotes diretamente em seu cabeçalho. No “SR-MPLS” (Segment Routing MPLS) essas instruções são transportadas em rótulos (labels) MPLS, no SRv6, tais instruções são transportadas nativamente no cabeçalho IPv6 com adição de uma extensão chamada de SRH, ou Segment Routing Header. Características e Benefícios do SRv6. Comparação com Tecnologias Legadas Ao comparar o SRv6 com tecnologias legadas como MPLS, é evidente que o SRv6 oferece uma abordagem mais simplificada, flexível e adaptável às necessidades atuais de redes de comunicação. Enquanto o MPLS continua sendo uma solução viável para muitos cenários, o SRv6 está emergindo como a escolha preferida para provedores de serviço que buscam inovação e eficiência em suas infraestruturas de rede, principalmente quando nessas redes as demandas “do futuro” se tornam cada vez mais evidentes. Conclusão O Segment Routing over IPv6 (SRv6) representa uma evolução significativa no campo das redes de comunicação, oferecendo uma abordagem mais simples, flexível e escalável em comparação com tecnologias legadas como MPLS. Com a crescente demanda por serviços digitais e infraestruturas de rede mais eficientes, é provável que o SRv6 continue ganhando destaque e se tornando uma parte integrante das futuras arquiteturas de rede. A crescente demanda e necessidades que
A importância de um provedor ter um DNS próprio
Um provedor sempre busca fornecer a internet com melhor qualidade para seus clientes, e um fator muito importante para conseguirmos navegar na internet é possuirmos um servidor DNS recursivo configurado, o porquê disso e como ele funciona já entendemos, mas como ter um servidor dentro da sua rede vai melhorar ainda mais a navegação de seus clientes?
Criação de VPN utilizando PFSense e OpenVPN
Basicamente, VPN significa Rede Virtual Privada (ou, Virtual Private Network), e serve como um túnel entre dois pontos de conexão. Ao estabelecer uma VPN entre um computador em sua residência e um PFSense em sua empresa, por exemplo, o túnel criado faz com que seu computador possa atuar como se estivesse ‘dentro’ da rede local de sua empresa, permitindo acesso a servidores e equipamentos, isso, se o PFSense for alcançável através de sua máquina residencial. Agora que entendemos do que se trata a VPN, vamos aprender a configurar utilizando o PFSense para estabelecer a conexão entre suas redes distintas. Configurando a VPN Vamos utilizar o ‘Wizard’ do próprio PFSense para essa configuração. Para isso, vamos no menu VPN > OpenVPN. Então, clique na Aba Wizards: Então, é isso pessoal, esse foi o nosso guia de configuração de OpenVPN utilizando PFSense e configuração para conectar nela, utilizando o OpenVPN Client, com os arquivos providenciados pelo próprio PFSense.Caso precise de ajuda ou suporte para a manutenção do PFSense, entre em contato que podemos lhe ajudar!Obrigado e até a próxima!
Instalação de PFSense como Gateway de sua rede.
Ao finalizar o Wizard, teremos nosso PFSense pronto para o uso! Nos próximos posts. Iremos ensinar a criar uma VPN utilizando o PFSense, para que tenha acesso à sua Rede Interna, através de sua casa. Obrigado e até os próximos Posts. Adriano Elias de SouzaConsultor de TIMade4it
Interligando dois Virtual Systems (VS) na plataforma Huawei NE (Interligando 2 roteadores virtuais no Huawei NE)
A outra forma de interligar… Interligando dois VS via VPN VPWS CCC # Admin-VS ! Lado L2 Admin-VS interface Virtual-Ethernet0/2/100 ve-group 100 l2-terminate interface Virtual-Ethernet0/2/100.100 vlan-type dot1q 100 ! Lado L2 VS1 interface Virtual-Ethernet0/2/200 ve-group 200 l2-terminate interface Virtual-Ethernet0/2/200.100 vlan-type dot1q 100 ! Interligação MPLS CCC VPWSccc teste interface Virtual-Ethernet0/2/100.100 tagged out-interface Virtual-Ethernet0/2/200.100 tagged # Admin-VS ! Lado L3 Admin-VS interface Virtual-Ethernet0/2/101 mac-address c4b8-b434-ab45 ve-group 100 l3-access interface Virtual-Ethernet0/2/101.100 vlan-type dot1q 100 ip address 10.1.1.1 255.255.255.252 ! Lado L3 VS1 interface Virtual-Ethernet0/2/201 ve-group 200 l3-access interface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 # Admin-VSadmin virtual-system vs1 pvmb slot 3 port-mode port assign interface Virtual-Ethernet0/2/201.100 # VS1 ! Lado L3 VS1interface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 ip address 10.1.1.2 255.255.255.252 Considerações sobre o cenário Validações <HUAWEI>display vll ccctotal ccc vc : 1local ccc vc : 1, 1 upremote ccc vc : 0, 0 up name: teste, type: local, state: up,intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false VC last up time : 2020/02/17 14:40:58VC total up time: 0 days, 0 hours, 16 minutes, 37 seconds Admin-VS:<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms VS1:<HUAWEI-vs1>ping 10.1.1.1 PING 10.1.1.1: 56 data bytes, press CTRL_C to break Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.1 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms <HUAWEI>displ bgp peer BGP local router ID : 192.168.88.100 Local AS number : 11111 Total number of peers : 1 Peers in established state : 1 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.2 4 22222 25 25 0 00:19:38 Established 0<HUAWEI>displ ospf peer brief (M) Indicates MADJ neighbor OSPF Process 1 with Router ID 10.0.0.1 Peer Statistic InformationTotal number of peer(s): 1 Peer(s) in full state: 1—————————————————————————– Area Id Interface Neighbor id State 0.0.0.0 VE0/2/101.100 10.0.0.2 Full<HUAWEI> displ ospfv3 peer OSPFv3 Process (1) OSPFv3 Area (0.0.0.0) Neighbor ID Pri State Dead Time Interface Instance ID 10.0.0.1 1 Full/DR 00:00:38 VE0/2/201.100 0 Por fim é isto pessoal, não sabemos a performance ou impacto na caixa, porém os serviços básicos funcionaram normalmente. Caso venha a testar com tráfego, nos deixe saber! Compartilhe conosco seus resultados. Se precisar de suporte entre em contato conosco! Abraços, Rafael Ganascim, Gabriel Henrique e Kevin Walters IT Consulting Team – Made4it
