Cisco ip input грузит процессор
Thanks. We have received your request and will respond promptly.
Come Join Us!
- Talk With Other Members
- Be Notified Of Responses
To Your Posts - Keyword Search
- One-Click Access To Your
Favorite Forums - Automated Signatures
On Your Posts - Best Of All, It's Free!
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.
Posting Guidelines
Promoting, selling, recruiting, coursework and thesis posting is forbidden.
IPX Input
The IPX Input process is similar to the IP Input process in the sense that it takes care of process switching, except that the IPX Input process switches IPX packets. Nearly all IPX packets are at process level looked at by IPX Input before getting queued to other IPX processes such as IPX SAP In, IPX RIP In, and so on. Unlike IP, IPX supports only one interrupt switching mode, and that is IPX fast-switching which is enabled by default. IPX fast-switching is enabled using the ipx route-cache interface command .
If you see high CPU utilization during the IPX Input process, verify the following:
IPX fast-switching is disabled. Use the show ipx interface command if IPX fast-switching is disabled.
Some IPX traffic cannot be IPX fast-switched:
IPX broadcasts - Check if the router is overwhelmed with IPX broadcasts using the show ipx traffic command.
IPX routing updates - If there are a lot of instabilities in the network, routing update processing increases.
Note: Instead of IPX RIP, use IPX EIGRP (incremental) to reduce the amount of updates, especially over slow speed serial links (see Routing Novell IPX Over Slow Serial Lines and SAP Management for details).
Note: More IPX-related documents can be found at the Novell IPX Technology Support Page.
TAG Stats Background
The CPU utilization seen for the "TAG Stats Background" process is expected, and it does not affect traffic forwarding.
The TAG Stats Background is a low priority process. This process collects statistics for tags and forwards them to the RP. It is not a function of the amount of traffic, but of the amount of work that the MPLS/LDP control plane does. This is an expected behavior, and it does not impact traffic forwarding. This issue is documented in the bug CSCdz32988 (registered customers only) .
TCP Timer
When the Transmission Control Protocol (TCP) timer process uses a lot of CPU resources, this indicates that there are too many TCP connection endpoints. This can happen in data-link switching (DLSw) environments with many peers, or in other environments where many TCP sessions are simultaneously opened on the router.
Reply To This Thread
Posting in the Tek-Tips forums is a member-only feature.
Click Here to join Tek-Tips and talk with other members! Already a Member? Login
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Условные обозначения
Дополнительную информацию об условных обозначениях в документе см. в разделе Технические советы Cisco. Условные обозначения.
More 2600 problems - 99% CPU usage - IP Input
I wrote recently because my cisco 2600 has been crashing frequently and i don't know what to do. well, today at three different times the router seemed to die. I can get into it through a terminal, but it responds EXTREMELY slowly to whatever i type.
"show proc CPU" shows 99% usage, almost all of it being taken up by the "IP Input" process. I also have several errors in my syslog similar to:
%SYS-3-CPUHOG: Task ran for 2148 msec (20/13), Process = IP Input, PC = 3199482 -Traceback= 314B5E6 319948A
I read that that error is the cisco watchdog timer basically telling me that the "IP Input" process has been hanging and using too much CPU.
What could cause this? How can I fix it? Am I being DOS'ed?
Any help would be appreciated. Thank you.
This can be an ARP storm, broadcast storm, DOS attack, screwed up route tables with EIGRP or OSPF and the list goes on.
Do a show ip traffic and see which protocol is the heavy user.. a sniffer would be be very useful for this..
"Diplomacy; the art of saying 'nice doggie' till you can find a rock" Wynn Catlin
Well, I discovered the problem and I want to share my experience.
first, sho proc cpu showed 99% usage. i reloaded the router and within an hour it was back to 99% (almost all being taken up by "IP Input".)
i was able to see the traffic flowing through the router. i had a ton of the following, even though debugging was only on for a few seconds:
01:03:39: TCP src=4815, dst=80, seq=2285476180, ack=0, win=16384 SYN
01:03:39: IP: s= (FastEthernet0/0), d=10.1.38.244 (Serial0/0), g=10.1.38.244, len 48, forward
all with same source address, but different destination- a lot of which were unroutable ip addresses. this told me that the traffic was coming from inside our network (in FastEthernet, out Serial).
here i wasted some time trying to set up an ACL to block the source address while i tried to figure out what was going on, but the source address shown on the router was the public NAT address, and not the private internal address of the machine. i needed the internal address of the machine.
time for the sniffer. i set up our switch to mirror all of our router's traffic to my machine, then i started up the sniffer. within 3 seconds it said "300 packets captured, 500, 1000. ). almost every packet was from one internal ip address.
so, i took that machine off of the network and the router cpu went down to 4% instantly. now i need to figure out what's wrong with that box. seems like a trojan of some sort- or perhaps code red since all traffic has destination port 80 (doesn't code red search for that?), but the box was never directly accessible by the outside world, so i'm not sure how it could have been infected. it was never patched because no one was aware it was running IIS. it is not used for web serving or anything. it may not be code red either, but that's where i am now.
this was a great learning experience for me. i hope it helps others also.
Way cool that you found it
port is code red's favorite port to use.. my firewall has been dumping alot of queries on that port. Cable company's filtering is for naught.
Someone may have uploaded files with the virus? Stuff like this while frustrating is alot of fun to chase down .
We have found a few "webservers" .. nonsense like installing frontpage which in turn installs MS personal webserver.. nasty trick of MS
"Diplomacy; the art of saying 'nice doggie' till you can find a rock" Wynn Catlin
Red Flag Submitted
Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
ARP Input
High CPU utilization in the Address Resolution Protocol (ARP) Input process occurs if the router has to originate an excessive number of ARP requests. The router uses ARP for all hosts, not just those on the local subnet, and ARP requests are sent out as broadcasts, which causes more CPU utilization on every host in the network. ARP requests for the same IP address are rate-limited to one request every two seconds, so an excessive number of ARP requests would have to originate for different IP addresses. This can happen if an IP route has been configured pointing to a broadcast interface. A most obvious example is a default route such as:
In this case, the router generates an ARP request for each IP address that is not reachable through more specific routes, which practically means that the router generates an ARP request for almost every address on the Internet. For more information about configuring next hop address for static routing, see Specifying a Next Hop IP Address for Static Routes.
Alternatively, an excessive amount of ARP requests can be caused by a malicious traffic stream which scans through locally attached subnets. An indication of such a stream would be the presence of a very high number of incomplete ARP entries in the ARP table. Since incoming IP packets that would trigger ARP requests would have to be processed, troubleshooting this problem would essentially be the same as troubleshooting high CPU utilization in the IP Input process.
IP Input High CPU with Non-VRF NAT NVI
In some of these Non-VRF scenarios, NAT NVI can cause process switching which can lead to high cpu due to the IP Input process and reduced throughput. Process Switching is seen when NAT NVI is done along with interface overload or the NAT pool that contains IP addresses that are within the subnet of a local interface. When this happens, show process cpu sorted command shows high utilization due to the IP Input process.
show ip cef switching statistics feature shows a large and increased number of punts due to Packet destined for us:
More 2600 problems - 99% CPU usage - IP Input
Пример сеанса отладки IP-пакета
Настроенные приемники данных протоколирования необходимо сначала проверить командой show logging:
Отключите все приемники данных протоколирования за исключением буфера регистрации и очистите этот буфер:
Для облегчения восприятия выходных данных отладки следует включить дату и время в миллисекундах:
Теперь можно начать сеанс отладки:
Отладка должна длиться не более 3 – 5 секунд. Сеанс отладки можно остановить командой undebug all:
Результаты можно проверить командой show logging:
В журнале указано следующее:
Пакет принимается каждые четыре миллисекунды
IP-адрес источника 192.168.40.53
Пакеты поступают на интерфейс Ethernet0/1
Пакеты имеют разные IP-адреса назначения
Пакеты отправлены из интерфейса Ethernet0/0
IP-адрес следующего узла 10.200.40.1
Пакеты представляли собой ICMP-запросы (тип=8)
В этом примере высокая загрузка ЦП в процессе IP входа была вызвана лавиной эхо-запросов с IP-адреса 192.168.40.53.
Затопление пакетами SYN можно без труда обнаружить этим способом, поскольку наличие флага SYN указано в выходных данных отладки:
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
ARP Background
ARP background processes handle mulitple jobs and can consume high CPU utilization.
This list provides some example jobs:
ARP flush due to interface up/down events
Clearing the ARP table through the clear arp command
ARP input packets
Virtual Template Background
A virtual template (vtemplate) has to be cloned for each new virtual access interface whenever a new user gets connected to the router or access server. The CPU utilization in the Vtemplate Backgr process can get extremely high if the number of users is large. This can be avoided by configuring pre-cloning of the virtual template. For further information, see Session Scalability Enhancements.
IP Background
The IP Background process involves these procedures: the periodic aging of the ICMP redirect cache every minute; an encapsulation type change of an interface; the move of an interface to a new state, UP and/or DOWN; a change in the IP address of the interface; the expiration of a new dxi map; and the expiration of dialer timers.
The IP Background process modifies the routing table in accordance with the status of the interfaces, while the IP Background process assumes that there is a link-state change when it receives link-state change messages. It then notifies all routing protocols to check the affected interface. If more interfaces run routing protocols, a higher CPU utilization is caused by the IP Background process.
Требования
Прежде чем изучать данный документ, рекомендуется ознакомиться с документом Решение проблемы высокой загрузки ЦП на маршрутизаторах Cisco.
Introduction
This document describes a scenario where Network Address Translation for Virtual Interface (NAT NVI) causes high CPU utilization. NAT NVI was designed to allow NAT between Virtual Route Forwarding (VRF) contexts, but has been seen to be deployed in non VRF scenarios.
Solution
1. Add in the new legacy NAT statements for dynamic and static entries.
2. Add ip nat inside or ip nat outside as appropriate to the NAT interfaces.
3. Remove ip nat enable from all interfaces.
4. Remove dynamic and static NAT NVI entries. This might require you to use the "forced" keyword in order to remove the entries currently in use.
Note: Configuration guide for NAT NVI can be found here for reference.
В этом году мы опубликовали две статьи, связанные со сравнением функциональности маршрутизаторов и межсетевых экранов компании Cisco, а также с обзором разделения control и data plane в сетевом оборудовании. В комментариях к этим статьям был затронут вопрос производительности сетевого оборудования. А именно как зависит производительность маршрутизаторов Cisco разных поколений от включения на них тех или иных сервисов. Так же обсуждалась тема производительности межсетевых экранов Cisco ASA. В связи с этим возникло желание посмотреть на эти вопросы с практической стороны, подкрепив известные моменты цифрами. О том, что получилось и, что получилось не очень, расскажу под катом.
Под производительностью будем подразумевать пропускную способность устройства, измеряемую в Мбит/с. Стенд для тестирования представлял из себя два ноутбука, с установленной программой iPerf3. Методика испытания – достаточно проста. iPerf3 запускался в режиме передачи пакетов по протоколу TCP. Использовалось 5 потоков. Я не ставил перед собой цели определить реальную производительность устройств. Для этой задачи необходима более сложная экипировка, так как требуется воссоздавать паттерны трафика реальной сети. Да и мерить нужно было бы количество обрабатываемых пакетов. У нас же основной задачей была оценка влияния использования различных сервисов на работу устройства, а также сравнение результатов, полученных на различных устройствах. Таким образом, выбранный инструментарий на первый взгляд казался достаточно подходящим для поставленных задач.
Cisco Integrated Services Router (ISR) Generation 1 и 2
Для начала из коробки были взяты два младших маршрутизатора Cisco 871 и 881. Это маршрутизаторы разных поколений (871 более старый – G1, а 881 более новый – G2), которые обычно ставятся в небольшие офисы, например, в удалённые филиалы компании.
Исследуемые маршрутизаторы имеют сходные черты в плане программной и аппаратной архитектуры: операционная система – Cisco IOS, «мозг» устройств – SoC MPC 8272 в 871 и SoC MPC 8300 в 881.
- Маршрутизация с использованием технологии Cisco Express Forwarding (CEF).
- Маршрутизация без использования оптимизирующих технологий (Process Switching).
- Маршрутизация (CEF) и применённый список доступа (ACL) на одном из интерфейсов.
- Маршрутизация (CEF) и ACL на одном из интерфейсов с опцией log.
- Маршрутизация (CEF) и включённая служба трансляции адресов (NAT*).
- Маршрутизация (CEF) и включенные сервисы межсетевого экранирования (CBAC для 871 и ZPF для 881).
- Маршрутизация (CEF), МСЭ и NAT.
Для более наглядного сравнения данные по разным устройствам нанесены на один график (рисунок 1).
- Так как интерфейсы на устройствах имеют тип FastEthernet, максимальная пропускная способность точка-точка, полученная через iPerf3, не превышала 95 Мбит/с. При этом загрузка ЦПУ для некоторых режимов тесетирования не достигала своих пиковых значений, а значит цифра 95 Мбит/с для этих маршрутизаторов не предел.
- Маршрутизатор 881 выглядит лучше, так как имеет более продвинутую аппаратную начинку (в первую очередь процессор общего назначения, далее ЦПУ).
- Как и следовало ожидать, мы видим заметную деградацию производительности при включении сервисов.
- При отключении CEF мы имеем существенное уменьшение производительности, так как маршрутизатор начинает обрабатывать каждый пакет не самым оптимальным образом.
- Включение опции log в ACL приводит к повышению нагрузки на устройство (загрузка ЦПУ в этом случае составляет 99%), что негативно сказывается на производительности. Обусловлено это тем фактом, что опция log заставляет маршрутизатор обрабатывать каждый пакет, попадающий в отмеченную строчку ACL, в режиме Process Switching, что существенно увеличивает нагрузку на процессор.
Общая загрузку ЦПУ составляет 47%. Из них 42% уходит на обработку прерываний, вызванных передачей пакетов. Прерывания при передаче пакетов бывают двух типов: прерывание получения и прерывание передачи пакета. Прерывание получения пакета инициируется интерфейсным процессором, когда пакет получен через интерфейс маршрутизатора и он готов к обработке. Получив такое прерывание ЦПУ прекращает обработку текущих процессов, и начинает выполнять обработку пакета. Так как включен режим CEF, ЦПУ принимает решение, куда передать пакет на основании таблиц CEF (FIB и Adjacency) во время прерывания. Т.е. ему не требуется отправлять пакет на процессорную обработку, а значит существенно экономятся процессорные мощности. В связи с этим на процессы в маршрутизаторе тратится лишь 5% загрузки ЦПУ. Прерывание отправки пакета передаётся на ЦПУ, когда пакет был отправлен интерфейсным процессором дальше по каналам связи. ЦПУ реагирует на это прерывание обновлением счётчиков и освобождением памяти, выделенной для хранения пакета. В плане вклада в общую загрузку устройства данное прерывание менее интересно.
Маршрутизация в режиме Process Switching:
Теперь общая загрузка ЦПУ составляет 99%. Причём только 27% уходит на прерывания. Остальные 72% тратятся на выполнение процессов. Процесс IP Input забирает практически 70% процессорного времени. Именно этот процесс отвечает за процессорную обработку пакетов, т.е. тех пакетов, которые не могут быть обработаны во время прерывания (например, отключен CEF или в его таблицах нет нужной информации для передачи, пакеты адресованы непосредственно маршрутизатору или являются широковещательным трафиком и пр.). А так как в нашем примере отключены CEF и Fast Switching (об этом методе я не упоминал в силу его неактуальности), после того как к ЦПУ пришло прерывание получения пакета, ЦПУ отправляет пакет на процессорную обработку. Прерывание завершается и ЦПУ обрабатывает пакет непосредственно в рамках одного из своих процессов. Поэтому мы и видим такую утилизацию ЦПУ процессом IP Input.
Ещё интересно будет посмотреть на загрузку ЦПУ в случае ACL с опцией log.
Опция log в ACL заставляет маршрутизатор каждый пакеты отправлять на процессорную обработку, признаком чего, как и в предыдущем примере, является высокая утилизация ЦПУ процессом IP Input.
Cisco ASA 5500
Давайте посмотрим теперь на такое устройство как межсетевой экран Cisco ASA 5505. Можно сказать, что ASA 5505 – это аналогичное маршрутизатору Cisco 881 устройство в плане позиционирования (для небольших офисов и филиалов). Эти устройства примерно из одного ценового сегмента и обладают относительно сходными аппаратными характеристиками. В ASA 5505 используется ЦПУ AMD Geode с тактовой частотой 500 MHz. Самое главное отличие –операционная система. В ASA 5505 используется ASA OS. Про различия между маршрутизаторами и ASA в плане функциональности мы говорили в отдельной статье. Посмотрим теперь на производительность ASA и влияния на неё различных сервисов.
- Межсетевой экран.
- Межсетевой экран и включённая служба трансляции адресов (NAT).
- Межсетевой экран и ACL на одном из интерфейсов с опцией log.
Из диаграммы видно, пропускная способность ASA 5505 во всех режимах работы ограничена лишь техническими аспектами стенда. Причём, если мы посмотрим на загрузку ЦПУ, то для всех вариантов она практически идентична:
- При относительно схожих ценовых и аппаратных параметрах ASA 5505 предоставляет большую производительность, чем маршрутизатор 881.
- Производительность ASA практически не зависит от сервисов (во всяком случае в рамках данного стенда её выявить не удалось).
- Опция логирования (log) в ACL не приводит к деградации производительности. Обусловлено этой спецификой реализаций функции маршрутизации в устройстве.
Cisco ISR 4000
Идём дальше. Предлагаю посмотреть, как обстоят дела с влиянием сервисов на производительность маршрутизаторов Cisco ISR 4000. Это самая новая линейка маршрутизаторов Cisco для небольших и средних инсталляций. Как мы помним, в этих маршрутизаторах используется операционная система Cisco IOS XE, которая умеет работать в многопоточном режиме. С точки зрения аппаратной начинки, в этих маршрутизаторах используются многоядерные процессоры.
И так достаём из коробки самый младший Cisco ISR 4000 – 4321. Активируем на нём performance license, чтобы получить заявленную максимальную производительность 100 Мбит/с, и начинаем тестировать. Важно отметить, что на маршрутизаторах ISR 4000 всегда используется шейпер, ограничивающий максимальную производительность устройства. Используется два порога: базовая (для 4321 – это 50 Мбит/с) и расширенная (для 4321 – это 100 Мбит/с; активируется лицензией performance license) производительности. Такая схема работы направлена на получение прогнозируемых значений производительности устройства, не позволяя «захлёбывать» от большого количества трафика.
Для начала проверяем производительность чистой маршрутизации в режиме CEF без дополнительных сервисов. Запускаем iPerf3 и получаем 95 Мбит/с. Ожидаемо. Смотрим в этот момент на загрузку ЦПУ:
Вот это результат! Загрузка ЦПУ 1%. Круто! Но не всё так идеально. Понимание данного феномена приходит после более детального изучения специфики работы IOS XE.
IOS XE – это операционная система, созданная на базе Linux’а, тщательно допиленного и оптимизированного вендором. Традиционная операционная система Cisco IOS запускается в виде отдельного Linux процесса (IOSd). Самое интересное заключается в том, что в IOS XE мы имеем отдельный основной процесс, выполняющий функции data plane. Т.е. мы имеем чёткое разделение control и data plane на программном уровне. Процесс, отвечающий за control plane, называется linux_iosd-imag. Это собственно и есть привычным нам IOS. Процесс, отвечающий за data plane, называется qfp-ucode-utah. QFP, знакомо? Сразу вспоминаем про сетевой процессор QuantumFlow Processor в маршрутизаторах ASR 1000. Так как изначально IOS XE появился именно на этих маршрутизаторах, процесс, отвечающий за передачу пакетов, получил аббревиатуру qfp в своём названии. В дальнейшем для ISR 4000, видимо, ничего менять не стали, с одной лишь разницей, что в ISR 4000 QFP является виртуальным (выполняется на отдельных ядрах процессора общего назначения). Кроме озвученных процессов в IOS XE присутствуют и другие вспомогательные процессы.
Таким образом, чтобы посмотреть на сколько загружены процессорные мощности, анализируем вывод следующих команд, специфичных для IOS XE:
В нашем маршрутизаторе используется четыре ядра (CPU 0, 1, 2, и 3). Команда позволяет нам получить информацию по загрузке каждого из них.
Примечание
Увидеть аппаратную начинку маршрутизатора можно выводом стандартной для Linux информации из файла dmesg: more flash:/tracelogs/dmesg.
В маршрутизаторе ISR 4321 используется процессор:
CPU0: Intel® Atom(TM) CPU C2558 @ 2.40GHz stepping 08
Следующая команда позволяет нам увидеть утилизацию процессорных мощностей различными процессами:
В данном примере, IOS съедает всего 2%, а QFP – 150% (что эквивалентно утилизации одно ядра полностью и ещё одного на половину).
Так, что же в итоге показывает тогда команда «show processes cpu»? Она выводит загрузку виртуального ЦПУ, который был выделен процессу IOSd. Под данный процесс на маршрутизаторах ISR 4000 выделяется одно из ядер ЦПУ.
Из всего этого можно сделать вывод, что в IOS XE архитектура обработки пакетов существенно изменилась по сравнению с обычным IOS. IOS больше не занимается обработкой абсолютно всех пакетов. Данным процессом обрабатываются лишь те пакеты, которые требуют процессорной обработки. Но даже в этом случае в IOS XE используется более новый механизм Fastpath, который реализует передачу пакетов для процессорной обработки посредствам отдельного потока внутри IOSd, а не через прерывания. Прерывания в IOSd возникают только, когда не возможна обработка через Fastpath.
- Маршрутизация с использованием технологии CEF.
- Маршрутизация и применённый список доступа (ACL) на одном из интерфейсов.
- Маршрутизация (CEF) и ACL на одном из интерфейсов с опцией log.
- Маршрутизация (CEF) и включённая служба трансляции адресов NAT.
- Маршрутизация (CEF) и включенные сервисы межсетевого экранирования (ZPF).
- Маршрутизация (CEF), МСЭ и NAT.
Результаты тестирования представлены на рисунке 3. Для большей наглядности на один график нанесены значения пропускной способности (а они у нас во всех случаях одинаковы) и загрузку ЦПУ процессом QFP. Процесс IOSd не интересен в силу того, что во всех режимах загрузка виртуального ЦПУ внутри IOSd минимальна – 1%.
При проведении тестирования выявить зависимость производительности маршрутизатора ISR 4321 от включения сервисов не удалось. Есть небольшое повышение загрузки CPU, но совсем незначительное. Также стоит отметить, что включение опции log в ACL больше не приводит к драматическим потерям в производительности, так как пакет не отправляется на процессорную обработку.
На примере нескольких устройств разных поколений и типов мы попытались рассмотреть, как зависит производительность от включения различных сервисов. В целом полученные результаты укладываются в ранее известные факты. Америки мы не открыли. Краткие выводы, полученные в результате тестирования, можно сформулировать так:
Net Background
The Net Background process runs whenever a buffer is required but is not available to the process or interface. It creates the desired buffers from the main pool based on the request. Net background also manages the memory used by each process and cleans up the freed-up memory. This process is mainly associated with the interfaces and can consume significant CPU resources. The symptoms of high CPU are increase in throttles, ignores, overruns, and resets on an interface.
Предварительные условия
Prerequisites
Contents
Requirements
We recommend that you read Troubleshooting High CPU Utilization on Cisco Routers before proceeding with this document.
Introduction
This document describes how to troubleshoot high CPU utilization caused by different processes.
Components Used
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
FIB Control Timer
The FIB control timer initializes and starts the FIB statistics collection-timer for per-VLAN statistics and global statistics; initializes and starts the FIB/ADJ request/exception timer; maintains the FIB-related registry functions; and initializes BGP accounting timer. These processes get started when EARL is initialized.
Other Processes
If any other process is consuming a lot of CPU resources, and there is no indication of any problem in the logged messages, then the problem could possibly be caused by a bug in the Cisco IOS® software. Using the Bug Toolkit (registered customers only) , run a search for the specified process to see if any bugs have been reported.
В данном документе описано решение проблемы высокой загрузки ЦП процессом IP-входа.
Примечание. Данный документ не содержит стратегии предотвращения атак различных типов.
Используемые компоненты
Данный документ применим для любого оборудования и программного обеспечения.
Сведения, представленные в данном документе, были получены на тестовом оборудовании в специально созданных лабораторных условиях. При написании данного документа использовались только данные, полученные от устройств с конфигурацией по умолчанию. При работе с реально функционирующей сетью необходимо полностью осознавать возможные последствия выполнения команд до их применения.
Contents
IP-вход
Процесс ПО Cisco IOS®, называемый «IP-вход», осуществляет коммутацию процессов IP-пакетов. Если процесс IP-входа использует слишком много ресурсов ЦП, маршрутизатор осуществляет коммутацию большого объема IP-трафика. Проверьте следующее:
Коммутация прерываний выключена на интерфейсах с большим объемом трафика.
Коммутация прерываний связана с использованием алгоритмов коммутации, отличных от коммутации процессов. Например, быстрая коммутация, оптимальная коммутация, коммутация Cisco Express Forwarding и т. д. (дополнительную информацию см. в разделе Основы настройки производительности). По выходным данным команды show interfaces switching определите интерфейс, перегруженный трафиком. По выходным данным команды show ip interface можно определить метод коммутации, используемый на каждом интерфейсе. Отмените запрет на коммутацию при прерывании на этом интерфейсе. Следует помнить, что обычная быстрая коммутация настраивается на выходных интерфейсах: если для интерфейса настроена быстрая коммутация, пакеты, выходящие из такого интерфейса, являются пакетами быстрой коммутации. Метод коммутации Cisco Express Forwarding настраивается на входных интерфейсах. Чтобы создать базу данных переадресации (FIB) и записи таблицы смежности для определенного интерфейса, настройте коммутацию Cisco Express Forwarding на всех интерфейсах, связанных маршрутом с этим интерфейсом.
Быстрая коммутация на этом же интерфейсе выключена
Если интерфейс имеет много вторичных адресов или субинтерфейсов и имеется большой объем трафика, исходящий из интерфейса на адрес этого же интерфейса, тогда все эти пакеты обрабатываются коммутацией процессов. В этой ситуации необходимо включить ip route-cache same-interface на этом интерфейсе. Когда используется коммутация Cisco Express Forwarding, нет необходимости отдельно включать коммутацию Cisco Express Forwarding на том же интерфейсе.
Быстрая коммутация на интерфейсе, обеспечивающем политику маршрутизации, выключена
Если на интерфейсе настроена карта маршрутизации и большой объем трафика обрабатывается этой картой, тогда маршрутизатор использует коммутацию процессов для трафика. В этой ситуации необходимо включить параметр ip route-cache policy на этом интерфейсе. Проверьте ограничения, указанные в разделе «Включение маршрутизации на основе политики, обрабатываемой быстрой коммутацией».
Приходит трафик, который не коммутируется на уровне прерывания
Это может быть любой из следующих типов трафика. Чтобы получить дополнительную информацию щелкните соответствующую ссылку.
Пакеты, для которых нет записи в кэше коммутации
Если настроена быстрая, оптимальная коммутация или Cisco Express Forwarding, пакет, для которого нет записи в кэше быстрой коммутации, FIB или таблицах смежности, все равно обрабатывается. Затем создается запись в соответствующем кэше или таблице, а все последующие пакеты, соответствующие этим критериям, обрабатываются быстрой, оптимальной или CEF-коммутацией. В нормальных условиях эти обрабатываемые пакеты не приводят к чрезмерной загруженности ЦП. Однако, если в сети имеется устройство, которое: 1) генерирует пакеты с чрезвычайно высокой скоростью для устройств, достижимых через маршрутизатор, и 2) использует другой IP-адрес источника или назначения, для этих пакетов нет соответствия в кэше коммутации или таблице, тогда пакеты обрабатываются процессом IP-входа (если настроена коммутация NetFlow, TCP порты источника и назначения также сравниваются с записями в кэше NetFlow). Устройство, являющееся источником пакетов, может находится в аварийном состоянии или осуществлять атаку.
(*) Только с подобранными смежностями. Дополнительную информацию о смежностях Cisco Express Forwarding см. в документации Cisco Express Forwarding.
Пакеты, предназначенные для маршрутизатора
Ниже приведены примеры пакетов, предназначенных для маршрутизатора.
Обновления маршрутизации, которые поступают с чрезвычайно высокой скоростью. Если маршрутизатор получает чрезвычайно большое число обновлений маршрутизации, которые необходимо обработать, эта задача может привести к перегрузке ЦП. Как правило, этого не происходит в стабильной сети. Способ сбора данных зависит от настроенного протокола маршрутизации. Однако целесообразно начать регулярно проверять выходные данные команды show ip route summary. Быстро меняющиеся значения – признак нестабильности сети. Частые изменения в таблице маршрутизации означают повышенную обработку протокола маршрутизации, что приводит к повышенной загрузке ЦП. Дополнительную информацию о решении этой проблемы см. в разделе Поиск и устранение неисправностей TCP/IP в руководстве по поиску и устранению неисправностей объединенной сети.
Атака на основе подмены адресов (спуфинг). Чтобы идентифицировать проблему, определите объем IP-трафика с помощью команды show ip traffic. Если возникла проблема, становится значительным число полученных пакетов с локальным адресатом. Далее проверьте выходные данные команд show interfaces и show interfaces switching, чтобы определить интерфейс, принимающий пакеты. После определения принимающего интерфейса, включите ip accounting на исходящем интерфейсе и проверьте наличие шаблона. При атаке адрес источника почти всегда отличается, а адрес назначения остается неизменным. Для временного решения проблемы можно настроить список доступа (предпочтительно на устройстве, ближайшем к источнику пакетов), но полное решение заключается в отслеживании устройства, являющегося источником пакетов, и остановки атаки.
Проверьте число широковещательных пакетов в выходных данных команды show interfaces Если сравнить число широковещательных пакетов с общим числом пакетов, полученных интерфейсом, можно сделать вывод о чрезмерности числа широковещательных пакетов. Если к маршрутизатору подключена локальная сеть с несколькими коммутаторами, тогда это может указывать на проблему с связующим деревом.
IP-пакеты с параметрами
Пакеты, которым требуется преобразование протокола
Многоканальный протокол PPP (поддерживается в методе коммутации Cisco Express Forwarding)
Если в маршрутизаторе отсутствует адаптер службы сжатия (CSA), сжатые пакеты должны обрабатываться коммутацией процессов.
Если в маршрутизаторе отсутствует адаптер службы шифрования (ESA), зашифрованные пакеты должны обрабатываться коммутацией процессов.
Пакеты, проходящие через последовательные интерфейсы с инкапсуляцией X.25
В наборе протоколов X.25 управление потоком реализуется на втором уровне модели взаимодействия открытых систем (OSI).
Большое число пакетов, поступающих с чрезвычайно высокой скоростью для адресата в непосредственно подключенной подсети, для которого нет записи в таблице протокола разрешения адресов (ARP). Это не должно иметь место в случае ТСР-трафика из-за оконного механизма, однако может происходить с UDP трафиком. Чтобы определить проблему, повторите действия, рекомендованные для отслеживания атак спуфинга.
Через маршрутизатор передается большой объем многоадресного трафика. К сожалению, простого способа определения объема многоадресного трафика нет. Команда show ip traffic отображает только сводную информацию. Однако, если на маршрутизаторе настроена многоадресная маршрутизация, можно включить быструю коммутацию многоадресных пакетов командой настройки интерфейса ip mroute-cache (быстрая коммутация многоадресных пакетов выключена по умолчанию).
Превышен лимит подписки для маршрутизатора. Если маршрутизатор используется чрезмерно интенсивно и не может обработать объем трафика, попробуйте перераспределить нагрузку на другие маршрутизаторы или установите маршрутизатор с более высокой производительностью.
На маршрутизаторе настроено преобразование сетевых IP-адресов и большое число DNS пакетов передается через маршрутизатор. UDP- или TCP-пакеты с портом 53 (DNS) источника или назначения всегда передаются преобразованием NAT на уровень обработки.
Существуют пакеты других типов, которые передаются на обработку.
Ведение журнала на консоли приводит к излишнему увеличению прерываний для ЦП и повышает его загрузку. Ведение журнала на узле (или контролирующее ведение журнала) генерирует дополнительный трафик на интерфейсах.
TTY Background
The TTY Background process is a generic process used by all terminal lines (console, aux, async, and so on). Normally there should not be any impact on the performance of the router since this process has a lower priority compared to the other processes that need to be scheduled by the Cisco IOS software.
If this process takes high CPU utilization, check whether "logging synchronous" is configured under "line con 0." The possible cause could be Cisco bug ID CSCed16920 (registered customers only) Cisco bug ID or CSCdy01705 (registered customers only) .
Читайте также: