Estaba configurando una máquina virtual QEMU/KVM y quería usar una red puente para ello. En todos los manuales/tutoriales que he leído, dice que se deshabilite DHCP en la NIC física y se habilite en el puente. Lo que no entiendo es que si el puente actúa como lo haría un puente/conmutador físico, ¿por qué tiene que tener una dirección IP asignada mientras que la NIC física real no tiene una? Esta pregunta ya me hicieron un par de veces pero todavía no he encontrado una respuesta, por ejemploaquíla respuesta decía que de esta manera las máquinas virtuales pueden comunicarse con el puente. Pero ¿por qué lo necesitan? Con máquinas físicas reales, un puente funciona de forma transparente y simplemente reenvía el tráfico. Entonces, mis preguntas son:
- ¿Por qué un puente virtual necesita una dirección IP cuando uno físico no?
- ¿Cómo sabe la NIC física que debe utilizar la dirección IP del puente virtual cuando la NIC no tiene una?
- ¿Por qué las máquinas virtuales necesitan comunicarse con el puente mientras que las máquinas físicas en realidad no se comunican directamente con un puente físico?
Aquí hay algunas ilustraciones para mostrar mejor lo que quiero decir:
- Cómo imagino que funciona una red física con un conmutador de red:
- Cómo imagino que ~debería~ funcionar un puente virtual
- Según tengo entendido, realmente funciona.
Respuesta1
- ¿Por qué un puente virtual necesita una dirección IP cuando uno físico no?
Es un error pensar que un puente virtual necesita una dirección IP. No lo necesita.
tu en realidadpodertener un puente virtual sin una dirección IP. Pero entonces no se podrá acceder al host en sí a través de IP en esa interfaz física: solo las máquinas virtuales lo serán.
En un host de virtualización empresarial, esto puede resultar útil: es posible que tenga una red de cliente que deba conectarse a las máquinas virtuales de los clientes. Es posible que no desee otorgar acceso desde dicha red al propio host de virtualización, perosoloa las respectivas máquinas virtuales. Luego tendría otra red de administración físicamente separada que usaría para administrar sus hosts de virtualización. Esta red estaría conectada al host a través de una NIC separada quenoser miembro de cualquier puente virtual.
- ¿Cómo sabe la NIC física que debe utilizar la dirección IP del puente virtual cuando la NIC no tiene una?
A menos que la NIC física tenga funciones específicas de aceleración de IPv4, una dirección IP es solo datos de carga útil para la NIC. Una NIC física básica funciona únicamente con la Capa 2, es decir, con direcciones MAC. El protocolo IP es de Capa 3 y generalmente se deja para la pila de controladores de red del sistema operativo. Cuando "configura una dirección IP para una NIC" con ifconfigo ip addr, no necesariamente realiza ningún cambio en la configuración física real del hardware, sino en una construcción abstracta que incluye tanto la NIC física como el soporte del protocolo IP a nivel del sistema operativo asociado con la NIC.
Cuando una NIC física está configurada para actuar como miembro de un puente, es posible que sea necesario desactivar cualquier característica de aceleración de Capa 3 de todos modos: cuando actúa como parte de un puente, la NIC necesita recibir todos los paquetes entrantes, sin importar el dirección MAC o IP de destino, y el código del puente decidirá si el paquete se reenviará y a qué miembro del puente. Un puente básico no debe preocuparse en absoluto por las direcciones IP. Cualquier funcionalidad de Capa 3 en un puente va más allá de la funcionalidad básica del puente y es/debería ser opcional en un puente virtual.
Si la NIC física está configurada con una dirección IP cuando se configura como parte de un puente, activará la funcionalidad ARP en esa NIC (+su controlador). Pero los mensajes ARP salientes de esa NIC física no podrán llegar a las máquinas virtuales: para llegar a todo el segmento con sus ARP (como lo requiere la funcionalidad adecuada de Capa 2), el controlador de NIC tendría que generar el mensaje ARP como mensaje ARP saliente. y mensaje entrante simultáneamente, y el controlador NIC no tendrá el código para hacerlo.
Tener un puente virtual con máquinas virtuales significa que algunas partes del segmento IP del puente estarán físicamente fuera del host, mientras que otras estarán contenidas dentro de las máquinas virtuales ubicadas dentro del host. Si el host usara la NIC como de costumbre en un intento de comunicarse con una de las máquinas virtuales, los paquetes se enviarían innecesariamente fuera del host al conmutador o enrutador físico al que está conectado el host, y desde allí tendrían que Regrese al host y a través del puente hasta la máquina virtual de destino.
Esto ciertamente sería ineficiente y podría no funcionar en absoluto: el conmutador físico al que está conectado el host con el puente virtual normalmente no tendría ninguna razón para enviar ningún paquete originado desde ese host al propio host.
En cambio, los paquetes salientes desde el host al segmento de red puenteado deben enviarse a través del código de puente, que primero busca qué interfaz del puente (virtual o física) estaría "más cerca" del destino. Si el puente conoce el destino, el paquete saliente se envía directamente hacia él. Para la comunicación entre el host y sus máquinas virtuales, esto significa que la comunicación ocurre completamente dentro del host físico y no utiliza el ancho de banda de la red física fuera del host en absoluto.
Si el puente no conoce la dirección MAC de destino, los paquetes salientes se envían inicialmente a todas las interfaces de los miembros del puente: tan pronto como se recibe una respuesta, el puente conocerá la ubicación del destino del paquete inicial y podrá regresar. al método eficiente de operación (como arriba).
Al realizar solicitudes ARP desde el host que contiene el puente, las solicitudes deben transmitirse a ambas máquinas virtuales.ysacar la NIC física para que las solicitudes se envíen realmente a laenteroSegmento de red: el código puente puede hacer eso, la NIC física individual no.
Creo que no existe ningún requisito de que un puente de Linux sea exclusivamente físico o virtual: no veo por qué un puente de Linux no podría tener múltiples interfaces físicas.ycualquier número de máquinas virtuales asociadas a él. Pero en un entorno empresarial, generalmente no se desea crear un "host que haga todo" como ese. Fácilmente podría convertirse en una pieza de infraestructura crítica y complicada que nunca puede tener ningún tiempo de inactividad; es decir, un dolor de cabeza para los administradores del sistema.
- ¿Por qué las máquinas virtuales necesitan comunicarse con el puente mientras que las máquinas físicas en realidad no se comunican directamente con un puente físico?
De nuevo la idea errónea: las VM sínoNecesita una dirección IP en el puente "para comunicarse con el puente" como tal.
Pero si tudesearPara que el host y las VM puedan comunicarse entre sí en el mismo segmento de red IP, asignar una dirección IP al dispositivo puente es la forma de hacerlo.
La dirección IP en el dispositivo puente está ahí principalmente para satisfacer las necesidades de comunicación delanfitrión, no de lamáquinas virtuales- pero puede permitir que el host se comunique con las máquinas virtuales a través de IP de manera eficiente sin necesidad de pasar por dispositivos externos, si eso es lo que desea.