Funcionalidades e benefícios do TR-069 no Made4Graph

Como vimos em nossos artigos sobre TR-069, o protocolo CWMP, apresenta muitas funcionalidades e vários benefícios, e estes podem ser encontrados na ferramenta Made4Graph, onde esta possui um módulo específico para TR-069. A imagem abaixo mostra o módulo, e o que pode ser acessado na ferramenta.             Na primeira opção do módulo, temos a Dashboard TR-069, esta tela mostra relatórios completos do status dos equipamentos que possuem TR-069 habilitado, bem como a porcentagem total dos dispositivos que possuem ou não o TR69 habilitado.             É possível ver também os modelos de CPE, os fabricantes e também a quantidade de cada um na base do Provedor, que tenha o TR-069 habilitado.             A imagem abaixo mostra como são apresentadas as informações ao utilizador. Na segunda opção do módulo, temos a CPE, nesta aba são encontradas diversas funcionalidades, utilizadas pelo suporte, dentre elas estão: Alterar a senha, nome e canal, do wifi, tanto 2.4Ghz, quanto 5.8GHz Verificar status das portas LAN Verificar o tempo que a CPE está ligada Verificar número de clientes conectados a CPE, com a opção de histórico de clientes conectados, para auxiliar o suporte na resolução de problemas mais difíceis, sem a necessidade de se deslocar à casa do cliente. Verificar o sinal PON de ONTs/ONUs Verificar se existe um redirecionamento de portas na CPE Imagem da CPE, que auxilia a equipe de suporte a conhecer melhor o equipamento que está sendo dado suporte             A imagem abaixo exibe as abas presentes dentro da opção CPE do TR-069             Esta tela também pode ser encontrada na aba Gráfico Realtime, quando selecionamos o PPPoE do cliente desejado, vamos em Grafico Realtime. Em seguida vamos na opção de Gestão de Equipamento, ali também podem ser realizadas as configurações da CPE via TR-069, isso permite maior agilidade na hora de configurar a CPE do cliente             O Made4Graph conta com mais de 20 templates de Vendors/Fabricantes diferentes, para TR-069, com seus respectivos parâmetros e as configurações específicas, além disso em nossa base de homologação existem mais de 40 modelos de CPEs de diversos fabricantes e modelos de equipamentos que permitem uma flexibilidade na hora de trazer a sua base de CPEs para o TR-069.             As imagens abaixo ilustram os templates disponíveis, e também os equipamentos que foram homologados dentro do TR-069.             É possível fazer a restauração dos dados da CPE após o reset baseado no template que foi configurado. Existem ainda muitas outras funcionalidades, ao final deste artigo deixarei um link onde você pode acessar gratuitamente a versão demo do made4graph, e TR-069. Você pode assistir um tour pelo tr069 do made4graph nesse vídeo aqui Qualquer dúvida de como funciona nossa ferramenta ou uma apresentação completa da ferramenta, entre em contato conosco que nosso time de especialistas está disponível para você

Como solicitar um CDN do Google?

Olá pessoal!! Aqui é o Luís Dias, consultor na Made4it e hoje iremos falar um pouco sobre CDNs, mais especificamente Google Global Cache (GGC), um tema muito bacana e interessante que já existe em nossas vidas há muito tempo e que facilita muito nosso trabalho em escalabilidade da rede. É um tema bem interessante e que requer um pouco de atenção, então pega um café bem forte e vem comigo.  Primeiro que é CDN? Um CDN abreviação de Content delivery network (Rede de Entrega de Conteúdo) é um grupo de servidores distribuídos geograficamente que acelera a entrega de conteúdo da Web, aproximando-o de onde os usuários finais estão. Esse equipamento utiliza o armazenamento em cache, um processo que armazena cópias de arquivos temporariamente, para que você possa acessar o conteúdo da Internet a partir de um dispositivo mais rapidamente por meio de um servidor próximo a você. Os CDNs armazenam todo tipo de conteúdo em cache, como página da Web, imagens e vídeos. Isso permite que você assista a um filme, faça downloads de software, publique nas redes sociais ou faça compras sem ter que esperar pelo carregamento do conteúdo. GGC – Google Global Cache O GGC ou Google Global Cache, são os Servidores do Google espalhados pelos ISPs do Brasil e do mundo afora. Os GGCs são servidores instalados dentro das Redes dos ISPs e Operadoras para melhorar a experiência dos usuários com o conteúdo do google, provendo mais velocidade, latência e experiência destes usuários com os Serviços do Google. O CDN do Google, além de melhorar a experiência dos usuários com a plataforma deles, também é usado para reduzir o congestionamento e redução do tráfego de Trânsito, PTT e Peering para o Google. Assim reduzindo custos para o ISP ou Operadora. Nada mais do que uma troca muito boa, tanto para o Google que seus usuários ficam felizes com a performance e para o ISP fica muito bom pois economiza em quantidade de Link ou Trânsito. Como funciona o GGC: Quando um utilizador solicita um conteúdo – por exemplo, um vídeo, página web, ou uma imagem, o Sistema do Google determina se o conteúdo pode ser servido a partir do Nó GGC. Se o Nó GGC tiver o conteúdo solicitado no seu Servidor Cache, ele irá servir o conteúdo diretamente para o utilizador final, melhorando a rapidez/latência da navegação para o utilizador e otimizando os recursos de banda do ISP. Se o conteúdo não estiver armazenado no Servidor Cache, o Nó GGC vai recuperar esse conteúdo a partir dos servidores da Google e armazena para as futuras solicitações. Como é feita a solicitação do GGC: Para podermos fazer a solicitação do GGC, primeiro precisamos saber quanto temos de tráfego para conteúdo do Google. Pois como todo CDN, temos um requisito de mínimo de banda para conteúdos relacionados ao Google, como Youtube, etc. Hoje a banda mínima é um tráfego maior de 3Gbps – 95 percentil por pelo menos 3 meses. 95 Percentil* – é um cálculo matemático utilizado para avaliar o uso regular e sustentado de links de comunicação de rede. Mas você deve estar se perguntando “Luís, como eu vou saber quanto de tráfego eu tenho para o Google, para solicitar o GGC?” Para esse procedimento podemos utilizar uma ferramenta de Netflow, neste caso aqui estarei utilizando o Made4Flow, a melhor e mais prática ferramenta de Netflow do mercado. Vamos entender como essa mágica funciona: Ao entrarmos nos deparamos com a Dashboard da ferramenta, onde conseguimos especificar o tipo de tráfego que queremos gerar o relatório de consumo, ou podemos escolher a dashboard que queremos, no caso para ver tráfego para o Google, Netflix, Facebook, Akamai. Ao entrarmos na aba Dashboard Google, iremos conseguir ver quanto temos de tráfego total para o Google e verificar se iremos conseguir solicitar o CDN, visto que eles pedem um tráfego percentil mínimo. Após analisarmos, conseguimos dar continuidade na solicitação do GGC Para fazermos a solicitação do GGC (Google Global Cache) é necessário entrarmos no site: https://isp.google.com/partner_request/?data.request_type=Peering E preenchermos o formulário onde vamos colocar os nossos dados como ASN, nome, endereço, etc. Após solicitação caso aprovado, iremos receber um e-mail, informando se fomos aprovados ou não. Caso aprovado, o Google ira nos reportar o passo a passo que devemos seguir e nos passará um prazo de estimativa de quanto tempo levará para o servidor chegar no endereço que fornecemos no formulário. Espero que tenham gostado e compreendido o conteúdo! Caso tenha alguma dúvida entre em contato com nosso time de especialistas.

Controle de banda Seletivo no Roteador Huawei

Olá, meu nome é Gabriel Henrique, sou analista de redes aqui na Made4it e hoje vou mostrar para vocês como configurar o controle de banda seletivo em usuários de camada de acesso nos roteadores da linha NE da Huawei. O controle de banda seletivo abre a possibilidade de novos produtos ou a melhora, incremento ou “charme” na entrega do serviço ao usuário final sendo um diferencial muito interessante, principalmente para ISPs que possuem CDN local. Mas, afinal, do que se trata o controle de banda seletivo ? Normalmente, nas implementações de BNGs/BRAS/PPPoE Server, temos como corriqueiro um controle de banda global (do ponto de vista do usuário) do qual todo e qualquer conteúdo é limitado pelo valor do plano contratado. No controle de banda seletivo, temos a possibilidade de atrelar diferentes bandas para diferentes serviços, onde você pode por exemplo atrelar um controle de banda de valor “X” para o seu conteúdo local de CDN, “y” para o tráfego interno a sua rede e “z” quando a origem ou destino do tráfego é externo (links, transitos, Peering, IX/PTT, PNI, transportes…), podemos dizer que fazemos o QoS seletivo ou que controlamos especificamente quanto de banda por conteúdo ou também poderia ser dito que podemos tirar o controle de banda do CDN ou PBR seletivo. Enfim, chega de conversa, vamos para a parte mais legal 🙂 No nosso cenário de testes, temos: – Cliente com plano de 100Mbps – Necessidade de liberar até 500Mbps quando origem/destino for CDNs locais – Necessidade de manter 100Mbps quando origem/destino não forem CDNs Locais– CDNs locais endereçados com 192.0.2.0/24 e 2001:DB8::/64 Pré-requisitos: – ERP/Radius com suporte ao AVP “Huawei-Policy-Name”– Domain de autenticação dos clientes com um “user-group” declarado (Se não sabe o que é user-group, fique ligado no blog da Made que logo logo tem um post sobre Firewall que vai explicar exatamente do que se trata 😉 Passo 1: Configurar, no system-view, os parâmetros de Radius necessários e ativar a função de “Value Added Service” no roteador. Passo 2: No Radius-group usado para autenticação, ativar o suporte a accounting do value-added-service Passo 3: Configurar as ACLs de acesso delimitando o tráfego de CDN e o tráfego geral Passo 4: Configurar os “classifiers” para classificar o tráfego das ACLs Passo 5: Configurar os “behaviors” que vamos usar para identificar cada um dos classifiers Passo 6: Configurar a traffic-policy que será atrelada globalmente, contendo o classifier e behavior configurados anteriormente, efetivando a classificação diferenciada dos fluxos Passo 7: Aplicar a traffic-policy globalmente. Passo 8: Configurar os qos-profiles que vão delimitar a banda dos respectivos conteúdos Passo 9: Configurar a policy que irá controlar a banda do cliente Pronto. Agora, basta o ERP/Radius entregar para o cliente o AVP Huawei-Policy-Name := 150m que, o cliente terá o controle de banda limitando até 500Mbps quando a origem/destino forem os CDNs locais, e até 100Mbps para as demais origens/destinos. Lembrando que se o ERP/Radius entregar o Huawei-Input-Average-Rate, o BRAS/BNG irá usá-lo preferencialmente e não irá aplicar o Policy name! A traffic-policy permite até 8 “tariff-levels” aonde você pode classificar seu tráfego em até 8 tipos de serviço e aplicar diferentes controles de banda para cada um deles. No caso de exemplo, caso queira configurar o controle de banda diferenciado para outros planos, basta criar novos “qos-profile” e “value-added-service policy” com os valores que deseja aplicar, pois o tráfego de CDN e geral já está classificado em “tariff-levels” distintos. É isso aí, até a próxima! Qualquer dúvida de como implantar essa configuração em sua rede entre em contato e converse com um dos nossos especialistas

Como Funciona o TR-069?

Já vimos um pouco das funcionalidades do TR069, para acessar o conteúdo onde apresentamos o que é o TR069 leia o nosso primeiro artigo, agora veremos como essa “mágica” funciona.  TR-069 é baseado em SOAP/HTTP, onde é feita a conexão entre a CPE e o ACS. A comunicação é feita através de chamadas de procedimento remoto (RPC), isso permite a CPE encaminhar os parâmetros, além do seu status atual, bem como gerência de firmware para o ACS. É muito importante lembrar que, quem inicia a conexão é a CPE, vai partir dela o primeiro contato, e também os informes periódicos ao ACS, pois a cada fração de tempo a CPE encaminha ao ACS um inform para que o ACS atualize seu status no servidor. O ACS somente vai iniciar o contato em momentos específicos, como: atualização de firmware, ou ainda uma interação iniciada pelo operador, mas que devem ser aceitas pela CPE para que seja concluída a ação. A imagem acima mostra a comunicação entre a CPE e o ACS, onde a CPE encaminha uma solicitação de conexão para o ACS, perceba que nesta foto, a CPE já é conhecida pelo ACS, do contrário a comunicação teria alguns campos a mais, como o GetParamenterNames request, onde esta solicitação parte do ACS para a CPE, com a intenção de conhecer os parâmetros que podem ser entregues ao ACS. Open connection: a CPE informa que quer falar com o ACS SSL initiation: é adicionado a comunicação um certificado para proteger a troca de mensagens inform request: a CPE diz ao ACS que vai informar seu status atual inform response: o ACS diz que a CPE pode encaminhar os parâmetros a ele HTTP post(empty): a CPE diz OK GetParameterValues request: requisição dos parâmetros da CPE GetParameterValues response: resposta da CPE com os parâmetros para o ACS SetParameterValues request: o ACS informa que agora conhece os parâmetros, e que precisa dos valores dos parâmetros da CPE SetParameterValues response: a CPE informa ao ACS os valores dos parâmetros, requisitados pelo ACS. HTTP response empty: o ACS informa que não existem mais informações para serem trocadas entre eles, e que pode ser finalizada a comunicação. Close connection: A CPE finaliza a conexão. É possível ter essa funcionalidade na sua rede de forma simples, que é através do módulo do TR069 no Made4graph, onde todas as informações necessárias ficam dentro da própria interface do software. Para você conhecer o Made4graph e os benefícios da ferramenta você pode acessar a demo ou então marcar uma demonstração com o time comercial 😁

Adicionar alerta por Telegram no Anti-DDoS

Uma das funcionalidades do Anti-DDoS do Made4flow é a possibilidade de enviar alertas de ataques para o seu celular via telegram. Preparamos um tutorial de como você pode configurar essa ação!

Atualizações Made4flow e Made4graph

Mais atualizações em nossos softwares Made4flow e Made4Graph!
O nosso time de desenvolvimento trouxe agora novas funções que vão ajudar o seu suporte, as atualizações dessa versão e de versões anteriores estão todas em nossa wiki que você pode ver aqui! Vamos ver quais foram elas

Porque só ter Zabbix não funciona?

Para entender essa pergunta, vamos lembrar como o Zabbix funciona. O Zabbix é um software open-source de monitoramento, com ele conseguimos monitorar nossos ativos de diversas maneiras, com protocolo SNMP, via Zabbix Agent, HTTP/S, com scripts externos, e por aí vai…. Quando instalamos e configuramos o Zabbix, vemos diversos templates prontos para poder monitorar equipamentos de diversas marcas e modelos, com eles temos itens, regras de descoberta, triggers, gráficos todos para já serem aplicados ao host, mas é lógico que sempre podemos melhorar o que já existe e adicionar mais ainda. Porém, mesmo adicionando seu host no Zabbix, selecionando o template correto e iniciando o monitoramento dele, não adianta de nada se não houver alguém para acompanhar esse monitoramento. Precisamos de alguém que esteja sempre de olho nos incidentes, nos gráficos dos hosts, nos dados coletados, para identificar algum possível problema. Imagina só! Durante seu expediente você sempre acompanha os gráficos dos seus links contratados com upstreams, porém após seu expediente, durante um horário de pico, um de seus links começa a bater o máximo contratado e afeta a entrega de internet para seus clientes finais, ou uma porta de um de seus equipamentos chega na capacidade máxima com o crescimento que ocorreu nos últimos meses. Isso poderia ser evitado caso houvesse alguém pronto para agir quando encontrado algum comportamento inesperado no monitoramento. Temos até a possibilidade de criar diversas dashboards também e nelas adicionarmos gráficos, histórico de incidentes e tudo mais para facilitar esse acompanhamento, mas sem alguém de olho no monitoramento quando algo assim ocorrer, se torna inútil. Um de nossos serviços, o Made4NOC, serve para isso. Temos nossa equipe de monitoramento à disposição, ela trabalha 24h por dia, 7 dias por semana e está sempre de olho em cada item no monitoramento dos ativos presentes em nosso Zabbix. Além disso, sempre que ocorre um incidente ou nossa equipe encontra um comportamento não esperado, está preparada para tomar ações, seja acionar nossa consultoria, entrar em contato com o cliente, seja entrar em contato com um fornecedor de link ou equipamento ou o que for necessário para podermos resolver tudo o quanto antes. Quer entender melhor como o NOC da Made4it pode ajudar sua rede? Fale com um dos nossos especialistas e saiba o que e como monitorar! Luiz Felipe | Consultor

O que é TR069?

Olá, me chamo Marcos Lucas, faço parte do Time Suporte Técnico de Implantação do Made4Graph e TR069, hoje gostaria de falar sobre meu primeiro trabalho com ISP/Telecom que foi como atendente de suporte em um provedor de internet. Depois de um certo tempo trabalhando, o responsável pelo setor veio conversar comigo e disse que estava pensando em abrir um turno a mais no suporte, pois até então o horário limite era 22:00h, mas estava pensando em estender até as 00:00h, eu topei, foi uma época de muito aprendizado, pois o turno das 22h sofreu algumas alterações, e em alguns momentos, assumi sozinho a responsabilidade pelo suporte, isso foi bacana, pois aprendi muito, porém muito trabalhoso. Eu era responsável por parte das configurações dos equipamentos para cliente final. Tudo era feito manualmente, mesmo a parte do suporte ao cliente. Muitas vezes os clientes vinham dizer que o wifi não estava funcionando certo, que a banda não estava chegando, ou ainda que seus jogos não estavam funcionando da forma que deveria, enfim os motivos são diversos, e tudo era verificado manualmente pelo suporte, e isso leva um tempo, imagina você com 15 clientes ao mesmo tempo, loucura né? Agora e se eu te disser que existe uma forma mais fácil de buscar essas informações, e aquele suporte que às vezes durava horas, pode ser resolvido em minutos isso depende também do conhecimento de quem está operando no suporte Recentemente fui apresentado ao TR-069 ou CWMP, um protocolo simples, mas poderoso, que entrega justamente as informações que auxiliam o suporte nos pontos onde é mais doloroso e difícil, a busca pela informação de maneira clara e direta. O que é o TR069? TR069 (Technical Report 069) é o nome do relatório escrito pelo Broadband Forum que padroniza o gerenciamento de dispositivos CPEs (Customer Premises Equipment), ou equipamento da casa do cliente, como por exemplo (Roteadores domésticos, ONUs e ONTs). Mais precisamente falaremos sobre o TR-069 que descreve o CWMP (CPE WAN Management Protocol). CWMP é um protocolo de gerenciamento remoto que trabalha na camada de Aplicação, onde este permite a comunicação da CPE com um servidor ACS (Auto Configuration Server). Este protocolo pode oferecer suporte a uma variedade de funcionalidades para o gerenciamento de CPEs, incluindo; Autoconfiguração Gerenciamento de imagem de firmware Monitoramento de status, desempenho e diagnósticos. Alteração de configuração remota como Wifi, WAN, LAN, PPPoE Configuração automática O TR069 permite que um ACS provisione uma CPE ou uma coleção de CPEs com base em uma variedade de critérios, adicionados no servidor de ACS. O mecanismo de provisionamento inclui parâmetros para provisionamento de forma geral e um mecanismo para adicionar recursos específicos do fornecedor conforme necessário. Isso permite o provisionamento em massa, e também se houver um caso de Reset da CPE, o ACS vai reconhecer o parâmetro como reset, e imediatamente vai usar a sua base de dados para re-provisionar a CPE ao seu estado anterior.             Sobre a configuração de parâmetros específicos do fornecedor o mecanismo de identificação TR-069 permite o provisionamento do CPE com base nos requisitos de cada CPE em específico ou em critérios coletivos, como: fornecedor do CPE, modelo, versão do software, entre outros critérios. Gerenciamento de imagem de firmware O TR069 fornece mecanismos para identificação da versão do firmware e do Software da CPE, com isso é possível gerenciar o download de arquivos de imagem de firmware do CPE. O download do arquivo pode ser iniciado a partir do ACS ou do CPE (opcional). É possível verificar também o sucesso ou falha do download de um arquivo, pois o TR-069 oferece suporte para esta operação. O protocolo TR-069 também define um formato de arquivo assinado digitalmente que pode ser usado opcionalmente para baixar arquivos individuais ou um pacote de arquivos com instruções de instalação explícitas para o CPE executar. Este formato de pacote assinado garante a integridade dos arquivos baixados e as instruções de instalação associadas, permitindo a autenticação de uma fonte de arquivo que pode ser outra parte que não a operadora ACS. Status e monitoramento de desempenho Caso um provedor de serviços deseje monitorar o desempenho ou status de serviço do CPE, o TR-069 oferece suporte à funcionalidade pela qual a CPE pode enviar estatísticas ao ACS. É possível encontrar um amplo conjunto de parâmetros gerais, juntamente a isso fornece a possibilidade de que os fornecedores definam parâmetros adicionais que o ACS pode monitorar. Ele também define um conjunto de condições sob as quais a CPE deve notificar ativamente o ACS sobre as mudanças. É importante lembrar que alguns Vendors limitam a entrega de parâmetros, ou ainda entregam parâmetros muito específicos, e neste último caso exige uma configuração mais profunda do servidor de ACS. Na questão da não entrega dos parâmetros, é importante checar com o Vendor (Fabricante) se é possível adicionar as opções a firmware. Lembre-se, o ACS apenas lê os parâmetros, ele não os gera e depois manda para a CPE. Diagnóstico TR069 suporta funcionalidade que permite atualizar as informações de disponibilidade da CPE, que o ACS pode usar para determinar a causa do mau funcionamento da conectividade ou degradação do serviço. O TR069 define um conjunto comum de parâmetros e um mecanismo geral para adicionar recursos de diagnóstico específicos do fornecedor, e pode usar esse recurso para se concentrar em um único dispositivo e coletar informações de diagnóstico para análise posterior. A imagem abaixo exibe o funcionamento do TR069 desde o provedor, até a casa do cliente Conseguiu entender como funciona o TR069 e como ele pode facilitar o seu dia a dia? Quer entender como ele funciona? A Continuidade do conteúdo está aqui Aqui na Made4it nós temos o TR069 como um módulo dentro do software de gerenciamento de cliente PPPoE/IPoE, o Made4Graph que conta com essa e outras funcionalidades que vão ajudar você e seu provedor a gerenciar seu cliente com mais assertividade e agilidade. Caso ainda tenha dúvidas ou queira conhecer o TR069 do Made4graph indico que você entre aqui nesse artigo ou converse com nosso time

Problemas com tráfego de CDN local (GGC Google) e anúncios BGP

Olá. Meu nome é Gabriel, sou analista de redes aqui na Made4it e hoje vou contar sobre uma situação interessante envolvendo CDN GGC Google e engenharia de tráfego que pegamos aqui no time de consultoria um tempo atrás. Recebemos um acionamento de um cliente com um case onde o tráfego de uma CDN local GGC Google teve um decremento drástico após uma alteração de engenharia de tráfego. Depois de validações extensas pelo cliente não conseguiram achar a causa primária deste comportamento e então acionaram nosso time. Começamos lá no dia 04/11 com um decremento estranho no tráfego de Inbound na interface com o CDN local. Foi bem sucinto e representou 1Gbps de tráfego a menos na interface. Com essa info em mãos, a primeira coisa que fiz foi acessar o Made4Flow  pra auxiliar a entender o que aconteceu usando claro meu gráfico favorito, o “Interface por ASN”Tomei o cuidado de pegar um intervalo de tempo contemplando exatamente o evento do dia 03 ao dia 04 justamente para entender quais ASNs exatamente deixaram de ser “servidos” pelo cache local. Com isso em mãos, de cara já notei 2 coisas:– O ASN “Laranja” aqui deixou de ser “servido” por essa CDN, isso é fato pelo decremento de tráfego evidente no gráfico…– O(s) ASN(s) “Azul” (um conjunto de ASNs específicos configurados de maneira personalizada em nosso software) também mostraram um decremento significativo no gráfico. O ASN “Azul” é quem hospeda o cache. O ASN “Laranja” sendo também cliente da Made4it nos permitiu um teste mais eficiente dentro de sua rede. O ASN “Azul” e ASN “Laranja” por serem parceiros nos deram total liberdade para conduzir o troubleshooting e validar o que fosse necessário em ambos os lados. Depois de algumas verificações, usamos a ferramenta do próprio provedor de conteúdo para validar qual “node/cache” estava “servindo” esse tráfego que deixou de vir pela CDN local do ASN “Azul”. Esse tráfego deixou de vir da CDN do ASN “Azul”, mas precisa vir de algum lugar, concordam? Na imagem acima, 2 coisas me chamaram a atenção sendo:– Um Node em Guarulhos, referente a rede desse provedor de conteúdo, é quem passou a entregar o tráfego que antes deveria vir na CDN local do ASN “Azul”– x.x.x.0/25? Na hora me acendeu a luz para um dado importantíssimo sobre anúncios para as CDNs desse provedor de conteúdo. Eles obedecem a uma regra que diz:– Anúncios diretos (ASN que hospeda o cache) o node aceita até /27 para influência direta na engenharia de tráfego e elegibilidade para entrega de conteúdo.– Anúncios indiretos (ASNs adjacentes ao ASN que hospeda o cache) o node aceita apenas até /24 para influência direta na engenharia de tráfego e elegibilidade para entrega de conteúdo.Beleza, para o tráfego do ASN “Azul” eu já tinha a possível causa do problema. Ao tentarem induzir esse nodo local a entregar mais tráfego, acabaram por anunciar blocos /25 ao node do cache implicando na rede do provedor de conteúdo “servir” este tráfego via seus nodes em Guarulhos. Porém, ainda temos um decremento de tráfego no ASN “Azul”, o que aconteceu? O ASN “Azul” nesse caso na verdade era 3 ASNs, algo que foi criado de maneira customizada no software Made4Flow. Curiosamente, 2 desses ASNs estavam “injetando” prefixos /25 no node da CDN, onde o comportamento encontrado foi exatamente igual ao relatado acima do ASN “Laranja”. Com todas essas informações em mãos, partimos para colocar a mão na massa e ajustar os anúncios respeitando o que o provedor de conteúdo solicita (e tem documentado) para sua CDN. Após os devidos ajustes, vejam o resultado: Conclusão:Sabemos que para um node de CDN funcionar existem diversos fatores e que envolve protocolos trabalhando de maneira orquestrada sendo eles o BGP, DNS, TCP, dentre outros… porém, nesse caso, nosso problema foi um desvio de comportamento quando feito um anúncio ao node da CDN fora do range aceitável.Ao anunciarmos os blocos /25 de ASNs adjacentes do ASN que hospeda o node/cache, o      “player” passou a entregar o tráfego para esse ASN/Prefixo via seus nodes de CDN lá de Guarulhos, implicando em um aumento de tráfego indireto no nosso cliente ASN “Azul” e perda de performance e eficiência do node local. Os usuários atrás dessa rede foram diretamente afetados uma vez que seu conteúdo passou a ser entregue por uma infraestrutura a mais de 1000 km de distância, incrementando latência, tempo de carregamento e experiência geral do usuário. Após os ajustes na engenharia de tráfego respeitando a documentação do provedor de conteúdo e boas práticas de BGP, o node passou a se comportar novamente como esperado. Para engenharia de tráfego contemplando CDNs, sempre respeitar a documentação do player em questão e usar as ferramentas do mesmo para detectar qual “node” está “servindo” o tráfego. Normalmente players de CDN também dispõem de portal para acompanhamento da performance do cache com métricas e dados importantíssimos sobre o mesmo, usem essas ferramentas ao seu favor. Achou interessante e quer ver um pouco mais como funciona o software que usamos nessa tratativa ou então quer conversar com especialista para resolver problemas como esse na sua rede? Fale com a nossa equipe– Gabriel Henrique, Analista de Redes na Made4it, trabalha há mais de 10 anos com tecnologia e ISPs.

Como configurar Blackhole no Cisco IOS-XE

Agora que você já sabe o que é uma Blackhole BGP (se caso ainda não saiba, confira nosso artigo sobre RTBH – Blackhole). Agora é hora de configurar ela e conseguir se proteger dos ataques DDoS. Para resumir a Blackhole, é uma técnica de enviar uma rota para o “buraco negro” ou simplesmente fazer o roteador descartar os pacotes direcionados a esse IP. Com a Blackhole você também pode anunciar para seus fornecedores/upstreams esses IPs atacados e assim conseguir cessar os ataques. Agora que já sei o que é, agora vem a pergunta, como fazer blackhole no meu roteador? No artigo de hoje vamos mostrar como configurar a Blackhole em roteadores Cisco Para fazer a Blackhole de forma manual temos alguns passos que são: Identificar o IP atacado; Criar a rota para blackhole; Anunciar essa rota em blackhole via BGP para suas operadoras/upstreams. Você pode automatizar tudo isso com o Made4Flow, já fechando uma sessão direta e não precisando fazer o trabalho manual. Vamos lá então para as configurações 1 – Identificar o IP atacado Você pode fazer isso através de análise de Netflow, como no Made4Flow, através dos gráficos e identificar através do Relatório de Dados Bruto, qual o IP tem um maior tráfego e possivelmente é a vítima do ataque. Dentro do Made4Flow, acesse por exemplo o Gráfico de Interface por Aplicação, depois, clicando em cima da porta com mais uso, você pode identificar qual IP está sendo atacado, ou através do Made4Flow, de forma simples acessando o módulo Anti-DDoS -> Anomalias Ativas. O IP atacado foi o: 200.189.56.55 (Exemplo) ​​2) Criar uma rota para Blackhole ou Null0 Após identificar o IP atacado via Made4Flow, agora é hora de criar a rota em seu Roteador Cisco para efetivamente jogar o IP para Blackhole ou Null0. Vamos supor que o IP atacado seja o 200.200.200.1, vamos criar a rota da seguinte maneira Comandos aplicado: enableconfigure terminalip route 200.200.200.1 255.255.255.255 Null0 Após aplicar a rota apontando para Null0 esse IP irá PARAR DE FUNCIONAR! Você pode checar a rota usando o comando de show: Se a rota estiver mostrando como Null0, você já está enviando-a para Blackhole. 3 – Anunciar o IP em blackhole via BGP para suas operadoras/upstreams Após identificar e colocar em blackhole a rota, você precisa anunciar via BGP para suas operadoras/upstreams. Obs: Antes da configuração é sempre recomendado falar com sua Operadora/Upstream para saber qual a community BGP de Blackhole. A sessão BGP com sua operadora precisa estar estabelecida. Para isso temos alguns passos: Configure a Community de Blackhole de sua Operadora/Upstream Para configurar a community de blackhole para que posteriormente seja utilizada, precisamos executar o seguinte comando: Comandos: ip prefix-list BLACKHOLE permit 200.200.200.1/32route-map BLACKHOLE permitmatch ip address prefix-list BLACKHOLEset community 666:666     set community 666:666 Caso seja necessário adicionar mais communities, aplique o mesmo comando mudando o nome e o número da community. Dica: Fale com a sua operadora para saber qual community BGP de blackhole ela usa. Anunciar o IP atacado com a community de BlackHole para o Upstream Para realizar o anúncio do IP atacado com a community de blackhole, é necessário realizar os seguintes passos; Entre na configuração de BGP do roteador Cisco Após isso, realizamos o anúncio do IP atacado para o nosso Upstream, por meio do comando abaixo; Comandos: router bgp 65000neighbor 192.168.100.1 as 64700neighbor 192.168.100.1 route-map  BLACKHOLE out Automatizando com o Made4Flow Com o Made4Flow, é possível automatizar o processo de anúncio para blackhole de IP’s atacados. Para isso precisamos: Configurar a sessão BGP entre o Roteador de Borda e Made4Flow; Para configurar a sessão BGP entre o Roteador e Made4Flow, você precisa criar uma route-map e depois a sessão BGP. Para configurar a route-map: Comando: route-map MADE4FLOW-IN permit 1000              set ip nex-hop 192.168.66.66 Neste caso é necessário adicionar o Next-hop manualmente no roteador. Dentro do Made4Flow, você já pode anunciar com a community BGP e o Next-hop correto se preferir. Configurar o Made4Flow para enviar via Ações Dentro do Módulo de Anti-DDoS, você pode acessar o menu: Ações e Respostas e configurar a resposta para enviar a Blackhole com a community BGP correta: Configurar o roteador para enviar para operadoras Para configurar para enviar para as operadoras/upstreams você precisa configurar para que a community BGP seja identificada no match da Route-map de saída. Para isso precisamos configurar um ip community-filter Próximo passo é configurar na Route-map da sua operadora/upstream, como no envio da blackhole, mas agora casando com a community no match, como em nossa configuração: Checar se você recebe do Made4Flow Comando: show bgp ipv4 unicast neighbors 192.168.120.2 routes E se está enviando para a operadora: Comando: show bgp ipv4 unicast neighbors 192.168.1.1 advertised-routes Feita essas configurações, está pronta a automatização do Made4Flow, ao receber um ataque o Made4Flow já pode enviar essa rota para Blackhole. Temos outros conteúdos de como configurar Blackhole que você pode encontrar em nosso blog e qualquer dúvida que ainda tiver entre em contato com nosso time de especialistas   Leonardo Nascimento | Consultor Made4it