Cisco 4948E попадание трафика на CPU

[roma33rus]

Всем привет. Имею внутри сети Cisco 4948E. На ней терминирую вланы. Время от времени фиксируем ситуацию, когда подскакивает загрузка CPU:

 

Путем диагностики выяснилось, что грузит CPU обработка трафика. Поэтому сняли дамп трафика с cpu так:

monitor session 4 source cpu both

 

Собственно я офигел, когда увидел там HTTP трафик, при этом предназначается он абоненту, который за этой циской. Пришел он точно извне, судя по информации L2 в пакетиках. При этом, если абону отключить услугу, то трафик блочится выше, не доходя до циски.

 

Как такой трафик мог оказаться на CPU у циски? У железки выхода в инет нет, она только терминирует вланы внутри сети, больше ничем не занимается.

 

Собственно вот сам дамп: cisco_cpu.pcapng

И здесь дубль: https://cloud.mail.ru/public/nqEo/w8RXnM3Da

 

Буду благодарен за любую подсказку.

Edited May 16, 2024 by roma33rus

[Умник]

Не получается скачать дамп.

[roma33rus]

32 минуты назад, Умник сказал:

Не получается скачать дамп.

Да, действительно, не качается.

 

Вот выложил в облако: https://cloud.mail.ru/public/nqEo/w8RXnM3Da

[Умник]

Очень похоже, что на абонента валится что-то похожее на DDoS. Это ненормальный TCP. К тому же используется порт 443 для обычного HTTP (не -S).

Трафик асимметричный, от самого абонента ничего нет. Он был в сети на момент записи дампа? Посмотрите в эту сторону: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html (особенно в части взаимодействия таймеров для FDB и ARP).

[roma33rus]

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 этот трафик взобрался.

 

Ссылочка полезная, спасибо, почитаю.

[Умник]

Как мне кажется, у вас была ситуация, когда из-за асимметрии в трафике MAC-адрес абонента в FDB протух, а ARP-запись - нет. В этом случае свитч стал источником Unknown Unicast-трафика. Есть предположение, что как минимум часть такого трафика может попадать на CPU. В следующий раз посмотрите вывод show process cpu.

[roma33rus]

16 минут назад, Умник сказал:

Как мне кажется, у вас была ситуация, когда из-за асимметрии в трафике MAC-адрес абонента в FDB протух, а ARP-запись - нет. В этом случае свитч стал источником Unknown Unicast-трафика. Есть предположение, что как минимум часть такого трафика может попадать на CPU. В следующий раз посмотрите вывод show process cpu.

Да, процессы смотрели уже. Там в топе был "Cat4k Mgmt HiPri".

 

Про fdb и arp понял. Посмотрю в эту сторону и в следующий раз внимание на нее обращу.

[Умник]

Еще sh platform health.

[roma33rus]

11 минут назад, Умник сказал:

Еще sh platform health.

Да, это тоже смотрели.

 

Сейчас точно не скажу, но вроде под нагрузкой был "K5CpuMan Review". Но это не точно.

 

В следующий раз будем снимать показатели и сюда готовить.

[Умник]

Тогда еще 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/

[BOJIKA]

в конфиге ищите ответы...