jidckii
@jidckii
system administrator

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

Всем привет.
Никак не могу разобраться, как правильно агрерировать каналы, что бы увелисивалась пропускная способность .
схема такая.
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 сети и на разных свичах ?
  • Вопрос задан
  • 1636 просмотров
Пригласить эксперта
Ответы на вопрос 5
Mystray
@Mystray
NOC
между двумя хостами - практически нереально на недорогом железе. Если коммутатор умеет хешить по L3+L4, то еще куда ни шло, в несколько потоков (с разными портами), может быть, удастся получить больше одного линка. Но это только шанс, что хеши разные попадутся.
Если коммутаторы не умеют балансить по L4, то между двумя хостами вы никак не сделаете больше скорости 1 линка, просто потому, что выбор линка будет определяться исключительно IP-адресами.
Ответ написан
ifaustrue
@ifaustrue
Пишу интересное в теллеграмм канале @cooladmin
Дело в том что Etherchannel при любом раскладе может опираться в балансировке либо на IP, либо на MAC, либо на MAC+IP комбинации, в вашем случае они не измены, потому эта технология ничего не даст.

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

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

И да, смотрите лучше балансировку по графикам MRTG. Вывод в консоли статистики на текущий момент не информативно и может быть ошибочно.
Ответ написан
Комментировать
@throughtheether
human after all
Предполагаю, что проблема может быть в том, что нагрузка идет с одного ip на один ip и по этому не распределяется нагрузка.
Поддерживаю ваше предположение:
EtherChannel Load-Balancing Configuration:
src-dst-ip


А если я их на 1 коммутаторе смогу поселить, будет работать агрегация ?
В этом случае на вашем месте я бы попробовал отключить агрегацию на коммутаторе и поэкспериментировать с настройками бондинга на сервере ( режим balance-alb для ОС Linux). Но стоит быть готовым к тому, что производительность iSCSI может упасть из-за нарушения порядка следования IP-пакетов.
Ответ написан
Комментировать
mikes
@mikes
bonding не делает "трубу" больше, он делает ее шире, соответственно, если у вас всего 2 хоста для обмена трафиком, то больше физической скорости одного порта вы не выжмете как не упражняйтесь в алгоритмах распределения трафика, переходите на 10gb карточки, или на fibrechannel :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы