Потратил сегодня еще пару часов на тестирование. Все заработало!, но выявлен однозначный баг, если в момент настройки ip_mac binding клиент уже подключен к какому то порту коммутатора, то его MAC на этом порту потом никогда не блокируется даже после перезагрузки (на других портах пожалуйста, даже если клиент подключен к подчиненному коммутатору), лечиться выключением порта удалением пары внесением пары заново и повторным включением порта, если нужны развернуты подробности могу вечером опубликовать.

мне нужны

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

судя по всему, это подпадает вот под этот ответ от разработчиков, который я уже публиковал в этом же кейсе ранее:

"For non-IP packet (ie, L2 packet or IPX packet), those packet will be forwarded by switch. The IP-MAC binding feature is designed for IP protocol.
However, once that PC issue any ARP packet and the IP-MAC doesn't match that specified list, that MAC will be placed in fdb table with "blockbyAddrBind" state, and that MAC will be blocked, including L2, IPX, etc. packet with that MAC."

Т.е., на основе моих тестов, ПК, который подключен к свичу ДО настройки IP-MAC Binding просто уже занес в свою таблицу arp запись для того хоста, который он, к примеру, пингует. Именно поэтому его не блокирует свич. Как только таблицу arp на ПК очистите - неправильный ip сразу блокируется, т.е. как раз то, о чем писалось выше:
"However, once that PC issue any ARP packet and the IP-MAC doesn't match that specified list, that MAC will be placed in fdb table with "blockbyAddrBind" state, and that MAC will be blocked"
tester в своем посте (еще раз прошу прощения, снес случайно) писал об этом: если на ПК задать static arp запись для destination хоста? то даже с неправильным ip этот ПК будет продложать взаимодействовать с destination хостом и свич не блокирует его по IP-MAC Binding.
Если у кого-то есть мысли или дополнения - с удовольствием выслушаю.
Можно ли этот механизм усовершенстовать - это уже следующий вопрос, будем запрашивать разработчиков.

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

Это говорит о бесполезности IP-MAC binding в данной реализации. Решение - очистите таблицу, и все заработает .
Клиент может путем несложной настройки своей машины обойти IP-MAC binding и попробуйте его заставить очищать таблицу .
Фиксить этот баг сколько будут неизвестно.
Вариант - искать сложные пассажи бубном - вдруг наткнемся на правильную последовательность (не исключено, что у кого-то это получилось).

1. Никто не предлагает чистить таблицу arp у клиента.
2. По поводу "Фиксить этот баг сколько будут неизвестно" - ну неправда ваша, я же писал Вам, что сейчас функция расширяется и мы заинтересованы в том, чтобы на этом этапе решить все возможные проблемы.
3. По поводу подлкючения клиентов - сложных пассажей не требуется, думаю. Достаточно заранее прописать в таблицу IP-MAC Binding нового подключаемого клиента и потом только уже давать ему доступ в сеть. По любому ему придется послать arp запрос на шлюз по умолчанию. Если что-то не так - свич его блокирует.

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

Да, действительно блокирование происходит при приходе на свич arp-request пакета с неверной парой MAC-IP, все остальные пакеты не проверяются, да и на мой взгляд производительности не хватит и в общем случае не нужно, достаточно поставить на шлюзе статикой MAC-IP и все, клиент поменявший IP не сможет общаться со шлюзом и все (пара то не совпадает), единственное, что бы я посоветовал разработчикам это добавить обработку не только arp-request, но и arp-reply тогда эту проблему можно будет 100% решить, ибо в ответе от хоста будет содержаться неверная пара, а ответ будет 100% нужен иначе машина на той стороне не сможет с ним связаться (на ней то никто не будет статикой левую пару прописывать ).

Т.е. возвращаемся к необходимости ведения ARP таблицы на шлюзе...
А может сделать принудительные ARP опросы со шлюза? Т.е. как только на порту изучен новый МАС, свич ему посылает ARP запрос, при отсутствии ответа или неправильном ответе, блокирует этот МАС на 3 минуты. Потом все заново. Главное - чтоб он при этом мог посылать SNMP трап о факте нарушения. А то кулхацкеры могут ковровыми рассылками пакетов оставлять правильных абонентов без связи, а админи ниочем и не узнают.

рр

1.
2. ). На вопрос - КОГДА - дается ответ, что к октябрю новая прошивка будет. У меня 90% уверенность, что исправить, чтобы толком работало, не успеют (вспомним модель 2108).

По поводу поставить на шлюзе статикой MAC-IP - так зачем тогда вообще 3526 нужен ? Ставим 2108 и на шлюзе статикой MAC-IP.
Да, кстати, можем продемонстрировать как обходится привязка на шлюзе статикой MAC-IP.
Наше мнение - опираясь на анализ ARP-пакетов, решить проблему на 100% вряд ли можно. Будем рады, если ошибаемся

Оч. интересно, как обходить такую привязку на шлюзе? Можно в личку.
Была мысль нагло посылать свои запросы и слушать весь трафик, вибирая нужные нам пакеты. Комп жертвы будет их отбрасывать.

А почему бы не использовать для целей IP-MAC-Port Binding ACL-ы? Ведь DES-3526 умеет фильтровать по Packet Content Mask. Нужно создать профиль для добавления правил, которые будут разрешать весь ARP; два профиля с масками, по которым будет вырезаться Source MAC, Source IP и Destination MAC, Destination IP; и профиль для добавления правил, которые будут запрещающать все на том или ином порту. Или я что-то не так понимаю?

Ага, только давай не будем через форум общаться, я же в соседнем кабинете сижу )

Разработчикам я тоже посоветовал бы для контроля IP адреса на комутаторе исползовать DHCP. Сделать как DOCSIS сетях - если клиент получил IP адрес от DHCP сервера, считать IP адрес валидным иначе блокируем этот MAC.

Ramas

не всегда удобно.
В кабельных модемах, кстати, можно прописать, какие IP-адреса разрешены. Неплохо бы длинку обратить внимание на реализацию в кабельных модемах.

Идея хорошая, хотя и не новая.
Есть только несколько "но":
1. Свичи все же отличаются от головных станций кабельных сетей, но это лирика.
2. Не во всех сетях ISP используется DHCP.

Решение будем искать, как только новости будут - сообщу.
Всем спасибо за обсуждение и идеи!

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