Мне было интересно, должен ли механизм маршрутизации для LACP (исходный / целевой MAC, исходный + целевой MAC, исходный / целевой IP, исходный + целевой IP) в пределах
также: при использовании автоматического LACP происходит ли согласование, чтобы устройства автоматически использовали одну и ту же стратегию маршрутизации? что худшего может случиться, если механизмы маршрутизации не подходят?
* Я использую термин «магистраль» здесь в значении «группировки нескольких физических кабелей для обеспечения избыточности и повышения пропускной способности».
Нет, нет причин для совпадения алгоритмов хеширования на каждой стороне. LACP не знает и не заботится о стратегии удаленного хеширования. Одноранговые узлы LACP не согласовывают хеширование, потому что им все равно, как их одноранговый узел балансирует трафик. Отсутствует проверка того, что входящий фрейм пришел в «правильный» интерфейс.
Вы должны думать о LACP как о «механизме проверки» агрегации каналов.
Вы не добьетесь лучшей производительности независимо от того, используете ли вы статическую LAG или LACP LAG. Что вы получите, так это более быстрое переключение при отказе и некоторый интеллект, который проверяет, что ссылки функциональный прежде чем вводить их в LAG.
Теперь ... в зависимости от вашего ДВИЖЕНИЯ ... прямо ответил бы на ваш вопрос, что лучше. Каждый участник ссылки может использовать разные методы (IP src / dest, MAC src / dest), чтобы выбрать, как EGRESS трафик. В идеале оба конца ссылки будут делать то же самое, но это не обязательно.
У NetApp есть ЧУДЕСНЫЙ документ по этому поводу, охватывающий несколько различных сценариев, но позвольте мне сразу перейти к делу:
1) Вам понадобится отдельная связь LACP для каждого VIF, по одной для каждой головы NetApp.
2) Вы должны настроить статические LAG на стороне ESXi, если вы используете 5.0 или более раннюю версию, и LACP с поддержкой LAG, если вы используете 5.1 или новее.
Как только вы достигнете ограничений 1GbE для этого NetApp, вам нужно будет либо перейти на карты 10GbE, либо получить более мощный фильтр.
РЕДАКТИРОВАТЬ: Вот ссылка на документацию, теперь может быть пересмотр 5.1 http://media.netapp.com/documents/tr-3749.pdf