Безопасность : Устройства защиты Cisco PIX серии 500

PIX/ASA: Наблюдение и устранение неполадок производительности

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (6 августа 2008) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

В этом документе описаны команды PIX/ASA, которые можно использовать для контроля и улучшения производительности устройств защиты Cisco PIX серии 500 и ASA 5500.

Примечание: Обратитесь к ASA 8.3 и Позже: Монитор и Проблемы производительности Устранения неполадок для подобного устранения проблем на устройстве адаптивной защиты Cisco (ASA) с версией 8.3 и позже.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Сведения в этом документе основываются на Версии 6.2 (1) программного обеспечения Cisco PIX Firewall и выше.

Примечание: Сведения в этом документе могут также использоваться с выполнением Устройства безопасности серии 5500 Cisco ASA 7.x и выше версии.

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

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Устранение неполадок

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

Примечание: Если у вас есть выходные данные команды показа от устройства Сisco, можно использовать Средство интерпретации выходных данных (только зарегистрированные клиенты), чтобы отобразить потенциальные проблемы и исправляете. Интерпретатор выходных данных (средство OIT) поддерживает некоторые команды show. Работа с программой Интерпретатор выходных данных возможна только для зарегистрированных пользователей после выполнения входа в учетную запись Cisco. Кроме того, необходимо установить и включить JavaScript в веб-браузере.

Настройка скорости и дуплексного режима

Устройство безопасности предварительно сконфигурировано для автоматического обнаружения параметров настройки скорости и дуплексного режима на интерфейсе. Тем не менее, в некоторых случаях не удается выполнить процесс автосогласования, что приводит к несоответствию скорости и дуплексного режима (и к снижению производительности). Для критически важной сетевой инфраструктуры, Cisco аппаратно программирует скорость и дуплексный режим на каждом интерфейсе, так что вероятность возникновения ошибок минимальна. Обычно эти устройства не перемещаются, поэтому если настроить их правильно изначально, в дальнейшем не будет необходимости их менять.

В любом сетевом устройстве скорость соединения может быть определена, в то время как дуплексный режим нужно согласовывать. Если два сетевых устройства настроены на автоматическое согласование скорости и дуплекса, они отправляют друг другу кадры (так называемые импульсы быстрого канала, FLP), которые объявляют их возможности скорости и дуплекса. Для неосведомленного партнера по каналу эти импульсы воспринимаются как обычные кадры со скоростью 10 Мбит/с. Для устройства, которое может декодировать импульсы, в FLP содержатся все параметры скорости и дуплекса, которые предоставляет партнер по каналу. Станция, получающая FLP, подтверждает кадры, после чего устройства взаимно соглашаются на установку предельных для обоих параметров скорости и дуплекса. Если одно из устройств не поддерживает автосогласование, другое устройство получает импульсы FLP и переходит в режим параллельного обнаружения. Чтобы определить скорость партнера, устройство "слушает" длину импульсов, а затем устанавливает соответствующую скорость. Проблема возникает при настройке дуплекса. Поскольку требуется согласование с дуплексом, устройство, на котором установлен режим автосогласования, не может определить настройки другого устройства, и оно устанавливает по умолчанию режим полудуплекса, как установлено стандартом IEEE 802.3u.

Например, если интерфейс PIX настроен на автосогласование и подключен к коммутатору в аппаратно заданном режиме полного дуплекса со скоростью 100 Мбит/с, то PIX отправляет импульсы FLP. Однако ответа от коммутатора не последует, т.к. режим дуплекса и параметры скорости для него жестко заданы на аппаратном уровне и он не принимает участия в согласовании. При отсутствии ответа от коммутатора PIX переходит в режим параллельного обнаружения и прослушивает длину импульсов в кадрах, которые отсылает коммутатор. Таким образом, PIX может определить, что для коммутатора установлена скорость 100 Мбит/с, и установить соответствующую скорость интерфейса. Поскольку коммутатор не обменивается импульсами FLP, PIX не может определить, в каком дуплексном режиме работает коммутатор, поэтому он переходит из дуплексного режима в полудуплексный, как установлено стандартом IEEE 803.2u. Коммутатор аппаратно запрограммирован на скорость 100 Мбит/с и дуплексный режим, тогда как PIX выполнил автосогласование со скоростью 100 Мбит/с для полудуплексного режима (как и должен был), в результате возникает несоответствие дуплексных режимов, что может оказать негативное влияние на производительность.

Несоответствие скорости или дуплекса часто обнаруживается через повышение значений счетчиков ошибок в данных интерфейсах. Наиболее распространенными ошибками являются ошибки кадров, контроля циклическим избыточным кодом (CRC) и карликовых пакетов (с недопустимо малой величиной). Эти значения на интерфейсе увеличиваются из-за несогласованности параметров дуплекса и скорости или проблем с кабелем. Чтобы продолжить, необходимо устранить эту проблему.

Пример

interface ethernet0 "outside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 00d0.b78f.d579
  IP address 192.168.1.1, subnet mask 255.255.255.0
  MTU 1500 bytes, BW 100000 Kbit half duplex
        7594 packets input, 2683406 bytes, 0 no buffer
        Received 83 broadcasts, 153 runts, 0 giants
        378 input errors, 106 CRC, 272 frame, 0 overrun, 0 ignored, 0 abort
        2997 packets output, 817123 bytes, 0 underruns
        0 output errors, 251 collisions, 0 interface resets
        0 babbles, 150 late collisions, 110 deferred

Нагрузка на CPU

Если наблюдается высокая загрузка CPU, необходимо выполнить следующие действия:

  1. Убедитесь что значение счетчика подключений в show xlate count невелико.

  2. Убедитесь, что блок памяти функционирует нормально.

  3. Проверьте, что количество ACL выше.

  4. Выполните команду show memory detail, чтобы проверить загрузку памяти, используемой PIX.

  5. Убедитесь, что значения счетчиков в show processes cpu-hog и show processes memory соответствуют норме.

  6. Любой хост как перед устройством защиты, так и за ним может создавать вредоносный или избыточный трафик, который может быть связан с широковещательной рассылкой и групповой адресацией и вызывать высокий коэффициент загрузки ЦП. Чтобы решить эту проблему, необходимо настроить список доступа для запрета трафика между хостами (сквозного) и проверить нагрузку.

  7. Проверьте параметры скорости и дуплекса в интерфейсах PIX. Несоответствие параметров удаленных интерфейсов может быть причиной повышенной загрузки CPU.

    На данном примере показана ситуация, возникающая при несоответствии параметров скорости, что выражается в повышенном количестве входных ошибок и перегрузок. Для определения ошибок используйте команду show interface:

    pix#show int e1 
    interface ethernet1 "inside" is up, line protocol is up
      Hardware is i82559 ethernet, address is 0050.54ff.d053
      IP address 172.16.1.5, subnet mask 255.255.255.0
      MTU 1500 bytes, BW 100000 Kbit full duplex
            154755357 packets input, 3132291269 bytes, 0 no buffer
            Received 5352738 broadcasts, 0 runts, 0 giants
            7182 input errors, 0 CRC, 0 frame, 7182 overrun, 0 ignored, 0 abort
            2595913856 packets output, 3842928626 bytes, 0 underruns
            0 output errors, 0 collisions, 0 interface resets
            0 babbles, 0 late collisions, 0 deferred
    

    Чтобы решить проблему, установите параметр скорости на auto (автоматически) в соответствующем интерфейсе.

    Примечание: Cisco рекомендует включить команду ip verify reverse-path interface на всех интерфейсах, поскольку это отбросит пакеты, которые не сделали, чтобы допустимый источник обратился, который приводит к меньшему количеству использования ЦПУ. Это применяется к FWSM, сталкивающемуся с проблемами высокой загрузки CPU.

  8. ,Другой причиной высокой загрузки ЦП может быть слишком большое количество маршрутов групповой адресации. Чтобы определить, не слишком ли много многоадресных маршрутов, получаемых PIX/ASA, используйте команду show mroute.

  9. Для получения сведений о случаях DoS-атак ("отказ в обслуживании") в сети, которые могут свидетельствовать о вирусной атаке, используйте команду show local-host.

    Примечание: Когда nameif/уровень безопасности изменился для нового интерфейса (только зарегистрированные клиенты), действие Высокой загрузки CPU могло бы произойти из-за проблемы, описанной в Высокой загрузке CPU. Обратитесь к идентификатору ошибки Cisco CSCsq48636 (только зарегистрированные клиенты) для получения дополнительной информации.

Примечание: Если решение, предоставленное выше, не решает вопрос, обновите платформу ASA согласно требованиям. Сошлитесь на Таблицу данных многофункциональных устройств защиты Cisco ASA серии 5500 для получения дополнительной информации о возможностях и мощностях Платформы Устройства адаптивной безопасности. Свяжитесь с TAC (только зарегистрированные клиенты) для получения дополнительной информации.

Высокая загрузка памяти

Ниже приводятся возможные причины высокой загрузки памяти и некоторые решения этой проблемы:

  • Регистрация событий: Регистрация событий может задействовать значительные ресурсы памяти. Чтобы избежать этой проблемы, выполняйте установку и регистрацию всех событий на внешнем сервере, например, на сервере системного журнала.

  • Утечка памяти: Известная проблема ПО устройства защиты, приводящая к интенсивному использованию ресурсов памяти. Для решения этой проблемы требуется обновить ПО устройства защиты.

  • Включение режима отладки: При включенном режиме отладки задействуются большие ресурсы памяти. Чтобы отключить режим отладки, используйте команду undebug all.

  • Блокирующие порты: Блокирующие порты на внешнем интерфейсе устройства безопасности заставляют устройство безопасности использовать большие значения памяти для блокирования пакетов через указанные порты. Для решения этого вопроса заблокируйте недопустимый трафик в конце интернет-провайдера.

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

Режимы PortFast, Channeling и Trunking

Во многих коммутаторах, в частности, в коммутаторах Cisco с операционной системой Catalyst (OS), предусмотрена функция автообнаружения и самонастройки (plug-and-play). Поэтому многие параметры портов, задаваемые по умолчанию, требуется изменить при подключении PIX к коммутатору. Например, на коммутаторах с ОС Catalyst включение channeling (объединения каналов) и trunking (магистрального соединения) включается автоматически (Auto), а режим PortFast отключен. Таким образом, при подключении PIX к коммутатору с ОС Catalyst, необходимо отключить объединение каналов и магистральное соединение и включить PortFast.

Режим объединения каналов, называемый также Fast EtherChannel или Giga EtherChannel, используется для объединения двух или нескольких физических портов в логическую группу для увеличения объема потока данных по каналу. Если порт настроен на автоматическое объединение каналов, он отправляет кадры по протоколу агрегации портов (Port Aggregation Protocol, PAgP) как только канал становится активным, чтобы определить, участвует ли он в объединении каналов. Эти PAgP-кадры могут стать источником проблем в случае, если другое устройство выполняет в это время автоматическое согласование скорости и дуплекса на данном канале. Если на порте установлено автоматическое объединение каналов, это может вызвать трехсекундную задержку передачи трафика через данный порт после включения канала.

Примечание: На Коммутаторах серии Catalyst XL канализирование является "not set" к Автоматическому по умолчанию. Поэтому необходимо отключить объединение каналов на любом порте, который подключен к PIX.

Магистральное соединение, которое относится к общим протоколам магистральных каналов (другое название — межкоммутаторное соединение (ISL) или Dot1q) объединяет несколько сетей VLAN на одиночном порту (или канале). Транкинг обычно используется между двумя коммутаторами, когда оба коммутатора имеют более одной назначенной VLAN. Если порт настроен на автоматическое магистральное соединение, он рассылает кадры протокола динамического магистрального соединения (DTP; Dynamic Trunking Protocol) при включении канала, чтобы определить, нужно ли порту, к которому он подключается, группировать магистрали. Данные кадры DTP могут вызвать проблемы автосогласования канала. Если на порте установлено автоматическое магистральное соединение, это вызывает 15-секундную задержку передачи трафика через данный порт после включения канала.

Режим PortFast, также называемый Fast Start, — это функция, которая сообщает коммутатору о подключении устройства уровня 3 из порта коммутатора. В этом случае 30-секундное ожидание порта (15 секунд на "прослушивание" и 15 — на "обучение"), заданное по умолчанию, отменяется, а порт переводится в состояние передачи немедленно после включения канала. Важно иметь ввиду, что при включении режима PortFast связующее дерево не отключается. Оно остается активным на данном порту. При включении PortFast коммутатор лишь получает сведения о том, что на другом конце канала нет подключенных коммутаторов или концентраторов (т.е. устройств только уровня 2). Коммутатор обходит обычную 30-секундную задержку, одновременно пытаясь определить, возникнет ли в результате активации этого порта петля на втором уровне. После активации канала он все равно представлен в связующем дереве. Элементы BPDU будут отправляться с порта, а коммутатор будет продолжать прослушивать данный порт на наличие BPDU. Из этих соображений рекомендуется включить PortFast для любого порта коммутатора, подключаемого к PIX.

Примечание: Релизы операционной системы Catalyst 5.4 и позже включают <mod> set port host / команда <port>, которая позволяет вам использовать одиночную команду, чтобы отключить канализирование, отключить транкинг и включить PortFast.

Network Address Translation (NAT)

Все сеансы подключения через систему безопасности подвергаются трансляции сетевых адресов определенного характера (NAT). Каждый сеанс NAT или перегрузки NAT (PAT) назначается на слот трансляции, называемый xlate. Эти xlate-слоты могут сохраняться даже после изменения правил NAT по отношению к ним. Это приводит к истощению слотов трансляции или непредсказуемому поведению трафика, который подвергается трансляции, или к обоим последствиям. В данном разделе поясняется, как просмотреть и удалить xlate-слоты в устройстве защиты.

Примечание: Всегда clear xlate после добавления изменяются или удаляют команды aaa-server, access-list, alias, global, nat, route, or static в конфигурации.

caution  Внимание:  При глобальном удалении xlate-слотов в системе безопасности возможно кратковременное прерывание потока всего трафика в устройстве.

Пример конфигурации PIX для PAT, которые используют IP-адрес внешнего интерфейса:

global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0

Трафик, передаваемый через устройство защиты, почти всегда подвергается NAT. Просмотреть трансляции, используемые в устройстве защиты, можно с помощью команды show xlate:

pix#show xlate
1 in use, 1 most used
PAT Global 192.168.1.2(1) Local 10.2.2.2 ICMP id 21
pix#show xlate detail
1 in use, 1 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
ICMP PAT from inside:10.2.2.2/22 to outside:192.168.1.2/2 flags ri

Слоты трансляции могут сохраняться даже после ключевых изменений. Чтобы удалить слоты текущей трансляции в устройстве защиты, используйте команду clear xlate:

pix#clear xlate
pix#show xlate
0 in use, 1 most used

Команда clear xlate удаляет всю текущую динамическую трансляцию в таблице xlate-слота. Чтобы удалить определенную IP-трансляцию, используйте команду clear xlate с ключевым словом global [ip-адрес].

Ниже приведен пример конфигурации PIX для NAT:

global (outside) 1 10.10.10.10-10.10.10.100
nat (inside) 1 0.0.0.0 0.0.0.0

Просмотрите выходные данные show xlate для трансляции с внутреннего 10.2.2.2 на глобальный внешний 10.10.10.10:

pixfirewall#show xlate detail
2 in use, 2 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from inside:10.2.2.2 to outside:10.10.10.10 flags i
NAT from inside:10.5.5.5 to outside:10.10.10.11 flags i

Удалите трансляцию для глобального IP-адреса 10.10.10.10:

pixfirewall# clear xlate global 10.10.10.10

В данном примере трансляция для IP-адресов от внутреннего 10.2.2.2 до внешнего глобального 10.10.10.10 удалена:

pixfirewall#show xlate detail
1 in use, 2 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from inside:10.5.5.5 to outside:10.10.10.11 flags i

При удалении слотов трансляции обратите внимание на трансляции другого типа:

  • Static (статический) xlate — это постоянный xlate, который создается с помощью команды static. Чтобы удалить статические xlate-слоты, необходимо удалить команду static из конфигурации. Команда clear xlate не удаляет правило статической трансляции. При удалении команды static в конфигурации, возможно сохранение передачи трафика по соединениям, созданным ранее и использующим правило статической трансляции. Чтобы деактивировать эти соединения, используйте команду clear local-host.

  • Dynamic (динамический) xlate — это xlate, созданный по требованию с функцией обработки трафика (доступной с помощью команд nat или global). Команда clear xlate удаляет динамические xlate-слоты и связанные с ними соединения. При удалении команды nat или global, динамический xlate-слот и связанные с ним соединения могут оставаться активными.

Системные журналы

С помощью системных журналов выполняется устранение проблем PIX. Cisco предоставляет бесплатный сервер системных журналов для Windows NT, называемый сервер системного журнала межсетевого экрана PIX (PIX Firewall Syslog Server, PFSS). Загрузить PFSS можно на странице Software Downloads (только для зарегистрированных пользователей).

Другие поставщики ПО, такие как Kiwi Enterprises, предлагают серверы системных журналов для других платформ Windows, например, Windows 2000 и Windows XP. leavingcisco.comВ большинстве компьютеров с ОС UNIX или Linux серверы системных журналов установлены по умолчанию.

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

Например: :

logging on
logging host <ip_address_of_syslog_server>
logging trap debugging

Примечание: Данный пример настраивает PIX для передачи Отладки (уровень 7) и больше важных системных журналов к серверу системного журнала. Поскольку эти записи журнала PIX очень подробны, используйте их только для устранения проблем. Для обычной работы настройте уровень регистрации на "Предупреждение" (уровень 4) или "Ошибка" (уровень 3).

При снижении производительности откройте системный журнал в текстовом файле и выполните поиск IP-адреса источника, связанного с данной проблемой производительности. (При работе в ОС UNIX используйте grep для поиска IP-адреса источника.). Проверьте сообщения, в которых зафиксированы попытки внешнего сервера получить доступ к внутреннему IP-адресу на TCP-порту 113 (для протокола идентификации, Ident), однако PIX не принял пакеты. Это сообщение должно выглядеть примерно так:

%PIX-2-106001: Inbound TCP connection denied from 
10.64.10.2/35969 to 172.17.110.179/113 flags SYN

При получении такого сообщения выполните команду service reset inbound для PIX. PIX не отбрасывает пакеты незаметно; вместо этого команда заставляет PIX выполнить немедленную перезагрузку любого входящего соединения, которое было запрещено политикой безопасности. В данной ситуации сервер не будет ожидать пакет Ident, чтобы прервать TCP-соединение, он получит пакет перезагрузки сразу же. Дополнительные сведения о PIX и Ident см. в разделе Снижение производительности PIX из-за проблем с протоколом IDENT.

Обратный поиск DNS

В случае низкой производительности PIX убедитесь, что на доверенном DNS-сервере есть записи указателя системы доменных имен (DNS PTR), называемые записями обратного поиска DNS, для внешних адресов, используемых PIX. В этом случае также имеются ввиду любые адреса в глобальном пуле трансляции сетевых адресов (Network Address Translation, NAT) (или внешнем интерфейсе PIX, если интерфейс перегружен), любые статические адреса и внутренние адреса (если они не используются вместе с NAT). Некоторые приложения, например, серверы протокола передачи файлов (File Transfer Protocol, FTP) и серверы Telnet, могут использовать обратный поиск DNS, чтобы определить, откуда пользователь вошел в сеть и является ли он допустимым узлом. Если проблему не удалось решить с помощью обратного поиска DNS, то вероятная причина падения производительности — превышение времени ожидания запроса.

Чтобы убедиться в том, что на этих хостах имеется запись PTR, выполните команду nslookup на ПК или компьютере с ОС UNIX, включив в поиск глобальный IP-адрес, который используется для подключения к Интернету.

Пример

% nslookup 198.133.219.25
25.219.133.198.in-addr.arpa     name = www.cisco.com.

После чего будет получен ответ, содержащий DNS-имя устройства, назначенного на данный IP-адрес. Если ответа получено не было, обратитесь к специалисту, ответственному за DNS, чтобы получить дополнительные записи PTR для каждого глобального IP-адреса. Дополнительные сведения о проблемах производительности PIX из-за утраты записей PTR см. в разделе Низкая или неустойчивая производительность FTP/HTTP через PIX.

Переполнения на интерфейсе

Если у вас есть всплеск трафика, отброшенные пакеты могут произойти, если пакет превышает емкость буферизации буфера FIFO на NIC и буферах кольца приема. Включение фреймов паузы для управления потоками может облегчить эту проблему. Пауза (XOFF) и кадры XON генерируются автоматически аппаратными средствами NIC на основе использования буфера FIFO. Когда использование буфера превышает наибольшее возможное значение, фрейм паузы передается. Для включения паузы (XOFF) кадры для управления потоками используйте следующую команду:

hostname(config)#interface tengigabitethernet 1/0
hostname(config-if)# flowcontrol send on

Обратитесь к Включению Физического интерфейса и Параметров Ethernet Настройки для получения дополнительной информации.

команды "show"

show cpu usage

Команда show cpu usage впервые была представлена в PIX 6.0(1) и использовалась для определения нагрузки от трафика на CPU данного PIX. Во время пиковой нагрузки, переполнения сети или атак, наблюдаются резкий кратковременный скачок загрузки CPU.

В PIX имеется один CPU для выполнения множества задач, например, для обработки пакетов и печати сообщений отладки на консоли. У каждого процесса есть своя цель и некоторые из них требуют больше времени CPU для выполнения, чем другие. Шифрование, вероятно, самый ресурсоемкий процесс, задействующий CPU, поэтому если PIX пропускает большой объем трафика по зашифрованным туннелям, необходимо увеличить скорость PIX с помощью установки платы ускорителя VPN (VAC) [Part # PIX-VPN-ACCEL] для PIX или специального концентратора VPN, например, VPN 3000. Плата VAC снимает нагрузку с PIX CPU при шифровании и дешифровании и обеспечивает выполнение этих процессов аппаратно. Это позволяет PIX выполнять шифрование и дешифрование трафика с 3DES (168-битным шифрованием) со скоростью 100 Мбит/с.

Регистрация – это еще один процесс, который может потреблять большой объем системных ресурсов. Поэтому рекомендуется отключить в PIX консоль, слежение и буфер регистрации. Эти процессы можно запустить при устранении неполадок, однако при выполнении обычных операций, особенно если ресурсы CPU недостаточны, их лучше отключать. Также следует установить уровень 5 (Уведомление) или ниже для регистрации в системном журнале или регистрации простого протокола управления сетью (Simple Network Management Protocol, SNMP) (истории регистраций). В дополнение можно отключить особые идентификаторы сообщений системного журнала с помощью команды no logging message <идентификатор_системного_журнала>.

На вкладке Monitoring диспетчер устройств PIX (PDM) также предоставляет график, что позволяет отслеживать загрузку CPU PIX во времени. Данный график используется для определения загрузки PIX.

Команда show cpu usage служит для отображения статистики использования CPU.

Пример

pixfirewall#show cpu usage

CPU utilization for 5 seconds = 1%; 1 minute: 2%; 5 minutes: 1%

Описание выходных данных

В данной таблице приводится описание полей выходных данных команды show cpu usage.

Поле Описание
Загрузка CPU за 5 секунд Уровень загрузки CPU за последние 5 секунд
1 минута Средняя загрузка CPU по 5-секундным периодам за последнюю минуту
5 минут Среднее значение для 5-секундных замеров использования CPU за последние пять минут

show traffic

Команда show traffic показывает, какое количество трафика проходит через PIX за определенный период времени. Результат подсчитывается за время, прошедшее с момента последнего выполнения данной команды. Чтобы получить точный результат, выполните команду clear traffic, а затем подождите 1-10 минут перед тем, как выполнить команду show traffic. Также можно выполнить команду show traffic дважды с интервалом в 1-10 минут, однако достоверными, в этом случае, будут выходные данные второго выполнения команды.

Команду show traffic можно использовать для определения объема трафика, проходящего через PIX. При наличии нескольких интерфейсов с помощью этой команды можно определить, какой из интерфейсов отправляет и получает больше всего данных. Для PIX с двумя интерфейсами суммарный входящий и исходящий трафик на внешнем интерфейсе должен быть эквивалентен суммарному входящему и исходящему трафику на внутреннем интерфейсе.

Пример

pixfirewall#show traffic
outside:
        received (in 124.650 secs):
                295468 packets  167218253 bytes
                2370 pkts/sec   1341502 bytes/sec
        transmitted (in 124.650 secs):
                260901 packets  120467981 bytes
                2093 pkts/sec   966449 bytes/sec
inside:
        received (in 124.650 secs):
                261478 packets  120145678 bytes
                2097 pkts/sec   963864 bytes/sec
        transmitted (in 124.650 secs):
                294649 packets  167380042 bytes
                2363 pkts/sec   1342800 bytes/sec

Если объем трафика приближается или достигает пропускной способности одного из интерфейсов, следует обновить интерфейс на более быстрый или ограничить объем трафика, проходящий через этот интерфейс. В противном случае возможно отбрасывание пакетов. Как уже говорилось в разделе show interface чтобы получить подробные сведения о пропускной способности, можно проверить счетчики интерфейса.

show perfmon

Команда show perfmon используется для наблюдения за количеством и типом трафика, инспектируемого PIX. Это единственный способ определить количество трансляций (xlates) и соединений (conn) в секунду. Соединения дополнительно разрушены в соединениях TCP и пользовательского протокола данных(UDP). Описание выходных данных при выполнении команды см. в разделе Описание выходных данных.

Пример

PERFMON STATS     Current      Average
Xlates              18/s         19/s
Connections         75/s         79/s
TCP Conns           44/s         49/s
UDP Conns           31/s         30/s
URL Access          27/s         30/s
URL Server Req       0/s          0/s
TCP Fixup         1323/s       1413/s
TCPIntercept         0/s          0/s
HTTP Fixup         923/s        935/s
FTP Fixup            4/s          2/s
AAA Authen           0/s          0/s
AAA Author           0/s          0/s
AAA Account          0/s          0/s

Описание выходных данных

В данной таблице приводится описание выходных данных show perfmon.

Поле Описание
Xlates Трансляции, выполненные за секунду
Соединения Подключений, установленных за секунду
TCP Conns Количество TCP-соединений в секунду
UDP Conns Соединения UDP на секунду
URL Access Количество доступов по URL-адресам (к веб-узлам)
URL Server Req Количество запросов, отправленных в приложения Websense и N2H2 в секунду (требуется ввод команды filter)
TCP Fixup Число пакетов TCP, переадресуемых PIX в секунду
Перехват TCP Число SYN-пакетов в секунду, превышающее начальный фиксированный предел
HTTP Fixup Количество пакетов, назначенных на порт 80 в секунду (требуется применить команду fixup protocol http)
FTP Fixup Количество проверенных FTP-команд в секунду
AAA Authen Запросы на аутентификацию в секунду
AAA Author Количество запросов авторизации в секунду
AAA Account Учетные требования в секунду

show blocks

Чтобы определить наличие перегрузки в PIX, наряду с командой show cpu usage можно использовать команду show blocks.

Блоки обработки пакетов (1550 и 16384 байт)

При поступлении в интерфейс PIX пакет помещается в очередь во входящем интерфейсе, передается в операционную систему и затем помещается в блок. Для пакетов Ethernet используется 1550-байтные блоки, для пакетов, приходящих с платы 66 МГц Gigabit Ethernet используются 16384-байтные блоки. PIX определяет, должен ли данный пакет быть принят или отклонен на основании алгоритма адаптивной защиты (Adaptive Security Algorithm, ASA) и передает пакет для обработки в очередь исходящих пакетов исходящего интерфейса. Если PIX не удается поддерживать нагрузку трафика, число доступных блоков на 1550 байт (или блоков на 16384 байт для GE 66 МГц) приблизится к 0 (как показано в столбце CNT выходных данных команды). Когда столбец CNT равен нулю, PIX пытается выделить больше блоков (максимум 8192). Если блоки недоступны, PIX отбрасывает пакет.

Блоки переключения при отказе и системного журнала (256 байт)

256-байтовые блоки в основном используются для сообщений аварийного переключения с синхронизацией состояния. Активный PIX генерирует и отправляет пакеты на резервный PIX, чтобы обновить таблицу трансляций и соединений. В периоды прохождения пульсирующего трафика, то есть когда высокоскоростные соединения образуются и разрываются, количество доступных 256-байтных блоков может снизиться до 0. Это снижение свидетельствует о том, что PIX в режиме ожидания не обновил одно или несколько соединений. Как правило, это приемлемо, поскольку протокол аварийного переключения с синхронизацией состояния будет перехватывать xlate или подключение, которое было разорвано. Тем не менее, если столбец CNT для 256-байтных блоков сохраняет нулевое значение близкое к нулю в течение продолжительного времени, PIX не сможет поддерживать таблицы трансляций и соединений, которые синхронизируются по числу обрабатываемых PIX соединений в секунду. Если проблема сохраняется, следует заменить модель PIX на более быструю.

Сообщения системного журнала, которые отсылает PIX, также используют 256-байтные блоки, однако они не выдаются в количестве, способном вызвать истощение пула 256-байтных блоков. Если в столбце CNT количество 256-байтных блоков близко к нулю, убедитесь, что вход на сервер системного журнала в режиме отладки (уровень 7) не производился. Это задается в строке режима журнала прерываний в конфигурации PIX. В этом случае рекомендуется установить для регистрации уровень 5 (Уведомление) или ниже, пока не будут получены дополнительные данные для отладки.

Пример

pixfirewall#show blocks
  SIZE    MAX    LOW    CNT
     4   1600   1597   1600
    80    400    399    400
   256    500    495    499
  1550   1444   1170   1188
 16384   2048   1532   1538

Описание выходных данных

В данной таблице приводится описание выходных данных show blocks.

Столбец Описание
РАЗМЕР Размер пула блока в байтах.
MAX Максимальное количество блоков, разрешенное для пула блоков с указанным размером. Учтите, что при загрузке память выделяется для максимального количества блоков. Обычно максимальное количество блоков неизменно. Исключение составляют 256-байтные и 1550-байтные блоки, которые могут динамически создаваться PIX (максимальное количество — 8192).
Низкий Нижняя граница. Это значение отображает самое низкое количество блоков данного размера с момента включения PIX или со времени последнего удаления блоков с помощью команды clear blocks.
CNT Текущее количество блоков, доступных в данном пуле блоков определенного размера.

В данной таблице приводится описание значений строки SIZE в выходных данных команды show blocks.

Значение SIZE Описание
4 Используется для дублирования существующих блоков в DNS, протоколе управления ключами Ассоциации безопасности Интернет (ISAKMP), фильтрации URL и модулях аутентификации пользователя, h323, tftp и TCP.
80 Используется в TCP-перехвате для генерации пакетов подтверждения (ACK) и для сообщений приветствия при переключении при отказе.
256 Используется для обновлений переключений при отказе с сохранением состояния, ведения системного журнала и выполнения других функций TCP.
1550 Используется для хранения пакетов Ethernet для обработки в PIX.
16384 Используется только для 64-битных плат Gigabit Ethernet 66 МГц (i82543) в PIX 535.

show memory

Команда show memory отображает общий объем физической памяти (ОЗУ) для PIX, наряду с количеством байтов, используемых в данный момент. Чтобы воспользоваться этими данными, необходимо получить четкое представление о том, как PIX использует ресурсы памяти. При запуске PIX копирует операционную систему из флэш-памяти в ОЗУ и запускает ОС из ОЗУ (таким же образом, как это делают маршрутизаторы). Затем PIX копирует конфигурацию при начальной загрузке из флэш-памяти и помещает ее в ОЗУ. После чего PIX выделяет определенный объем в ОЗУ для создания пулов блоков, что было рассмотрено ранее в разделе show blocks. По завершении выделения PIX может потребоваться дополнительный объем ОЗУ, но только в том случае, если увеличился размер конфигурации. Кроме того, PIX сохраняет записи трансляций и соединений в ОЗУ.

При нормальной работе свободный объем памяти в PIX должен изменяться незначительно или не изменяться вообще. Единственный случай нехватки памяти возможен только при целенаправленной атаке, когда через PIX выполняются сотни тысяч соединений. Чтобы проверить количество соединений, выполните команду show conn count, которая показывает текущее и максимально возможное количество соединений, выполняющихся через PIX. При нехватке памяти происходит аварийный отказ в работе PIX. До катастрофического отказа вы могли бы заметить сообщения ошибки выделения памяти в системном журнале (PIX-3-211001). В случае нехватки памяти по причине целенаправленной атаки обратитесь в Центр технической поддержки Cisco (TAC).

Примечание: Когда Cisco ASA исчерпывает память, он больше не принимает новые VPN-подключения, отбрасывает все существующие соединения и возвращает это сообщение об ошибках Ошибка: %ASA-3-336003: Никакие буферы, доступные для <байтов> пакет в 1 байт.

Примечание: Используйте команду show mem для подтверждения выделения ресурсов памяти и памяти обновления при необходимости. Если проблема сохраняется, свяжитесь с Центром технической поддержки Cisco для дальнейшего устранения проблем.

Пример

pixfirewall#show memory
1073741824 bytes total, 1022992384 bytes free

show xlate

Команда show xlate count отображает ток и максимальное число трансляций через PIX. Трансляция — это сопоставление внутренних адресов внешним адресам и может представлять собой сопоставление «один-к-одному», как в случае трансляции сетевых адресов (Network Address Translation, NAT), и «несколько-к-одному», как в случае трансляции адресов портов (Port Address Translation, PAT). Эта команда является поднабором команды show xlate, которая выводит каждую трансляцию через межсетевой экран PIX. В выходных данных команды отображаются «используемые» трансляции, к которым относятся активные трансляции в PIX при выполнении команды, и «наиболее используемые» — максимальное число трансляций, которое наблюдалось в PIX с момента включения.

Примечание: На одном узле возможно несколько соединений с разными местами назначения и только одна трансляция. Если счетчик xlate значительно превышает количество узлов во внутренней сети, то есть вероятность того, что на один из внутренних узлов был совершен несанкционированный доступ. Если это так, то его исходный адрес был подменен и из PIX этого узла осуществляется отправка пакетов.

Примечание: Когда vpnclient конфигурация включена, и внутренний хост отсылает запросы DNS, команда show xlate могла бы перечислить множественный xlates для статического преобразования.

Пример

pixfirewall#show xlate count
84 in use, 218 most used

На данном примере показаны выходные данные команды show xlate detail при активном состоянии трех трансляций адресов портов (Port Address Translations, PAT):

pixfirewall(config)#show xlate detail

3 in use, 3 most used

Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,

       o - outside, r - portmap, s - static

TCP PAT from inside:10.1.1.15/1026 to outside:192.150.49.1/1024 flags ri

UDP PAT from inside:10.1.1.15/1028 to outside:192.150.49.1/1024 flags ri

ICMP PAT from inside:10.1.1.15/21505 to outside:192.150.49.1/0 flags ri

Первая запись является Переадресацией Порта TCP для порта хоста (10.1.1.15, 1026) на внутренней сети к порту хоста (192.150.49.1, 1024) на внешней сети. Флаг "r" обозначает, что данная трансляция является трансляцией адресов портов. Флаг "i" означает, что данная трансляция применяется к внутреннему адресу или порту.

Вторая запись иллюстрирует трансляцию адресов UDP-порта хоста (10.1.1.15, 1028) внутренней сети в порт хоста (192.150.49.1, 1024) внешней сети. Флаг "r" обозначает, что данная трансляция является трансляцией адресов портов. Флаг "i" означает, что данная трансляция применяется к внутреннему адресу или порту.

Третья запись иллюстрирует трансляцию адресов ICMP-порта для host-ICMP-id (10.1.1.15, 21505) внутренней сети в host-ICMP-id (192.150.49.1, 0) внешней сети. Флаг "r" обозначает, что данная трансляция является трансляцией адресов портов. Флаг "i" означает, что данная трансляция применяется к внутреннему адресу или ICMP-id.

Поля внутренних адресов появляются в пакетах, которые проходят от более защищенных интерфейсов к менее защищенным. И наоборот, они появляются в качестве адресов назначения в пакетах, которые проходят от менее защищенных интерфейсов к более защищенным.

show conn count

Команда show conn count отображает текущее и максимальное количество соединений через PIX. Подключение сопоставляет сведения уровня 4 от внутреннего адреса внешнему адресу. Соединения создаются при получении PIX пакета SYN для TCP-сеансов, или когда прибывает первый пакет в UDP-сеансе. Соединения обрываются, когда PIX принимает последний пакет ACK во время закрытия сеанса TCP или когда завершается время ожидания сеанса UDP.

Слишком высокое соединение (в 20-100 раз выше нормального) может свидетельствовать об атаке. Выполните команду show memory, чтобы убедиться, что большое число соединений не вызывает нехватку памяти для PIX. Под воздействием атаки можно ограничить максимальное число подключений, приходящихся на одну статическую запись, а также максимальное количество начальных подключений. Это защитит внутренние серверы от переполнения. Подробнее см. Справочник по командам межсетевого экрана Cisco Secure PIX.

Пример

pixfirewall#show conn count
2289 in use, 44729 most used

show interface

Команда show interface может помочь определять проблемы несогласованности дуплексных параметров и проблемы с кабелем; это может также предоставить дальнейшее понимание относительно того, переполнен ли интерфейс. Если PIX испытывает нехватку ресурсов CPU, число 1550-байтных блоков близко к нулю. (Обратите внимание на 16384-байтные блоки на платах Gig 66 МГц). Другим показателем является увеличение «no buffers» в интерфейсе. Сообщение no buffers свидетельствует о том, что интерфейс не в состоянии отправлять пакеты операционной системе PIX, так как отсутствуют доступные блоки для пакета, из-за чего пакет отбрасывается. Если уровень «no buffer» повышается постоянно, воспользуйтесь командой show proc cpu, чтобы проверить уровень загрузки CPU в PIX. Если уровень загрузки CPU высок из-за интенсивного трафика, следует заменить модуль PIX на более мощный.

Когда пакет впервые поступает в интерфейс, он помещается во входную аппаратную очередь. Если входная аппаратная очередь заполнена, пакет помещается во входную программную очередь. Пакет передается от его очереди ввода на PIX OS и помещается в 1550-байтовый блок (или 16384-байтовый блок на интерфейсах Gigabit Ethernet частотой 66 МГц). Затем PIX определяет исходящий интерфейс для пакета и помещает пакет в соответствующую аппаратную очередь. Если аппаратная очередь заполнена, пакет помещается в исходящую программную очередь. Если максимальное число блоков в любой из программных очередей велико, интерфейс переполняется. Например, если данные поступают на PIX со скоростью 200 Мбит/с и затем выходят с одиночного интерфейса со скоростью 100 Мбит/с, то значения исходящей программной очереди на исходящем интерфейсе будут высокими, т.к. интерфейс не справляется с объемом трафика. При возникновении такой ситуации следует рассмотреть вопрос о замене интерфейса на более быстрый.

Пример

pixfirewall#show interface
interface ethernet0 "inside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 0002.b31b.99ff
  IP address 9.9.9.1, subnet mask 255.255.255.0
  MTU 1500 bytes, BW 100000 Kbit full duplex
        4630 packets input, 803174 bytes, 0 no buffer
        Received 2 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        4535 packets output, 445424 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 babbles, 0 late collisions, 0 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (128/128) software (0/1)
        output queue (curr/max blocks): hardware (0/2) software (0/1)

Вам следует так же проверить интерфейс на наличие ошибок. Получение карликовых кадров, входных ошибок, CRC, или ошибок в кадрах является признаком несоответствия дуплексных режимов. (Также возможны повреждения кабелей.). Дополнительные сведения о проблемах дуплексных режимов см. в разделе Настройка скорости и дуплексного режима. Помните, что каждый счетчик ошибок показывает количество пакетов, отброшенных по той или иной конкретной причине. Если наблюдается постоянное повышение значений определенного счетчика, это скорее всего отрицательно сказывается на производительности PIX, поэтому следует выяснить причины этого повышения.

При проверке счетчиков интерфейса учтите, что если для него установлен режим полного дуплекса, то не должно наблюдаться никаких конфликтов, поздних конфликтов или задержанных пакетов. Наоборот, если для интерфейса установлен полудуплексный режим, могут возникнуть конфликты, поздние конфликты и, возможно, задержанные пакеты. Общее число коллизий, поздних коллизий и задержанных пакетов не должно превышать 10% суммы счетчиков входящих и исходящих пакетов. Если конфликты превышают 10% общего трафика, то канал имеет чрезмерную нагрузку и необходимо произвести обновление до полнодуплексного канала или канала с более высокой скоростью (с 10 на 100 Мбит/c). Помните, что если показатель конфликтов равен 10%, то это значит, что PIX отбрасывает 10% пакетов, проходящих через данный интерфейс, а каждый из них должен быть передан повторно.

Подробные сведения о счетчиках интерфейса см. в описании команды interface в разделе Справочники по командам для межсетевого экрана Cisco Secure PIX.

show processes

Команда show processes в PIX отображает все активные процессы, которые выполняются PIX в момент исполнения данной команды. Эти данные используются для определения того, какой из процессов получает слишком много времени CPU, а какой не получает вовсе. Для получения этих данных выполните команду show processes дважды с перерывом в 1 минуту. Для сомнительного процесса отнимите значение времени выполнения из второго результата от значения времени выполнения из первого результата. Это даст возможность узнать, сколько времени CPU (в миллисекундах) получает процесс в данном интервале времени. Учтите, что запуск некоторых процессов запланирован через определенные промежутки времени, а некоторые процессы запускаются только тогда, когда получены данные для выполнения. У процесса 577poll, вероятно, будет самое большое время выполнения по сравнению с другими процессами. Такая ситуация не выходит за пределы нормы, поскольку процесс 577poll опрашивает интерфейсы Ethernet для определения их потребности в обработке тех или иных данных.

Примечание: Исследование каждого процесса PIX испытывает недостаток области этого документа, но упомянуто кратко для полноты. Дополнительные сведения о процессах PIX см. в разделе Команда PIX show processes.

Перечень команд

В общих словах, команду show cpu usage можно использовать для просмотра нагрузки PIX. Помните, что показания выходных данных — это среднее значение при выполнении процесса; в работе PIX могут наблюдаться резкие повышения нагрузки CPU, которые невозможно определить по среднему значению. Как только PIX достигает 80-процентного использования CPU, время ожидания через PIX медленно увеличивается до уровня, составляющего примерно 90% CPU. При загрузке процессора более 90% в PIX происходит потеря пакетов.

Если уровень загрузки CPU высокий, используйте команду show processes, чтобы определить процесс, который использует больше всего процессорного времени. Используйте эти данные для того, чтобы сократить время, которое занимает процесс высокой интенсивности (например, регистрация).

Если CPU не испытывает перегрузок, но есть подозрение, что пакеты все-таки отбрасываются, используйте команду show interface, чтобы проверить интерфейс PIX на предмет наличия ошибок буферизации и конфликтов, вызванных, вероятнее всего, несоответствием дуплексных режимов. Если значения счетчиков буферов не растет, но загрузка CPU остается высокой, то интерфейс не в состоянии осуществлять поддержку проходящего через него трафика.

Если с буферами все хорошо, проверьте состояние блоков. Если текущие значения для 1550-байтных блоков в столбце CNT в выходных данных команды show blocks близки к 0 (или 16384-байтных блоков на платах Gig 66 МГц), то, возможно, PIX отбрасывает пакеты Ethernet из-за высокой занятости. В этом случае наблюдаются резкие кратковременные повышения нагрузки CPU.

Если при создании новых соединений через PIX возникают проблемы, используйте команду show conn count, чтобы проверить текущее число соединений, которые обрабатываются PIX.

Если текущий показатель высок, проверьте выходные данные команды show memory, чтобы убедиться, что PIX не испытывает недостатка памяти. Если ресурсов памяти недостаточно, следует проанализировать источник соединений с помощью команды show conn или show local-host, чтобы убедиться в отсутствии атак, направленных на отказ в обслуживании.

Другие команды можно использовать для оценки объемов трафика, проходящего через PIX. С помощью команды show traffic отображаются суммарные пакеты и байты для каждого интерфейса, а с помощью команды show perfmon трафик разбивается на несколько разных типов, которые проверяются при помощи PIX.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 22040