white_crow Опубликовано 7 июля, 2010 (изменено) · Жалоба 1. D_link на первом месте при использовании на доступе. Понятно - что цена вкусная. Я про умные (управляемые) свичи. Так вот - поделитесь, какие у них недостатки, косяки, ограничения , которые могут сказаться в будущем, масштабируемость, профили для мультикаста и т.д.... (У нас на доступе Zyxel MES-3528 - меня вполне устраивает функционал. По крайней мере пока. Но руководство соблазняют коллеги из соседних городов на длинк, прежде всего ценой. Я не знаю цен на длинк, и точных цен на зухел, но примерно порядка 300 USD, и в последнее время вроде цена снизилась ниже трех сотен.... (мне нужно реальное сравнение, чтобы иметь реальные контраргументы, ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel ) Изменено 7 июля, 2010 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 7 июля, 2010 · Жалоба Почитайте соседние ветки - все разжевано. "+" - цена, быстрая реакция на требования и баги в прошивках, интересные функции, адаптированные под провайдинг, все-таки самый вменяемый саппорт, распространенность. "-" - проблемы с новыми коммутаторами в плане хеша. Поделитесь про новые месы от зикселя. Как они в работе, какие плюсы-минусы. Очень интересно. Также хотелось бы узнать на чем агрегация и ядро. Можно в личку. Заранее благодарен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 июля, 2010 · Жалоба >ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel Для этого надо писать код с применением ООП, применяя всего лишь обычное наследование классов, таким образом, добавление нового железа в сеть с точки зрения автоматизированного управления - это написание очередного класса(у меня уходит где-то ~25-50 Кб кода на одну железку(на самом деле целую серию одного вендора) + базовый класс на ~30 Кбайт), без переписывания старого кода. Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках. Всё равно какой-никакой зоопарк будет, если не сегодня, так "завтра", когда используемые Вами коммутаторы начнут исчезать со складов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 7 июля, 2010 · Жалоба >ибо зоопарк из свичей плодить не хочется - все управление по SNMP и телнету заточено на Zyxel Для этого надо писать код с применением ООП, применяя всего лишь обычное наследование классов, таким образом, добавление нового железа в сеть с точки зрения автоматизированного управления - это написание очередного класса(у меня уходит где-то ~25-50 Кб кода на одну железку(на самом деле целую серию одного вендора) + базовый класс на ~30 Кбайт), без переписывания старого кода. Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках. Всё равно какой-никакой зоопарк будет, если не сегодня, так "завтра", когда используемые Вами коммутаторы начнут исчезать со складов. +1 делаю так же, но это для тех кто управление сам к билингу прикручивал. Я сделал так, что можно указать какими способами железка управляется (telnet, snmp, ssh - это на самом деле можно считать как telnet) и соответствующий справочник с набором команд, типа скриптования для свича. Все эти скрипты именуются по человечески для мега-саппорта, типа "показать таблицу маков". Выполнить можно сразу на группе железок. С телнетом если честно мучался больше всего, т.к. пришлось реализовать протокол полностью со всеми опциями и управляющими командами, из-за разных настроек для железок разных производителей, тупо отключить все опции не прокатывает :( В случае с одним вендором можно конечно ориентироваться на его управлялку, но вендор может когда-то и поменяться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 8 июля, 2010 · Жалоба (У нас на доступе Zyxel MES-3528 - меня вполне устраивает функционал. По крайней мере пока. Но руководство соблазняют коллеги из соседних городов на длинк, прежде всего ценой.у делинка нет системы мониторинга открытия двери и прочего, вы этот функционал используете?... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 8 июля, 2010 · Жалоба у делинка нет системы мониторинга открытия двериа loopdetect? +1 к классам snmp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 8 июля, 2010 · Жалоба Управление по телнет надо сводить к 0, т.к. в разных прошивках одни и те же команды могут давать разный вывод и весь парсинг слетает. С SNMP такого как бы нет или очень-очень малые изменения в новых прошивках. Вы просто не умеете писать парсеры. А раз уж длинк так чутко относится к пожеланиям кастомеров, то давно бы уже стребовали реализовать какой-нибудь netconf или аналог. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 июля, 2010 · Жалоба Кто чего не умеет это один вопрос. Я говорю про то, что вывод телнет никак не формализован(в отличии от весьма строгой структуры snmp) и когда в следущей прошивке заменят точку на запятую и потом сиди отлавливай почему ничего не работает. Да, можно написать парсер не очень криво, учесть заранее лишние пробелы, новые неизвестные строки и т.п., но всё равно всё не предусмотришь. >то давно бы уже стребовали реализовать какой-нибудь netconf или аналог Ну если по большому счёту, то разница между netconf и snmp не велика, единственное что по snmp не всегда можно узнать почему железка отказалась что-либо сконфигурить у себя, но это вопрос имплементации, всегда можно сделать статус-переменную в которой хранить код ошибки и такое зачастую встречается(почти у всех так при работе с файлами/конфигами по snmp) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
madgnu Опубликовано 8 июля, 2010 · Жалоба Из минусов - быть извечным бета-тестером новых прошивок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 июля, 2010 · Жалоба >Из минусов - быть извечным бета-тестером новых прошивок. Да это так со всеми чисто китайскими коммутаторами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 (изменено) · Жалоба Почитайте соседние ветки - все разжевано.Спасибо, сотни постов некогда читать (много шелухи среди зерен), хотел, чтобы кто-то четко сказал самые главне "узкие места" в двух словах. По-поводу зиксел 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 июля, 2010 · Жалоба >признак вендора свича тоже сразу предусмотрен, для ветвления логики программы, поэтому переход на другого вендора не будет катастрофой, но придется поработать.... Это Вы сейчас так думаете, а когда на каждый чих будет десяток ветвлений, то замучаетесь лазеть по исходникам. Ну если нет зоопарка, то ладно, дело ваше... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 · Жалоба Да все нормально разрулим. Вы преувиличиваете проблему зоопарка свичей и значение объектно-ориентированного программирования в данной задаче. В конце концов - при переходе на другие свичи - есть время - взял драг эн дропом скопировал процедуоуи подкрутил ее под новый свич. А выбор по признаку свича - заранее заложен. И всетаки - не верю, что длинки - такие классные свичи.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 8 июля, 2010 · Жалоба white_crow Очень интересно расспросить вас про эти зуксели. Как у него с определением петель в одном порту? Знаю что он не умеет autorecovery. По-моему это очень неудобно! Сколько у вас мак адресов в одном вилане? Сколько у вас зукселей стоят в сети и как долго вы их эксплуатируете? Про длинки могу рассказать, но сочинения писать не умею, готов ответить на конкретные вопросы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 8 июля, 2010 (изменено) · Жалоба У des-3526 есть ряд багов: дохнут гигабитные порты, дохнут блоки питания, выгорают медные порты, отказывают вентиляторы, вентиляторы начинают "рычать", чем пугают жильцов. Всё это происходит не сильно часто, но происходит. Блоки питания работают поразному в разных партиях. Из багов прошивки: периодически сами собой включаются отключенные порты, не всегда отключаются гигабитные порты. ACL на порту не режут первый пакет, он поступает в таблицу коммутации. Если клиент ставит мак шлюза, порезать железно это не получается. Перестают собираться логи. CPU зашкаливает на некоторых прошивках. Периодически коммутаторы от длинка виснут: 3526 редко, 30ХХ часто висли, 3828 всегда (по крайней мере дело так обстаяло при запуски серии). P.S. но в целом 3526 я доволен. Изменено 8 июля, 2010 пользователем secandr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 (изменено) · Жалоба white_crowОчень интересно расспросить вас про эти зуксели. Как у него с определением петель в одном порту? Знаю что он не умеет autorecovery. По-моему это очень неудобно! Сколько у вас мак адресов в одном вилане? Сколько у вас зукселей стоят в сети и как долго вы их эксплуатируете? Про длинки могу рассказать, но сочинения писать не умею, готов ответить на конкретные вопросы. Петли нормально определеяет (имеется ввиду петля в пределах коммутатора) И да - после определения петли - сам не восстановвится. (но не актуально - я за год не встречал такого случая) С учетом, что каждый свич 24 порта и на каждыый свич - свой VLAN - то не много совсем маков. Делаем Ethernet около года. Штук двести свичей. Пока проблем не было. Изменено 8 июля, 2010 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 (изменено) · Жалоба У 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 8 июля, 2010 · Жалоба Из багов прошивки: периодически сами собой включаются отключенные порты, не всегда отключаются гигабитные порты. ACL на порту не режут первый пакет, он поступает в таблицу коммутации. Если клиент ставит мак шлюза, порезать железно это не получается. Перестают собираться логи. CPU зашкаливает на некоторых прошивках.Не согласен в корне! Вы явно давненько не имели дело с 3526, потестируйте ARP spoofing prevention на предмет подстановки маков клиентами, будете удивлены неимоверно ;) . Более того, с помощью PCF ACL можно резать вообще что угодно по любой сигнатуре в первых 80-ти байтах пакета. У нас весь доступ на 3526 построен, и ни одной из вышеперечисленных болячек эти свичи не страдают уже пару лет как.А прошивки 6-й версии - вообще песня. Можно, например промерять длину абонентского кабеля по порту "на лету". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 · Жалоба PCF ACL - это круто. В Zyxel Такого нет в помине. А этот PCF ACL - что еще умеет? Он программно выполняется? Есть ограничение по количеству правил и производительности? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 8 июля, 2010 · Жалоба Ну а если подумать, то этот PCF нужен только для того, чтобы порезать uTP у кого слабенькое ядро. И судя по теме, где это обсуждалось, достаточно сложно составить хорошие правила, чтобы не порезать чего-нибудь лишнего. Ну может ещё какой-нибудь мусор типа netbios'а, хотя не видно ничего плохого в том, что если пару кбит/с будет добираться до центра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 8 июля, 2010 · Жалоба PCF ACL - это круто. В Zyxel Такого нет в помине.А этот PCF ACL - что еще умеет? Он программно выполняется? Есть ограничение по количеству правил и производительности? Круто, то круто, только правила забешся составлять, а еще у каждой модели (а то и прошивки) свои особенности.Работает на асиках, т.е. аппаратно. Ограничения есть, но если шибко не увлекаться, то запас достаточный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 8 июля, 2010 (изменено) · Жалоба Я читал соседню ветку про uTP p2p протокл от начала до конца. И понял - это единственное применения такому "функционалу" ACL - первых 80 байт... Но понял - это костыль неимоверный. Сигнатуры буду постоянно меняться - каждый раз следить за этим, искать новые признаки p2p, и менять на всех свичах правила - жесть. А если будут шифровать и рандомные схемы применять..... Всетаки лучше укрепить ядро, чтобы прожевал pps, или "промолотил" централизованно ограничения на сессии и т.д. ______ Но лучше давить на создателей BitTorrent- договариваться, чтобы оптимизировали протокол и не портили жысь провайдерам.... (хотя одно другому не мешает) Изменено 8 июля, 2010 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 8 июля, 2010 · Жалоба Круто, то круто, только правила забешся составлять, а еще у каждой модели (а то и прошивки) свои особенности. Ничего там нет сложного. Час покурить мануалы и сможешь составить правило под любой трафик Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 9 июля, 2010 · Жалоба Более того, с помощью PCF ACL можно резать вообще что угодно по любой сигнатуре в первых 80-ти байтах пакета.. 80 это у 3526. А он уже все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 9 июля, 2010 · Жалоба Ну если по большому счёту, то разница между netconf и snmp не велика, единственное что по snmp не всегда можно узнать почему железка отказалась что-либо сконфигурить у себя, но это вопрос имплементации, всегда можно сделать статус-переменную в которой хранить код ошибки и такое зачастую встречается(почти у всех так при работе с файлами/конфигами по snmp) Ой. Сделайте мне добавление BGP нейбора по snmp. Не применяя tftp конечно же. Потом поговорим про остальную "невеликую разницу". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...