Объединение коммутаторов 802.3ad и HPE: входящий и исходящий трафик не в одном интерфейсе

Объединение коммутаторов 802.3ad и HPE: входящий и исходящий трафик не в одном интерфейсе

У меня настроен 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/портов автоматически балансируют нагрузку различных соединений (хотя и не обязательно оптимально).

Итак, входящий трафик к хосту контролируется коммутатором, исходящий трафик контролируется хостом. Это может очень легко привести к использованию разных портов в обоих направлениях. Но это не повредит.

Связанный контент