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

Geofeed: Why Your IP Addresses Show Up in the Wrong City and How to Fix It

Anyone who works with an Internet service provider has probably seen this type of complaint: “My client is in Paraná, but the website thinks he’s in São Paulo.”“The streaming is saying I’m in another country.”“The bank blocked access because it thought the IP location was strange.”“Google is showing a weather forecast for another city.” It’s a bit of a thankless situation, because most of the time the network is working. The client is browsing, BGP is OK, DNS is responding, traceroute is coming through, latency is acceptable. But for the end user, the perception is simple: something is wrong with their Internet. And often it is. Not in connectivity, but in the way that IP address is being geolocated by third parties. IP has no city recorded inside it The first important thing to understand is that an IP is not born with a city inside it. There is no field in the IP protocol saying: or: IP geolocation is an inference. Content companies, banks, CDNs, anti-fraud platforms, search engines, streaming services and commercial bases try to find out where that IP is probably being used. To do this, they cross-reference various pieces of information: Internet log data, traffic behavior, measurements, history, user information, commercial bases, DNS, BGP, among other things. In most cases it works well enough. But when it goes wrong, it’s a real nuisance. A provider can receive a new block, buy or transfer resources, change prefixes between cities, activate a new POP, reorganize CGNAT, divide IPv6 by region, exchange upstreams or simply start using a block that was previously associated with another location. It’s just that the external bases can take a while to learn this. And then the calls begin. Where geofeed comes in The geofeed is a standardized way for the network operator to say: “These IP prefixes are being used in these locations.” It doesn’t change routing. It doesn’t change BGP. It doesn’t announce anything to the Internet. It’s not an upstream session. It’s just a CSV file published over HTTPS, following a format defined in RFC 8805 [1]. A simple example: 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, Each line associates a prefix with an approximate location. The format is: In practice: I mean: The comma at the end is important. It represents the last field, postal_code, which is empty. What each field means The first field is the IP prefix. It can be IPv4 or IPv6, in CIDR format. Examples: The second field is the country, using ISO 3166-1 alpha-2. For Brazil, we use BR. The third field is the region, using ISO 3166-2. In the case of Brazilian states: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul The official list can be consulted on the ISO platform [4]. For quick reference, there is also the ISO 3166-2:BR page, which lists the codes of the Brazilian states [5]. The fourth field is the city. The fifth field is the postal code. It exists in the format, but I don’t normally recommend using it for providers. The RFC itself treats this field with caution, because it can give too much granularity [1]. For ISP, in most cases, country, state and city are enough. Geolocation is approximation, not GPS This point is more important than it seems. When we talk about geofencing, it’s easy to fall into the temptation of trying to be too precise. But IP geolocation is not GPS. At NANOG 96, Sid Mathur presented a talk called High-quality IP Geofeeds using AI Coding Assistants and MCP. One of the presentation’s most useful messages is precisely this: IP geolocation is statistical and inexact. The ideal is to think in geographical regions, not an exact point on the map [6]. He makes a good point: more precision doesn’t always mean higher quality. For a fixed ISP, which knows that a particular prefix serves a specific city, it makes sense to inform the city: But if the same prefix serves several nearby cities, it might be better to stop in the state: This avoids solving one customer’s problem and creating a problem for another. In the same presentation, he also comments on very real cases: users blocked for regional content, streaming thinking the person is in another country, websites showing the wrong weather and ISPs receiving complaints for something that is often outside the connectivity layer [6]. Anyone who lives in an operation knows that this happens. Does geofeed solve everything? No. And it’s important to be honest here. Publishing geofeed does not oblige Google, Netflix, banks, MaxMind, IPinfo, Cloudflare or any other consumer to immediately accept that information. RFC 8805 treats the geofeed as a source published by the operator. Consumers can collect it, validate it, cross-reference it with other databases and decide whether or not to use it [1]. Even so, publishing correctly greatly improves your position. Before, you had to manually call up several different databases, each with its own process. With geofeed, you create a public, standardized and automatically discoverable source. It’s not a guarantee of instant correction, but it’s a much better operating practice. How do others find out about your geofeed? Publishing the file to a URL is only part of the story. You need to indicate where this file is in the IP block records. This is where RFC 9632 [2] comes in. It defines how to associate a geofeed file with IP resource registration objects, such as inetnum and inet6num. There are two main ways. The newest way is to use the own attribute: The way that is compatible with environments that don’t yet support the specific attribute is to use remarks: The important thing is that the consumer can look at the block record and discover that there is a geofeed file associated with it. What about RDAP? RDAP is the most modern way of querying registry data. While traditional WHOIS returns text, RDAP returns JSON. This makes it much easier to automate. RFC 9877 defines how an RDAP server can report geofeed links within

Geofeed: por qué tus IP aparecen en la ciudad equivocada y cómo empezar a solucionarlo

Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja: “Mi cliente está en Paraná, pero el sitio web cree que está en São Paulo”.“El streaming está diciendo que estoy en otro país”.“El banco bloqueó el acceso porque pensó que la ubicación IP era extraña”.“Google está mostrando una previsión meteorológica para otra ciudad”. Es una situación un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP está bien, DNS responde, traceroute pasa, la latencia es aceptable. Pero para el usuario final, la constatación es sencilla: algo va mal en su Internet. Y a menudo lo es. No en la conectividad, sino en la forma en que esa dirección IP está siendo geolocalizada por terceros. La IP no tiene ninguna ciudad registrada en su interior Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro. No existe tal campo en el protocolo IP: o: La geolocalización de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de búsqueda, los servicios de streaming y las bases comerciales intentan averiguar dónde se está utilizando probablemente esa IP. Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tráfico, mediciones, historial, información de usuarios, bases comerciales, DNS, BGP, entre otras cosas. En la mayoría de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia. Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicación. Sólo que las bases externas pueden tardar en aprenderlo. Y entonces empiezan las llamadas. Dónde entra el geofeed El geofeed es una forma normalizada de que el operador de red diga: “Estos prefijos IP se están utilizando en estos lugares”. No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesión ascendente. No es más que un archivo CSV publicado a través de HTTPS, siguiendo un formato definido en el RFC 8805 [1]. Un ejemplo sencillo: 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 línea asocia un prefijo a una ubicación aproximada. El formato es: En la práctica: Es decir: La coma del final es importante. Representa el último campo, postal_code, que está vacío. Qué significa cada campo El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR. Ejemplos: El segundo campo es el país, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR. El tercer campo es la región, utilizando la norma ISO 3166-2. En el caso de los estados brasileños: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia rápida, también existe la página ISO 3166-2:BR, que enumera los códigos de los estados brasileños [5]. El cuarto campo es la ciudad. El quinto campo es el código postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precaución, porque puede dar demasiada granularidad [1]. Para el ISP, en la mayoría de los casos, el país, el estado y la ciudad son suficientes. La geolocalización es aproximación, no GPS Este punto es más importante de lo que parece. Cuando hablamos de geolocalización, es fácil caer en la tentación de intentar ser demasiado precisos. Pero la geolocalización IP no es un GPS. En NANOG 96, Sid Mathur presentó una charla titulada Geolocalización IP de alta calidad mediante asistentes de codificación de IA y MCP. Uno de los mensajes más útiles de la presentación es precisamente éste: la geolocalización IP es estadística e inexacta. Lo ideal es pensar en regiones geográficas, no en un punto exacto del mapa [6]. Tiene razón: más precisión no siempre significa más calidad. Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad: Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado: Esto evita resolver el problema de un cliente y crear un problema a otro. En la misma presentación, también comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona está en otro país, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo está fuera de la capa de conectividad [6]. Cualquiera que viva en una operación sabe que esto ocurre. ¿El geofeed lo soluciona todo? No. Y aquí es importante ser honesto. Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa información. La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1]. Aun así, publicar correctamente mejora mucho tu posición. Antes, tenías que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente pública, normalizada y descubrible automáticamente. No es una garantía de corrección instantánea, pero es una práctica operativa mucho mejor. ¿Cómo se enteran los demás de tu geofeed? Publicar el archivo en una URL es sólo una parte de la historia. Tienes que indicar dónde está este archivo en los registros del bloque IP. Ahí es donde entra la RFC 9632 [2]. Define cómo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum y inet6num. Hay dos formas principales. La forma más novedosa es utilizar el atributo propio: La forma compatible con entornos que aún no admiten el atributo específico es utilizar remarks: Lo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a él. ¿Qué pasa con el RDAP? RDAP es la forma más moderna de

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

BOTNET KIMWOLF: Ataques DDoS Internos e como Mitigar agora (2026)

Mais uma vez, as redes dos ISPs estão sendo atacadas… mas agora o inimigo vem de dentro.  Você já viu o call-center explodir com reclamações de lentidão sem explicação? Mal nos recuperamos do ataque que explorou as vulnerabilidades no SDK Realtek onde roteadores e ONUs eram comprometidos e usados para DDoS contra terceiros, e já estamos lidando com uma ameaça muito mais perigosa e disseminada: a botnet AISURU/Kimwolf.  Essa botnet explora principalmente aparelhos Android baratos de IPTV, SmartTV e set-top-box instalados na casa dos usuários. Esses dispositivos viram zumbis que vendem proxy residencial e, em menor escala, participam de ataques DDoS a terceiros. O resultado?   Problemas generalizados em várias frentes:  RESULTADO: clientes frustrados, custo alto de suporte e risco de reputação pro ISP inteiro. Um ciclo vicioso que ninguém quer e que está crescendo rápido.  UM VERDADEIRO CAOS! Abaixo deixo um compilado de perguntas e respostas do que já sabemos sobre o assunto. E no final algumas dicas de como se proteger ou mitigar.  1) De onde vem esse ataque, e por quê?  Segundo os sites de segurança Xlab e Synthient, os atores envolvidos na botnet a utilizam para ganhar dinheiro com alguns tipos de serviço:   Como eles têm controle completo de todos os dispositivos, utilizam os servidores de comando-controle para criar túneis para navegação, instalar apps e iniciar ataques DDoS contra terceiros. Já houve reportes também de coisas além da segurança, como passar imagens e vídeos de assuntos controversos (políticos, geo-políticos, etc.). 2) Já tem muita gente infectada? Segundo dados da Synthient e XLab indicam, que é apenas uma fração das comunicações, foram mais de 12 milhões de IPs únicos (estimam cerca de 2 milhões de dispositivos). E a maior parte deles vem do Brasil (~15%), seguidos por Vietnã, Índia, USA e Argentina. A empresa chinesa de segurança XLab identificou que a botnet Kimwolf havia comprometido entre 1,8 e 2 milhões de dispositivos, com forte concentração no Brasil, Índia, Estados Unidos da América e Argentina. Imagem: blog.xLab.qianxin.com 3) Como os equipamentos são infectados? Você já deve ter se perguntado como esses equipamentos podem ser tão baratos né? Pois é. Algumas imagens de dispositivos que já vem infectados. Fonte: Synthient. E também já constatou que eles não passam por um processo rigoroso de correção de vulnerabilidades, patches de segurança e atualizações/melhorias. É o prato cheio nas mãos de criminosos. A principal forma de infecção da Kimwolf é explorando uma falha nas SDKs dos aplicativos de proxy-residencial (como Byteconnect, IPIDEA e PYPROXY). O atacante aluga um proxy legítimo desses serviços, usa o túnel para “voltar” pela conexão do próprio aparelho e acessar a rede local interna onde encontra o ADB (Android Debug Bridge) exposto sem autenticação (porta 5555 e similares). Em segundos, ele manda comandos remotos, baixa o malware e instala tudo. Topologia de infecção via proxy residenciais. Fonte: Synthient. Existem algumas formas que o equipamento pode ser infectado (mas todas acabam convergindo nesse mecanismo principal): 1º) Vindo de fábrica Muitos aparelhos saem de fábrica já com aplicativos de proxy-residencial pré-instalados (sem o usuário saber), para monetizar a banda depois. Quando o dispositivo entra no pool de proxy (ex: IPIDEA, Byteconnect, PYPROXY), o atacante explora exatamente essa porta aberta.Este é o jeito principal de infecção é assim que a botnet Kimwolf mais se espalhou, com milhões de dispositivos comprometidos em meses. 2º) Através de instalação de apps não confiáveis Os usuários instalam aplicativos de terceiros (não verificados), e estes silenciosamente adicionam o SDK de proxy, ativando o caminho para a exploração via ADB. 3º) Portas vulneráveis ADB/Telnet Alguns desses IPTV já vêm com ADB exposto por padrão. Mesmo sem o SDK inicial, um pequeno scan/brute force em portas como 5555, 3222 ou 5858 permite acesso shell e instalação do malware. 4) O que são estes apps de proxy-residenciais? Basicamente são empresas que vendem navegação à internet através de seus “proxies” ao redor do mundo. Quando você compra um serviço com eles, você estabelece uma “VPN” até os seus servidores, e então a sua navegação sai pelo pacote escolhido (por exemplo, navegação por IPs residenciais do Brasil, do Vietnã, etc.). Eles ganham dinheiro cobrando alguns dólares por GB trafegado. Mas e o que fazer? Se quer uma resposta fácil, você não terá. Vamos ter que enfrentar esse problema em diversas frentes. Afinal, diferente de outras botnets onde o dispositivo estava no controle do ISP (o roteador, a ONU, etc), neste caso os equipamentos infectados em 99% dos casos são do próprio cliente. Na perspectiva do ISP, podemos enfrentar o problema em 4 ações: Ação 1: identificar clientes/equipamentos ofensores No github da Synthient (o link vai estar mais abaixo), há uma fração da lista de IPs/portas utilizadas na botnet. Mas eles já são a primeira etapa para identificação. Utilize esta lista e compare com as comunicações no seu software de netflow (de preferência o made4flow), vindos do seu BNG. Com isto, você já vai conhecer quem internamente está infectado. Ação 2: mitigar / contornar impactos Aqui entra a criatividade técnica. O básico é o bloqueio em firewall ou blackhole das comunicações (mas elas não duram por muito tempo e servem no máximo como band-aid – pois a botnet é tão capaz de trocar de IPs/redes quanto as TVs piratas de contornar bloqueios da Anatel). Feito isto, comece a pensar em soluções mais elaboradas. Se precisar de ajuda, nos chame! Ação 3: corrigir equipamentos infectados As recomendações dos sites de segurança são: destrua estes aparelhos. Ponto final. Mas sabemos da realidade. Não tem como destruir o aparelho de um cliente, e sim trabalhar na conscientização. Desenvolva um roteiro, tenha jogo de cintura, e vá visitar seu cliente. Mostre como a rede dele está sendo utilizada para cometer crimes. Mostre os sites, os artigos. Tente atualizar, resetar, remover aplicativos suspeitos. Use o site https://synthient.com/check para mostrar ao cliente que ele foi pego nas varreduras da botnet. Ação 4: implementar monitoramento constante Se você está lidando com isso na sua rede e quer trocar ideia sobre filtros, PBR ou monitoramento automático, me manda mensagem ou comentário aqui. Estamos ajudando vários ISPs a mapear e isolar esses dispositivos sem dor de cabeça extra. QUERO AJUDA #CyberSecurity #DDoS #Botnet #ISP #Kimwolf #ProvedorInternet #SegurancaDigital Referências do artigo https://synthient.com/blog/a-broken-system-fueling-botnetshttps://blog.xlab.qianxin.com/kimwolf-botnet-en/#backgroundhttps://synthient.com/checkhttps://github.com/synthient/public-research/blob/main/2026/01/kimwolf/README.mdhttps://krebsonsecurity.com/2026/01/the-kimwolf-botnet-is-stalking-your-local-network/https://krebsonsecurity.com/2026/01/who-benefited-from-the-aisuru-and-kimwolf-botnets/https://krebsonsecurity.com/2025/11/is-your-android-tv-streaming-box-part-of-a-botnet/

BOTNET KIMWOLF: Internal DDoS Attacks and How to Mitigate Now (2026)

Once again, ISP networks are under attack… but now the enemy comes from within. Have you ever seen the call center explode with complaints of unexplained slowness? We’ve barely recovered from the attack that exploited vulnerabilities in the Realtek SDK where routers and ONUs were compromised and used for DDoS against third parties, and we’re already dealing with a much more dangerous and widespread threat: the AISURU/Kimwolf botnet. This botnet mainly exploits cheap Android IPTV, SmartTV and set-top-box devices installed in users’ homes. These devices become zombies that sell home proxies and, to a lesser extent, participate in DDoS attacks on third parties. The result? Widespread problems on several fronts: RESULT: frustrated customers, high support costs and reputational risk for the entire ISP. A vicious circle that nobody wants and that is growing fast. REAL CHAOS! Below is a compilation of questions and answers to what we already know about the subject. And at the end some tips on how to protect or mitigate yourself. 1) Where is this attack coming from and why? According to security websites Xlab and Synthient, the actors involved in the botnet use it to make money from certain types of service: Since they have complete control of all the devices, they use the command-control servers to create browsing tunnels, install apps and launch DDoS attacks against third parties. There have also been reports of things beyond security, such as passing on images and videos of controversial subjects (political, geo-political, etc.). 2) Are there already a lot of people infected? According to data from Synthient and XLab, which is only a fraction of communications, there were more than 12 million unique IPs (they estimate around 2 million devices). And most of them came from Brazil (~15%), followed by Vietnam, India, the USA and Argentina. The Chinese security company XLab identified that the Kimwolf botnet had compromised between 1.8 and 2 million devices, with a strong concentration in Brazil, India, the United States and Argentina. Image: blog.xLab.qianxin.com 3) How is the equipment infected? You may have wondered how such equipment can be so cheap, right? That’s right. Some images of devices that are already infected. Source: Synthient. And you’ve also seen that they don’t go through a rigorous process of vulnerability fixing, security patches and updates/improvements. It’s a full plate in the hands of criminals. The main way Kimwolf is infected is by exploiting a flaw in the SDKs of residential proxy applications (such as Byteconnect, IPIDEA and PYPROXY). The attacker rents a legitimate proxy from these services, uses the tunnel to “go back” through the device’s own connection and access the internal local network where he finds the ADB (Android Debug Bridge) exposed without authentication (port 5555 and similar). In seconds, it sends remote commands, downloads the malware and installs everything. Residential proxy infection topology. Source: Synthient. There are a number of ways in which equipment can be infected (but they all end up converging on this main mechanism): 1º) From the factory Many devices leave the factory with proxy-residential applications pre-installed (without the user knowing), in order to monetize the bandwidth later. When the device enters the proxy pool (e.g. IPIDEA, Byteconnect, PYPROXY), the attacker exploits exactly this open port.This is the main way of infection and this is how the Kimwolf botnet spread the most, with millions of compromised devices in months. 2º) By installing unreliable apps Users install third-party (unverified) applications, and these silently add the proxy SDK, activating the exploit path via ADB. 3º) Vulnerable ADB/Telnet ports Some of these IPTVs already come with ADB exposed by default. Even without the initial SDK, a small scan/brute force on ports such as 5555, 3222 or 5858 allows shell access and installation of the malware. 4) What are these proxy apps? Basically, they are companies that sell internet browsing through their “proxies” around the world. When you buy a service from them, you set up a “VPN” to their servers, and then your browsing goes through the chosen package (for example, browsing through residential IPs in Brazil, Vietnam, etc.). They make money by charging a few dollars per GB of traffic. But what to do? If you want an easy answer, you won’t get it. We’re going to have to tackle this problem on several fronts. After all, unlike other botnets where the device was in the ISP’s control (the router, the UN, etc), in this case the infected equipment in 99% of cases is the customer’s own. From an ISP perspective, we can tackle the problem in 4 actions: Action 1: identify offending customers/equipment On Synthient’s github (the link will be further down), there is a fraction of the list of IPs/ports used in the botnet. But they are already the first step towards identification. Use this list and compare it with the communications in your netflow software (preferably made4flow), coming from your BNG. With this, you will already know who is infected internally. Action 2: mitigate / circumvent impacts This is where technical creativity comes in. The basic thing is to block communications through a firewall or blackhole (but these don’t last long and serve at most as a band-aid – because the botnet is just as capable of changing IPs/networks as pirate TVs are of bypassing Anatel’s blocks). Once this is done, start thinking about more elaborate solutions. If you need help, call us! Action 3: fix infected equipment The recommendations of security websites are: destroy these devices. Period. But we know the reality. You can’t destroy a customer’s device, but you can work on raising awareness. Develop a script, play your cards right and go visit your client. Show them how their network is being used to commit crimes. Show them the sites, the articles. Try updating, resetting, removing suspicious applications. Use the website https://synthient.com/check to show the customer that they have been caught in the botnet scans. Action 4: implement constant monitoring If you’re dealing with this in your network and want to exchange ideas about filters,

BOTNET KIMWOLF: Ataques DDoS internos y cómo mitigarlos ahora (2026)

Una vez más, las redes ISP están siendo atacadas… pero ahora el enemigo viene de dentro. ¿Has visto alguna vez el centro de llamadas estallar con quejas de lentitud inexplicable? Apenas nos hemos recuperado del ataque que explotó vulnerabilidades en el SDK de Realtek, en el que se comprometieron routers y ONUs y se utilizaron para DDoS contra terceros, y ya estamos lidiando con una amenaza mucho más peligrosa y extendida: la botnet AISURU/Kimwolf. Esta botnet explota principalmente dispositivos baratos Android IPTV, SmartTV y set-top-box instalados en los hogares de los usuarios. Estos dispositivos se convierten en zombis que venden proxies domésticos y, en menor medida, participan en ataques DDoS a terceros. ¿El resultado? Problemas generalizados en varios frentes: RESULTADO: clientes frustrados, elevados costes de asistencia y riesgo para la reputación de todo el ISP. Un círculo vicioso que nadie quiere y que crece rápidamente. CAOS REAL A continuación encontrarás una recopilación de preguntas y respuestas a lo que ya sabemos sobre el tema. Y al final algunos consejos sobre cómo protegerte o mitigarlo. 1) ¿De dónde procede este ataque y por qué? Según los sitios web de seguridad Xlab y Synthient, los actores implicados en la botnet la utilizan para ganar dinero con determinados tipos de servicios: Como tienen el control total de todos los dispositivos, utilizan servidores de control de comandos para crear túneles de navegación, instalar aplicaciones y lanzar ataques DDoS contra terceros. También se ha informado de cosas que van más allá de la seguridad, como la difusión de imágenes y vídeos de temas controvertidos (políticos, geopolíticos, etc.). 2) ¿Ya hay demasiadas personas infectadas? Según los datos de Synthient y XLab, que son sólo una fracción de las comunicaciones, hubo más de 12 millones de IP únicas (estiman que unos 2 millones de dispositivos). Y la mayoría procedía de Brasil (~15%), seguido de Vietnam, India, EE.UU. y Argentina. La empresa de seguridad china XLab identificó que la botnet Kimwolf había comprometido entre 1,8 y 2 millones de dispositivos, con una fuerte concentración en Brasil, India, Estados Unidos y Argentina. Imagen: blog.xLab.qianxin.com 3) ¿Cómo se infectan los equipos? Seguro que te has preguntado cómo puede ser tan barato un equipo así, ¿verdad? Pues sí. Algunas imágenes de dispositivos ya infectados. Fuente: Synthient. Y también has visto que no pasan por un riguroso proceso de corrección de vulnerabilidades, parches de seguridad y actualizaciones/mejoras. Es un plato lleno en manos de delincuentes. La principal forma de infectar Kimwolf es aprovechando un fallo en los SDK de las aplicaciones proxy (como Byteconnect, IPIDEA y PYPROXY). El atacante alquila un proxy legítimo de estos servicios, utiliza el túnel para “volver atrás” a través de la propia conexión del dispositivo y acceder a la red local interna, donde encuentra el ADB (Android Debug Bridge) expuesto sin autenticación (puerto 5555 y similares). En segundos, envía comandos remotos, descarga el malware y lo instala todo. Topología de infección por proxy residencial. Fuente: Synthient. Hay varias formas de infectar los equipos (pero todas acaban convergiendo en este mecanismo principal): 1º) De fábrica Muchos dispositivos salen de fábrica con aplicaciones proxy preinstaladas (sin que el usuario lo sepa), para monetizar después el ancho de banda. Cuando el dispositivo entra en el grupo proxy (por ejemplo, IPIDEA, Byteconnect, PYPROXY), el atacante explota exactamente este puerto abierto.Ésta es la principal vía de infección y así es como más se propagó la botnet Kimwolf, con millones de dispositivos comprometidos en meses. 2º) Instalando apps poco fiables Los usuarios instalan aplicaciones de terceros (no verificadas), y éstas añaden silenciosamente el SDK del proxy, activando la ruta del exploit a través de ADB. 3º) Puertos ADB/Telnet vulnerables Algunos de estos IPTV ya vienen con ADB expuesto por defecto. Incluso sin el SDK inicial, un pequeño escaneo/fuerza bruta en puertos como 5555, 3222 o 5858 permite el acceso shell y la instalación del malware. 4) ¿Qué son estas aplicaciones proxy? Básicamente, son empresas que venden la navegación por Internet a través de sus “proxies” en todo el mundo. Cuando les compras un servicio, configuras una “VPN” a sus servidores, y luego tu navegación pasa por el paquete elegido (por ejemplo, navegar a través de IPs residenciales en Brasil, Vietnam, etc.). Ganan dinero cobrando unos pocos dólares por GB de tráfico. Pero, ¿qué hacer? Si quieres una respuesta fácil, no la tendrás. Vamos a tener que abordar este problema desde varios frentes. Al fin y al cabo, a diferencia de otras botnets en las que el dispositivo estaba bajo el control del ISP (el router, la ONU, etc.), en este caso el equipo infectado en el 99% de los casos es el del propio cliente. Desde la perspectiva de un ISP, podemos abordar el problema con cuatro acciones: Acción 1: Identificar a los clientes/equipos infractores En el github de Synthient (el enlace estará más abajo), hay una parte de la lista de IPs/puertos utilizados en la botnet. Pero ya son el primer paso hacia la identificación. Utiliza esta lista y compárala con las comunicaciones de tu software netflow (preferiblemente made4flow), procedentes de tu BNG. Con esto, ya sabrás quién está infectado internamente. Acción 2: mitigar / eludir los impactos Aquí es donde entra en juego la creatividad técnica. Lo básico es bloquear las comunicaciones mediante un cortafuegos o un agujero negro (pero éstos no duran mucho y sirven como mucho de tirita, porque la red de bots es tan capaz de cambiar de IP/red como las TV piratas de burlar los bloqueos de Anatel). Una vez hecho esto, empieza a pensar en soluciones más elaboradas. Si necesitas ayuda, ¡llámanos! Acción 3: reparar los equipos infectados Las recomendaciones de los sitios web de seguridad son: destruye estos dispositivos. Y punto. Pero conocemos la realidad. No puedes destruir el aparato de un cliente, pero puedes trabajar para concienciarlo. Desarrolla un guión, ten tu ingenio a mano y ve a visitar a tu cliente. Enséñale cómo se utiliza su red para cometer delitos. Enséñales los sitios, los artículos. Prueba a actualizar, reiniciar y eliminar las

Testes de Desempenho CGN/BNG em Plataforma Huawei NE8000 

Aprenda com Luiz Puppin, especialista em Huawei, como fazer uma análise técnica dos testes de desempenho (Forwarding Performance) realizados em um ambiente de laboratório com a plataforma Huawei NE8000, validando a capacidade do equipamento em operar como BNG+CGN integrado em alta carga.  Os testes buscaram verificar:  Objetivo dos Testes de Desempenho  O objetivo foi comprovar que a solução Huawei consegue sustentar:  Essas características são fundamentais para operações de ISPs e operadoras com alta concentração de assinantes atrás de CGN.  Arquitetura Utilizada  A topologia utilizada conecta:  Metodologia 5. Evidências e Resultados A seguir estão as comprovações extraídas diretamente do arquivo de teste. 5.1. Assinantes autenticados com sucesso O relatório confirma a autenticação simultânea de milhares de assinantes PPPoE: O total validado foi de: 5.2. Criação de 32 milhões de sessões NAT O DUT atingiu o limite de escalabilidade previsto pelo fabricante: Ou seja, o equipamento suportou 32 milhões de fluxos simultâneos, sem degradação perceptível. 5.3. Tráfego Sustentado a 50 Gbps – Sem Perda de Pacotes Ou seja: 5.4. Tráfego Bidirecional 50 Gbps (25G + 25G) O laboratório validou a operação simultânea upstream e downstream: Novamente, com zero perda de pacotes: 5.5. Estabilidade da CPU A CPU permanece em níveis estáveis, sem atingir limites críticos. 5.6. Conclusão dos Testes de Desempenho Com base nas evidências, é possível concluir que: Portanto, a plataforma demonstra capacidade real para operar CGN/BNG em ambientes de larga escala, com alto volume de tráfego e grande densidade de assinantes. Este artigo foi desenvolvido em colaboração com a equipe de Gerentes de Produtos IP para ISP da Huawei Brasil, com agradecimento especial ao Thiago Sério e ao Natan Fernandes. Precisa de ajuda para na configuração dos seus equipamentos Huawei? Nós podemos te ajudar! Quero conhecer mais

MC-LAG on Huawei routers

How to configure MC-LAG on Huawei: E-Trunk, Eth-Trunk, LACP and BFD step by step. Learn MC-LAG in Huawei, today we show you why E-Trunk (multi-chassis), when to use Eth-Trunk (aggregation), how to adjust LACP for active/backup ports and how BFD shortens MTTR. We include recommendations for hashing in MPLS scenarios and a test script to validate failure behavior. Link-aggregation (LAG), called Trunk at Huawei(Eth-Trunk when it’s Ethernet), is a technology that combines multiple physical interfaces into a single logical interface. With link-aggregation we win: Traditional LAG is always between two devices, point to point: Types of LAG for Huawei Quite simply, at Huawei we have three main ways of using Eth-Trunk: In the context of MC-LAG, what matters to us is basically: Let’s make it simple: Manual Static LACP How Trunk balances traffic Eth-Trunk doesn’t “add ports” like a giant door. The equipment decides which member to send each flow through using balancing algorithms. This defines two main behaviors: Hash-based load-balancing It’s standard on most routers/switches. It works like this: The hash can use various criteria, for example: With hash, the default mode is per-flow: Hash has an important consequence: It doesn’t always distribute bandwidth evenly.Depending on the distribution of flows (hash), one member may be at the bottleneck while another has almost no traffic. This is normal. Dynamic load-balance Some devices support dynamic mode, which monitors the instantaneous load of each member and reallocates flows between links that are underutilized or overloaded. One device that uses this type of balancing is Datacom’s switches. And what can the chips use for hashing? Hardly anyone talks about this point, but it’s crucial. Depending on the ASIC, the router may look: In the case of MPLS: This matters because: Practical examples: In a nutshell: The greater the MPLS depth that the ASIC sees, the better the distribution of MPLS flows in the LAG. What LACP does LACP (Link Aggregation Control Protocol, IEEE 802.3ad) is the guy who: At Huawei, when Eth-Trunk is in static LACP, the member interfaces: The side with the highest system priority (lowest numerical value) becomes the Actor. From there: What needs to be “OK” for LAG to rise properly For an Eth-Trunk with LACP to work as expected, certain points need to be aligned between the two sides: What LACP does is use system priority + system ID + interface priority + interface number to: Entering MC-LAG So far we’ve been talking about “normal” LAG, i.e. between two devices only. MC-LAG (Multi-Chassis LAG) comes in when you want it: The idea is simple: MC-LAG’s main objective: It’s basically taking the idea of redundancy from the port/link level to the device level. Active/active vs active/backup In many vendors you can find MC-LAG in two flavors: At Huawei, for this specific scenario with E-Trunk/mLACP, the behavior is active/backup: MC-LAG at Huawei: E-Trunk vs mLACP In Huawei, there are two main ways of implementing MC-LAG: The difference lies in the control mechanism between the PEs: In this article, we’ll focus on E-Trunk, which is the “classic” form of MC-LAG in many PE-CE scenarios. How E-Trunk works Don’t confuse E-Trunk (the sync technology between chassis) with Eth-Trunk (the link-aggregation itself). Consider the following scenario: The PEs then: With that: When a fault occurs: Optionally, you can: CE connectivity ↔ PEs with E-Trunk Some important design points: Use cases In the topology below, we’ll cover two use cases for MC-LAG (there are many others). 1) MC-LAG protecting VPLS (layer 2) At the top of the drawing, CE1 is multihomed to PE1 and PE2 using MC-LAG, all in the same VPLS-1 instance.On the network side, PE1/PE2 close the VPLS with PE3, which delivers the same service to CE2. This is end-to-end L2 protection for the VPLS, with equipment and POP redundancy. 2) MC-LAG protecting /30 L3 (layer 3) At the bottom of the drawing, CE3 receives a /30 L3 via MC-LAG, dual-homed in PE2 and PE3. Setting up the environment Now that you know all the concepts behind MC-LAG, let’s go to the lab. We’re going to use the PNETLAB virtual environment, with the Huawei NE40 V22 image. The physical ports and connections between devices are described in the topology below. The configuration of the CEs is simple: a mikrotik (ROS 7.6) using bonding interfaces, with LACP fast (in 1s). CE3 is simply a physical interface with a VLAN. CE1 CE2 CE3 The configuration of the PEs includes the point-to-point interfaces, active with OSPF, MPLS. On the access interfaces, the LAG and e-trunk synchronization configurations. And in the service layer, we have set up the VPLS (VSI) and also the L3 gateway (with the mac-address and the same IP). PE1 – Core Layer MLAG and E-trunk service This is where MLAG really comes into its own. We first create an ordinary Eth-Trunk, and then associate it with an e-trunk configuration, which makes the MLAG magic happen. With the LAG created, we now need to create the e-trunk configuration. To configure it, we need to: In our lab, we’ll close the loopback between PE1 and PE2 – these are part of the MLAG from CE1’s perspective. The master priority will be PE2, with priority 5. The timers configured are 9 for hello and 30 for hold-timer. Finally, it’s time to associate the LAG interface with e-trunk, thus creating an MLAG from CE1’s perspective. VPLS services PE2 – Core Layer The CORE and VPLS configurations of PE2 are similar to those of PE1 MLAG and E-trunk service Redundant Gateway Services For the redundant gateway service for CE3, we will: PE3 – Core Layer PE3’s CORE configurations are similar to those of PE1. VPLS services Unlike PE1 and PE2, which have an MLAG with the CE, in this case PE3xCE2 communication takes place directly on the physical interface with vlan 10. The VPLS settings remain the same, the difference is in the peers, which close the VPLS with PE1 and PE2 at the same time. Redundant Gateway Services Validating configurations and redundancy MC-LAG between devices In