faq обучение настройка
Текущее время: Пт мар 29, 2024 00:10

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




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
СообщениеДобавлено: Пт окт 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
Сообщений: 45
Подобная проблема. Пока не удалишь из 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
Сообщений: 8999
От 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
Сообщений: 8999
Приношу извинения, вы правы относительно uknown unicast, здесь ситуация другая.
Однако ваше предположение, что коммутатор генерирует arp на каждый приходящий пакет, неверно. ARP от коммутатора идет примерно раз в секунду, однако т.к. записи в arp таблице нет, весь входящий поток уходит на cpu, что и вызывает загрузку.
Я пообщаюсь с разработчиками, какие возможны варианты в данном случае.


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

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


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

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


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

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


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт фев 26, 2019 18:35 
Не в сети

Зарегистрирован: Чт сен 09, 2010 14:48
Сообщений: 11
NShut писал(а):
3. поймать мы знаем как, как бороться не знаем. Мониторить все коммутаторы и все айпи на такое, не один dpi не справится, сам сдохнет скорее.


буду некропостером, вдруг кому поможет :), если после загрузки коммутатора, создать правило в таблице маршрутизации типо:

если за коммутаором подсеть 10.10.10.0/24 - то cre ipro 10.10.10.0/24 null - все, кто есть в arpe будут работать, новые записи тоже коректно добавляются, проблем с пропаданием записей тоже нет - зато кого нет не дойдут до cpu. Нагрузка с цпу уйдет, вариант не плохой, но если это правило оставить и ребутнуть коммутатор - то трафик с этой подсети перестанет вообще маршрутизироваться, т.е. надо удалять его и заново забивать. (не знаю какую аналогию привести - наверное ближе всего правила в iptables, работает до первого включения, после перезагрузки оно становиться "выше").

Второй вариант, если используется супервлан, добавить подсеть за subvlanom: config sub_vlan vlanid 101 add ip_range .....

у второго способа есть ограничения, вроде бы до 5ти диапазонов за каждым sub, нагрузка тоже уходит, но потестить долго не получилось т.к. используем много дробных сегментов и не влазим в ограничение.


Dmitry Luhtionov писал(а):
У меня CPU в 100% было при попытке вытянуть таблицу FDB по SNMP с количеством записей около 1000.


раз в пять минут стагиваю с коммутаторов таблицу arpe по snmp (до 2к записей), проблем с загрузкой не наблюдаю.


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

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


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

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


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

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