Etherchannel между коммутаторами не увеличивает скорость?

Question

[jidckii]

Всем привет.
Никак не могу разобраться, как правильно агрерировать каналы, что бы увелисивалась пропускная способность .
схема такая.
Freenas iscsi tsrget <=(Po1) 5gb LACP => sw02(C2960G) <=(Po2) 5gb LACP (Po5)=> sw01 (C2960S) <= 4gb LACP (Po1)=> Linux iscsi инициатор.

sw02 config:

SRV-GN02#sh etherchannel summary 
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port


Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi0/35(P)   Gi0/36(P)   Gi0/37(P)   
                                 Gi0/38(P)   Gi0/39(P)   
2      Po2(SU)         LACP      Gi0/40(P)   Gi0/41(P)   Gi0/42(D)   
                                 Gi0/43(P)   Gi0/44(P)   

SRV-GN02#sh etherchannel load-balance 
EtherChannel Load-Balancing Configuration:
        src-dst-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
  IPv4: Source XOR Destination MAC address
  IPv6: Source XOR Destination MAC address

sw01 config:

SRV-GN01#sh etherchannel summary 
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port


Number of channel-groups in use: 5
Number of aggregators:           5

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi1/0/9(P)  Gi1/0/10(P) Gi1/0/11(P) 
                                 Gi1/0/12(P) 
5      Po5(SU)         LACP      Gi1/0/44(P) Gi1/0/45(P) Gi1/0/46(D) 
                                 Gi1/0/47(P) Gi1/0/48(P) 

SRV-GN01#sh etherchannel lo      
SRV-GN01#sh etherchannel load-balance 
EtherChannel Load-Balancing Configuration:
        src-dst-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
  IPv4: Source XOR Destination MAC address
  IPv6: Source XOR Destination MAC address

Собственно проблема в том, что с Freenas я начинаю лить в 8 потоков UDP iperf по 500m
$ iperf -c 172.20.0.36 -u -b 500m -i 1 -t 100

При этом на коммутаторах вижу вот такую картину
На sw02:

Gi0/35    freenas       connected    3          a-full a-1000 10/100/1000BaseTX
Gi0/36    freenas       connected    3          a-full a-1000 10/100/1000BaseTX
Gi0/37    freenas       connected    3          a-full a-1000 10/100/1000BaseTX
Gi0/38    freenas       connected    3          a-full a-1000 10/100/1000BaseTX
Gi0/39    freenas       connected    3          a-full a-1000 10/100/1000BaseTX
Gi0/40    SRV-GN01           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi0/41    SRV-GN01           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi0/42    SRV-GN01           notconnect   1            auto   auto 10/100/1000BaseTX
Gi0/43    SRV-GN01           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi0/44    SRV-GN01           connected    trunk      a-full a-1000 10/100/1000BaseTX

Gi0/35   	   0			0
Gi0/36   	   54			0
Gi0/37   	   100		0
Gi0/38   	   100		0
Gi0/39   	   54			0

Gi0/40   	   0			0
Gi0/41   	   0			0
Gi0/42   	   0			0
Gi0/43   	   0			100
Gi0/44   	   0			0

На sw01:

Gi1/0/9   IBM-server_bond    connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/10  IBM-server_bond    connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/11  IBM-server_bond    connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/12  IBM-server_bond    connected    trunk      a-full a-1000 10/100/1000BaseTX

Gi1/0/44  SRV-GN02           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/45  SRV-GN02           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/46  SRV-GN02           notconnect   1            auto   auto 10/100/1000BaseTX
Gi1/0/47  SRV-GN02           connected    trunk      a-full a-1000 10/100/1000BaseTX
Gi1/0/48  SRV-GN02           connected    trunk      a-full a-1000 10/100/1000BaseTX


Gi1/0/9   	           0			0
Gi1/0/10   	   0			0
Gi1/0/11   	   0			100
Gi1/0/12   	   0			0

Gi1/0/44   	   0			0
Gi1/0/45   	   0			0
Gi1/0/46   	   0			0
Gi1/0/47   	   100		0
Gi1/0/48   	   0			0

То есть нагрузка не размазывается уже межку коммутаторами.
Пробовал выставлять разные режимы load-balance

если выставить src-ip или src-mac , то коммутаторы начинаю вести себя крайне странно и пихают трафик во все активные порты при чем все в полку загружают.

Предполагаю, что проблема может быть в том, что нагрузка идет с одного ip на один ip и по этому не распределяется нагрузка.

Как правильно настроить, что бы можно было гнать 4G c 1 сервера на другой в обе стороны при условии, что они в 1 сети и на разных свичах ?

Answer 1

[Mystray]

между двумя хостами - практически нереально на недорогом железе. Если коммутатор умеет хешить по L3+L4, то еще куда ни шло, в несколько потоков (с разными портами), может быть, удастся получить больше одного линка. Но это только шанс, что хеши разные попадутся.
Если коммутаторы не умеют балансить по L4, то между двумя хостами вы никак не сделаете больше скорости 1 линка, просто потому, что выбор линка будет определяться исключительно IP-адресами.

Comments

[jidckii]

ну собственно на это и грешил....
А если я их на 1 коммутаторе смогу поселить, будет работать агрегация ?

[Mystray]

Ничего не изменится по факту. Агрегация работать будет, но точно так же. Даже если на входе фреймы будут правильно и равномерно размазаны, на выходе опять же коммутатор сам будет решать, в какой порт из группы их впихнуть, опять же по своему алгоритму.
Как вариант - пробовать делать не lacp/ec, а агрегирование средствами ОС (bonding/teaming), и устанавливать tx hash в l3+l4 или в round robin, а на коммутаторе делать порты аксессом в разных вланах, соединяя их соответственно. Но это жуткий костыль,не всюду применим, и не факт, что заработает.

Типа так:
host1(bond0) =switch= host2 (bond0)
eth0|--|ge0/0 (vlan 2) ge0/4|--| eth0
eth1|--|ge0/1 (vlan 3) ge0/5|--| eth1
eth2|--|ge0/2 (vlan 4) ge0/6|--| eth2
eth3|--|ge0/3 (vlan 5) ge0/7|--| eth3

Answer 2

[Клёвый Админ]

Дело в том что Etherchannel при любом раскладе может опираться в балансировке либо на IP, либо на MAC, либо на MAC+IP комбинации, в вашем случае они не измены, потому эта технология ничего не даст.

Можно попробовать привязать на iSCSI хосты новые адреса и инициировать несколько сессий с разных IP.

Comments

[jidckii]

Это не решение.
ну собственно на это и грешил....
А если я их на 1 коммутаторе смогу поселить, будет работать агрегация ?

[Клёвый Админ]

jidckii: нет не будет. Нужно что бы хеши считались разные, а они считаются либо по адресу либо по маку.

Answer 3

[Валентин]

Отправная точка для гугления - "Cisco lacp hashing algorithm". На сколько мне известно, хеширование на L4 у циски поддерживается только на нексусах. Даже на шкафах CRS вы будете неприятно удивлены, когда переполнится один линк в агрегате при построении жирного x-connectа через mpls. Такова жизнь(

В этом преимущество джуниперов - их EX-коммутаторы имеют эту поддержку сразу.

И да, смотрите лучше балансировку по графикам MRTG. Вывод в консоли статистики на текущий момент не информативно и может быть ошибочно.

Answer 4

[throughtheether]

Предполагаю, что проблема может быть в том, что нагрузка идет с одного ip на один ip и по этому не распределяется нагрузка.

Поддерживаю ваше предположение:

EtherChannel Load-Balancing Configuration:
src-dst-ip

А если я их на 1 коммутаторе смогу поселить, будет работать агрегация ?

В этом случае на вашем месте я бы попробовал отключить агрегацию на коммутаторе и поэкспериментировать с настройками бондинга на сервере ( режим balance-alb для ОС Linux). Но стоит быть готовым к тому, что производительность iSCSI может упасть из-за нарушения порядка следования IP-пакетов.

Answer 5

[mikes]

bonding не делает "трубу" больше, он делает ее шире, соответственно, если у вас всего 2 хоста для обмена трафиком, то больше физической скорости одного порта вы не выжмете как не упражняйтесь в алгоритмах распределения трафика, переходите на 10gb карточки, или на fibrechannel :)