Как ограничить пропуск ARP-ответов на порту коммутатора от определенных айпи адресов?

Есть проблема. Десятки рабочих станций в сети отправляют ложные арп ответы. Выглядит это так: компьютер-1 отправляет арп запрос, запрашивая мак адрес шлюза, компьтер-2 отправляет лже ответ, что мак адрес шлюза =x (х-мак адрес компьюетра-2), хотя реально мак адрес шлюза = у(у- реальный мак адрес шлюза). Соответственно, после обновления арп таблицы компьютера-1, все пакеты предназначенные шлюзу уходят с dst айпи = айпи реального шлюза, но dst мак = мак компьютера-2.

Пользуем DES-3526 (Build 4.01-B30).

Очень надеемся на ваш быстрый ответ.

P.S. в факах описано только "Как ограничить пропуск ARP-запросов на порту коммутатора определёнными адресами назначения?"[/i][/b]

В догонку. Попробую упростить описание потсавленной задачи:
Необходимо заблокировать все арп ответы, в которых есть информация, что у айпи адреса х какой-то физический адрес. И разрешить такие арп ответы только с одного порта.

Я Вам прошивку и рекомендации отправил.

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

Сейчас, загрузка цпу у случайных шести des-3526 не выходит за пределы 30%

Можно попробовать ACL типа Packet Conten Filtering. Вот здесь есть примеры http://www.dlink.ru/technical/faq_hub_switch_90.php

эх. Не выходит Не могли бы вы показать пример, как
заблокирвать арп-ответ айпи адресса 10.0.0.1 с помощью контент фильтеринга? Реальный кусок конфига. Буду оочень признателен.

Я думаю Вы просто пытаетесь блокировать ответ на порту получателя, а это надо делать на порту источника.

Нет. Ес-но я делаю фильтрацию на порту источника проблем. Я знаю где у меня находится реальный мак, и блочю на всех остальных портах.
Возможно у меня другое представление о контенте пакетов. И я не правильно использую офсеты.

Я предполагал, что пакет должен выглядеть так:
17:40:22.545481 01:01:01:01:01:01> 02:02:02:02:02:02, ethertype ARP (0x0806), length 60: arp reply айпи - 10.0.0.1 is-at 01:01:01:01:01:01

0x0000: 00010800 06040002 00016cf7 30bc0A0 ..........l.0...
0x0010: 000100e0 4c7c1628 c3039421 00000000 ....L|.(...!....
0x0020: 00000000 00000000 00000000 0000 ..............

По всему выделенному жирным я делаю фильтрацию, и ничего не выходит

А если использовать функцию IP-MAC-Port Binding в режиме ACL?

Очень не хотелось бы гадать - поможет или не поможет. Привязка была, но к сожалению тяжело сказать помогла ли она. Есть подозрение, что пакеты, в которых указан ложный мак основного шлюза, на самом деле отправляются от других девайсов. Скорее всего, паразитный комп вообще не светится, он просто отправляет арп-реплаи, указывая в мак адресе отправителя не свой физ адрес, а мак одно из зараженных им компьютеров. При чем, если прописать на любом компьютере основным шлюзом айпи зараженной машины, то пакеты роутятся и бегают в инет. Точно можно сказать только то, что сейчас в сети мешают ложные арп-реплаи, которые и хочется заблокировать на основании содержимого пакетов. Блочить чисто по айпи и типу пакета. Если можете, подскажите, пожалуйста, как выглядят такие пакеты. Я представляю себе их так:


0x0000: 00010800 06040002 00016cf7 30bc0A0 ..........l.0...
0x0010: 000100e0 4c7c1628 c3039421 00000000 ....L|.(...!....
0x0020: 00000000 00000000 00000000 0000 ..............


Первое жирное выделение – говорит о том, что это арп-реплай,
Второе содержит айпи адрес. Может я ошибаюсь?

Если ARP-ответ идёт с невалидного адреса, причём неважно что неверно MAC или IP, то MAC-будет заблокирован.

Лучше вы приведите свой неработающий ACL, а мы вас поправим.

И, кстати, вот ещё один чрезвычайно близкий к вашей проблеме faq