Introducción
En el IES Zaidin Vergeles, el ciclo formativo de Administración de Sistemas Informáticos en Red (ASIR) utiliza un cluster de virtualización basado en Proxmox para prácticas avanzadas. Este entorno, accesible desde https://informatica.ieszaidinvergeles.org:8011, permite a los estudiantes desplegar máquinas virtuales (VMs) en nodos con interfaces de 1 Gbps y 10 Gbps. Sin embargo, la necesidad de aislar redes por grupos (mediante interfaces virtuales vmbrXX) chocó con un desafío: prácticas como la instalación de Active Directory requerían múltiples VMs por alumno, saturando un nodo mientras otros permanecían infrautilizados.

El Problema: Aislamiento vs. Escalabilidad
Inicialmente, cada grupo (ej: 1ASIRB en vmbr28, red 172.28.0.1/16) trabajaba en una red lógica aislada. Esto garantizaba seguridad, pero limitaba la distribución de VMs entre nodos: si un alumno necesitaba un servidor y un cliente en la misma red, ambas VMs debían residir en el mismo nodo físico, sobrecargándolo.

La Solución: VXLAN, Redes Extendidas sin Límites Físicos
Para resolverlo, implementamos VXLAN (Virtual Extensible LAN), una tecnología de overlay que encapsula tramas Ethernet en paquetes UDP, permitiendo crear redes lógicas extendidas sobre infraestructura física heterogénea. A diferencia de las VLANs tradicionales, VXLAN escala hasta 16 millones de redes únicas (mediante VNI, Virtual Network Identifier) y traspasa límites de subredes físicas.

Diferencia entre VLAN vs VXLAN

Configuración en Proxmox: Paquetes y Redes

  1. Paquetes Requeridos:bashCopyapt install vlan bridge-utils
    • vlan: Para manejar interfaces virtuales.
    • bridge-utils: Para configurar puentes de red.
      Instalación:
  2. Ejemplo de Configuración en /etc/network/interfaces:
    Supongamos la red vmbr16 (172.16.0.1/16) para un grupo. La clave es crear un túnel VXLAN que interconecte este segmento entre nodos:

# Creación del túnel VXLAN servidor 1
auto vxlan16
iface vxlan16 inet manual
pre-up ip link add vxlan16 type vxlan id 16 dev vmbr10 dstport 4789 local 192.168.0.1 group 239.1.1.16
up ip link set vxlan16 up
down ip link set vxlan16 down
post-down ip link del vxlan16

# Puente que usa el túnel servidor 1
auto vmbr16
iface vmbr16 inet static
address 172.16.0.1/16
bridge-ports vxlan16 # Enlaza al túnel VXLAN
bridge-stp off # Desactiva Spanning Tree
bridge-fd 0 # Sin retraso en estados
mtu 1400 # Ajuste por overhead de encapsulación

# Creación del túnel VXLAN servidor 2
auto vxlan26
iface vxlan26 inet manual
pre-up ip link add vxlan26 type vxlan id 26 dev vmbr10 dstport 4789 local 192.168.0.2 group 239.1.1.26
up ip link set vxlan26 up
down ip link set vxlan26 down
post-down ip link del vxlan26

# Puente que usa el túnel servidor 2
auto vmbr26
iface vmbr26 inet static
address 172.26.0.2/16
bridge-ports vxlan26
bridge-stp off
bridge-fd 0
mtu 1400

Explicación Detallada:

    • VXLAN16:
      • id 16: Identificador de red (VNI 16).
      • dev vmbr10: Interfaz física usada para el tráfico encapsulado (aquí, la de 10 Gbps).
      • group 239.1.1.16: Grupo multicast para descubrir nodos participantes.
      • local 192.168.0.1: IP del nodo en la red física (vmbr10).
    • vmbr16:
      • Funciona como puente estándar, pero conectado al túnel VXLAN. Las VMs se unen a este puente, creando la ilusión de estar en la misma LAN, aunque estén en nodos distintos.

Beneficios Logrados

  1. Distribución de Carga: Las VMs de un mismo grupo (ej: servidor y cliente AD) pueden repartirse entre nodos, evitando cuellos de botella.
  2. Aislamiento Mantenido: Cada vmbrXX sigue siendo una red independiente; VXLAN solo extiende su alcance lógico.
  3. Transparencia para Alumnos: Las prácticas de redes (ping, configuración IP) funcionan como si todo estuviera local, facilitando el aprendizaje.

Consideraciones Adicionales

  • Multicast vs. Unicast: Usamos multicast en este ejemplo (sencillo para entornos pequeños). En redes grandes, conviene usar modo unicast con VTEPs (VXLAN Tunnel Endpoints) estáticos.
  • MTU: Reducirlo a 1400 evita fragmentación (el encapsulado VXLAN añade ~50 bytes).

MTU 1400: ¿Por qué es crítico?
El ajuste del MTU (Maximum Transmission Unit) a 1400 bytes en el puente virtual (vmbr16) es esencial debido al overhead generado por la encapsulación VXLAN. Cada trama Ethernet enviada a través del túnel VXLAN añade aproximadamente 50 bytes de cabeceras (VXLAN + UDP + IP externa). Si mantenemos el MTU por defecto (1500 bytes), el paquete encapsulado final superaría los 1550 bytes, excediendo el MTU estándar de las redes físicas (1500 bytes). Esto provoca dos escenarios:Sin este ajuste, aunque las VMs dentro del VXLAN puedan comunicarse entre sí (si sus paquetes son pequeños), fallarán al acceder a Internet u otros recursos externos. ¿La razón? Los paquetes hacia Internet deben salir del túnel VXLAN y viajar por la red física, donde chocan con el límite de 1500 bytes. Al reducir el MTU en el puente virtual, garantizamos que todos los paquetes encapsulados (incluyendo los destinados a Internet) quepan dentro del MTU físico, evitando pérdidas y asegurando conectividad end-to-end.

    1. Fragmentación de paquetes: El router o switch físico divide los paquetes grandes, introduciendo latencia y posibles errores si algún fragmento se pierde.
    2. Paquetes descartados: Algunos dispositivos bloquean paquetes que superan el MTU sin intentar fragmentación (comportamiento común en redes con PMTUD no configurado).

Conclusión
La integración de VXLAN en Proxmox ha transformado nuestra docencia en ASIR: los alumnos pueden desplegar infraestructuras complejas (como redes Windows AD) sin limitaciones físicas, mientras el cluster aprovecha mejor sus recursos. Tecnologías como esta no solo optimizan la infraestructura, sino que enriquecen la experiencia de aprendizaje, preparando a los estudiantes para entornos enterprise reales.