roma33rus Опубликовано 16 мая (изменено) · Жалоба Всем привет. Имею внутри сети Cisco 4948E. На ней терминирую вланы. Время от времени фиксируем ситуацию, когда подскакивает загрузка CPU: Путем диагностики выяснилось, что грузит CPU обработка трафика. Поэтому сняли дамп трафика с cpu так: monitor session 4 source cpu both Собственно я офигел, когда увидел там HTTP трафик, при этом предназначается он абоненту, который за этой циской. Пришел он точно извне, судя по информации L2 в пакетиках. При этом, если абону отключить услугу, то трафик блочится выше, не доходя до циски. Как такой трафик мог оказаться на CPU у циски? У железки выхода в инет нет, она только терминирует вланы внутри сети, больше ничем не занимается. Собственно вот сам дамп: cisco_cpu.pcapng И здесь дубль: https://cloud.mail.ru/public/nqEo/w8RXnM3Da Буду благодарен за любую подсказку. Изменено 16 мая пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 16 мая · Жалоба Не получается скачать дамп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 16 мая · Жалоба 32 минуты назад, Умник сказал: Не получается скачать дамп. Да, действительно, не качается. Вот выложил в облако: https://cloud.mail.ru/public/nqEo/w8RXnM3Da Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 16 мая · Жалоба Очень похоже, что на абонента валится что-то похожее на DDoS. Это ненормальный TCP. К тому же используется порт 443 для обычного HTTP (не -S). Трафик асимметричный, от самого абонента ничего нет. Он был в сети на момент записи дампа? Посмотрите в эту сторону: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html (особенно в части взаимодействия таймеров для FDB и ARP). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 16 мая · Жалоба 6 минут назад, Умник сказал: Очень похоже, что на абонента валится что-то похожее на DDoS. Это ненормальный TCP. К тому же используется порт 443 для обычного HTTP (не -S). Трафик асимметричный, от самого абонента ничего нет. Он был в сети на момент записи дампа? Посмотрите в эту сторону: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html (особенно в части взаимодействия таймеров для FDB и ARP). Да я тоже на ддос грешу. Абона не было в сети на этот момент, физически. Обратный трафик мы можем и не увидеть, я же снимал его с CPU самой циски. Меня больше интересует, каким образом он на CPU этот трафик взобрался. Ссылочка полезная, спасибо, почитаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 16 мая · Жалоба Как мне кажется, у вас была ситуация, когда из-за асимметрии в трафике MAC-адрес абонента в FDB протух, а ARP-запись - нет. В этом случае свитч стал источником Unknown Unicast-трафика. Есть предположение, что как минимум часть такого трафика может попадать на CPU. В следующий раз посмотрите вывод show process cpu. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 16 мая · Жалоба 16 минут назад, Умник сказал: Как мне кажется, у вас была ситуация, когда из-за асимметрии в трафике MAC-адрес абонента в FDB протух, а ARP-запись - нет. В этом случае свитч стал источником Unknown Unicast-трафика. Есть предположение, что как минимум часть такого трафика может попадать на CPU. В следующий раз посмотрите вывод show process cpu. Да, процессы смотрели уже. Там в топе был "Cat4k Mgmt HiPri". Про fdb и arp понял. Посмотрю в эту сторону и в следующий раз внимание на нее обращу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 16 мая · Жалоба Еще sh platform health. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 16 мая · Жалоба 11 минут назад, Умник сказал: Еще sh platform health. Да, это тоже смотрели. Сейчас точно не скажу, но вроде под нагрузкой был "K5CpuMan Review". Но это не точно. В следующий раз будем снимать показатели и сюда готовить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 16 мая · Жалоба Тогда еще sh platform cpu packet statistics https://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/65591-cat4500-high-cpu.html https://forum.nag.ru/index.php?/topic/145334-cisco-4948e-high-cpu-load/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BOJIKA Опубликовано 24 мая · Жалоба в конфиге ищите ответы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...