spruce Опубликовано 26 августа, 2009 · Жалоба Добрый день. Подскажите, если отфильтровывать жестко трафик с нулевыми мак адресами: 00-00-00-00-00-00, чем это может грозить? На свитче L3 постоянно сыпятся Failed ARP записи и таблица забивается напрочь. В результате чего маршрутизация падает у всех, кто идет через этот свитч. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrеw Опубликовано 26 августа, 2009 · Жалоба фильтруйте на доступе, в чем проблема? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 августа, 2009 · Жалоба Лучше снять дамп и разобраться с проблемой. Может статься, что никаких пакетов с нулевыми маками нет а есть неуспешные попытки разрешить ip адрес. Такое бывает если кто-то сканит и если блок адресов большой, эти записи забивают таблицу. Вообще-то они должны пропадать через несколько секунд. Ну или блок адресов всегда должен быть меньше чем физичеки вмещает arp таблица. Если же это кто-то вам с доступа вливает генератором gratuitous arp, то или фильтровать или ловить и отключать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jeejay Опубликовано 26 августа, 2009 · Жалоба дело не в нулевых маках. эдж-кор сначала создает у себя в кэше запись с нулевым МАКом. После ответа хоста на арп-запрос эта строка заполняется. BTW: клиенты получают IP по DHCP или статика? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 августа, 2009 (изменено) · Жалоба Ну да, собственно, и есть тот самый эджкор. в котором всего таблица 8К адресов, из которых успешных около 2-3К, а все остальные 5-6К - это failed адреса. После очищения кеша сразу начинает расти поле failed сотнями единиц буквально в несколько секунд. Я сначала тоже думал, что это кто-то забивает какой-то генерилкой или вирусником, но это происходит во всех вланах где живут абоненты. Сегменты сами по себе не большие. На каждый сегмент выделяется подсетка на 254 хоста(с маской \24) и в каждый влан входит столько домов, чтобы не перекрыть возможности сетки, ну это все расчитывали заранее, вланы от балды не кидали. ip выдаёт DHCP сервер Изменено 26 августа, 2009 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 августа, 2009 · Жалоба А сколько суммарный блок адресов терминируемый на этом устройстве ? Есть ли повторяющиеся записи с нулевым маком для одного и того же IP ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 августа, 2009 (изменено) · Жалоба суммарно получается около 150 вланов... в реале количество адресов можно делить в два или даже в 3раза. да трафик проходит вообще без проблем. На свитче работает OSPF с другими коммутаторами. Также вещается rip в вланы ну и просто различные каналы есть. Трафик на портах - ну начиная от 200 мбит и до 700 мбит доходит, не больше. На аплинке всего 1-1,5 гигабита. Загрузка ЦПУ около 20-30 процентов была. В последнее время вот вырасло до 40%. Если в таблицу каким то образом попадает адрес, то потом все начинает работать нормально. В первом посту немного неверно выразился - маршрутизация не падает у тех, адреса которых попали в таблицу. Повторных записей не замечал. Изменено 26 августа, 2009 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 26 августа, 2009 · Жалоба вообще это классическая болезнь(софтовая часть - ARP,IGMP, IGP и т.п.) любого дешёвого L3 свича, лечится долго, сложно и с матюгами(с вашей стороны) ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 27 августа, 2009 (изменено) · Жалоба Не понял, сколько же суммарно висит IP адесов. Если больше, чем заявлено в характеристиках коммутатора на таблицу arp, и время жизни записи достаточно долгое (может определяться как продолжительность посылки arp пакетов, а может и софтварно сидеть в таблице скажем минуту, пока какой нибудь периодический внутренний процесс не почистит) то смело надо разделять или умощать железо. proxy-arp тоже стоит проверить, если включен и не нужен, выключить. Не понял также фразу про делить на два. Если вы к тому, что все сразу не работают, то это не выход, раз блок висит, любой скан все равно пройдет весь блок. Изменено 27 августа, 2009 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 27 августа, 2009 · Жалоба Да, согласен про сканирование, делить особо нельзя. Тогда суммарно весит порядка 150 сетей (маска /24). Не понятно почему валят нулевые маки в таком количестве. Если просто сниффить сеть на arp запросы - то никаких нулевых маков не наблюдается. По поводу сканирования - ведь при сканировании какого то сегмента, как правило адреса обходятся последовательно в пределах одной подсети, тогда бы я получал на свитче последовательные IP адреса в логи; но тут разброс, причем координальный, надо либо иметь генерилку случайных адресов, либо еще что-то. Да и начинают появлятся они сразу после очистки кеша. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 27 августа, 2009 · Жалоба а какое рекомендуемое значение mac Aging Time, по умолчанию стоит 300сек ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jeejay Опубликовано 28 августа, 2009 · Жалоба mac Aging Time имеет отношение только в MAC-таблице и не влияет на арп. В данной ситуации косяк именно с арп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 28 августа, 2009 · Жалоба Так у вас 150*256 ~ 40k арп записей потенциально может появиться? А таблица на 8k. Однозначно менять железо. Скан идет (если реальные) из интернета всегда. Как он идет, рандомизированно или последовательно уже не суть. Если серые, то скан из вашей сетки сделает тоже самое. Про нулевые маки, уже говорили, это не пакеты ходят с нулевыми маками, это ваш коммутатор пытается разрешить IP адрес, посылая реквесты, а на время разрешения вносит в таблицу запись с нулями, когда приходит реплай, он вместо нулей подставляет мак. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 28 августа, 2009 · Жалоба mac Aging Time имеет отношение только в MAC-таблице и не влияет на арп. В данной ситуации косяк именно с арп.так а на что влияет ? как работает?внятного в инете что-то я не нашел Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jeejay Опубликовано 29 августа, 2009 · Жалоба влияет на время жизни МАК адресов:) работает так: ставите время - оно меняется Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 29 августа, 2009 · Жалоба то, что это время сохранения мас в таблице- это понятно, какое значение рекомендуется ? при высоком значении - мас будут занимать место в таблице, при низком таблица будет меньше, но если трафик будет высокий (вирусня или спуфинг) получим постоянное переполнение таблицы мас Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...