У меня настроен протокол 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}
Я попытался изменить режим балансировки нагрузки на своем коммутаторе, но ничего не изменилось.
Спасибо!
При использовании LACP или статического связывания каждая сторона самостоятельно решает, как маршрутизировать трафик.
Коммутаторы обычно применяют схему SA / DA - они хэшируют младшие три или четыре бита адресов источника и назначения и используют их в качестве индекса порта LAG. Более простые коммутаторы просто используют MAC-адреса, более сложные IP-адреса (если они есть) или даже в сочетании с портами TCP / UDP.
Намерение состоит в том, чтобы один поток всегда использовал одни и те же комбинации портов, чтобы кадры не могли выходить из строя.
Использование только MAC-адресов приводит к тому, что весь трафик между двумя хостами (или маршрутизаторами) всегда использует одну и ту же комбинацию портов.
Использование IP-адресов позволяет распределять потоки между маршрутизаторами или позволяет вам выбирать (вторичные) IP-адреса для оптимизации потоков и комбинаций IP / портов, автоматически балансируя нагрузку на различные соединения (хотя и не обязательно оптимально).
Таким образом, входящий трафик на хост контролируется коммутатором, а исходящий трафик контролируется хостом. Это может очень легко привести к использованию разных портов в обоих направлениях. Хотя это не больно.