Una técnica muy utilizada para proporcionar mayor disponibilidad y capacidad a la conexión entre dos equipos consiste en utilizar simultáneamente varios enlaces físicos entre ambos, formando un grupo de agregación de enlaces o LAG (Link Aggregation Group). LAG considero que es el término más correcto, aunque también son conocidos como port channel en el mundo de las redes o bonding en el mundo GNU/Linux. También, aunque de forma incorrecta en mi opinión, se les llama a veces trunk (de una tecnología propietaria llamada port trunking), esto a mí me resulta ambiguo, porque el uso más generalizado del término es para referrirse a un puerto de un switch por el que se permite tráfico de varias VLAN.

El caso es que para proporcionar mayor ancho de banda a un nuevo servidor de ficheros se quiere establecer un LAG entre este y el correspondiente conmutador (bonito término castellano para un switch). Esto, en principio, es bastante sencillo, sobre todo teniendo en cuenta que el servidor corre un Red Hat Enterprise Linux 7.3 (suficientemente moderno, su núcleo es la versión 3.10 de Linux) y el switch es un Cisco que ha costado más de lo que amortizo de hipoteca en un año.

Para establecer el LAG entre el servidor y el switch se va a utilizar el protocolo LACP (Link Aggregation Control Protocol), soportado por ambos.

El switch se configura creando un nuevo interfaz del tipo PortChannel, que será un interfaz virtual que representa al grupo de agregación, y añadiendo los interfaces físicos a utilizar a dicho grupo.

Aquí llamaremos al port channel port-channel1 (Po1 para los amigos) y añadiremos a su grupo los interfaces Ethernet1/1 al Ethernet1/4.

interface Po1

interface Eth1/1 - 4
  channel-group 1

Con esto es suficiente, ya que aunque hay varias formas de establecer el LAG, el modelo de switch utilizado usa el protocolo LACP por defecto. Como se verá más adelante, suponer que LACP era utilizado por defecto fue la causa del problema.

En el servidor se hace de forma similar creando un ficheo de configuración para el bonding que llamaremos bond0 y cambiando la configuración de los interfaces físicos a añadir al LAG.

/etc/sysconfig/network-scripts/ifcfg-bond0:

TYPE=Bond
BOOTPROTO=none
NAME=bond0
DEVICE=bond0
ONBOOT=yes
BONDING_MASTER=yes
IPADDR=192.168.10.10
GATEWAY=192.168.10.1
PREFIX=24
BONDING_OPTS="mode=4 miimon=100 lacp_rate=1"

Aquí es necesario indicar el modo del bonding, ya que soporta varios tipos de funcionamiento, el modo 4 utilizado es el que corresponde al protocolo 802.3ad, es decir LACP. El parámetro miimon indica cada cuantos milisegundos se debe comprobar si un interfaz del bonding tiene enlace, si se detecta que no tiene enlace será extraído del LAG inmediatamente. El parámetro lacp_rate indica cada cuantos segundos se envía un paquete de control de LACP (LACPDU).

Los interfaces miembro del LAG se configuran así:

/etc/sysconfig/network-scripts/ifcfg-eth0

TYPE=Ethernet
BOOTPROTO=none
NAME=eth0
DEVICE=eth0
ONBOOT=yes
MASTER=bond0
SLAVE=yes

Una vez configurados los interfaces del servidor (habrá que reiniciar los servicios de red) y el switch se debe establecer el LAG entre ambos.

Para ver el estado del interfaz bond0 se puede consultar el fichero /proc/net/bonding/bond0, aunque también podemos obtener suficiente información con un simple listado de los interfaces:

#ip link
...
8: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
9: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
...

Aquí se ve que hay dos interfaces eth0 y eth1 en modo SLAVE (parte de un bonding) y que hay un interfaz en modo MASTER (el bonding), todos están UP (tienen enlace) y todos tienen la misma MAC (como debe ser), ya que todos los interfaces físicos actúan «en representación» del interfaz de bonding.

En el switch también parece estar todo bien:

#sh int Po1
port-channel1 is up
admin state is up,
  Hardware: Port-Channel, address: a4bd.c6db.aac9 (bia a4bd.c6db.aac9)
  MTU 1500 bytes, BW 20000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, medium is broadcast
  Port mode is access
  full-duplex, 10 Gb/s
  Input flow-control is off, output flow-control is off
  Auto-mdix is turned off
  Switchport monitor is off
  EtherType is 0x8100
  Members in this channel: Eth1/1, Eth1/2, Eth1/3, Eth1/4
  Last clearing of "show interface" counters never
  1 interface resets
  30 seconds input rate 2328 bits/sec, 1 packets/sec
  30 seconds output rate 2520 bits/sec, 1 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 12.83 Mbps, 1.02 Kpps; output rate 139.13 Kbps, 181 pps
  RX
    2705286 unicast packets  3316 multicast packets  3932 broadcast packets
    2712534 input packets  3986560464 bytes
    0 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 Rx pause
  TX
    510610 unicast packets  29736 multicast packets  3699 broadcast packets
    544045 output packets  53042671 bytes
    0 jumbo packets
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard
    0 Tx pause

En esta información lo importante es que el port channel está UP y que el ancho de banda del mismo es 20.000.000 Kbit. El ancho de banda indica que hay dos puertos, de los cuatro que son miembros del port channel, que están conectados (se trata de puertos de 10 Gbps).

Viendo esto todo parece estar bien, sin embargo, al hacer un ping a otro equipo que se envía por dicho interfaz resulta que no hay respuesta:

# ping 192.168.10.20
PING 192.168.10.20 (192.168.10.10) 56(84) bytes of data.
From 192.168.10.10 icmp_seq=1 Destination Host Unreachable
From 192.168.10.10 icmp_seq=2 Destination Host Unreachable

Habrá que investigar, para ello lo primero comprobar qué pasa por el interfaz bond0:

# tcpdump -nn -i bond0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:59:12.717212 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
11:59:13.719184 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

Y así sucesivamente, es decir, los ARP no obtienen respuesta, pero eso ¿por qué? Indaguemos un poco más y veamos el tráfico en cada interfaz:

# tcpdump -nn -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:01:53.985192 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
12:01:54.987189 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

Vale, el bond0 está utilizando el interfaz eth0 para envíar las consultas ARP y no obtiene respuesta. Veamos entonces si hay algo extraño en el eth1:

# tcpdump -nn -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:21.343287 ARP, Reply 192.168.10.20 is-at a0:d6:cf:d0:32:b0, length 46
12:03:22.940519 ARP, Reply 192.168.10.20 is-at a0:b6:cf:d0:32:b0, length 46

Bueno, no es muy extraño, la política de reparto de carga entre los enlaces no es la misma en el switch que en el servidor, por lo que el servidor envía una consulta ARP por un interfaz y la recibe por el otro. A mí me parece normal.

Entonces, ¿por qué no pasan las respuetas ARP del interfaz eth1 al bond0? Pues porque el bonding está medio sordo. Pero, ¿por qué está medio sordo el bonding?

Comienza la investigación por el Interné: Google, a ver qué encuentras sobre esto: «Linux bonding medio sordo». Pero parece que nadie ha escrito aún sobre esto, bueno a ver en inglés: «Linux bonding half deaf». Tampoco.

En fin, toca leer la documentación del módulo de bonding y relacionada. Así, que tras no encontrar nada muy claro y buscar de todo relacionado con el bonding y 802.3ad dí con el artículo que me dio la clave (aunque trataba de otro problema): [Linux Bonding] 802.3ad bond interface has shown RX dropped packets.

En ese artículo hablaba de que el bonding, de manera premeditada y (en otros casos, desde luego) correcta, descartaba los paquetes recibidos por los interfaces no activos del bonding. Esto está muy bien cuando el modo del bonding es tal que unos interfaces están activos y otros no, que no es el caso del modo 4, 802.3ad o LACP.

Lo importante es que daba la clave de como evitar eso, el parámetro all_slaves_active. Así, estableciendo ese parámetro a uno se puede hacer un apaño y permitir que los paquetes recibidos por el interfaz eth1 sean admitidos y lleguen como recibidos por el interfaz bond0.

# echo 1 > /sys/class/net/bond0/bonding/all_slaves_active

Pero, como he dicho, eso es solo un apaño, ya que el problema de fondo aún está ahí. ¿Y cuál es ese problema? Pues que el bond0 no considera activo el interfaz eth1, pasa de él, como se deduce de lo siguiente:

# ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

El ancho de banda del interfaz es 10.000Mbps, es decir, lo que da un interfaz. Si estuviera utilizando los dos sería 20.000Mbps, como se vió en el estado del LAG en el lado del switch.

Por tanto el switch ha activado ambos enlaces del LAG (como se ve al recibir tráfico por los dos interfaces en el servidor), pero el servidor solo ha activado uno.

Mirando el detalle del estado del bonding se ve lo siguiente:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 13
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: churned
Actor Churned Count: 0
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 77
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

Slave Interface: eth1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 1
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 69
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

Una mente avezada no hubiera pasado por alto (al contrario de como hice yo inicialmente) la discordancia en los «Aggregator ID» de ambos interfaces miembros del bonding. Estaba empeñado en que la culpa era de la configuración del bonding pero, preguntándole a Google por qué puede haber diferentes aggregator ID, me dice un par de cosas. En StackExchange ya me confirman algo que no terminaba de interpretar correctamente en la documentación del bonding, y es que los diferentes aggregator ID están destinados a hacer grupos de interfaces separados dentro del bonding, utilizando solo uno de ellos. Esto me hace pensar que, tal vez, el switch esté haciendo algo mal.

La confirmación de esto la tuve en esta entrada del foro de CentOS, Only 1 NIC used in the bond, ahí se apuntaba a una entrada de un blog en la que se trataba otro síntoma, la MAC 00:00:00:00:00:00 del otro extremo. En esta entrada se remarca en negrita que lo que hay que hacer es comprobar que el port channel está en modo activo (LACP). Así que fui a hacer la comprobación:

# show port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 2 ports up
    First operational port is Ethernet1/1
    Age of the port-channel is 0d:20h:20m:41s
    Time since last bundle is 0d:20h:20m:51s
    Last bundled member is Ethernet1/4
    Ports:   Ethernet1/1    [on] [up]
             Ethernet1/2    [on] [up] *
             Ethernet1/3    [on] [down]
             Ethernet1/4    [on] [down]

 Había supuesto erróneamente que el modo por defecto era LACP, cuando en realidad era ON. En el modo on el switch simplemente añade los puertos al port channel si tienen enlace, sin más. Por tanto para el switch los dos puertos conectados al servidor formaban parte del port channel y, consecuentemente repartía el tráfico de salida entre ellos. Pero como el servidor estaba en modo LACP y no lograba negociar la agregación con este protocolo, asigna cada interfaz a un grupo de agregación distinto y utiliza solo uno de los grupos, formado por un solo interfaz.

La solución parecía ya al alcance de las manos.

# configure terminal
(config)# interface Eth1/1 - 4
(config-if-range)# no channel-group 1
(config-if-range)# channel-group 1 mode active
LACP process needs to be started before configuring active or passive mode

Resulta que ni siquiera estaba activada la capacidad LACP en el switch. En NX-OS la mayoría de capacidades del switch vienen desactivadas por defecto y hay que activarlas antes de utilizarlas. Activémosla pues y repitamos:

(config)# feature lacp
(config)# interface Eth1/1 - 4
(config-if-range)# channel-group 1 mode active
(config-if-range)# sh port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 0 ports up
    Age of the port-channel is 0d:20h:34m:57s
    Time since last bundle is 0d:00h:00m:48s
    Last bundled member is Ethernet1/1
    Time since last unbundle is 0d:00h:04m:50s
    Last unbundled member is Ethernet1/4
    Ports:   Ethernet1/1    [active ] [up]
             Ethernet1/2    [active ] [up] *
             Ethernet1/3    [active ] [down]
             Ethernet1/4    [active ] [down]
(config-if-range)# copy running-config startup-config
[########################################] 100%
Copy complete, now saving to disk (please wait)...

Ahora.

Comprobemos el otro lado:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 13
        Partner Key: 110
        Partner Mac Address: 00:01:02:03:aa:fc

Slave Interface: p4p1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 1
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 389
    port state: 61

Slave Interface: p4p2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 2
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 385
    port state: 61
# ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 20000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

Todo listo, ambos interfaces en el mismo grupo de agregación, el ancho de banda de ambos interfaces agregado al bonding y la MAC del switch detectada.

¡El bonding ya no está medio sordo!

Ya se puede desactivar el apaño del all_slaves_active, el LAG está ya funcionando correctamente (aunque esta configuración no era persistente).

# echo 0 > /sys/class/net/bond0/bonding/all_slaves_active

Otras referencias:

Para entender el significado de los estados de los interfaces del bonding (port state) ver las definiciones AD_STATE_… en el código del fichero bond_3ad.c.

El estado mostrado en /proc/net/bonding/bond0 es la representación en decimal del resultado de unir (OR) los valores que corresponden al estado del puerto según las definiciones encontradas en dicho código fuente. Es decir, cuando se estableció correctamente el LAG, el estado del bonding era 61 = 0x3d = 0x20+ 0x10 + 0x08 + 0x04 + 0x01 = DISTRIBUTING + COLLECTING + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY.

Antes, cuando el bonding estaba medio sordo, un interfaz del bonding estabe en estado 77 = 0x4d = 0x40 + 0x08 + 0x04 + 0x01 = DEFAULTED + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY. El otro puerto estaba en estado 69 = 0x45 = 0x40 + 0x04 + 0x01 = DEFAULTED + AGGREGATION + LACP_ACTIVITY.