Túnel GRE + IPSec entre Cisco IOS y Huawei NE40
En este post vamos a discutir un escenario muy común (y poco documentado), que consiste en utilizar un túnel GRE protegido con IPSec entre un router Cisco IOS ASR1002 y un router Huawei NE40. La topología de este ejemplo se describe a continuación. Se ha mantenido simple para que podamos discutir los detalles de GRE+IPSEC, sin entrar en los otros puntos de la red. En ella contamos con el router Cisco, con la dirección IP pública 198.51.100.2, y el router Huawei NE40, con la dirección IP pública 203.0.113.66. Ambos están conectados a Internet y disponen de conectividad entre sí. Debemos establecer un túnel GRE entre los routers y protegerlo mediante IPSec en modo túnel. El espacio de direcciones del túnel es 172.31.31.0/30. A continuación hablaremos de GRE e IPSec. El objetivo no es detallar por completo estos protocolos, sino ofrecer una visión general y, principalmente, una base para el resto del artículo. No te precipites, hay información muy relevante entre medias. GRE Generic Routing Encapsulation (GRE) es un protocolo de tunelización que puede encapsular diversos protocolos de red (por ejemplo, ATM, IPX, IPv6 e incluso IPv4) dentro de paquetes IPv4. Estos paquetes pueden transmitirse a través de redes IPv4 comunes (por ejemplo, Internet). Algunos casos de uso del GRE:interconectar redes internas desconectadas entre síinterconectar redes IPv6 aisladas a través de redes IPv4establecer la comunicación entre la sede central y las sucursales a través de Internetenlaces de mitigación con VPN cuando sea necesario protocolos de enrutamiento IPSEC IPSec es un marco de seguridad desarrollado por el IETF que trata de resolver problemas de seguridad que el protocolo IPv4 no pudo solucionar, como el cifrado, la integridad de los datos, la validación de fuentes y la antirrepetición. En realidad, IPSec no es un único protocolo, sino una combinación de protocolos y algoritmos. Los principales son IKEv1, IKEv2, ESP y AH. IPSec se utiliza ampliamente en las VPN, tanto de acceso remoto como de sitio a sitio. En el ciclo de vida de un túnel, tenemos 5 etapas bien definidas: Definición de «tráfico de interés»El tráfico de interés es el desencadenante que hace que se establezca el túnel. El router o el cortafuegos, al detectar tráfico de interés, inicia las siguientes etapas de la negociación de IPSec. El tráfico de interés suele configurarse en forma de ACL, o políticas de tráfico. IKE fase 1En la fase 1, el protocolo establece un canal de comunicación seguro con el par remoto. Una vez establecido este canal seguro, se permite el intercambio de mensajes de la fase 2. Es en la fase 1 cuando se protegen los peers, se autentican y se comparan las políticas ISAKMP (y tienen que coincidir). Hay dos modos, principal y agresivo. Términos que verás sobre la fase 1: ike, isakmp, grupo DH, clave precompartida, integridad, política isakmp Fase 2 de IKEEn esta fase, una vez establecido el túnel seguro en la fase 1, podemos negociar lo que denominamos «SA de IPSec», que no son más que los «acuerdos» sobre el tipo de tráfico que será protegido por el túnel IPSec, negociados de forma dinámica. Un ejemplo podría ser: «Voy a proteger el tráfico de la red 192.168.1.0/24 cuando el destino sea 192.168.2.0/24 utilizando el algoritmo de cifrado X y el de autenticación Y», y el par remoto establece la regla en sentido inverso. Otra función de la fase 2 es mantener las SAs, así como expirar claves y sesiones si se alcanza algún parámetro (ej: expirar SAs y negociar nuevas cada x horas, o cada N kilobytes). Términos que veremos sobre la fase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy Transferencia de datosEn esta fase tiene lugar la transferencia de datos propiamente dicha. Tan pronto como el tráfico relevante llega al router y se completan las fases 1 y 2, los paquetes se envían de acuerdo con los acuerdos establecidos en las SA de IPSec, transmitiéndose hasta el par remoto. Cierre del túnelEl cierre del túnel se produce de forma manual, o bien cuando algún parámetro de IPSec caduca o alcanza su límite. En este caso, se descartan todas las claves, se rescinden los contratos y, si es necesario redirigir el tráfico, debe establecerse un nuevo túnel IPSec. Para más detalles sobre GRE e IPSEC, consulte las referencias citadas al final del artículo. Las configuraciones GRE e IPSEC acordadas entre las Partes El siguiente ejemplo muestra cómo se acuerda la información de la VPN. Suelen ser formularios que se rellenan con información sobre el túnel. Dispositivo VPN Sitio A Dispositivo VPN Sitio B Dispositivo VPN Dirección IP del par VPN * 198.51.100.2 203.0.113.66 Dispositivo * Cisco ASR 1004 Huawei NE40-M2K Versión * V3.0.6 Propiedades del túnel Sitio A Dispositivo VPN Sitio B Dispositivo VPN Fase 1 Método de autenticación APasswordWellS3gur@ APasswordWellS3gur@ Versión de IKE IKEv2 IKEv2 Grupo Diffie-Hellman grupo 14 grupo 14 Algoritmo de cifrado * AES 256 AES 256 Algoritmo Hashing * SHA-1 SHA-1 Modo principal o agresivo * Modo principal Modo principal SA Lifetime * (para renegociación) sin kbytes rekeying 86400 segundos 86400 segundos Fase 2 Encapsulación * (ESP o AH) ESP ESP Algoritmo de cifrado * AES 256 AES 256 Algoritmo de autenticación * SHA-1 SHA-1 Perfect Forward Secrecy para reintroducir * Discapacitados Discapacitados Grupo Diffie-Hellman * grupo 14 grupo 14 SA Lifetime * (para renegociación) ) sin kbytes rekeying 3600 segundos 3600 segundos GRE Dirección 172.31.31.1/30 172.31.31.2/30 Keepalives Discapacitados Discapacitados MTU 1400 1400 Ajustar SMS 1360 1360 Información importante sobre la licencia y los módulos Consulte con el fabricante de su equipo para ver si no se requiere algún tipo de tarjeta de servicio, o licencia. En el caso del equipo de este laboratorio, el router NE40-M2K no necesitaba ningún módulo físico adicional, sólo la licencia IPSec. En el router Cisco tampoco fue necesaria ninguna licencia, ya que su IOS ya estaba en ADVIPSERVICES-K9 (que contiene toda la base para Ipsec). *Información útil*: si desea ejecutar IKEv1, en el router Huawei necesita un módulo de software para IKEv1 (que
Iniciar Made4Flow v2
Estamos muy orgullosos de anunciar el lanzamiento de la versión 2 de Made4Flow y Anti-DDoS. Con varias mejoras, esta versión aporta nuevas funciones y optimizaciones. Con un aspecto mucho más atractivo y la opción de personalización de los cuadros de mando interactivos, Made4Flow v2 destaca por su interfaz mucho más pulida y refinada, y también mucho más rápida y dinámica en comparación con su predecesora.
Netflix CDN, ¿cómo hacer un pedido?
Ahora que ya conoce la importancia y las ventajas de una caché CDN local (si aún no las conoce, consulte: «¿Qué es, para qué sirve y por qué se utiliza la caché CDN?»), le explicaremos qué necesitamos y cómo hemos adquirido la caché CDN de Netflix, también conocida como OCA (Open Connect Appliance): Ancho de banda mínimo! Dado que Netflix va a tener que invertir en un hardware costoso para usted, ¡también tiene que ser rentable para ellos! Hoy en Brasil es necesario tener al menos 5GB/s de tráfico con Netflix. Fuente: https://openconnect.netflix.com/deploymentguide.pdf «Obtengo muchos otros contenidos agrupados en tránsito, ¿cómo puedo estar seguro de cuánto tráfico tengo con Netflix?» Para poder determinar con exactitud el volumen de tráfico que generamos con Netflix, necesitamos una herramienta que permita analizar minuciosamente el origen y el destino de los paquetes que circulan por esa red. Para ello, le recomendamos Made4Flow. Lo cual nos permite visualizar el tráfico de los contenidos más importantes. También hay varios otros medios que permiten la visualización de DÓNDE aprendimos el tráfico: Um campo com mais detalhes sobre o consumo Netflix especificamente: Visualizamos tráfico procedente de servidores Cache CDN (OCA) o tráfico con Netflix Cuánto tráfico de Netflix representa del total de nuestra red. De dónde procede el tráfico de Netflix y si lo utilizamos nosotros o algún cliente de ASN Made4flow tiene muchas otras aplicaciones para brindarle la mejor visibilidad de su tráfico. «Creo que ya tengo o estoy cerca del tráfico necesario con Netflix, ¿cuándo van a venir aquí a ofrecer el servicio?» Desafortunadamente no lo harán, ¡tienes que ir tras ellos! Y debe asegurarse de cumplir con los requisitos antes de presentar la solicitud, de lo contrario, es posible que lo suspendan durante unos meses hasta su próxima solicitud. Póngase en contacto con ellos a través de la Solicitud de Electrodomésticos, a través del enlace: https://openconnect.netflix.com/pt_br/deployment-guide/appliance-request/ Complete el formulario prestando especial atención a los campos en las imágenes a continuación: Luego de eso, en unos días Netflix dará su respuesta y más detalles sobre la entrega del Hardware, que suele ser: Servidor 1u (modelo más pequeño) o 2u (modelo más grande) Con 2 o 4 puertos de 10GB/s (Óptico) Puede ver la descripción completa del hardware en el enlace: https://openconnect.netflix.com/pt_br/appliances/ Una vez realizado el pedido, recuerde cumplir los requisitos de ancho de banda, interconexión, alimentación eléctrica y espacio en el rack, que puede consultar en el enlace https://openconnect.zendesk.com/hc/en-us/articles/360034538352 ¡En las próximas publicaciones tendremos más detalles sobre cómo realizar solicitudes desde otros cachés de CDN y mucho más! Síganos también en las redes sociales para obtener más información sobre Made4it y Made4Flow. Si tiene alguna pregunta sobre la solicitud o sobre el software made4flow, comuníquese con nuestro equipo.
¿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!
