☰

¿Por qué asignar direcciones MAC e IP en la interfaz Bridge?

tag-icon • tag-icon linux ip bridge mac-address
¿Por qué asignar direcciones MAC e IP en la interfaz Bridge?

Digamos que creo una interfaz puente en Linux ( br0) y le agrego algunas interfaces ( eth0, tap0, etc.). Tengo entendido que esta interfaz actúa como un conmutador virtual con todas sus interfaces/puertos que le agrego.

¿Cuál es el significado de asignar una dirección MAC y una dirección IP a esa interfaz? ¿La interfaz actúa como un puerto adicional en el conmutador/puente que permite que otros puertos accedan a la máquina host?

He visto algunas páginas hablar sobre asignar una dirección IP a un puente. ¿La asignación MAC está implícita (o automática)?

Respuesta1

Como un puente es un dispositivo Ethernet, necesita una dirección MAC. Un puente de Linux puede originar cosas como tramas de protocolo de árbol de expansión, y tráfico como ese necesita una dirección MAC de origen.

Un puente norequeriruna dirección IP. Hay muchas situaciones en las que no tendrás uno. Sin embargo, en muchos casos ustedpuedetener uno, como por ejemplo:

  • Cuando el puente actúa como puerta de enlace predeterminada para un grupo de contenedores o máquinas virtuales (o incluso interfaces físicas). En este caso, necesita una dirección IP (porque el enrutamiento ocurre en la capa IP).

  • Cuando su NIC "principal" es miembro del puente, de modo que el puente es su conectividad con el mundo exterior. En este caso, en lugar de asignar una dirección IP a (por ejemplo) eth0, debería asignarla al dispositivo puente.

Si el puente esnorequerido para el enrutamiento IP, entonces no necesita una dirección IP. Ejemplos de esta situación incluyen:

  • Cuando el puente se utiliza para crear una red privada de dispositivos sin conectividad externa o con conectividad externa proporcionada a través de un dispositivo distinto del puente.

Respuesta2

El dispositivo puente que aparece con sus otros dispositivos de red no representa el puente virtual, representa una NIC virtual que está conectada al puente. Si tuviera un puente físico conectado con dispositivos de red físicos, tampoco vería el puente físico en sus dispositivos de red, pero vería su NIC que está conectada al puente, que por supuesto tiene su propia dirección MAC como cualquier otro dispositivo de red.

Asignar una dirección IP al dispositivo puente (que, nuevamente, es en realidad una NIC virtual conectada al puente virtual) permite que su dispositivo host enrute paquetes a la subred creada por el puente y todos los dispositivos conectados a él. ¡Limpio!

Si bien las herramientas de dispositivos de red como iproute2(con los comandos ip linky ip addr) le permiten ver la NIC virtual conectada al puente, también es posible ver el puente virtual con el brctlprograma. El brctl showcomando enumerará todos los puentes y sus interfaces adjuntas. Aquí hay un ejemplo usando iproutey brctlcon puentes y tuntaps de Linux:

# ip link add br0 type bridge
# ip tuntap add dev tap0 mode tap
# ip tuntap add dev tap1 mode tap
# ip addr add 10.0.0.1/24 broadcast 10.0.0.255 dev br0
# ip addr add 10.0.0.2/24 broadcast 10.0.0.255 dev tap0
# ip addr add 10.0.0.3/24 broadcast 10.0.0.255 dev tap1
# brctl addif br0 tap0
# brctl addif br0 tap1
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.2e22e593fe8c       no              tap0
                                                        tap1
# ip addr show to 10.0.0.0/24
11: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global br0
       valid_lft forever preferred_lft forever
12: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.2/24 brd 10.0.0.255 scope global tap0
       valid_lft forever preferred_lft forever
13: tap1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.3/24 brd 10.0.0.255 scope global tap1
       valid_lft forever preferred_lft forever

Tenga en cuenta que lo que aparece en "interfaces" en el resultado de brctl showson losotrointerfaces adjuntas al puente, además de la br0interfaz que se agregó automáticamente cuando se creó el puente. (Supongo que Linux no permite crear un puente virtual sin dispositivos conectados, y los puentes sin dispositivos se destruyen automáticamente). Para que conste, no he investigado esto en el kernel, ni soy un experto en redes. Publiqué esto porque parece explicar de manera convincente la implementación bastante confusa de puentes virtuales en Linux. No creo que los puentes virtuales en sí tengan direcciones MAC.

Respuesta3

Sí, la interfaz puente actúa como un puerto adicional.

Después man 5 systemd.netdev:

Un dispositivo puente es un conmutador de software, y cada uno de sus dispositivos esclavos y el propio puente son puertos del conmutador.

Respuesta4

Las interfaces br0y virbr0enumeradas por ip addry ip linkson interfaces de derivación que conectan el host al br0puente y al virbr0puente respectivamente. Esta sobrecarga de nombres ciertamente puede resultar confusa.

Entonces que es virbr0-nic?

Esto no era parte de la pregunta original, pero agregaré mi granito de arena aquí ya que esto me confundió en el pasado. virbr0-nices una interfaz ficticia cuya dirección MAC es utilizada por el virbr0puente como su propia dirección mac. Esta interfaz siempre presente está ahí para evitar que virbr0la dirección MAC de cambie cuando se agregan o eliminan puertos dinámicamente del puente. El host no envía ningún tráfico fuera de la virbr0-nicinterfaz.

Verhttps://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-portsyhttps://www.redhat.com/archives/libvirt-users/2012-September/msg00038.htmlpara una explicación.

información relacionada