No modo 5, ou modo balance-tlb, o tráfego de saída usa o endereço MAC da interface escrava que está saindo, em vez de usar o endereço da interface de ligação.
Normalmente, o MAC do vínculo é usado para todo o tráfego, o que pode causar uma condição de oscilação do MAC entre duas portas em um determinado switch - cada um dos switches verá o tráfego de entrada com o MAC do vínculo como origem, ambos da conexão direta para o dispositivo, e da conexão cruzada para o outro switch.
O modo de balanceamento de carga de transmissão contorna esse problema equilibrando a saída de tráfego entre as interfaces, mas usando o endereço MAC da interface como a origem do tráfego de saída. Se os outros nós na sub-rede (particularmente o roteador) não se importarem com esse comportamento, então funcionará bem - normalmente não haverá problema, mas posso imaginar algumas configurações restritivas de segurança do roteador ofendendo-se.
A interface de ligação levará o endereço MAC de uma de suas interfaces escravas:
root@test1:~# ifconfig
bond1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
inet addr:192.168.100.25 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe3d:f735/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
O MAC da eth1 corresponde à interface de ligação, é o "principal", por isso está obtendo o tráfego de entrada.
E apenas para confirmar:
root@test1:~# cat /sys/class/net/bond1/bonding/mode
balance-tlb 5
root@test1:~# cat /sys/class/net/bond1/bonding/active_slave
eth1
Ok, então ... é balanceamento de carga? Aqui está como parece de outro nó, enviando pings constantes:
root@test2:~# tcpdump -e -n -i eth0 proto 1
20:33:08.094078 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 38, length 64
20:33:08.094549 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 38, length 64
20:33:09.094052 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 39, length 64
20:33:09.094520 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 39, length 64
20:33:10.094078 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 40, length 64
20:33:10.094540 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 40, length 64
Tudo parece normal - a eth1 está respondendo. Então, não solicitado, há um switch - observe que o MAC de destino da solicitação e o MAC de origem da resposta não correspondem mais.
20:33:11.094084 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 41, length 64
20:33:11.094614 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 41, length 64
20:33:12.094059 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 42, length 64
20:33:12.094531 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 42, length 64
20:33:13.094086 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 43, length 64
20:33:13.094581 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 43, length 64
Assistindo a um ping constante, os switches entre as fontes continuam arbitrariamente com base na avaliação da carga da interface da ligação - parece reavaliar a cada 10 segundos.
O failover para tráfego de entrada no modo 5 é muito mais básico; quando a interface é detectada como inativa, o MAC da interface de ligação é simplesmente movido para a interface ao vivo. Isso geralmente aciona um aviso de oscilação do MAC nos registros do switch, mas isso é esperado; nada para se preocupar.
Os MACs da interface mudam disso:
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f
.. para, depois de derrubar eth1, isso:
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f
eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
E todas as origens de tráfego da eth2, com um MAC de :35 .
Então, sim - supondo que você não se importa com o balanceamento de carga do tráfego de entrada, o modo balance-tlb parece fazer um excelente trabalho de balanceamento de carga seguro de switch do tráfego de saída e failover do tráfego de entrada.
Se o seu roteador não se importa com vários MACs de origem que enviam tráfego para um único IP, e não fica ofendido com failovers ARP gratuitos, então você deve estar pronto!