WWW.NEW.PDFM.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Собрание документов
 

«загрузки CPU на 6500/7600 с SUP720. Методы траблшутинга, описанные в данном документе позволяют правильно определить причину в 90% случаев высокой нагрузки CPU на SUP720. Основной ...»

Определение причин высокой загрузки CPU на 6500 с SUP720

Целью данного документа является определение методов поиска причин высокой

загрузки CPU на 6500/7600 с SUP720. Методы траблшутинга, описанные в

данном документе позволяют правильно определить причину в 90% случаев

высокой нагрузки CPU на SUP720 .

Основной причиной высокой загрузки CPU на SUP720 является использование

CPU на MSFC, поэтому в основном документ рассматривает высокую загрузку

CPU на MSFC .

Так как невозможно рассмотреть каждую возможную причину высокой загрузки CPU на sup720, то в документе будет продемонстрировано использование некоторых инструментов, встроенных в SUP720 для того, чтобы показать основные методы определения причин высокой загрузки CPU .

Если у вас не получается определить причину на основе данного документа, откройте пожалуйста сервисный запрос в Cisco TAC для исследования данной проблемы .

**Данные методы можно применять для определения высокой загрузки CPU на RSP720, Sup32 and VS-S720, ввиду того, что они имеют общую архитектуру .

Определение того, где происходит высокая загрузка CPU:

В составе SUP720 на 6500 имеется два типа CPU. Один используется для операций на канальном уровне (layer 2 operations) и часто упоминается как SP (Switch Processor) CPU. Другой CPU используется для операций на сетевом и транспортном уровнях (layer3/4 operations) и часто упоминается как RP(Route Processor) CPU. Оба эти процессора располагаются на MSFC3, при этом каждый процессор имеет внутренний (in-band) канал до супервизора с пропускной способностью 1 Гб/с .

Также в зависимости от типа линейной карты, на ней может присутствовать DFC (Distributed Feature Card) для выполнения локального форвардинга на модуле. DFC также имеет свой собственный CPU, который выполняет локальную обработку пакетов на линейной карте. При определенных сценариях всокая загрузка CPU может наблюдаться на этих модулях .

Высокая загрузка CPU на SP (Switch processor):

Высокая загрузка CPU на SP встречается гораздо реже чем высокая загрузка CPU на RP. Причиной высокой загрузки CPU на SP обычно являются операции SUP720 на канальном уровне (layer 2), такие как spanning-tree (обработка BPDU) или обработка отчетов протокола IGMP (IGMP snooping/IGMP queries/membership), а также LACP/PAGP .

Вы можете проверить загрузку CPU SP с помощью следующих команд:

Switch# remote command switch show process cpu или Switch#remove login switch Switch-sp#show process cpu

Высокая загрузка CPU на RP (Route processor):

Загрузка создается трафиком, который должен обрабатываться на сетевом уровне (layer 3), таким как ARP, HSRP, транзитным трафиком, который обрабатывается программно. Ниже будут показаны шаги траблшутинга при высокой загрузке CPU процессами IP Input/ARP input, а также загрузка CPU, вызванная прерываниями (interrupt) коммутируемого трафика в CPU RP .

Вы можете проверить загрузку CPU RP с помощью следующих команд:

Switch#show process cpu

Высокая загрузкана DFC:

CPU на DFC помогает в программировании TCAM и маршрутизации, так как каждый DFC имеет свой собственный экземпляр TCAM .

Высокая загрузка CPU на DFC происходит не очень часто, причин всего несколько. Одной из причин высокой загрузки CPU on the DFC является Netflow Data Export. Обычно загрузка CPU со стороны NDE ожидаема, но в некоторых ситуациях она может быть достаточно высокой, нарушая работу других процессов .





Вы можете проверить загрузку CPU DFC с помощью следующих команд:

Switch# attach module Switch-DFC#show process cpu

Типы загрузки CPU:

Существует два типа загрузки CPU, прерывание (interrupt) и процесс (process) .

Загрузка CPU процессами:

Если процессы вызвали загрузку CPU, то это может быть вызвано следующими причинами:

1.) Processes switched traffic. Это пакеты, которые вызывает срабатывание определенных процессов для того, чтобы CPU перенаправил или обработал данные пакеты. Примером является трафик перенаправляемый процессом "IP Input" или служебный трафик (control-plane), обрабатываемый "PIM process" .

2.) Процесс, пытающийся выполнять очистку таблицы или предыдущего действия. Это может быть заметно по таким процессам как "CEF Scanner" или "BGP Scanner", которые используются для очистки, обновления таблиц CEF и BGP .

Загрузка CPU прерываниями:

Загрузка CPU прерываниями всегда вызвана трафиком. Прерывание (Interrupt) коммутируемого трафика, происходит в том случае, когда нет определенного процесса, но трафик все-равно должен быть перенаправлен .

Определение типов загрузки:

Текущую загрузку CPU процессами и прерываниями можно посмотреть с помощью команды "show process cpu" command.

Ниже показано как определить какой процент загрузки CPU utilization приходится на трафик прерываний, а какой на трафик, обрабатываемый процессами:

6500-3#sh proc cpu CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% Красный – Процент общей загрузки CPU Синий – Процент загрузки CPU, который вызван прерываниями .

При этом, процент загрузки CPU процессами можно посчитать по формуле:

Процент загрузки CPU процессами = Общая загрузка CPU – Загрузка CPU прерываниями

Распространенные причины высокой загрузки CPU на MSFC/RP:

IP пакеты со значением TTL, равным 1 – Если получен пакет с таким значением TTL, то в таком случаю отправителю должно быть послано сообщение «IP unreachable», информирующее о том, что время жизни пакета закончилось при транзите данного пакета. Данная операция не выполняется на аппаратном уровне и такие пакеты должны быть переданы (punted) в MSFC. Для устранения проблемы необходимо найти устройство, рассылающее пакеты с TTL, равным 1 и остановить посылку таких пакетов, увеличить TTL или настроить MLS TTL ratelimiter (http://cco.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/gui de/dos.html#wpmkr1141137) .

Использование ACL с параметром log – Так как параметр «log» требует создания сообщения syslog, то пакет, попадающий под действие записи ACL с параметром “log” должен быть передан (punted) в CPU RP, так как это не может быть выполнено аппаратно. Удалите параметр «log» из ACL для устранения проблемы .

Использование PBR (Policy Based Routing) route-map без записи set – Любой трафик, который попадает под действие PBR route-map в котором нет записи «set» будет передан (punted) в CPU RP. В силу этого нужно запрограммировать next-hop на аппаратном уровне и если next-hop неизвестен, этого трафик должен быть передан в CPU RP, для определения next hop. Для устранения проблемы сконфигурируйте запись set или удалите PBR route-map с интерфейса .

FIB TCAM Exception – Если вы пытаетесь добавить в FIB TCAM больше маршрутов, чем возможно, вы увидите следующую запись о об ошибке в логах:

CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched Это сообщение об ошибке появляется, когда количество доступного пространства в TCAM исчерпано. Это причина высокой загрузки CPU. Это ограничение FIB TCAM. Если TCAM заполнилась, устанавливается флаг и появляется сообщение FIB TCAM exception. В результате этого новые маршруты перестают добавляться в TCAM. Все начинает коммутироваться программно. Удаление маршрутов не помогает опять вернуться к аппаратной коммутации. Если однажды TCAM войдет в состояние exception, система должна быть перегружена для того,чтобы вернуться в нормальное состояние. Если система вошла в состояние FIB TCAM

exception вы это сможете увидеть с помощью следующей команды:

6500-2#sh mls cef exception status Current IPv4 FIB exception state = TRUE Current IPv6 FIB exception state = FALSE Current MPLS FIB exception state = FALSE Если вы видите, что exception state имеет значение TRUE, значит FIB TCAM в состоянии exception .

Максимальное количество маршрутов, которые могут быть инсталлированы в TCAM, может быть увеличено с помощью команды mls cef maximum-routes .

Эта проблема обычно появляется при попытке использовать полную таблицу BGP на PFC-3A или PFC-3B .

**Обратите внимание, что переключение (failover) между супервизорами в системе с двумя супервизорами не устраняет эту проблему(exception), даже если команда “show mls cef exception status” больше не показывает FIB exception. Требуется полная перезагрузка системы .

ICMP redirects – Если трафик идет по неэффективному пути, в этом случае должно быть послано сообщение ICMP redirect, для того чтобы проинформировать отправителя о лучшем next-hop. Это приводит к тому, что пакеты передаются (punted) в CPU RP, для того чтобы заставить MSFC послать ICMP redirect отправителю. Это можно увидеть при захвате пакетов с помощью netdr. Пример использования netdr продемонстрирован в разделе “Инструменты для определения источника загрузки CPU ” .

Отключение icmp redirects останавливает передачу (punted) такого трафика в CPU RP. Однако, это является показателем неэффективности сети, которая пытается динамически быть исправлена. Необходимо взаимодействие с пользователем, чтобы определить эту неэффективность .

Если вам необходима помощь в определении почему генерируются пакеты ICMP redirect, пожалуйста откройте кейс в Центре Технической Поддержки (TAC) .

CEF Glean adjacency - Это наблюдается, когда не происходит ARP resolution для next hop (не определяется MAC адрес устройства, являющегося next-hop). В таком случае все пакеты должны быть переданы (punted) в CPU RP длятого чтобы послать запрос ARP для next hop. Это всегда проявляется как прерывание (interrupt), вызванное трафиком .

Для того, чтобы защитить CPU RP от этой проблемы, необходимо настроить Glean adj. mls rate-limiter .

(http://cco.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/gui de/dos.html#wpmkr1141161) Netflow и ACL сконфигурированы на одном и тоже интерфейсе проверяющие один и тот же трафик – Нельзя использовать механизмы на основе ACL и механизмы на основе Flow на одном и том же интерфейсе для одного и того же трафика. Примером является использование NAT и PBR, сконфигурированные на одном и том же интерфейсе для одного и того же трафика .

NAT использует netflow, так как первый пакет каждого потока должен быть передан в CPU RP для создания аппаратной (in hardware) записи netflow. Если запись netflow создана, то все последующие пакеты попадают под действие этой аппаратной записи и обрабатываются аппаратно (in hardware) .

Policy-Based Routing использует ACL. Создается запись “policy-route”Ю когда конфигурируется route-map для использования PBR и применяется к интерфейсу. Это указывает не специальное соседство, которое находится там, куда указывает запись “set” в route-map .

Проблема проявляется, когда пакет совпадает одновременно с правилами NAT и PBR, трафик не может быть послан Netflow в CPU и перенаправлен специальному соседу по правилам PBR, и таким образом трафик обрабатывается программно. Если эти два механизма перекрываются, то трафик обрабатывается программно, а не аппаратно. When this occurs neither feature may be applied to the matching traffic .

Если пакет не совпадает одновременно с критериями на основе ACL и Netflow, то релевантная функция (на основе ACL или Netflow) будет выполняться аппаратно .

Следовательно, для правильной производительности на аппаратном уровне в ситауации, когда механизмы на основе ACL и Netflow сконфигурированы на одном и том же интерфейсе, очень важно иметь уникальные политики .

Чтобы избежать данной проблемы, не конфигурируйте механизмы на основе ACL и Netflow на одном и том же интерфейсе, проверяющие один и тот же трафик .

Вы можете получить дополнительную информацию по траблшутингу конфликтов механизмов перейдя по следующей ссылке:

https://supportforums.cisco.com/docs/DOC-15670 Directed Broadcast traffic – Весь широковещательный (broadcast) трафик vlan’а должен быть направлен в MSFC, когда интерфейс 3 уровня (сетевого) сконфигурирован внутри этого vlan. Это относится и к направленному широковещательному (directed broadcast) трафику. Нужно использовать групповую (multicast) рассылку вместо широковещательного (broadcast) .

Bridging loop – Если наблюдается bridging loop в сети, то это может стать причиной высокой загрузки CPU на MSFC. Весь широковещательный (broadcast) трафик vlan’а должен быть направлен в MSFC, когда интерфейс 3 уровня (сетевого) сконфигурирован внутри этого vlan .

Вы можете определить какой трафик обрабатывается CPU с помощью механизма захвата пакетов netdr, для выяснения интерфеса на котором создается петля (loop ) (Подробнее в разделе Использование Netdr для определения трафика, попадающего в CPU) .

Туннель GRE с неуникальным источником (source) – На супервизоре sup720, начало (source) туннеля должно быть уникальным для каждого из туннелей .

Трафик туннелей с неуникальным IP адресов источника (source) будет отбрабатываться программно. Исправить эту ситуацию можно с помощью использования уникальных интерфейсов loopback для каждого туннеля GRE или использования дополнительных (secondary) адресов на интерфейсах loopback в качестве начала (source) туннеля. Для получения дополнительной информации смотрите CSCdy72539 .

При этом можно также увидеть следующую ошибку:

%Warning: Using same source IP for more than one IP/GRE tunnels may cause software switching packets for tunnels using this address. If possible, use a unique tunnel source for Interface Tunnel tun# (%Внимание: использование того же самого IP адреса источника для более чем одного туннеля IP/GRE может вызвать обработку пакетов программым образом для туннелей, использующих этот адрес. По возможности используйте уникальные адреса источника для интерейсов Tunnel tun#)

Другие неподдерживаемые механизмы на супервизоре Sup720-PFC3:

Следующие механизмы /типы трафика не поддерживаются 6500 и вызывают высокую загрузку CPU, если настроены:

**Обратите внимание, что это не полный список и неподдерживаемые механизмы могут быть не перечислены ниже .

NBAR Трафик с установленным полем IP options .

Мультикаст RPF дропы RSVP (INTSERV QOS) *может быть использован для туннелей CEF экаунтинг Мультикаст трафик и NAT – см.

CSCek78254 Следующий линк дает более полный список неподдерживающихся механизмов и команд для sup720-PFC3:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/f eatures.html#wp3691673

Инструменты, используемые для определения источника загрузки CPU:

Определение источника загрузки CPU RPс помощью буферов интерфейса:

*Обратите внимание* вы сможете видеть трафик в буферах интерейсов 3 уровня, если он обрабатывается процессами (processed switched) (смотрите выше раздел “Определение типов загрузки CPU ”). Метод не будет работать когда трафик обрабатывается прерываниями (interrupt switched). Чтобы проанализировать трафик, обрабатываемый прерываниями, нужно использовать захват пакетов с помощью механизма netdr .

Один из самых быстрых способов определения интерфейса 3 уровня, который является источником трафика, вызывающего высокую нагрузку на CPU это посмотреть какой из интерфейсов имеет большое количество отброшенных пакетов (drops, flushes) во входной очереди интерфейса. Входная очередь для интерфейса 3 уровня это очередь CPU для этого интерфейса на супервизоре sup720. Это всегда относится к трафику, который посылается напрямую в CPU.

Вы можете получить список таких интерфейсов с помощью следующей команды:

6500-2#show interface | include is up|drop Vlan10 is up, line protocol is up Input queue: 74/75/18063/18063 (size/max/drops/flushes); Total output drops: 0 Vlan20 is up, line protocol is up Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 В этом примере мы видим, что интерфейс SVI (Switched Virtual Interface) 10 содержит 74 пактов в буфере, при этом максимальный размер буфера равен 75 пакетам. Это показывает, что большое количество трафика попадает (punted) с этого интерфейса в RP CPU, так как эта очередь заполнена .

Так как мы видим большое количество трафика в этой очереди, мы можем посмотреть что содержится в этой очереди с помощью команды "show buffers input-interface vlan 10 header". Эта команда покажет IP заголовок пакета, в котором мы можем определить отправителя (source). Если мы хотим проанализировать целиком пакет, то это можно сделать с помощью команды "show buffers input-interface vlan 10 packet" .

Ниже показан примеры вывода этих команд для SVI 10

6500-2#sh buffers input-interface vlan 10 header Buffer information for Small buffer at 0x4667A08C data_area 0x802F664, refcount 1, next 0x466AE968, flags 0x200 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x530D5048 (Vlan10), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x802F6DA, datagramsize 60, maximum size 308 mac_start 0x802F6DA, addr_start 0x802F6DA, info_start 0x0 network_start 0x802F6E8, transport_start 0x802F6FC, caller_pc 0x41F78790 source: 10.10.10.2, destination: 10.100.101.10, id: 0x0000, ttl: 1, TOS: 0 prot: 6, source port 0, destination port 0 Выше мы можем видеть основную информацию об этом трафике, которая находится в заголовке пакета IP, включая значние полей TOS, TTL и инкапсуляцию протоколов .

Если мы видим целиком пакет, то можем проанализировать гораздо больше информации, включая информацию канального уровня, как показано ниже:

6500-2#sh buffers input-interface vlan 10 packet Buffer information for Small buffer at 0x466A23B0 data_area 0x80340A4, refcount 1, next 0x466E991C, flags 0x200 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x52836BE4 (Vlan10), if_output 0x0 (None) inputtime 16:32:10 .

292 (elapsed 00:00:50.608) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x803411A, datagramsize 60, maximum size 308 mac_start 0x803411A, addr_start 0x803411A, info_start 0x0 network_start 0x8034128, transport_start 0x0, caller_pc 0x41F78790 source: 10.10.10.2, destination: 10.100.101.10, id: 0x0000, ttl: 1, TOS: 0 prot: 6, source port 0, destination port 0 0: 0015C726 FB800000 01000600 08004500..G&{.........E .

16: 002E0000 00000106 36510A0A 0A020A64........6Q.....d 32: 650A0000 00000000 00000000 00005000 e.............P .

48: 0000265C 00000001 02030405 FD..&\........} Red = Dest MAC Blue = Source MAC Green = Ethertype (0x800 for IP traffic) Purple = Src. IP Orange = Dest IP С помощью команды “show ip traffic” мы можем увидеть какой трафик передается в CPU (punted):

6500-2#show interface | i is up|drop Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Vlan10 is up, line protocol is up Input queue: 74/75/18063/18063 (size/max/drops/flushes); Total output drops: 0 Vlan20 is up, line protocol is up SVI 10/Интерфейс Vlan 10 получает большое количество трафика, который передается (punted) в RP CPU. Мы можем посмотреть, что находится в этой очереди с помощью команды "show buffers input-interface vlan 10 header" .

Ниже показан вывод этой команды для SVI 10 6500-2#sh buffers input-interface vlan 10 header Buffer information for Small buffer at 0x4667A08C data_area 0x802F664, refcount 1, next 0x466AE968, flags 0x200 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x530D5048 (Vlan10), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x802F6DA, datagramsize 60, maximum size 308 mac_start 0x802F6DA, addr_start 0x802F6DA, info_start 0x0 network_start 0x802F6E8, transport_start 0x802F6FC, caller_pc 0x41F78790 source: 10.10.10.2, destination: 10.100.101.10, id: 0x0000, ttl: 1, TOS: 0 prot: 6, source port 0, destination port 0 Buffer information for Small buffer at 0x4667C7E8 data_area 0x80314A4, refcount 1, next 0x46695FD0, flags 0x200 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x530D5048 (Vlan10), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x803151A, datagramsize 60, maximum size 308 mac_start 0x803151A, addr_start 0x803151A, info_start 0x0 network_start 0x8031528, transport_start 0x803153C, caller_pc 0x41F78790

source: 10.10.10.1, destination: 10.10.10.2, id: 0xD096, ttl: 255, prot: 1

Если на этом этапе мы не уверены какой именно трафик будет передаваться в CPU(punted), мы можем проанализировать статистику получаемую с помощью команды “show ip traffic" для того чтобы понять какой трафик передается (punted) в CPU. Вначале нужно очистить статистику для трафика IP.

Далее нам нужно следить какие именно счетчики увеличиваются для понимания причины:

6500-2#clear ip traffic Clear "show ip traffic" counters [confirm] 6500-2#sh ip traffic

IP statistics:

Rcvd: 33516 total, 0 local destination 0 format errors, 0 checksum errors, 33516 bad hop count ------Здесь мы видим, что увеличивается сетчик bad Hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options Opts: 0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route 0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump 0 other Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 couldn't fragment Bcast: 0 received, 0 sent Mcast: 0 received, 0 sent Sent: 0 generated, 0 forwarded Drop: 40005 encapsulation failed, 0 unresolved, 0 no adjacency 0 no route, 0 unicast RPF, 0 forced drop 0 options denied, 0 source IP address zero

ICMP statistics:

Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0 unreachable 0 echo, 0 echo reply, 0 mask requests, 0 mask replies, 0 quench 0 parameter, 0 timestamp, 0 info request, 0 other 0 irdp solicitations, 0 irdp advertisements 0 time exceeded, 0 timestamp replies, 0 info replies Sent: 0 redirects, 0 unreachable, 0 echo, 0 echo reply 0 mask requests, 0 mask replies, 0 quench, 0 timestamp 0 info reply, 58464 time exceeded, 0 parameter problem ---- Также мы видим, что 6500 посылает сообщения ICMP о том, что закончилось время жизни (TTL) пакета .

0 irdp solicitations, 0 irdp advertisements snip Глядя на статистику трафика мы видим, что увеличивается счетчик «bad hop count» и коммутатор посылает сообщения ICMP, что закончилось время жизни пакета .

На 6500 весь трафик с TTL раным 1 передается (punted) в CPU и посылается сообщение ICMP о том что закончилось время жизни пакета (TTL expired message) тому устройству, которое прислало этот пакет .

Также, видно, что первый пакет в буфере имеет TTL равный 1, который объясняет почему трафик передается (punted) в CPU. Мы видим, что второй пакет с адресом отправителя 10.10.10.1 (SVI 10) посылается на адрес 10.10.10.2 .

Этот пакет содержит сообщение ICMP TTL expired message .

Использование Netdr для определения трафика, передаваемого в CPU:

Захват пакетов с помощью netdr выполняется контроллером MSFC CPU. Это самое близкое место, в котором вы можете захватить пакеты на MSFC для того чтобы определить какой трафик передается (punted) в MSFC/RP CPU. Для супервизоров Sup720 и Sup32 имеется возможность захватывать пакеты, идущие в RP или SP. Команда netdr может быть использована для захвата пакетов, передаваемых в обоих направлениях (Tx и Rx) при программной обработке (software-switching) .

–  –  –

При использовании опции «continuous» коммутатор будет непрерывно захватывать (capture) пакеты передаваемые в RP пока не будет заполнен весь буфер захвата (4096 пакетов), а затем начнет перезаписывать буфер по правилу FIFO (взамен захваченных первыми) .

Опции «tx» и «rx» позволяют захватить пакеты идущие из MSFC и в MSFC соответственно .

Опции «and-filter» и «or-filter» определяет какой оператор «и» или «или»

будет соответственно применен ко всем опциям, которые следуют далее .

Например, если вы будете использовать синтаксис «debug netdr and-filter option#1 option#2», то оба параметра option #1 и option #2 должны встречаться в пакетах, которые захватываются. Соответсвенно, если используется «or-filter» достаточно наличие одного параметра option #1 или option #2, для того чтобы пакет был захвачен .

Опция «interface» используется для захвата пакетов, идущих в или из указанного интерфейса. В качестве интерфейса можно указывать SVI или интерфейс третьего уровня (L3) на коммутаторе .

Опция «vlan» используется для того чтобы захватить все пакеты определенного VLAN. В качестве номера VLAN можно также указать один из внутренних (internal) VLANов, ассоциированных с интерфейсом третьего уровня (L3 interface) .

Опции «srcindex» и «dstindex» используются для захвата всех пакетов, совпадающих соответственно с индексами source ltl и destination ltl .

Обратите внимание, что опция «interface», рассмотренная выше позволяет захватывать пакеты идущие в или из интерфейсов третьего уровня (L3) (SVI или физического). С помощью опций «srcindex» или «dstindex» можно захватить пакеты Tx или Rx на определенном интерфейсе второго уровня (L2). Опции «srcindex» и «dstindex» можно использовать с индексами интерфейсов второго (L2) или третьего (L3) уровня .

Опция «ethertype» позволяет захватывать все пакеты, совпадающие с типом, определенным «ethertype» .

Опции «source-ip-address» и «destination-ip-address» позволяют захватывать все пакеты совпадающие соответственно с определенным IP адресом отправителя или получателя .

Ниже показан пример захвата трафика, идущего на адрес 10.100.101.10, отправленный адресом 10.10.10.2, идущий в RP CPU:

6500-2#debug netdr cap rx and-filter source-ip-address 10.10.10.2 destination-ipaddress 10.100.101.10 6500-2#sh netdr cap A total of 4096 packets have been captured The capture buffer wrapped 0 times Total capture capacity: 4096 packets

------- dump of incoming inband packet ------interface Vl10, routine mistral_process_rx_packet_inlin, timestamp 00:00:11 dbus info: src_vlan 0xA(10), src_indx 0xC0(192), len 0x40(64) bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896) 10020400 000A0000 00C00000 40080000 00060468 0E000040 00000000 03800000 mistral hdr: req_token 0x0(0), src_index 0xC0(192), rx_offset 0x76(118) requeue 0, obl_pkt 0, vlan 0xA(10) destmac 00.15.C7.26.FB.80, srcmac 00.00.01.00.06.00, protocol 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 46, identifier 0 df 0, mf 0, fo 0, ttl 100, src 10.10.10.2, dst 10.100.101.10 tcp src 0, dst 0, seq 0, ack 0, win 0 off 5 checksum 0x265C Red = Входящий Vlan трафика Blue = Интерфейс третьего уровня с которого идет трафик Green = Ethertype и МАСадреса отправителя и получателя Purple = IP заголовок Orange = SRC индекс (отправитель входящего трафика) .

Dark Red = Dest индекс (куда трафик будет посылаться) .

Вы можете использовать выяснить кто является источником трафика, который передается в CPU и вызывает его высокую загрузку. Используйте документ Troubleshooting with a NETDR capture on a sup720/6500 для получения дополнительной информации как интерпретировать эти данные .

Также вы можете открыть сервисный запрос в Cisco TAC, если вам нужна помощь в интерпретации этих данных .

Использование CPU SPAN для определения трафика, обрабатываемого CPU Этот захват выполняется на ASIC, который подключен к RP/SP CPU. Это точно позволяет реплицировать на устройство, осуществляющее захват, трафик который посылается на RP или SP CPU. Это может помочь вручную определить какой трафик вызывает высокую загрузку CPU или определить какой трафик посылается к и от CPU для обработки (такой как HSRP/OSPF/PIM служебный (control plane) трафик) .

При использовании релиза 12.2(18)SXF или более ранних конфигурация для входящей span сессии выглядит следующим образом:

RP Console:

Router#monitor session 1-66 source|destination|filter interface|remote|vlan FastEthernet|GigabitEthernet|Port-channel|GE-WAN tx|rx|both

SP Console:

Router#remote login switch Router-sp#test monitor session 1-66 add|del|show rp-inband|sp-inband tx|rx|both

-ИлиRouter#remote login switch Router-sp#test monitor add|del| session: 1-66 rp-inband|sp-inband tx|rx|both Router-sp#test monitor session 1-66 show Начиная с релиза 12.2(33)SXH и в более поздних версиях можно использовать следующую конфигурацию для входящей SP-RP span сессии:

Router(config)# monitor session 1 type local Router(config-mon-local)# source cpu rp|sp tx|rx|both Router(config-mon-local)# destination interface gigabitethernet 1/2 Router(config-mon-local)# no shutdown

Для получения дополнительной информации воспользуйтесь ссылкой:

http://cco.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/gui de/span.html#wp1109488 После получения результатов работы span сессии можно определить МАС адрес и IP адрес устройства, которое является источником трафика, попадающего в CPU .

Траблшутинг всплесков (spikes) загрузки CPU .

Иногда невозможно определить причину всплеска загрузки CPU, так как сложно задать команду "show process CPU" в момент, когда происходит кратковременный всплекс загрузки CPU. Один из способов обойти это препятствие, это использование скриптов EEM для выполнения команд, когда загрузка CPU превышает определенное значение.

Следующий скрипт EEM выполнит команду "show process cpu sorted" когда загрузка CPU становится более 50%:

event manager scheduler script thread class default number 1 event manager applet High_CPU event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1 get-type exact entry-op ge entry-val 50 poll-interval 0.5 action 0.0 syslog msg "High CPU DETECTED. Please wait - logging Information to file system:high_cpu.txt" action 0.1 cli command "enable" action 0.2 cli command "show clock | append file system:high_cpu.txt" action 1.2 cli command "term length 0" action 1.3 cli command "show process cpu sorted | append file system:high_cpu.txt" Укажите вместо выражения file system название файловой системы, где будет сохраняться файл high_cpu.txt, например bootdisk .

Если вам нужна дополнительная помощь для определения причины высокой загрузки CPU, откройте пожалуйста сервисный запрос в Cisco TAC .

Оргинальный документ доступен по ссылке


Похожие работы:

«Ирина Перунова Коробок Москва "Воймега" УДК 821.161.1-1 Перунова ББК 84 (2Рос=Рус)6-5 П27 Художник серии: Сергей Труханов И. Перунова П27 Коробок. — М.: Воймега, 2014. — 100 с. ISBN 978-5-7640-0148-7 Книга выпущена при поддержке Рыбинского отделения Союза писателей Росии. © И. Перунова...»

«На грузовике по территории Финляндии Памятка водителя большегрузного автотранспортного средства l l ll l l ll l l На грузовике по территории Финляндии Памятка водителя большегрузного автотранспортного средства  Ответственные органы Министерство тран...»

«Господа! Я не специалист. Вот мнение специалиста. В В Ершов любезно согласился ответить на вопросы нашего форума. Отвечаю на вопросы. Экипаж был сформирован за несколько дней до полета в составе КВС, второго пилота, штурмана и бортинженера. Самостоятельный налет на Ту-154М в данной долж...»

«НЕМЕЦКИЕ УЧАСТНИКИ 8-го российско-германского Форума "Петербургский диалог" 30 сентября – 3 октября 2008 года Санкт-Петербург, Санкт-Петербургский государственный университет I. Политика Руководитель груп...»

«утилиты баз данных Утилиты для флэшек. Программы восстановления данных, создания загрузочных USB Flash Drive. Функции работы с полями баз данных включают в себя. поиск имени поля и его значения;. по...»

«50 УДК 681.32 ВИЗУАЛЬНОЕ ВЫДЕЛЕНИЕ ОСОБЫХ ТОЧЕК И ХАРАКТЕРНЫХ ЛИНИЙ ИЗЛОМОВ ИССЛЕДУЕМОЙ ПОВЕРХНОСТИ Клименко М.И., к.ф.-м.н., ст. преподаватель, Кондратьева Н.А., к.ф.-м.н., доцент, Мухин В.В., к.т.н, ст. преподаватель, Сологуб Ю.В., магистр, Чопоров С.В., ассистент Запорожский национальный университет В данной работе расс...»

«Annotation "Степной волк" — одно из самых популярных произведений Гессе. Он в известной мере автобиографичен. Это исповедь буржуазного интеллигента, пытающегося преодолеть собственную болезнь. Перевод с немецкого С. Апта...»

«Рабочая программа по учебному предмету "Окружающий мир" разработана на основании документов:1. Федерального государственного образовательного стандарта начального общего образования, утвержднного приказом МО и науки РФ №373 от 06.10.2009г с последующ...»








 
2018 www.new.pdfm.ru - «Бесплатная электронная библиотека - собрание документов»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.