Так нужно использовать, тогда и Permit IP Pool не потребуется.

отказались от использования т.к. нестабильно работает данный функционал.

Опишите, пожалуйста, подробно какие проблемы возникают при работе DHCP Snooping, будем анализировать.

Denis Evgraphov, Вам наш инженер уже третью страницу пытается объяснить что нам нужен permit pool, а Вы говорите что DHCP Snooping лучше. Вам некажется что это уже из области демагогии? Ответьте как оф. представитель по существу на заданные нашим инженером вопросы?

Господа, мне одному кажется что будет продуктивнее просто созвониться и выяснить все вопросы в режиме "on_line"?

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

Суть:
Есть белые 172.х.х.х, получаемый клиентом в случае, если мак клиента зарегистрирован как лигитимный на DHCP серваке.
Есть серые 10.х.х.х, выдаваемый клиенту в противном случае. с него клиент может зайти в личный кабинет и зарегистрироватаь свой МАС.

Теперь моделируем ситуацию:
Клиент поменял девайс, заходит с нового МАС, сервак выдает 10.тра.ля.ля, PIMB в режиме dhcp_snooping выхватывает связку и лочит на порту на время LeaseTime. Тем временем клиент регит МАС, делает ReNew, но старая связка все еще активна, и клиент остается у разбитого корыта, пока не истечет LeaseTime.


Другая ситуация:
У клиента есть несколько машин, нет NAT (тупо, на роутере шнурок от провайдера сунули в LAN), а в интернет клиент выходит только с одной. Если кто-то из неИнет машин ломанется раньше, то она отхватит белыйIP, тогда ИнетМашине адреса не достанется.
Понимаю что ситуация идиотская, но она бывает.

J0kER01
Обе эти ситуации решаются через
или 3 или 4 или "сколько там у клиента компов" или (если совсем не заморачиваться) no_limit

Из мануала:


config address_binding dhcp_snoop max_entry ports 1 limit 2
на свитче создается новая связка, т.к. max_entry 2.

Другая ситуация:

она не может отхватить белый айпи, у всех машин одинаковые мак адреса что ли? она отхватывает серый айпи. Когда Инет машина ломанется в сеть, она таки получит свой белый адрес, т. к. опять таки max_entry 2

А если так уж не хочется используется max_entry, в чем проблема в dhcp сервере настроить lease time для пулов/сетей из 10.0.0.0/8 равным 2-3 минутам?
За это время и адрес можно успеть зарегистрировать, и подождать пока для отключенного от интернета неИнет компа пропадет связка.

ArDamant
смотрите предыдущую страницу:

Permit IP Pool на данной серии не планируется, как я уже писал, и поэтому я предлагаю решить имеющиеся проблемы при помощи DHCP Snooping. В плане решения я солидарен с SpiderX, кроме пункта с маленьким Lease Time, который может сильно увеличить нагрузку на DHCP сервер.
Запросить указанный Вами функционал, как я уже тоже писал можно, но быстро его реализовать, к сожалению, не получится, так как уже сложилась большая очередь запросов на расширение функционала по данной серии и поэтому проблему я рекомендую решать имеющимися средствами.

функционал дхцп снупинг привязывает всё подряд без разбора, разделить пулы с его помощью нельзя! поэтому не предназначен для решения вопроса доступа!

поскольку пермит пул как функционал добавлять не собираются, вопрос снят!

Какой у Вас будет пул на DHCP сервере, такие и создадутся привязки на коммутаторе при использовании DHCP Snooping.

задача в разделении доступа, про сервера речи и не шло.

Насколько я понимаю, имеющимися средствами вы решать задачу просто напросто не хотите - хотя решение вам указали.
И попытаться настроить DHCP сервер так, чтобы зарегистрированным mac адресам выдавались одни IP адреса, а незарегистрированным - другие - вы тоже по какой-то причине не имеете желания.

Тему закрываю.