Los proveedores de Internet se enfrentan a una nueva oleada de ataques DDoS

La falta de cuidado con los equipos, los servicios y la configuración de los bloques de direcciones IP ha puesto a los proveedores de servicios de Internet (ISP) en riesgo inminente de sufrir ataques distribuidos de denegación de servicio Los proveedores de servicios de Internet (ISP, por sus siglas en inglés) corren un riesgo inminente de sufrir ataques distribuidos de denegación de servicio (DDoS) a gran escala, lo cual se debe, en gran medida, a la falta de precauciones en el mantenimiento de los equipos, los servicios y la configuración de los bloques de direcciones IP. El año pasado, varios proveedores de servicios de Internet brasileños atravesaron momentos difíciles al sufrir ataques DDoS en su infraestructura, lo que dio lugar a numerosas publicaciones en redes sociales, periódicos y programas de televisión. Recientemente, a finales de febrero, una nueva oleada de ataques volvió a afectar a varios proveedores de servicios de Internet, con numerosos informes que apuntaban a proveedores de Río de Janeiro, los cuales, además, se han pronunciado públicamente para informar a sus clientes de que están experimentando graves problemas en la prestación de sus servicios debido a dichos ataques. La víctima no es necesariamente el objetivo A pesar de las molestias que causan a las operaciones de suministro de Internet, los ataques DDoS dirigidos a los proveedores de servicios de Internet (ISP), al contrario de lo que se suele pensar, no tienen necesariamente como objetivo a los propios proveedores. En la mayoría de los casos, el objetivo de los grupos de piratas informáticos es utilizar la infraestructura de estas empresas para atacar a los verdaderos objetivos, que suelen ser las grandes corporaciones multinacionales. Los equipos con configuraciones inadecuadas o incorrectas y los descuidos humanos suelen ser factores que facilitan el aprovechamiento y el «reclutamiento» de dicha infraestructura para el mundo del crimen organizado. Durante los ataques DDoS a gran escala, las víctimas suelen verse afectadas por un elevado volumen de solicitudes, procedentes de miles —y, en ocasiones, de decenas de miles— de fuentes diferentes, generalmente repartidas por todo el mundo. Las medidas y estrategias de mitigación que dependen del trabajo humano para identificar las fuentes de los ataques resultan ineficaces ante el enorme poder de fuego de los hackers, ya que estos provienen de miles de orígenes maliciosos diferentes, que llegan de forma repentina a la infraestructura de la víctima. Por ello, lo ideal es contar con la ayuda de un sistema Anti-DDoS. Ataques DDoS repartidos por 181 países El día 12 del mes pasado, unas dos semanas antes de que se hiciera pública la nueva oleada de ataques DDoS, Hacknet, una red neuronal artificial dedicada a la identificación de actividades de piratería informática en todo el mundo, identificó y cartografió una gran red con más de 40 000 servidores, repartidos por 181 países, que se estaban utilizando para generar ataques DDoS. La noticia se publicó en la página web y en las redes sociales de la empresa NetSensor, responsable del mantenimiento de dicha red neuronal, junto con un enlace para descargar la lista de direcciones IP que se estaban utilizando en los ataques, con el fin de que los profesionales de la seguridad pudieran adoptar medidas preventivas de protección. NetSensor analizó la lista de dispositivos que estaban siendo objeto de ataques, la completó con más datos y envió comunicaciones privadas a las direcciones registradas como medio de contacto para cada uno de los bloques de direcciones IP. En Brasil participaron más de mil empresas, lo que se tradujo en más de 1.600 correos electrónicos de contacto, en los que NetSensor emitió la alerta, facilitó información sobre el dispositivo y se puso a disposición para ofrecer más aclaraciones. El resultado de las notificaciones fue una sorpresa negativa, con aspectos como: La respuesta más triste fue la del responsable del bloque de un proveedor, que se limitó a escribir: «Por favor, elimine mi correo electrónico de la lista». Son pocas las empresas que adoptan una postura seria También hubo algunas empresas que respondieron de forma positiva a la alerta. Algunas remitieron el caso al responsable del dispositivo desde el que se estaba utilizando la dirección IP; otras solicitaron más información al respecto y, además, algunas agradecieron la alerta y afirmaron que analizarían el caso y tomarían las medidas necesarias. Lamentablemente, el porcentaje de empresas que adoptan esta actitud más seria y profesional se situó en torno al 0,5 %. Ante este panorama, las empresas en general deben tener presente que la delincuencia cibernética se ha especializado mucho en los últimos años, hasta el punto de convertirse en una actividad altamente organizada, estructurada, inteligente y rentable. Por lo tanto, para estar a la altura a la hora de hacer frente y defenderse de estos ciberdelincuentes, es necesario desarrollar técnicas y conocimientos, así como emplear recursos de forma inteligente que estén a la altura de nuestros adversarios. Es decir, buscar nuevos enfoques y tecnologías capaces de ayudar en la defensa frente a las nuevas amenazas, a las que, en la actualidad, no se consigue hacer frente de manera eficaz. Además, ya no se pueden seguir tolerando las omisiones, las incompetencias y las negligencias que se observan en relación con las redes, los equipos y los servicios. Solo así tendremos posibilidades de éxito a la hora de hacer frente a las amenazas que nos acechan, procedentes del submundo de Internet. Fuente: https://www.cisoadvisor.com.br/provedores-de-internet-enfrentam-nova-onda-de-ataques-ddos/ Cómo proteger a su proveedor de Internet frente a los ataques DDoS Del mismo modo que existen herramientas para los atacantes, también disponemos de herramientas y medios para proteger al proveedor. Lo que necesitamos es mitigar el ataque, lo que consiste en proteger al objetivo de los ataques DDoS. Made4it cuenta con la herramienta ideal para usted: ¡Made4Flow!Con Made4Flow podrá detectar los ataques y tomar medidas para proteger a su proveedor. Descubra las ventajas de la protección anti-DDoS para los proveedores de Internet:

¿Qué hay de nuevo en Zabbix 6.4?

La nueva versión se enfoca en simplificar la configuración de Zabbix, lo que le permite propagar instantáneamente los cambios de configuración en entornos grandes y distribuidos, así como optimizar los flujos de trabajo de actualización de software. Las organizaciones que utilizan LDAP o SAML se beneficiarán de las nuevas capacidades de aprovisionamiento de usuarios Just-in-time (JIT), lo que permite a los administradores de TI propagar usuarios de Zabbix mediante mecanismos centralizados de autenticación de usuarios. Esta actualización también contiene varias plantillas e integraciones para los vendedores y proveedores de nube más populares, como Veeam, AWS, Azure, Cisco y muchos otros. Aprovisionamiento de usuarios justo a tiempo (JIT) Cree y actualice automáticamente sus usuarios de Zabbix con la nueva función de aprovisionamiento de usuarios justo a tiempo para LDAP y SAML: Eventos de causa y síntomas Para permitir una descripción general de los problemas y mejores opciones de filtrado, además de identificar la causa raíz de los problemas, los eventos de problemas ahora se pueden marcar como eventos de causa o síntoma: Propagación instantánea de cambios de configuración Sincronice instantáneamente sus cambios de configuración con Zabbix Agent y Proxy, ejecutándose en modo activo o pasivo. Los proxies activos y pasivos de Zabbix ahora pueden capturar cualquier cambio de configuración realizado en su instancia de Zabbix casi al instante: El agente activo de Zabbix ahora recibe una copia completa de la configuración solo cuando se realizan cambios de configuración entre intervalos de sincronización de configuración: Actualización de Zabbix sin tiempo de inactividad Para mejorar los flujos de actualización de componentes de Zabbix (especialmente para entornos grandes), los proxies ahora son compatibles con versiones anteriores dentro del mismo ciclo de lanzamiento de LTS: Mejoras en la velocidad y el rendimiento para el descubrimiento masivo de SNMP y la recopilación de datos Una nueva forma de recopilar una gran cantidad de métricas de SNMP de forma masiva con un impacto mínimo en el rendimiento del punto final monitoreado mediante solicitudes GetBulk: Nuevo diseño de menú El diseño del menú de Zabbix ha sido rediseñado. El propósito del nuevo diseño del menú es proporcionar un acceso lógico y consistente a las funciones clave de Zabbix: Transmisión en tiempo real de métricas y eventos HTTP Transmita métricas y eventos en tiempo real desde Zabbix a sistemas externos a través de HTTP: Versionado de plantillas El sistema de versiones de las plantillas se introdujo para mejorar y facilitar la gestión de las mismas: Marco de desarrollo para crear widgets de Zabbix Se han realizado varios cambios de diseño con el objetivo de simplificar el flujo de trabajo para crear widgets personalizados en Zabbix: Interfaces opcionales para cheques originados en el servidor. Ya no se necesita una interfaz de host para los tipos de elementos relacionados con colecciones iniciadas directamente desde Zabbix Server o Zabbix Proxy: Configuración simplificada de tipos de medios para múltiples proveedores de servicios de correo electrónico Zabbix 6.4 simplifica el flujo de trabajo de configurar un nuevo tipo de medios de correo electrónico al permitirle seleccionar entre varios proveedores de servicios de correo electrónico preconfigurados: Plantillas e integraciones adicionales Zabbix 6.4 viene con muchas plantillas nuevas para los proveedores y vendedores de la nube más populares: Zabbix 6.4 presenta una integración de webhook para la aplicación de mensajería Line, lo que permite que los eventos de Zabbix se reenvíen a la aplicación. Cambios y mejoras adicionales Made4it es una empresa tecnológica que se enorgullece de ser socio certificado de Zabbix, una de las plataformas de monitorización de redes más prestigiosas del mundo. Como socios certificados, nuestros profesionales cuentan con una amplia formación para ofrecer soluciones personalizadas y adaptadas a las necesidades específicas de cada cliente. Nuestras soluciones de supervisión de redes son integrales e incluyen desde la configuración básica hasta la implementación de soluciones avanzadas para redes de gran envergadura. Con Made4it, puede estar seguro de que su sistema está siendo supervisado las 24 horas del día, los 7 días de la semana, lo que garantiza la seguridad y el buen rendimiento de su red. Además, contamos con un equipo de asistencia altamente cualificado que está siempre dispuesto a ayudarle en caso de problemas o dudas. Con Made4it, podrá estar tranquilo sabiendo que está en buenas manos. No pierdas más tiempo y conoce nuestros servicios de monitoreo de red. ¡Contáctenos hoy y descubra cómo podemos ayudar a que su negocio funcione aún mejor!

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. 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 se obtiene del proveedor de Huawei). Configuraciones de Cisco IOS XE Así que vamos a configurar el router Cisco para establecer la VPN. No entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf. Configuraciones de la fase 1 según la tabla anterior: Todo lo anterior se refiere a la Fase 1. Así que, cuando esté diagnosticando problemas y estos pertenezcan a esta fase, ya sabrá dónde realizar los cambios 🙂. Ahora preparando la fase 2: ¡Demasiado simple en Cisco! Ahora combinaremos las dos fases en un solo perfil: Creación del túnel GRE y adición de la protección IPSec: Configuraciones Huawei A continuación, vamos a configurar el router Huawei para establecer la VPN. Como en el caso de Cisco, no entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf. La configuración en el router Huawei es un poco más compleja, ya que crea un túnel para el protocolo GRE, y un túnel para IPSec. Además, queremos utilizar la misma IP para ambos túneles, por lo que se necesita un VRF. 😮 Creación de una instancia de servicio para utilizar la VPN (sólo aplicable en NE40): Actualización del nuevo VRF (vpn-instance): Creación de las dos interfaces Loopback con la misma IP (magia VRF). El looback con el túnel IPSec estará en la tabla de enrutamiento público, mientras que el del túnel GRE estará en la tabla VPNA. Ahora llegamos a IPSec. La ACL de tráfico interesante define el tráfico que será protegido por IPSec. En el caso entonces, tendremos el tráfico GRE entre las IPs del sitio A y el sitio B. Tenga en cuenta que sólo hago la comunicación en una dirección – la dirección del router proteger su tráfico). El ACL anterior puede leerse así: «Proteger los datos del protocolo GRE procedentes del VRF vpna entre el origen 203.0.113.66 y el destino 198.51.100.2» Ahora vamos a crear la fase 1 (recuerde que en Cisco ya se empieza por ella, lo cual es mucho más sencillo). En medio de esta fase hay algunas configuraciones de enlace de la instancia VPN, debido a la VRF creada. Todo lo anterior se refiere a la Fase 1. Así que, cuando esté diagnosticando problemas y estos pertenezcan a esta fase, ya sabrá dónde realizar los cambios 🙂. Pasamos a la fase 2: Ahora combinaremos las dos fases en un solo perfil: Creación de túneles GRE e IPSEC. Vamos allá para no confundir: Túnel 900 – es un túnel GRE, que opera dentro de la vpna. Túnel 10 – es un túnel IPSec, que funciona en la tabla global La idea en Huawei es que haya un túnel IPSec funcionando en el exterior y un segundo túnel GRE en el interior, uno encapsulado dentro del otro. Pero lo curioso es que el túnel GRE funciona fuera de la VRF, y el IPSec, dentro. Un poco lioso, ¿verdad? Así que tunnel900 que es el GRE (y que recibe las IPs de /30) usa un destino que va dentro de la VPNA. Y dentro de la VPNA se llega al destino por túnel IPSec. Observe también que la política IPsec se asoció con el túnel 10, utilizando el perfil que se creó. Por último, y no por ello menos importante, una ruta que presenta cierta complejidad en sí misma: dentro de la instancia VPNA, indico que, para llegar al par remoto, utilizo la interfaz IPSec recién creada, siendo el siguiente salto el propio par. Y así configuramos el router Huawei. A ver si ahora ha subido. Validación del funcionamiento En el proceso de validación del túnel, debemos recordar siempre que cada fase y etapa depende del establecimiento completo de la otra, por lo que no tiene sentido querer tener conectividad si la fase 1 aún no ha establecido la comunicación. En ambos routers, validaremos en secuencia: Pasemos a las pruebas. Comprobación Cisco Validación de la conectividad mediante ping ICMP Comprobación de que IKEv2 se ha establecido en Fase 1: Cuando no aparece nada en la salida, o no está lista, significa que alguno de los parámetros de la Fase 1 no coincidía. Comprueba en ambos lados si están de acuerdo. Continuamos la validación en la fase 2: En la salida anterior, vemos que los routers han conmutado el contrato de «tráfico interesante». Cada parte se ha comprometido a proteger una dirección de la comunicación GRE. En secuencia todavía en Fase 2, hay algunos contadores muy importantes que se refieren a paquetes enviados/recibidos/encapsulados/encriptados/verificados. Se encuentra en la salida del comando «show crypto ipsec sa». Veámoslos. Cuando estos contadores no se incrementan, o siguen incrementando fallos, es porque alguna

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.

Qué es TR-069 y cómo puede ayudar a los proveedores

TR-069 es un protocolo de gestión de dispositivos de red. Permite a los ISP administrar y configurar de forma remota dispositivos de red como enrutadores y módems.

Con TR-069, los proveedores pueden automatizar las tareas de configuración, supervisión y mantenimiento de los dispositivos de red, lo que contribuye a garantizar que los servicios de Internet funcionen de forma coherente y eficiente. Además, TR-069 también permite a los proveedores recopilar datos de rendimiento del dispositivo, lo que les ayuda a identificar y resolver problemas de manera rápida y eficiente.

En resumen, TR-069 es una herramienta valiosa para los proveedores de servicios de Internet, ya que le permite automatizar y administrar dispositivos de red de forma remota, recopilar datos de rendimiento para identificar y resolver problemas rápidamente, automatizar actualizaciones de software y firmware y ofrecer administración de red para sus clientes. lo que puede ayudar a reducir costos, aumentar la eficiencia operativa y aumentar la satisfacción y lealtad del cliente.

Made4Graph – Versión 2.2.7 (06/09/2022)

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: Instalar servidor ubuntu Cree y registre una cuenta azul (y también una suscripción) Crear un host en el portal azure, informando los datos del servidor (IP, nombre, redes, etc.) Descargar el instalador del portal Ejecuta los comandos de instalación que te ofrecerá el portal Responder a preguntas/inicios de sesión/accesos durante la instalación Informe al equipo

¡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: OLT’s y ONT’s del mismo proveedor. Los ONT son modo de enrutador Autenticación PPPoE 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. . ¿Quiere saber más sobre TR-069? Lea nuestro artículo PREGUNTAS FRECUENTES: ¿Se aplica esto a otros proveedores de OLT? 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. ¿Esto es válido para todos los fabricantes de ONT? 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

Nueva versión Made4Flow

Otra versión del software made4flow, tuvimos algunos cambios en esta actualización, siempre estamos trayendo novedades de acuerdo a las principales necesidades de nuestros clientes. ¿Comprobamos la actualización de esta versión? Versión 1.3.4 (26/07/2022) Agregado Se agregó una nueva pantalla para ver los ataques amortiguados por Anti-DDoS Se ha añadido esta nueva pantalla que muestra los ataques registrados, pero que no se han convertido en anomalías, además de mostrar el número de ataques por periodo, el detalle del tráfico y, por último, los paquetes capturados en un determinado ataque. Se agregaron registros de acción en Anti-DDoS Un cliente informó que la ruta expiró por sí sola y no fue posible verificar qué sucedió realmente ya que no teníamos registros del sistema. Con la adición de logs es posible tener una idea de las acciones realizadas en el sistema para verificar si fue un bug o la acción de alguien. Equilibrado Se corrigió la pérdida de datos sin procesar de los enrutadores. Ordenación de datos ajustada en datos sin procesar Se ajustó el filtro en los datos sin procesar para la otra opción. Capacidad de respuesta fija de los botones de acción en Anti-DDoS Agregación de datos fijos para gráficos generados con períodos mayores a 2 meses Se corrigió la caducidad incorrecta de la ruta BGP si hay otra con el mismo objetivo actualmente activo en Anti-DDoS Permisos de visualización de usuario de solo lectura ajustados en Anti-DDoS Eliminación fija de pares BGP en Anti-DDoS Se corrigió la pérdida de rutas BGP en el reinicio de Anti-DDoS Se ajustó el límite de prefijo por umbral en Anti-DDoS Se corrigió la tabla de ASN principales de destino de AS Globo Esas fueron las últimas actualizaciones de sprint, puede consultar todas las versiones anteriores y actualizaciones en Made4it Wiki. Para hablar con nuestro equipo comercial, póngase en contacto con 43 9 8485-4013 o contato@made4it.com.br