Доброго времени суток!

Что имеем:
- 1 "аппаратная" (по факту стойка с активным оборудованием нашем и провайдерским), 1 серверная на разных этажах
- Свитчи DGS-3120-24TC (Boot PROM Version Build 3.00.501, Firmware Version Build 4.01.B003, Hardware Version B1, Firmware Type EI) и свитчи DGS-3120-48TC (Boot PROM Version Build 3.00.501, Firmware Version Build 4.01.B003, Hardware Version B1, Firmware Type EI)
- Кабели для стэкирования
- Маршрутизатор Microtik

Что хотим:
- 2 свитча DGS-3120-24TC объединяем в стэк (цепочкой, т.е. первый со вторым одним шнурком для стэкирования) в серверной
- 2 свитча DGS-3120-48TC объединяем в стэк (цепочкой, т.е. первый со вторым одним шнурком для стэкирования) в "аппаратной"
- Настраиваем агрегацию между двумя стэками в серверной и "аппаратной"
- Настраиваем агрегацию между стэком в "аппаратной" и маршрутизатором

Что сделали:
- Настроили желаемые стэки, но пришлось воспользоваться статьей http://sysadmins.ru/topic396955.html, т.к. у нас тип прошивки был RI, а он не поддерживает стэкирование
- Настроили агрегацию между двумя стэками в в серверной и "аппаратной", в серверной 1:23,2:23 в аппаратной 1:45,2:45, LACP
- Настроили агрегацию между стэком в "аппаратной" и маршрутизатором, со стороны свитча 1:47,2:47, LACP
- Везде используется алгоритм балансировки L4 Port Source Dest

Что пошло не так:
- При агрегации между серверной и "аппаратной" в Active Ports только один порт, в то время как между стэком в "аппаратной" и маршрутизатором 2 порта - насторожило сразу
- Некоторое время схема эксплуатировалась, но счастье кончилось когда однажды местная энергокомпания решила провести работы "внепланово", как оказалось, наши ИБП оказались к аткому повороту судьбы не готовы и электричество кончилось, вместе с ним кончились и свитчи с маршрутизатором в "аппаратной". После не поднялась агрегация. Проверка показала, что перезагрузка стэка может поднять агрегация, а может и не поднять => т.е. сервера + стэк в серверной были недоступны, что нас не устраивало
- Также тесты показали, что агрегация что между стэками, что между стэком и маршрутизатором не давала увеличения ширины канала, работала только как "резервный линк"

Начали ковыряться, заметили, что в настройках портов LACP везде выставлено Passive, возможно беда в этом, т.к. пишут что работают схемы Passive-Active или Active-Active. Однако непонятно как это будет в случае со стэком => настроили на стэке в "аппаратной" Active на портах 1:45,1:47,2:45,2:47, на стэке в серверной везде Passive. Не помогло - при включении сервера доступны, стэк в серверной доступен, однако в логах порты 2:45 в "аппаратной" и 2:23 в серверной постоянно падали и поднимались, на сети это тоже отразилось негативно (некоторые сервисы не завелись).

В общем нужен хелп, нам нужно понять, почему не работает корректно агрегация между "аппаратной" и серверной (или периодически не поднимается или поднимается но с проблемами на slave-портах) и почему не получается увеличить ширину канала через агрегации.

P.S. Loopdetect на портах, включенных в агрегацию - отключен, BPDU Protect и DoS Attack Prevention отключены

Ошибки на портах lacp есть? Подключение витой парой или оптикой?

Да, ошибки на портах (а точнее на порту 2:45 со стороны "аппаратной" и 2:23 со стороны серверной) присутствуют. Подключение витой парой

Вообщем вылезают пара основных вопросов:
1) Работает ли вообще агрегация в условиях стека? Т.е. когда два свитча с одной стороны в стеке и два с другой в стеке и между ними агрегация двумя линками каждый в свою пару комматуторов.
Делал кто-то подобное?
2) В случае если ответ на вопрос 1 положительный, то как настраивали passive\active на агрегации в условиях стека?

Ошибки CRC ? Если да - ищите повреждения кабеля.

В том числе и CRC, на самом деле там присутствуют почти все виды ошибок на "чтение"



Хмм, тестер (самый простой) повреждения пар не видит, диагностику мы конечно же проведем, просто я не уверен, что проблема в этом.
А вы можете подсказать ответ все таки на мои вопросы? Может проблема в самом DLink?

А я вам скажу - у вас просто огромное количество CRC. В любом случае это не нормально, этого быть не должно.

Это понятно, вопрос в том берутся ли ошибки из за того, что повреждена линия или потому что Dlink данной модели не умеет делать агрегацию между стеками?

У Cisco написано http://www.cisco.com/cisco/web/support/RU/10/105/105430_53.html что ошибки CRC не обязательно связаны только лишь с кабелем, поэтому вопрос остается открытым (имею ввиду можно ли вообще сделать агрегацию между стеками).

Здесь CRC связан с темже. Если у вас LACP собрался, т.е. показывает приблизительно такую же картину - значит всё норм.

А вот нифига, LACP на тех же DES-3200 и DGS-3120 поднимался, даже если на том конце лацп не включен. А с полулинками вообще песня один раз случилась.
В любом случае, по-моему, несоответствие дуплексных режимов - не есть нормальное поведение, которое надо устранять по факту обнаружения.

P.S. Стек на DGS-3120 дальше тестирование "на коленке" стенда у меня не пошел.

ни разу такого не видел, эктив будет только 1 порт.

Вопрос про LACP на вышеописанных коммутаторах, да и вообще в целом.
При включение LACP как правильно подключать кабели, чтобы подключение было мастер-мастер и мембер-мембер, или не имеет разницы? у D-Link, есть понятие мастер порта, насколько я знаю, его суть только в конфигурирование самого канала агрегации, или же этот мастер порт еще для чего-то нужен.
Раньше никогда не задумывался об это, а тут включил агригацию, а она кросом поднялас, т.е. мастер - мембер и мембер - мастер.