Cómo configurar vlans en dispositivos Ufispace
Este artículo te mostrará cómo configurar vlans en dispositivos Ufispace en modo troncal, híbrido y de acceso. En primer lugar, aquí tienes una guía paso a paso sobre cómo crear una VLAN: Accede al modo privilegiado: Accede al modo de configuración: Crea un Puente y configura el protocolo RSTP (requisito de OcNos). Crear VLAN y asociarla al bridge creado: Salir del modo «vlan database» Comprobar las configuraciones pendientes: Resultado esperado del comando anterior: Si necesitas deshacer los ajustes, puedes utilizar el comando Si los ajustes son correctos, se pueden aplicar con el comando Para comprobar la configuración de la VLAN: Una vez creada la Vlan, hay que asignarla a una interfaz, en modo TAG o UNTAGGGED (en acceso). Cómo configurar la VLAN en modo Trunk: Interfaz de acceso: Configura en modo Layer2 y asigna una Bridge (creado previamente): Configura el modo de interfaz en Troncal: Configura la vlan en TAG en la interfaz: Comprueba la configuración y aplícala: Cómo configurar la VLAN en modo Acceso Crear VLAN y asociarla al bridge creado: Interfaz de acceso: Configura en modo Layer2 y asigna un Puente: Configura el modo de interfaz en Troncal: Establece vlan como UNTAGGGED en la interfaz: Comprueba la configuración y aplícala: Cómo configurar la VLAN en modo Hybrid Interfaz de acceso: Configura en modo Layer2 y asigna un Puente: Establece el modo de interfaz en Hybrid: Establece vlan como UNTAGGGED en la interfaz: Configura vlan en TAGGED en la interfaz: Comprueba la configuración y aplícala: Resumen de todos los ajustes aplicados: Una vez completadas todas estas configuraciones detalladas, estará en condiciones de gestionar las VLAN de forma eficiente en los equipos de Ufispace, lo que garantizará una red organizada y segura. Siga los pasos con atención y, en caso de dudas, no dude en consultar la documentación oficial o ponerse en contacto con el servicio de asistencia técnica especializada. ¿Le gustaría hablar con uno de nuestros especialistas en UfiSpace e IPInfusion? En Made4it somos especialistas en estas tecnologías y ofrecemos servicios completos de configuración y asistencia técnica. Póngase en contacto con nuestros asesores para obtener más información y optimizar su red con soluciones profesionales: https://made4it.com.br/
Dónde utilizar Ufispace
Equipamiento Ufispace: Usos y Servicios Apoyados Introducción Ufispace es una empresa del ámbito de las redes y las telecomunicaciones, especializada en ofrecer soluciones de infraestructura de red de alta calidad. Sus equipos están diseñados para satisfacer las crecientes demandas de conectividad, capacidad y rendimiento en diversos sectores. En este artículo exploraremos los dispositivos S9600-72XC, S9600-56DX y S9510-28DC, dónde pueden utilizarse y qué servicios admiten. Equipamiento Ufispace S9600-72XC – Dispone de 8 puertos de 40/100G, 64 puertos de 1/10/25G, 2 puertos de 10G (MGMT, ópticos) y 1 puerto de 100/1000M (MGMT, eléctrico); Procesador Intel Skylake-D de 8 núcleos a 1,9 GHz, memoria de 32 GB DDR4, almacenamiento SSD de 128 GB y capacidad de conmutación de 2,4 Tbps, con un búfer profundo de 4 GB. S9600-56DX – Dispone de 8 puertos de 40/100/400G, 48 puertos de 40/100G, 4 puertos de 1/10/25G y 1 puerto de 100/1000M (MGMT, eléctrico); Procesador Intel Icelake-D de 8 núcleos a 2,1 GHz, memoria de 32 GB DDR4, almacenamiento SSD de 128 GB y rendimiento de capacidad de conmutación de 4,8 Tbps, con un búfer profundo de 8 GB. S9510-28DC – Dispone de 2 puertos de 100/400G, 2 puertos de 40/100G, 24 puertos de 10/25G y 1 puerto de 100/1000M (MGMT, eléctrico); Procesador Intel Denverton-NS de 4 núcleos a 1,6 GHz (estándar) / Intel Denverton-NS de 8 núcleos a 1,7 GHz (premium), memoria de 8 GB DDR4 (estándar) / 16 GB de DDR4 (Premium), almacenamiento de 32 GB en SSD (estándar) / 128 GB en SSD (Premium) y rendimiento de capacidad de conmutación de 800 Gbps, con un búfer profundo de 2 GB. Uso del equipo de Ufispace Gracias a su alta densidad de puertos y capacidad de conmutación. Como Núcleo del Centro de Datos o Agregador de Servidores. Pueden utilizarse en escenarios de topología Core, Agregación, trabajando como BGP, MPLS, como P y PE. En escenarios L2VPN, L3VPN, 6PE. Conclusión Los conmutadores Ufispace son una gran elección en los centros de datos para funciones críticas como el núcleo del servidor y la agregación, gracias a su alta densidad de puertos y capacidad de conmutación. Para los ISP, ofrecen la robustez y flexibilidad necesarias para topologías complejas, soportando protocolos como BGP y MPLS, así como servicios como L2VPN y L3VPN. Equipados con procesadores de última generación, abundante memoria y almacenamiento eficiente, estos conmutadores garantizan un rendimiento superior y una gran capacidad, lo que los hace ideales para construir infraestructuras de red modernas y eficientes.
Acceso inicial a Ufispace
Hoy vamos a hablar de cómo realizar el acceso inicial a los dispositivos UFISPACE con el sistema operativo OcNOS de IP Infusion. El primer acceso al equipo debe realizarse mediante un cable serie. La mayoría de los ordenadores actuales no disponen de una conexión serie; por lo tanto, es posible utilizar un adaptador de consola USB a RJ45, como el que se muestra en la imagen: Con el cable en la mano, conecta el lado RJ45 al puerto de consola del dispositivo UFISPACE, como se muestra en el ejemplo siguiente: Con la conexión física entre el ordenador y el UFISPACE, podemos entonces utilizar software, como teraterm, putty, entre otros, para realizar el acceso inicial. En este ejemplo, te mostraremos cómo hacerlo utilizando Putty. Para ello, abra Putty e introduzca los datos tal y como se indica a continuación: En Serial line, introduce el nombre de la interfaz COM de tu ordenador. Esto puede variar según cada equipo. La velocidad de acceso al UFISPACE debe ajustarse a 115200. Al acceder a través de la consola, aparecerá la pantalla de solicitud de nombre de usuario y contraseña, que por defecto es «ocnos» y «ocnos», respectivamente: Una vez que haya accedido a través de la consola, lo primero que se recomienda es cambiar la contraseña del usuario «ocnos» por una más segura; para ello, debe seguir los siguientes pasos: 1 – Entra en el modo enable: 2 – Entra en el modo de configuración: 3 – Cambia la contraseña del usuario y crea un nuevo usuario, como se muestra en el ejemplo: 5 – Aplica la configuración: 6 – Por último, guarda la configuración: Ahora vamos a configurar una interfaz de gestión. Por defecto, los equipos UFISPACE vienen con la interfaz «eth0» para utilizarla en la gestión out-of-band. Una buena práctica es dejar la gestión sólo en una VRF de gestión, con acceso controlado sólo a través de esa VRF. Para realizar esta configuración, sigue estos pasos: 1 – Accede a la interfaz eth0: 2 – Asigne la gestión de VRF a la interfaz: 3 – Configura la IP de gestión y la descripción de la interfaz: 4 – Aplica los ajustes y guarda: Para validar la configuración de la interfaz, podemos utilizar el comando «show ip interface brief», como se muestra en el ejemplo: Si estás en modo configuración, utiliza el comando «do show ip interface brief» Para configurar la ruta por defecto en la vrf, utilizamos el siguiente comando: Para validar la ruta por defecto en la VRF, podemos utilizar el comando Por defecto, ssh ya está activado en la gestión de vrf, si quieres desactivarlo, utiliza el comando: Para activar SSH en la vrf main, utiliza el comando Por último, es importante configurar ACL’s para proteger el acceso SSH y permitir sólo las redes que realmente puedan acceder al equipo. A continuación, vamos a configurar la ACL que contiene nuestras redes administrativas, que en este caso serán 10.10.0.0/30 y 172.16.0.0/24: Ahora tenemos que aplicar la ACL a la línea vty: Probando el acceso ssh con un usuario recién creado: Podemos ver que el acceso ha funcionado correctamente. Ahora vamos a comprobar si la ACL que hemos creado para la protección funciona. En este caso, vamos a utilizar la IP 172.20.0.1 como origen para acceder al dispositivo: Podemos ver que el ping funciona normalmente: Sin embargo, no nos da acceso SSH, lo que confirma que la ACL funciona correctamente: Ahora vamos a configurar SNMP para monitorizar un sistema como Zabbix. Para habilitar SNMP en la VRF management, utilizamos el comando: En caso de que se utilice «vrf main» para realizar la supervisión, basta con utilizar los siguientes comandos: Es importante que mantengamos la hora del equipo correcta para que podamos validar los registros para la resolución de problemas con la hora local correcta. Para ello, vamos a configurar NTP para actualizar la fecha y la hora: Para comprobar los pares NTP, utilizamos el comando: Ahora tenemos que corregir la zona horaria para que la hora sea correcta: Otra característica importante es la posibilidad de utilizar «commit confirmed» con timeout, para utilizarla en casos de configuraciones que puedan causar downtime de la red. Hagamos un ejemplo cambiando el nombre de host y aplicando un tiempo de espera confirmado de confirmación de 10 segundos: Si no se confirma la confirmación, la configuración volverá a la configuración anterior: Para confirmar la confirmación, utilizamos el comando «confirm-commit». Conclusión Tras completar las configuraciones iniciales, el dispositivo estará preparado para responder al acceso SSH a través de la red a las IPs autorizadas en el firewall y con los usuarios configurados. La monitorización SNMP también podrá consultar la información utilizando la Comunidad creada. Si tienes alguna duda sobre la configuración inicial de UFISPACE, ponte en contacto con nosotros para que podamos ayudarte.
SRv6: ¿un sucesor del MPLS?
En Made4it nos apasiona la evolución, y el SRv6 ha sido motivo de gran entusiasmo y debate entre nuestros equipos y la comunidad. Un protocolo que intente competir directamente con el MPLS sin duda debe analizarse con mucho detenimiento. Vamos a conocerlo un poco mejor en una serie de artículos sobre el tema. En los últimos años, la evolución de las redes se ha visto impulsada por unas demandas cada vez mayores de escalabilidad, flexibilidad y eficiencia. En este escenario dinámico, tecnologías como el MPLS (Multiprotocol Label Switching) han surgido como soluciones predominantes para satisfacer las complejas necesidades de enrutamiento y gestión del tráfico. Sin embargo, con el avance de las aplicaciones y los servicios digitales, han surgido retos que el MPLS tradicional no lograba resolver de manera eficiente. Las necesidades constantes de las redes, junto con nuevas tecnologías como el 5G, el IoT, los vehículos autónomos y todo un ecosistema en crecimiento exponencial, EXIGEN que las redes de comunicación se adapten a las nuevas demandas y necesidades. Es aquí donde el Segment Routing sobre IPv6 (SRv6) entra en escena como una alternativa innovadora que satisface estos requisitos con sencillez y elegancia. MPLS: la tecnología heredada El MPLS se introdujo a finales de la década de 1990 y ganó popularidad rápidamente gracias a su capacidad para proporcionar un enrutamiento de paquetes basado en etiquetas (las famosas «labels»), lo que permite un mayor control sobre el flujo de tráfico y una mejor calidad de servicio (QoS). En la década de 2000, el MPLS se convirtió en la opción preferida de los proveedores de servicios y las empresas que buscaban soluciones robustas para redes a gran escala, centros de datos e interconexiones entre redes. Para los proveedores de servicios, la escalabilidad y la facilidad que ofrecía el MPLS hicieron que su implementación en sus redes resultara inevitable. Esto permitió a los proveedores de servicios desarrollar y comercializar nuevos productos, lo que culminó en que las empresas conectaran sus sedes centrales y sucursales de forma transparente, que los operadores de telefonía móvil lograran expandir sus redes de forma masiva, entre otras muchas innovaciones que se produjeron con el tiempo, a medida que Internet dejaba de ser propiedad de las grandes corporaciones para pasar a ser de las personas. Necesidades y limitaciones del MPLS: Toda tecnología tiene aspectos positivos y negativos, y se diseña y desarrolla para satisfacer una o varias necesidades en un momento determinado. A medida que pasa el tiempo, las redes crecen y siguen evolucionando, lo que implica que surgen constantemente nuevas necesidades que quizá no puedan satisfacerse con dichas tecnologías. En el caso del MPLS no ha sido diferente: a medida que las redes han continuado creciendo y evolucionando, algunas limitaciones del MPLS han comenzado a hacerse muy evidentes. Complejidad operativa: La gestión y la configuración de las redes MPLS, en función de su tamaño y de las «funcionalidades» que requiera la red, pueden resultar complejas y exigir conocimientos altamente especializados. Escalabilidad: A medida que las redes crecen, resulta complicado ampliar las infraestructuras MPLS sin aumentar significativamente los costes y la complejidad de la red. Existen técnicas y buenas prácticas para este tipo de implementaciones, pero, al igual que cualquier otra tecnología, el MPLS también tiene sus limitaciones en cuanto a escalabilidad. En muchos casos, el precio de la escalabilidad de una red MPLS es un uso cada vez mayor de recursos de procesamiento en los equipos de red, tablas de enrutamiento cada vez más extensas y entornos de red cada vez más delicados. Esto aumenta inevitablemente los gastos de capital (CAPEX) y los gastos operativos (OPEX) de la operación, llegando a puntos en los que resulta completamente inviable mantener dicha tecnología en funcionamiento en la red y obliga a buscar arquitecturas de red alternativas para mantener el entorno operativo. Flexibilidad limitada: MPLS se diseñó para escenarios específicos y puede que no se adapte fácilmente a las nuevas demandas de tráfico y a los servicios emergentes. Con la aparición de nuevas tecnologías como el 5G y las nuevas necesidades que plantean el IoT y las innovaciones tecnológicas en el ámbito de los vehículos autónomos y la telemedicina, resulta necesario disponer de alternativas para la segregación de la red a nivel de topología (Slicing), además de la segmentación del tráfico según prioridades tales como rutas de baja latencia y alto tráfico, baja latencia y bajo tráfico, alto tráfico sin tener en cuenta la latencia, y así sucesivamente. En la actualidad, el MPLS no es capaz de satisfacer estas nuevas demandas con sus mecanismos heredados. SRv6: La innovación en el enrutamiento por segmentos El Segment Routing sobre IPv6 (SRv6) es una tecnología de nueva generación que combina el Segment Routing (SR) y el IPv6, aprovechando los mecanismos de enrutamiento ya existentes en el IPv6. Mediante el uso de una extensión de la cabecera IPv6 como medio para la identificación y el enrutamiento de la información dentro de una red, el SRv6 aporta ventajas tanto en el plano de control como en el plano de datos de los equipos de red, con un menor coste y un mayor rendimiento. El SRv6 se diseñó desde el principio teniendo en cuenta las necesidades actuales y futuras, por lo que es altamente programable y totalmente flexible para adaptar tanto las redes heredadas como los nuevos entornos de red. Con el concepto de «programabilidad» ya consolidado, el SRv6 ofrece a la red la capacidad de codificar instrucciones individuales para los paquetes directamente en su encabezado. En el «SR-MPLS» (Segment Routing MPLS), estas instrucciones se transportan en etiquetas (labels) MPLS; en SRv6, dichas instrucciones se transportan de forma nativa en la cabecera IPv6 mediante la incorporación de una extensión denominada SRH, o Segment Routing Header. Características y ventajas de SRv6. Comparación con tecnologías heredadas Al comparar el SRv6 con tecnologías heredadas como el MPLS, resulta evidente que el SRv6 ofrece un enfoque más sencillo, flexible y adaptable a las necesidades actuales de las redes de comunicación. Si bien el MPLS sigue siendo una solución viable para muchos
Nuevo método para importar máquinas virtuales de VMware a ProxMox
¡Hola a todos, soy Bryam, de Made4it! Como saben, siempre estamos atentos a las novedades que pueden revolucionar nuestra forma de trabajar, y hoy estamos muy ilusionados por compartir algo que nos facilitará la vida a todos los que nos dedicamos a la infraestructura y la virtualización. A diario llevamos a cabo diversas migraciones para todo tipo de empresas, y esta novedad facilitará enormemente nuestro proceso. Ustedes lo pidieron y la tecnología ha respondido: ¡la migración de máquinas virtuales de VMware a ProxMox acaba de volverse mucho más sencilla e intuitiva! Olvídense de los comandos complicados y de las líneas de código que parecían no tener fin. Ahora, con solo unos clics, pueden llevar a cabo todo el proceso directamente a través de la interfaz gráfica de usuario web. Estén atentos, porque les contaremos con todo detalle esta innovación que promete suponer un punto de inflexión en nuestro día a día. ¡Acompáñennos en este viaje tecnológico! Introducción Hasta entonces, la migración de VMware a ProxMox era un proceso que se realizaba íntegramente a través de la CLI: teníamos que descargar un binario específico, establecer la comunicación con el VMware de destino, descargar el disco, convertirlo, importarlo a ProxMox y vincularlo a alguna máquina virtual. Al observar este enorme interés por parte de los usuarios que se decantan por ProxMox, han aprovechado la ocasión para desarrollar un nuevo método de migración de máquinas virtuales y, lo mejor de todo, es que se realiza íntegramente a través de la interfaz gráfica de usuario web, lo que ha simplificado enormemente este proceso, ¡ya que ya no es necesario utilizar la interfaz de línea de comandos del servidor! Esta nueva opción está disponible a partir de la versión 8.1.8 de ProxMox y los binarios que hacen posible esta función son los siguientes: pve-manager versión 8.1.8, libpve-storage-perl versión 8.1.3 y el nuevo binario pve-esxi-import-tools. Actualizando En primer lugar, debemos tener configurado alguno de estos repositorios en nuestro Proxmox: pvetest o pve-no-subscription Seleccione su servidor > Actualizaciones > Repositorios Si no dispone de ninguno de estos repositorios, solo tiene que ir a la opción «Add» y seleccionar el repositorio «Test» o «pve-no-subscription». Una vez añadido el repositorio, solo tiene que ir a la opción «Updates», seleccionar la opción «Refresh» para obtener los paquetes más actualizados y, a continuación, ir a «Upgrade» ¡ACTUALICE SU PROXMOX SOLO SI ESTÁ SEGURO DE LO QUE ESTÁ HACIENDO, YA QUE ESTE PROCESO, SI NO SE REALIZA CORRECTAMENTE, PUEDE AFECTAR A SU ENTORNO!! ¡Si tiene alguna duda, no dude en ponerse en contacto con nosotros! Se abrirá una ventana emergente y solo tendrá que configurar la actualización. Una vez finalizada la actualización, se recomienda reiniciar el servidor para que se ejecute con el nuevo kernel (si se ha actualizado). Comunicación con VMware La comunicación con nuestro VMware se realiza a través de la API y, para configurarla, debemos acceder a: Centro de datos > Almacén de datos > Añadir > ESXi Configuraremos este nuevo almacenamiento de la siguiente manera: Una vez configurado el almacenamiento, ya aparecerá en sus servidores ProxMox. Realización de la migración Cuando acceda a Storage, aparecerá una pantalla como esta: Básicamente, veremos las máquinas virtuales existentes en su VMware; a continuación, solo tiene que seleccionar la que desee migrar y elegir la opción «Importar» Aparecerá esta pantalla, en la que se muestran los ajustes previos que desea realizar antes de importar: En caso de que la máquina virtual tenga algún CD-ROM asociado en VMware, este no se migrará. La máquina virtual no se puede migrar mientras esté en marcha; primero hay que apagarla (en VMware) Una vez que haya realizado los cambios que desee, solo tiene que hacer clic en «Importar» y esperar. Una vez finalizada la importación, ¡su máquina virtual ya estará lista para su uso! Importación en tiempo real Para reducir el tiempo de inactividad, dado que debemos apagar la máquina virtual que se va a migrar, ProxMox ha incorporado la opción «Live Import», que permite, durante el proceso de importación, encender la máquina virtual y dejarla ya operativa, simulando así la función «Live Restore» que ya ofrece ProxMox Backup Server. Más información ¿Le interesa simplificar sus migraciones de máquinas virtuales? Made4it está aquí para garantizar que su transición a ProxMox sea lo más fluida posible. ¡No deje que las dudas le frenen! Póngase en contacto con nosotros y concertaremos una llamada para aclararle todo lo que necesite saber. ¿Aún no está convencido? Eche un vistazo a nuestra entrada «VMware frente a ProxMox: ¿cuál elegir?» en el blog de Made4it. En ella, detallamos las ventajas de cada sistema para que pueda tomar la mejor decisión para su caso concreto. Recuerde que Made4it es especialista en virtualización. Estamos a su disposición para ayudarle a alcanzar nuevas cotas con ProxMox. ¡Póngase en contacto con nosotros ahora mismo y lleve su infraestructura al siguiente nivel!
Hacia el futuro de la gestión multivendedor para CPE e IoT: TR-069 a TR-369
Introducción En el panorama cada vez más interconectado de la tecnología moderna, la gestión eficiente y unificada de los dispositivos se ha convertido en algo crucial. La evolución del protocolo TR-069 a TR-369 marca un punto crucial en este camino, abriendo nuevas puertas a proveedores de servicios y usuarios finales. En este artículo analizaremos la transición de TR-069 a TR-369 y el importante impacto que tiene en la gestión de dispositivos en un mundo cada vez más conectado. TR-069 —> TR-369: El futuro de la gestión de dispositivos El Protocolo de Gestión de WAN CPE (CWMP), conocido como TR-069, supuso un hito en la capacidad de los proveedores de Internet para prestar servicios de forma rápida y eficaz, garantizando una gestión proactiva y segura de la red. Sin embargo, con la llegada de la Internet de los objetos (IoT ) y la creciente demanda de dispositivos interconectados, ha quedado claro que este protocolo necesita evolucionar. La TR-369, también conocida como Plataforma de Servicios al Usuario (USP), es la respuesta a esta necesidad de evolución. Desarrollado conjuntamente por una serie de empresas e instituciones de renombre, entre ellas Google, Nokia y Huawei, el TR-369 promete ser flexible, seguro, escalable y estandarizado para satisfacer las demandas de un mundo cada vez más conectado. Retos y oportunidades del Internet de los objetos La creciente demanda de entornos interconectados, como hogares inteligentes y entornos basados en la nube, ha traído consigo una serie de retos y oportunidades. La monetización de los dispositivos IoT se ha convertido en una prioridad para muchas empresas, lo que ha dado lugar a soluciones propietarias que, aunque comprensibles, contribuyen a un ecosistema pobre y limitado. TR-369 ha surgido como solución a estos retos, ofreciendo una norma abierta e interoperable que fomenta la competencia sana, la innovación continua y el ahorro de costes para los proveedores de servicios y los usuarios finales. El futuro de la gestión de dispositivos: TR-369 en acción Con la implantación de TR-369, los proveedores de servicios pueden esperar una gestión de dispositivos más eficaz y unificada, independientemente del proveedor. La flexibilidad y escalabilidad de TR-369 garantizan que las soluciones basadas en esta norma estén preparadas para los retos del futuro, manteniéndose al día y adaptándose a las nuevas tecnologías y demandas del mercado. Conclusión A medida que avanzamos hacia un futuro cada vez más interconectado, la evolución del TR-069 al TR-369 constituye un paso crucial en el camino hacia una gestión eficiente y unificada de los dispositivos. Con el respaldo de empresas e instituciones líderes del sector, el TR-369 promete revolucionar la forma en que se gestionan los dispositivos en un mundo cada vez más conectado. Prepárese para el futuro de la gestión de dispositivos con TR-369 y descubra las ventajas de un enfoque multiproveedor para CPE e IoT. Conozca OktopUSP: la revolución en gestión de dispositivos Como patrocinadora oficial del proyecto, Made4it tiene el placer de presentar el OktopUSP, un proyecto innovador desarrollado por la empresa Oktopus, bajo la dirección de Leandro Antonio Farias Machado. Este proyecto promete revolucionar la forma en que los proveedores de Internet y los integradores de TI gestionan sus dispositivos, ofreciendo control remoto, información detallada y una solución preparada para el futuro. Descripción: OktopUSP se creó para que los proveedores de Internet y los integradores informáticos pudieran aprovechar todo el potencial de sus productos. Gracias a sus sólidas funciones y a su enfoque multiproveedor, OktopUSP permite: Listo: OktopUSP ofrece gestión en la nube o en las instalaciones, lo que le permite acceder a sus dispositivos desde cualquier lugar y recibir alertas en tiempo real, sin tener que modificar la topología de su red. Multiproveedor: No se convierta en rehén de un único proveedor con soluciones específicas y costosas. Con OktopUSP, puedes controlar tu parque de dispositivos mixtos de forma fiable y segura. WiFi: Con más de 350 parámetros para la configuración Wi-Fi y la flexibilidad para supervisar varios dispositivos IoT, OktopUSP le ofrece un control total sobre su red inalámbrica. Pronto os daremos más detalles sobre OktopUSP , y también nos enorgullece anunciar que Made4Graph incluirá la gestión a través de TR-369, además de TR-069. Permanezca atento a nuestras actualizaciones para no perderse ninguna novedad. El futuro en soluciones Made4it En Made4Graph, ya es posible llevar a cabo una gestión integral a través del protocolo TR-069, lo que permite a los proveedores y administradores de red supervisar y controlar sus dispositivos con facilidad y eficacia. Además, la plataforma se está preparando para el futuro, con planes para implementar en breve la gestión mediante el protocolo TR-369. Esta transición entre ambos protocolos es una prueba del compromiso de Made4it por ofrecer soluciones innovadoras que se adapten a las demandas en constante evolución del mercado. Gracias al soporte continuo y a las actualizaciones que ofrece Made4Graph, los proveedores y administradores de red pueden estar seguros de que están preparados para afrontar los retos y aprovechar las oportunidades que presenta el futuro de la gestión de CPE e IoT. ¡Estén atentos a nuestras novedades! Suscríbase a continuación para no perderse las últimas noticias.
Reconfiguración del ONU/ONT NOKIA G-1425-GA tras un reinicio: la autoconfiguración mediante la opción 43 de DHCP para la asignación del ACS
En este artículo hablaremos sobre el proceso de reconfiguración de los routers Nokia G-1425-GA tras su reinicio. Para que se reconfiguren por completo y vuelvan al estado en el que se encontraban antes del reinicio, es necesario disponer de un servidor ACS TR-069 configurado y en funcionamiento, que conserve sus configuraciones anteriores. Si no sabe qué es un servidor ACS ni para qué sirve, lea el artículo. Estas pruebas se llevaron a cabo en las instalaciones de laboratorio de DPR Telecomunicaciones, el principal socio de Nokia en Brasil. Cuentan con una amplia planta de fabricación de equipos ópticos y un laboratorio para realizar pruebas de las soluciones de Nokia. Obtenga más información sobre DPR aquí. Para la prueba, utilizamos el modelo de la ONU NOKIA G-1425-GA. Se configuró por completo, incluido el servidor ACS made4graph de Made4it, que se encargó de la persistencia de los datos para el aprovisionamiento. Una vez que el entorno de laboratorio ha quedado debidamente configurado, hemos restablecido los ajustes de fábrica en nuestro CPE de pruebas. Como se puede observar en las imágenes siguientes, se han perdido todas las configuraciones, incluidas las de WAN, Wi-Fi y el servidor ACS, que han vuelto a los valores predeterminados. Solicitar el«Restablecimiento de la configuración del sistema a los valores predeterminados de fábrica» La configuración«por defecto»del TR-069 del ONT de Nokia tras el reinicio. Un aspecto importante del laboratorio es observar la VLAN y el modo de direccionamiento de la ONU con la configuración de fábrica. En este caso, la ONU de Nokia se conecta a una WAN en la VLAN 881 y con el DHCP activado. Una vez restablecido el router, con la configuración de fábrica vigente, hemos configurado la infraestructura de autoprovisión mediante las opciones 43 de DHCP, tal y como se indica en el artículo: . ¡Para ello hemos utilizado la misma VLAN 881 predeterminada! Aquí, en cuestión de segundos, la ONU recibió la dirección IP del servidor DHCP y también la del servidor ACS. A continuación, comienza la magia del TR-069, con el servidor ACS made4graph reconfigurando por completo la ONU a su estado anterior, incluyendo la WAN correcta (nombre de usuario, contraseña PPPoE y VLAN de acceso al BNG/BRAS), la red Wi-Fi, los reenvíos de puertos y mucho más. ¿Y cómo se genera la URL para la entrega del ACS a través de la opción 43 de DHCP? Para generar la URL, Nokia utiliza una regla para la opción 43«Vendor Specific Information» codificada con tres parámetros: Los campos siempre se componen de: Basándonos en esta regla, podemos generar el código de la opción 43 para enviarlo a través de DHCP. Le explicaré cómo hacerlo. En primer lugar, debe tener los datos a mano: URL del servidor ACS Nombre de usuario Contraseña Con estos datos, puede crear el campo según los requisitos de Nokia. Veamos un ejemplo: 😀 Para generar la URL del ACS https://acs.made4graph.com.br/ con el nombre de usuario «made4graph» y la contraseña «made4it», debemos convertir cada campo a formato hexadecimal, anotar la longitud de la cadena y darle el formato correcto. URL URL (hexadecimal) Talla Tamaño (hexadecimal) https://acs.made4graph.com.br/ 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 30 1E USUARIO Usuario (hex) Talla Tamaño (hexadecimal) made4graph 6D616465346772617068 10 0A CONTRASEÑA Contraseña (hexadecimal) Talla Tamaño (hexadecimal) made4it 6D616465346974 7 07 Entonces, el campo hexadecimal completo quedaría así: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974 Llegamos a la cadena final, que puede pegarse en el servidor DHCP: 0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974 *El 0x al principio indica al servidor DHCP que los datos que le siguen están en formato hexadecimal Para facilitarle la tarea, hemos creado el generador automático de Option 43 para NOKIA, que puede consultar aquí Conclusión En este artículo, le mostramos cómo configurar un servidor DHCP para proporcionar atributos de ACS a los CPE de Nokia que acaban de ser «restablecidos» a los valores de fábrica, sin necesidad de «preconfiguración» ni de modificar el firmware. Esto nos permite, de forma sencilla y eficaz, autoconfigurar una URL, un nombre de usuario y una contraseña de un servidor ACS en un CPE/ONU de Nokia, lo que hace que sea accesible desde un servidor ACS y permite su autoconfiguración a través del protocolo TR-069. Esta técnica resulta muy útil en entornos con CPE/ONU de Nokia, donde un servidor DHCP preconfigurado en la VLAN de ID 881 (por defecto en Nokia) garantiza que, independientemente de que un CPE se reinicie o pierda su configuración, siempre mantendrá la conectividad con el servidor ACS y estará correctamente configurado a través de TR-069. Un agradecimiento especial a DPR por brindarnos todo el apoyo necesario, además de proporcionar la infraestructura para que se llevaran a cabo las pruebas, lo que nos ha demostrado que los equipos de Nokia implementan de forma fiable la especificación TR-069 CPE WAN Management Protocol y permiten la autoconfiguración del ACS a través de la opción 43 de DHCP.
Opción 43 de DHCP para la configuración automática de ACS
Hoy vamos a analizar la famosa opción 43 de DHCP, que se utiliza principalmente en la autoconfiguración de dispositivos como puntos de acceso, conmutadores, teléfonos IP, CPE, dispositivos IoT y otros a través del protocolo TR-069. Asimismo, le mostraremos un ejemplo de configuración utilizando el servidor DHCP de un router Mikrotik, que proporciona parámetros a través de la opción 43 de DHCP y permite la autoconfiguración de servicios durante el proceso de asignación de la dirección IP al dispositivo. Esto nos permite, por ejemplo, detectar automáticamente un controlador externo al dispositivo, incluso si el equipo ha sido restablecido a los valores de fábrica. El documento RFC 2132 «DHCP Options and BOOTP Vendor Extensions» [1] aborda diversos tipos de información que pueden enviarse a través del protocolo DHCP, como, por ejemplo, el DNS, la máscara de subred, la dirección de la puerta de enlace (enrutador), los atributos específicos del proveedor y muchos otros. La Opción 43 se define en este RFC como «Vendor Specific Information» y se utiliza para que los clientes y los servidores DHCP intercambien información específica entre sí. El RFC no especifica qué valores se pueden enviar, ni de qué tipo de información se trata, y mucho menos el tipo de datos. Se limita a describir la estructura, que debe ser la siguiente: Código Len Información específica del proveedor 43 n i1 i2 … Código 1 Len 1 Fecha 1 Código 2 Len 2 Fecha 2 Código n Len n Fecha n T1 n1 d1 T2 n2 T2 … … … Con esta estructura, cada fabricante u organización puede estructurar los datos de la forma que le resulte más conveniente para su uso. Por ejemplo, para que los puntos de acceso puedan configurarse con las direcciones IP de los controladores Wi-Fi, lo que permite su «incorporación» al controlador centralizado; para que los teléfonos IP dispongan de la dirección IP o la URL del servidor de telefonía; y para que los routers compatibles con TR-069 puedan configurarse con la URL del ACS. ¡Y todo ello de forma automática! El objetivo de este artículo es mostrar el uso de la opción 43 junto con TR-069, enviando la URL del servidor ACS al CPE a través del servidor DHCP. Esto nos permite que el router, incluso si se ha reiniciado y carece de una «plantilla» de configuración, obtenga a través de DHCP la URL del servidor ACS, junto con el nombre de usuario y la contraseña, datos necesarios para integrarse en el ACS y permitir que el TR-069 aplique automáticamente las configuraciones en el CPE. Pero antes de continuar, voy a dejar algunos enlaces a otros ejemplos de casos de uso de la opción 43. Configure la opción 43 de DHCP para los puntos de acceso ligeros: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html Detección de ID de VLAN a través de DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Utilice la opción 43 de DHCP para la configuración de los puntos de acceso Unifi:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ ¿Cómo llegó el DHCP al TR-069? Si no sabe qué es el ACS, consulte nuestro otro artículo. El DHCP se ha incorporado como una de las formas de incorporación del ACS. La incorporación es el proceso mediante el cual se configura el CPE o el router con un servidor ACS.Existen tres formas de llevar a cabo el proceso de incorporación de los CPE a un servidor ACS, según la especificación TR-069 del Broadband Forum [2]: El objetivo final de cualquiera de los tres es el mismo: tener la URL del servidor ACS configurada en el CPE, para que este pueda gestionarse a través del protocolo TR-069. Proceso de solicitud de la opción 43 de DHCP El BroadBand Forum establece una serie de pasos para que el CPE pueda obtener la URL del ACS a través de DHCP. La siguiente imagen muestra los pasos, y a continuación vamos a comentar cada uno de ellos. Pasos a seguir en la comunicación: En la especificación del TR-069 también se definen otros campos o protocolos que pueden utilizarse con el mismo fin: la opción 125 de DHCPv4 y la opción 17 de DHCPv6. Asimismo, se mencionan diversas reglas de detección tras un reinicio y cómo abordar los problemas de conectividad con el ACS. Sin embargo, quedan fuera del alcance de este artículo. Ejemplo de una transacción DHCP con la opción 43: capturas de paquetes Ejemplo de configuración en Mikrotik En este artículo, veremos cómo configurar un router Mikrotik para que, a través del servidor DHCP, proporcione parámetros de autoconfiguración a los «clientes» mediante la opción 43. La configuración se basará en la topología que se muestra a continuación, similar a la utilizada en nuestras pruebas con un CPE de Nokia. En primer lugar, es necesario configurar el servidor DHCP y, a continuación, vincular los ajustes de la opción DHCP 43. Utilizamos la red 192.168.2.0/24 y la VLAN 881, tal y como se muestra en nuestro ejemplo: Seguramente se estará preguntando: ¿de dónde ha salido ese valor de la opción 43? Efectivamente, existe una regla que hay que crear, y en el siguiente artículo podrá consultar cómo generarla para su servidor ACS. Conclusión En este artículo, explicamos cómo utilizar el atributo «Option43» de DHCP para la autoconfiguración de un servidor ACS en CPE y diversos dispositivos. Analizamos su funcionamiento y cómo puede utilizarse para automatizar el envío de configuraciones específicas a los dispositivos mediante un protocolo tan habitual como el DHCP. Conocer las capacidades, características y opciones que admiten el fabricante y el modelo del equipo nos ayuda a automatizar diversas configuraciones, entre las que se incluye, entre otras, la gestión de un CPE de Nokia a través del protocolo TR-069. Referencias:[1] RFC 2132, Opciones DHCP y extensiones de fabricante de BOOTP, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, Protocolo de gestión de CPE en WAN, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
VMware vs Proxmox – ¿Cuál elegir?
Introducción Hoy en día, cuando hablamos de servidores, los asociamos automáticamente a la virtualización. Atrás quedaron los días en que utilizábamos servidores bare-metal para ejecutar una sola aplicación. Con la facilidad de la virtualización y el mejor aprovechamiento de los recursos del servidor, se ha hecho casi obligatorio utilizar su servidor con algún software de virtualización. En la actualidad, dos grandes nombres lideran la virtualización: VMware y Proxmox. Más aún tras la noticia de la venta de VMware a Broadcom, este tema se ha vuelto aún más candente. Y la pregunta que se hace la mayoría es: ¿VMware o Proxmox? ¿Qué virtualizador elegir? ¿Cuál es el «mejor»? A lo largo de este post, haremos algunas comparaciones entre los dos virtualizadores para que puedas decidir cuál se adapta mejor a tus necesidades y, por supuesto, ¡conocer las principales características de cada uno! Resumen del servicio Proxmox es un virtualizador de código abierto actualizado y mantenido por Proxmox. Está basado en Debian y utiliza KVM/QEMU como virtualizador y LXC para contenedores. Destaca por ser gratuita y tener una gran variedad de funcionalidades, por lo que el límite de lo que puedes crecer y evolucionar está directamente ligado a tu conocimiento de la herramienta. Proxmox también destaca en lo que respecta a la compatibilidad con hardware antiguo, ya que está directamente vinculado al núcleo Linux utilizado. VMware es un virtualizador de código cerrado cuya actualización y mantenimiento corren a cargo, desde hace poco, de Broadcom. En la actualidad, ha dejado de ser gratuito y ahora su uso está sujeto exclusivamente a un sistema de licencias. Como virtualizador, utiliza tecnologías propias para la virtualización de servidores, y su alto rendimiento y estabilidad son innegables. Destaca por su interfaz sencilla y por unas funcionalidades que aportan un gran valor añadido en entornos de gran envergadura. La compatibilidad de VMware depende de la versión de la que se trate; cuanto más reciente es la versión, menor es la compatibilidad con equipos considerados antiguos. Facilidad de uso Proxmox, a primera vista, puede parecer confuso y difícil, sobre todo porque algunas configuraciones requieren la integración con la CLI. Sin embargo, una vez que te acostumbras a su interfaz y a las funciones que necesitas, todo resulta más fácil. También cuenta con una excelente documentación que cubre todas las funciones disponibles. También tiene soporte de pago, que los usuarios pueden elegir comprar o no, y cuenta con una buena comunidad activa. VMware tiene una interfaz más objetiva y fácil de usar. Con unos pocos clics, puedes poner en marcha una máquina virtual. En cambio, si desea acceder a otras funciones, deberá adquirir una nueva licencia y/o configurar otro software (por ejemplo, VEEAM, vCenter). Dispone de una excelente documentación y varias KB (Knowledge Base) que explican diversos problemas que pueden surgir. Rendimiento Ambos servicios funcionan bien. VMware destaca por ejecutar su sistema operativo en memoria RAM, lo que permite navegar mejor por su interfaz. Aparte de eso, ambos están muy cerca en términos de rendimiento en escenarios mixtos, utilizando máquinas virtuales Linux y Windows y diferentes tipos de almacenamiento y almacenamiento. Escalabilidad Ambos virtualizadores permiten aumentar los recursos (CPU/MEM/DISCO) de sus máquinas virtuales sin problemas y, si es necesario, ampliar incluso los recursos internos, como añadir más espacio en algún almacén de datos o disco de sus máquinas virtuales. Ahora, si adquiere otro servidor y desea aumentar su infraestructura de servidores, Proxmox maneja mejor la adición de un nuevo servidor a su sistema. Mientras que en VMware este servidor estaría aislado y habría que configurar un nuevo servicio (vCenter) para unir los servidores bajo su gestión, en Proxmox basta con crear un Cluster y dar de alta el nuevo servidor en el cluster (literalmente sólo estas dos configuraciones). Características y funcionalidades Ambos servicios tienen características y funcionalidades similares. En el caso de VMware, el acceso a ellos dependerá de la licencia que tengas, mientras que en Proxmox dependerá de si la versión en la que te encuentras tiene soporte para ello o no. Ejemplos de algunas de las funcionalidades que tienen en ambos: Costes Hicimos una simulación para un servidor con 1 CPU (Socket) y estos fueron los costes No necesitas una licencia para utilizar Proxmox, sólo el apoyo directo del fabricante si lo deseas. Estudios de casos y ejemplos prácticos Supongamos algunos escenarios y comprendamos dónde es interesante implantar VMware o Proxmox. P. D.: ¡ Voy a defender los entornos locales de los proveedores de Internet! Escenario 1: Tengo un servidor usado de antes de 2015 y me gustaría añadirlo a producción para virtualizar 5 VMs no críticas. Escenario VMware: Escenario Proxmox Es decir, en ambos casos podrá implementar su solución. Por supuesto, en el caso de VMware, además del precio de la licencia, deberá tener en cuenta el modelo de su servidor y, sobre todo, su año de fabricación. Los servidores muy antiguos no son compatibles con las versiones más recientes de VMware, y tendrá que realizar inversiones adicionales para dar soporte al escenario de copia de seguridad en caso de que cuente con más de 10 máquinas virtuales en su entorno. Escenario de actualización 1: Vi que la virtualización funcionaba muy bien, y ahora quiero añadir más VMs, pero ahora habrá VMs críticas, y para ejecutar estas VMs actualicé y compré un nuevo servidor. Escenario VMware: Escenario Proxmox Conclusión En cualquier caso, hemos visto que Proxmox y VMware son muy similares y pueden ofrecer el mismo resultado, ¡siempre que se cumplan algunos requisitos! Todo depende del tamaño de su infraestructura y de su criticidad. Lo primero que debemos tener en cuenta es la inversión que voy a realizar en licencias. En caso de que opte por utilizar VMware, considere si esa inversión no podría ser más útil en algún otro ámbito (por ejemplo, actualizar algún componente de mi servidor interno). Mi recomendación es la siguiente: si tu infraestructura está al 100%, con servidores nuevos que no necesitan actualización, y puedes permitirte las licencias, apuesta por VMware, porque te dará lo mejor en el mundo de la
Cómo configurar FlowSpec en los routers Juniper
Visión general: El BGP FlowSpec (Border Gateway Protocol Flow Specification) es una extensión del protocolo BGP que se utiliza para definir reglas de filtrado del tráfico en los routers o, dicho de forma más sencilla, para generar reglas de cortafuegos en los routers a partir de un anuncio BGP. A diferencia del BGP convencional, que realiza el enrutamiento basándose en información de IPv4/IPv6 y prefijos, el BGP FlowSpec permite a los administradores de red especificar criterios más detallados para el enrutamiento de paquetes, incluyendo información de la capa 4 (puertos TCP/UDP) e incluso patrones de paquetes. Para obtener más información sobre BGP Flowspec, consulte nuestro artículo sobre qué es BGP Flowspec a través de este enlace. Operación: BGP FlowSpec funciona añadiendo nuevos tipos de atributos a BGP, lo que permite a los administradores de red especificar reglas de filtrado detalladas. Estas normas pueden incluir criterios como: Se pueden realizar las siguientes acciones con BGP FlowSpec: Cuando estas reglas se propagan a través de la red BGP, los routers pueden utilizar esta información para filtrar o manipular el tráfico de acuerdo con las políticas definidas. Funcionamiento – Más detalles: En el contexto de BGP FlowSpec, las acciones se especifican como parte de las reglas de filtrado. Cada regla de filtrado contiene tres partes principales: Las acciones en BGP FlowSpec se codifican utilizando comunidades BGP. Cada acción se asigna a una comunidad BGP específica: Cuando se crea una regla BGP FlowSpec, se especifican los campos coincidentes, la acción deseada y, opcionalmente, los campos de protocolo. A continuación, esta regla se codifica como una comunidad BGP y se incluye en un mensaje de actualización BGP que se envía a los routers vecinos. Los routers que reciben esta regla aplican las acciones especificadas a los paquetes que cumplen los criterios de coincidencia. Tenga en cuenta que las comunidades BGP específicas para cada acción pueden variar en función de la implementación de BGP FlowSpec en su equipo de red. Le recomiendo que consulte la documentación de su equipo para obtener información detallada sobre las comunidades BGP asociadas a cada acción en BGP FlowSpec. Casos prácticos: 1. **Mitigación de ataques DDoS: BGP FlowSpec puede utilizarse para bloquear o redirigir tráfico malicioso durante ataques de denegación de servicio distribuidos (DDoS). Se pueden aplicar reglas precisas para filtrar el tráfico no deseado y mantener los servicios en línea. 2. **Políticas de calidad de servicio (QoS): Los administradores de red pueden utilizar BGP FlowSpec para garantizar la calidad del servicio priorizando determinados tipos de tráfico en función de puertos o protocolos específicos. 3. **Aplicación de políticas de seguridad**: BGP FlowSpec puede utilizarse para aplicar políticas de seguridad granulares, bloqueando el tráfico asociado a malware o actividades sospechosas. Ejemplos de configuración: La configuración de BGP FlowSpec puede variar en función del equipo de red utilizado. Este ejemplo explora cómo diseñar una solución de mitigación DDoS en la que un proveedor de servicios permite a sus clientes anunciar rutas BGP FlowSpec para él. También analiza algunas de las mejores prácticas que deben tenerse en cuenta antes de implementar este tipo de solución y, por último, algunos de los comandos de Junos disponibles para ayudarle a comprobar que su solución Flow-spec funciona correctamente. Escenario topológico del ejemplo: Empecemos por ver cómo se configurará nuestra solución: Como podemos observar en la topología anterior, existe «BORDA», un equipo de Juniper que actúa como enrutador BGP de la red, y «Made4Flow», el software que analizará los flujos, generará reglas de BGP FlowSpec de forma dinámica y las anunciará a través de BGP al enrutador BGP denominado «BORDA». En este escenario, el ejemplo de ataque es un ataque de amplificación DNS. Esto significa que la red está recibiendo un gran volumen de paquetes UDP puerto 53 que en realidad no necesita para que el ISP funcione con normalidad. El ataque llena el circuito entre el ISP y los operadores y deja la red inoperativa. Cuando el atacante decide lanzar el ataque, el ISP puede utilizar Made4Flow para generar una ruta BGP FlowSpec exclusiva para paquetes UDP del puerto 53 y anunciarla al enrutador BGP de borde, el cual puede convertir dicha ruta en un filtro de cortafuegos en sus interfaces de comunicación con los operadores. Y entonces esto bloquea los paquetes de amplificación DNS en el borde de la red del ISP y también en el operador (si el operador soporta sesiones FlowSpec), pero permite que el tráfico legítimo siga llegando. En primer lugar, vamos a analizar la configuración de la sesión BGP FlowSpec en el router BGP BORDA con Made4Flow, suponiendo que el router ya está configurado para el enrutamiento unicast BGP normal (sesión BGP normal para anunciar rutas Blackhole o Mitigation/Scrubbing Center). Para configurar una sesión BGP FlowSpec en dispositivos Juniper, utilizamos los siguientes comandos: Buenas prácticas: Existen buenas prácticas para proteger esta solución. Tanto las rutas BGP FlowSpec como los filtros de cortafuegos resultantes que crean son recursos finitos en el router. Por lo tanto, el enrutador BGP BORDA puede filtrar las rutas entrantes para garantizar que no reciba un número excesivo de rutas ni rutas erróneas. Límite del prefijo: Así que lo primero que hay que hacer es establecer un límite de prefijos para las rutas BGP FlowSpec. Podría simplemente establecer un único límite de prefijo para las rutas inet unicast e inet flow; sin embargo, en este ejemplo se definirá un límite independiente para las rutas inet flow. Para que Made4Flow solo pueda enviar diez rutas BGP Flowspec cada vez, vamos a establecer el límite de prefijos en 10 (esta configuración debe ajustarse en función de cada caso concreto): Política de rutas : Lo siguiente que hay que hacer es aplicar una política de rutas entrantes. Esta política limitará el router a recibir prefijos que provengan del propio ISP con prefijos /24 a /32, que son los anunciados por Made4Flow. Añadamos también una Comunidad 64496:86 para que pueda identificar las rutas como rutas BGP FlowSpec. Para el resto de rutas, basta con filtrarlas en función de la asignación de rutas
