faq обучение настройка
Текущее время: Вс янв 20, 2019 23:16

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
СообщениеДобавлено: Пт окт 12, 2018 15:38 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
Device Type : DGS-3627 Gigabit Ethernet Switch
MAC Address : 5C-D9-98-37-1F-00
Boot PROM Version : Build 1.10-B09
Firmware Version : Build 3.00.B47
Hardware Version : A1

Комутатор работает как L3, если из одной IP подсети направить постоянный поток пакетов на
не существующий IP в другой сети,
то загрузка CPU возрастает и свитч начинает умирать.
По видимому это связано с тем, что свич пытается по каждому ip пакету приходящему на несуществующий хост произвести
arp request.

Как от этого защититься?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Пн окт 15, 2018 09:37 
Не в сети

Зарегистрирован: Пн май 13, 2013 10:39
Сообщений: 39
Подобная проблема. Пока не удалишь из arptable, рассылает пакеты по всем портам, т.к. в fdb мака уже нет, а в arp-таблице связка есть. Если идет большой UDP поток, неплохо так штормит. Уменьшение времени жизни arp-записи даже до рекомендуемых 20 минут приводит к тому, что некоторое оборудование перестает нормально работать, например, ip телефоны cisco. Тоже прошу советов, можно ли, что-нибудь сделать?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Пн окт 22, 2018 13:16 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
Жива ли тех. поддержка DLINK'а?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Пн окт 22, 2018 14:47 
Не в сети

Зарегистрирован: Пн июл 07, 2008 14:37
Сообщений: 117
Время жизни мака должно быть больше/равно времени жизни arp.
У меня для fdb 300сек(5 минут) и для arp также.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт окт 23, 2018 15:01 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
[-Alt-] писал(а):
Время жизни мака должно быть больше/равно времени жизни arp.
У меня для fdb 300сек(5 минут) и для arp также.


Вы решили описанную выше проблему c умиранием control plane?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Пн окт 29, 2018 15:32 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
Проблема не решена и присутствует
Просьба сотрудникам dlink порекомендовать решение

Наблюдаем следующую картину:
На IP пользователя идёт большой поток маленькими UDP пакетами.
Если host с данным IP присутствует(то есть на DGS имеется arpentry IP mac) ВСЁ ОТЛИЧНО.
Как только клиент отключает хост с данным IP и arpentry исчезает, но поток на DGS продолжает идти dgs умирает.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт окт 30, 2018 10:19 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Вт янв 18, 2011 13:29
Сообщений: 8906
От unknown unicast необходимо защищаться на доступе, для этого существует механизм traffic control. Этот же механизм есть и на DGS-3627.
Также настройте таймеры arp и fdb как вам рекомендовали выше.
Описанное поведение коммутатора не является ошибкой - вы, по сути, засыпаете его трафиком, для которого он должен сгенерировать arp request, что целиком ложится на cpu и вполне обоснованно вызывает его загрузку.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт окт 30, 2018 12:46 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
При чем здесь unknown unicast? Тут ни какого L2 на не известный mac НЕТУ,
так как arp записи в таблице коммутатора НЕТУ его он то и пытается выясниить arp запрсоами.

Какие таймеры arp и fdb уменяьшать если нет ARP и нет MAC.

Советую погуглить по словам arp rate limit
и посмотреть для чего в подобных коммутаторов делают такие команды.
Возможно что даже такая команда не нужна просто достаточно оптимизировать алгоритм посылки ARP request,
не пытаться его послать на каждый приходящий IP пакет.

Ситуация ещё хуже например в корпоративной сети
работает стримовый сервис который шлёт UDP поток на отключенный хост.
Свитч ляжет!!!

Проблема не решена и присутствует
Просьба сотрудникам dlink порекомендовать решение


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Ср окт 31, 2018 12:31 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Вт янв 18, 2011 13:29
Сообщений: 8906
Приношу извинения, вы правы относительно uknown unicast, здесь ситуация другая.
Однако ваше предположение, что коммутатор генерирует arp на каждый приходящий пакет, неверно. ARP от коммутатора идет примерно раз в секунду, однако т.к. записи в arp таблице нет, весь входящий поток уходит на cpu, что и вызывает загрузку.
Я пообщаюсь с разработчиками, какие возможны варианты в данном случае.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Ср окт 31, 2018 12:47 
Не в сети

Зарегистрирован: Чт окт 14, 2004 10:36
Сообщений: 154
Откуда: Курск
Спасибо


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Пт ноя 09, 2018 05:56 
Не в сети

Зарегистрирован: Вт фев 12, 2008 09:13
Сообщений: 101
Artem Kolpakov писал(а):
Приношу извинения, вы правы относительно uknown unicast, здесь ситуация другая.
Однако ваше предположение, что коммутатор генерирует arp на каждый приходящий пакет, неверно. ARP от коммутатора идет примерно раз в секунду, однако т.к. записи в arp таблице нет, весь входящий поток уходит на cpu, что и вызывает загрузку.
Я пообщаюсь с разработчиками, какие возможны варианты в данном случае.

А можно с разработчиками также пообщаться на тему коммутатора 3620. Проблема такая же. Если отправить трафик на ip адрес, шлюз которого данный комутатор, arp записи в таблице нет. Коммутатор начинает пропускать arp запросы и ответы, видимо когда он запрашивает необходимый arp ip для обучения, он пропускает остальное, результат: любые интерфесы, в любых влан перестают обучаться, сеть превращаться в труху. Бороться с таким автоматом пока не придумано как. Весь трафик оценивать на существование arp записи не реально.
Причем шторм может быть не сильно большим, т.е. на графиках его даже не видно.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Чт ноя 29, 2018 09:31 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Вт янв 18, 2011 13:29
Сообщений: 8906
По результатам длительного общения с разработчиками могу сказать следующее.
1. Использование safeguard engine помогает снизить загрузку cpu если она уходит в полку от unknown unicat (когда, допустим, при нормальной работе у вас загрузка 50-60%, а при потоке подскакивает до 100%) и помогает сохранить управление коммутатором.
2. Полностью отсечь этот трафик можно при помощи стандартных acl - в этом случае загрузка cpu не наблюдается.
3. Удаленно в cli коммутатора выяснить параметры мусорного потока (его source/dest ip address) невозможно - надо смотреть дамп, снятый или через зеркалирование или через RSPAN.
Других вариантов нет.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Ср дек 12, 2018 06:48 
Не в сети

Зарегистрирован: Вт фев 12, 2008 09:13
Сообщений: 101
1. Только что проверил на боевом коммутаторе. Сейчас утро, загрузка цпу 20%, при штроме в 3 Мбита на не обученный arp загрузка растет до 30%
коммутатор все пропускает, отлично все пингуется, сам управляется замечательно. Но спустя 5 мин, по истечении обучения arp записям (скорее всего или fdb не знаю), начинают валится рабочии станции, узлы, т.е. все что маршрутит коммутатор.
2. невозможно. данный коммутатор уровня 3, на него сходятся адреса и внешних айпи, а не только локальные, но это не важно. Станция из сети пропадает, это был веб сервер или торрент пир или не важно что, к нему цепляются клиенты, естественно продолжают цепляться и укладывают сеть.
3. поймать мы знаем как, как бороться не знаем. Мониторить все коммутаторы и все айпи на такое, не один dpi не справится, сам сдохнет скорее.
Из всего изложенного, зная провайдера у которого стоит данный коммутатор, я полностью могу вывести из строя сети за которые он отвечает, при этом не арп штормом (от него увы все дохнут), а обычным нормальным трафиком. т.е. по факту это проблема прошивки и логики. коммутатор ищя мак в сети, начинает забивать на всех остальных.
Моя просьба пообщаться с разработчиками на тему как исправить эту проблему им аппаратно.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Чт дек 13, 2018 15:46 
Не в сети

Зарегистрирован: Пт дек 19, 2008 14:23
Сообщений: 365
У меня CPU в 100% было при попытке вытянуть таблицу FDB по SNMP с количеством записей около 1000.


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB