Hay dos están interconectados Cisco WS-2950T.

Mediante el puerto GBIC del primer conmutador se conectó una primera NIC de interfaz de vinculación, y mediante el puerto GBIC del segundo conmutador se conectó una segunda NIC de interfaz de vinculación.

Por supuesto, ambos conmutadores ven la dirección MAC de enlace solo en una interfaz (por ejemplo, es GBIC en el primer conmutador) y todo el tráfico entrante para la interfaz de enlace pasa a través de este GBIC.

Pero en "mode = 5" todo el tráfico saliente se distribuye entre todas las interfaces que hacen enlace. En este caso, los paquetes se eliminarán del segundo conmutador y, de todos modos, ¿pasarán por el primer conmutador? ¿O la división estará funcionando?

answer

En el modo 5, o modo balance-tlb, el tráfico saliente usa la dirección MAC de la interfaz esclava que está dejando, en lugar de usar la dirección de la interfaz de enlace.

Por lo general, la MAC del enlace se usa para todo el tráfico, lo que puede causar una condición de aleteo de MAC entre dos puertos en un conmutador determinado; cada uno de sus conmutadores verá el tráfico entrante con la MAC del enlace como fuente, tanto desde la conexión directa al dispositivo y de la conexión cruzada al otro conmutador.

El modo de equilibrio de carga de transmisión evita este problema equilibrando el tráfico saliente entre las interfaces, pero utilizando la dirección MAC de la interfaz como origen del tráfico saliente. Si a sus otros nodos en la subred (particularmente al enrutador) no les importa este comportamiento, entonces funciona bien; por lo general, no habrá ningún problema, pero puedo imaginar que algunas configuraciones de seguridad restrictivas del enrutador se ofendan.

La interfaz de enlace tomará la dirección MAC de una de sus interfaces esclavas:

[email protected]:~# 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

El MAC de eth1 coincide con la interfaz de enlace, es el "principal", por lo que recibe el tráfico entrante.

Y, solo para confirmar:

[email protected]:~# cat /sys/class/net/bond1/bonding/mode
balance-tlb 5

[email protected]:~# cat /sys/class/net/bond1/bonding/active_slave
eth1

Ok, entonces ... ¿está balanceando la carga? Así es como se ve desde otro nodo, enviando pings constantes:

[email protected]:~# 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

Todo parece normal: eth1 está respondiendo. Luego, de forma espontánea, hay un interruptor: observe que el MAC de destino de la solicitud y el MAC de origen de la respuesta ya no coinciden.

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

Al observar un ping constante, los conmutadores entre la fuente continúan arbitrariamente en función de la evaluación de la carga de la interfaz de enlace; parece volver a evaluarse cada 10 segundos.


La conmutación por error para el tráfico entrante en el modo 5 es mucho más básica; cuando se detecta que la interfaz está inactiva, el MAC de la interfaz de enlace simplemente se mueve a la interfaz en vivo. Esto a menudo activará una advertencia de aleteo de MAC en los registros de su conmutador, pero eso es de esperar; nada de que preocuparse.

Las MAC de la interfaz cambian a partir de esto:

eth1      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35
eth2      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:3f

..to, después de eliminar eth1, esto:

eth1      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:3f
eth2      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35

Y todas las fuentes de tráfico de eth2, con una MAC de :35.


Entonces, sí, asumiendo que no le importa el equilibrio de carga del tráfico entrante, el modo balance-tlb parece hacer un excelente trabajo en el equilibrio de carga seguro para conmutadores del tráfico saliente y la conmutación por error del tráfico entrante.

Si a su enrutador no le importan los MAC de múltiples fuentes que envían tráfico para una sola IP y no se ofende con las fallas ARP gratuitas, ¡entonces debería estar listo!