Есть два взаимосвязанный Cisco WS-2950T.
Через один порт GBIC на первый переключатель подключен первый NIC интерфейса связывания и одним портом GBIC на второй переключатель подключен второй Сетевая карта интерфейса связывания.
Конечно, оба коммутатора видят связанный MAC-адрес только на одном интерфейсе (например, это GBIC на первый переключатель) и все входящий трафик для интерфейса связывания проходит через этот GBIC.
Но в «mode = 5» все исходящий трафик распределяется между всеми интерфейсами, которые создают связь. В этом случае пакеты будут отброшены из второй переключатель и в любом случае будет проходить через первый переключатель? Или дивизия будет работать?
В режиме 5 или режиме balance-tlb исходящий трафик использует MAC-адрес подчиненного интерфейса, который он оставляет, вместо использования адреса интерфейса связи.
Как правило, MAC-адрес связи используется для всего трафика, что может вызвать состояние переключения MAC-адресов между двумя портами на данном коммутаторе - каждый из ваших коммутаторов будет видеть входящий трафик с MAC-адресом связи в качестве источника, как при прямом подключении к устройству. , и от кросс-коммутации к другому коммутатору.
Режим балансировки нагрузки при передаче обходит эту проблему, балансируя исходящий трафик между интерфейсами, но используя MAC-адрес интерфейса в качестве источника для исходящего трафика. Если другие ваши узлы в подсети (в частности, маршрутизатор) не возражают против такого поведения, тогда оно работает нормально - обычно проблем не возникает, но я могу представить себе, что некоторые ограничительные настройки безопасности маршрутизатора обидятся.
Интерфейс связи примет MAC-адрес одного из своих подчиненных интерфейсов:
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
MAC-адрес eth1 соответствует интерфейсу связи, он «первичный», поэтому он получает входящий трафик.
И, чтобы подтвердить:
root@test1:~# cat /sys/class/net/bond1/bonding/mode
balance-tlb 5
root@test1:~# cat /sys/class/net/bond1/bonding/active_slave
eth1
Хорошо, так .. это балансировка нагрузки? Вот как это выглядит с другого узла, отправляя постоянные пинги:
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
Все выглядит нормально - eth1 отвечает. Затем без подсказки появляется переключатель - обратите внимание, что MAC-адрес назначения запроса и MAC-адрес источника ответа больше не совпадают.
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
Наблюдая за постоянным пингом, переключение между источником продолжается произвольно на основе оценки нагрузки интерфейсом связи - кажется, что она пересматривается каждые 10 секунд.
Аварийное переключение для входящего трафика в режиме 5 гораздо проще; когда интерфейс обнаруживается как неработающий, MAC связанного интерфейса просто перемещается на рабочий интерфейс. Это часто вызывает предупреждение о смене MAC в журналах коммутатора, но этого следовало ожидать; не о чем беспокоиться.
MAC-адреса интерфейса меняются следующим образом:
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f
..to, после отключения eth1, это:
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f
eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
И все источники трафика от eth2 с MAC :35.
Итак, да - при условии, что вы не заботитесь о балансировке нагрузки входящего трафика, режим balance-tlb, кажется, отлично справляется с безопасным переключением балансировки нагрузки исходящего трафика и аварийным переключением входящего трафика.
Если ваш маршрутизатор не заботится о нескольких исходных MAC-адресах, отправляющих трафик для одного IP-адреса, и не обижается на бесплатную отработку отказа ARP, тогда все готово!