Hola a todos,

Hoy vengo con un articulo que mezcla algo de hard y algo de soft. A día de hoy, con el auge de los entornos virtuales, es relativamente sencillo montar máquinas virtuales (también es aplicable a las físicas) con varias tarjetas de red. De hecho en VirtualBox, que es el software de servidor que empleo para la creación de dichas máquinas, se pueden crear hasta 4 interfaces, que yo sepa, por máquina.

En mi caso, la primera vez que vi un interfaz de este tipo fué en una NAS de Netgear. Me pareció curioso cómo empleaba las interfaces físicas para proporcionar diversos servicios, entre otros equilibrio de carga adaptativo, o simplemente failover. En cualquiera de los casos, me quede con la copla y ahora lo he trasladado a ciertas máquinas para lograr esa misma funcionalidad.

¿Que significa?

¿Bueno, cómo podríamos definir un interfaz bonded?, pues simplemente como una agrupación lógica de interfaces de red físicos que son agrupados con una finalidad, normalmente o bien por cuestiones de rendimiento o bien por cuestiones de disponibilidad o por ambas cosas como veremos más adelante.

Como ejemplo del primero de los casos, dos interfaces físicas de red, unidas lógicamente, pueden transmitir / recibir paquetes de forma simultánea y balancear la carga en base a la situación de cada una de ellas.

Como ejemplo del segundo de los casos lo más habitual es mantener un interfaz en funcionamiento normal y tener otro de reserva para el caso de que el primero falle.

¿Que necesitamos?

Bueno, pues necesitamos una máquina con al menos dos tarjetas de red. En el caso que nos ocupa, yo tengo varias máquinas virtuales con varias de ellas. Emplearemos una de ellas para mostrar la configuración.

En la captura siguiente podéis apreciar la máquina con 4 tarjetas de red. Luego veremos en detalle su configuración en debian.

¿Para que podemos emplearlo?

Ya lo he comentado en puntos anteriores, por cuestiones de rendimiento o simplemente por cuestiones de disponibilidad física. Esto realmente se corresponde con lo que en el driver se denomina política y puede tener los siguientes valores:

• balance-rr (0): clásica política round robin, transmite los paquetes en orden secuencial empleado todas los interfaces esclavos existentes. Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
• active-backup (1): Solo uno de los interfaces esclavos se encuentra activo. El otro solo pasa a activo en el caso de que el primero falle. Este modo solo provee tolerancia a fallos.
• balance-xor (2): basa la transmisión en los hash de los direcciones origen y destino de los paquetes. El algoritmo por defecto solo considera para el calculo direcciones MAC. Todo esto dicho de otra forma mas entendible, permite emplear cada uno de los esclavos para las comunicaciones con ciertas máquinas, de esta forma separando de alguna manera la transmisión. Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
• broadcast (3): Transmite todos los paquetes por todas las interfaces. Este modo solo proporciona tolerancia a fallos.
• 802.3ad (4): crea grupos de interfaces que comparten velocidad y tipo de transmisión. Emplea todos los esclavos que pertenecen al grupo conforme a la especificación 802.3ad.  Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
• balance-tbl (Adaptive transmit load balancing) (5): Es un modo que no requiere ningún tipo de soporte por parte de los switch de red, al contrario que en el caso anterior. Los paquetes que son transmitidos a la red se envian por los esclavos dependiendo de la carga de cada uno de ellos. El tráfico de entrada solo es recibido por uno de los interfaces. En el caso de que este de entrada falle, es empleado el otro directamente. Este modo soporta tanto balanceo de carga como tolerancia a fallos.
• balance-alb (Adaptive load balancing) (6): Es un modo que no requiere ningún tipo de soporte por parte de los switch de red, e incluye tanto TLB de salida como balanceo de entrada. Para ello emplea paquetes ARP. Este modo soporta tanto balanceo de carga como tolerancia a fallos.

En base a los modos que acabo de indicar, creo que el lector ya se estará haciendo una idea de para que podemos querer configurar un interfaz de este tipo.

Configuración en debian

Bien, dicho lo dicho pasemos a ver cómo configurar un par de bonded. En el caso que voy a poner de ejemplo, como ya se ha comentado, la máquina virtual cuenta con cuatro tarjetas de red. ¿Y para que cuatro?, bien, es una máquina especial, dedicada a hacer copias de seguridad a traves de la LAN, y para ello he destinado dos tarjetas de red para la red interna y dos mas para la red externa. De esta forma logro que el tiempo que la máquina se encuentra haciendo la copia de seguridad a traves de la LAN emplee solo uno de los interfaces bonded y para el uso de otros servicios emplee el otro interfaz, logrando de esta forma mejorar la velocidad de la copia, al menos, es el objetivo aunque realmente no he hecho pruebas de rendimiento. Debemos tener en cuenta que este escenario de ejemplo poca ventaja va a sacar de la configuración, pues por debajo de la máquina virtual solo existe un host con una tarjeta de red, pero si en vuestro caso disponéis de máquinas con varias interfaces físicas seguro que os podéis beneficiar.

Existen varias alternativas para configurar los interfaces bounded, en mi caso el que uso es el siguiente:

• uso del paquete ifenslave, para ello procedemos a su instalación
• A continuación procedemos a su configuración que la realizaremos en el propio fichero /etc/network/interfaces. En este fichero se definen las cuatro interfaces esclavas y las dos bonded, asociando de dos en dos a las bonded. En mi caso el fichero queda de la siguiente forma:

root@clonezillaServer:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
bond-master bond0
bond-primary eth0
bond-mode balance-alb

auto eth1
iface eth1 inet manual
bond-master bond0
bond-primary eth0
bond-mode balance-alb

auto eth2
iface eth2 inet manual
bond-master bond1
bond-primary eth2
bond-mode balance-alb

auto eth3
iface eth3 inet manual
bond-master bond1
bond-primary eth2
bond-mode balance-alb

# Define master
auto bond0
iface bond0 inet dhcp
bond-slaves none
bond-primary eth0
bond-mode balance-alb
bond-miimon 100

# Define master
auto bond1
iface bond1 inet dhcp
bond-slaves none
bond-primary eth2
bond-mode balance-alb
bond-miimon 100

En estas condiciones si hago un ifconfig de la máquina podremos ver que las direcciones IP de la LAN las han tomado los interfaces bonded en lugar de los «físicos». Interesante tambien fijarse, que los interfaces bond han heredado la MAC de la tarjeta ethx definida como primary en cada una de las interfaces bonded.

root@clonezillaServer:~# ifconfig -a
bond0 Link encap:Ethernet HWaddr 08:00:27:a3:9e:92
inet addr:192.168.3.97 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fea3:9e92/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:944 errors:0 dropped:164 overruns:0 frame:0
TX packets:599 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:234249 (228.7 KiB) TX bytes:48053 (46.9 KiB)

bond1 Link encap:Ethernet HWaddr 08:00:27:8a:d2:11
inet addr:192.168.3.76 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe8a:d211/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:450 errors:0 dropped:164 overruns:0 frame:0
TX packets:546 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:48636 (47.4 KiB) TX bytes:39482 (38.5 KiB)

eth0 Link encap:Ethernet HWaddr 08:00:27:a3:9e:92
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:744 errors:0 dropped:0 overruns:0 frame:0
TX packets:326 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:214241 (209.2 KiB) TX bytes:28048 (27.3 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:d5:97:7c
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:200 errors:0 dropped:164 overruns:0 frame:0
TX packets:273 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20008 (19.5 KiB) TX bytes:20005 (19.5 KiB)

eth2 Link encap:Ethernet HWaddr 08:00:27:8a:d2:11
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:243 errors:0 dropped:0 overruns:0 frame:0
TX packets:293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:28208 (27.5 KiB) TX bytes:22950 (22.4 KiB)

eth3 Link encap:Ethernet HWaddr 08:00:27:2d:e4:a4
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:207 errors:0 dropped:164 overruns:0 frame:0
TX packets:253 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20428 (19.9 KiB) TX bytes:16532 (16.1 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:70 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4944 (4.8 KiB) TX bytes:4944 (4.8 KiB)

Conclusiones

Pues por mi parte poco más que añadir. Si estáis interesados en el asunto, hay multitud de información en inet sobre el mismo, bastante más completa y detallada que este articulo.

Mi idea era simplemente trasladaros esta posibilidad, para que vosotros mismos a partir de este momento podáis buscar la información que estiméis conveniente e implementéis este tipo de interfaz en los casos que estiméis conveniente.

Fuentes de información

• https://wiki.debian.org/Bonding
• https://www.kernel.org/doc/Documentation/networking/bonding.txt
• https://en.wikipedia.org/wiki/Link_aggregation
• http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html#wp1111405
• https://en.wikipedia.org/wiki/Address_Resolution_Protocol