А ничего и не должно, естесственно - он же ARP mode... Я о нем вообще в другом ключе вспомнил: просто раньше сам планировал через IMPb делать привязки на пользователей, для должников - снимать их, но чтобы они, опять же, имели доступ к биллингу, и чтобы доступ к VPN-серверам имели адреса из динамического пула dhcp (чтобы каждый притащенный с работы ноутбук пользователю не нужно было прописывать у нас ради 5 минут в инете). Но в свете обсуждаемого бага подумал и решил от динамического пула отказаться, блокировать пользователей как-нибудь иначе (например, на L3), а IMPb делать на ARP mode, ибо сразу снимаются жесткие требования к количеству свободных правил ACL (и вообще, 500 на устройство - это лучше, чем 200 на 8 портов ) и появляется возможность использовать другие коммутаторы, кроме DES-3526. Ведь, ИМХО, в принципе нет смысла привязываться к одной модели - не самой дешевой и по сути уже устаревшей, основная заслуга которой - бытие плацдармом для отрабатывания программерами ДЛинка различного функционала. )))


Поддерживаю.


Неправильно думаете. Второй профиль IMPb ACL mode как раз и делает, что всех блокирует. Он потому последним быть и должен - после него любые другие неактуальны в большинстве случаев (меньшинство - это не-IP протоколы).


Ага. И это не есть гуд!



Да, не так. А без этого, в общем-то, весь прикладной смысл ACL mode теряется...
Кстати, Иван, пришлите, пожалуйста, в почту B19 для 3526. Там ведь, очевидно, по сравнению с B15 какие-то баги поправлены?

Я Вам прошивку выслал.

pptp vpn у нас нет. интернет раздаем по pppoe, а для его работы ip-адрес не нужен. зато нужен acl, разрешающий всем без разбора свой\чужой ether proto 0x8863 и 0x8864 в сторону центра.

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




жесткая и однозначная привязка ip+mac+port для-всех-без-исключения-и-ни-шага-в-сторону нам не подходит.

на нашем центральном L3 есть аппаратный лимит в 1024 acl, т.е. за вычетом где-то полусотни разных служебных правил остается 950 "не должников". за это число мы вышли, и теперь треба выносить правила на другие железки. желательно подешевле и умеющие правильный acl.

des-3526, как выяснилось, с этой задачей не справляется, по крайней мере с нынешним софтом. хотя в описании сказано, что должна.

есть какие-нибудь рекомендации по поводу железки для сведЕния пары кварталов, которая все-таки умеет правильный acl, низкую цену и годится для установки в ящик на крышу (входы - медь, со всеми ее электрическими прелестями)?

причем желательно из того, что есть здесь и сейчас

Зря, между прочим. Мы вот сейчас вошли в один межсетевой пиринг - приходится всю свою адресацию менять. Если бы не было dhcp - я не представляю, как всем пользователям поменять вручную адреса...


Почему? В чем принципиальная ее невозможность? С другой стороны - если ставить коммутаторы не на агрегацию, а на доступ, то никто не мешает на некоторых портах IMPb просто выключать...


Нет таких железок. О том и речь. Вам нужно четко определиться с потребностями. А именно: требуется ли связка MAC-IP? Просто по MAC'ам контролировать можно без проблем (и не только на оборудовании D-Link), а весь цимус IMPb именно в контроле IP... Если вы не планируете предоставлять никаких дополнительных услуг, которые пойдут по сети, а не по PPPoE, то может вам вообще привязки не нужны?

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


на доступ дорого. не для нашего болота этот вариант


все-же хотелось бы узнать у разработчиков - имеет ли смысл надеяться на патч в ближайшие месяца два-три или стоит отложить эти des-3526 в долгий ящик и смотреть в сторону других железок других производителей?

Мы Вам сразу ответим как будет информация. Однозначно можно надеяться, потому что это похоже на баг.

Из чего состоит слон? из хобота, ушей и бегемота

работающий acl в 3526 есть, и на нем преспокойно можно сделать интересующие привязки и без помощи address_binding - раз уж он не работает так, как нужно.

от красивостей, типа табличек с кнопочками в веб-интерфейсе, конечно, придется отказаться - но это мелочи.

жаль, что нельзя создать профиль примерно такого вида:
create access_profile ethernet source_mac FF-FF-FF-FF-FF-FF ip source_ip_mask 255.255.255.255 profile_id 7

так что придется пользоваться масками по содержимому пакета. т.е. взять готовые из address_binding (не лезть же, в самом деле, в документацию в поисках, где там в пакете что)

функция преобразования пары ip+mac (или одного ip) в маску прикручивается к уже работающим скриптам за 5 минут, чтение списка правил и преобразование их обратно в ip+mac - еще 10 минут.

еще несколько часов на отладку и доведение до ума.



если всё это заработает, как ожидается - новую прошивку с исправленными багом можно и полгода ждать, и год.

всё заработало как и задумывалось.

Именно так. Packet Content Fithering очень гибкий и продвинутый механизм.

Жутко неудобный вариант!


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

а разве binding не для того задумывался, чтобы ни под каким предлогом не пропускать неизвестных?

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Я думаю что нет, так как функционал IP-MAC Binding Permit IP Pool реализован.

К сожалению сделать ACL приоритетнее IMP не представляется возможным и главным образом из-за анализа ARP пакетов в режиме strict.

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

А в режиме loose приоритетный acl прикрутить?

А разрешить заблокированным видеть определённые IP-адреса можно сделать? (по аналогии IP-MAC Binding Permit IP Pool )

Мне крайне необходимо чтобы заблокированные видели сервер статистики. Я понимаю что кроме как средствами ACL на сегодняшний день это не реализовать.... А вдруг! инженерная мысль найдёт какой нибудь выход из положения!

ЗЫ: управляем связками IPMB через SNMP.

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