Что касается приема (Rx), выбор конкретной LACP-ссылки для использования зависит от передатчика (то есть пары переключателей в конфигурации MLAG) и его локальных настроек (я, конечно, надеюсь, что коммутатор MLAG будет использовать «локальную» ссылку, а не передавать трафик через ICCP на другой коммутатор MLAG). Обратите внимание, что партнеры по LACP-агрегации могут работать с разными настройками и алгоритмами Tx-хеша… и это вполне нормально. Алгоритм Tx-хеша нужен лишь для распределения исходящего трафика между доступными физическими ссылками и никакого отношения к приему (Rx) не имеет.
Что касается передачи (Tx), выбор конкретной физической LACP-ссылки для передачи каждого Ethernet-кадра определяется Tx-хешем. Но хеш не гарантирует равномерное распределение трафика между всеми доступными ссылками. Например, если есть 2 ссылки и применяется хеширование по L3+L4, то функция хеша берет dst-address, src-address, dst-port и src-port и вычисляет хеш по этой «четверке». Если полученный хеш, скажем, нечётный, все кадры пойдут по ссылке #0, а при чётном — по ссылке #1. Изменение любого из этих 4 значений на один символ не гарантирует переключение хеша между {нечёт, чёт}. Однако это вопрос статистики: при множестве одновременно активных соединений трафик скорее будет распределяться равномернее. С другой стороны, все кадры, относящиеся к одному L4-соединению, всегда будут передаваться по одной и той же физической ссылке.
Еще имейте в виду, что при использовании L2 Tx-хеширования для трафика через шлюз берется в расчет MAC-адрес маршрутизатора, что означает: трафик с LACP-хоста (например, с сервера) в интернет будет идти по одной физической ссылке. Поэтому при настройке сервера, который будет общаться с клиентами через шлюз, разумно использовать L3-хеширование или (лучше) L3+L4-хеширование.
