Configuración de L2VPN con SRv6 en Huawei: Prácticas con SRv6

¡Bienvenidos, estimados lectores y entusiastas de las redes! Si han llegado hasta aquí, es porque ya han superado la teoría del SRv6 (Segment Routing IPv6) en nuestros dos primeros artículos. Si aún no los ha consultado, le recomiendo que les eche un vistazo para no sentirse perdido como un paquete sin enrutador.Al fin y al cabo, nadie quiere ser el paquete perdido en la red, ¿verdad? En los primeros capítulos de nuestra saga sobre SRv6, nos hemos adentrado en los conceptos y la teoría que subyacen al protocolo. Si por casualidad no lo recuerda, eche un vistazo a esos artículos y repáselos: https://made4it.com.br/srv6-um-sucessor-do-mpls/https://made4it.com.br/srv6-um-sucessor-do-mpls-parte-2/ Ahora ha llegado el momento de ponerse manos a la obra y ver cómo funciona todo esto en la práctica. Es como construir un Halcón Milenario de LEGO después de leer el manual de instrucciones. ¡Montemos juntos esta estructura paso a paso! Preparen sus terminales, abróchense los cinturones y despegamos en este laboratorio de configuración básica de SRv6. Si está listo para pasar de la teoría a la práctica y dominar otra habilidad de Jedi de las redes, ¡venga conmigo! El laboratorio El objetivo del laboratorio es crear una topología sencilla con SRv6, utilizando ISIS como IGP y BGP para la señalización de la L2VPN. Utilizaremos el SID «END-DX2» para transportar la L2VPN dentro de nuestro entorno SRv6. En nuestro laboratorio estamos utilizando seis routers Huawei NE40E-M2K (V800R022C10SPC500), que actúan como nodos de la red de enrutamiento por segmentos IPv6. También contamos con dos routers Mikrotik (RouterOS 7.6), que simulan los puntos de acceso de la red. Topología física: Topología con direccionamiento IPv6: Topología con servicios: En estas topologías se aprecia que, sin duda, a alguien le gusta mucho el café. Sin más preámbulos, vayamos al grano. Guía de configuración Pan com leche. Tarea 1: Configurar IS-IS en todos los routers. En primer lugar, configuramos IS-IS como protocolo de enrutamiento de nivel 2 en todos los routers, habilitando IPv6. R1: R2: Configure el resto de routers siguiendo las instrucciones de la documentación. Tarea 2: Configurar interfaces de bucle invertido con soporte para IS-IS Configure las interfaces de bucle invertido en cada router con direcciones IPv4 e IPv6 y active el protocolo IS-IS. R1: R2: Siga las instrucciones de configuración de los demás routers tal y como se indica en la documentación. Tarea 3: Configurar redes de enlace compatibles con IS-IS Configure las interfaces Ethernet interconectadas entre los routers con direcciones IPv6 y active el protocolo IS-IS. R1 – Ethernet3/0/1: conectada al router R2. R1 – Ethernet3/0/3 – Conectada al router R3. Configure el resto de routers siguiendo las instrucciones de la documentación. Tarea 4: Habilitar SRv6 a nivel global Configure SRv6 en cada router, definiendo direcciones de origen y localizadores, e integrándolos en IS-IS R1: R2: Siga la configuración del resto de routers según la documentación. Tarea 5: Configurar BGP con soporte para L2VPN en los PE Configure el BGP con EVPN y soporte para L2VPN en los routers de borde (R1 y R6), creando sesiones BGP entre ellos. R1: R6: Tarea 6: Crear EVPN/EVPL y SID End.DX2 en los PE Configure las instancias EVPN/EVPL y asigne los localizadores SRv6 correspondientes en los routers de borde. R1: R6: Tarea 7: Vincular la EVPL a las interfaces con los CE Asigne las instancias EVPL a las interfaces conectadas a los routers de los clientes (CE). R1: R6: Tarea 8: Comprobaciones Una vez configurado, realizaremos algunas comprobaciones de las tecnologías implicadas: 8.1: Adyacencias del IGP. Confirme las adyacencias de IS-IS entre los routers. 8.2: Tabla de rutas del IS-IS. A continuación, la salida de la tabla de rutas del router R1: Algo interesante que hemos observado aquí son las rutas para los prefijos de «Locator» (/64). Es decir, el entorno ya conoce en su tabla de rutas el prefijo utilizado para el SRv6 de cada uno de los nodos de la topología 😊 8.3: Tabla BGP «EVPN» del router R1, para garantizar que existe una sesión entre el R1 y el R6, necesaria para el VPWS. Observamos que el R1 tiene establecida y operativa una sesión con el router R6. La tabla de enrutamiento del R1 también muestra un ESI para el R6 en el RD 200:1. Hasta aquí, todo está preparado para que el entorno utilice el VPWS. 8.4: EVPL en los routers R1 y R6. A continuación, la salida del router R1. En R1 vemos que la EVPL está activa (UP) y que el túnel utilizado para el tránsito de paquetes dentro de la red es del tipo «SRv6-BE» (Segment Routing IPv6 – Best Effort). Esto indica que la VPWS está establecida y operativa entre el head-end y el tail-end, y también que el túnel de transporte entre los PE utiliza SRv6. 8.5: Tabla local de SID del router R1: Al examinar la tabla local de SID asignados a R1, observamos no solo el SID configurado para el VPWS, sino también algunos SID de tipo «END» y de tipo «END.X». Lo que realmente nos interesa en este momento es el SID «End.DX2», que indica que cualquier cosa enviada a la dirección IPv6 2001:db8:1:1::a/128 se entregará en nuestra VPWS. Si tiene curiosidad por saber en qué consisten los demás SID, no se pierda las próximas entradas del blog 😀 8.6: Configuración y comunicación de los CE. Interfaces de los CE 1 y 2, con una dirección IPv4 para la comunicación. Tabla ARP del CE1 y un «ping» con destino al CE2, lo que confirma la conectividad entre los CE. LLDP de vecinos en el CE1, lo que muestra que la ruta es «transparente» desde el punto de vista de los CE. 8.7: Mientras el CE1 intercambia «pings» con el CE2, una captura de paquetes en la interfaz del router R1 con destino al resto de la red SRv6 muestra el siguiente resultado: Los paquetes de EVPN se encapsulan y, al enviarse a la red SRv6, la «dirección de destino» pasa a ser 2001:db8:6:6::A, siendo este el «SID» END.DX2. Lo más interesante de SRv6 es que este paquete

Comparar proveedores

En este artículo compararemos algunos dispositivos Ufispace con Huawei. Vamos a cubrir aquí 4 equipos, siendo: – Ufispace S9510-28DC Disaggregated Cell Site Gateway Router – Huawei S6730-H24X6C Switch – Ufispace 9600 Open Aggregation Router – Huawei NE8000 M4 Router Elegimos modelos similares en cuanto a número de puertos, capacidad de tráfico y funcionalidades. Tanto Huawei como Ufispace tienen muy buenas soluciones para los ISPs, con equipos que soportan protocolos como OSPFv2/v3, IS-IS, BGP, MPLS, SR MPLS, SRv6, VXLAN, entre otros. Huawei es una marca china muy conocida entre los proveedores de servicios de Internet (ISP) por sus soluciones de enrutamiento y conmutación, con equipos como los routers Huawei NE40 y NE8000, y los conmutadores S5700 y S6700, entre otros. Cuenta con una amplia gama de productos para satisfacer las necesidades de los ISP. Ufispace, de Taiwán, tiene una solución completa para conmutadores y enrutadores, y se presenta con un concepto de «Red Abierta», lo que significa que el usuario puede decidir qué software de gestión instalar en el hardware, como Ocnos de IP Infusion, que es un software maduro con todas las funcionalidades de enrutamiento que necesitan los ISPs. Empecemos hablando del router Huawei NE8000 M4. Es un router modular que viene con las siguientes características: – 16G de RAM – CPU Six Core – Viene con 4 puertos combo 100G, que pueden modificarse mediante configuración para utilizar puertos 10G; – Admite hasta 4 tarjetas de expansión; – Admite hasta 12 puertos 100G; – Capacidad de conmutación 2,4 Tbps Es un router muy utilizado por los ISP como router BGP, que admite 25 millones de rutas en la RIB y 4 millones en la FIB. También se utiliza ampliamente como concentrador PPPoE o IPoE BNG, soportando hasta 64.000 abonados. Por otro lado, contamos con un router Ufispace S9600-72XC, que presenta las siguientes características: – 32G de RAM; – CPU Octa Core; – Incluye 64 puertos 1/10/25G SFP28; – 8 puertos de 4/100G QSFP28; – Capacidad de conmutación 2,4 Tbps Ufispace es una marca muy buena que se ha hecho un nombre en el mercado de los ISP’s. Este modelo en concreto admite 20 millones de rutas en la RIB y unos 4 millones en la FIB, y puede utilizarse muy bien como router de borde. Y como es una White Box (puedes elegir un sistema operativo), puede utilizarse como BNG. Para más detalles sobre BNG en Ufispace, te sugiero que leas el artículo Utilizar OpenBNG para construir redes de banda ancha resistentes – https://www.ufispace.com/company/blog/openbng-resilency-models A continuación encontrarás una tabla comparativa con algunas de las características de cada modelo de router: Ahora hablemos de los interruptores. Hagamos también una breve comparación entre el Huawei S6730-H24X6C y el Ufispace S5910-28DC. Empezamos comprobando el conmutador Huawei S6730-H24X6C, que viene con unas cuantas características: – 4G de RAM – CPU de cuatro núcleos – Viene con 24 puertos 10G; – 6 puertos de 40/100G; – Capacidad de conmutación 1,68 Tbps Los conmutadores de Huawei son bien conocidos y ampliamente utilizados en los ISPs para funciones de acceso y agregación en redes MPLS. Es un conmutador con una buena capacidad de tráfico e incluso se utiliza en algunos casos para BGP para cajas CDN como Google, Netflix y FNA. Por otro lado, tenemos el conmutador Ufispace S5910-28DC, que viene con características similares: – 8G (estándar) o 16G (Premium) de RAM; – CPU Quad Core (estándar) u Octacore (premium); – Viene con 24 puertos 10G/25G; – 2 puertos 40/100G; – 2 puertos de 100/400G; – Capacidad de conmutación 800 Gbps Se trata de un conmutador que está ganando notoriedad por tener puertos de 400G, y puede muy bien utilizarse en la red troncal MPLS en las funciones P/PE, y en la función BGP, ya que admite 3,5 millones de rutas en la RIB y 1,2 millones en la FIB. A continuación se muestra una tabla comparativa entre los interruptores: Conclusión: En este artículo hemos visto una breve comparación entre algunos modelos de Huawei y Ufispace. Elegimos modelos similares en cuanto a capacidad de tráfico, número de puertos y funcionalidades. Ambos dispositivos tienen interoperabilidad de protocolos y pueden desplegarse juntos, lo que los convierte en grandes opciones para las redes de los ISP.

Seminario web: Actualización de ZABBIX 7.0

Ya está aquí la versión 7.0 de Zabbix y, con ella, está cobrando importancia un nuevo concepto de monitorización: la monitorización sintética. El monitorizado sintético tiene como objetivo ampliar aún más la visibilidad de la que disponemos al realizar el monitorizado de páginas y aplicaciones web; se acabó lo de recibir únicamente un error HTTP con el código XYZ o un comentario del tipo «Ah, pero tal recurso tarda mucho en cargarse», ahora, junto con esta información, podemos añadir una captura de pantalla que muestre cómo se veía realmente la página en el momento en que se produjo el problema y ver de verdad lo que nuestro cliente estaba viendo. Este seguimiento es posible gracias a una pizca de JavaScript y a otra buena dosis de Selenium WebDriver. WebDriver – Selenium es una herramienta de automatización para realizar pruebas en aplicaciones web. Permite controlar un navegador web mediante programación (aquí es donde entra en juego JavaScript), interactuando con los elementos de la página, rellenando formularios, haciendo clic en botones y comprobando el comportamiento de la aplicación. Es ideal para pruebas automatizadas y repetitivas. Para utilizar esta monitorización en Zabbix, necesitaremos trabajar en dos frentes: el primero es en el propio Front-End, donde se realiza la configuración del host, se vincula la plantilla y se configuran las macros según lo que desee monitorizar; esta es la parte sencilla. La segunda parte se lleva a cabo en la CLI: debemos indicar a Zabbix cuál es la URL de WebDrive que va a utilizar y debemos instanciar los colectores que realizarán la monitorización sintética. Pasemos a la práctica, pues. En primer lugar, asegúrese de que dispone de la versión 7.0 de Zabbix; debido a diversas dependencias de la arquitectura de Zabbix, esta supervisión solo funcionará a partir de la versión 7.0. A continuación, deberá disponer de la plantilla en su Zabbix, que puede adquirirse aquí: https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/app/website_browser Por lo tanto, basta con crear un host, vincular la plantilla y rellenar las macros heredadas del host de la siguiente manera: Una vez introducidos los archivos macro y creado el elemento, ahora debemos acceder a la interfaz de línea de comandos (CLI) del servidor para finalizar la instalación. En la interfaz de línea de comandos (CLI) del servidor, debemos editar el archivo zabbix_server.conf e introducir las siguientes variables (por lo general, se encuentran al final del archivo) WebDriverURL = ¿Cuál es la URL que permite acceder a Selenium? Y StartBrowserPollers = Número de pollers que se utilizarán para recopilar los elementos de tipo navegador Si instala Selenium de forma local, puede dejar la variable configurada de la siguiente manera: WebDriverURL=http://localhost:4444 En cuanto al número de pollers, podemos empezar con 1 e ir aumentándolo según sea necesario: StartBrowserPollers=1 Una forma sencilla de instalar Selenium es utilizarlo mediante un contenedor; para ello, primero debemos instalar Docker Engine en nuestro servidor y, a continuación, configurar el contenedor de Selenium. Para ello, podemos utilizar dos comandos: Este primer comando es un script de instalación automática de Docker Engine en su servidor. Y el segundo comando sirve para configurar el contenedor de Selenium en su servidor. Para consultar el estado del contenedor, puede utilizar el comando Una vez configurado el contenedor, basta con reiniciar el servicio del servidor Zabbix para que lea las nuevas variables y pueda utilizar Selenium y llevar a cabo la supervisión. Volviendo al front-end, podemos acceder al panel de control del servidor que acabamos de supervisar, y el resultado esperado es: Explicación de cada uno de los aspectos objeto de seguimiento: Gráficos y estadísticas Cada gráfico muestra la evolución de las métricas a lo largo del tiempo, lo que permite identificar patrones y posibles cuellos de botella en el rendimiento. Los valores mínimos (mín.), medios (med.) y máximos (máx.) ayudan a comprender la distribución de las métricas: Estas métricas son fundamentales para supervisar el rendimiento del sitio web e identificar problemas que puedan afectar a la experiencia del usuario.

SRv6: ¿un sucesor del MPLS? – Parte 2

En nuestro último artículo sobre SRv6, elaborado por nuestros expertos, comentamos las ventajas de SRv6 en comparación con MPLS; si aún no lo ha leído, haga clic en el siguiente enlace: https://made4it.com.br/srv6-um-sucessor-do-mpls/ En este artículo, abordaremos el funcionamiento de SRv6, compararemos los protocolos del plano de control, hablaremos del plano de datos y también analizaremos las principales diferencias entre SRv6 y MPLS. MPLS es una tecnología que sigue utilizándose mucho en la actualidad, sin embargo, sus características de funcionamiento son muy diferentes a las de SRv6, que se concibió no solo como una evolución de MPLS, sino también para simplificar en gran medida el funcionamiento de las redes de transporte y afines, adaptándolas a las necesidades del futuro y reduciendo al mismo tiempo la complejidad de las redes. Comparación entre SRv6 y MPLS. Antes de abordar el funcionamiento del SRv6, analicemos las principales diferencias entre este y el consolidado MPLS. En la tabla que figura a continuación podemos observar el «antes» (before) y el «ahora» (now), lo que ilustra la evolución y la simplificación del MPLS hacia el SRv6: Fuente: Serie de libros electrónicos «IP Network»: SRv6, Huawei, Lanjun Luo En MPLS (antes) observamos una «pila» de protocolos y tecnologías. Todo ello se simplifica en SRv6, donde conseguimos ofrecer las mismas funcionalidades que MPLS, pero sin depender de los protocolos de señalización de «etiquetas» (ldp/rsvp-te). También se simplifican los tipos de servicios que, en SRv6, utilizan EVPN y su excelente escalabilidad para proporcionar acceso y transporte de servicios en la red. Además de todo ello, SRv6 satisface asimismo las necesidades actuales de programabilidad y escalabilidad que antes no eran posibles en MPLS. El SRv6 no se limita a las redes «metro» ni a los transportes en entornos «del futuro» (5G/IoT); como se puede observar en el ejemplo siguiente, en la sección «before» necesitamos IP/VXLAN para el transporte de información dentro de DC1 y DC2, mientras que en la red troncal utilizamos MPLS con LDP, TE o SR(MPLS). A continuación, tenemos el «After» de la implementación de SRv6 con EVPN, que muestra la simplificación del escenario. Con SRv6 y EVPN, hemos logrado ofrecer lo que antes solo era posible con una «pila» de diversos protocolos, lo que suponía una carga para el procesamiento y aumentaba la complejidad del entorno. Fuente: Serie de libros electrónicos «IP Network»: SRv6, Huawei, Lanjun Luo Además de estas ventajas, dado que SRv6 utiliza componentes nativos de IPv6, esto resulta de gran ayuda en los procesos de migración. Hoy en día, prácticamente todos los equipos admiten el enrutamiento de encabezados IPv6, por lo que la migración de un entorno heredado (MPLS) a esta nueva tecnología puede llevarse a cabo de forma orgánica y gradual, protegiendo la inversión y garantizando tiempos de inactividad mínimos en el entorno. Fuente: Implantación del Segment Routing IPv6 (SRv6) en VIVO – Nelson J. dos Santos Junior – Foro Brasileño de IPv6 2023. El SRv6 y su simplificación constituyen un gran aliado para la integración de grandes dominios de enrutamiento (como, por ejemplo, en los casos de empresas adquiridas por otras, en los que dichas redes deben comunicarse e interoperar). Con SRv6 logramos integrar dichas redes mediante simplificaciones de enrutamiento sencillas, mientras que en MPLS se requería una planificación exhaustiva y el uso de técnicas como InterAS OPTION A, B y C. Funcionamiento de SRv6: Sabemos que en MPLS utilizamos etiquetas entre las capas 2 y 3 que determinan cómo debe enrutarse el paquete en una red; sin embargo, es necesario que todos los equipos que formen parte de la ruta tengan habilitados los protocolos necesarios (IGP/LDP/RSVP). En la imagen siguiente podemos ver las etiquetas MPLS de un paquete capturado: Fuente: SINGH, Arshdepp. «Fun with Revisiting MPLS basics». LinkedIn, 23 de mayo de 2020. Disponible en https://www.linkedin.com/pulse/fun-revisiting-mpls-basics-capturing-labels-wireshark-arshdeep-singhConsultado el: 22 de abril de 2024. Por su parte, el SRv6 utiliza una extensión de la cabecera IPv6 denominada «Segment Routing Header» (SRH) para insertar direcciones IPv6 denominadas SID (identificadores de segmento) con el fin de identificar el segmento de enrutamiento IPv6: Fuente: DayOne Intro SRv6, Juniper, HEGDE, Shaddha y otros . El SID representa un segmento específico dentro de un segmento de dominio de enrutamiento; utiliza una dirección IPv6 de 128 bits, también conocida como «SRv6 Segment» o «SRv6 SID». En comparación con el MPLS, podríamos decir que el SID es la «etiqueta» que delimita la ruta de transporte o el servicio; sin embargo, en SRv6 lo transformamos en una dirección IPv6 única que puede enrutarse de forma nativa a través de IPv6 (¿mucho más sencillo, no? 😉) Fíjese en la estructura de un SID: Fuente: Serie de libros electrónicos «IP Network»: SRv6, Huawei, Lanjun Luo Localizador: Es la primera parte del SID, que utiliza más bits. Desempeña la función de localización, representando la dirección de un nodo SRv6 específico. Una vez configurado en un equipo, se propaga por todo el dominio SRv6 mediante un IGP, lo que permite que otros equipos localicen ese nodo concreto. Función: Es una parte del SID que designa una función SRv6 que se ejecuta localmente en un nodo específico. Normalmente lo denominamos «programa». Se trata de una instrucción destinada a dirigir los paquetes dentro de la red. En este SID, podemos indicar, por ejemplo, una EVPN-VPWS o una L3VPN específica de este nodo. Dado que el SID se encuentra dentro del bloque «locator», el cual es propagado por el IGP (ISIS/OSPF) dentro del dominio SRv6, toda comunicación dirigida a este SID termina específicamente en este «nodo». Una comparación con el MPLS que podemos establecer aquí es la de una «etiqueta» utilizada para delimitar un servicio como L2VPN a través de targeted-ldp. En SRv6, basta con implementar en el head-end y el tail-end las instrucciones SID para el servicio y ya está. Los «nodos» que deben interpretar los SID encapsularán y desencapsularán los datos en función de ellos, mientras que el resto de la red se limita a enrutar los paquetes IPv6 basándose en el IGP. Argumento (opcional): Se utiliza para definir información relevante, como el «flujo de paquetes»

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!

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

¿Qué es un ASN y cuáles son sus ventajas?

Hoy vamos a hablar sobre el ASN (Número de Sistema Autónomo) y las ventajas que te ofrece. ¿Qué es ASN? Un Número de Sistema Autónomo (ASN) es un grupo de redes de direcciones IP gestionadas por uno o más operadores de red que tienen una política de enrutamiento clara y única. Cada Sistema Autónomo ( AS) tiene un número asociado que se utiliza como identificador del Sistema Autónomo cuando se intercambia información de enrutamiento externo. Los protocolos de enrutamiento externos, como BGP, utilizan el (ASN ) para intercambiar información de enrutamiento con otros (ASN). Los ASN pueden encontrarse en dos formatos: 2 bytes y 4 bytes. – Un ASN de 2 bytes es un número de 16 bits. Este formato proporciona 65.536 ASN (de 0 a 65.535). De estos ASN, la Autoridad de Asignación de Números de Internet (IANA) ha reservado 1.023 de ellos (de 64.512 a 65.534) para uso privado. – Un ASN de 4 bytes es un número de 32 bits. Este formato proporciona 2³² o 4 294 967 296 ASN (del 0 al 4 294 967 295). La IANA ha reservado un bloque de 94 967 295 ASN (del 4200000000 al 4294967294) para uso privado. Para disponer de un sistema autónomo, debe solicitar un número de sistema autónomo (ASN) al Registro Regional de Internet (RIR) correspondiente a la región en la que se encuentra la organización. En Brasil, el organismo competente es el LACNIC. Además, es necesario configurar los dispositivos de red de acuerdo con las políticas de enrutamiento definidas por la organización, que pueden consultarse en las páginas web de las instituciones. Consulte nuestro artículo sobre «¿Cómo solicitar un ASN para su proveedor?». Actualmente hay cinco RIR en funcionamiento: 1 – American Registry for Internet Numbers (ARIN): Norteamérica y parte del Caribe; 2 – Centro de Coordinación de Redes IP Europeas (RIPE NCC): Europa, Oriente Medio y Asia Central; 3 – Centro de Información de Redes de Asia y el Pacífico (APNIC): Asia y el Pacífico; 4 – Registro de Direcciones de Internet para América Latina y el Caribe (LACNIC): América Latina y parte del Caribe; 5 – Centro Africano de Información sobre Redes (AfriNIC): África. ¿Sabía usted que no solo los proveedores de servicios, las empresas de telecomunicaciones y los proveedores de acceso a Internet deben ser sistemas autónomos? Otros tipos de empresas también deben utilizarlos, como: bancos, universidades, aseguradoras, productoras, portales de noticias y grandes empresas, ya que el acceso a Internet es fundamental para su actividad principal y el ASN puede garantizar que estos servicios estén siempre disponibles y sean seguros. Cuando una organización se convierte en AS, dispone de un ASN, Autonomous System Number -número que identifica el conjunto de IPs que posee la organización-, crucial para identificar los sistemas y permitir el intercambio de información y rutas entre ellos. ¿Cuáles son las ventajas de tener un ASN? Solicitar y obtener un ASN es esencial para que una organización, especialmente un proveedor de servicios de Internet, tenga pleno control sobre su infraestructura de red, optimice el rendimiento, mejore la redundancia y la seguridad y participe activamente en el encaminamiento global de Internet. Ofrecemos soporte completo y consultoría para la solicitud e implementación del ASN en su red. Ponte en contacto para saber cómo podemos ayudarte.