Home Linux NETPLAN BONDING

NETPLAN BONDING

by José Luis Sánchez Borque

NETPLAN BONDING

Netplan permite establecer diferentes configuraciones de red que permiten establecer diferentes modos de trabajo para mejorar la disponibilidad (tolerancia a fallos) y ancho de banda de red.

Entendemos por disponibilidad, establecer mecanismos de redundancia con las tarjetas de red para evitar la pérdida de conectividad de un servicio crítico ante la desconexión o avería de una de las tarjetas de red.

Por mejoras en el ancho de banda entendemos la capacidad de trabajar varias tarjetas de red en forma de equipo (TEAM) para aumentar el ancho de banda general del dispositivo. Existen diferentes técnicas, alguna de las cuales requiere configuración expresa en el Switch.

Te dejo en enlace a la explicación de comandos básicos de NETPLAN en caso que no los tengas por la mano Ubuntu 18.04 y NETPLAN. Tutorial rápido de los cambios de NETWORKING

Modos de trabajo con NETPLAN

balance-rr

Política Round-Robin: transmite paquetes en orden secuencial desde el primer esclavo disponible hasta el último. Este modo proporciona equilibrio de carga y tolerancia a fallas.

Active-backup

Política de copia de seguridad activa: solo un esclavo en el enlace está activo. Un esclavo diferente se activa si, y solo si, el esclavo activo falla. La dirección MAC del enlace es visible externamente en un solo puerto (adaptador de red) para evitar confundir al conmutador. Este modo proporciona tolerancia a fallas.

balance-xor

Política XOR: transmisión basada en el recuento de esclavos del módulo [(dirección MAC de origen XOR’d con dirección MAC de destino)]. Esto selecciona el mismo esclavo para cada dirección MAC de destino. Este modo proporciona equilibrio de carga y tolerancia a fallas.

Broadcast

Política de difusión: transmite todo en todas las interfaces esclavas. Este modo proporciona tolerancia a fallas.

802.3ad

IEEE 802.3ad Agregación dinámica de enlaces. Crea grupos de agregación que comparten la misma configuración de velocidad y dúplex. Utiliza todos los esclavos en el agregador activo de acuerdo con la especificación 802.3ad.

Prerrequisitos:

    • Soporte de Ethtool en los controladores base para recuperar la velocidad y el dúplex de cada esclavo.
    • Un conmutador que admite la agregación de enlace dinámico IEEE 802.3ad. La mayoría de los conmutadores requerirán algún tipo de configuración para habilitar el modo 802.3ad.

balance-tlb

Equilibrio de carga de transmisión adaptable: unión de canales que no requiere ningún soporte especial del interruptor. El tráfico saliente se distribuye de acuerdo con la carga actual (calculada en relación con la velocidad) en cada esclavo. El tráfico entrante es recibido por el esclavo actual. Si el esclavo receptor falla, otro esclavo toma la dirección MAC del esclavo receptor fallado.

Prerrequisitos:

    • Soporte de Ethtool en los controladores base para recuperar la velocidad de cada esclavo.

balance-alb

Equilibrio de carga adaptable: incluye balance-tlb más recepción de equilibrio de carga (rlb) para tráfico IPV4, y no requiere ningún soporte especial de conmutador. El equilibrio de carga de recepción se logra mediante negociación ARP. El controlador de enlace intercepta las respuestas ARP enviadas por el sistema local al salir y sobrescribe la dirección de hardware de origen con la dirección de hardware única de uno de los esclavos en el enlace, de modo que diferentes pares usan diferentes direcciones de hardware para el servidor.

Veamos un ejemplo con la política de active-backup.

La configuración es muy sencilla

network:
   version: 2
   renderer: networkd
   ethernets:
      ens33:
         dhcp4: no
         dhcp6: no
      ens38:
         dhcp4: no
         dhcp6: no
   bonds:
      bond-lan:
         dhcp4: yes
         interfaces: [ens33, ens38]
         parameters:
            mode: active-backup
            mii-monitor-interval: 1
            gratuitious-arp: 5
            fail-over-mac-policy: active
            primary: ens33

En la página de NETPLAN REFERENCE encontraremos el significado de cada uno de los parámetros que hemos añadido al fichero de configuración de NETPLAN. Especial atención al parámetro fail-over-mac-policy, que tiene una implicación MUY importante en el comportamiento de la configuración. Al final del POST os explico la importancia de dicho parámetro.

Veamos la configuración IP del servidor y analicemos la información detenidamente.

root@ubutest:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond-lan state UP group default qlen 1000
link/ether 00:0c:29:dd:7c:f4 brd ff:ff:ff:ff:ff:ff
3: ens38: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond-lan state UP group default qlen 1000
link/ether 00:0c:29:dd:7c:fe brd ff:ff:ff:ff:ff:ff
4: bond-lan: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:dd:7c:f4 brd ff:ff:ff:ff:ff:ff
inet 192.168.153.137/24 brd 192.168.153.255 scope global dynamic bond-lan
valid_lft 1058sec preferred_lft 1058sec

Vemos que tanto ens33 como ens38 están UP, y que la nueva tarjeta de red que aparece con el nombre de bond-lan asume la misma MAC (00:0c:29:dd:7c:f4) que el interface activo por defecto establecido con el parámetro primary. Esto es importante, pues cuando “tiremos” la interface ens33, la tarjeta bond-lan asumirá la MAC de la otra tarjeta de red, y por lo tanto a nivel de DCHP se asumirá una nueva dirección IP. Eso implica tirar abajo todas las conexiones existentes.

Este comportamiento es parametrizable con el parámetro fail-over-mac-policy. Dicho parámetro establece la política que asumirá el TEAM cuando la interface caiga. Con el valor active, bond-lan tendrá la misma MAC que la tarjeta que esté activa en cada momento. Lo que implica claramente en caso de dchp cambio de dirección IP, y por lo tanto todas las conexiones activas se pierden.

Está claro que la solución pasa en un servidor por tener una IP estática y no dinámica. Con eso tema resuelto ?. Sería algo tal como esto:

bonds:
   bond-lan:
     dhcp4: no
     dchp6: no
     addresses: [192.168.153.100/24]
     gateway4: 192.168.153.2

Veamos la información que disponemos del bonding en el fichero /proc/net/bonding/bond-lan:

root@ubutest:~# cat /proc/net/bonding/bond-lan

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup) (fail_over_mac active)
Primary Slave: ens33 (primary_reselect always)

Currently Active Slave: ens33
MII Status: up
MII Polling Interval (ms): 10
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: ens38
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:dd:7c:fe
Slave queue ID: 0

Slave Interface: ens33
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:dd:7c:f4
Slave queue ID: 0

Vamos a provocar un fallo desconectando ens33. Vemos que hay un pequeño corte y en apenas 1 segundo el sistema recupera la conectividad.

Si examinamos la nueva configuración IP, vemos ahora que la tarjeta de red activa es ens38, y sobre todo que bond-lan tiene ahora una nueva IP debido a que asume la MAC de ens38. TODAS las conexiones a tomar viento….. (recuerda que si pones una IP estática tema resuelto)

root@ubutest:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever

2: ens33: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc fq_codel mast er bond-lan state DOWN group default qlen 1000
link/ether 00:0c:29:dd:7c:f4 brd ff:ff:ff:ff:ff:ff

3: ens38: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond-lan state UP group default qlen 1000
link/ether 00:0c:29:dd:7c:fe brd ff:ff:ff:ff:ff:ff

4: bond-lan: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue sta te UP group default qlen 1000
link/ether 00:0c:29:dd:7c:fe brd ff:ff:ff:ff:ff:ff
inet 192.168.153.139/24 brd 192.168.153.255 scope global dynamic bond-lan
valid_lft 1599sec preferred_lft 1599sec
inet6 fe80::20c:29ff:fedd:7cf4/64 scope link
valid_lft forever preferred_lft forever

Vemos la nueva información proporcionada por el sistema:

root@ubutest:~# cat /proc/net/bonding/bond-lan

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup) (fail_over_mac active)
Primary Slave: ens33 (primary_reselect always)

Currently Active Slave: ens38
MII Status: up
MII Polling Interval (ms): 10
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: ens38
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:dd:7c:fe
Slave queue ID: 0

Slave Interface: ens33
MII Status: down
Speed: Unknown
Duplex: Unknown
Link Failure Count: 2
Permanent HW addr: 00:0c:29:dd:7c:f4
Slave queue ID: 0

CONFIGURACIÓN CON IP MANUAL

Os adjunto ejemplo con la configuración estática de los parámetros IP de tal forma que cuando un interface falle, la IP se mantiene y no hay caída de los posibles servicios de red configurados en el servidor.

network:
   version: 2
   renderer: networkd
   ethernets:
      ens33:
         dhcp4: no
         dhcp6: no
      ens38:
         dhcp4: no
         dhcp6: no
      bonds:
   bond-lan:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.153.10/24]
      gateway4: 192.168.153.2
      nameservers:
         addresses: [8.8.8.8]
      interfaces: [ens33, ens38]
      parameters:
         mode: active-backup
         mii-monitor-interval: 1
         gratuitious-arp: 5
         fail-over-mac-policy: active
         primary: ens33

Tal como indicamos a continuación, y dado que estamos trabajando en un entorno virtualizado hemos de configurar el parámetro fail-over-mac-policy con el valor active para evitar problemas con la MAC y nuestro hipervisor ( Virtualbox o VMware )

CONFIGURACIÓN CON fail-over-mac-policy: none

Alguno se preguntará si no hay forma de cambiar el comportamiento del bonding en caso de configuración por DHCP. Es decir, teníamos le problema que cuando una tarjeta se desconecta, el bonding asume la MAC de la otra tarjeta, con lo que por DCHP hay un cambio de dirección IP al asignarle una nueva por el cambio de MAC. Esto es así por el parámetro:

fail-over-mac-policy: active

Si establecemos el valor a none, o bien por defecto comentamos la línea, el bonding asume nueva nueva MAC para los tres interfaces: ens33, ens38 y bond-lan. Por lo tanto tema resuelto, es decir, aunque desconectemos cualquier de los interfaces, ens33 o ens38, la IP asignada por dhcp no cambia al ser la misma para los tres dispositivos.

Vemos en la imagen adjunto el mismo valor MAC para los tres interfaces. Fijaros que no me asigna IP….. Os lo explico en un segundo.

Y ahora viene la gran pregunta….

¿Para que me he complicado la vida estableciendo el parámetro con el valor active en vez de none?

Pues muy sencillo…. Estoy trabajando en un entorno virtualizado… Tanto es si es VMware Workstation o VirtualBOX. El hipervisor da error al detectar la misma MAC en varios interfaces de red diferente, y por lo tanto he tenido que configurar el valor a active para poder hacer la demo. Fijaros que en caso contrario ni me asigna IP (ver imagen superior)

Os adjunto error que me da el hipervisor con la configuración establecida a none:

Adapter ‘Ethernet0’ may not have network connectivity.MAC address D6:BB:D7:96:D6:AF of adapter ‘Ethernet0’ is within the reserved address range or is in use by another virtual adapter on your system.

Adapter ‘Ethernet0’ may not have network connectivity….

En una máquina física podéis establecer el parámetro a none si problemas, pero insisto que la solución en un servidor pasa por establecer una IP fija.

Os dejo un vídeo de mi canal con todo lo explicado. Espero os sirva.

 

You may also like

Leave a Comment