-1
Совершенно не понятно зачем arping в управляющем vlan? А если нужен в клиентском, то сложность в том, что у L2-коммутатора L3-интерфейс один и находится, как правило, в другом vlan и в таком случае чем формировать этот самый arping?

Вы вообще arping'ом когда-нибудь пользовались? В чём сложность сформировать на определённом порту arp who-has от указываемого вручную ip и затем поймать ответ обратно? При чём здесь L3-интерфейс?

При том что ARP протокол это протокол сетевого уровня.

А причем тут вообще интерфейс коммутатора к arping?
Никто не говорит, что пинговать надо от имени L3 свитча.

это значит, что коммутатор должен на CPU обрабатывать все ARP-пакеты в пользовательском (не управляющем!) вилане в поисках нужного?.. звучит страшно =)

а что мешает юзать ARP Ping на предназначенном для этого оборудовании - на третьем уровне?..

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Не вижу ничего в этом страшного - CPU в 35xx И 32xx давно умеет даже packet content filter делать.
На третьем уровне мешает две вещи - всё то же отсутствие arping'а на оборудовании и невозможность во многих случаях дотягивания влана до компьютера, на котором этот arping есть.

умеет - это одно. а возможность задавить флудом коммутатор в неуправляющем вилане - это другое

а зачем вилан дотягивать, если L3 и так имеет доступ к абоненту?

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Да ну бросьте, при чём здесь флуд?

Блин, L3 на длинках (3627G, если интересно). Вы умеете с них arping'и делать?

до сих пор обсуждался именно access, насколько я вижу, перечитав тему. да, на 3627 фишка очень не помешала бы

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Во всех железяках имени Dlink ACL (за исключением cpu ACL ) реализованны аппаратно и процессором не обрабатываются.

+100

_________________
с уважением, БП

В последних железяках вроде появились счётчики отработки правил ACL. Тогда задача делится на четыре этапа: генерация пакета от процессора, генерация временного правила ACL, ловящего обратный ответ, показ счётчика отработки, удаление временного правила ACL.

Дык нам CPU ACL и понадобится.

Что за бред arping с коммутаторов L2? А биллингом не, никак?

Если конечно хотелка по поводу arping, но на коммутаторах L3, аля 3828 и 36-й серии, на L2 смысла делать нет, т.к. управляющий интерфейс один и он в управляющем влане, и пигновать свичом клиента - бред, если пинговать - то через L3, агрегирующего влан клиента, то вроде всё в порядке вещей: пингуется - значит без фаеров сидит

Если конечно не сложно, задайте пожалуйста запрос в ШК по поводу arping через snmp, допустим сделать 2-4 пакета и возвращать walk с результатами, актуально для 36 серии, но если можно, то и на 38-й хотелось бы тоже.

В теме много чего написали, но конкретики мало.

Bigarov Ruslan
Раз Вы отвечали в теме, то и спрос с Вас

В теме речь шла про улучшения:
1. Добавить в лог DHCP Screening мак адрес.
2. Планируется ли автосохранение конфигурации по расписанию?
3. Поддержка Option 82 уникастовых DHCP пакетов.
3.1. для DHCP Relay
3.2. для DHCP Local Relay
4. arping
4.1. на L2 свитчах
4.2. на L3 свитчах
Вроде бы ничего не забыл.
Можно по каждому пункту ответ. "Да", "Нет", "Нет информаций" и "Мы запросили данный функционал" будет достаточно.

P.S. Также в теме Вы писали, что обсуждаете возможность реализации DHCP Relay per Port, в соседней теме написано, что запросили функционал DHCP Relay per Vlan. Если ли какая-то информация, что будет в итоге? Или будут оба? Сроки есть?

--------------------
Господа, поскольку на форуме нет единой темы для запроса функционала, улучшений (как это сделано с прошивками, howto), давайте для каждого улучшения создавать отдельную тему, так и обсуждать проще, и следить за судьбой предмета обсуждения. А то начали за "мак в логе" говорить, а закончили "арпингом".

-> 2. Планируется ли автосохранение конфигурации по расписанию?
Если и делать, то отключаемое, при сохранении конфигурации прерывается обслуживание на время сохранения, что не всегда приемлемо.

-> 4. arping на L2 свитчах
Вещь достаточно непонятная, в любом случае сегмент сети дотяну до L3 свитча, и процессор там помощнее будет . Я думаю данный функционал востребован только там.

От себя добавлю необходимость в динамическом Arp Spoofing Prevention
Было-бы неплохо иметь возможность подвязывать только IP+port шлюза, а что-бы коммутатор подвязывал нужный мак к этой связке сам.
Смысл сего действия:
При создании/удалении/изменении IPIF интерфесов на L3 коммутаторах бывают сьезжают их MAC адреса. Приходится перестраивать Arp Spoofing Prevention по довольно большой группе коммутаторов. В случае с SuperVlan/SubVlan вообще беда .

_________________
В интернете три беды: дураки, вирусы и спам.