¿Cómo pedir Microsoft CDN? (MCC)

¿Hola a todos cómo están? En este post te explicaremos un poco sobre cómo solicitar el CDN de Microsoft más conocido como MCC (Microsoft Connected Caching). Requisitos / Información: Ancho de banda mínimo: 2 Gbps (selectivo) / 5 Gbps de descargas por dispositivos Win10. (Restrictivo) Email: ispnode@microsoft.com Información : https://peering.azurewebsites.net/Peering/Caching PeeringDB: http://as8075.peeringdb.com/ Vayamos a una descripción general sobre el MCC Microsoft Connected Cache (MCC) es una solución de almacenamiento en caché solo de software que sirve contenido dentro de las redes de ISP. MCC se puede implementar en tantos servidores bare metal o máquinas virtuales como sea necesario y se administra desde un portal en la nube. Los servicios en la nube de Microsoft manejan el enrutamiento desde los dispositivos de los consumidores hasta el servidor de almacenamiento en caché para las descargas de contenido. Microsoft Connected Cache es una solución híbrida (que combina recursos locales y en la nube) compuesta por una máquina Linux compatible con Docker implementada en su servidor y un portal de gestión en la nube. Microsoft ha elegido Azure IoT Edge por ser una plataforma segura y, aunque su caso de uso no esté relacionado con el IoT, Azure IoT Edge nos proporcionará la seguridad necesaria en cuanto a la infraestructura de implementación y gestión. Para obtener más información sobre Azure IoT https://docs.microsoft.com/en-us/azure/iot-edge/about-iot-edge Azure IoT Edge consta de tres componentes que utilizará la infraestructura de Microsoft Connected Cache: 1. Una interfaz basada en la nube que permite la instalación, el monitoreo y la administración remotos y seguros de los nodos de Microsoft Connected Cache. 2. Un tiempo de ejecución que gestiona de forma segura los módulos implementados en cada dispositivo. 3. Módulos/contenedores que ejecutan la funcionalidad de Microsoft Connected Cache en su dispositivo. ¿Qué es el MCC? El servidor de almacenamiento en caché de Microsoft utiliza los servicios de Azure IoT Edge para entregar contenido a los clientes finales de ISP. Funciona como un servidor de almacenamiento en caché dentro de la red del ISP, sirviendo las IP especificadas en los anuncios de la sesión BGP entre el servidor y el enrutador. ¿Qué hay en el contenido? En un principio lo que vendría de su CDN como actualizaciones para Windows, Office, juegos de XBOX y archivos de sitios de Microsoft. Actualmente, dado que se trata de una implementación nueva, no todo lo de Microsoft está disponible a través de MCC. ¿Es lo mismo que el GGC de Google o el OCA de Netflix? Sí, se parece mucho, pero la gran diferencia es que Microsoft no le envía ningún hardware específico para su red; usted debe proporcionar el hardware, instalar el sistema operativo y realizar la instalación de todos los paquetes necesarios para que el MCC funcione. Los requisitos son: Se deben utilizar interfaces de red de al menos 10 Gbits para la distribución de contenidos a través del servidor. Microsoft recomienda encarecidamente que se instalen discos SSD en el servidor. ¿Cómo funciona MCC? Según el documento de Microsoft, que lo describe, funciona de la siguiente manera: 1. El portal de administración de Azure que se usa para crear y administrar nodos de Microsoft Connected Cache. 2. Microsoft Connected Cache implementado y aprovisionado en el servidor. 3. El Portal de administración de Azure que se usa para configurar Microsoft Delivery Optimization Services para enrutar el tráfico al servidor de Microsoft Connected Cache al proporcionar dos piezas de información: A: la dirección IPv4 pública del servidor que aloja Microsoft Connected Cache. b. Los bloques de CIDR que representan el espacio de direcciones IP del cliente, que deben enrutarse al nodo de Microsoft Connected Cache. 4. Los dispositivos de usuario final de Microsoft se conectan periódicamente a Microsoft Delivery Optimization Services y los servicios hacen coincidir la dirección IP del cliente con la dirección IP del nodo correspondiente de Microsoft Connected Cache. 5. Los dispositivos de usuario final de Microsoft realizan solicitudes de rango de contenido desde el nodo de caché conectado de Microsoft. 6. El nodo de Microsoft Connected Cache extrae contenido de la red CDN, inicializa su caché local almacenada en el disco y entrega el contenido al cliente. 7. Las solicitudes subsiguientes de contenido de los dispositivos de los usuarios finales ahora provendrán del caché. 8. Si el nodo de Microsoft Connected Cache no está disponible, el cliente extraerá el contenido de la CDN para garantizar un servicio ininterrumpido a sus suscriptores. ¿Cuál es el proceso para solicitar un MCC? Solicite el acceso al programa rellenando el formulario descrito en la página Link: https://peering.azurewebsites.net/peering/Caching A continuación se muestra el resumen de los pasos necesarios para implementar Microsoft Connected Cache en su servidor. 1. Proporcione a Microsoft la suscripción de Azure que usará para Microsoft Connected Cache 2. Cree un recurso de caché conectada de Microsoft en Azure 3. Cree un nodo de caché conectado de Microsoft a. Información de aprobación del espacio IP 4. Edite la información del nodo de caché 5. Configure un servidor que ejecute Ubuntu 20.04 o una VM de Ubuntu que se ejecute en Windows Server 2019 6. Instale Microsoft Connected Cache en un servidor o máquina virtual 7. Verificar el correcto funcionamiento de Microsoft Connected Cache Server 8. Ver el informe de resumen de caché conectado de Microsoft 9. Problemas habituales. Si tiene alguna duda sobre estas instrucciones, póngase en contacto con: msconnectedcache@microsoft.com El portal de administración de Microsoft Connected Cache Azure se usa para crear y administrar nodos de Microsoft Connected Cache. Se usa un Id. de suscripción de Azure para otorgar acceso a la vista y crear el recurso de Microsoft Connected Cache en los nodos de Azure y Cache. Instalación: La instalación está muy bien descrita en el manual, pero brevemente: Ejemplo de correo electrónico recibido con la aprobación de MCC El equipo recibió este correo electrónico cuando se aprobó el MCC. Contiene instrucciones para proceder con la instalación. Nota: ES IMPORTANTE REENVIAR EL CORREO ELECTRÓNICO DE SOLICITUD PRIMERO A MICROSOFT, DE LO CONTRARIO LA APLICACIÓN NO APARECERÁ PARA LA INSTALACIÓN. En el portal, elija Crear

¡Cómo automatizar el proceso de aprovisionamiento de clientes!

El aprovisionamiento de clientes es una tarea diaria para un proveedor de Internet, tanto al instalar nuevos clientes como durante el mantenimiento. En este proceso, además de que el proveedor siempre tiene que proporcionar un técnico que realiza, además de la instalación física, la configuración lógica de insertar la VLAN, usuario y contraseña PPPoE del cliente en su CPE, tenemos algunos problemas conocidos, como: – Demanda de tiempo para configuración manual – Apertura a los fracasos humanos: – Error de credenciales PPPoE – Error de VLAN – Errores de usuario y contraseña – No cumple con el estándar determinado por el proveedor de configuración – Pérdida de configuraciones en resets de CPEs por parte de los clientes. Yo diría que este es el rey de los tickets de soporte de un proveedor, donde muchas veces el cliente, buscando solucionar algún problema en casa, resetea el equipo y no puede volver a configurarlo. En este caso, si el soporte telefónico no puede ayudar al cliente en la configuración, el proveedor deberá proporcionar un técnico en vivo para el servicio. Y si ha leído hasta aquí, quizá se esté preguntando si realmente es posible resolver este problema de forma automática. ¡Y la respuesta es sí! Es más, contamos con una amplia gama de escenarios y posibilidades que nos permiten, además de automatizar el proceso de aprovisionamiento, hacer que sea autoconfigurable, para el famoso caso de los reinicios. E incluso disponemos de un abanico de escenarios y posibilidades que nos permiten, además de automatizar el proceso de aprovisionamiento, hacerlo auto-reconfigurable, para el famoso caso de los resets. – Ejemplo de escenario de implementación: En los casos en que los equipos de la red de acceso son del mismo fabricante, contamos con la ventaja de que «hablan el mismo idioma», lo que nos resulta de gran ayuda, ya que, en la gran mayoría de los casos, podemos aprovechar la ventaja de automatizar la aplicación y el mantenimiento de las configuraciones en los equipos. Básicamente en OLT, configuramos los parámetros que serán enviados por OMCI, que contienen información como usuario y contraseña de PPPOE, activación de WAN, activación de NAT. Veamos un ejemplo práctico de configuraciones para realizar este proceso: Los ajustes que se describirán en este ejemplo se aplican a: – OLT Huawei de las series MA56xx y MA58xx. – Modo Router Huawei de la ONT. NOTA: Tenga en cuenta que algunos comandos aparecen entre [corchetes], indicando el nombre de cada parámetro, y deben modificarse para adaptarlos al contexto de aplicación. La creación del perfil DBA, de línea y de servicio será normal, según cada escenario. Recomendamos un perfil para cada VLAN y también recomendamos una VLAN por PON en la OLT. Liberación de configuración en modo OMCI: Para poder entregar la configuración a la ONU, debemos liberar el método de configuración OMCI. Para habilitar NAT en la WAN: Para poder subir la ONT con la NAT activa creamos un perfil WAN. Añadir la ONT con usuario y contraseña PPPoE: El secreto de la aplicación está en esta parte, y el comando ont ipconfig será responsable de entregar el PPPoE al CPE. interfaz gpon [FRAME]/[SLOT]ONT añadir [PON] [ONT-ID] sn-auth [NÚMERO DE SERIE] omci ont-lineprofile-id [ID] ont-srvprofile-id [ID] descripción [DESCRIPCIÓN]ont ipconfig [PON] [ONT-ID] pppoe vlan [VLAN] priority 5 user-account username [USER-PPPOE] password [SENHA-PPPOE] Creación de WAN: Entrega de Vlan en puertos LAN: Para que los dispositivos ethernet que están frente al CPE entiendan la Vlan que estamos entregando en los puertos, asumimos el modo vlan nativo: Activación de puertos en modo ruta: Configuramos el modo de ruta para los puertos de modo que estén habilitados para el enrutamiento de IP y la entrega de DHCP a los dispositivos que se conectan detrás de él. NOTA: tanto al entregar la Vlan como al activar el modo ruta, tenemos un ejemplo hecho para ONT’s con 4 puertos, pero hay casos en que esto cambia según la cantidad de puertos disponibles en la ONT. Si ha seguido los pasos anteriores para configurar su ONT en modo enrutador, ya debería funcionar. – ¿Cómo automatizar esto con mi sistema ERP? El proceso anterior se puede realizar manualmente, pero para que sea más efectivo, podemos usar scripts de aprovisionamiento del sistema ERP para llevar a cabo el proceso de aprovisionamiento. A continuación tenemos una plantilla de script que se puede utilizar, tenga en cuenta que cada variable está separada con #, y esto debe verificarse con cada sistema, para que pasen la variable o ayuden en el desarrollo del script. interface gpon #subrack#/#slot# ont add #pon# sn-auth #onu_mac# omci ont-lineprofile-id #vlan# ont-srvprofile-id #vlan# desc #nombre# ont ipconfig #pon# #número_de_ONU# pppoe vlan #vlan# priority 5 user-account username #usuario# password #contraseña# ont internet-config #pon# #número_de_ONU# ip-index 0 ont wan-config #pon# #número_de_ONU# ip-index 0 profile-id [ID-PERFIL-WAN] ont port native-vlan #pon# #número_de_ONU# eth 1 vlan #vlan# priority ont port route #pon# #número_de_ONU# eth 1 enable ont port native-vlan #pon# #número_de_ONU# eth 2 vlan #vlan# priority ont port route #pon# #número_de_ONU# eth 2 enable ont port native-vlan #pon# #número_de_ONU# eth 3 vlan #vlan# priority ont port route #pon# #número_de_ONU# eth 3 enable – Extras: También hay otras cosas que podemos entregar como credenciales PPPoE como datos SIP o activación automática TR-069. Y hablando del TR-069, este modo de configuración funciona muy bien con él, ya que garantiza la comunicación IP, y el TR-069 a su vez garantiza la gestión completa del CPE, como wi-fi, contraseñas, datos de señal, etc. . PREGUNTAS FRECUENTES: El proceso descrito anteriormente fue probado y aprobado en Huawei OLT, algunos otros vendedores soportan este tipo de configuración pero para cada uno, el modo de configuración es diferente. No, el proceso anterior sólo está aprobado en escenarios Huawei con Huawei. Este artículo ha sido escrito por el consultor de Made4it Rafael Henrique. Si tiene alguna pregunta sobre este artículo o sobre cómo realizar esta configuración en su red, póngase en contacto con nuestro equipo

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: 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!

¿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