У меня настроен LACP между моим сервером (802.3ad, уровень 2, то есть на основе MAC-адреса источника и MAC-адреса назначения) и моим коммутатором.
Недавно я увидел, что входящий трафик для сетевого узла использует один интерфейс (eth3), а исходящий для того же сетевого узла использует другой интерфейс (eth1)!?
Это нормальное поведение?
Просмотр документации ядра (https://www.kernel.org/doc/Documentation/networking/bonding.txt, раздел xmit_hash_policy): Я так не думаю. Но должен признать, что я заблудился, действительно заблудился...
Вот моя установка:
конфигурация связи на моем сервере
root@server:~# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200
802.3ad info
LACP rate: fast
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 2
Number of ports: 2
Actor Key: 17
Partner Key: 8
Partner Mac Address: 2c:23:3a:6a:c5:fe
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 6
Permanent HW addr: b0:83:fe:d9:93:a0
Aggregator ID: 2
Slave queue ID: 0
Slave Interface: eth3
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 6
Permanent HW addr: b0:83:fe:d9:93:a2
Aggregator ID: 2
Slave queue ID: 0
Конфигурация коммутатора (HPE 5130):
<switch> display link-aggregation load-sharing mode interface Bridge-Aggregation 8
Bridge-Aggregation8 load-sharing mode:
Layer 2 traffic: packet type-based sharing
Layer 3 traffic: packet type-based sharing
<switch>display link-aggregation verbose Bridge-Aggregation 8
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected,
I -- Individual, * -- Management port
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired
Aggregate Interface: Bridge-Aggregation8
Aggregation Mode: Dynamic
Loadsharing Type: Shar
Management VLAN : None
System ID: 0x8000, 2c23-3a6a-c5fe
Local:
Port Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
GE1/0/8 S 32768 8 {ABCDEF}
GE2/0/8 S 32768 8 {ABCDEF}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
--------------------------------------------------------------------------------
GE1/0/8 2 255 17 0xffff, b083-fed9-93a0 {ABCDEF}
GE2/0/8 1 255 17 0xffff, b083-fed9-93a0 {ABCDEF}
Я попытался изменить режим балансировки нагрузки на своем коммутаторе, но ничего не изменилось.
Спасибо!
решение1
При использовании LACP или статического связывания каждая сторона самостоятельно решает, как маршрутизировать трафик.
Коммутаторы обычно применяют схему SA/DA — они хэшируют нижние три или четыре бита адресов источника и назначения и используют их как индекс порта LAG. Более простые коммутаторы просто используют MAC-адреса, более сложные — IP-адреса (если они есть) или даже в сочетании с портами TCP/UDP.
Цель состоит в том, чтобы один поток всегда использовал одни и те же комбинации портов, чтобы кадры не могли нарушить последовательность.
Использование только MAC-адресов приводит к тому, что весь трафик между двумя хостами (или маршрутизаторами) всегда использует одну и ту же комбинацию портов.
Использование IP-адресов позволяет распределять потоки между маршрутизаторами или выбирать (вторичные) IP-адреса для оптимизации потоков, а комбинации IP/портов автоматически балансируют нагрузку различных соединений (хотя и не обязательно оптимально).
Итак, входящий трафик к хосту контролируется коммутатором, исходящий трафик контролируется хостом. Это может очень легко привести к использованию разных портов в обоих направлениях. Но это не повредит.