Como configurar Geofeed no Registro.br
No artigo anterior falamos sobre geofeed, RFC 8805, RFC 9632, RDAP e por que isso importa para provedores. Agora vamos para a prática. A ideia aqui é montar um exemplo simples de publicação de geofeed usando o Registro.br, com arquivo CSV publicado em HTTPS e validação via WHOIS e RDAP. Para não usar nenhum bloco real, os exemplos abaixo usam blocos reservados para teste e documentação. Em produção, naturalmente, você deve substituir pelos blocos reais do ASN. Cenário de exemplo Vamos imaginar que o provedor tenha um bloco IPv4 /22 e use cada /24 em uma cidade diferente. Para o exemplo IPv4, vamos usar: Esse bloco faz parte de um espaço reservado para testes/benchmarking. Ele não deve ser usado em produção na Internet. Aqui ele serve apenas para deixar o exemplo com cara de operação real, sem expor prefixo. A divisão operacional seria: No IPv6, vamos usar o bloco de documentação: E separar em /40: Essa abordagem fica mais próxima do mundo real: um bloco maior cadastrado e, dentro dele, divisões por cidade ou região. Um arquivo por bloco Por enquanto, o Registro.br mantém uma política mais restrita para publicação de geofeed. Na prática, o caminho mais seguro é trabalhar com um arquivo por bloco cadastrado, contendo apenas o próprio bloco ou sub-blocos dele. Então, se o bloco cadastrado é: faz sentido ter um único arquivo para esse /22, contendo os /24 internos: Conteúdo: Perceba o ponto principal: todas as linhas estão dentro do bloco 198.18.0.0/22. Isso é diferente de misturar blocos independentes no mesmo arquivo. Por exemplo, se você tivesse dois blocos diferentes cadastrados no Registro.br, como: não seria uma boa ideia colocar tudo no mesmo CSV neste momento. O mais seguro seria criar um arquivo para cada bloco. Arquivo IPv6 Para o IPv6, seguindo a mesma lógica, o bloco cadastrado seria: O arquivo poderia se chamar: Conteúdo: Aqui também vale a mesma regra: os /40 estão dentro do /32. Em um provedor real, a granularidade pode variar. Você pode usar /40, /44, /48 ou outro tamanho, dependendo de como o IPv6 foi planejado. O importante é que o geofeed represente a operação de forma coerente e não tente ser mais preciso do que a rede realmente permite. Formato correto do CSV A RFC 8805 define o formato base do geofeed [1]: Mas no arquivo publicado, normalmente você não coloca cabeçalho. Então não faça assim: Faça assim: Alguns detalhes importantes: O arquivo deve estar em UTF-8. O prefixo precisa estar em formato CIDR. O país do Brasil é BR. O estado precisa seguir ISO 3166-2. Paraná é BR-PR, São Paulo é BR-SP, Rio Grande do Sul é BR-RS. A cidade não deve conter vírgula. O campo de código postal deve ficar vazio, mas a vírgula final deve permanecer. Onde consultar os códigos dos estados Para o campo de região, use ISO 3166-2. Alguns exemplos: A fonte oficial é a ISO Online Browsing Platform [4]. Para consulta rápida, a página ISO 3166-2:BR também lista os códigos dos estados brasileiros [5]. Publicando o arquivo Você pode publicar o CSV no próprio site do provedor, em um servidor web, em um bucket público ou usando GitHub Pages. O ponto principal é que a URL precisa baixar o arquivo diretamente. Exemplo para IPv4: Exemplo para IPv6: Ou, usando GitHub Pages: Cuidado com links do tipo: Esse link abre uma página HTML do GitHub, não o arquivo diretamente. Para o Registro.br, a URL precisa entregar o CSV direto. Exemplo com GitHub Pages Um caminho simples para laboratório ou pequenos provedores é usar GitHub Pages. O fluxo é: O arquivo IPv4 ficaria assim: A URL final poderia ficar assim: Se ao abrir essa URL o navegador baixar ou mostrar somente o conteúdo CSV, está no caminho certo. Se abrir uma página do GitHub, com layout, botões, menu e preview, está errado. Content-Type O Registro.br pode validar o tipo de conteúdo publicado. O ideal é que o servidor responda com: ou: A RFC 9877 registra o tipo application/geofeed+csv para arquivos geofeed [3]. Para validar: Exemplo de resposta esperada: ou: Validando a sintaxe Antes de cadastrar no Registro.br, vale passar o arquivo em um validador. Uma opção prática é: Ele ajuda a pegar erro bobo, como: Exemplo errado: Problemas: Correto: Configurando no Registro.br Depois de publicar e validar o arquivo, acesse o portal do Registro.br. O fluxo geral é: 3. selecionar o bloco e abrir a opção Configurar Geofeed; 4. informar a URL HTTPS do arquivo; Exemplo IPv4: Exemplo IPv6: Lembrando novamente: estes blocos são apenas exemplos para documentação. Em produção, você usaria os blocos reais. Validando no WHOIS Depois de configurar, valide se o geofeed apareceu no WHOIS. Exemplo IPv4: Resultado esperado: Exemplo IPv6: Resultado esperado: Em produção, substitua pelos IPs reais dos blocos configurados. Validando no RDAP Também dá para validar via RDAP. IPv4: Resultado esperado: IPv6: Resultado esperado: O RDAP é importante porque é o caminho mais estruturado para sistemas automatizados descobrirem o geofeed. A RFC 9877 foi criada justamente para padronizar esse link de geofeed dentro das respostas RDAP [3]. Validando se ficou descobrível Além de WHOIS e RDAP, uma ferramenta útil é o GeolocateMuch: Em ambiente real, use o prefixo ou IP. Essa ferramenta ajuda a verificar se o geofeed está sendo descoberto a partir dos dados públicos. Checklist final Antes de considerar finalizado, revise: Erros comuns Misturar blocos diferentes no mesmo arquivo Errado: Se o arquivo é do bloco 198.18.0.0/22, o prefixo 198.18.8.0/24 está fora dele. Usar estado sem o prefixo do país Errado: Correto: Esquecer a vírgula final Errado: Correto: Usar link de preview do GitHub em vez do arquivo direto Errado: Correto, usando GitHub Pages: Boas práticas operacionais Depois de configurar, não esqueça que isso precisa ser mantido. Revise o geofeed quando houver: O ideal é que a informação venha de uma fonte confiável: IPAM, documentação de POPs, inventário de blocos ou base interna da operação. Geofeed feito “de cabeça” até funciona no começo, mas vira problema quando a rede cresce. Conclusão Configurar geofeed no Registro.br não é complicado. O que exige atenção é o detalhe. Um arquivo por bloco cadastrado.Somente o bloco ou sub-blocos dele.CSV em UTF-8.URL HTTPS baixando direto.Estado no padrão ISO 3166-2.Validação
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
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.
Tendências de T.I para 2025: O Que Sua Empresa Precisa Fazer Agora?
As Principais Tendências de TI e Telecom para 2025 O documento reúne insights de líderes de mercado que apresentam as tendências globais e suas aplicações no cenário brasileiro: A IA será o grande pilar da transformação digital, impulsionando automação, personalização e eficiência. O uso de dados para decisões estratégicas será obrigatório. A necessidade de processamento descentralizado e respostas rápidas colocará o Edge Computing no centro da inovação, aliado ao crescimento das soluções em nuvem. A infraestrutura de 5G terá um papel decisivo, viabilizando redes mais rápidas e o desenvolvimento de soluções avançadas, como cidades inteligentes e automação industrial. A TI Verde e as práticas ESG ganharão destaque, com a otimização do uso energético e adoção de soluções sustentáveis em Data Centers. A qualidade no atendimento e a redução do churn serão diferenciais competitivos. Empresas focadas na excelência e na adoção de ferramentas de gestão se destacarão. A Visão da Made4it – Guilherme Ganascim Em meio a essas tendências, Guilherme Ganascim, Diretor Comercial da Made4it, trouxe reflexões valiosas na página 54 do relatório. Ele reforça que o grande desafio para 2025 será manter a base de clientes em um mercado saturado, destacando três estratégias fundamentais: Como Guilherme destaca: “A banda larga não é mais apenas sobre velocidades e preços, mas sim sobre proporcionar uma melhor qualidade de experiência.” A Made4it, com sua experiência em soluções tecnológicas inovadoras, se posiciona como parceira essencial para empresas que buscam excelência no atendimento e inovação em suas operações. Outros Destaques no Relatório O IPV7 Predictions também contou com contribuições de líderes de outras empresas que compartilham uma visão alinhada às principais tendências para 2025: Vero Internet – Fabiano Ferreira, CEO, prevê que o 5G, aliado à Inteligência Artificial, será a base para personalização e otimização de serviços, indo além da conectividade para soluções integradas. Zadara – Robson Andrade, Country Manager, destaca a consolidação do Edge Computing, essencial para lidar com o aumento de dados e demandas em tempo real, impulsionados pelo IoT. Elea Digital Data Centers – Wesley Barbosa, Diretor Comercial, reforça o potencial do Brasil para se tornar um polo global de IA, com sua matriz energética limpa e capacidade de expansão em infraestrutura digital. Essas empresas, assim como a Made4it, estão na linha de frente da inovação, com estratégias claras para enfrentar os desafios e aproveitar as oportunidades em 2025. Conclusão: Preparando-se para um Futuro de Inovação e Qualidade O IPV7 Predictions 2025 é um mapa essencial para líderes que desejam se antecipar às mudanças e liderar o mercado. Tendências como IA, Edge Computing, 5G e ESG apontam para um futuro onde a inovação e a qualidade da experiência do cliente serão fatores determinantes. A Made4it, com sua contribuição de Guilherme Ganascim, reitera seu compromisso em oferecer soluções robustas e personalizadas, ajudando empresas de TI e telecom a se posicionarem com excelência no mercado. Baixar e-book Falar no WhatsApp
Como configurar vlans nos equipamentos Ufispace
Neste artigo será demonstrado como configurar vlans nos equipamentos Ufispace, no modo trunk, hybrid e access. Primeiramente, segue abaixo o passo a passo de como criar a VLAN: Acessar modo Privilegiado: Acessar modo de configuração: Criar Bridge e configurar protocolo RSTP (requisito do OcNos). Criar Vlan e associar na bridge criada: Sair do modo de “vlan database” Verificar configurações pendentes: Saída esperada do comando acima: Caso necessário desfazer as configurações, pode ser usado o comando: Se as configurações estiverem corretas, podem ser aplicadas com o comando: Para verificar a configuração da VLAN: Com a Vlan criada, é necessário atribuir em uma interface, seja em modo TAG ou UNTAGGED (em access). Como configurar VLAN em modo Trunk: Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge (criada anteriormente): Configurar modo de interface em Trunk: Configurar vlan em TAG na interface: Conferir configuração e aplicar: Como configurar VLAN no modo Access Criar Vlan e associar na bridge criada: Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge: Configurar modo de interface em Trunk: Configurar vlan em UNTAGGED na interface: Conferir configuração e aplicar: Como configurar VLAN em modo Hybrid Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge: Configurar modo de interface em Hybrid: Configurar vlan em UNTAGGED na interface: Configurar vlan em TAGGED na interface: Conferir configuração e aplicar: Resumo de todas configurações aplicadas: Ao final de todas essas configurações detalhadas, você estará apto a gerenciar VLANs de maneira eficiente nos equipamentos Ufispace, garantindo uma rede organizada e segura. Siga os passos com atenção e, em caso de dúvidas, não hesite em consultar a documentação oficial ou entrar em contato com o suporte técnico especializado. Gostaria de falar com um de nossos especialistas em UfiSpace e IPInfusion? Nós da Made4it somos especialistas nessas tecnologias e oferecemos serviços completos de configuração e suporte. Fale com nossos consultores para saber mais e otimizar a sua rede com soluções profissionais: https://made4it.com.br/
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
DHCP Option 43 para auto-configuração de ACS
Hoje vamos explorar o famoso DHCP Option 43, usado principalmente na autoconfiguração de dispositivos como Access Points, Switches, Telefones IP, CPEs, dispositivos IoT e outros através do TR-069. Também vamos mostrar um exemplo de configuração utilizando o DHCP Server de um roteador Mikrotik entregando parâmetros via DHCP Option43 e permitindo a autoconfiguração de serviços no processo de atribuir endereço de IP ao dispositivo. Isso nos possibilita, por exemplo, sinalizar um controlador externo ao dispositivo, automaticamente, mesmo que o equipamento tenha passado por um factory-reset. A RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] trata de diversos tipos de informações que podem ser enviadas através do protocolo DHCP como por exemplo o DNS, Máscara de sub-rede, endereço do gateway (router), atributos específicos de vendor e muitos outros mais. O Option 43 é definido nesta RFC como “Vendor Specific Information” e é usado para que os clientes e servidores DHCP troquem informações específicas entre si. A RFC não define que valores eu posso enviar, e nem que informações são estas e muito menos o tipo de dados. Ele apenas descreve a estrutura, que deve ser: Code Len Vendor specific information 43 n i1 i2 … Code 1 Len 1 Data 1 Code 2 Len 2 Data 2 Code n Len n Data n T1 n1 d1 T2 n2 T2 … … … Com esta estrutura, cada fabricante ou organização, pode modelar os dados como for mais conveniente para seu uso. Por exemplo, para access-points poderem ser configurados os endereços IP dos controladores Wifi permitindo seu “join” no controlador centralizado, para Telefones IP entregando o IP ou URL do servidor de telefonia e para os roteadores que suportem TR-069 poderem ser configurados com a URL do ACS. E tudo isso automaticamente! O foco deste artigo será mostrar o uso do option 43 junto ao TR-069, enviando a URL do servidor ACS para a CPE através do servidor DHCP. Isso nos permite que o roteador mesmo resetado e sem um “template” de configuração, aprenda via DHCP a URL do servidor ACS junto do usuário e senha, dados necessários para se integrar ao ACS e permitir o TR-069 aplicar configurações na CPE automaticamente. Mas antes de continuar, vou deixar alguns links de outros exemplos de caso de uso do option 43. Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html VLAN ID Discovery over DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Use DHCP Option 43 for Unifi Accesspoint Provisioning:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ Como o DHCP foi parar no TR-069 Se não sabe o que é o ACS, consulte nosso outro artigo . O DHCP foi inserido como uma das formas de onboarding do ACS. O onboarding é o processo em que a CPE/roteador é configurada com um servidor ACS.Existem três formas de se fazer o processo de onboarding das CPEs para um servidor ACS, segundo a especificação TR-069 do Broadband Forum [2]: O objetivo final de qualquer um dos três é um só: ter a URL do servidor ACS configurada na CPE, para que a mesma possa ser gerenciada através do protocolo TR-069. Processo de solicitação do DHCP Option 43 O BroadBand Forum define alguns passos para que a CPE possa conseguir a URL do ACS através do DHCP. A figura abaixo mostra os passos, e já vamos falar de cada um deles. Passo a passo da comunicação: Na especificação do TR-069 também estão definidos outros campos/protocolos que podem ser utilizados para o mesmo fim: DHCPv4 Option 125, DHCPv6 Option 17. Também citam diversas regras de descoberta pós-reset e como lidar com problemas de conectividade com o ACS. Mas estão fora do escopo deste artigo. Exemplo de uma transação DHCP com Option 43 – Capturas de pacotes Exemplo de configuração no Mikrotik Aqui, veremos como configurar um roteador Mikrotik para, via DHCP-Server, entregar parâmetros de autoconfiguração de “clientes” via o Option43. A configuração será baseada na topologia abaixo, semelhante ao utilizado em nossos testes com uma CPE Nokia. Primeiro é necessário ter a configuração do DHCP Server, depois vincular as configurações de DHCP Option43. Utilizamos a rede 192.168.2.0/24 e a Vlan 881, conforme nosso exemplo: Você deve estar se perguntando, de onde aquele valor da opção 43 saiu? Existe sim uma regra para ser criada, e você pode conferir como gerar para seu servidor ACS no seguinte artigo. Conclusão Neste artigo, abordamos como utilizar o atributo “Option43” do DHCP para autoconfiguração de um servidor ACS em CPEs e dispositivos diversos. Abordamos o seu funcionamento e como ele pode ser utilizado para automação de entrega de configurações específicas a dispositivos utilizando um protocolo tão comum como o DHCP. Conhecer as capacidades, atributos e opções que o fabricante e o modelo de equipamento suportam nos ajuda a automatizar diversas configurações, incluindo mas não se restringindo ao gerenciamento de uma CPE, Nokia, via o TR-069. Referências:[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
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!
