Podcast de Redes de Eduardo Collado

El Jueves tuve la suerte de poder compartir en el Esnog 35 que se celebró en la Universidad Carlos III de Madrid una presentación sobre SCION y hoy la grabo en formato podcast por si os es de interés.

Internet funciona de milagro. BGP lleva décadas aguantando el peso de la interconexión global sobre un modelo que confía en que los demás se van a comportar bien. Y la mayoría de las veces funciona. Pero si hoy tuviéramos que construir Internet desde cero, sabiendo lo que sabemos, no lo haríamos igual. SCION es una propuesta seria en esa dirección: caminos explícitos, verificación criptográfica y dominios de confianza bien definidos. No es el futuro garantizado de Internet, pero sí una demostración de que muchas de las limitaciones que damos por inevitables no lo son en absoluto.

Aquí os dejo la presentación por si os interesa. SCION_Presentacion

Ya habíamos hablado de ECH en 2020 cuando era todavía un draft, pero ya por fin tenemos el RFC 9849 que lo describe ya de verdad. ECH ya no es un draft: desde marzo de 2026 es el RFC 9849 de la IETF, en categoría Proposed Standard.

Aunque mucha gente da por hecho que con HTTPS ya va todo cifrado desde el principio, la realidad es que no era exactamente así. Durante años, en el arranque de la conexión TLS seguían viajando en claro algunos datos bastante sensibles, como por ejemplo el nombre del servidor al que te querías conectar. Es decir, que la conversación luego iba protegida, sí, pero al principio todavía ibas dejando pistas de más.

Ahí es donde entra ECH, que significa Encrypted Client Hello. La idea es cifrar precisamente esa parte sensible del saludo inicial para que no vaya expuesta por la red. Dicho de forma sencilla, es una manera de evitar que en ese primer “hola” entre cliente y servidor se revele información que no debería estar a la vista. Es una mejora importante de privacidad, porque tapa una fuga que llevaba años ahí y que quedaba un poco fea en algo que, en teoría, ya considerábamos seguro.

El mecanismo, además, está bastante bien pensado. ECH separa el saludo en una parte visible y otra cifrada: una especie de sobre por fuera y contenido real por dentro. A eso se suman detalles como el uso de HPKE, que significa Hybrid Public Key Encryption, el padding para que el tamaño de los mensajes no delate información, y técnicas como GREASE, que ayudan a que el tráfico con ECH no destaque demasiado frente al resto. Vamos, que no se limita solo a cifrar, sino que intenta hacerlo bien.

Ahora bien, también conviene decir lo que ECH no hace. No convierte tu conexión en invisible ni arregla toda la privacidad de Internet de golpe. Por ejemplo, si el DNS no va cifrado, sigues dejando pistas importantes por el camino. Y la IP también puede seguir dando bastante contexto. O sea, ECH resuelve una parte muy concreta y muy relevante del problema, pero no borra todo lo demás.

En resumen: ECH no reinventa Internet ni pone todo patas arriba, pero sí corrige una fuga bastante evidente en el arranque de las conexiones TLS. Y solo por eso ya merece la pena prestarle atención, porque era una de esas piezas que faltaban para que la privacidad en HTTPS estuviera un poco más a la altura de lo que la mayoría damos por hecho.

Foto de cottonbro studio: https://www.pexels.com/es-es/foto/oscuro-internet-tecnologia-efecto-desenfocado-5473951/

Hoy os cuento en detalle qué es EasyPodcast, un gestor de podcasts que he creado desde cero, que es gratuito y de código abierto, y que me permite publicar este podcast en mi propio servidor sin depender de ninguna plataforma.

La idea nació de una pregunta incómoda: ¿quién es el dueño real de tu podcast cuando lo tienes en Anchor, iVoox o Buzzsprout? La respuesta, en la mayoría de los casos, es que ellos tienen tus datos, tu feed y tu contenido. Y pueden cambiar las reglas cuando les dé la gana.

EasyPodcast resuelve eso. Se instala en cualquier hosting básico, genera tu feed RSS automáticamente, te da una web pública con modo oscuro incluido, panel de administración limpio, SEO automático, copias de seguridad con un clic y hasta importación desde otras plataformas. Todo gratis, sin límite de episodios, sin sorpresas.

También os explico lo que EasyPodcast no hace, y por qué. No tiene estadísticas de descargas por capítulo ni datos por usuario. No es una carencia: es una decisión. Creo que la privacidad de quien escucha importa, y no voy a montar un sistema de rastreo para saber quién descarga qué. Punto.

Si buscas independencia, control total sobre tu contenido y respeto hacia tus oyentes, EasyPodcast está hecho para ti. Si necesitas un dashboard con métricas detalladas, hay otras opciones y en el episodio también hablo de ellas con honestidad.

Todo el código está en https://github.com/educollado/EasyPodcast y la web del proyecto en https://www.easypodcast.eu.

Lo primero: no quiero arrancar este episodio sin dar las gracias como se merece a IPng Networks y, en especial, a Pim Van Pelt. Tuve la suerte de compartir un café con él en el ESNOG de Barcelona hace un par de años, y te das cuenta en cinco minutos de que no solo sabe una barbaridad, sino que además tiene la capacidad de explicar cosas muy complejas de forma clara y honesta. Su trabajo y su manera de compartir conocimiento han ayudado a muchos a entender qué demonios está pasando realmente dentro del plano de datos moderno. Este episodio, en buena parte, nace de esa base de conocimiento que otros han currado antes.

Y ahora sí, como dice Felipe, vamos al lío.

Este episodio es la primera parte de un análisis bastante serio —pero contado como lo contaría alguien que lleva más de veinte años en telecomunicaciones— sobre algo que casi todos hemos sufrido alguna vez: tienes un servidor Linux con buena CPU, buena RAM, tarjetas modernas… y de repente empieza a perder paquetes. O aparece jitter. O la latencia hace cosas raras. Y miras la CPU global y está al 20 %. Y piensas: “¿Pero qué está pasando aquí?”

La clave no está en la potencia bruta. Está en el modelo de procesamiento.

El stack de red del kernel Linux está pensado para ser generalista. Tiene que servir para servidores web, bases de datos, firewalls, virtualización, mil aplicaciones a la vez. Cada paquete que entra genera interrupciones, estructuras dinámicas, validaciones, decisiones del scheduler… Todo eso funciona muy bien cuando la carga es razonable.

Pero cuando empiezas a hablar en serio de paquetes por segundo, la historia cambia. No tanto por los gigabits, sino por los pps. Empiezan las invalidaciones de caché, la carga se concentra en una o dos colas, aparecen microbursts que no se absorben bien y el sistema empieza a comportarse de forma poco predecible. No es que Linux “no pueda”. Es que no está optimizado exclusivamente para forwarding masivo.

Aquí es donde entra el enfoque vectorial.

En vez de tratar cada paquete como si fuera un evento único que requiere atención inmediata, el modelo vectorial los agrupa en lotes y los procesa en bloque. Se reducen transiciones, se mantiene la caché caliente y la CPU hace lo que mejor sabe hacer: ejecutar el mismo código repetidamente sobre datos similares.

En lugar de vivir a base de interrupciones, los cores dedicados al plano de datos hacen polling continuo. Sí, están preguntando todo el rato si hay trabajo. A primera vista parece poco eficiente, pero cuando te mueves en millones de paquetes por segundo, el coste del polling es mucho menor que el de gestionar millones de interrupciones.

Sobre esta idea se construye VPP, el Vector Packet Processor. Es un plano de datos en espacio de usuario que, apoyándose en DPDK, toma control directo de las interfaces de red. Organiza el procesamiento como un grafo de nodos: uno clasifica capa 2, otro analiza IP, otro hace el lookup en la FIB, otro reescribe cabeceras, otro aplica ACLs… y todo eso lo hace sobre vectores de buffers ya reservados en hugepages. No hay malloc por paquete. No hay estructuras que se creen y destruyan constantemente.

Y aquí ya nos metemos en terreno físico de verdad: cachés L1, L2, L3, predicción de saltos, TLB, hugepages… Esto no va solo de “configurar BGP”. Va de entender cómo funciona la CPU por dentro. Si ejecutas el mismo código sobre datos contiguos, la caché trabaja a tu favor. Si accedes a memoria del otro socket NUMA, el coste sube. Si no alineas bien colas RSS con workers, puedes saturar un core mientras el de al lado está mirando.

Todo cuenta: CPU, memoria, NIC y cómo lo configuras.

Otro punto importante es que esto no elimina el kernel. Lo separa. El forwarding masivo lo hace el motor vectorial en el plano de datos, pero el plano de control sigue en Linux. Bird o FRR gestionan BGP, OSPF, lo que toque. La sincronización entre ambos mundos se hace por Netlink: el kernel mantiene el RIB y VPP ejecuta la FIB real.

Eso funciona muy bien… siempre que lo entiendas. En una reconvergencia gorda, con miles de rutas BGP entrando o saliendo, puedes generar una tormenta de mensajes Netlink. Si no dimensionas bien los buffers o no separas cores correctamente, puedes tener problemas de sincronización. No es magia. Es ingeniería.

También se habla de cosas muy de campo: caída de enlaces físicos, BFD reaccionando en milisegundos, microbursts, tráfico de paquetes mínimos que te revientan el pps aunque el Gbps no sea alto, y RSS repartiendo mal la carga.

Aquí aparece una métrica que me parece brutal: el “vector size”. Si ves que el promedio se acerca a 256 buffers por llamada, sabes que ese worker está cerca del límite. Mucho más útil que mirar la CPU global y quedarte tranquilo. Es una manera mucho más honesta de saber dónde estás.

A partir de ahí, el dimensionamiento cambia completamente. Dejas de hablar de “este servidor es más potente” y empiezas a hablar de ciclos por paquete. Si el forwarding básico consume X ciclos y añadir NAT o VXLAN suma Y más, puedes estimar cuántos millones de paquetes por segundo puede manejar cada core. Eso ya no es intuición, es matemática.

También se compara de forma honesta con ASIC. Los ASIC siguen siendo impresionantes. Para ciertas escalas y latencias mínimas, son imbatibles. No desaparecen ni mucho menos. Pero el espacio intermedio ha cambiado mucho. Hoy un servidor bien diseñado puede hacer cosas que hace diez o quince años solo estaban al alcance de hardware muy especializado.

La diferencia es que aquí tienes flexibilidad software. Puedes evolucionar, automatizar, versionar configuración, integrar métricas con Prometheus, tratar el router como infraestructura como código.

Y eso cambia la mentalidad.

El plano de datos deja de ser una caja negra. Empiezas a medir ciclos por nodo, vectores procesados, presión de buffers. Dejas de sobredimensionar “por si acaso” y empiezas a dimensionar con números reales.

No es una solución mágica ni sirve para todo el mundo. Requiere entender CPU, hugepages, NUMA, afinidad de cores y cómo se comporta el sistema bajo carga real. Pero si te dedicas a esto desde hace años y te gusta entender lo que pasa de verdad debajo del capó, es difícil no interesarse.

En el fondo, este episodio no va solo de reenviar más tráfico. Va de entender cómo se mueven los paquetes dentro de una máquina moderna, por qué a veces todo parece ir bien hasta que deja de irlo, y cómo rediseñar el plano de datos para que, cuando aprietes de verdad, el sistema responda de forma estable y predecible.

Artículos de VPP en IPngNetworks: https://ipng.ch/s/articles/

Foto de Alex wolf mx: https://www.pexels.com/es-es/foto/carretera-coche-deportivo-deportes-de-motor-carrera-14401648/

Parece que el día en el que el modelo OSI ha dejado de ser sagrado ha llegado. El modelo OSI de 7 capas parecía escrito en piedra hasta que Ramana Kompella y Vijoy Pandey de Cisco han publicado el artículo Mind the semantic gap: A case for the 9-layer OSI model, un artículo rompedor donde proponen una ampliación del modelo OSI de 7 a 9 capas para solventar los problemas derivados de la brecha semántica entre cómo las redes transportan datos y cómo los sistemas modernos, especialmente los basados en IA, necesitan entender y operar sobre su significado y contexto.

Todo esto explicado de forma sencilla lo que nos dice es que el modelo OSI estaba diseñado para entregar la información entre un punto A y un punto B, y eso lo hace perfecto, pero hemos llegado a un punto donde además de entregar la información de A a B, y eso es cierto que lo hace muy muy bien, pero hay un pequeño detalle que nos falta.

El modelo OSI es muy bueno en entregar la información, pero al modelo OSI le da igual si el destino ha entendido el mensaje, si lo ha comprendido bien, como un cartero, entrega las cartas, pero no entra en si el receptor ha entendido bien el mensaje y si la información que ha obtenido es la que el emisor quería que el receptor entendiese.

Hoy estaba en el gimnasio escuchando un podcast llamado Network Break y mientras estaba haciendo ejercicio han comentado este tema y me he quedado con la copla, porque quiero mentir a nadie, me ha impactado muchísimo que el modelo OSI que fue publicado en 1984, imagino que muchos de los que estáis aquí ni siquiera habíais nacido, yo tenía 7 años entonces.

Para mi el modelo OSI estaba básicamente escrito en piedra, era inmutable y una verdad absoluta. El escuchar que el modelo OSI podría cambiar me ha dejado en shock, es verdad que todo cambia, pero el modelo OSI … a veces uno no está preparado para escuchar ciertas cosas, pero mentalidad abierta, ¿por qué no? así que me he puesto a investigar sobre el tema.

Hasta hace relativamente poco las comunicaciones se hacían por humanos, esos que tenemos carne, huesos y experiencia vital, no modelos que necesitan que todo esté perfectamente descrito.

Pero ahora es diferente, además de interactuar las personas interactúan esos entes generalmente conocidos por IAs. Hasta hace poco los agentes de IA actuaban de forma independiente, aislada, no se comunicaban con otros, pero ahora la cosa cambia, los agentes interactúan entre sí, agentes de diversos tipos, ya no son agentes iguales y tienen que ser capaces de comunicarse.

Cuando los agentes quieren comunicarse entre si surgen problemas y no porque los agentes no sean «listos» sino por otro tema más abajo, el problema es que las reglas de comunicación que disponen no dan la talla.

Antes de empezar con esto hay que definir dos conceptos, la sintaxis y la semántica, seguro que lo conoces, pero siempre va bien recordarlo.

Sintaxis

La sintaxis es la forma en la que se transmite la información. Son las reglas del formato: cómo se estructura un mensaje para que pueda ser leído.

La sintaxis dice cómo se escribe algo, no qué significa.

Ejemplo:

Semántica

La semántica es el significado de esa información. Es lo que realmente quiere decir el mensaje, más allá de que esté bien escrito.

La semántica dice qué significa algo y qué se espera que pase.

Ejemplo:

Hasta ahora en las comunicaciones no necesitaban trabajar con la semántica porque eso lo hacen los humanos de serie, pero claro, con las máquinas es diferente, ahora necesitamos también controlar la semántica.

Vamos a suponer que un agente envía un mensaje sintácticamente perfecto, pero el agente receptor no entiende bien el significado, la semántica, así que entran en bucles de aclaración que no terminan nunca:

Estos bucles de aclaración son muy caros en tiempo y recursos, además esto hace que al final el sistema se vuelva impredecible y que si algo sucede varias veces no siempre va a dar el mismo resultado, esto es terrible, depende del contexto de cada uno al final.

A esto le llamamos «brecha semántica«, y esto es la clave de todo. En el artículo se cita una frase que me parece fantástica sobre la Internet que tenemos diseñada a día de hoy ya que fue

«diseñada para mover bytes, no para mover intención, significado y estado compartido entre agentes«

El tema es que los humanos trabajamos con información en crudo y los agentes de IA trabajan con intención y significado y esa es la brecha que hay que cerrar y que se propone cerrar con esta modificación del modelo OSI.

Esta modificación es añadir las capas 8 y 9 al modelo. Es interesante añadir que aquí la solución no ha pasado por tirarlo todo y volver a empezar de cero, sino algo mucho más fácil que es aprovechar lo anterior y añadir lo que falta, de forma que lo anterior sigue siendo funcional.

La idea es añadir dos capas:

Capa 8: Comunicación de Agente (el cómo se comunican los agentes)

Capa 9: Semántica del Agente (el qué es lo que quieren decir)

La capa 8 (El cómo) estandariza la estructura de las conversaciones: sobres, intención y patrones. Esta es la gramática de los agentes, define la estructura de las frases, si es una pregunta, una orden, una afirmación, es decir, el esqueleto del mensaje

La capa 9 (El qué) estandariza el significado para establecer una verdad compartida antes de actuar. Esta es el diccionario compartido, su función es la de que antes de hacer nada, todo el mundo esté de acuerdo en qué significa cada palabra.

Dentro de la capa 9 tenemos el punto central que es el Contexto Compartido que es algo parecido a las reglas del juego, aquí se define todo, los conceptos, las acciones o los parámetros para cada cosa. Antes de empezar a hablar los agentes harán un Semantic Handshake, para confirmar que están de acuerdo en el Contexto Compartido que se va a utilizar.

Si no aplicáramos esto algo como «Reiniciar el servicio» tendría sus problemas: ¿qué es reiniciar? ¿qué servicio? ¿de qué manera quieres esto?. Con la capa 9 todo esto queda definido.

Lo más importante de todo esto del Contexto Compartido es que se negocia antes de hacer nada, esto es fundamental.

Ejemplo del Mundo Real

Se cae el sistema, se despliega un equipo de agentes, uno de métricas, uno de sistemas, otro de red, otro de … sin las capas 8 y 9 puede ser que un agente piense que el 30% de la utilidad (según sus metricas) está caído, otro el 50%, no saben qué tienen que hacer y hay mucha confusión.

Con las capas 8 y 9 tenemos orden y las cosas funcionan

Beneficios:

Hasta ahora estábamos enfocados en mover datos, ahora en mover el entendimiento y esto para empezar tenemos que empezar con las capas 8 y 9.

Referencias:

https://outshift.cisco.com/blog/mind-the-semantic-gap-osi-model

https://www.linkedin.com/posts/sujit-chandrapati-73905b5_outshift-mind-the-semantic-gap-a-case-activity-7424996635505750016-aN1W/

Foto de cabecera de Suzy Hazelwood: https://www.pexels.com/es-es/foto/foto-en-primer-plano-de-libros-con-titulos-variados-1122865/

Hoy hablamos de Afrinic, el Registro Regional de Internet que gestiona las direcciones IP en 54 países de África y que atraviesa una de las peores crisis de gobernanza de la historia de Internet. Aunque solo administra un 6% de las IPv4 mundiales, lo que está ocurriendo allí puede tener un impacto enorme en el futuro de la red.

Desde hace años, Afrinic vive una situación crítica: sin junta directiva electa desde 2022, bajo administración judicial desde 2023 y atrapada en un torbellino de demandas, elecciones anuladas y sospechas de corrupción. El origen de todo está en su enfrentamiento con CIL, uno de los mayores receptores de IPv4 en África. Afrinic acusó a CIL de incumplimientos y uso indebido de direcciones, mientras que CIL respondió con una ofensiva legal que dejó a la organización prácticamente paralizada y sin fondos.

A partir de ahí, los problemas se multiplicaron: intentos fallidos de elecciones en 2025 por votos delegados falsificados, la presión de ICANN que amenaza con retirar el reconocimiento a Afrinic como RIR, y la intervención del gobierno de Mauricio, percibida por algunos como una intromisión política que pone en duda la independencia del organismo. A esto se suman contratos legales opacos, abogados sin capacidad para representar a Afrinic y un ambiente de desconfianza que no deja de crecer.

Hoy Afrinic se encuentra en un callejón con varias salidas posibles, todas delicadas: reestructuración con ayuda de otros RIRs, pérdida de reconocimiento por parte de ICANN o, incluso, la disolución forzosa que propone CIL. Lo que está en juego no es solo el futuro de una organización, sino la estabilidad de Internet en todo un continente.

Referencias:

En este episodio, vamos a hablar sobre seguridad en nuestro amigo BGP. BGP fue diseñado pensando en que todos éramos buenos y que Internet era un sitio mucho más respetable de lo que es hoy.

El camino hacia un BGP más seguro pasa por:

Por si preferís ver en vídeo, no es exactamente el mismo contenido, pero sí muy similar.

Foto de Lewis Kang’ethe Ngugi: https://www.pexels.com/es-es/foto/monitor-de-pantalla-plana-encendido-289927/

En un switch Nexus, los puertos pueden configurarse como puertos de acceso o como puertos trunk, según lo que se requiera en la red.

Los puertos de acceso se utilizan para conectar dispositivos finales, como ordenadores, impresoras y otros dispositivos de usuario final, a la red. Cada puerto de acceso está asociado con una sola VLAN.

Configuración de un puerto de acceso:

En este ejemplo, configuramos el puerto Ethernet1/1 como un puerto de acceso y lo asignamos a la VLAN 10.

Los puertos trunk se usan para transportar tráfico de múltiples VLAN entre switches o entre un switch y un router. Los puertos trunk etiquetan las tramas Ethernet con un identificador de VLAN para asegurar que el tráfico se dirija a la VLAN correcta. Configuración de un puerto trunk:

En este ejemplo, configuraremos el puerto Ethernet1/2 como un puerto trunk para permitir el tráfico de las VLAN 10, 20 y 30, con la VLAN nativa configurada en 1. La VLAN nativa se utiliza para el tráfico no etiquetado.

Para proteger la red de problemas relacionados con el Spanning Tree Protocol (STP), hay que mantener la estabilidad y evitar bucles de red. Aquí os dejo las mejores prácticas y configuraciones de STP para un switch Cisco Nexus:

BPDU Guard se utiliza para proteger los puertos configurados como puertos de acceso (edge ports) que no deberían recibir Bridge Protocol Data Units (BPDUs). Si un puerto con BPDU Guard habilitado recibe un BPDU, el puerto se deshabilitará automáticamente para prevenir bucles de STP.

spanning-tree port type edge: Configura el puerto como un puerto de acceso, lo que significa que se transicionará inmediatamente al estado forwarding.

Root Guard previene que dispositivos no autorizados se conviertan en el root bridge, lo cual podría alterar la topología STP de la red.

spanning-tree guard root: Habilita Root Guard en el puerto para asegurarse de que no se pueda convertir en root port si se reciben BPDUs de un dispositivo no autorizado.

Loop Guard ayuda a prevenir bucles causados por un fallo en recibir BPDUs en puertos no-designados. Es útil en topologías redundantes donde los puertos pueden quedarse en estado «stuck in blocking».

spanning-tree guard loop: Habilita Loop Guard en el puerto para evitar que se transicione a forwarding si deja de recibir BPDUs.

UDLD detecta enlaces unidireccionales causados por fallos físicos y puede deshabilitar el puerto afectado.

udld port aggressive: Configura UDLD en modo agresivo para detectar y deshabilitar rápidamente enlaces unidireccionales.

PortFast se utiliza en puertos de acceso para que transicionen inmediatamente al estado forwarding, lo que es útil en puertos conectados a hosts.

spanning-tree port type edge: Habilita PortFast en los puertos de acceso para minimizar el tiempo de convergencia.

Configurar correctamente los puertos de un switch Cisco Nexus para protegernos de problemas con el Spanning Tree Protocol (STP) implica habilitar BPDU Guard, Root Guard, Loop Guard y PortFast en los puertos adecuados. Estas configuraciones previenen bucles de red, aseguran la estabilidad de la topología STP y mejoran la eficiencia de la red.

Configurar Port Security de manera efectiva en una red corporativa es esencial para prevenir accesos no autorizados y proteger la integridad de la red. Aquí están las mejores prácticas para lograrlo en switches Cisco Nexus:

Lo primero será habilitar el feature de port-security:

Antes de configurar Port Security, es crucial definir políticas claras que establezcan qué dispositivos están permitidos en la red y cuáles no. Estas políticas deben ser comunicadas y aplicadas consistentemente.

Comienza con una configuración básica de Port Security para restringir el número de direcciones MAC permitidas en cada puerto:

switchport port-security maximum 2: Permite un máximo de dos direcciones MAC en el puerto.

Configura direcciones MAC «sticky» para que las direcciones aprendidas dinámicamente se guarden en la configuración de running, lo que facilita la administración:

Define qué acción tomar en caso de una violación de seguridad. Las opciones incluyen protect, restrict, y shutdown. La opción restrict es generalmente recomendada para evitar interrupciones totales:

Para ver las macs sticky aprendidas:

Para borrar una mac sticky

Configura alertas para ser notificado en caso de violaciones de seguridad. Utiliza Syslog o SNMP traps para recibir notificaciones:

Configura alertas para ser notificado en caso de violaciones de seguridad. Utiliza Syslog o SNMP traps para recibir notificaciones:

Realiza auditorías de las configuraciones de Port Security y las direcciones MAC asociadas a cada puerto. Utiliza comandos como:

Documenta todas las configuraciones y asegúrate de que el equipo de IT esté formado en cómo configurar y monitorizar Port Security. Incluye procedimientos para resolver violaciones y restaurar la normalidad.

Hoy vamos a hablar un poco sobre Proxmox, porque es la mejor opción que hay ahora mismo para tener una plataforma de virtualización.

En el audio de hoy hablo de:

Espero que os resulte interesante y recordad que si necesitáis algo con Proxmox en Tecnocrática es una de las cosas que hacemos.

En el audio de hoy os traigo la charla que di en el último EsNOG, os hablo desde los conceptos fundamentales de DMA (Acceso Directo a Memoria), que permite que ciertos componentes de hardware accedan a la memoria sin la intervención de la CPU, hasta tecnologías avanzadas como UltraEthernet, diseñadas para mejorar la eficiencia y el rendimiento en aplicaciones de Inteligencia Artificial (IA) y Computación de Alto Rendimiento (HPC).

La evolución hacia RDMA (Acceso Directo a Memoria Remota) es notable por su capacidad de eliminar copias de datos innecesarias, reduciendo la carga en la CPU y disminuyendo la latencia de la red. RDMA permite transferencias de memoria a memoria sin la intervención del sistema operativo, mejorando significativamente la eficiencia en la transferencia de datos entre sistemas remotos.

Una tecnología particularmente relevante mencionada en el documento es RoCE (RDMA over Converged Ethernet), que adapta RDMA para operar sobre redes Ethernet. RoCE mejora la eficiencia operativa al permitir transferencias de datos de alta velocidad sin sobrecargar el procesador central y es ideal para entornos como centros de datos y la nube, donde se requieren altas tasas de transferencia de datos y baja latencia.

RoCE viene en varias versiones, como RoCE v1, que opera en redes sin pérdidas utilizando Control de Flujo por Prioridad (PFC), y RoCE v2, que funciona sobre redes IP y utiliza UDP para encapsular paquetes RDMA, incluyendo mecanismos de control de congestión avanzados como ECN.

La culminación de estas tecnologías se presenta con UltraEthernet, que se describe como una evolución de RoCE diseñada específicamente para las necesidades de la IA y la HPC. Ofrece mejoras en escalabilidad, manejo de la congestión, rendimiento y seguridad, optimizando para operaciones rápidas necesarias en el procesamiento de grandes volúmenes de datos en tiempo real o tiempos de ejecución aceptables. También incorpora mecanismos de seguridad directamente en la capa de red para proteger datos críticos, como el cifrado de datos en tránsito y la autenticación de nodos.

En resumen, estas tecnologías no solo avanzan en la eficiencia y el rendimiento de las redes y los sistemas de procesamiento de datos, sino que también abordan desafíos críticos de seguridad y escalabilidad necesarios para el futuro de la computación en IA y HPC.

Descargar: ultraethernet_esnog_31.pdf