anti-arpscan на prion и snr

[aaaaa]

Добрый день, чем отличается настройка порта в trust от supertrust?

[Ivan Tarasenko]

Добрый день.

Предусмотрены 2 порога anti-arpscan: по порту источника и по ip-адресу источника.

В случае с trust port, запросы с указанного порта не будут попадать в порог порта, но будут отслеживаться запросы по ip-источника с этого порта. 

В случае с supertrust-port, запросы с указанного порта не будут попадать в порог в том числе и по IP-адресу источника.

Порт, через который происходит управление коммутатором, рекомендуется всегда указывать в качестве supertrust-port.

Подробную информацию вы можете найти также в Command Guide и Configuration Guide.

[aaaaa]

Спасибо.

[aaaaa]

Подскажите пожалуйста, для включения anti-arpsсan на а28 (используется релей) достаточно:

 

ip arp-inspection trust на магистральный порт,

 

глобально:

ip arpinspection dhcp-relay

ip arprate-limit recover enable

 

на пользовательские порты ip arp-rate-limit enable

 

верно?

[Victor Tkachenko]

Нужно также указать vlan, для которого будет отрабатывать arp-inspection.

Также можно указать порог частоты отправки arp и таймаут при его превышении.

ip arp-inspection vlan <vlan_id>
ip arp-inspection dhcp-relay
ip arp-rate-limit recover enable
ip arp-rate-limit recover time <time>

interface port 1
ip arp-rate-limit enable
ip arp-rate-limit rate <rate>

interface port 25
ip arp-inspection trust

 

[aaaaa]

Спасибо.

 

Edited January 12, 2018 by aaaaa

[aaaaa]

Еще вопрос про разницу в блокировке, при обнаружение арп запросов с наличием src-ip блокируются пакеты с данным ip на порту, порт не переходит в состояние down, правильно?

 

А при обнаружении превышения пакетов без src-ip порт переходит в состояние shutdown by anti-arpscan?

[Victor Tkachenko]

@aaaaa, если речь о коммутаторах SNR, то в anti-arpscan можно выделить 2 механизма защиты: port-based и IP-based.

Port-based отслеживает частоту получения arp на конкретном порту и при превышении порога блокирует порт.

IP-based отслеживает arp от конкретного IP-адреса и при превышении порога блокирует весь трафик от этого IP-адреса, но не трогает порты коммутатора.

[aaaaa]

Orion А26

 

 

У меня на нескольких коммутаторах а26 включен anti-arpscan, данные коммутаторы находятся в разных домах, в разных вланах управления. На магистральных настроен supertrustport, настройки коммутаторов идентичные. Все пользователи в одном влан и там и там.

 

На одном коммутаторе часто отключаются абонентские порты на другом все спокойно.

Что, кроме абонентского оборудования может влиять на срабатывания anti-arpscan? 

[Victor Tkachenko]

33 минуты назад, aaaaa сказал:

Orion А26

Тут механизм аналогичный.

 

33 минуты назад, aaaaa сказал:

На одном коммутаторе часто отключаются абонентские порты на другом все спокойно.

Отключаются именно процессом anti-arpscan?

 

34 минуты назад, aaaaa сказал:

Что, кроме абонентского оборудования может влиять на срабатывания anti-arpscan? 

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

[aaaaa]

Да, отключается именно процессом anti-arpscan, блокируются по ip, так как порт в up.

 

Думал дело в оборудовании клиента/прошивке, но подключили роутер той же модели с той же прошивкой, что работал нормально на другом коммутаторе, к коммутатору, который отключает абонентов, после чего данный роутер минут через 15 был отключен процессом anti-arpscan.

Edited January 12, 2018 by aaaaa

[Victor Tkachenko]

@aaaaa, оставьте обращение на support и приложите к нему вывод `sh tech` коммутатора, а также модель и версию ПО маршрутизатора и дамп трафика с порта подключения.

[aaaaa]

После включения anti-arpscan на коммутаторах изменился cpu utilization c 35-40% до 70-80% это нормальное поведение?

[Victor Tkachenko]

@aaaaa, это напрямую зависит от количества arp, проходящих через коммутатор. При использовании функционала anti-arpscan на коммутаторах агрегации или в больших кольцах, такое вполне возможно.

[aaaaa]

На одном из коммутаторов возникла такая картина:)

nbo_8_1.1(config)#sh cpu ut

Last  5 second CPU USAGE:  78%
Last 30 second CPU USAGE:  77%
Last  5 minute CPU USAGE:  68%
From  running  CPU USAGE: -2168%

 

На самом деле я так понимаю anti-arpscan помогает только от сканирования mac, но при желании можно сканировать с меньшим количеством пакетов.

Фактически от дальнейший реализации подмены мака спасет:

 

 ip dhcp snooping binding user-control
 ip dhcp snooping binding user-control max-user 5

 

от чужого dhcp-server

 ip dhcp snooping action blackhole

 

от штормов: 

 

 storm-control unicast 63
 rate-violation broadcast 200
 rate-violation multicast 200
 rate-violation control shutdown recovery 3600

 

от петель

 loopback-detection specified-vlan 101
 loopback-detection control shutdown

 

от лишних подключений

 switchport port-security
 switchport port-security violation protect

 

как я предполагаю дополнительно включать anti-arpscan это ресурсы на ветер, плюс у некоторых пользователей все равно валится по 15-20 arp пакетов?
 

Edited January 24, 2018 by aaaaa

[Victor Tkachenko]

3 часа назад, aaaaa сказал:

На одном из коммутаторов возникла такая картина:)

nbo_8_1.1(config)#sh cpu ut

Last  5 second CPU USAGE:  78%
Last 30 second CPU USAGE:  77%
Last  5 minute CPU USAGE:  68%
From  running  CPU USAGE: -2168%

Вероятно установлена старая версия ПО, этот баг уже известен и устранен.

 

3 часа назад, aaaaa сказал:

как я предполагаю дополнительно включать anti-arpscan это ресурсы на ветер, плюс у некоторых пользователей все равно валится по 15-20 arp пакетов?

Верно, от сканирования это наверняка не спасет, а от штормов защита уже имеется.