+--------+
| Host A |
+----+---+
| eth0 (AA:AA:AA:AA:AA:AA)
|
|
+----+-----+
| Switch 1 | (layer2/3)
+----+-----+
|
+----+-----+
| Switch 2 |
+----+-----+
|
+----------+----------+
+-------------------------+ Switch 3 +-------------------------+
| +----+-----------+----+ |
| | | |
| | | |
| eth0 (B0:B0:B0:B0:B0:B0) | | eth4 (B4:B4:B4:B4:B4:B4) |
| +----+-----------+----+ |
| | Host B | |
| +----+-----------+----+ |
| eth1 (B1:B1:B1:B1:B1:B1) | | eth5 (B5:B5:B5:B5:B5:B5) |
| | | |
| | | |
+------------------------------+ +------------------------------+
Я долго исследовал это и не нашел ответа. В документации указано, что при использовании режима 6 связывания интерфейса Linux (balance-alb) никаких изменений переключателя не требуется. Это происходит из-за того, что хост B не отправляет никаких дополнительных пакетов из eth5, тогда как в нормальных условиях ожидается, что это произойдет? Одно из решений - настроить задание cron, которое проверяет хост B, чтобы не допустить истечения времени ожидания записей таблицы моста, но это похоже на грязный взлом.
Да - это ожидаемо. Вы столкнулись с довольно распространенной проблемой, связанной с привязкой сетевых адаптеров к хостам, одноадресным флудом. Как вы отметили, таймеры на вашем коммутаторе для рассматриваемых аппаратных адресов, так как никакие кадры, полученные с этих адресов, не наблюдаются.
Вот общие варианты-
1.) Более длинные таймауты таблицы адресов. На смешанном коммутаторе L2 / L3 таймеры ARP и CAM должны быть близко друг к другу (при этом таймер CAM работает на несколько секунд дольше). Эта рекомендация действует независимо от остальной конфигурации. На коммутаторе L2 таймеры обычно можно установить на более длительное время без особых проблем. Тем не менее, если вы полностью не отключите таймеры, вы в конечном итоге вернетесь в ту же ситуацию, если не будет какого-либо источника трафика с этих других адресов.
2.) Вы можете жестко запрограммировать MAC-адреса на рассматриваемых коммутаторах (к сожалению, на всех коммутаторах на схеме). Очевидно, что это не оптимально по ряду причин.
3.) Измените режим связывания на стороне Linux на тот, который использует общий MAC-адрес источника (например, 802.3ad / LACP). Это дает множество эксплуатационных преимуществ, если ваш коммутатор поддерживает это.
4.) Создать безвозмездный арпс через задание cron из каждого интерфейса. Вам могут потребоваться фиктивные IP-адреса на различных интерфейсах, чтобы предотвратить возникновение колебаний (т. Е. IP-адрес хоста циклически проходит через различные аппаратные адреса).
5.) Если это проблема с трафиком, просто перейдите на 10GE! (извините - пришлось бросить это туда)
Маршрут LACP, вероятно, является наиболее распространенным и поддерживаемым, и коммутаторы, вероятно, могут быть настроены для довольно равномерной балансировки входящего трафика к серверу по различным каналам. Если это не удастся, я думаю, что проще всего будет интегрировать бесплатный вариант arp.