Buen dia, asi se implementa parece en PROXMOX , nunca lo he usado pero si vi
obviamente las opciones de VLAN OVS , BRIDGE OVS, y básicamente es lo mismo que
hacerlo directamente en el propio Linux, yo sinceramente prefiero mayor
flexibilidad que me daría realmente tener un managed switch capa 3 por ej he
implementar todo eso directamente en el swirtch y no por software en el proxmox
o directamente en un box Linux. Al final parece yo soy mas hardwareiano que
softwareano peus ciertamente muchos de usatedes abogan por olvidarse del
hardware y poner el esfuerzo o gasto en implementar todo por software creando
maquinas Linux a tal efecto . pero me parece ambas opciones son viables como
msim ol oes o usar un controlador RAID físico o usar una implementación RAID
por software por ejemplo
Obvaimente con las diferencias o limitaciones de las diferentes formas de
implementar todo esto de VLANS y bonding o link aggreggation y demás
Cheers, Hope it helps ¡
JJ
Abrir vSwitch
Open vSwitch (openvswitch, OVS) es una alternativa a los puentes nativos de
Linux, enlaces e interfaces vlan. Open vSwitch es compatible con la mayoría de
las características que encontraría en un conmutador físico, proporcionando
algunas características avanzadas como soporte RSTP, VXLA N, OpenFlow, y
soporta múltiples vlans en un solo bridge. Si necesita estas características,
tiene sentido cambiar a Open vSwitch.
instalación
Actualice el índice del paquete y, a continuación, instale los paquetes de Open
vSwitch ejecutando:
apt update
apt install openvswitch-switch
configuración
Referencia oficial aquí, aunque un poco desnuda:
https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.README.Debian
visión general
Abrir la unión y el puente de vSwitch y Linux o vlans NO DEBE mezclarse. Por
ejemplo, no intente agregar una vlan a un vínculo de OVS ni agregar un Vínculo
de Linux a un OVSBridge o viceversa. Open vSwitch está diseñado específicamente
para funcionar en entornos virtualizados, no hay ninguna razón para usar la
funcionalidad nativa de Linux.
Puentes
Un Bridge es otro término para un Switch. Dirige el tráfico a la interfaz
apropiada basada en la dirección Mac. Los puentes vSwitch abiertos deben
contener dispositivos Ethernet sin procesar, junto con interfaces virtuales
como OVSBonds o OVSIntPorts. Estos Bridges pueden llevar los vlan múltiples, y
ser divididos en 'puertos internos' que se utilizarán como interfaces vlan en
el host.
Cabe señalar que se recomienda que el Bridge esté enlazado a un puerto troncal
sin vlans sin etiquetar; esto significa que su puente en sí nunca tendrá una
dirección IP. Si usted necesita trabajar con el tráfico sin marcar que viene en
el Bridge, se recomienda que usted lo etiquete (asigne a un vlan) en la
interfaz de origen antes de ingresar el Bridge (aunque usted puede asignar una
dirección IP en el Bridge directamente para esos datos sin etiquetar, no se
recomienda). Puede dividir las VLAN etiquetadas mediante interfaces virtuales
(OVSIntPort) si necesita acceso a esas vlans desde el host local. Proxmox
asignará a las máquinas virtuales invitadas una interfaz de toque asociada a
una vlan, por lo que NO necesita un Bridge por vlan (como requiere redes linux
clásicas). Usted debe pensar en su OVSBridge al igual que un interruptor de
hardware físico.
Al configurar un Bridge, en /etc/network/interfaces, prefije la definición de
la interfaz del Bridge con allow-ovs $iface. Por ejemplo, un puente simple que
contiene una sola interfaz tendría el aspecto de:
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports eth0
Recuerde, si desea dividir vlans con ips para su uso en el host local, debe
usar OVSIntPorts, consulte las secciones a seguir.
Sin embargo, cualquier interfaz (Physical, OVSBonds o OVSIntPorts) asociadas a
un Bridge debe tener sus definiciones prefijadas con allow-$brname $iface, por
ejemplo, allow-vmbr0 bond0
NOTA: Todas las interfaces se deben enumerar bajo ovs_ports que son parte del
Bridge incluso si usted tiene una definición de puerto (por ejemplo,
OVSIntPort) que haga referencia cruzada al Bridge!!!
Bonos
Los bonos se utilizan para unir varias interfaces de red para actuar como una
sola unidad. Los enlaces deben referirse a los dispositivos Ethernet sin
procesar (por ejemplo, eth0, eth1).
Al configurar una unión, se recomienda utilizar LACP (también conocido como
802.3ad) para la agregación de vínculos. Esto requiere el soporte del Switch en
el otro extremo. Un enlace simple usando eth0 y eth1 que formará parte del
puente vmbr0 podría tener este aspecto.
allow-vmbr0 bond0
iface bond0 inet manual
ovs_bridge vmbr0
ovs_type OVSBond
ovs_bonds eth0 eth1
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
NOTA: Las interfaces que forman parte de un vínculo no necesitan tener su
propia sección de configuración.
Interfaces de host VLA N
Para que el host (por ejemplo, el host proxmox, no las máquinas virtuales en sí
mismos!) utilice una vlan dentro del Bridge, usted debe crear los OVSIntPorts.
Estos dividen una interfaz virtual en el vlan especificado al que puede asignar
una dirección IP (o utilizar DHCP). Debe establecer ovs_options tag=$VLAN para
que OVS sepa de qué vlan debe formar parte la interfaz. En el mundo del Switch,
esto se refiere comúnmente como una interfaz RVI (interfaz virtual ruteada), o
IRB (enrutamiento integrado y bridging).
IMPORTANTE: Estos OVSIntPorts que cree también deben aparecer en la definición
real del Bridge bajo ovs_ports. Si no lo hacen, NO se criarán a pesar de que
especificó un ovs_bridge. También debe prefijar la definición con allow-$bridge
$iface
Configurar este puerto vlan tendría este aspecto en /etc/network/interfaces:
allow-vmbr0 vlan50
iface vlan50 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=50
address 10.50.10.44
netmask 255.255.255.0
gateway 10.50.10.1
Árbol de expansión rápida (RSTP)
Open vSwitch es compatible con el Rapid Spanning Tree Protocol, pero está
deshabilitado de forma predeterminada. Rapid Spanning Tree es un protocolo de
red utilizado para prevenir loopes en una red de área local Ethernet
interligada.
ADVERTENCIA: El kernel PVE 4.4 de stock entra en pánico, debe utilizar un
kernel 4.5 o superior para la estabilidad. Además, se sabe que el controlador
Intel i40e no funciona, las NIC Intel de generación anterior que usan ixgbe
están bien, al igual que los adaptadores Mellanox que utilizan el controlador
mlx5.
Para configurar un Bridge para el soporte RSTP, usted debe utilizar un script
"arriba" como las opciones "ovs_options" y "ovs_extras" no emiten los comandos
apropiados. Un ejemplo sería agregar esto a la configuración de la interfaz
"vmbr0":
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
Puede ser prudente establecer también un script "post-up" que duerma durante 10
segundos más o menos esperando en la convergencia RSTP antes de que continúe el
arranque.
Otras opciones de puente que se pueden establecer son:
• other_config:rstp-priority= Configura la prioridad del Root Bridge, cuanto
menor sea el valor, más probable será convertirse en el Root Bridge. Se
recomienda establecer esto en el valor máximo de 0xFFFF para evitar que Open
vSwitch se convierta en el Root Bridge. El valor predeterminado es 0x8000
• other_config:rstp-forward-delay= La cantidad de tiempo que el Bridge se
sentará en modo de aprendizaje antes de entrar en un estado de reenvío. Rango
es 4-30, Predeterminado 15
• other_config:rstp-max-age= El rango es 6-40, predeterminado 20
Usted debe también considerar agregar un valor de costo a todas las interfaces
que son parte de un Bridge. Usted puede hacerlo en la configuración de la
interfaz ethX:
ovs_options other_config:rstp-path-cost=20000
Las opciones de interfaz que se pueden establecer a través de ovs_options son:
• other_config:rstp-path-cost= Predeterminado 2000 para 10GbE, 20000 para 1GbE
• other_config:rstp-port-admin-edge= Establecer en False si se sabe que está
conectado a un Switch que ejecuta RSTP para evitar entrar en estado de reenvío
si no se detectan BDPUs
• other_config:rstp-port-auto-edge= Establecer en False si se sabe que está
conectado a un Switch que ejecuta RSTP para evitar entrar en un estado de
reenvío si no se detecta ningún BDPUs
• other_config:rstp-port-mcheck= Establecido en True si se sabe que el otro
extremo está usando RSTP y no STP, transmitirá BDPUs inmediatamente en la
detección de enlaces
Usted puede mirar el estatus RSTP para una interfaz vía:
ovs-vsctl get Port eth0 rstp_status
NOTA: Open vSwitch no permite actualmente que un bono participe en RSTP.
Nota sobre MTU
Si usted planea utilizar un MTU más grande que el valor predeterminado de 1500,
usted necesita marcar cualquier interfaz física, los bonos, y los Bridges con
un MTU más grande agregando un ajuste mtu a la definición tal como mtu 9000 de
lo contrario será desautorizado.
allow-vmbr0 eth0
iface eth0 inet manual
ovs_mtu 9000
#auto eth1
allow-vmbr0 eth1
iface eth1 inet manual
ovs_mtu 9000
# Interface bond0
auto bond0
allow-vmbr0 bond0
iface bond0 inet manual
ovs_bridge br-ex
ovs_type OVSBond
ovs_bonds eth0 eth1
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
ovs_mtu 9000
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_mtu 9000
Nota impar:Algunas NIC Intel Gigabit más nuevas tienen una limitación de
hardware que significa que la MTU máxima que pueden soportar es 8996 (en lugar
de 9000). Si sus interfaces no están subiendo y usted está tratando de utilizar
9000, esta es probablemente la razón y puede ser difícil de depurar. Intente
establecer todas sus MTU en 8996 y vea si resuelve sus problemas.
Ejemplos
Ejemplo 1: Puente + Puertos internos + Tráfico sin etiquetar
El ejemplo siguiente le muestra cómo crear un Bridge con una interfaz física,
con 2 interfaces vlan divididas, y etiquetando el tráfico sin etiquetar que
entra en el eth0 al vlan1.
Esta es una lista completa y en funcionamiento /etc/network/interfaces:
# Loopback interface
auto lo
iface lo inet loopback
# Bridge for our eth0 physical interfaces and vlan virtual interfaces (our VMs
will
# also attach to this bridge)
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
# NOTE: we MUST mention eth0, vlan1, and vlan55 even though each
# of them lists ovs_bridge vmbr0! Not sure why it needs this
# kind of cross-referencing but it won't work without it!
ovs_ports eth0 vlan1 vlan55
ovs_mtu 9000
# Physical interface for traffic coming into the system. Retag untagged
# traffic into vlan 1, but pass through other tags.
auto eth0
allow-vmbr0 eth0
iface eth0 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
ovs_options tag=1 vlan_mode=native-untagged
# Alternatively if you want to also restrict what vlans are allowed through
# you could use:
# ovs_options tag=1 vlan_mode=native-untagged trunks=10,20,30,40
ovs_mtu 9000
# Virtual interface to take advantage of originally untagged traffic
allow-vmbr0 vlan1
iface vlan1 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=1
address 10.50.10.44
netmask 255.255.255.0
gateway 10.50.10.1
ovs_mtu 1500
# Ceph cluster communication vlan (jumbo frames)
allow-vmbr0 vlan55
iface vlan55 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=55
address 10.55.10.44
netmask 255.255.255.0
ovs_mtu 9000
Ejemplo 2: Bond + Bridge + Puertos internos
En el ejemplo siguiente se muestra una combinación de todas las entidades
anteriores. 2 NIC se unen y se agregan a un puente OVS. 2 las interfaces vlan
se dividen para proporcionar el acceso del host a los vlan con diversos TLC.
Esta es una lista completa y en funcionamiento /etc/network/interfaces:
# Loopback interface
auto lo
iface lo inet loopback
# Bond eth0 and eth1 together
allow-vmbr0 eth0
iface eth0 inet manual
ovs_mtu 9000
#auto eth1
allow-vmbr0 eth1
iface et13 inet manual
ovs_mtu 9000
allow-vmbr0 bond0
iface bond0 inet manual
ovs_bridge vmbr0
ovs_type OVSBond
ovs_bonds eth0 eth1
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
ovs_mtu 9000
# Bridge for our bond and vlan virtual interfaces (our VMs will
# also attach to this bridge)
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
# NOTE: we MUST mention bond0, vlan50, and vlan55 even though each
# of them lists ovs_bridge vmbr0! Not sure why it needs this
# kind of cross-referencing but it won't work without it!
ovs_ports bond0 vlan50 vlan55
ovs_mtu 9000
# Proxmox cluster communication vlan
allow-vmbr0 vlan50
iface vlan50 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=50
address 10.50.10.44
netmask 255.255.255.0
gateway 10.50.10.1
ovs_mtu 1500
# Ceph cluster communication vlan (jumbo frames)
allow-vmbr0 vlan55
iface vlan55 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=55
address 10.55.10.44
netmask 255.255.255.0
ovs_mtu 9000
Ejemplo 3: Bond + Bridge + Puertos internos + Tráfico sin etiquetar + Sin LACP
En el ejemplo siguiente se muestra una combinación de todas las entidades
anteriores. 2 NIC se unen y se agregan a un puente OVS. Este ejemplo imita la
configuración predeterminada de la red proxmox pero usando una unión en lugar
de una sola NIC y la unión funcionará sin un Switch administrado que soporta la
LACP.
Esta es una lista completa y en funcionamiento /etc/network/interfaces:
# Loopback interface
auto lo
iface lo inet loopback
# Bond eth0 and eth1 together
allow-vmbr0 bond0
iface bond0 inet manual
ovs_bridge vmbr0
ovs_type OVSBond
ovs_bonds eth0 eth1
ovs_options bond_mode=balance-slb vlan_mode=native-untagged
# Bridge for our bond and vlan virtual interfaces (our VMs will
# also attach to this bridge)
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports bond0 vlan1
# Virtual interface to take advantage of originally untagged traffic
allow-vmbr0 vlan1
iface vlan1 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options vlan_mode=access
address 192.168.3.5
netmask 255.255.255.0
gateway 192.168.3.254
Ejemplo 4: Árbol de expansión rápida (RSTP) - enlace ascendente de 1 Gbps,
interconexión de 10 Gbps
ADVERTENCIA: El kernel PVE 4.4 de stock entra en pánico, debe utilizar un
kernel 4.5 o superior para la estabilidad. Además, se sabe que el controlador
Intel i40e no funciona, las NIC Intel de generación anterior que usan ixgbe
están bien, al igual que los adaptadores Mellanox que utilizan el controlador
mlx5.
Este ejemplo muestra cómo puede utilizar el Árbol de expansión rápida (RSTP)
para interconectar sus nodos ProxMox de forma barata, y el enlace ascendente a
los switches principales para el tráfico externo, todo mientras mantiene un
esquema de interconexión totalmente tolerante a errores. Esto significa que el
acceso VM<->VM (o posiblemente Ceph<->Ceph) puede funcionar a la velocidad de
las interfaces de red conectadas directamente en una topología de estrella o
anillo. En este ejemplo, estamos usando 10 Gbps para interconectar nuestros 3
nodos (conexión directa), y el vínculo ascendente a nuestros switches
principales a 1 Gbps. Spanning Tree configurado con las métricas de costo
correctas evitará bucles y activará las rutas óptimas para el tráfico.
Obviamente estamos usando esta topología porque los puertos del switch de 10
Gbps son muy caros, así que esto es estrictamente una maniobra de ahorro de
costos. Obviamente podría utilizar puertos de 40 Gbps en lugar de puertos de 10
Gbps, pero lo clave son las interfaces utilizadas para interconectar los nodos
son de mayor velocidad que las interfaces utilizadas para conectarse a los
switches principales.
Esto supone que está utilizando Open vSwitch 2.5+, versiones anteriores no
soportaron Rapid Spanning Tree, pero solo Spanning Tree que tuvo algunos
problemas.
Para explicar mejor lo que estamos logrando, mira esta representación ascii-art
a continuación:
X = 10Gbps port
G = 1Gbps port
B = Blocked via Spanning Tree
R = Spanning Tree Root
PM1-3 = Proxmox hosts 1-3
SW1-2 = Juniper Switches (stacked) 1-2
* NOTE: Open vSwitch cannot do STP on bonded links, otherwise the links to the
core
switches would be bonded in this diagram :/
|-----------------------------|
| G G G | SW1
|-|-----------|-----------|---| R
|-+-----------+-----------+---|
| | G | G | G | SW2
|-+-|---------+-|---------+-|-|
| | | | | |
| | | | | |
| B B B B B
| | | | | |
|--|-|--| | | |--|-|--|
| G GX--------+-+--------XG G |
| X | | | | X |
|------\| | | |/------|
PM1 \ | | / PM3
\ | | B
\ | | /
\|--|-|--|/
\ G G /
|X X|
|-------|
PM2
Esta es una lista completa y en funcionamiento /etc/network/interfaces:
auto lo
iface lo inet loopback
allow-vmbr0 eth0
# 1Gbps link to core switch
iface eth0 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
# Use cost 20000, 40000, 60000 for node 1, 2, 3 (primary 1G port on each
node, in preference order)
ovs_options tag=1 vlan_mode=native-untagged other_config:rstp-enable=true
other_config:rstp-path-cost=20000 other_config:rstp-port-admin-edge=false
other_config:rstp-port-auto-edge=false other_config:rstp-port-mcheck=true
ovs_mtu 8996
allow-vmbr0 eth1
# 1Gbps link to secondary core switch
iface eth1 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
# Use cost 21000, 41000, 61000 for node 1, 2, 3 (secondary 1G port on each
node, in preference order)
ovs_options tag=1 vlan_mode=native-untagged other_config:rstp-enable=true
other_config:rstp-path-cost=21000 other_config:rstp-port-admin-edge=false
other_config:rstp-port-auto-edge=false other_config:rstp-port-mcheck=true
ovs_mtu 8996
allow-vmbr0 eth2
# 10Gbps link to another proxmox/ceph node
iface eth2 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
ovs_options tag=1 vlan_mode=native-untagged other_config:rstp-enable=true
other_config:rstp-path-cost=2000 other_config:rstp-port-admin-edge=false
other_config:rstp-port-auto-edge=false other_config:rstp-port-mcheck=true
ovs_mtu 8996
allow-vmbr0 eth3
# 10Gbps link to another proxmox/ceph node
iface eth3 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
ovs_options tag=1 vlan_mode=native-untagged other_config:rstp-enable=true
other_config:rstp-path-cost=2100 other_config:rstp-port-admin-edge=false
other_config:rstp-port-auto-edge=false other_config:rstp-port-mcheck=true
ovs_mtu 8996
allow-ovs vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports eth0 eth1 eth2 eth3 vlan50 vlan55
# Lower settings for shorter convergence times, we're on a fast network.
# Set the priority high so that it won't be promoted to the STP root
# NOTE: ovs_options and ovs_extra do *not* work for some reason to set the STP
# options.
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
other_config:rstp-priority=32768 other_config:rstp-forward-delay=4
other_config:rstp-max-age=6
ovs_mtu 8996
# Wait for spanning-tree convergence
post-up sleep 10
# Proxmox cluster communication vlan
allow-vmbr0 vlan50
iface vlan50 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=50
address 10.50.30.44
netmask 255.255.255.0
gateway 10.50.30.1
ovs_mtu 1500
# Ceph cluster communication vlan (jumbo frames)
allow-vmbr0 vlan55
iface vlan55 inet static
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=55
address 10.55.30.44
netmask 255.255.255.0
ovs_mtu 8996
En nuestros conmutadores de núcleo Juniper, ponemos en marcha esta
configuración:
set protocols rstp bridge-priority 0
set protocols rstp forward-delay 4
set protocols rstp max-age 6
# ProxMox 1
set protocols rstp interface ge-0/0/2 cost 20000 no-root-port
set protocols rstp interface ge-1/0/2 cost 21000 no-root-port
# ProxMox 2
set protocols rstp interface ge-0/0/3 cost 40000 no-root-port
set protocols rstp interface ge-1/0/3 cost 41000 no-root-port
# ProxMox 3
set protocols rstp interface ge-0/0/4 cost 60000 no-root-port
set protocols rstp interface ge-1/0/4 cost 61000 no-root-port
Inspección:
# Get Bridge info
ovs-vsctl get Bridge vmbr0 rstp_status
# Get Per-Port info
for port in eth0 eth1 eth2 eth3 ; do
echo "==================================="
echo "PORT $port :"
echo ""
ovs-vsctl get Port $port rstp_status
done
multidifusión
En este momento Open vSwitch no hace nada con respecto a la multidifusión.
Normalmente donde usted puede decir linux para habilitar el querier multicast
en el Bridge, usted debe configurar su querier en su router o switch. Consulte
el wiki de Multicast_notes para obtener más información.
Uso de Open vSwitch en Proxmox
El uso de Open vSwitch no es tan diferente del uso de puentes Linux normales.
La diferencia principal es que en lugar de tener un bridge por vlan, usted
tiene un solo Bridge que contiene todos sus vlans. Entonces al configurar la
interfaz de red para la máquina virtual, usted seleccionaría el Bridge
(probablemente el único Bridge que tiene), y usted también ingresaría la
etiqueta VLAN asociada con el VLA N que usted quiere que su máquina virtual sea
una parte de. ¡Ahora no hay ningún esfuerzo al agregar o quitar VLAN!
From: Yunel del Toro Montoya
Sent: Tuesday, April 27, 2021 9:43 AM
To: cubacel@xxxxxxxxxxxxx
Subject: [cubacel] Open vSwitch
Hola:
Alguien ha trabajado con Open vSwitch
que me ayude a crear una configuraciones de Red, bridges sobre vlan y bonds
Gracias
