La red en Proxmox es una de esas zonas donde una línea aparentemente inocente puede tener más peso que media tarde de diagnóstico. Una VM no responde, una migración se queda rara, una VLAN no aparece donde debería o una interfaz que jurabas que era la buena resulta que no está enganchada al bridge que toca.
Cuando estoy en esa situación intento no empezar por la interfaz web. La web está bien, la uso mucho, pero para leer la red de un nodo desde SSH prefiero una salida cruda que pueda copiar, comparar y guardar. Para eso tiro de pvesh.
| |
No es un comando espectacular. No te dibuja un diagrama bonito. Te enseña interfaces, bridges, métodos de configuración, IPs, MTU, puertos físicos y si la interfaz está activa. Justo lo que necesito cuando quiero separar tres cosas que se mezclan demasiado rápido en la cabeza: lo que creo que configuré, lo que Proxmox tiene declarado y lo que el nodo está exponiendo en ese momento.
la captura de este post#
La captura sale de un nodo real de mi laboratorio, con nombres e IPs saneados. He dejado la estructura importante porque es lo que interesa: una interfaz física sin IP, un bridge principal, un bridge dedicado con MTU 9000 y varias NICs en modo manual.
La salida tiene este aspecto.
| |
Me gusta esta salida porque no intenta ser amable. Si una interfaz está en manual, lo dice. Si un bridge tiene gateway, lo dice. Si una red de storage va con MTU 9000, aparece ahí. No hay que fiarse de memoria.
por qué uso pvesh para esto#
Proxmox guarda la configuración de red del nodo, pero cuando trabajas en un cluster lo peligroso no es solo tener mal una línea. Lo peligroso es creer que todos los nodos están iguales porque los montaste el mismo día.
En un homelab real eso rara vez aguanta mucho tiempo. Cambias una tarjeta de red, pruebas una VLAN, mueves una VM, creas un bridge para una red interna, desactivas STP porque no lo necesitas, subes MTU para una red de storage y seis meses después ya no recuerdas qué nodo quedó perfecto y cuál quedó funcionando de momento.
pvesh get /nodes/<nodo>/network me da una forma bastante seca de comprobarlo.
| |
Si quiero algo más legible en terminal puedo cambiar el formato, pero YAML me resulta cómodo porque cada interfaz queda como un bloque. Se lee bien y se pega bien en una nota interna.
iface: el nombre que no quiero dar por supuesto#
Lo primero que miro es iface.
| |
O una interfaz física.
| |
En máquinas pequeñas esto parece trivial. En cuanto metes varias NICs, 2.5 GbE, 10 GbE, puertos duales o adaptadores USB que no deberías usar para nada serio, deja de serlo. Los nombres enp... no son bonitos, pero son concretos.
Me interesa especialmente cruzar iface con bridge_ports. Si vmbr0 dice que usa enp4s0, ya sé qué tarjeta física está sosteniendo ese bridge. Si esperaba otra, paro. No arreglo red a base de intuición, porque la intuición en networking suele ser una forma elegante de perder una tarde.
También miro si aparecen interfaces que no esperaba. Una NIC en manual puede ser normal. Una NIC sin active puede ser normal. Pero si veo un puerto que debería estar en un bridge y aparece suelto, ya tengo una pista.
bridges: donde viven realmente las VMs#
En Proxmox las VMs suelen conectarse a bridges. Por eso no me basta con ver que el host tiene red. Quiero saber qué bridge está conectado a qué puerto y qué red representa.
La línea clave suele ser esta.
| |
Si una VM está en vmbr0, pero vmbr0 apunta a un puerto que no es el que yo pensaba, puedo estar mirando el problema equivocado. Lo mismo si tengo un vmbr10 para una red interna, storage, migraciones o tráfico aislado.
Me fijo también en bridge_stp y bridge_fd.
| |
En muchos homelabs pequeños esto está en off y no pasa nada. Pero si estás conectando bridges a switches gestionables, trunks, VLANs o cosas con más de un camino físico, conviene saberlo. No porque haya que activar STP siempre, sino porque hay que entender qué decisión tomaste.
Cuando todo funciona, la red parece aburrida. Cuando algo falla, estas dos líneas dejan de ser decoración.
method: static, manual y las pequeñas mentiras#
La diferencia entre static y manual importa.
| |
Suele significar que esa interfaz o bridge tiene configuración IP directa. En el bridge principal, por ejemplo, espero ver address, cidr, gateway y netmask.
| |
En una interfaz física que solo actúa como puerto de un bridge, manual es normal. No quiero IP ahí. Quiero que el bridge sea quien tenga la configuración.
El problema aparece cuando una interfaz que debía ser parte de un bridge tiene IP propia, o cuando un bridge que debería tener IP aparece manual. Ahí empiezan los síntomas raros: el host responde por donde no esperas, una ruta sale por otro lado o una VM parece estar bien conectada pero no llega a nada útil.
No es que method lo explique todo. Pero te dice por dónde empezar.
gateway: solo quiero uno, y quiero saber cuál es#
En un nodo Proxmox normal, el gateway por defecto suele vivir en el bridge principal.
| |
Si veo gateways en sitios raros, levanto la ceja. Puede haber diseños con varias rutas, tablas avanzadas y redes separadas, claro. Pero en un homelab medio, dos gateways declarados sin una razón clara suelen ser el principio de una historia fea.
Yo intento que la red de gestión sea fácil de leer. vmbr0 con IP de gestión, gateway ahí, y luego bridges internos o dedicados sin gateway salvo que tenga una razón muy concreta.
Esto se vuelve importante cuando tienes una red de storage o de cluster. Esa red puede tener IP estática, pero no tiene por qué ser la salida por defecto del nodo. Mezclarlo todo porque total, enruta, es cómodo hasta que deja de serlo.
MTU: el número que solo miras cuando ya duele#
La línea de MTU suele pasar desapercibida.
| |
Hasta que una red de storage, Ceph, migraciones o replicación empieza a comportarse raro.
Si tengo una red dedicada a tráfico pesado y he decidido usar jumbo frames, quiero ver el MTU en el nodo. Pero verlo en Proxmox no basta. Tiene que estar coherente en el switch, en los otros nodos y en cualquier camino intermedio. Un MTU 9000 en un lado y 1500 en otro no siempre rompe de forma obvia. A veces solo degrada, fragmenta o genera fallos intermitentes que parecen otra cosa.
Por eso esta salida me sirve como primera comprobación, no como sentencia final. Si veo mtu: '9000', la siguiente pregunta es si todos los nodos de esa red dicen lo mismo.
| |
Ese tipo de comparación rápida te evita entrar en la web nodo por nodo. No es bonito, pero funciona.
active, autostart y exists#
Estos campos parecen menores.
| |
No los ignoro.
exists me dice que la interfaz existe para el sistema. Si una configuración menciona una NIC que ya no está, ahí hay basura o una migración física mal cerrada.
active me dice si está levantada. Una interfaz puede existir y no estar activa. Eso no siempre es malo, pero si sostiene un bridge que necesito, ya tengo problema.
autostart me importa después de reinicios. Hay configuraciones que funcionan mientras nadie reinicia el nodo. Luego vuelven las sorpresas. Si un bridge crítico no arranca solo, el nodo puede volver de mantenimiento con una pinta sana pero sin red útil para ciertas VMs.
Un homelab no falla siempre por cosas sofisticadas. A veces falla porque algo que debía arrancar no arrancó.
cómo lo uso antes de migrar VMs#
Antes de mover una VM entre nodos, miro dos cosas: storage y red.
La parte de red es simple. Si la VM usa vmbr0, vmbr10 o un bridge con VLAN awareness, quiero saber que el nodo destino tiene esa red de forma equivalente. No necesariamente idéntica en cada detalle, pero sí compatible.
Una VM con su interfaz en vmbr10 no va a quedar feliz si el nodo destino no tiene vmbr10 o si ese bridge apunta a otra red. Proxmox puede validar algunas cosas, pero yo prefiero no descubrirlo tarde.
Mi comprobación mínima sería algo así.
| |
Luego comparo bridges, puertos y MTU. Si estoy en modo rápido, tiro de grep. Si estoy tocando algo delicado, guardo la salida y la comparo con calma.
VLANs: no siempre aparecen donde esperas#
Este comando no sustituye a revisar toda la configuración VLAN. Si usas VLAN aware bridges, subinterfaces o trunks en el switch, hay más capas.
Pero sí me ayuda a detectar la base. ¿Existe el bridge correcto? ¿Está activo? ¿Tiene el puerto físico adecuado? ¿Tiene MTU coherente? ¿Aparece alguna subinterfaz VLAN declarada en el nodo?
Si la salida del nodo ya no cuadra, no merece la pena saltar al firewall o al servicio dentro de la VM. Primero arreglas el mapa local. Luego sigues.
Esto es especialmente útil cuando una VM no tiene red después de moverla. Muchas veces el invitado está bien. El problema está en que el bridge de destino no representa lo mismo que el bridge de origen.
mi secuencia cuando algo huele a red#
Si una VM no responde y sospecho de Proxmox, hago algo bastante aburrido.
| |
Primero miro a qué bridge está conectada la VM. Luego miro si la VM está viva. Después leo la red del nodo. Si eso cuadra, ya me voy a firewall, switch, DNS o al propio sistema invitado.
Lo importante es no mezclar capas. Si el bridge está mal, no pierdo tiempo dentro de la VM. Si el bridge está bien, no toco Proxmox por tocar.
lo que no hago desde aquí#
No cambio red en caliente alegremente porque una salida me parezca fea.
Proxmox permite aplicar cambios de red, pero una mala decisión te puede cortar la sesión SSH o dejar un nodo menos accesible de lo que estaba. Si estoy remoto y el cambio toca la interfaz de gestión, bajo el ritmo. Reviso consola, acceso alternativo, ventana de mantenimiento y si el nodo está sosteniendo algo que no quiero tirar.
Para leer, pvesh es perfecto. Para escribir, la red merece más respeto.
También evito limpiar bridges que no reconozco sin revisar VMs y contenedores. Un bridge puede parecer abandonado y seguir sosteniendo una máquina que arranca una vez al mes. En homelab eso pasa muchísimo.
mi lectura final#
pvesh get /nodes/<nodo>/network no arregla la red. Lo que hace es mejor: te quita fantasía.
Te enseña qué interfaces existen, qué bridges están activos, qué puerto físico usa cada bridge, dónde vive el gateway y si hay MTU especial. Con eso ya puedes diagnosticar con menos teatro.
Yo lo uso especialmente antes de migrar VMs, antes de tocar VLANs, después de cambiar tarjetas de red y cuando una máquina deja de responder justo después de un mantenimiento.
No es el comando más vistoso de Proxmox, pero es uno de esos que prefiero tener cerca. La red no perdona mucho. Cuanto antes leas la realidad, antes dejas de pelearte con lo que creías recordar.