Подскажите, существует ли способ запретить обращения с определенного MAC на определенном порту коммутатора DES-3526.

Причем так что-бы мак-адрес не попадал в FDB таблицу коммутатора.

У абонентов порты коммутатора порты с 1-го по 24й.
25й и 26й - магистральные. За магистральным портом находится "шлюз по умолчанию" для клиентов.
Периодически возникает следующая проблема: подстановка устройству подключенному к абонентскому порту мак-адреса шлюза по умолчанию, после чего клиентам подключенным на данный коммутатор и самому коммутатору перестает быть доступным шлюз по умолчанию.

Пытались победить следующим образом:
config arp_spoofing_prevention add gateway_ip XXX.XXX.XXX.XXX gateway_mac XX-XX-XX-XX-XX-XX ports 1-24

Результат нулевой, ACL создаются, но ничего не меняется, запись в FDB таблице как создавалась так и продолжает создаваться

Версия прошивки 5.01.B55

Существует ли способ который бы предотвращал появление записи в FDB таблица коммутатора des-3526, соответствия определенного мак-адреса, определенном порту?
А именно: необходимо что бы в FDB таблице могла появится запись о том что устройство с мак адресом XX-XX-XX-XX-XX-XX находится за 25м портом, либо что устройство с мак адресом XX-XX-XX-XX-XX-XX находится за 26м портом; и не могла появиться аналогичная запись, указывающая что устройство с таким мак адресом подключено к какому любому из портов с 1го по 24й?

в какой ARP-таблице вы смотрите? если на самом 3526, то так и должно быть. Ибо всё что идёт на сам свитч можно зафильровать только CPU ACLками. До вашего шлюза пакеты не будут доходить, а будут фильтроваться.
Более того, если клиенты у вас со свитчем в одной подсети - выносите свитч в отдельный VLAN, чтобы клиенты с ним вообще не пересекались!

_________________
LiveComm

apr-таблица на самом коммутаторе.
Шлюз за коммутатором с такими проблемами успешно справляется собственными силами. Проблема в данном случае имеет место быть на самом коммутаторе 3526.


Об этом поподробнее где можно узнать?


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

Тогда я не понимаю какое отношение L2 свитч и его ARP-таблица влияют на работоспособность сети. Сразу скажу - никак не связаны между собой. Максимум что произойдёт, если в его ARP-таблице левый адрес будет - нельзя с этого адреса будет законнектиться на свитч. Так что если у вас не работает вся сеть - то ищите проблему в другом. Например в вашем шлюзе

_________________
LiveComm

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

В следствии этого при обращении на любой адрес клиента подключенного на данный коммутатор пакеты уходят не на магистральный порт, а на клиентский, на котором был подставлен мак-адрес шлюза по умолчанию.

Не знаю как еще более подробнее объяснить.

И еще раз: со шлюзом все в порядке, на его работоспособности все вышеописанное никак не сказывается. (пакеты из подсетей отличных от той в которой находится коммутатор с вышеописанной проблемой продолжают маршрутизироваться).

Еще раз, существует ли способ который бы предотвращал появление записи в FDB таблица коммутатора des-3526, соответвия определенного мак-адреса, определенном порту?
А именно: необходимо что бы в FDB таблице могла появится запись о том что устройство с мак адресом XX-XX-XX-XX-XX-XX находится за 25м портом, либо что устройство с мак адресом XX-XX-XX-XX-XX-XX находится за 26м портом; и не могла появиться аналогичная запись, указывающая что устройство с таким мак адресом подключено к какому любому из портов с 1го по 24й?

FDB и ARP - разные вещи!
Вам вот сюда в данном случае: http://www.dlink.ru/ru/faq/62/252.html

_________________
LiveComm

приведенный по ссылке пример работает только в очень странных случаях:
1. нам заранее известен валидный мак адрес клиента
2. Записи в FDB таблицу не происходит только в случае когда вместе с мак-адресом на клиентском порту появляется невалидный IP.

Смысл этих манипуляций в таком примере не понятем, тот-же эффект достигается включением опции порт-секьюрити в режиме "перманент".

А функцию ARP Spoofing Prevention не пробовали? Описание функции есть в мануале R5.1 на ftp. Какая у вас версия прошивки?

в первом посте описано что пробовали.
запись в FDB на абонентском порту все-равно создается.

А она не может не создаваться. Это в логике работы свитча. Единственный вариант это прописать валидные MAC-адреса в статическую таблицу MAC-адресов и выключить Learning на порту.

Валидные мак-адреса - не предсказуемы. Это клиенты, которые на момент создания конфигурации еще не подключены. Тоесть статическая arp таблица тоже неприменима получается.

Тут идея безумная возникла: магистральные порты - транковые ( тегированные) клиентские - не тегированные.
Реально ли содрать правила в CPU фильтре по следующему принципу:
1. разрешаем все тегируемые пакеты.
2. запрещаем все пакеты содержащие наш мак-адрес в качестве мак-адреса источника.

Верна ли моя догадка что данная конструкция может отфильтровать все пакеты с абонентских портов (1-24) в случае если они содержат указанный мак адрес в качестве мак-адреса источника и не являются тегированными. И в этом случае запись в FDB не создасться?
Реализуема ли такая конструкция чисто теоретически?

Нет не применима. И причём здесь CPU Interface filtering тоже не очень понятно. Эти правила фильтруют трафик предназначенный интерфейсу CPU и тоже только на входе. Я вообще не понимаю зачем Вам отсутствие записи в FDB вообще?

Вполне возможно что я не совсем понимаю логики коммутатора.
Требуется решить следующую проблему:

Вот как раз от этого и должна помогать функция ARP Spoofing Prevention. В вашем случае не помогает? Также вот этот FAQ читали? http://www.dlink.ru/ru/faq/62/252.html

в том-то и дело что "должна" но почему-то не помогает.
в мануале описаны теже-самые правила что создаются ARP Spoofing Prevention? или я не прав?
эффект нулефой от обоих методов.