речь идет не о DHCP и не о головных кабельных модемах, а о абонентских.

Первое сообщение в этой теме датировано 26 июня. Сегодня 18 октября. Прошло почти 4 месяца. Воз все там же?

Я Вам на почту отправил!

Получил, спасибо. Сейчас будем тестировать. Это какая-то бета-версия прошивки, или уже полноценный продукт? Просто ни в новостях, ни в объявлениях, ни на ftp ее пока нет.

Где можно ознакомиться со списком остальных изменений?

это пока beta, релиз будет в ближайшее время, вместе с ним и change log

_________________
С уважением, Карагезов Владислав

Ну что же. Сама функция привязки MAC-IP-port работает. Хотя без граблей не обошлось.
Во-первых, как ни странно, после смены прошивки с 5-09 на 6-10 все Secured Permanent адреса перепутались. С чем связано - не знаю. До прошивки все 24 порта изучены и запомнены. Конфигурация сохранена, свитч перегружен. После перепрошивки все изученные ранее MAC адреса хаотично распределились по портам, естественно клиенты не работают. Поэтому до перепрошивки нужно заранее переписать базу маков, чтобы в дальнейшем переводить ее в MAC-IP binding.
Во-вторых, остались грабли с автоматическим перемещением MAC с неверным IP в блок-лист, после чего его оттуда можно выщемить только руками. Все же это крайне неудобно. Любая ошибка клиента приводит к необходимости вмешательства техсаппорта, даже если клиент сам заметил ошибку и устранил ее. Ну ладно, если это единичный случай. А если в сети объявился левый DHCP-сервер? Например, Wi-Fi роутеры частенько грешат такой пургой. Имеют по умолчанию адрес 192.168.0.1 и включенный встроенный DHCP. Таким образом вся сеть может схватить левые айпишники и попасть в блок-лист. Включая и компьютеры техсаппорта...

В общем, прошивку нужно дорабатывать.

P.S.
Кстати, разработчик замечания по веб-интерфейсу принимает? Есть пара замечаний. Функционированию это конечно не мешает, но постоянно работать не очень удобно.

1. Сортировка. Не совсем понятно, чем руководствуются разработчики, когда сортируют записи в разных порядках. К примеру, в списке изученых МАС-адресов сортировка идет по МАС-адресу, в привязке МАС-IP по IP-адресу, в описаниях портов - по портам. Не есть гут. Думается, что вставить в интерфейс кнопки для смены сортировки по любому признаку (порт, МАС, IP) не очень сложно. А работать будет гораздо удобнее.

2. Вывод записей на экран. Было бы удобно, если бы количество строк можно было регулировать. Например, привязка МАС-IP выдает 20 записей на страницу. А на свитч у меня, как правило, приходится до 26-28 записей (по одной на порт, на некоторых портах иногда по 2 записи). Мне было бы удобно запомнить, к примеру, вывод 30 записей на экран, и видеть все записи сразу.

3. Было бы удобно в мониторинге МАС-адресов дать возможность выбрать группу портов, которые нужно показать (и дать возможность сортировать записи не только по МАС но и по порту). Иначе, если я пытаюсь посмотреть обнаруженные клиентские записи, сталкиваюсь с тем, что на исходящем порту у меня несколько тысяч запомненых МАС, и выбрать среди них порты с 1 по 24 можно только по одному.

4. Учитывая, что в мониторинге есть два близких по смыслу инструмента - MAC address и Browse Arp Table, нельзя ли их объединить? Почему в окне MAC address нельзя добавить поле с айпишниками, а в Browse Arp Table - номер порта, на котором МАС изучен? Было бы намного комфортнее.

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

P.P.S.
Всем поклонникам CLI немедленно идти в сад. Оконный веб-интерфейс сделан для удобства и наглядности работы. Поэтому желающие могут продолжать корчить из себя супер-пупер мега админов, глядя в терминалку и используя текстовый интерфейс. Еще могут переключать на ТВ каналы пакетным переключателем и крутить диск на телефоне, ибо так круче. А мне комфортнее пользоваться оконным интерфейсом, кликать мышкой, и нажимать кнопки на пульте и трубе. Если веб-интерфейс есть, он должен быть удобен в работе.

по поводу борьбы с DHCP серверами - см. ACL и FAQ с примером настройки. Никаких проблем не возникнет.
По поводу ошибки с МАС - по нашим тестам, если все возвратить к разрешенному виду, через оперделенное время клиент может работать, т.к. блокируемый МАС удаляется из таблицы blocked.
По поводу Web интерфейса - можно письмом оформить? Спасибо

_________________
С уважением, Карагезов Владислав

Это в том случае, если левый DHCP сервер подключен к одному из 3526. Однако, есть масса примеров, когда в одной сети находятся как управляемые так и неуправляемые устройства. В этом случае проблема остается. Вы же понимаете, что использование 24-портовых устройств во всем жилом фонде не может быть целесообразным. Я не могу позволить себе тратить 500-1000 долларов на оборудование такой точки в каждой хрущобе с двумя клиентами, которых в моих районах достаточно. Следовательно, управляемость стопроцентной не будет.
Или Вы имели ввиду, что свитч можно настроить на работу только с определенным DHCP сервером? Тоже не вариант. К примеру, мне необходимо сменить адрес DHCP сервера. Для этого мне придется внести изменения в несколько десятков/сотен устройств? Причем, все это время у меня часть пользователей не работает, т.к. обращается или к уже несуществующему, или к еще не прописанному серверу.


Спасибо. Это радует. Я надеюсь, в описании к прошивке это время будет указано? Потому что я, как Вы понимаете, не сидел с секундомером около монитора в ожидании события, которое может и не наступить. Однако, в связи с этим другой вопрос: а где будет сохраняться уведомление о событии? Потому что в свитч-логе событие не отразилось. Профилактика правонарушений дело несомненно благое, но все же о дурных наклонностях клиентов стоит быть в курсе. Т.е. то, что все двери заперты, конечно хорошо. Но о том, что кто-то ходит по этажам и дергает ручки, все же стоит быть в курсе.
Кстати, хорошо бы чтобы в блокировании отражалась причина, по которой клиент не был пропущен: несоответствие МАС или несоответствие IP. Т.е. фиксировать как новые МАС, с которыми ломятся на порт, так и новые IP, которые присвоены разрешенным МАСам. Пока же в блоке виден только МАС.


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

по порядку:
1. Если клиентов мало - используйте другие решения, например DES-21xx.
2. Следует учитывать, что это beta FW. Ваши пожелания по отслеживанию "дерганья дверных ручек" безусловно имеют обоснования, в этом направлении мы работаем. Также, когда будете писать письмо, можете в деталях осветить вашу точку зрения.

_________________
С уважением, Карагезов Владислав

Интересует возможность добавления в IP-MAC Binding связки один IP на порт, но несколько маков.
Пример:
create address_binding ip_mac ipaddress 192.168.168.168 mac_address 66-55-44-33-22-11 ports 5
+
create address_binding ip_mac ipaddress 192.168.168.168 mac_address 11-22-33-44-55-66 ports 5

_________________
Улыбаемся и машем (с) Мадагаскар

Хм, в ответе разработчиков было, что срабатывает защита на any ARP пакет. Неужели на reply не срабатывает? И правильно я понял, что поиск идет в таблице по маку. Т.е. если мак в таблице IP-MAC есть, то сверяется ip и при несовпадение идет блокировка мака. А если мак в таблице IP-MAC отсутствует то и проверки, не взял ли он чужой ip не будет. Т.е. ставить эту опцию не на secured port нет смысла?

_________________
Olleg

Наверное так и надо, тогда на на главных напревлениях (магистралях) можно будет контроллировать привязу IP-MAC для критичных серверов например, а весь пользовательский трафик пропускать без изменений, руководствуясь принципом, что у нас в сети кривых маков не бывает Естересвенно если на других свитчах н аюзерских портах 100% контроль мас адрессов

А зачем вам это? Это же противоречит основным принципам безопасности!

Еще не все пользователи купили себе домашние мыльницы di-604, di-624, di-624+ и etc... Ныться начинают. А так было бы подконтрольное использование.

_________________
Улыбаемся и машем (с) Мадагаскар