Подскажите пожалуйста.

Вот если на L3 коммутаторе Cisco подвесить сетку с реальными ip

Например:
int vlan 10
  ip addr 1.1.1.254 255.255.255.0
end

и подключиться ноутом в этот vlan

то сниффером сразу видно, что этот диапазон начинают сканировать боты и летит очень много ARP запросов c Cisco:

who-has 1.1.1.34 tell 1.1.1.254
who-has 1.1.1.12 tell 1.1.1.254
who-has 1.1.1.56 tell 1.1.1.254

Как сделать чтобы ARP в этом vlan'е работал только для тех ip которые реально есть?

Спасибо.

P.S. Просто это актуально для WiFi сетки - засоряется эфир.

• Что делать с ARP запросами если их много?,Andrey, 21:13 , 11-Авг-16
  • Что делать с ARP запросами если их много?,ak91, 15:04 , 12-Авг-16
    • Что делать с ARP запросами если их много?,Аноним, 14:04 , 13-Авг-16
• Что делать с ARP запросами если их много?,gfh1gfh, 14:09 , 12-Авг-16
  • Что делать с ARP запросами если их много?,ak91, 14:59 , 12-Авг-16
• Что делать с ARP запросами если их много?,Del, 21:01 , 14-Авг-16
• Что делать с ARP запросами если их много?,rusadmin, 12:02 , 16-Авг-16
• Что делать с ARP запросами если их много?,IZh, 13:46 , 18-Авг-16
  • Что делать с ARP запросами если их много?,rusadmin, 06:21 , 19-Авг-16
    • Что делать с ARP запросами если их много?,Del, 08:17 , 19-Авг-16
      • Что делать с ARP запросами если их много?,rusadmin, 14:50 , 19-Авг-16
        • Что делать с ARP запросами если их много?,IZh, 18:22 , 19-Авг-16

>[оверквотинг удален]
> и подключиться ноутом в этот vlan
> то сниффером сразу видно, что этот диапазон начинают сканировать боты и летит
> очень много ARP запросов c Cisco:
> who-has 1.1.1.34 tell 1.1.1.254
> who-has 1.1.1.12 tell 1.1.1.254
> who-has 1.1.1.56 tell 1.1.1.254
> Как сделать чтобы ARP в этом vlan'е работал только для тех ip
> которые реально есть?
> Спасибо.
> P.S. Просто это актуально для WiFi сетки - засоряется эфир.

Cisco пытается найти MAC-IP в этом VLAN потому, что прилетел пакет с source-IP который Cisco пытается найти у себя в сегменте. Если в VLAN этого IP нет - возможно он прилетел не через этот VLAN, а с другого сегмента (никто не мешает подставить в качестве src-IP что угодно). Как вариант лечения - заблокировать прием на других интерфейсах пакетов с source из подсети, которая привязана к текущему VLAN.
ARP timeout можно подрегулировать чтобы уменьшить/увеличить ARP запросы с Cisco. Только не регулируйте слишком рьяно - могут начаться проблемы. Дефолтового значения хватает в 99.99% случаев.

Не совсем понял что вы написали.

Этот arp flood, он легитимный - если я сам начну извне сканировать диапазон 1.1.1.0/24 то я тоже увижу эти who-has в большом количестве.

Мне нужно понять - можно ли с помощью каких-то спец.настроек или ACL, сделать так, что внутри vlan'а ARP работал только с теми ip которые реально есть, а для тех, кого нет - то дропался.

> сделать так, что внутри vlan'а ARP работал только с теми ip
> которые реально есть, а для тех, кого нет - то дропался.

Вообще-то ARP как раз и импользуется для того, чтоб понять, есть ли получатель и каков его физический адрес. Откуда циске знать, жив хост или не жив, если не посредством арп-запроса?

Если так сильно не нравится - вырубайте арп и прописывайте все адреса статически.
P.S. даже 10-15 пакетов в секунду не смогут скол-нибудь значимо "засорять" эфир, это просто смешные цифры.

Почитать про Dynamic ARP inspection на коммутаторах Cisco.

> Почитать про Dynamic ARP inspection на коммутаторах Cisco.

Я читал.
Вы можете что-то конкретное посоветовать по DAI, в рамках описанной задачи?

>[оверквотинг удален]
> и подключиться ноутом в этот vlan
> то сниффером сразу видно, что этот диапазон начинают сканировать боты и летит
> очень много ARP запросов c Cisco:
> who-has 1.1.1.34 tell 1.1.1.254
> who-has 1.1.1.12 tell 1.1.1.254
> who-has 1.1.1.56 tell 1.1.1.254
> Как сделать чтобы ARP в этом vlan'е работал только для тех ip
> которые реально есть?
> Спасибо.
> P.S. Просто это актуально для WiFi сетки - засоряется эфир.

Может просто нагенерить статических записей?

Кто то из хостов, подключенной к данному коммутатору, запрашивает соединения с данными адресами. Хост можете определить ACL с логированием, повешанным  на int vlan 10.
Например
ip access-l ex LOG
permit ip any any log
int vlan 10
ip access-gr LOG out

... на консоли включайте term mon (это если не с кабеля сидите) и ждите вражину

ip unnumbered например

int null 0
no ip send-unrea
ip route 1.1.1.0 255.255.255.0 null 0
int loopback 10
ip add 1.1.1.1 255.255.255.0
int vl 10
ip unnumbered loopback 10
ip route 1.1.1.2 255.255.255.255 vlan 10

> ip unnumbered например
> int null 0
> no ip send-unrea
> ip route 1.1.1.0 255.255.255.0 null 0
> int loopback 10
> ip add 1.1.1.1 255.255.255.0
> int vl 10
> ip unnumbered loopback 10
> ip route 1.1.1.2 255.255.255.255 vlan 10

Это костыль
Мое мнение - нужно выяснять источник этих запросов, а не грузить процессор сливом в нулл

>[оверквотинг удален]
>> no ip send-unrea
>> ip route 1.1.1.0 255.255.255.0 null 0
>> int loopback 10
>> ip add 1.1.1.1 255.255.255.0
>> int vl 10
>> ip unnumbered loopback 10
>> ip route 1.1.1.2 255.255.255.255 vlan 10
> Это костыль
> Мое мнение - нужно выяснять источник этих запросов, а не грузить процессор
> сливом в нулл

Адреса белые на инт-се

>[оверквотинг удален]
>>> ip route 1.1.1.0 255.255.255.0 null 0
>>> int loopback 10
>>> ip add 1.1.1.1 255.255.255.0
>>> int vl 10
>>> ip unnumbered loopback 10
>>> ip route 1.1.1.2 255.255.255.255 vlan 10
>> Это костыль
>> Мое мнение - нужно выяснять источник этих запросов, а не грузить процессор
>> сливом в нулл
> Адреса белые на инт-се

...и?
Вы провайдер и вам летят с чужих автономок эти запросы?

unknown unicast flood - большая проблема для датацентров например.
Где приходится держать несколько сеток в одном сегменте.