Есть необходимость объединить две Радио-линии по 50 мегабит, пытался использовать эти два функционала, собрав "стенд", настроил шейпинг на 100 Кбит (для теста на "стенде") и настроил агрегацию этих двух портов. Ничего не вышло. Эти две функции не совместимы? Или я что-то не так сделал?

описание стенда:
ноут1-\
--------к1=====к2-----сервер
ноут2-/

на обоих коммутаторах настроил шейпер на 100 Кбит четырех портов, агрегировал по два порта на каждом коммутаторе и соединил двумя кабелями. Пробывал все алгоритмы агрегации, скорость более 100 Кбит не поднялась.

Вы на каких портах пытались полисер настроить?

На портах 10/100 Мбит (1 и 2). А на каких надо было?

Во-первых, на данном коммутаторе не shaper, а policer. Во-вторых, если Вы тестировали гоняя трафик через Link Aggregation между двумя ПК, то трафик между ними всегда передаётся по одному пути агрегации, а не идёт распределение по двум путям.

_________________
С уважением,
Бигаров Руслан.

Тогда что-то не срастается: "Методические указания к лабораторным работам по курсу "Коммутируемые сети"" авторы: Федотов Р. А., Пролетарский А. В., Баскаков И.В. - "Лабораторная работа №11. Контроль полосы пропускания (Шейпинг трафика)"

Но суть не в этом. Трафик гонял с двух ноутов одновременно на сервер и с сервера, используя алгоритмы агрегации как mac_source так и mac_destination, даже были попытки с mac_source_dest. Алгоритмы во время экспериментов выставлял на двух коммутаторах одинаковые. Активность наблюдалась только на одном порту, хотя каждый из ноутбуков занимал всю полосу, скорость делилась пополам, причем одного порта.

PS Оба коммутатора прошиты прошивкой 4.20

Дело не в прошивке, а в том, что при малом кол-ве путей вероятность, что один путь будет заполнен больше чем другой очень большая. Поэтому при использовании функции Link Aggregation советуют как минимум 4-е пути организовывать.

_________________
С уважением,
Бигаров Руслан.

На сколько я понимаю, Вы настаиваите на том, что такая схема должна работать. Тогда продолжу экперимент используя некий участок сети, и обязательно отпишусь. Благодарю за помощь!

Только учтите, что коммутаторы не балансируют трафик по путям, а пробрасывают исходя из алгоритма агрегации.

_________________
С уважением,
Бигаров Руслан.

Это понятно, но он же при агрегации должен учитывать выставленные ограничения размера канала на портах и с учетом переполнения канала часть MACов пойдет по вторичному порту?

Теория теорией, а практику не оспорить:
Для эксперимента был взят отдельный влан сети (наименьший), 15-20 пользователей были в активе во время эксперимета, все они работали через ПППоЕ сервер, который собственно и выпускал их в "мир". Цель эксперимента получить высокопроизводительный канал от сервера к клиентам, используя порты с ограничением 1мбит на двух экпериментальных 3026 установленных непосредственно перед нетегированным портом со стороны пользователей.
Соответственно на двух портах каждого коммутатора было выставленно 1024 Кбит/сек и порты были агрегированы. Алгоритм агрегации использовался mac_destination (собственно в конце эксперимента были опробыванны и другие алгоритмы) так как интересует трафик от сервера к пользователям. Тем самым получаем схему 1мак(сурс)---"15-20"маков(дест). Наблюдения за активностью портов дали плачевные результаты, активность наблюдалась только на одном порту и скорость исходящего трафика от сервера в этот влан не превышала 12хх Кбит/сек (в ходе экспериментов было обнаруженно что ограничение скорости на портах имеет погрешность в 20%). После чего было было добавлено еще два порта в агрегацию, теоретически суммарная мощьность канала должна составлять 4 Мбит. При добавлении портов в агрегацию была сделана попытка добавить не шейпированные порты, на что коммутаторы выругались, это доказывает что при агрегации учитываются и сторонние настройки портов. И так, мы получили по четыре агрегированных порта, тоесть путей решения задачи перенаправления ~20 маков по портам 4! Исход эксперимента одинаков - активность только на одном порту. Так же при настройке шейпера/полисера рекомендуется использовать функцию "Flow control", после включения данной вункции разници не оказалось.
Вывод: Возможно функция агрегации портов будет работать при объединении двух бродкастных сегментов сети или для пропускания множества вланов не имеющих между собой ничего общего, то есть при схеме хх МАСов-----агрегация----уу МАСов. Для расширения аплинка допустим к провайдеру или к определенной точке сети это не подходит.

Из описания я понял, что есть задача ограничивать клиентские порты скоростью 1Mbps, а вот причины использования Link Aggregation, а тем более зарезания на каналах агрегации скорости не понятны. Я так понимаю, что погрешность в 20% касается TCP трафика, так как UDP трафик работает нормально. В остальном, если на другой стороне 1 сервер, то использовать dst_mac или src_dst_mac нельзя при данной топологии. В идеале использовать src_mac или src_ip на коммутаторе, к которому подключены клиентские ПК и dst_mac или dst_ip на коммутаторе, к которому подключён сервер.

_________________
С уважением,
Бигаров Руслан.

Про src_ip я и сам прекрасно понимаю, но такого функционала нет у данного коммутатора:


Зачем наводить смуту? Еслиб был этот функционал, я даже и речи не начал бы. По поводу Вашего не понимания причин зарезания скорости - это для эксперимента, по сути прочитайте первый пост, и все станет ясно. Тот влан на котором проводился эксперимент в среднем используется на 3-4 мегабита по этому и выбрано ограничение в 1 мегабит. И задача изначально описана в первом посте достаточно понятно. И в топике написан конкретный коммутатор и его функционал, о котором идет речь.
Я не пытаюсь дескредитировать Вас и продукцию компании которую вы предоставляете, а пытаюсь узнать возможно ли использовать это в моем случае, если да то где я ошибся? Но для себя сделал вывод, что нет, так как два эксперимента показали невозможность.

Я описывал вцелом для вашего случая, а так да, DES-3026 бюджетная серия и алгоритмов агрегирования по IP в ней нет.

_________________
С уважением,
Бигаров Руслан.

Большое спасибо. Это все что нужно было ))