alibek Опубликовано 22 ноября, 2013 · Жалоба Есть несколько коммутаторов, соединенных последовательно (цепочкой), это коммутаторы SNR-S2960, QTECH 2800 (аналог S2960) и QTECH 2900. Некоторое время на них наблюдаются проблемы с качеством услуг. На одном из коммутаторов (первый в цепочке) я включил anti-arpscan, после чего в консоли наблюдал такие сообщения: %Nov 22 11:09:37 2013 IP 192.168.10.168 connected with Port Ethernet1/25 has been recovered. %Nov 22 11:09:43 2013 IP 192.168.10.111 connected with Port Ethernet1/25 has been prohibited. %Nov 22 11:09:43 2013 IP 192.168.24.83 connected with Port Ethernet1/25 has been prohibited. %Nov 22 11:09:43 2013 IP 192.168.12.87 connected with Port Ethernet1/25 has been prohibited. 1/25 — это аплинк. 192.168 — это не моя сетка (у меня 10.0.). Скорее всего это внутренняя сетка за абонентским коммутатором, которая каким-то образом (случайно или нарочно) попадает "наверх" (возможно по причине того, что какой-то из коммутаторов неправильно настроен). На коммутаторах SNR-S2960 в некоторых случаях вылезал неустранимый глюк с dhcp-snooping, когда коммутатор начинал блокировать все dhcp-пакеты; решить ее не удалось, поэтому на некоторых коммутаторах пришлось dhcp-snooping отключить, возможно флуд связан с этим. Но причина — это вопрос второй. Сейчас же мне нужно найти, откуда этот флуд идет. Указанные в логе IP-адреса мне ничего не дают. И поскольку это не мой IP-адрес, ни в какой ARP-таблице он фигурировать не будет. Но раз уж anti-arpscan фиксирует какой-то флуд и показывает IP-адрес источника, значит он этот адрес взял из ethernet-фрейма (или из IP-датаграммы, инкапсулированной в ethernet-фрейм). И я хочу узнать MAC-адрес, указанный в заголовке ethernet-фрейма, поскольку с большой степенью вероятности в нем будет указан MAC-адрес источника флуда. Как это сделать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BasilKlyev Опубликовано 22 ноября, 2013 · Жалоба Есть такая хрень у них. Производил смену управляющего влана на одном большом районе и частично обновлял конфиги на коммутаторах. На 2-х домах стоят по паре SNR-S2960-48G подключенных последовательно по оптике. Ну вот и прописал я на них anti-arpscan. Это была пятница ... В итоге - потерял доступ к ним полностью до перезагрузки. При чем глюки были даже при отключеных абонентах - т.е. подключены были только по оптике между собой. В логах не смотрел что было - просто отключил anti-arpscan и все заработало(субота, утро, пить хочется - какие нафик логи). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 22 ноября, 2013 · Жалоба Я сейчас тоже отключил, чтобы хоть как-то работало. Но источник найти все же нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VVSina Опубликовано 22 ноября, 2013 · Жалоба arping? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mallorn Опубликовано 27 ноября, 2013 (изменено) · Жалоба Если вы таким образом включаете S29XX - всегда делайте #no anti-arpscan ena При включенной защите от сканирования арп свитч гасит порт, если с него прилетает больше чем X арп пакетов в секунду, X настраивается. И включает порт обратно через Y секунд, Y тоже настраивается. Это полезный функционал, когда у вас "гирлянд" нет на сети, а каждый свитч\дом сидит на отдельной линии. Тогда anti-arpscan позволяет фильтровать излишне деятельных абонентов и потенциальных зловредов, просто не пропуская лишние арп-запросы. Ну а если источник хочется узнать, с выключенным anti-arpscan посидите с tcpdump\wireshark на нужном порту или vlan и сразу найдете. Изменено 27 ноября, 2013 пользователем Mallorn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VVSina Опубликовано 27 ноября, 2013 · Жалоба у меня anti-arpscan на s2950 тупо гасил абонентов с семёркой. XP и Linux при этом работали нормально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BasilKlyev Опубликовано 27 ноября, 2013 · Жалоба когда у вас "гирлянд" нет на сети, Дак вот в том то и дело что чисто экономически не выгодно подводить на один дом 2 волокна с узлового коммутатора на те 2 дома где стоят "гирлянды"(Общага, конкретная ОБЩАГА). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 27 ноября, 2013 · Жалоба Это полезный функционал, когда у вас "гирлянд" нет на сети, а каждый свитч\дом сидит на отдельной линии. Это полезный функционал даже если гирлянды есть. Транковые порты можно настроить как доверенные, а абонентские гасить. Но у меня на каком-то коммутаторе (или коммутаторах) это не срабатывает и сканы уходят на ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...