Не согласен по поводу недоделки. Каждое устройство имеет свои осбенности и ограничения. А так в целом рад слышать что DGS-3610-XX понравился. По поводу SNMP согласен постепенно будем подтягивать.

To Valeriy-kww:

А что мещает использовать эту функцию в указанном устройстве? Только отсутсвие SNMP OID-ов по этой теме?

Совершенно верно.
Отсутствие управления по SNMP SuperVLAN/SubVLAN очень критично.
У нас в среднем порядка 10-20 подключений в день.
Управление коммутаторами реализовано полностью по SNMP
При подключении и отключении абонентов к сети, администратор сети не участвует в этом процессе. Есть инженер, который планирует магистрали, есть секретарь-оператор принимающий заявки, есть девушка оформляющая договора с абонентами, и ей нет никакого дела до того как оно работает. Она вносит адрес абонента, его паспортные данные и все, остальное делает АСУ которое содержит необходимые компоненты для автоматизированной работы.
Держать/нагружать админа для конфигурирования коммутатора при подключении каждого нового абонента VLAN вручную, при схеме vlan-per-customer - неразумно imho.
Делать параллельно SNMP управление по TELNET ?? лично мне такой зоопарк в сети не нужен, да и мало кого он устроит.
Именно это и останавливает от использования данной функции., да и от покупки устройства в целом.
P/s
В нашей сети агрегация построена на нескольких DGS-3627 связанных 10G портами (L3 маршрутизация).
При количестве IP интерфейсов напрашиваются цифры 16 SuperVlan + 255 SubVLAN идеально-оптимальный вариант для данной модели. Насколько он реализуем - судить не берусь.

_________________
В интернете три беды: дураки, вирусы и спам.

А у Вас каждый раз при добавлении одного абонента прописывается VLAN? Т.е. сразу VLAN-ы в схеме VLAN-per-customer не прописаны?

Нет не прописаны.
Да и невозможно угадать сколько и куда их будет нужно.
Например на прошлой неделе подключали фирму со складами, 1 Vlan / 16 IP , 2 общежития 1 Vlan / 128 IP. Как тут угадать или распределить заранее ?
Немного отклонюсь от темы с вашего позволения.
Вообще очень много тонкостей/хитростей при работе с коммутаторами D-Link. К примеру, у меня в сети не используется IMB, а для управления используем PCF ACL. IP/port. При сохранении конфигурации прерывается обслуживание абонентов на несколько секунд. Что бы не прерывать обслуживание, мониторится время работы коммутатора, ACL не сохраняются, а текущие ACL загружаются сразу после перезагрузки коммутатора (если она возникла). Так и добиваемся ровной работы, без обрывов.

_________________
В интернете три беды: дураки, вирусы и спам.

Насчет недоделки соглашусь, это я просто так "сказанул". Хотел сказать, что 3610 то ведь круче 3627 и существенно продвинутее. Вот бы со сроками определиться когда по SNMP запрашиваемый функционал будет? Ну хоть примерно. Насколько понимаю пока ничего в эту сторону не начиналось, по крайней мере запрашиваю об этом в форуме и лично уже давно. 3627 вот бы поюзать, но покупать его - "авось потянет" страшно. Да и мало в нем сабвиланов пока.

Точного расписания пока нет.



Над этим работаем. Проверяли Traffic Generator-ом загрузку CPU при использовании функции Super VLAN, тест показал, что на загрузку CPU использование данной функции не влияет, гоняли трафик со скоростью 1Gbps как между SubVLAN-ами так и через hop.

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

Да мы тоже замечали такую особенность. Заметил сильную нагрузку на 3610 просто при увеличении кол-ва субвиланов. Трафик при этом не возрос особенно. Связь вроде нормально работает, но загрузка проца около сотни часто бывает. Не могу найти причину, что подскажете?

И до сих пор ни от кого не получил ответа на вопрос: почему так сильно и так часто таращит админку???

Если помните мы вели переписку по этой проблеме. Но Вы перестали отвечать, Алексей.
Нагрузка скорее всего связана с тем, что свитч всегда отвечает своим адресом на любой запрос ARP. Это делается процом, отсюда и загрузка.
Не забудьте про address range

Помню кончечно. Просто я не вижу и не получаю способов решения проблемы. Админку таращит всегда. address range всегда был прописан. Проблема в том, что админку таращило всегда, еще до тех пор как я связался с supervlan. И никакой связи между таращением админки и загрузкой проца я не наблюдал всё это время. Ну не прикажете же делать снимок дебага постоянно...

Вот обратите внимания на такую беду: Параметры Arp retry time, Arp retry interval - максимальны. При этом процесс Tarptime сжирает почти всё процессорное время. Если эти параметры уменьшить, то свитч на 5-10 минут просто перестает работать с определенной периодичностью. 2 раза я скрин дебага высылал. Экспериментировать на паре тысяч юзверей я не могу - уж простите. И как мне быть?

Я просто понял что свитч переварит 2-3 тысячи зверей с прокси-арп, и смирился с тем что таращит админку. Волнообразная загрузка процессора конечно пугает, но средняя пока около 60. Всему виной Tarptime - уменьшить его нельзя ибо начинаются провалы. Это глобальное. Частности не так важны. Вот и не знаю чего ещё писать, ибо нет ответов на озвученные вопросы...

Решил снова рискнуть головой и уменьшил arp retry times = 90, arp retry intervals = 3400

Примерно через 40 минут, отвалилась админка 3610, умер трафик на данной жлезке. Длилось минут 5-6, как появилась связь я сразу вернул всё обратно и ни за что так больше не сделаю. Уменьшил от максимальных значений совсем на мало. В общем я не понимаю в чем тут зависимости. И самое главное не понимаю что можно сделать.

Но пока я склоняюсь к варианту ZTE 5928-FI, имя еще не раскрученное, но вот в деле он молотит говорят не плохо. И цена почти на 1К дешевле.

Что можете сказать в пользу DGS-3610 ?

Укажите пожалуйста в личку Ваш телефон.

2gda Если я правильно помню, вы должны были предоставить дебажную информацию с устройства, после обновления прошивки. Перед фазой рекомендации, должна быть фаза сбора информации, которую мы с вами никак не можем пройти. Вывода @ я от Вас до сих пор не получил.

Добрый день!

Никаких изменений не произошло в плане super vlan в dgs3612g ?

По кол-ву Super и Sub VLAN-ов или Вы о чём-то другом говорите?!

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