Созрело у меня такое предложение.

Постепенно все больше и больше ставим свичей уровня DES-30xx/35xx.
Соответственно, приходим к столь желанной схеме с умным доступом, когда каждый абонент и своем порту.
Везде используем привязки.

И тут встал вопрос - а зачем нам в такой схеме контролировать МАК в привязках ? Если мы знаем в каком порту какой абонент - то достаточно контролировать его ИП только на этом порту. Без разницы - используется DHCP или нет. Даже больше - контроль мака в такой ситуации является припятствием к более полноценному предоставлению услуг со стороны оператора, так как лишает абонента возможности самостоятельно, без уведомления кого/либо менять свое оконечное устройство.
И вот собственно - предложение - доработать функционал IMPB до возможность создания привязки, контролирующей только соответствие порта и ИП.
Самым простым способом реализовать это мне видится просто договориться что если в привязки указан мак ff:ff:ff:ff:ff:ff - значит для этой привязки пропускать любой мак.
В реальности такой мак не используется. Ну или какой другой мак выбрать для этих целей.

Мне кажется такая реализация будет и достаточно простой и очень востребовательной.
С нетерпением буду ждать ответа

в 3526 есть IP-MAC Binding Permit IP Pool
может подойдёт? хотя сам не проверял.

Подойдёт, так-же можно использовать набор ACL или VLAN per user

использование ACL наверное все таки более универсально, т.к. на 3028 нет Permit pool, но в случае ACL практически лишаемся возможности смотреть логи в случае несанкционированного подключения или смены IP у абонента.
Скажем поменял IP абонент-чайник (хз как, вирус, сам наэксперементировал) и не признается в этом, а саппорт будет гадать, что же произошло. Опять же в случае с ACL есть ограничение на стратегию формирования правил.
Вообщем как обычно нет универсального решения под все типы задач.

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

А чем не подходят ACL в этом случае?