Я искал в Интернете эту проблему, с которой я столкнулся. Это похоже на этот вопрос: Как именно и конкретно работает хеширование адреса назначения LACP уровня 3?
Моя установка такова: у меня есть центральный коммутатор Procurve 2510G-24, версия образа Y.11.16. Это центр звездообразной топологии, к нему подключены четыре коммутатора через один гигабитный канал. Эти коммутаторы обслуживают пользователей.
На центральном коммутаторе у меня есть сервер с двумя гигабитными интерфейсами, которые я хочу связать вместе, чтобы достичь более высокой пропускной способности, и два других сервера, которые имеют одногигабитные подключения к коммутатору.
Топология выглядит следующим образом:
sw1 sw2 sw3 sw4
| | | |
---------------------
| sw0 |
---------------------
|| | |
srv1 srv2 srv3
На серверах была установлена FreeBSD 8.1. На srv1 я настроил интерфейс lagg, используя протокол lacp, а на коммутаторе я установил магистраль для двух портов, используя lacp. Коммутатор показал, что сервер был партнером lacp, я мог пинговать сервер с другого компьютера, а сервер мог пинговать другие компьютеры. Если бы я отключил один из кабелей, соединение продолжало бы работать, так что все выглядело нормально.
Пока не тестировал пропускную способность. Между srv1 и sw0 использовалась только одна ссылка. Все тесты проводились с помощью iperf, а распределение нагрузки проверялось с помощью systat -ifstat.
Я хотел проверить балансировку нагрузки для операций приема и отправки, так как я хочу, чтобы этот сервер был файловым сервером. Таким образом, было два сценария:
Каждый раз использовалась только одна ссылка. Если бы один кабель был отключен, соединения продолжались бы. Однако после того, как кабель был снова подключен, нагрузка не распределялась.
Каждый сервер может заполнить гигабитную ссылку. В сценариях индивидуального тестирования iperf сообщал о 940 Мбит / с. Использование ЦП составляло около 20%, а это означает, что серверы могли выдержать удвоение пропускной способности.
srv1 - это dell poweredge sc1425 со встроенными сетевыми модулями Intel 82541GI (драйвер em на freebsd). После устранения предыдущей проблемы с тегами vlan поверх интерфейса lagg выяснилось, что em не может это поддерживать. Поэтому я подумал, что, возможно, что-то еще не так с драйверами em и / или стеком lagg, поэтому я запустил backtrack 4r2 на этом же сервере.
Итак, srv1 теперь использует ядро Linux 2.6.35.8. Я установил склеивающий интерфейс bond0. Модуль ядра был загружен с опцией mode = 4, чтобы получить lacp. Коммутатор был доволен ссылкой, я мог пинговать на сервер и с него. Я мог бы даже поместить vlan поверх интерфейса связывания.
Однако решилась только половина проблемы:
Я подумал, что, возможно, мне не повезло и хэши для двух MAC-адресов клиентов были одинаковыми, поэтому я ввел два новых сервера и протестировал их с четырьмя одновременно, и все равно ничего не изменилось. Я попытался отключить и снова включить одну из ссылок, и все, что произошло, - это переключение трафика с одной ссылки на другую и снова обратно на первую. Я также попытался установить магистраль в "простой режим магистрали" на коммутаторе и экспериментировал с другими режимами связывания (roundrobin, xor, alb, tlb), но я никогда не видел распределения трафика.
Но вот что интересно:
один из четырех коммутаторов - Cisco 2950, образ версии 12.1 (22) EA7. Он имеет 48 портов 10/100 и 2 гигабитных восходящих канала. У меня есть сервер (назовите его srv4) с подключенным к нему 4-канальным транком (4x100), выпуск FreeBSD 8.0. Коммутатор подключен к sw0 через гигабит. Если я настраиваю сервер iperf на одном из серверов, подключенных к sw0, а клиент - на srv4, используются ВСЕ 4 ссылки, и iperf сообщает около 330 Мбит / с. systat -ifstat показывает, что используются все четыре интерфейса.
Канал порта cisco использует src-mac для балансировки нагрузки. HP должен использовать как источник, так и место назначения в соответствии с руководством, поэтому он также должен работать. Может ли это означать, что в прошивке HP есть ошибка? Я делаю что-то неправильно?