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»
Configuración L3 en equipos Ufispace
Protocolos de enrutamiento estático y dinámico, OSPF y BGP Vamos a presentar la configuración de la Capa 3 (L3) en equipos Ufispace, tanto estática como dinámica, utilizando protocolos como OSPF (Open Shortest Path First) y BGP (Border Gateway Protocol). A continuación encontrarás una guía para configurar estas funciones. Para iniciar la configuración, tienes que acceder al dispositivo Ufispace a través de la interfaz de línea de comandos (CLI). Demostraremos el acceso mediante ssh, pero también puede hacerse mediante conexión serie y telnet. Configuración directamente en la interfaz: Ejemplo de configuración de la subinterfaz vlan. Utilizando la vlan 4 como ejemplo. Para configurar el enrutamiento estático, añade rutas estáticas a la configuración: OSPF es un protocolo de enrutamiento dinámico muy utilizado en redes corporativas. Para configurar OSPF en el dispositivo Ufispace: V4 V6 Añada las interfaces que participan en OSPF mediante los siguientes comandos: Para comprobar que los ajustes son correctos y funcionan: Por último, guarda la configuración para asegurarte de que los cambios se conservan tras un reinicio: Conclusión Configurar el enrutamiento estático y dinámico en los equipos Ufispace implica pasos específicos para definir direcciones IP en las interfaces, añadir rutas estáticas y configurar protocolos de enrutamiento como OSPF y BGP. Siguiendo esta guía, podrás configurar un encaminamiento eficaz y sólido en tu red. Al finalizar esta guía, estará preparado para configurar el enrutamiento estático y dinámico en los equipos de Ufispace, utilizando protocolos como OSPF y BGP para garantizar una red eficiente y robusta. Siga los pasos con atención y, en caso de dudas, consulte la documentación oficial o solicite ayuda 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. Además, somos socios oficiales de Padtec, empresa que comercializa los routers UfiSpace. Póngase en contacto con nosotros para obtener más información y optimizar su red con soluciones profesionales. ¡Hasta luego! https://made4it.com.br/
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: OcNOS>enable 2 – Entra en el modo de configuración: OcNOS#configure terminal 3 – Cambia la contraseña del usuario y crea un nuevo usuario, como se muestra en el ejemplo: OcNOS(config)#username ocnos password S3nh4-Super-F0rt3 OcNOS(config)#username made4it password S3nh4-Super-F0rtissima OcNOS(config)#username made4it role network-admin 4 – Alterar o nome do equipamento: hostname UFISPACE-01 5 – Aplica la configuración: OcNOS(config)#commit 6 – Por último, guarda la configuración: OcNOS(config)#do write Building configuration… [OK] 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: OcNOS(config)#interface eth0 2 – Asigne la gestión de VRF a la interfaz: OcNOS(config-if)#ip vrf forwarding management 3 – Configura la IP de gestión y la descripción de la interfaz: OcNOS(config-if)#ip address 10.10.0.2/30 OcNOS(config-if)#description GERENCIA 4 – Aplica los ajustes y guarda: OcNOS(config)#commit OcNOS(config-if)#do write Building configuration… [OK] 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: OcNOS(config)#ip route vrf management 0.0.0.0/0 10.10.0.1 eth0 description ROTA DEFAULT OcNOS(config)#commit Para validar la ruta por defecto en la VRF, podemos utilizar el comando OcNOS#show ip route vrf management Por defecto, ssh ya está activado en la gestión de vrf, si quieres desactivarlo, utiliza el comando: OcNOS(config)#no feature ssh vrf management Para activar SSH en la vrf main, utiliza el comando OcNOS(config)#feature ssh OcNOS(config)#commit 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: OcNOS(config)#ip access-list admin OcNOS(config-ip-acl)#10 permit tcp 10.10.0.0/30 any eq ssh OcNOS(config-ip-acl)#20 permit tcp 172.16.0.0/24 any eq ssh OcNOS(config-ip-acl)#65000 deny any any any OcNOS(config-ip-acl)#commit Ahora tenemos que aplicar la ACL a la línea vty: OcNOS(config)#line vty OcNOS(config-all-line)#ip access-group admin in OcNOS(config-all-line)#commit OcNOS(config-all-line)#do write Building configuration… [OK] 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: UFISPACE-01(config)#snmp-server enable snmp vrf management UFISPACE-01(config)#snmp-server community made4it vrf management UFISPACE-01(config)#commit En caso de que se utilice «vrf main» para realizar la supervisión, basta con utilizar los siguientes comandos: UFISPACE-01(config)#snmp-server enable snmp UFISPACE-01(config)#snmp-server community made4it-vrf-main UFISPACE-01(config)#commit 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: UFISPACE-01(config)#feature ntp vrf management UFISPACE-01(config)#ntp enable vrf management UFISPACE-01(config)#ntp server 200.160.7.186 vrf management UFISPACE-01(config)#commit Para comprobar los pares NTP, utilizamos el comando: #show ntp peers ———————————————————– Peer IP Address Serv/Peer ———————————————————– 200.160.7.186 Server (configured) #show ntp peer-status Total peers : 1 * – selected for sync, + – peer mode(active), – – peer mode(passive), = – polled in client mode remote refid st t when poll reach delay offset jitter ============================================================================== * 200.160.7.186 LOCAL(0) 7 u 14 32 37 0.194 -4.870 3.314 Ahora tenemos que corregir la zona horaria para que la hora sea correcta: UFISPACE-01(config)#clock timezone Sao_Paulo UFISPACE-01(config)#commit 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.
Actualizaciones – Made4Flow, Made4Graph y Made4OLT – Marzo de 2024
Made4Flow – Versión 2.7.0 Añadidos: Visualización del router: Visualización de interfaces: Visualización del prefijo: Barra horizontal: Sector: Polar: Últimos datos: Lista de ASN: Lista de protocolos: Lista de aplicaciones: Mapa: Cambios: Correcciones: ¿Aún no conoce Made4Flow? Made4Graph – Versión 2.4.4 Añadidos: Correcciones: ¿Aún no conoce Made4Graph? Made4OLT – Versión 1.3.1 [Beta] Añadidos: Modificaciones: Correcciones: ¿Aún no conoce Made4OLT?
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.
