Имеются два коммутатора DGS-3420 и DGS-3620.

Есть сервер на Linux c двумя сетевыми картами, которые объединены в bond (trunk) с mode=4 т.е. 802.3ad и алгоритмом ip_src_dst.

Создаю trunk port на коммутаторе как и положено в LACP, а при подключении сервера либо вообще не работает передача данных, либо работает только один порт.

Пробовал на 3420, затем на 3620 ... везде одинаковые симптомы. На коммутаторе в списке активных портов транка появляется только один, второго коммутатор не желает видеть и обмениваться с ним данными.

В итоге подключил сервер к DGS-3450, где все прекрасно зацепилось и заработало (у меня несколько таких серверов, подключенных к 3450, 3627 и даже 3100-48). Затем уже между 3450 и 3420 создал trunk static (он слава богу завелся без проблем) и таким вот "изощренным способом" подключил сервер.

Вопрос: Что такого изменилось в 3420 и 3620 по сравнению с 3450 и 3627 после чего перестал работать стандартный, много раз опробованный алгоритм объединения портов?

+

Еще на 3420 замечены ошибки в работе traffic_segmentation ... Мне нужно в пределах одного vlan отделить один порт и сделать его для одних портов доступным, а для других нет ...

Делаю все как всегда на других моделях и получаю полный рандом. Совершенно случайным образом блокируются порты, в других вланах начинается хаос, до одних хостов связь прекращается, а до других наоборот возникает ...

Я даже не смог понять по какой системе это все работает ... В итоге мы с моим инженером развели руками и решили не трогать более этот опасный инструментарий, который положил мне приличную часть сети и сделал это очень "творчески и выборочно" да так, что мы искали проблему полчаса. Есс-но сразу перевели все нужные порты на свободный 3450 и там все быстренько сделали как надо.

Просьба пояснить такое поведение traffic_segmentation и что от него можно ожидать? Что вообще можно ожидать от DGS-3420 и DGS-3620 в частности, который к тому же оказался недостойным высокого звания L3 коммутатора?

Когда можно ожидать прошивки, устраняющей детские болезни железок? Хотелось бы верить, что железо стоит вложенных денег.

Чтобы ситуация была совсем понятной и в будущем не натыкаться на советы о том, что между двух хостов более 1 Гб/с не получить, то уточняю.

- сервер, который я подключаю, занимается ip_forwarding, т.е. по сути L3-коммутатор, через который идут клиенты (около 1000 абонентов)
- с другой стороны стоят 14 серверов авторизации и абоненты по случайной схеме раскидываются на эти 14 машин

Таким образом 14 серверов видят эту самую 1000 абонентов и речи о паре хостов при использовании ip_source_destination не идет.

Также уточню, что проблема не в полке в 1 Гб/с, а в принципе в нестартующем втором линке.

DGS-3620-28TC F/W 1.00.38
DGS-3420-28TC F/W 1.00.26

опишу более подробнее ситуацию с 3420 traffic_segmentation
Имеется влан Х с портами 1-25
Требуется исключить из общего влана порт 19, при настройке порт 19 forward_list 9-12,19 порт 25 перестает общаться с 9-12
Настройка остальных портов 1-18,20-28 forward_list 1-28

balixin
Приведите настройки traffic_segmentation и укажите, какие порты куда работают/не работают.

replicant
lacp у вас не работает исключительно с вашим linux-сервером? С другими коммутаторами смотрели?

Также просьба привести настройки traffic_segmentation и описать некорректную работу

В данной теме мы описываем одни и теже свичи.
я просто сделал дополнение по сегментации.
По LACP пока не проверяли с другим оборудованием, сделаем пару тестов. В данный момент они работают с другими свичами в Static, нареканий нет.

Что касаемо сегментации


Если сделать так


То перестает идти обмен между 9-12 и 25 портами

Так же столкнулся с проблемой LACP на 3420.
На второй стороне был zte-5928FI. Судя по логам ZTE - он считает LACPDU от 3420 ошибками.

При этом статический тип link_aggregation работает прекрасно.

Тоже сталкивались с такой проблемой, но на ZTE более старшей серии и DGS-3627G, проблема там на сколько я помню в разном толковании стандарта IEEE 802.1AX-2008 разработчиками ZTE и D-Link:


В общем ZTE хочет, чтобы эти 50 октетов были заполнены нулями, а D-Link их чем-то заполняет, за давностью не помню уже чем, в этом вся проблема.

balixin
Подтвердить на стенде не могу. При указанной конфигурации:

трафик между портами 9-12 и 25 ходит без проблем.

Будем тестировать далее, по результатам сообщим, а как нам быть с LACP trunk?

По поводу lacp.
Чтобы существующую проблему можно было исправить, нужна детальная инструкция по шагам, как эту проблему можно воспроизвести. Опять же, по поводу ZTE - вопрос в том, почему оборудование не игнорирует эти поля?

Глядя на lacp пакеты от DES-3526, DGS-3627 и DGS-3420-28SC я в последних не смог найти чего-то аномального - они идентичны за исключением зарезервированных полей и информации о линке. LACP между коммутаторами работает исправно.

Ага, они сказали так-же, почему D-Link заполняет эти поля , и сослались на стандарт:

Впрочем, специально для нас, ZTE пофиксил проблему в этой серии коммутаторов.

По поводу заполнения reserved полей я отпишу в ШК.
Согласен - ошибка в принципе с обеих сторон.

Вот параметры устройств

В данной конфигурации с 3450, 3627 все работает прекрасно без нареканий


А вот с 3620-28ТС и 3420-28ТС беда


Сервер

сдался вам этот LACP... собирайте static

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Здравствуйте, закупили два 3420-28tc в планах поднимать LACP между ними и HP(BigIron) очень бы нехотелось столкнуться с такойже проблемой, т.к. все будет происходить на рабочей системе и предварительно протестить возможности нет.

И еще небольшой вопрос, может я что не так делаю, но не пробивается ip в 192.168.0.x/24 сети пишет :

Command: config ipif System ipaddress 192.168.0.169/24
Conflicted subnet addresses
Fail!

Boot PROM Version : Build 1.00.006
Firmware Version : Build 1.00.023