☰

¿Cómo puedo obtener una interfaz VLAN en un puente Linux?

tag-icon • tag-icon linux networking debian bridge bridging
¿Cómo puedo obtener una interfaz VLAN en un puente Linux?

Estoy experimentando con puentes de Linux y filtrado de VLAN, pero tengo algunos problemas.

Lo que tengo es una VM con un troncal (marcos etiquetados) que llega a ens19. Lo que quiero hacer es conectar este puerto a un puente de Linux y en este puente tener interfaces "virtuales" que están etiquetadas en la VLAN que necesito con una pila TCP/IP completa detrás (la del host).

Para mis experimentos me limito a las vlan 3 y 5, pero la idea es que sea fácil de ampliar. El uso no parecerá enorme porque podría ser reemplazado por subinterfaces de ens19. Pero más adelante me interesará conectar el puerto ens19 con una interfaz gretap para circular varias VLAN en un túnel.

He hecho pruebas con interfaces ficticias y tap, pero me parece que no funciona dada la naturaleza de estas interfaces. Probé con una subinterfaz br0.3 pero aquí mi cliente recibe la respuesta ARP pero el PING nunca recibe una respuesta ICMP...

ip link add name br0 type bridge vlan_filtering 1
ip link set dev br0 up
ip link add link br0 name br0.3 type vlan id 3
ip link set dev ens19 master br0
ip link set ens19 up
ip link set dev br0 up
ip link set dev br0.3 up
ip addr add 10.3.0.106/22 dev br0.3

PING DEL CLIENTE > imposible agotar el tiempo de espera cuando br0.3 está activo

CLIENTE ARP: OK

CLIENTE ICMP: NO OK

br0 volcado

Respuesta1

puente tonto

Con la configuración actual, no pasa tráfico: todo lo filtra el puente compatible con VLAN porque, de forma predeterminada, utiliza la VLAN 1 en todos los puertos y en la interfaz propia del puente. Cuando llega o se emite una trama con VLAN ID 3, como no coincide con el filtro, se descarta.

Para que el experimento actual funcione, simplemente vuelva a colocar el puente como un puente "tonto":

ip link set dev br0 type bridge vlan_filtering 0

Ahora el tráfico etiquetado ens19llegará (etiquetado) el br0(si no se reenvía a otro lugar), se desetiquetará br0.3y llegará alenrutamientopila (por ejemplo: como tipo IPv4, ARP o IPv6). El tráfico no etiquetado, si lo hubiera, también llegará alenrutamientoapilar a través de br0. Cualquier otro tráfico etiquetado con VLAN se descartará porque no hay nada que lo reclame: elenrutamientoLa pila en sí no comprende las VLAN.

El puente reenviará tramas etiquetadas con VLAN, sin considerar el significado de los ID de VLAN, lo que puede causar problemas si se usa la misma dirección MAC en varias VLAN. Esto podría confundir el manejo de la base de datos de reenvío en el puente o provocar que aparezcan duplicados o bucles en otros equipos, etc.

Por lo tanto, se prefiere un puente compatible con VLAN.

Puente compatible con VLAN

Si el puente tiene que desempeñar un papel neutral y el objetivo es crear fácilmente nuevos puertos por VLAN y aún más, paracambiarVLAN en puertos sin tener que eliminar y volver a crear una interfaz (como es necesario con las subinterfaces VLAN), entonces, de hecho, un puente compatible con VLAN es útil. En esta configuración, si bien todavía es posible utilizar subinterfaces VLAN además de br0, se puede evitar. En su lugar, se puede utilizar unvethpar para cada VLAN: uno como puerto puente, otro como interfaz que se comunica con la pila de enrutamiento (ese es un caso de uso devethsin involucrar espacios de nombres de red en absoluto).

br0en sí no tiene que usarse para enrutamiento, excepto tal vez si se usa como administración si no hay otra interfaz física (que no sea ens19) disponible. A continuación, la configuración comienza con el bloqueo completo de cualquier puerto agregado, incluido br0él mismo, configurándolo también vlan_default_pvid 0(en lugar de obtener el ID de VLAN de puerto 1 predeterminado para todo). Esto también permite configurar inmediatamente los puertos puente hacia arriba sin correr el riesgo de fugas durante la configuración, ya que, de forma predeterminada, nada puede pasar.

La configuración de VLAN en el puente compatible con VLAN utiliza elbridge vlancomando con el más nuevortnetlink(7)API del núcleo. El comando obsoleto brctlno puede hacer esto, porque elAPI del kernel anterior(o /sys) no proporciona las funciones para esto.

El caso de OP se desarrolla en pasos sucesivos:

  • creación y enlace troncal

    Al puente se le debe asignar su propia (y única) dirección MAC para que nohereda de forma predeterminada la dirección MAC más baja disponible en los puertos puente, que podría cambiar con el tiempo: elvethEl siguiente método puede hacer que el puente cambie la dirección MAC con el tiempo cuando se agregan nuevas VLAN, lo cual no es un problema real para este método, pero podría afectar el método de subinterfaz VLAN si se usa en conjunto, o afectar el br0uso de cuando se tiene una IP. dirección misma. En sistemas recientes basados ​​en systemd, esto esya hecho porsistemadcualquiera que sea el administrador de red involucrado, incluso si este comportamiento no es deseado, si detecta una nueva interfaz virtual similar a Ethernet creada sin indicar su dirección MAC.

    ip link add name br0 address 12:34:56:78:9a:bc up type bridge vlan_filtering 1 vlan_default_pvid 0
ip link set dev ens19 up master br0

  • Opcional: br0todavía debe usar la VLAN 1 (sin etiquetar) transmitida a través de ens19(etiquetada), por ejemplo para administración:

    bridge vlan add vid 1 dev ens19
bridge vlan del vid 1 dev br0 self pvid untagged

    La interfaz del puente en sí requiere la selfpalabra clave adicional al configurarla.

  • agregue VLAN activadas ens19(VLAN ID 3 y 5 aquí):

    bridge vlan add vid 3 dev ens19
bridge vlan add vid 5 dev ens19

    O si se debe considerar ens19elpuerto troncal de enlace ascendente, simplemente agregue todas las demás VLAN en él:

    bridge vlan add vid 2-4094 dev ens19

    Úselo -compressvlanspara mostrar lo que contiene o se mostrarán 4093 líneas de entradas individuales.

    bridge -compressvlans vlan show dev ens19

Ahora se puede lograr el mismo resultado general con:

  • ya sea una subinterfaz VLAN encima br0(usando VLAN ID 3 aquí)

    Si la interfaz del puente (aquí) o el puerto del puente (siguiente viñeta) no tienen el ID de VLAN agregado, dicho tráfico no pasará cuando el puente esté configurado como un puente compatible con VLAN.

    El ID de VLAN debe agregarse, aún etiquetado, a br0:

    bridge vlan add vid 3 dev br0 self

    Como se indicó anteriormente, todo se podría agregar por adelantado solo una vez:

    bridge vlan add vid 2-4094 dev br0 self

    Luego se agrega la subinterfaz VLAN habitual encima:

    ip link add link br0 name br0.3 up type vlan id 3
ip addr add 10.3.0.106/22 dev br0.3

    Cambiar la ID de VLAN asociada con la interfaz (y en configuraciones comunes a la LAN IP 10.3.0.0/22) requiere eliminar la subinterfaz y recrear una nueva con una ID de VLAN diferente: la type vlaninterfaz no se puede reconfigurar.

  • o un par devethinterfaces (usando VLAN ID 5 aquí)

    pvid untaggedjuega el mismo papel que usar una subinterfaz VLAN: desetiquetas del puente al puerto, etiquetas del puerto al puente. Solo una ID de VLAN puede ser el PVID (y aquí es la ID de VLAN única en uso).

    ip link add name vlan5 up type veth peer name br0vlan5
ip link set br0vlan5 up master br0
bridge vlan add vid 5 dev br0vlan5 pvid untagged
ip addr add 10.3.4.106/22 dev vlan5

    Excepto que los nombres elegidos en los ejemplos reflejan el ID de VLAN, por lo que esto causaría confusión humana, el ID de VLAN asociado se puede cambiar (casi) sobre la marcha (cambiándolo aquí de 5 a 6):

    bridge vlan del vid 5 dev br0vlan5
bridge vlan add vid 6 dev br0vlan5 pvid untagged

    Y si aún no ha configurado todas las VLAN ens19, cámbielo allí también:

    bridge vlan del vid 5 dev ens19
bridge vlan add vid 6 dev ens19

información relacionada