¿Qué es TR069?
Hola, mi nombre es Marcos Lucas, formo parte del Equipo de Soporte Técnico para la Implementación de Made4Graph y TR069, hoy me gustaría hablar de mi primer trabajo con un ISP/Telecom, que fue como agente de soporte en una red de internet. proveedor. Después de un rato de trabajo vino a hablarme el encargado del sector y me dijo que estaba pensando en abrir un turno extra de apoyo, porque hasta ese momento el horario era de 22:00hrs, pero estaba pensando en extenderlo hasta las 00:00hrs, acepté, fue un tiempo de mucho aprendizaje, porque el turno de las 10:00pm sufrió algunos cambios, y en ocasiones, asumí la responsabilidad del soporte solo, lo cual fue genial, porque aprendí mucho , pero fue mucho trabajo. Fui responsable de parte de la configuración del equipo para el cliente final. Todo se hizo manualmente, incluso la parte de atención al cliente. Muchas veces los clientes venían a decir que el wifi no funcionaba correctamente, que no nos llegaba el ancho de banda, o incluso que sus juegos no funcionaban como deberían, en fin, eran varios los motivos, y todo lo revisaba manualmente el soporte, y eso que lleva un tiempo, imagínate tener 15 clientes al mismo tiempo, loco no? Ahora, que tal si te digo que hay una forma más fácil de buscar esta información, y que el soporte que a veces duraba horas, se puede resolver en minutos, esto también depende del conocimiento de quien está operando el soporte. Recientemente me presentaron TR-069 o CWMP, un protocolo simple pero poderoso que brinda precisamente la información que ayuda a respaldar en los puntos donde es más doloroso y difícil, la búsqueda de información de una manera clara y directa. ¿Qué es TR069? TR069 (Technical Reporting 069) es el nombre del informe elaborado por el foro de Banda Ancha que estandariza la gestión de los dispositivos CPEs (Customer Promises Equipment) o equipos en el domicilio del cliente, tales como (routers domésticos, ONUs y ONTs). Más precisamente hablaremos del TR-069 que describe el CWMP (CPE WAN Management Protocol). CWMP es un protocolo de administración remota que funciona en la capa de aplicación, donde permite que el CPE se comunique con un servidor ACS (Servidor de configuración automática). Este protocolo puede admitir una variedad de funcionalidades para administrar CPE que incluyen; Autoconfiguración Gestión de imágenes de firmware Supervisión de estado, rendimiento y diagnóstico. Cambio de configuración remota como Wifi, WAN, LAN, PPPoE Configuración automática TR069 permite que un ACS aprovisione un CPE o una colección de CPE en función de una variedad de criterios, agregados en el servidor ACS. El motor de aprovisionamiento incluye parámetros para el aprovisionamiento general y un mecanismo para agregar características específicas del proveedor según sea necesario. Esto permite el aprovisionamiento masivo, y también si hay un caso de restablecimiento de CPE, ACS reconocerá el parámetro como restablecido e inmediatamente usará su base de datos para volver a aprovisionar el CPE a su estado anterior. En cuanto a la configuración de parámetros específicos del proveedor, el mecanismo de identificación TR-069 permite el aprovisionamiento del CPE en base a los requerimientos de cada CPE específico o en criterios colectivos, tales como: proveedor del CPE, modelo, versión de software, entre otros criterios. Gestión de imágenes de firmware El TR069 proporciona mecanismos para identificar la versión del firmware y el Software CPE, con esto es posible administrar la descarga de archivos de imagen de firmware CPE. La descarga del archivo se puede iniciar desde el ACS o el CPE (opcional). También es posible verificar el éxito o fracaso de la descarga de un archivo, ya que el TR-069 admite esta operación. El protocolo TR-069 también define un formato de archivo firmado digitalmente que se puede usar opcionalmente para descargar archivos individuales o un paquete de archivos con instrucciones de instalación explícitas para que los ejecute el CPE. Este formato de paquete firmado garantiza la integridad de los archivos descargados y las instrucciones de instalación asociadas, lo que permite la autenticación de una fuente de archivo que puede ser distinta del operador de ACS. Supervisión de estado y rendimiento Si un proveedor de servicios desea monitorear el desempeño o el estado del servicio del CPE, el TR-069 admite la funcionalidad mediante la cual el CPE puede enviar estadísticas al ACS. Se puede encontrar un amplio conjunto de parámetros generales, junto con esto brinda la posibilidad de que los proveedores definan parámetros adicionales que el ACS puede monitorear. También define un conjunto de condiciones bajo las cuales el CPE debe notificar activamente los cambios a la ACS. Es importante recordar que algunos Vendors limitan la entrega de parámetros, o incluso entregan parámetros muy específicos, y en este último caso requiere una configuración más profunda del servidor ACS. Respecto a la no entrega de los parámetros, es importante consultar con el Vendor (Fabricante) si es posible agregar las opciones al firmware. Recuerde, el ACS solo lee los parámetros, no los genera y luego los envía al CPE. Diagnóstico TR069 admite una funcionalidad que permite actualizar la información de disponibilidad del CPE, que el ACS puede utilizar para determinar la causa del mal funcionamiento de la conectividad o la degradación del servicio. El TR069 define un conjunto común de parámetros y un mecanismo general para agregar capacidades de diagnóstico específicas del proveedor, y puede usar esta capacidad para centrarse en un solo dispositivo y recopilar información de diagnóstico para un análisis más detallado. La siguiente imagen muestra el funcionamiento del TR069 desde el proveedor hasta el domicilio del cliente ¿Conseguiste entender cómo funciona el TR069 y cómo puede facilitarte el día a día? ¿Quieres entender cómo funciona? La continuidad del contenido está aquí. Aquí en Made4it tenemos el TR069 como módulo dentro del software de gestión de clientes PPPoE/IPoE, Made4Graph que cuenta con esta y otras funcionalidades que te ayudarán a ti y a tu proveedor a gestionar tu cliente con más asertividad y agilidad. Si aún tienes dudas o quieres conocer el TR069 de Made4graph, te sugiero que
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:00hrs, mas estava pensando em estender até as 00:00hrs, 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 duravam 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 (Tecnical Reporting 069) é o nome do relatório escrito pelo Broadband fórum que padroniza a gerenciamento de dispositivos CPEs (Customer Promisses Equipament), 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 de 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, é pode usar esse recurso para se concentrar em um único dispositivo e coletar informações de diagnóstico para análise posterior. A imagem a baixo 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
Issues with local CDN traffic (Google GGC) and BGP ads
Hello. My name is Gabriel, I’m a network analyst here at Made4IT and today I’m going to tell you about an interesting situation involving CDN GGC Google and traffic engineering that we caught here in the consulting team a while ago. We received a call from a customer with a case where traffic from a local CDN GGC Google had a drastic decrease after a traffic engineering change. After extensive validations by the customer they were unable to find the root cause of this behavior and so they called our team. We started there on 11/04 with a strange decrease in Inbound traffic on the interface with the local CDN. It was very succinct and represented 1Gbps less traffic on the interface. With this info in hand, the first thing I did was access Made4Flow to help understand what happened using of course my favorite chart, the “Interface by ASN”I took care to take a time interval contemplating exactly the event from the 3rd to the 4th precisely to understand which ASNs were no longer “served” by the local cache. With that in hand, I noticed 2 things right away:– The “Orange” ASN here is no longer “served” by this CDN, this is a fact due to the decrease in traffic evident in the graph…– The “Blue” ASN(s) (a set of specific ASNs custom configured in our software) also showed a significant decrease in the graph. The “Blue” ASN is who hosts the cache. The ASN “Orange” being also a Made4IT client allowed us a more efficient test within its network. ASN “Azul” and ASN “Orange” as partners gave us total freedom to carry out the troubleshooting and validate what was necessary on both sides. After some checks, we used the content provider’s own tool to validate which “node/cache” was “serving” this traffic that stopped coming from the local CDN of the “Azul” ASN. This traffic no longer comes from the ASN “Azul” CDN, but it needs to come from somewhere, do you agree? In the image above, 2 things caught my attention:– A Node in Guarulhos, referring to the network of this content provider, is the one who started to deliver the traffic that should previously come from the local CDN of the “Azul” ASN– x.x.x.0/25? At the time, a very important piece of information about ads for this content provider’s CDNs came to mind. They obey a rule that says:– Direct ads (ASN hosting cache) node accepts up to /27 for direct influence on traffic engineering and content delivery eligibility.– Indirect advertisements (ASNs adjacent to the ASN hosting the cache) the node only accepts up to /24 for direct influence on traffic engineering and content delivery eligibility.Alright, for the ASN “Azul” traffic I already had the possible cause of the problem. When trying to induce this local node to deliver more traffic, they ended up announcing /25 blocks to the cache node, implying that the content provider network would “serve” this traffic via its nodes in Guarulhos. However, we still have a decrease in traffic on the “Azul” ASN, what happened? The “Blue” ASN in this case was actually 3 ASNs, something that was custom created in the Made4Flow software. Interestingly, 2 of these ASNs were “injecting” /25 prefixes into the CDN node, where the behavior found was exactly the same as the one reported above for the ASN “Orange. With all this information in hand, we set out to get our hands dirty and adjust the ads respecting what the content provider requests (and has documented) for its CDN. After the necessary adjustments, see the result: Conclusion:We know that for a CDN node to work there are several factors and that it involves protocols working in an orchestrated way, such as BGP, DNS, TCP, among others… CDN out of acceptable range.When we announce the blocks /25 of ASNs adjacent to the ASN hosting the node/cache, the “player” started delivering traffic to that ASN/Prefix via its CDN nodes from Guarulhos, implying an increase in indirect traffic on our ASN client “Azul” and loss of performance and efficiency of the local node. Users behind this network were directly affected as their content started to be delivered by an infrastructure over 1000kms away, increasing latency, loading time and overall user experience. After adjustments in traffic engineering respecting the content provider’s documentation and good BGP practices, the node started to behave again as expected. For traffic engineering contemplating CDNs, always respect the documentation of the player in question and use its tools to detect which “node” is “serving” the traffic. Usually CDN players also have a portal to monitor the performance of the cache with metrics and very important data about it, use these tools to your advantage. Did you find it interesting and want to see a little more about how the software we use in this conversation works or do you want to talk to a specialist to solve problems like this on your network? Talk to our team– Gabriel Henrique, Network Analyst at Made4IT, has been working with technology and ISPs for over 10 years.
Problemas con el tráfico CDN local (Google GGC) y anuncios BGP
Hola. Mi nombre es Gabriel, soy analista de redes aquí en Made4IT y hoy les voy a hablar de una situación interesante que involucra a CDN GGC Google y la ingeniería de tráfico que captamos aquí en el equipo de consultoría hace un tiempo. Recibimos una llamada de un cliente con un caso en el que el tráfico de un CDN local GGC Google tuvo una disminución drástica después de un cambio de ingeniería de tráfico. Después de validaciones exhaustivas por parte del cliente, no pudieron encontrar la causa raíz de este comportamiento, por lo que llamaron a nuestro equipo. Empezamos allí el 04/11 con una extraña disminución en el tráfico entrante en la interfaz con el CDN local. Fue muy breve y representó 1 Gbps menos de tráfico en la interfaz. Con esta información en la mano, lo primero que hice fue acceder a Made4Flow para ayudar a comprender lo que sucedió usando mi gráfico favorito, la “Interfaz por ASN“.Tuve cuidado de tomar un intervalo de tiempo contemplando exactamente el evento del 3 al 4 precisamente para entender qué ASN ya no eran “servidos” por el caché local. Con eso en la mano, noté 2 cosas de inmediato:– El ASN “Orange” aquí ya no es “servido” por este CDN, esto es un hecho debido a la disminución de tráfico evidente en la gráfica…– Los ASN “azules” (un conjunto de ASN específicos configurados de forma personalizada en nuestro software) también mostraron una disminución significativa en el gráfico. El ASN “Azul” es quien aloja el caché. El ASN “Orange” siendo también un cliente de Made4IT nos permitió una prueba más eficiente dentro de su red. ASN “Azul” y ASN “Orange” como socios nos dieron total libertad para llevar a cabo la resolución de problemas y validar lo necesario en ambos lados. Después de algunas comprobaciones, utilizamos la propia herramienta del proveedor de contenido para validar qué “nodo/caché” estaba “sirviendo” este tráfico que dejó de provenir del CDN local del ASN “Azul”. Este tráfico ya no proviene del ASN “Azul” CDN, sino que debe provenir de algún lugar, ¿está de acuerdo? En la imagen de arriba, 2 cosas me llamaron la atención:– Un Nodo en Guarulhos, refiriéndose a la red de este proveedor de contenido, es quien pasó a entregar el tráfico que antes debía provenir del CDN local del ASN “Azul”– x.x.x.0/25? En ese momento, me vino a la mente un dato muy importante sobre los anuncios de los CDN de este proveedor de contenido. Obedecen una regla que dice:– El nodo de anuncios directos (caché de alojamiento ASN) acepta hasta /27 para influencia directa en la ingeniería de tráfico y la elegibilidad de entrega de contenido.– Anuncios indirectos (ASN adyacentes al ASN que aloja el caché), el nodo solo acepta hasta /24 para influencia directa en la ingeniería de tráfico y la elegibilidad de entrega de contenido.Muy bien, para el tráfico ASN “Azul” ya tenía la posible causa del problema. Al tratar de inducir a este nodo local a entregar más tráfico, terminaron anunciando bloques /25 al nodo de caché, lo que implica que la red del proveedor de contenido “serviría” este tráfico a través de sus nodos en Guarulhos. Sin embargo, todavía tenemos una disminución en el tráfico en el ASN “Azul”, ¿qué pasó? El ASN “azul” en este caso era en realidad 3 ASN, algo que se creó de forma personalizada en el software Made4Flow. Curiosamente, 2 de estos ASN estaban “inyectando” prefijos /25 en el nodo CDN, donde el comportamiento encontrado fue exactamente el mismo que el informado anteriormente para el ASN “Orange. Con toda esta información en la mano, nos propusimos poner manos a la obra y ajustar los anuncios respetando lo que el proveedor de contenido solicita (y tiene documentado) para su CDN. Después de los ajustes necesarios, vea el resultado: Conclusión:Sabemos que para que un nodo CDN funcione hay varios factores y que implica que los protocolos funcionen de forma orquestada, como BGP, DNS, TCP, entre otros… CDN fuera de rango aceptable.Cuando anunciamos los bloques /25 de ASN adyacentes al ASN que aloja el nodo/caché, el “jugador” comenzó a entregar tráfico a ese ASN/Prefijo a través de sus nodos CDN desde Guarulhos, lo que implica un aumento de tráfico indirecto en nuestro cliente ASN “Azul” y pérdida de rendimiento y eficiencia del nodo local. Los usuarios detrás de esta red se vieron directamente afectados ya que su contenido comenzó a ser entregado por una infraestructura a más de 1000 km de distancia, lo que aumentó la latencia, el tiempo de carga y la experiencia general del usuario. Luego de ajustes en la ingeniería de tráfico respetando la documentación del proveedor de contenido y las buenas prácticas de BGP, el nodo volvió a comportarse como se esperaba. Para la ingeniería de tráfico que contempla CDNs, siempre respete la documentación del reproductor en cuestión y utilice sus herramientas para detectar qué “nodo” está “sirviendo” el tráfico. Por lo general, los reproductores de CDN también tienen un portal para monitorear el rendimiento del caché con métricas y datos muy importantes al respecto, use estas herramientas a su favor. ¿Te pareció interesante y quieres ver un poco más sobre cómo funciona el software que usamos en esta conversación o quieres hablar con un especialista para solucionar problemas como este en tu red? Habla con nuestro equipo– Gabriel Henrique, analista de redes en Made4IT, ha estado trabajando con tecnología e ISP durante más de 10 años.
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 há 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, aonde o comportamento encontrado foi exatamente igual ao relatado acima do ASN “Laranja. Com todas essas informações em mãos, partimos 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 1000kms 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õe 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 a 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 sendo 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
Cómo configurar Blackhole en Cisco IOS-XE
Ahora que ya sabes qué es un BGP Blackhole (si aún no lo sabes, consulta nuestro artículo sobre RTBH – Blackhole). Ahora toca configurarlo y poder protegerte de los ataques DDoS. Para resumir el Blackhole, es una técnica de enviar una ruta al “agujero negro” o simplemente hacer que el router descarte paquetes dirigidos a esa IP. Con Blackhole también puede anunciar estas IP atacadas a sus proveedores/upstreams y así detener los ataques. Ahora que sé lo que es, ahora viene la pregunta, ¿cómo bloquear mi enrutador? En el artículo de hoy, le mostraremos cómo configurar Blackhole en los enrutadores Cisco. Para hacer el Blackhole manualmente tenemos unos pasos que son: Identificar la IP atacada; Crea la ruta al agujero negro; Anuncie esta ruta de agujero negro a través de BGP a sus operadores/ascendentes. Puedes automatizar todo esto con Made4Flow, ya cerrando una sesión directa y sin tener que hacer trabajo manual. Vamos a la configuración entonces 1 – Identificar la IP atacada Esto lo puedes hacer a través del análisis de Netflow, como en Made4Flow, a través de las gráficas e identificar a través del Raw Data Report, qué IP tiene más tráfico y posiblemente sea víctima del ataque. Dentro de Made4Flow, acceda, por ejemplo, al Gráfico de Interfaz por Aplicación, luego, haciendo clic en el puerto más utilizado, puede identificar qué IP está siendo atacada, o a través de Made4Flow, simplemente accediendo al módulo Anti-DDoS -> Anomalías activas. La IP atacada fue: 200.189.56.55 (Ejemplo) 2) Crear una ruta a Blackhole o Null0 Después de identificar la IP atacada a través de Made4Flow, ahora es el momento de crear la ruta en su enrutador Cisco para arrojar efectivamente la IP a Blackhole o Null0. Supongamos que la IP atacada es 200.200.200.1, creemos la ruta de la siguiente manera Comandos aplicados: enableconfigure terminalip route 200.200.200.1 255.255.255.255 Null0 ¡Después de aplicar la ruta que apunta a Null0, esta IP DEJARÁ DE FUNCIONAR! Puede verificar la ruta usando el comando show: Si la ruta se muestra como Null0, entonces ya la está enviando a Blackhole. 3 – Anuncie la IP en blackhole a través de BGP a sus operadores/upstreams Después de identificar y bloquear la ruta, debe anunciarse a través de BGP a sus operadores/ascendentes. Nota: Antes de configurar, siempre se recomienda hablar con su Operador/Upstream para averiguar qué comunidad Blackhole BGP es. Es necesario establecer la sesión BGP con su operador. Para ello tenemos unos pasos: Configure su comunidad Blackhole Carrier/Upstream Para configurar la comunidad Blackhole para usarla más tarde, necesitamos ejecutar el siguiente 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 En caso de que sea necesario agregar más comunidades, aplique el mismo comando cambiando el nombre y el número de la comunidad. Sugerencia: hable con su operador para averiguar qué comunidad de agujero negro BGP utilizan. Anuncie la IP atacada con la comunidad BlackHole para Upstream Para realizar la publicidad de la IP atacada con la comunidad blackhole es necesario realizar los siguientes pasos; Ingrese la configuración BGP del enrutador Cisco Luego de eso, anunciamos la IP atacada a nuestro Upstream, usando el siguiente comando; Comandos: router bgp 65000neighbor 192.168.100.1 as 64700neighbor 192.168.100.1 route-map BLACKHOLE out Automatizando con Made4Flow Con Made4Flow, es posible automatizar el proceso de anuncio de agujero negro de IP atacadas. Para eso necesitamos: Configure la sesión BGP entre el Edge Router y Made4Flow; Para configurar la sesión BGP entre el enrutador y Made4Flow, debe crear un mapa de ruta y luego la sesión BGP. Para configurar el mapa de ruta: Comando: route-map MADE4FLOW-IN permit 1000 set ip nex-hop 192.168.66.66 En este caso, es necesario agregar Next-hop manualmente en el enrutador. Dentro de Made4Flow, ya puede anunciarse con la comunidad BGP y el Next-hop correcto si lo prefiere. Configurar Made4Flow para enviar a través de Acciones Dentro del Módulo Anti-DDoS, puede acceder al menú: Acciones y Respuestas y configurar la respuesta para enviar el Blackhole con la comunidad BGP correcta: Configure el enrutador para enviar a los operadores Para configurar el envío a operadores/aguas arriba, debe configurar para que la comunidad BGP se identifique en la coincidencia del mapa de ruta saliente. Para esto necesitamos configurar un filtro de community-filter El siguiente paso es configurar el Route-map de tu operador/upstream, como en el envío del blackhole, pero ahora emparejando a la comunidad en el match, como en nuestra configuración: Compruebe si recibe de Made4Flow Dominio: show bgp ipv4 unicast neighbors 192.168.120.2 routes Y si vas a enviar al transportista: Dominio: show bgp ipv4 unicast neighbors 192.168.1.1 advertised-routes Una vez realizados estos ajustes, la automatización de Made4Flow está lista. Al recibir un ataque, Made4Flow ahora puede enviar esta ruta a Blackhole. Tenemos otros contenidos sobre cómo configurar Blackhole que puedes encontrar en nuestro blog y cualquier duda que aún te quede, ponte en contacto con nuestro equipo de expertos Leonardo Nacimiento | consultor made4it
How to Configure Blackhole on Cisco IOS-XE
Now that you know what a BGP Blackhole is (if you still don’t know, check out our article on RTBH – Blackhole). Now it’s time to configure it and be able to protect yourself from DDoS attacks. To summarize the Blackhole, it is a technique of sending a route to the “black hole” or simply making the router discard packets directed to that IP. With Blackhole you can also announce these attacked IPs to your suppliers/upstreams and thus stop the attacks. Now that I know what it is, now comes the question, how to blackhole my router? In today’s article we will show you how to configure Blackhole on Cisco routers To do the Blackhole manually we have some steps that are: Identify the attacked IP; Create the route to blackhole; Advertise this blackhole route via BGP to your carriers/upstreams. You can automate all of this with Made4Flow, already closing a direct session and not having to do manual work. Let’s go to the settings then 1 – Identify the attacked IP You can do this through Netflow analysis, as in Made4Flow, through the graphs and identify through the Raw Data Report, which IP has the most traffic and possibly being the victim of the attack. Within Made4Flow, access, for example, the Interface Graph by Application, then, by clicking on the most used port, you can identify which IP is being attacked, or through Made4Flow, simply by accessing the Anti-DDoS module -> Active Anomalies. The attacked IP was: 200.189.56.55 (Example) 2) Create a route to Blackhole or Null0 After identifying the attacked IP via Made4Flow, now it’s time to create the route on your Cisco Router to effectively throw the IP to Blackhole or Null0. Let’s assume that the attacked IP is 200.200.200.1, let’s create the route as follows Commands applied: enableconfigure terminalip route 200.200.200.1 255.255.255.255 Null0 After applying the route pointing to Null0 this IP will STOP WORKING! You can check the route using the show command: If the route is showing as Null0 then you are already sending it to Blackhole. 3 – Advertise the IP in blackhole via BGP to your operators/upstreams After identifying and blackhole the route, you need to advertise via BGP to your carriers/upstreams. Note: Before setting up, it is always recommended to talk to your Operator/Upstream to find out which Blackhole BGP community is. The BGP session with your carrier needs to be established. For this we have a few steps: Configure your Carrier/Upstream Blackhole Community To configure the blackhole community to be used later, we need to run the following command: Commands: 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 In case it is necessary to add more communities, apply the same command changing the community name and number. Tip: Talk to your operator to find out which BGP blackhole community they use. Announce the attacked IP with the BlackHole community for Upstream To carry out the advertisement of the attacked IP with the blackhole community, it is necessary to carry out the following steps; Enter the Cisco router’s BGP configuration After that, we announce the attacked IP to our Upstream, using the command below; Commands: router bgp 65000neighbor 192.168.100.1 as 64700neighbor 192.168.100.1 route-map BLACKHOLE out Automating with Made4Flow With Made4Flow, it is possible to automate the blackhole announcement process of attacked IPs. For that we need: Configure the BGP session between the Edge Router and Made4Flow; To configure the BGP session between the Router and Made4Flow, you need to create a route-map and then the BGP session. To configure the route-map: Comando: route-map MADE4FLOW-IN permit 1000 set ip nex-hop 192.168.66.66 In this case it is necessary to add Next-hop manually on the router. Within Made4Flow, you can already advertise with the BGP community and the correct Next-hop if you prefer. Configure Made4Flow to send via Actions Within the Anti-DDoS Module, you can access the menu: Actions and Responses and configure the response to send the Blackhole with the correct BGP community: Configure the Router to Send to Carriers To configure to send to operators/upstreams you need to configure so that the BGP community is identified in the outbound Route-map match. For this we need to configure an ip community-filter The next step is to configure the Route-map of your operator/upstream, as in sending the blackhole, but now matching the community in the match, as in our configuration: Check if you receive from Made4Flow Command: show bgp ipv4 unicast neighbors 192.168.120.2 routes And if you are sending to the operator: Command: show bgp ipv4 unicast neighbors 192.168.1.1 advertised-routes Having made these settings, the automation of Made4Flow is ready. Upon receiving an attack, Made4Flow can now send this route to Blackhole. We have other content on how to configure Blackhole that you can find on our blog and any questions you still have, please contact our team of experts Leonardo Nascimento | Made4it consultant
Como identificar um Gato net ou internet ilegal?
Para começarmos esse artigo, gostaria de descrever o que são os Provedores de Internet Clandestinos, ou também chamados de “Gato Net”. Provedores clandestinos/ Gato Net geralmente são criados por pessoas físicas ou jurídicas que contratam um Link de Internet que não é recomendado e geralmente não possuem licenças das autoridades governamentais para revender internet. Geralmente eles contratam um link residencial e compartilham ou vendem para seus vizinhos, amigos, etc. Provedores clandestinos, além de serem ilegais (conforme art. 183 da lei Nº. 9.472 (Lei Geral das Telecomunicações – LGT), podem trazer riscos para nossas redes, pois na maioria das vezes são feitos por pessoas sem o conhecimento técnico necessário para manter uma rede com boas práticas de configurações. Em muitos casos o Gato Neta acaba sendo alvo de ataques DDoS, causando efeitos negativos para o seu provedor. Caso seja identificado um cliente em seu provedor que esteja cometendo tais práticas, pode-se valer de meios legais para fazer cessar tais práticas. Porém, como fazemos para identificar um cliente que esteja usando essas práticas para compartilhamento ou venda de internet ilegal? Com a ferramenta Made4graph, conseguimos visualizar os clientes que estão com o maior uso de banda: Também podemos verificar o gráfico em tempo real do cliente junto com o extrato completo de uso, nos mostrando o consumo em cada período que ficou conectado: Com essas informações conseguimos fazer algumas comparações com outros clientes que tem a mesma quantidade de banda contratada. Se houver uma diferença grande de uso entre clientes, temos um indício de que este usuário está fazendo compartilhamento ilegal de Internet. Uma outra observação que podemos fazer é utilizando o Grafico Historico do Cliente, nele vamos visualizar uma semelhança com graficos de um ISP, onde o maior trafego ocorre entre as 19:00 até as 22:00 horas. É importante que o provedor de internet se antecipe cuide da sua rede para não precisar lidar com problemas ainda maiores! Quer ver mais opções de gráficos do software Made4grarph? Acesse a versão demo ou agende uma apresentação com o time comercial da made4it! Gelso Baltazar | Consultor |
¿Cómo identificar una internet ilegal?
Para comenzar este artículo, me gustaría describir qué son los Proveedores de Internet Clandestino, o también llamados “Internet Ilegal”. Los proveedores de Internet clandestinos/ilegales suelen ser creados por personas naturales o jurídicas que contratan un Enlace de Internet que no es recomendable y generalmente no cuentan con licencias de las autoridades gubernamentales para revender Internet. Suelen contratar un enlace residencial y compartirlo o venderlo a sus vecinos, amigos, etc. Los proveedores clandestinos, además de ser ilegales (según el art. 183 de la Ley Nº. 9.472 (Ley General de Telecomunicaciones – LGT), puede traer riesgos a nuestras redes, ya que la mayoría de las veces son realizadas por personas sin los conocimientos técnicos necesarios para mantener una red con buenas prácticas de configuración. En muchos casos, Internet ilegal acaba siendo blanco de ataques DDoS, provocando efectos negativos para su proveedor. Si se identifica a un cliente en su proveedor que está cometiendo tales prácticas, se pueden utilizar medios legales para detener tales prácticas. Sin embargo, ¿cómo identificamos a un cliente que utiliza estas prácticas para compartir o vender Internet ilegal? Con la herramienta Made4graph pudimos visualizar los clientes con mayor uso de ancho de banda: También podemos consultar la gráfica en tiempo real del cliente junto con el extracto completo de uso, mostrándonos el consumo en cada periodo que estuvo conectado: Con esta información pudimos hacer algunas comparaciones con otros clientes que tienen la misma cantidad de ancho de banda contratado. Si hay una gran diferencia en el uso entre los clientes, tenemos una indicación de que este usuario está compartiendo Internet ilegalmente. Otra observación que podemos hacer es utilizando la Gráfica Histórica del Cliente, en la cual veremos una similitud con las gráficas de un ISP, donde el mayor tráfico se da entre las 19:00 y las 22:00 horas. ¡Es importante que el proveedor de Internet se ocupe de su red con anticipación para que no tenga que lidiar con problemas aún mayores! ¿Quiere ver más opciones de gráficos del software Made4graph? ¡Acceda a la versión de demostración o programe una presentación con el equipo de ventas de made4it! Gelso Baltazar | Consultor |
