[white_crow]

1. D_link на первом месте при использовании на доступе. Понятно - что цена вкусная. Я про умные (управляемые) свичи.

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

 

 

(У нас на доступе Zyxel MES-3528 - меня вполне устраивает функционал. По крайней мере пока. Но руководство соблазняют коллеги из соседних городов на длинк, прежде всего ценой.

Я не знаю цен на длинк, и точных цен на зухел, но примерно порядка 300 USD, и в последнее время вроде цена снизилась ниже трех сотен....

 

(мне нужно реальное сравнение, чтобы иметь реальные контраргументы, ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel )

 

 

Изменено 7 июля, 2010 пользователем white_crow

[yakuzzza]

Почитайте соседние ветки - все разжевано.

"+" - цена, быстрая реакция на требования и баги в прошивках, интересные функции, адаптированные под провайдинг, все-таки самый вменяемый саппорт, распространенность.

"-" - проблемы с новыми коммутаторами в плане хеша.

 

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

 

Заранее благодарен.

[s.lobanov]

>ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel

 

Для этого надо писать код с применением ООП, применяя всего лишь обычное наследование классов, таким образом, добавление нового железа в сеть с точки зрения автоматизированного управления - это написание очередного класса(у меня уходит где-то ~25-50 Кб кода на одну железку(на самом деле целую серию одного вендора) + базовый класс на ~30 Кбайт), без переписывания старого кода.

Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках.

 

Всё равно какой-никакой зоопарк будет, если не сегодня, так "завтра", когда используемые Вами коммутаторы начнут исчезать со складов.

[SokolovS]

>ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel

 

Для этого надо писать код с применением ООП, применяя всего лишь обычное наследование классов, таким образом, добавление нового железа в сеть с точки зрения автоматизированного управления - это написание очередного класса(у меня уходит где-то ~25-50 Кб кода на одну железку(на самом деле целую серию одного вендора) + базовый класс на ~30 Кбайт), без переписывания старого кода.

Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках.

 

Всё равно какой-никакой зоопарк будет, если не сегодня, так "завтра", когда используемые Вами коммутаторы начнут исчезать со складов.

+1 делаю так же, но это для тех кто управление сам к билингу прикручивал. Я сделал так, что можно указать какими способами железка управляется (telnet, snmp, ssh - это на самом деле можно считать как telnet) и соответствующий справочник с набором команд, типа скриптования для свича. Все эти скрипты именуются по человечески для мега-саппорта, типа "показать таблицу маков". Выполнить можно сразу на группе железок. С телнетом если честно мучался больше всего, т.к. пришлось реализовать протокол полностью со всеми опциями и управляющими командами, из-за разных настроек для железок разных производителей, тупо отключить все опции не прокатывает :(

 

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

[zoro]

(У нас на доступе Zyxel MES-3528 - меня вполне устраивает функционал. По крайней мере пока. Но руководство соблазняют коллеги из соседних городов на длинк, прежде всего ценой.

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

 

 

[terrible]

у делинка нет системы мониторинга открытия двери

а loopdetect?

 

+1 к классам snmp

[tgz]

Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках.

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

 

[s.lobanov]

Кто чего не умеет это один вопрос.

Я говорю про то, что вывод телнет никак не формализован(в отличии от весьма строгой структуры snmp) и когда в следущей прошивке заменят точку на запятую и потом сиди отлавливай почему ничего не работает. Да, можно написать парсер не очень криво, учесть заранее лишние пробелы, новые неизвестные строки и т.п., но всё равно всё не предусмотришь.

 

>то давно бы уже стребовали реализовать какой-нибудь netconf или аналог

 

Ну если по большому счёту, то разница между netconf и snmp не велика, единственное что по snmp не всегда можно узнать почему железка отказалась что-либо сконфигурить у себя, но это вопрос имплементации, всегда можно сделать статус-переменную в которой хранить код ошибки и такое зачастую встречается(почти у всех так при работе с файлами/конфигами по snmp)

[madgnu]

Из минусов - быть извечным бета-тестером новых прошивок.

[s.lobanov]

>Из минусов - быть извечным бета-тестером новых прошивок.

 

Да это так со всеми чисто китайскими коммутаторами.

[white_crow]

Почитайте соседние ветки - все разжевано.

Спасибо, сотни постов некогда читать (много шелухи среди зерен), хотел, чтобы кто-то четко сказал самые главне "узкие места" в двух словах.

 

По-поводу зиксел MES-3528.

У меня пока нет проблем, но и срок еще не большой, абонентов не много (за год 1200, динамика сохраняется).

 

На данный момент используется следующий функционал:

Серые IP адреса раздаются DHCP, конфиг которого форрмируется из базы данных абонентов. Используется Option82+DHCP-snooping+ARPinspection. Таким образом юзер получает всегда один и тот же серый IP. Мак адреса не собираем - привязка к коммутатору и порту - это заносится в базу при заключении договора.

Сменить свой IP юзер ручками не может.

Схема VLAN на доступ. (Терминация VLAN - на L3 агрегации - Соответсвенно Межабонентский траф через центр не гоняем)

Межабонентский траф - отдельная услуга. Рулиться с помощью добавления разрешающего правила в коммутатор по telnet (Написана обвязка к базе для управления).

Таким же образом регулируется доступ к разным пакетам TVoIP вещания - на доступе работает MVR , IGMP-снупинг, IGMP-фильтрация (достаточно гибкие пакеты каналов можно настроить).

Еще используется bandwidth-control на каждом порту - тоже через визуальную обвязку из базы хомячков рулится скорость на порту.

 

Разные другие рюшечки пока не юзаю. В будущем может понадобиться только разделение трафика на приоритеты.

 

На агрегации или XGS-4728F (10G 2 порта, 24шт оптических 1G, 2шт 12G порта типа стек) или 4012F

На ядре пока тоже XGS-4728F (траф пока не большой....)

 

_____

И да, извините, но до ООП пока не доросли : )))) (нам бы все побыстрее - чисто процедурное программирование, но, команды для свичей и т.д храняться в базе Firebird, и признак вендора свича тоже сразу предусмотрен, для ветвления логики программы, поэтому переход на другого вендора не будет катастрофой, но придется поработать....)

Может это длинк часто меняет синтаксис команд, точки на запятые - но все остальные придерживаются строгости в этом смысле Like a Cisco IOS

Изменено 8 июля, 2010 пользователем white_crow

[s.lobanov]

>признак вендора свича тоже сразу предусмотрен, для ветвления логики программы, поэтому переход на другого вендора не будет катастрофой, но придется поработать....

 

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

[white_crow]

Да все нормально разрулим. Вы преувиличиваете проблему зоопарка свичей и значение объектно-ориентированного программирования в данной задаче. В конце концов - при переходе на другие свичи - есть время - взял драг эн дропом скопировал процедуоуи подкрутил ее под новый свич. А выбор по признаку свича - заранее заложен.

 

И всетаки - не верю, что длинки - такие классные свичи....

 

 

[mschedrin]

white_crow

Очень интересно расспросить вас про эти зуксели.

Как у него с определением петель в одном порту? Знаю что он не умеет autorecovery. По-моему это очень неудобно!

Сколько у вас мак адресов в одном вилане?

Сколько у вас зукселей стоят в сети и как долго вы их эксплуатируете?

 

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

[secandr]

У des-3526 есть ряд багов: дохнут гигабитные порты, дохнут блоки питания, выгорают медные порты, отказывают вентиляторы, вентиляторы начинают "рычать", чем пугают жильцов. Всё это происходит не сильно часто, но происходит. Блоки питания работают поразному в разных партиях.

 

Из багов прошивки: периодически сами собой включаются отключенные порты, не всегда отключаются гигабитные порты. ACL на порту не режут первый пакет, он поступает в таблицу коммутации. Если клиент ставит мак шлюза, порезать железно это не получается. Перестают собираться логи. CPU зашкаливает на некоторых прошивках.

 

Периодически коммутаторы от длинка виснут: 3526 редко, 30ХХ часто висли, 3828 всегда (по крайней мере дело так обстаяло при запуски серии).

 

P.S. но в целом 3526 я доволен.

Изменено 8 июля, 2010 пользователем secandr

[white_crow]

white_crow

Очень интересно расспросить вас про эти зуксели.

Как у него с определением петель в одном порту? Знаю что он не умеет autorecovery. По-моему это очень неудобно!

Сколько у вас мак адресов в одном вилане?

Сколько у вас зукселей стоят в сети и как долго вы их эксплуатируете?

 

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

Петли нормально определеяет (имеется ввиду петля в пределах коммутатора)

И да - после определения петли - сам не восстановвится. (но не актуально - я за год не встречал такого случая)

С учетом, что каждый свич 24 порта и на каждыый свич - свой VLAN - то не много совсем маков.

Делаем Ethernet около года. Штук двести свичей. Пока проблем не было.

Изменено 8 июля, 2010 пользователем white_crow

[white_crow]

У des-3526 есть ряд багов: дохнут гигабитные порты, дохнут блоки питания, выгорают медные порты, отказывают вентиляторы, вентиляторы начинают "рычать", чем пугают жильцов. Всё это происходит не сильно часто, но происходит. Блоки питания работают поразному в разных партиях.

 

Из багов прошивки: периодически сами собой включаются отключенные порты, не всегда отключаются гигабитные порты. ACL на порту не режут первый пакет, он поступает в таблицу коммутации. Если клиент ставит мак шлюза, порезать железно это не получается. Перестают собираться логи. CPU зашкаливает на некоторых прошивках.

 

Периодически коммутаторы от длинка виснут: 3526 редко, 30ХХ часто висли, 3828 всегда (по крайней мере дело так обстаяло при запуски серии).

 

P.S. но в целом 3526 я доволен.

Порты не дохли, не выгорали.

Блоки питания не дохли (они внутри)

ACL режут нормально. (очень специфическая хрень -нужно привыкнуть, совсем не похоже на like a Cisco, ограничено 128 правил на свич - т.к. работает аппаратно и зашито жетско эта цифра. Правила не гибкие, но мне хватает - MAC, IP, VLAN, Port, Protocol, DSCP) (В дилнке вроде ? там чуть ли не содержание пакета можно ловить, но это - жесть)

Работает - ARP inspection, Port Security ( к-во маков на порт можно ограничить, с обучением , таймаутом), - так что с маками баловаться и флудить не получиться. Тот мак, что послал запрос на DHCP и получил адрес с учетом значения опции 82 - тот работает - остальные - досвидос.

Broadcast Storm Control - на каждом порту независмо.

CPU тоже может зашкаливать, когда мультикаст шмаляет на vLAN управления - управление в отдельный VLAN - и нет проблем.

Завианий свичей не было. Охлаждение - пассивное - нет кулеров.

Изменено 8 июля, 2010 пользователем white_crow

[Alexandr Ovcharenko]

Из багов прошивки: периодически сами собой включаются отключенные порты, не всегда отключаются гигабитные порты. ACL на порту не режут первый пакет, он поступает в таблицу коммутации. Если клиент ставит мак шлюза, порезать железно это не получается. Перестают собираться логи. CPU зашкаливает на некоторых прошивках.

Не согласен в корне! Вы явно давненько не имели дело с 3526, потестируйте ARP spoofing prevention на предмет подстановки маков клиентами, будете удивлены неимоверно ;) . Более того, с помощью PCF ACL можно резать вообще что угодно по любой сигнатуре в первых 80-ти байтах пакета. У нас весь доступ на 3526 построен, и ни одной из вышеперечисленных болячек эти свичи не страдают уже пару лет как.

А прошивки 6-й версии - вообще песня. Можно, например промерять длину абонентского кабеля по порту "на лету".

[white_crow]

PCF ACL - это круто. В Zyxel Такого нет в помине.

А этот PCF ACL - что еще умеет?

Он программно выполняется?

Есть ограничение по количеству правил и производительности?

[s.lobanov]

Ну а если подумать, то этот PCF нужен только для того, чтобы порезать uTP у кого слабенькое ядро. И судя по теме, где это обсуждалось, достаточно сложно составить хорошие правила, чтобы не порезать чего-нибудь лишнего. Ну может ещё какой-нибудь мусор типа netbios'а, хотя не видно ничего плохого в том, что если пару кбит/с будет добираться до центра.

[shicoy]

PCF ACL - это круто. В Zyxel Такого нет в помине.

А этот PCF ACL - что еще умеет?

Он программно выполняется?

Есть ограничение по количеству правил и производительности?

Круто, то круто, только правила забешся составлять, а еще у каждой модели (а то и прошивки) свои особенности.

Работает на асиках, т.е. аппаратно.

Ограничения есть, но если шибко не увлекаться, то запас достаточный.

[white_crow]

Я читал соседню ветку про uTP p2p протокл от начала до конца. И понял - это единственное применения такому "функционалу" ACL - первых 80 байт...

Но понял - это костыль неимоверный. Сигнатуры буду постоянно меняться - каждый раз следить за этим, искать новые признаки p2p, и менять на всех свичах правила - жесть. А если будут шифровать и рандомные схемы применять.....

Всетаки лучше укрепить ядро, чтобы прожевал pps, или "промолотил" централизованно ограничения на сессии и т.д.

 

______

Но лучше давить на создателей BitTorrent- договариваться, чтобы оптимизировали протокол и не портили жысь провайдерам....

(хотя одно другому не мешает)

Изменено 8 июля, 2010 пользователем white_crow

[Negator]

Круто, то круто, только правила забешся составлять, а еще у каждой модели (а то и прошивки) свои особенности.

Ничего там нет сложного.

Час покурить мануалы и сможешь составить правило под любой трафик

 

[DVM-Avgoor]

Более того, с помощью PCF ACL можно резать вообще что угодно по любой сигнатуре в первых 80-ти байтах пакета..

80 это у 3526. А он уже все.

[tgz]

Ну если по большому счёту, то разница между netconf и snmp не велика, единственное что по snmp не всегда можно узнать почему железка отказалась что-либо сконфигурить у себя, но это вопрос имплементации, всегда можно сделать статус-переменную в которой хранить код ошибки и такое зачастую встречается(почти у всех так при работе с файлами/конфигами по snmp)

Ой. Сделайте мне добавление BGP нейбора по snmp. Не применяя tftp конечно же. Потом поговорим про остальную "невеликую разницу".