Características y beneficios de TR-069 en Made4Graph

Como hemos visto en nuestros artículos sobre TR-069, el protocolo CWMP ofrece numerosas funcionalidades y diversas ventajas, que se pueden encontrar en la herramienta Made4Graph, la cual cuenta con un módulo específico para TR-069. La imagen que figura a continuación muestra dicho módulo y lo que se puede consultar en la herramienta. En la primera opción del módulo tenemos el Dashboard TR-069, esta pantalla muestra informes completos del estado de los equipos que tienen TR-069 habilitado, así como el porcentaje total de dispositivos que tienen TR-069 habilitado o no. También es posible ver los modelos de CPE, los fabricantes y también la cantidad de cada uno en la base de Proveedores, que tiene habilitado el TR-069. La imagen que figura a continuación muestra cómo se presenta la información al usuario. En la segunda opción del módulo, tenemos el CPE, en esta pestaña se encuentran varias funcionalidades, utilizadas por el soporte, entre ellas están: Cambiar contraseña wifi, nombre y canal, tanto 2.4Ghz como 5.8GHz Comprobar el estado de los puertos LAN Comprobar la hora en que está encendido el CPE Comprobar el número de clientes conectados al CPE, con la opción de consultar el historial de clientes conectados, para ayudar al servicio de asistencia a resolver los problemas más complejos sin necesidad de desplazarse al domicilio del cliente. Compruebe la señal PON de las ONT/ONU Compruebe si hay reenvío de puertos en el CPE Imagen del CPE, que ayuda al equipo de soporte a comprender mejor el equipo que recibe soporte La siguiente imagen muestra las pestañas presentes dentro de la opción TR-069 CPE Esta pantalla también la podemos encontrar en la pestaña GraficoRealtime, cuando seleccionamos el PPPoE del cliente deseado, vamos a Grafico Realtime. A continuación, acceda a la opción «Gestión de equipos»; allí también se pueden realizar los ajustes del CPE a través de TR-069, lo que permite una mayor rapidez a la hora de configurar el CPE del cliente Made4Graph cuenta con más de 20 plantillas de distintos proveedores/fabricantes para TR-069, con sus respectivos parámetros y configuraciones específicas; además, en nuestra base de homologación hay más de 40 modelos de CPE de diversos fabricantes y modelos de equipos, lo que le permite una gran flexibilidad a la hora de integrar su base de CPE en el TR-069. Las imágenes a continuación ilustran las plantillas disponibles, así como el equipamiento que fue homologado dentro del TR-069. Es posible restaurar los datos de CPE después del reinicio según la plantilla que se configuró. Todavía hay muchas otras funcionalidades, al final de este artículo dejaré un enlace donde puedes acceder a la versión de demostración de made4graph y TR-069, de forma gratuita. Puedes ver un recorrido por el tr069 de made4graph en este video aquí Si tiene alguna duda sobre el funcionamiento de nuestra herramienta o desea una presentación completa de la misma, póngase en contacto con nosotros; nuestro equipo de expertos está a su disposición.

¿Cómo solicitar un CDN de Google?

¡¡Hola gente!! Soy Luís Dias, consultor en Made4it, y hoy vamos a hablar un poco sobre las CDN, más concretamente sobre Google Global Cache (GGC), un tema muy interesante que lleva mucho tiempo formando parte de nuestras vidas y que facilita enormemente nuestro trabajo en materia de escalabilidad de la red. Es un tema muy interesante y requiere un poco de atención, así que toma un café fuerte y ven conmigo. Primero, ¿qué es CDN? Una CDN, abreviatura de red de entrega de contenido, es un grupo de servidores distribuidos geográficamente que acelera la entrega de contenido web, acercándolo a donde se encuentran los usuarios finales. Este dispositivo utiliza el almacenamiento en caché, un proceso que almacena temporalmente copias de archivos para que pueda acceder al contenido de Internet desde un dispositivo más rápidamente a través de un servidor cercano. Los CDN almacenan en caché todo tipo de contenido, como páginas web, imágenes y videos. Esto le permite ver una película, descargar software, publicar en las redes sociales o comprar sin tener que esperar a que se cargue el contenido. GGC – Google Global Cache El GGC, o Google Global Cache, son los servidores de Google repartidos entre los proveedores de servicios de Internet (ISP) de Brasil y de todo el mundo. Los GGC son servidores instalados dentro de las redes de los proveedores de servicios de Internet y de las operadoras para mejorar la experiencia de los usuarios con el contenido de Google, proporcionándoles mayor velocidad, menor latencia y una mejor experiencia con los servicios de Google. El CDN de Google, además de mejorar la experiencia de los usuarios con su plataforma, también se utiliza para reducir la congestión y el tráfico de Tránsito, PTT y Peering hacia Google. De este modo, se reducen los costes para el proveedor de servicios de Internet (ISP) o el operador. No es más que un intercambio muy beneficioso, tanto para Google —cuyos usuarios quedan satisfechos con el rendimiento— como para el proveedor de servicios de Internet, ya que le permite ahorrar en el número de enlaces o en el tráfico. Cómo funciona GGC: Cuando un usuario solicita contenido, por ejemplo, un video, una página web o una imagen, el sistema de Google determina si el contenido se puede servir desde el nodo GGC. Si el nodo GGC tiene el contenido solicitado en su servidor de caché, entregará el contenido directamente al usuario final, mejorando la velocidad/latencia de navegación para el usuario y optimizando los recursos de ancho de banda del ISP. Si el contenido no se almacena en el servidor de caché, el nodo GGC recuperará ese contenido de los servidores de Google y lo almacenará para futuras solicitudes. Cómo se realiza la solicitud de GGC: Para poder realizar la solicitud de GGC, primero debemos saber cuánto tráfico tenemos para el contenido de Google. Porque como toda CDN, tenemos un requisito mínimo de ancho de banda para contenidos relacionados con Google, como Youtube, etc. Hoy, el ancho de banda mínimo es un tráfico superior a 3 Gbps, percentil 95 durante al menos 3 meses. Percentil 95*: es un cálculo matemático que se utiliza para evaluar el uso regular y sostenido de los enlaces de comunicación de la red. Pero te debes estar preguntando «Luís, ¿cómo voy a saber cuánto tráfico tengo para Google, para solicitar el GGC?» Para este procedimiento podemos utilizar una herramienta de Netflow; en este caso, voy a utilizar Made4Flow, la mejor y más práctica herramienta de Netflow del mercado. Entendamos cómo funciona esta magia: Al entrar nos encontramos frente al Dashboard de la herramienta, donde podemos especificar el tipo de tráfico que queremos que genere el informe de consumo, o podemos elegir el Dashboard que queremos, en este caso para ver el tráfico a Google, Netflix, Facebook , Akamai. Cuando entremos en la pestaña Google Dashboard, podremos ver cuánto tráfico total tenemos para Google y comprobar si podremos solicitar el CDN, ya que piden un percentil mínimo de tráfico. Después de analizarlo, pudimos continuar con la solicitud de GGC Para solicitar el GGC (Google Global Cache) es necesario ingresar al sitio web: https://isp.google.com/partner_request/?data.request_type=Peering Y rellenamos el formulario donde vamos a poner nuestros datos como ASN, nombre, dirección, etc. Después de que se apruebe la solicitud, recibiremos un correo electrónico informándonos si fuimos aprobados o no. Si se aprueba, Google nos indicará el paso a paso que debemos seguir y nos dará una estimación del tiempo que tardará el servidor en llegar a la dirección que le proporcionamos en el formulario. ¡Espero que hayas disfrutado y entendido el contenido! Si tiene alguna duda, póngase en contacto con nuestro equipo de expertos.

Control selectivo de ancho de banda en el enrutador Huawei

Buenos días, me llamo Gabriel Henrique, soy analista de redes aquí en Made4it y hoy les voy a mostrar cómo configurar el control selectivo de ancho de banda para los usuarios de la capa de acceso en los routers de la gama NE de Huawei. El control selectivo de ancho de banda abre la posibilidad de nuevos productos o la mejora, incremento o “encanto” en la entrega del servicio al usuario final, siendo un diferencial muy interesante, principalmente para los ISP que cuentan con un CDN local. Pero, después de todo, ¿qué es el control selectivo del ancho de banda? Normalmente, en las implementaciones de BNG, BRAS o servidores PPPoE, es habitual contar con un control de ancho de banda global (desde el punto de vista del usuario), en el que todo el contenido está limitado por el valor del plan contratado. En el control de ancho de banda selectivo, existe la posibilidad de asignar diferentes anchos de banda a distintos servicios, de modo que, por ejemplo, puede asignar un control de ancho de banda con un valor «X» a su contenido local de CDN, «y» al tráfico interno de su red y «z» cuando el origen o destino del tráfico es externo (enlaces, tráficos de tránsito, peering, IX/PTT, PNI, transportes…), podríamos decir que aplicamos una QoS selectiva o que controlamos específicamente la cantidad de ancho de banda por tipo de contenido; también se podría afirmar que podemos aplicar el control de ancho de banda de la CDN o el PBR selectivo. De todos modos, basta de hablar, vayamos a la parte divertida 🙂 En nuestro escenario de prueba, tenemos: – Cliente con un plan de 100 Mbps – Necesidad de habilitar hasta 500 Mbps cuando el origen o el destino sean CDN locales – Necesidad de mantener 100 Mbps cuando el origen o el destino no sean CDN locales– CDN locales con direcciones 192.0.2.0/24 y 2001:DB8::/64 Requisitos previos: – ERP/Radius con compatibilidad con el AVP «Huawei-Policy-Name»– Dominio de autenticación de los clientes con un «user-group» declarado (si no sabe qué es un «user-group», no se pierda el blog de Made, donde muy pronto se publicará una entrada sobre cortafuegos en la que se explicará exactamente de qué se trata 😉 Paso 1: Configure, en la vista del sistema, los parámetros Radius necesarios y active la función «Servicio de valor agregado» en el enrutador. Paso 2: en el grupo Radius utilizado para la autenticación, habilite el soporte de contabilidad de servicio de valor agregado Paso 3: Configure las ACL de acceso que delimitan el tráfico CDN y el tráfico general Paso 4: configurar «clasificadores» para clasificar el tráfico de las ACL Paso 5: Configurar los «comportamientos» que usaremos para identificar cada uno de los clasificadores Paso 6: Configure la política de tráfico que se vinculará globalmente, que contenga el clasificador y el comportamiento previamente configurados, efectuando la clasificación diferenciada de los flujos. Paso 7: Aplicar la política de tráfico globalmente. Paso 8: Configurar los qos-profiles que delimitarán el ancho de banda de los respectivos contenidos Paso 9: Configure la política que controlará el ancho de banda del cliente Listo. Ahora, el ERP/Radius solo necesita entregar el AVP Huawei-Policy-Name := 150m al cliente, y el cliente tendrá control de ancho de banda limitando hasta 500Mbps cuando el origen/destino son los CDN locales, y hasta 100Mbps para los otros orígenes/destinos. Tenga en cuenta que, si el ERP/Radius proporciona el valor «Huawei-Input-Average-Rate», el BRAS/BNG lo utilizará de forma preferente y no aplicará el nombre de la política. La política de tráfico permite hasta 8 «niveles de tarifas» donde puede clasificar su tráfico en hasta 8 tipos de servicio y aplicar diferentes controles de ancho de banda para cada uno de ellos. En el ejemplo que se muestra, si desea configurar el control de ancho de banda diferenciado para otros planes, solo tiene que crear nuevos «qos-profile» y «value-added-service policy» con los valores que desee aplicar, ya que el tráfico de CDN y el tráfico general ya están clasificados en «tariff-levels» distintos. ¡Eso es todo, hasta la próxima! Si tiene alguna duda sobre cómo implementar esta configuración en su red, póngase en contacto con nosotros y hable con uno de nuestros especialistas.

¿Cómo funciona el TR-069?

Ya hemos visto algunas de las funciones del TR069; para acceder al contenido en el que explicamos qué es el TR069, lea nuestro primer artículo; ahora veremos cómo funciona esta «magia». TR-069 está basado en SOAP/HTTP, donde se realiza la conexión entre el CPE y el ACS. La comunicación se realiza a través de llamadas de procedimiento remoto (RPC), esto permite que el CPE envíe los parámetros, además de su estado actual, así como la gestión del firmware al ACS. Es muy importante recordar que es la CPE la que inicia la conexión; de ella partirá el primer contacto, así como los informes periódicos al ACS, ya que, en cada intervalo de tiempo, la CPE envía un informe al ACS para que este actualice su estado en el servidor. El ACS solo iniciará el contacto en momentos concretos, como: la actualización del firmware o una interacción iniciada por el operador; no obstante, el CPE deberá aceptar dichas interacciones para que la acción se complete. La imagen de arriba muestra la comunicación entre el CPE y el ACS, donde el CPE envía una solicitud de conexión al ACS, observe que en esta imagen, el CPE ya es conocido por el ACS, de lo contrario, la comunicación tendría algunos campos más, como Solicitud GetParamenterNames, donde esta solicitud parte del ACS al CPE, con la intención de conocer los parámetros que se pueden entregar al ACS. Conexión abierta: la CPE informa que quiere hablar con la ACS Iniciación SSL: se añade un certificado a la comunicación para proteger el intercambio de mensajes solicitud de informe: el CPE le dice al ACS que informará su estado actual informar respuesta: el ACS dice que el CPE puede enviarle los parámetros Publicación HTTP (vacía): CPE dice OK Solicitud GetParameterValues: solicitud de parámetros CPE Respuesta GetParameterValues: respuesta CPE con parámetros para ACS Petición SetParameterValues: el ACS informa que ya conoce los parámetros, y que necesita los valores de los parámetros del CPE Respuesta SetParameterValues: el CPE informa al ACS de los valores de los parámetros solicitados por el ACS. Respuesta HTTP vacía: el ACS indica que ya no hay más información que intercambiar entre ellos y que la comunicación puede darse por concluida. Close connection: A CPE finaliza a conexão. Es posible tener esta funcionalidad en tu red de una manera sencilla, que es a través del módulo TR069 en Made4graph, donde toda la información necesaria se encuentra dentro de la propia interfaz del software. Para que lo sepas Made4graphy las ventajas de la herramienta puede acceder al demoo programa una demostración con el equipo comercial 😁.

Añadir Alerta por Telegram en Anti-DDoS

Una de las funciones Anti-DDoS de Made4flow es la capacidad de enviar alertas de ataques a su teléfono celular a través de Telegram. ¡Hemos preparado un tutorial sobre cómo puedes configurar esta acción!

Actualizaciones de Made4flow y Made4graph

¡Más actualizaciones de nuestro software Made4flow y Made4Graph!
Nuestro equipo de desarrollo ahora ha traído nuevas funciones que ayudarán a su soporte, las actualizaciones de esta versión y las versiones anteriores están todas en nuestra wiki que puede ver aquí. Vamos a ver cuales eran

¿Por qué simplemente tener Zabbix no funciona?

Para entender esta pregunta, recordemos cómo funciona Zabbix. Zabbix es un software de monitoreo de código abierto, con él podemos monitorear nuestros activos de diferentes maneras, con el protocolo SNMP, a través de Zabbix Agent, HTTP/S, con scripts externos, etc. Cuando instalamos y configuramos Zabbix, vemos varias plantillas listas para poder monitorear equipos de diferentes marcas y modelos, con ellas tenemos ítems, reglas de descubrimiento, disparadores, gráficos todo para aplicar al host, pero es lógico que Siempre se puede mejorar lo que ya existe y agregar aún más. Sin embargo, incluso agregar su host en Zabbix, seleccionar la plantilla correcta y comenzar a monitorearlo, no sirve de nada si no hay nadie que siga este monitoreo. Necesitamos a alguien que esté siempre pendiente de las incidencias, de las gráficas de los anfitriones, de los datos recogidos, para identificar posibles problemas. ¡Solo imagina! Durante tu horario laboral, siempre monitoreas las gráficas de tus enlaces contratados con upstreams, pero después de tu horario laboral, en horas pico, uno de tus enlaces empieza a alcanzar el máximo contratado y afecta la entrega de internet a tus clientes finales, o un puerto de uno de sus equipos llega a su máxima capacidad con el crecimiento que se ha producido en los últimos meses. Esto podría evitarse si hubiera alguien listo para actuar cuando se encontrara un comportamiento inesperado en el monitoreo. Incluso tenemos la posibilidad de crear varios tableros también y agregar gráficos, historial de incidentes y todo lo demás para facilitar este seguimiento, pero sin alguien que esté pendiente del seguimiento cuando sucede algo así, se vuelve inútil. Uno de nuestros servicios, Made4NOC, está pensado precisamente para eso. Contamos con nuestro equipo de supervisión a su disposición, que trabaja las 24 horas del día, los 7 días de la semana, y está siempre atento a cada elemento en la supervisión de los activos presentes en nuestro Zabbix. Además, cada vez que se produce una incidencia o nuestro equipo se encuentra con un comportamiento inesperado, está preparado para actuar, ya sea llamando a nuestra asesoría, contactando con el cliente, contactando con un enlace o proveedor de equipos o lo que sea necesario para que podamos resolverlo todo a la mayor brevedad. tan pronto como sea posible. ¿Desea comprender mejor cómo el NOC de Made4it puede ayudar a su red? ¡Póngase en contacto con uno de nuestros expertos y descubra qué y cómo supervisar! Luis Felipe | Consultor

¿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. Tras un tiempo trabajando, el responsable del departamento vino a hablar conmigo y me dijo que estaba pensando en añadir un turno más en el servicio de asistencia, ya que hasta entonces el horario límite era a las 22:00 h, pero estaba pensando en ampliarlo hasta las 00:00 h, Acepté; fue una época en la que aprendí mucho, ya que el turno de las 22:00 h sufrió algunos cambios y, en algunas ocasiones, asumí yo solo la responsabilidad del servicio de asistencia. Fue una experiencia positiva, pues aprendí mucho, aunque también supuso 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 bien, ¿y si le dijera que existe una forma más sencilla de obtener esa información, y que ese proceso de asistencia técnica que a veces se prolongaba durante horas puede resolverse en cuestión de minutos? eso depende también de los conocimientos de la persona que atiende la asistencia técnica 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 (Informe técnico 069) es el nombre del informe elaborado por el Broadband Forum que establece las normas para la gestión de dispositivos CPE (Customer Premises Equipment), es decir, equipos instalados en el domicilio del cliente, como, por ejemplo, routers domésticos, ONU y ONT. 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 mecanismo de aprovisionamiento incluye parámetros para el aprovisionamiento general y un mecanismo para añadir recursos específicos del proveedor según sea necesario. Esto permite el aprovisionamiento masivo y, además, en caso de que se produzca un reinicio del CPE, el ACS reconocerá el parámetro como reinicio y utilizará inmediatamente 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. La norma TR069 define un conjunto común de parámetros y un mecanismo general para incorporar funciones de diagnóstico específicas de cada proveedor, y puede utilizar esta función para centrarse en un único dispositivo y recopilar información de diagnóstico para su posterior análisis. La imagen que se muestra a continuación ilustra 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

Problemas con el tráfico CDN local (Google GGC) y anuncios BGP

Buenos días. Me llamo Gabriel, soy analista de redes aquí en Made4it y hoy les voy a contar una situación interesante relacionada con la CDN GGC de Google y la ingeniería de tráfico que abordamos aquí en el equipo de consultoría hace algún 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 mi poder, lo primero que hice fue acceder a la Made4Flow para ayudarme a comprender lo que había sucedido, utilizando, por supuesto, mi gráfico favorito, el«Interfaz por ASN». Me aseguré de seleccionar un intervalo de tiempo que abarcara exactamente el evento ocurrido entre el día 3 y el día 4, precisamente para comprender qué ASN dejaron de ser «atendidos» por la caché local. Con eso en la mano, noté 2 cosas de inmediato:– El ASN «Naranja» ha dejado de recibir servicio de esta CDN, lo cual se confirma por la evidente disminución del tráfico que se observa en el gráfico…– El o los ASN «Azul» (un conjunto de ASN específicos configurados de forma personalizada en nuestro software) también han mostrado una disminución significativa en el gráfico. El ASN «Azul» es el que aloja la caché. El hecho de que el ASN «Naranja» fuera también cliente de Made4it nos permitió realizar una prueba más eficiente dentro de su red. Al ser socios, el ASN «Azul» y el ASN «Naranja» nos dieron total libertad para llevar a cabo la resolución de problemas y validar lo que fuera necesario en ambos lados. Tras realizar algunas comprobaciones, utilizamos la herramienta del propio proveedor de contenidos para verificar qué«nodo/caché»estaba «suministrando» ese tráfico que había dejado de llegar a través de la CDN local del ASN «Azul». Este tráfico dejó de llegar desde la CDN del ASN «Azul», pero tiene que venir de algún sitio, ¿no le parece? En la imagen anterior, me llamaron la atención dos cosas, a saber:– Un nodo en Guarulhos, perteneciente a la red de este proveedor de contenidos, es el que ha pasado a gestionar el tráfico que antes debía proceder de la 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: – Anuncios directos (ASN que aloja la caché): el nodo acepta hasta /27 para ejercer una influencia directa en la ingeniería de tráfico y cumplir los requisitos para la entrega de contenidos. – Anuncios indirectos (ASN adyacentes al ASN que aloja la caché): el nodo solo acepta hasta /24 para ejercer influencia directa en la ingeniería de tráfico y determinar la elegibilidad para la entrega de contenido.Bien, en cuanto al tráfico del ASN «Azul», ya tenía la posible causa del problema. Al intentar inducir a este nodo local a entregar más tráfico, acabaron anunciando bloques /25 al nodo de la caché, lo que implicó que la red del proveedor de contenidos «sirviera» 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 tres ASN, algo que se creó de forma personalizada en el software Made4Flow. Curiosamente, dos de esos ASN estaban «inyectando» prefijos /25 en el nodo de la CDN, donde el comportamiento observado fue exactamente el mismo que el descrito anteriormente en relación con el ASN «Naranja». Con toda esta información a nuestra disposición, nos pusimos manos a la obra para ajustar los anuncios de acuerdo con los requisitos que el proveedor de contenidos exige (y ha documentado) para su CDN. Tras realizar los ajustes necesarios, este es el resultado: Conclusión:Sabemos que para que un nodo de CDN funcione intervienen diversos factores y que ello implica protocolos que funcionan de manera coordinada, como BGP, DNS, TCP, entre otros… Sin embargo, en este caso, nuestro problema fue una anomalía en el comportamiento al realizarse un anuncio al nodo de la CDN fuera del rango aceptable.Al anunciar los bloques /25 de ASN adyacentes al ASN que aloja el nodo/caché, el «player» comenzó a entregar el tráfico a dicho ASN/prefijo a través de sus nodos de CDN situados en Guarulhos, lo que supuso un aumento del tráfico indirecto en nuestro cliente ASN «Azul» y una pérdida de rendimiento y eficiencia del nodo local. Los usuarios de esta red se vieron directamente afectados, ya que su contenido pasó a ser distribuido a través de una infraestructura situada 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. En lo que respecta a la ingeniería de tráfico con CDN, respete siempre la documentación del reproductor en cuestión y utilice sus herramientas para detectar qué «nodo» está «suministrando» el tráfico. Normalmente, los reproductores de CDN también disponen de un portal para supervisar el rendimiento de la caché con métricas y datos de gran importancia al respecto; utilice estas herramientas en su beneficio. ¿Le ha parecido interesante y desea conocer un poco más cómo funciona el software que utilizamos en este proceso, o tal vez desea hablar con un especialista para resolver problemas como este en su red? Póngase en contacto con nuestro equipo en. Gabriel Henrique, analista de redes en Made4it, lleva más de 10 años trabajando en el ámbito de la tecnología y los proveedores de servicios

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 Puede hacerlo mediante el análisis de Netflow, como en Made4Flow, a través de los gráficos, e identificar, mediante el informe de datos brutos, qué dirección IP presenta un mayor tráfico y podría ser la 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. Disponemos de más contenido sobre cómo configurar Blackhole, que puede consultar en nuestro blog; si tiene alguna duda, póngase en contacto con nuestro equipo de expertosen Leonardo Nascimento | Consultor de Made4it