Segurança : Dispositivos de segurança Cisco PIX 500 Series

PIX/ASA: Monitore e pesquise defeitos problemas de desempenho

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento descreve os comandos de PIX/ASA que você pode usar para monitorar e resolver problemas do desempenho de um Cisco PIX 500 Series/ASA 5500 Security Appliance.

Nota: Refira ASA 8.3 e mais atrasado: Monitore e pesquise defeitos problemas de desempenho para o Troubleshooting similar na ferramenta de segurança adaptável de Cisco (ASA) com versão 8.3 e mais recente.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

A informação neste documento é baseada na versão 6.2(1) e mais recente do Software do firewall Cisco PIX.

Nota: A informação neste documento pode igualmente ser usada com a ferramenta de segurança do 5500 Series de Cisco ASA que executa 7.x e acima da versão.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você trabalhar em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Troubleshooting

A fim pesquisar defeitos problemas de desempenho, verifique as áreas básicas descritas nesta seção.

Nota: Se você tem a saída do comando show de seu dispositivo Cisco, você pode usar a ferramenta Output Interpreter (clientes registrados somente) a fim indicar problemas potenciais e reparos. A ferramenta Output Interpreter apoia determinados comandos de exibição. Se você usa a ferramenta Output Interpreter, você deve ser um cliente registrado, você deve ser entrado a sua conta de Cisco, e você deve ter o Javascript permitido dentro de seu navegador.

Configurações de velocidade e dúplex

A ferramenta de segurança preconfigured para autodetect os ajustes da velocidade e duplexação em uma relação. Contudo, diversas situações existem que podem fazer com que o processo de auto-negociação falhe, que conduz à velocidade ou as incompatibilidades duplex (bidirecional) (e os problemas de desempenho). Para a infraestrutura de rede de missão crítica, Cisco não codifica manualmente a velocidade e duplexação em cada relação tão lá é nenhuma possibilidade para o erro. Estes dispositivos geralmente não se movem ao redor, assim que se você os configura corretamente, você não deve precisar de mudá-los.

Em todo o dispositivo de rede, a velocidade do link pode ser detectada, mas o duplex deve ser negociado. Se dois dispositivos de rede são configurados à velocidade e duplexação da autonegociação, trocam os quadros (chamados pulsos rápidos de enlace, ou FLP) que anunciam suas capacidades da velocidade e duplexação. Um parceiro de enlace que não esteja ciente, estes pulsos é similar aos quadros regulares do 10 Mbps. Um parceiro de enlace que possa descodificar os pulsos, os FLP contém todos os ajustes da velocidade e duplexação que o parceiro de enlace pode fornecer. A estação que recebe os FLP reconhece os quadros, e os dispositivos concorda mutuamente com os ajustes os mais altos da velocidade e duplexação que cada um pode conseguir. Se um dispositivo não apoia a negociação automática, o outro dispositivo recebe os FLP e as transições ao modo de detecção paralela. A fim detectar a velocidade do sócio, o dispositivo escuta o comprimento dos pulsos, e ajusta então a velocidade em conformidade. O problema elevara com a configuração bidirecional. Desde que o duplex deve ser negociado, o dispositivo que é ajustado à autonegociação não pode determinar os ajustes no outro dispositivo, assim ele opta por metade-frente e verso, como exposto no padrão da IEEE 802.3u.

Por exemplo, se você configura a interface de PIX para a negociação automática e a conecta a um interruptor que esteja codificado para o 100 Mbps e FULL-frente e verso, o PIX manda FLP. Contudo, o interruptor não responde porque é codificado para a velocidade e duplexação e não participa na negociação automática. Porque não recebe nenhuma resposta do interruptor, as transições PIX no modo de detecção paralela e detectam o comprimento dos pulsos nos quadros que o interruptor manda. Isto é, o PIX detecta que o interruptor está ajustado ao 100 Mbps, assim que ajusta a velocidade da relação em conformidade. Contudo, porque o interruptor não troca FLP, o PIX não pode detectar se o interruptor pode executar FULL-frente e verso, assim que o PIX ajusta o duplex da relação metade-frente e verso, como exposto no padrão da IEEE 803.2u. Desde que o interruptor é codificado ao 100 Mbps e FULL-frente e verso, e o PIX tem apenas negociado automaticamente ao 100 Mbps e metade-frente e verso (como deve), o resultado é uma incompatibilidade duplex (bidirecional) que possa causar problemas sérios de desempenho.

Uma velocidade ou uma incompatibilidade duplex (bidirecional) mais frequentemente são reveladas quando os contadores de erros nas relações na pergunta aumentam. A maioria de erros comuns são quadro, verificações de redundância cíclica (CRC), e runts. Se estes valores incrementam em sua relação, uma incompatibilidade de velocidade/bidirecional ou uma questão de cabeamento ocorrem. Você deve resolver esta edição antes que você continue.

Exemplo

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 Utlization

Se você observou a utilização CPU é alta, segue estas etapas a fim pesquisar defeitos:

  1. Verifique que o contagem de conexão na contagem do xlate da mostra é baixo.

  2. Verifique que o bloco de memória é normal.

  3. Verifique que o número de ACL é mais alto.

  4. Emita o comando dos detalhes da memória da mostra, e verifique que a memória usada pelo PIX é utilização normal.

  5. Verifique que as contagens no CPU hog dos processos da mostra e na memória dos processos da mostra são normais.

  6. Alguns hospedam o presente dentro ou fora que a ferramenta de segurança pode gerar o tráfego malicioso ou maciço que pode ser uma transmissão/tráfego multicast e causar a utilização elevada da CPU. A fim resolver esta edição, configurar uma lista de acessos para negar o tráfego entre os anfitriões (End to End) e para verificar o uso.

  7. Verifique o duplex e apresse ajustes nas interfaces de PIX. O ajuste da má combinação com as interfaces remotas pode aumentar a utilização CPU.

    Este exemplo mostra o número mais alto no erro de entrada e as excedentes devido à má combinação da velocidade. Use o comando show interface a fim verificar os erros:

    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
    

    A fim resolver esta edição, ajuste a velocidade como o automóvel à interface correspondente.

    Nota: Cisco recomenda que você permite o IP verifica o comando interface do caminho reverso em todas as relações porque deixará cair os pacotes que não têm um endereço de origem válida, que conduza a menos USO de CPU. Isto aplica-se ao FWSM que enfrenta edições da alta utilização da CPU.

  8. Uma outra razão para o uso da alta utilização da CPU pode ser devido a rotas de transmissão múltiplas demais. Emita o comando do mrouter da mostra a fim verificar se o PIX/ASA recebe rotas de transmissão múltiplas demais.

  9. Use o comando show local-host a fim ver se a rede experimenta um ataque de recusa de serviço, que possa indicar um ataque do vírus na rede.

    Nota: A atividade da alta utilização da CPU pôde ocorrer devido à edição descrita na alta utilização da CPU quando o nameif/nível de segurança mudou para a relação nova (clientes registrados somente). Refira a identificação de bug Cisco CSCsq48636 (clientes registrados somente) para mais informação.

Nota: Se a solução forneceu acima não resolve a edição, promove a plataforma ASA de acordo com as exigências. Refira a folha de dados do Dispositivos de segurança adaptáveis Cisco ASA série 5500 para obter mais informações sobre das capacidades e das capacidades adaptáveis da plataforma da ferramenta de segurança. Contacte TAC (clientes registrados somente) para mais informações.

Utilização da memória alta

Estão aqui algumas causas possíveis e definições para a utilização da memória alta:

  • Logging de evento: O logging de evento pode consumir grandes quantidades de memória. A fim resolver esta edição, instale e registre todos os eventos a um servidor interno, tal como um servidor de SYSLOG.

  • Escape de memória: Um problema conhecido no software da ferramenta de segurança pode conduzir ao consumo da memória alta. A fim resolver esta edição, promova o software da ferramenta de segurança.

  • Eliminação de erros permitida: A eliminação de erros pode consumir grandes quantidades de memória. A fim resolver esta edição, desabilitação que debuga com o comando undebug all.

  • Portas de bloqueio: As portas de bloqueio na interface externa de uma ferramenta de segurança fazem com que a ferramenta de segurança consuma quantidades elevadas de memória para obstruir os pacotes através das portas especificadas. A fim resolver esta edição, obstrua o tráfego causador na extremidade ISP.

  • Ameaça-detecção: A característica da detecção da ameaça consiste em níveis diferentes das estatísticas que recolhem para várias ameaças, assim como na detecção de varredura da ameaça, que determina quando um host está executando uma varredura. Desligue esta característica para consumir menos memória.

PortFast, canalização, e entroncamento

À revelia, muito Switches, tal como os switch Cisco que executam o Catalyst Operating System (OS), é projetado ser dispositivos plug and play. Como tal, muitos dos parâmetros da porta padrão não são desejáveis quando um PIX é obstruído no interruptor. Por exemplo, em um interruptor que execute o OS do catalizador, a canalização do padrão é ajustada ao automóvel, o entroncamento é ajustado ao automóvel, e PortFast é desabilitado. Se você conecta um PIX a um interruptor que execute o OS do catalizador, desabilite a canalização, desabilite o entroncamento, e permita PortFast.

Canalizar, igualmente conhecida como o Fast EtherChannel ou EtherChannel de Giga, é usada para ligar dois ou mais portas física em um grupo lógico a fim aumentar o throughput geral através do link. Quando uma porta é configurada para o canal automático, manda quadros do Port Aggregation Protocol (PAgP) enquanto o link se torna ativo a fim determinar se é parte de um canal. Estes quadros podem causar problemas se o outro dispositivo tenta à autonegociação a velocidade e duplexação do link. Se canalizar na porta é ajustada ao automóvel, igualmente conduz a um atraso adicional de aproximadamente 3 segundos antes que os começos da porta para enviar o tráfego após o link estejam acima.

Nota: Nos Catalyst XL Series switch, canalizar não é ajustada ao automóvel à revelia. Por este motivo, você deve desabilitar a canalização em toda a porta de switch que conectar a um PIX.

O entroncamento, igualmente conhecido pelo Inter-Switch Link (ISL) comum ou pelo dot1q dos protocolos de entroncamento, combina as LAN virtuais múltiplas (VLAN) em uma porta única (ou no link). O entroncamento é usado tipicamente entre dois Switches quando ambo o Switches tem mais de um VLAN definido nele. Quando uma porta é configurada para o entroncamento automático, manda quadros do Dynamic Trunking Protocol (DTP) enquanto o link vem acima a fim determinar se a porta a que conecta quer ao tronco. Esses quadros DTP podem provocar problemas com a autonegociação do link. Se o entroncamento é ajustado ao automóvel em uma porta de switch, adiciona um atraso adicional de aproximadamente 15 segundos antes que os começos da porta para enviar o tráfego após o link estejam acima.

PortFast, igualmente conhecido como o começo rápido, é uma opção que informe o interruptor que um dispositivo da camada 3 está conectado fora de uma porta de switch. A porta não espera o padrão 30 segundos (15 segundos a escutar e 15 segundos a aprender); em lugar de, esta ação faz com que o interruptor ponha a porta no estado de encaminhamento imediatamente depois que o link vem acima. É importante compreender que quando você permite PortFast, medindo - a árvore não é desabilitada. Medida - a árvore é ainda ativa nessa porta. Quando você permite PortFast, o interruptor está informado somente que não há um outro interruptor ou hub (dispositivo da camada 2-only) conectado no outro extremo do link. O interruptor contorneia o atraso 30-second normal quando tentar determinar se resultados de um laço da camada 2 se traz acima essa porta. Depois que o link é trazido acima, ainda participa na medida - árvore. A porta manda as unidades de dados do pacote de Bridge (BPDU), e o interruptor ainda escuta BPDU nessa porta. Por estas razões, recomenda-se que você permite PortFast em toda a porta de switch que conectar a um PIX.

Nota: Os Catalyst OS Releases 5.4 e mais atrasado incluem o comando set port host <mod>/<port> que permite que você use um comando único desabilitar a canalização, desabilitar o entroncamento, e permitir PortFast.

Network Address Translation (NAT)

Todas as sessões que conectam através da ferramenta de segurança devem se submeter a algum formulário da tradução de endereço de rede, ou a NAT. Sessão de cada sobrecarga NAT ou NAT (PANCADINHA) é atribuída um slot de tradução conhecido como um xlate. Estes xlates podem persistir mesmo depois que você faz mudanças ao NAT ordena que influência elas. Isto pode conduzir a uma prostração dos slots de tradução ou do comportamento inesperado ou a ambos pelo tráfego que se submete à tradução. Esta seção explica como ver e xlates claros na ferramenta de segurança.

Nota: Os xlates sempre claros depois que você adiciona, mudam, ou removem o AAA-server, a lista de acesso, aliás, global, nat, a rota, ou os comandos static em sua configuração.

cuidado Cuidado: Uma interrupção momentânea do fluxo de todo o tráfego através do dispositivo puder ocorrer quando você xlates globalmente claros na ferramenta de segurança.

Prove a configuração de PIX para a PANCADINHA que usa o endereço IP de Um ou Mais Servidores Cisco ICM NT da interface externa:

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

Trafique que corre através da ferramenta de segurança se submete muito provavelmente ao NAT. A fim ver as traduções que estão no uso na ferramenta de segurança, emita o comando 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

Os slots de tradução podem persistir depois que as mudanças chaves são feitas. A fim cancelar entalhes da tradução atual na ferramenta de segurança, emita o comando clear xlate:

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

O comando clear xlate cancela toda a tradução dinâmica atual da tabela do xlate. A fim cancelar uma tradução particular IP, você pode usar o comando clear xlate com a palavra-chave global do [ip address].

Está aqui uma configuração de PIX da amostra para o NAT:

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

Observe o xlate da mostra output para a tradução para 10.2.2.2 interno ao Outside Global 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

Cancele a tradução para o endereço IP global de 10.10.10.10:

pixfirewall# clear xlate global 10.10.10.10

Neste exemplo, a tradução para 10.2.2.2 interno ao Outside Global 10.10.10.10 é ida:

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

Quando você cancela slots de tradução, seja certo levar em consideração os tipos diferentes de traduções:

  • Um xlate estático é um xlate persistente que seja criado com o comando static. A fim remover os xlates estáticos, você deve remover o comando static da configuração. O comando clear xlate não remove a regra da tradução estática. Se você remove um comando static da configuração, as conexões de preexistência que usam a regra estática podem ainda enviar o tráfego. Use o comando claro do host local a fim desativar estas conexões.

  • Um xlate dinâmico é um xlate que seja por encomenda criado com processamento de tráfego (através do nat ou do comando global). O comando clear xlate remove os xlates dinâmicos e suas conexões associadas. Se você remove um nat ou um comando global da configuração, o xlate dinâmico e as conexões associadas puderam permanecer ativos.

Syslogs

Os Syslog permitem que você pesquise defeitos edições no PIX. Cisco oferece um servidor de SYSLOG livre para o Windows NT chamado Servidor de Syslog de Firewall de PIX (PFSS). Você pode transferir o PFSS da página dos downloads do software (clientes registrados somente).

Diversos outros fornecedores, tais como Kiwi Enterprisesleavingcisco.com , oferecem servidores de SYSLOG para diversas plataformas Windows, tais como o Windows 2000 e o Windows XP. A maioria UNIX e de máquinas de Linux têm os servidores de SYSLOG instalados à revelia.

Quando você estabelece o servidor de SYSLOG, configurar o PIX a fim enviar-lhe logs.

Por exemplo:

logging on
logging host <ip_address_of_syslog_server>
logging trap debugging

Nota: Este exemplo configura o PIX para enviar a eliminação de erros (nível 7) e uns Syslog mais críticos ao servidor de SYSLOG. Desde que estes logs PIX são os mais verbosos, use-os somente quando você pesquisa defeitos uma edição. Para a operação normal, configurar o nível de registro à advertência (nível 4) ou ao erro (nível 3).

Se você experimenta uma edição com desempenho lento, abra o Syslog em um arquivo de texto e em uma busca para o endereço IP de origem associado com o problema de desempenho. (Se você usa UNIX, você pode grep com o Syslog para o endereço IP de origem.) Verifique para ver se há mensagens que indicam o servidor interno tentado alcançar o endereço IP interno na porta TCP 113 (para o protocolo de identificação, ou a identificação), mas o PIX negou o pacote. A mensagem deve ser similar a este exemplo:

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

Se você recebe esta mensagem, emita o comando service reset inbound ao PIX. O PIX não deixa cair silenciosamente pacotes; em lugar de, este comando faz com que o PIX restaure imediatamente toda a conexão de entrada que for negada pela política de segurança. O server não espera o pacote identificação para cronometrar para fora sua conexão de TCP; em lugar de, recebe imediatamente um pacote da restauração. Refira os problemas de desempenho de PIX causados pelo Protocolo IDENT para obter mais informações sobre do PIX e da identificação.

Consultas de DNS inverso

Se você experimenta o desempenho lento com o PIX, verifique que você tem os registros do ponteiro do Domain Name System (PTR DNS), igualmente conhecidos como registros da pesquisa de DNS reversa, no servidor DNS competente para os endereços externos que o PIX usa. Isto incluem todo o endereço em seu pool da tradução de endereço de rede global (NAT) (ou a interface externa PIX se você sobrecarrega na relação), qualquer endereço estático, e endereço interno (se você não usa o NAT com ele). Alguns aplicativos, tais como o File Transfer Protocol (FTP) e os servidores Telnet, podem usar pesquisas de DNS reversas a fim determinar de aonde o usuário vem e se é um host válido. Se a pesquisa de DNS reversa não resolve, a seguir o desempenho está degradado como os tempos do pedido para fora.

A fim assegurar-se de que um registro PTR exista para estes anfitriões, emita o comando nslookup de seu PC ou a máquina Unix; inclua o endereço IP global que você se usa para conectar ao Internet.

Exemplo

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

Você deve receber uma resposta para trás com o nome de DNS do dispositivo atribuído a esse endereço IP de Um ou Mais Servidores Cisco ICM NT. Se você não recebe uma resposta, contacte a pessoa que controla seu DNS a fim pedir a adição de registros PTR para cada um de seus endereços IP globais. Refira pobres ou desempenho intermitente de FTP/HTTP com um PIX para obter mais informações sobre dos problemas de desempenho no PIX causado pelos registros PTR que são perdidos.

Excedentes na relação

Se você tem uma intermitência de tráfego, os pacotes descartado podem ocorrer se a explosão excede a capacidade de proteção do buffer FIFO no NIC e nos bufferes do anel de recebimento. Permitir frames de pausa para o controle de fluxo pode aliviar esta edição. A pausa (XOFF) e os quadros XON são gerados automaticamente pelo hardware NIC baseado no uso do buffer FIFO. Um frame de pausa é enviado quando o uso de buffer excede a marca da água superior. Para permitir quadros da pausa (XOFF) para o controle de fluxo, use o comando seguinte:

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

Refira a possibilidade da interface física e configurar parâmetros dos Ethernet para mais informação.

comandos show

show cpu usage

O comando show cpu usage foi introduzido em PIX 6.0(1) e é usado primeiramente para determinar a carga de tráfego colocada no PIX CPU. Durante tempos do tráfego de pico, a rede aflui, ou os ataques, o USO de CPU podem cravar.

O PIX tem um único CPU para processar uma variedade de tarefas; por exemplo, processa pacotes e as cópias debugam mensagens ao console. Cada processo tem sua própria finalidade, e alguns processos exigem mais processador central - tempo do que outros processos. A criptografia é provavelmente a maioria de processo intensivo de CPU, assim que se seu PIX passa muito tráfego através dos túneis criptografado, você deve considerar um PIX mais rápido, um [Part - PIX-VPN-ACCEL] do VPN Accelerator Card (VAC) para o PIX, ou um concentrador VPN dedicado, tal como o VPN3000. O VAC offloads a criptografia e a descriptografia do PIX CPU e executa-a no hardware no cartão. Isto permite que o PIX cifre e decifre o 100 Mbps do tráfego com 3DES (criptografia do 168-bit).

O registro é outro processo que pode consumir grande quantidade de recursos do sistema. Devido a isto, recomenda-se que você desabilita o console, o monitor, e o buffer entrando o PIX. Você pode permitir estes processos quando você pesquisa defeitos um problema, mas desabilita-os para a operação do dia a dia, especialmente se você é executado fora da capacidade de CPU. Igualmente sugere-se que a informações de syslog ou o Simple Network Management Protocol (SNMP) que registram (história de registo) devam ser ajustados ao nível 5 (notificação) ou abaixar. Além, você pode desabilitar o mensagem do syslog específico ID com o comando no logging message <syslog_id>.

O gerenciador de dispositivo pix (PDM) igualmente fornece um gráfico na aba da monitoração que permite que você ver o USO de CPU do PIX ao longo do tempo. Você pode usar este gráfico a fim determinar a carga em seu PIX.

O comando show cpu usage pode ser utilizado para exibir as estatísticas de utilização da CPU.

Exemplo

pixfirewall#show cpu usage

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

Descrição da saída

Esta tabela descreve os campos na saída do uso processador central da mostra.

Campo Descrição
Utilização CPU pelos segundos 5 Utilização de CPU durante os últimos cinco segundos
1 minuto Amostras de uma média de 5 segundos de utilização da CPU no último minuto
5 minutos Média de exemplos de 5 segundos de utilização de CPU nos últimos cinco minutos.

show traffic

O comando show traffic mostra quanto tráfego que passa com o PIX durante um período de tempo dado. Os resultados se baseiam no intervalo de tempo desde a emissão do comando. Para resultados precisos, emita o comando clear traffic primeiramente e espere então 1-10 minutos antes que você emita o comando show traffic. Você poderia igualmente emitir o comando show traffic e a espera 1-10 minutos antes que você emita o comando outra vez, mas somente a saída do segundo exemplo é válida.

Você pode usar o comando show traffic a fim determinar quanto o tráfego passa com seu PIX. Se você tem interfaces múltiplas, o comando pode ajudá-lo a determinar que relações enviam e recebem a maioria de dados. Para ferramentas de PIX com duas relações, a soma do tráfego de entrada e de saída na interface externa deve igualar a soma do tráfego de entrada e de saída na interface interna.

Exemplo

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

Se você vem perto de ou alcança o throughput taxado em uma de suas relações, você precisa de promover a uma relação mais rápida ou de limitar a quantidade de tráfego em que vai ou fora dessa relação. A falha fazer assim pode conduzir aos pacotes descartado. Como explicado na seção da relação da mostra, você pode examinar os contadores de interface a fim encontrar sobre a taxa de transferência.

show perfmon

O comando show perfmon é usado monitorar a quantidade e os tipos de tráfego que o PIX inspeciona. Este comando é a única maneira de determinar por segundo o número de traduções (xlates) e de conexões (conexão). As conexões são divididas posteriormente em conexões TCP e UDP. Veja a descrição de Output para descrições da saída que este comando gera.

Exemplo

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

Descrição da saída

Esta tabela descreve os campos na saída do perfmon da mostra.

Campo Descrição
Xlates Conversões criadas por segundo
Conexões Conexões estabelecidas por segundo
Conns TCP Conexões TCP por segundo
Conns UDP Conexões UDP por segundo
Acesso URL URL (Web site) alcançadas por segundo
Req do server URL Os pedidos enviaram a Websense e ao N2H2 por segundo (exige o comando do filtro)
Reparares TCP Número de pacotes TCP que o PIX encaminha por segundo
TCPIntercept Número de pacotes SYN por segundo que excederam ao limite embriônico definido em um estático
Reparares HTTP Número de pacotes destinado à porta 80 por segundo (requer comando fixup protocol http)
Reparares FTP Comandos ftp inspecionados por segundo
AAA Authen Solicitações de autenticação por segundo
Autor AAA Pedidos de autorização por segundo
Conta AAA Requisições de contabilização por segundo

show blocks

Junto com o comando show cpu usage, você pode usar o comando show blocks a fim determinar se o PIX está sobrecarregado.

Blocos de Processamento de Pacotes (1550 e 16.384 Bytes)

Quando entra a interface de PIX, um pacote está colocado na fila da interface de entrada, passado até o OS, e colocado em um bloco. Para pacotes de Ethernet, os blocos 1550-byte são usados; se o pacote vem dentro em uma placa de Ethernet Gigabit 66 megahertz, os blocos 16384-byte estão usados. O PIX determina se o pacote está permitido ou negado com base no algoritmo de segurança de adaptação (ASA) e processa o pacote completamente à fila de saída na interface externa. Se o PIX não pode apoiar a carga de tráfego, o número de 1550-byte disponível obstrui (ou blocos 16384-byte para 66 megahertz GE) pairos perto de 0 (segundo as indicações da coluna de CNT do comando output). Quando a coluna CNT atingir zero, o PIX tentará alocar mais blocos, até um máximo de 8192. Se houver mais blocos disponíveis, o PIX descarta o pacote.

Blocos de Failover e Syslog (256 Bytes)

Os blocos de 256 bytes são principalmente usados para mensagens de failover stateful. O PIX ativo gera e envia pacotes ao PIX em standby a fim atualizar a tradução e a tabela de conexão. Durante períodos de tráfego intermitente onde as altas taxas de conexões são criadas ou rasgadas para baixo, o número de blocos disponíveis do 256-byte pode deixar cair a 0. Esta gota indica que umas ou várias conexões não estão atualizadas ao PIX em standby. Isto é geralmente aceitável porque a próxima vez em torno da comutação classificada o protocolo trava o xlate ou a conexão que são perdidos. Contudo, se a coluna de CNT para o 256-byte obstrui estadas em ou perto de 0 por períodos de tempo extendido, o PIX não pode prosseguir com a tradução e as tabelas de conexão que são sincronizadas devido ao número de conexões por segundo que o PIX processa. Se isto acontece consistentemente, promova o PIX a um modelo mais rápido.

Os mensagens do syslog mandados do PIX igualmente usam os blocos do 256-byte, mas não são liberados geralmente em tal quantidade que causa uma prostração do pool de bloco do 256-byte. Se a coluna de CNT mostra que o número de blocos do 256-byte está perto de 0, assegure-se de que você não registre na eliminação de erros (nível 7) ao servidor de SYSLOG. Isso é indicado pela linha de armadilha de registro na configuração do PIX. Recomenda-se que você ajusta o registo à notificação (nível 5) ou o abaixa, a menos que você exigir a informação adicional para propósitos de debugging.

Exemplo

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

Descrição da saída

Esta tabela descreve as colunas na saída dos blocos da mostra.

Coluna Descrição
TAMANHO O tamanho, nos bytes, do pool de bloco.
MAX O número máximo de blocos disponíveis para o pool de bloco especificado do byte. Observe que o número máximo de blocos está gravado fora da memória na inicialização. Tipicamente, o número máximo de blocos não muda. A exceção é para o 256-byte e os blocos 1550-byte, onde o PIX pode dinamicamente criar mais quando necessário, até um máximo de 8192.
BAIXO A baixa filigrana. Este valor é o mais baixo número de blocos deste tamanho disponíveis desde que o PIX foi posto acima, ou desde que a última vez onde os blocos foram cancelados com o comando clear blocks.
CNT O número atual de blocos disponível para esse pool de blocos de tamanho específico.

Esta tabela descreve os valores da fileira do TAMANHO na saída dos blocos da mostra.

Valor do TAMANHO Descrição
4 Use a fim duplicar os blocos que existem no DNS, no Internet Security Association and Key Management Protocol (ISAKMP), na Filtragem URL, no uauth, no h323, no tftp, e nos módulos TCP.
80 Use no TCP Intercept a fim gerar pacotes do reconhecimento (ACK) e para mensagens Hello Messages do Failover.
256 Use para atualizações da comutação classificada, informações de syslog, e outras funções TCP.
1550 Use a fim armazenar os pacotes de Ethernet que são processados com o PIX.
16384 Use para somente o 64-bit, as placas de Ethernet Gigabit 66 megahertz (i82543) no PIX 535.

show memory

O comando show memory indica a memória física total (ou RAM) para o PIX, junto com o número de bytes atualmente disponível. A fim usar esta informação, você deve primeiramente compreender como o PIX usa a memória. Quando as botas PIX, ele copiarem o OS do flash em RAM e executarem o OS de RAM (apenas como o Roteadores). Em seguida, o PIX copia a configuração de inicialização do flash e coloca-a em RAM. Finalmente, o PIX atribui RAM a fim criar os poois de bloco discutidos na seção dos blocos da mostra. Uma vez que esta atribuição está completa, o PIX precisa RAM adicional somente se a configuração aumenta em tamanho. Além disso, o PIX armazena as entradas de tradução e conexão na RAM.

Durante a operação normal, a memória livre no PIX deve mudar muito pouco, se de todo. Tipicamente, a única vez que você deve ser executado baixo na memória é se você está sob o ataque e os milhares de conexões atravessam o PIX. A fim verificar as conexões, emita o comando show conn count, que indica a corrente e o número máximo de conexão com o PIX. Se o PIX é executado fora da memória, causa um crash eventualmente. Antes do impacto, você pôde observar mensagens da falha de alocação de memória no Syslog (PIX-3-211001). Se você é executado fora da memória porque você está sob o ataque, contacte o centro de assistência técnica da Cisco (TAC).

Nota: Quando Cisco ASA é executado fora da memória, já não aceita conexões de VPN novas, deixa cair todas as conexões existentes, e retorna este erro do Mensagem de Erro: %ASA-3-336003: Sem bufferes disponíveis para o pacote de bytes do <bytes>.

Nota: Use o comando do mem da mostra a fim verificar a atribuição dos recursos de memória e promover se for necessário a memória. Se o problema persiste, contacte o tac Cisco para um Troubleshooting mais adicional.

Exemplo

pixfirewall#show memory
1073741824 bytes total, 1022992384 bytes free

show xlate

O comando show xlate count indica a corrente e o número máximo de traduções com o PIX. Uma tradução é um mapeamento de um endereço interno a um endereço externo e pode ser um mapeamento um a um, tal como o Network Address Translation (NAT), ou um mapeamento many-to-one, tal como a tradução de endereço de porta (PAT). Esse comando é um subconjunto do comando show xlate, que produz cada tradução por meio do PIX. A saída do comando mostra traduções “no uso,” qual refere o número de traduções ativa no PIX quando o comando é emitido; “o mais usado” refere os máximos de traduções que foram considerados nunca no PIX desde que foi posto sobre.

Nota: Um host único pode ter conexões múltiplas aos vários destinos, mas somente uma tradução. Se a contagem do xlate é muito maior do que o número de anfitriões em sua rede interna, é possível que um de seus host internos esteve comprometido. Se seu host interno foi comprometido, paródias o endereço de origem e envia a pacotes para fora o PIX.

Nota: Quando a configuração vpnclient é permitida e o host interno manda pedidos DNS, o comando show xlate pôde alistar xlates múltiplos para uma tradução estática.

Exemplo

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

Este exemplo mostra a saída do comando show xlate detail com três traduções de endereços da porta ativa (pancadinhas):

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

A primeira entrada é uma tradução de endereços da porta TCP para a porta de host (10.1.1.15, 1026) na rede interna à porta de host (192.150.49.1, 1024) na rede externa. A bandeira “r” denota a tradução é uma tradução de endereço de porta. “Eu” bandeiras denoto que a tradução se aplica à endereço-porta interna.

A segunda entrada é uma tradução de endereço de porta UDP para a porta de host (10.1.1.15, 1028) na rede interna à porta de host (192.150.49.1, 1024) na rede externa. A bandeira “r” denota a tradução é uma tradução de endereço de porta. “Eu” bandeiras denoto que a tradução se aplica à endereço-porta interna.

A terceira entrada é uma tradução de endereço de porta ICMP para a host-ICMP-identificação (10.1.1.15, 21505) na rede interna à host-ICMP-identificação (192.150.49.1, 0) na rede externa. A bandeira “r” denota a tradução é uma tradução de endereço de porta. “Eu” bandeiras denoto que a tradução se aplica à endereço-ICMP-identificação interna.

Os campos de endereço interno aparecem como endereços de origem nos pacotes que transversal de mais interface segura a menos interface segura. Inversamente, aparecem como endereços de destino nos pacotes que transversal de menos interface segura a mais interface segura.

show conn count

O comando exibir contagem conexão mostra o número atual e máximo de conexões pelo PIX. Uma conexão é um mapeamento de informações de Camada 4 de um endereço interno para um endereço externo. As conexões estão acumuladas quando o PIX recebe um pacote SYN para sessões de TCP ou quando o primeiro pacote em uma sessão de UDP chega. As conexões estão rasgadas abaixo de quando o PIX recebe o pacote ACK final, que ocorre quando o aperto de mão da sessão de TCP se fecha ou quando o intervalo expira na sessão de UDP.

Contagens de conexão extremamente altas (de 50 a 100 vezes acima do normal) podem indicar que você está sendo atacado. Emita o comando show memory a fim assegurar-se de que o contagem de alta conexão não faça com que o PIX seja executado fora da memória. Se você estiver sob ataque, você pode limitar o número máximo de conexões por entrada estática e também limitar o número máximo de conexões embrionárias. Esta ação protege seus servidores internos, assim que não se tornam oprimidos. Refira referências de comando do Cisco secure PIX firewall para mais informação.

Exemplo

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

show interface

O comando show interface pode ajudar a determinar problemas de incompatibilidade bidirecional e problemas de cabo; pode igualmente fornecer o maior insight se ou não a relação está passada. Se o PIX é executado fora da capacidade de CPU, o número dos blocos 1550-byte paira perto de 0. (olhar nos blocos 16384-byte nos cartões da atuação 66 megahertz.) Um outro indicador é o aumento de “sem bufferes” na relação. A mensagem dos sem bufferes indica que a relação é incapaz de enviar o pacote ao PIX OS porque não há nenhum bloco disponível para o pacote, e o pacote é deixado cair. Se um aumento em níveis do sem buffer ocorre regularmente, emita o comando show proc cpu a fim verificar o USO de CPU no PIX. Se o USO de CPU é alto devido a uma carga de tráfego pesado, promova a um PIX mais poderoso que possa segurar a carga.

Quando um pacote entrar em uma interface pela primeira vez, ele será colocado na fila de hardware de entrada. Se a fila de hardware de entrada está completa, o pacote está colocado na fila do software da entrada. O pacote é transferido de sua fila de entrada até o PIX OS e posicionado em um bloco de 1550 bytes (ou em um bloco de 16384 bytes nas Interfaces Gigabit Ethernet de 66 MHz). O PIX determina, em seguida, a interface de saída do pacote e o coloca na fila apropriada de hardware. Se a fila de hardware está completa, o pacote está colocado na fila do software de emissor. Se os blocos máximos em qualquer uma das filas do software são grandes, a seguir a relação está passada. Por exemplo, se o 200 Mbps entra o PIX e todos saem uma única relação do 100 Mbps, a fila do software de emissor indica altos números na interface externa, que indica que a relação não pode segurar o volume de tráfego. Se você experimenta esta situação, promova a uma relação mais rápida.

Exemplo

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)

Você também deve procurar erros na interface. Se você recebe runts, erros de entrada, CRC, ou erros de frame, é provável que você tem uma incompatibilidade duplex (bidirecional). (O cabo poderia ser defeituoso também.) Veja ajustes da velocidade e duplexação para obter mais informações sobre das edições frente e verso. Recorde que cada contador de erros representa o número de pacotes que são deixados cair devido a esse erro particular. Se você vê um contador específico que incremente regularmente, o desempenho em seu PIX sofre muito provavelmente, e você deve encontrar a causa de raiz do problema.

Quando você examinar os contadores de interface, note que se a relação é ajustada FULL-frente e verso, você não deve experimentar nenhuns colisões, colisões atrasada, ou pacotes adiados. Inversamente, se a relação é ajustada metade-frente e verso, você deve receber colisões, alguns colisões atrasada, e possivelmente alguns pacotes adiados. O número total de colisões, de colisões atrasada, e de pacotes adiados não deve exceder 10% da soma dos contadores do pacote de entrada e saída. Se suas colisões excedem 10% de seu tráfego total, a seguir o link está utilizado, e você deve promover FULL-frente e verso ou a uma velocidade mais rápida (10 Mbps ao 100 Mbps). Recorde que as colisões do meio de 10% que o PIX deixa cair 10% dos pacotes que atravessam essa relação; cada um desses pacotes deve ser retransmitido.

Refira o comando interface nas referências de comando do Cisco secure PIX firewall para informações detalhadas sobre dos contadores de interface.

show processes

O comando show processes no PIX indica todos os processos ativo que são executado no PIX o comando é executado naquele tempo que. Esta informação é útil a fim determinar que processos recebem demasiado processador central - cronometre e que processos não recebem nenhum processador central - tempo. A fim obter esta informação, emita o comando show processes duas vezes; espere aproximadamente 1 minuto entre cada exemplo. Para o processo na pergunta, subtraia o valor de tempo de execução indicado na segunda saída do valor de tempo de execução indicado na primeira saída. Este resultado diz-lhe quanto processador central - cronometre (nos milissegundos) o processo recebido nesse intervalo do tempo. Note que alguns processos estão programados para ser executado em intervalos particulares, e alguns processos são executado somente quando têm a informação a processar. O processo 577poll tem muito provavelmente o valor de tempo de execução o maior de todos seus processos. Isto é normal porque o processo 577poll vota as interfaces Ethernet a fim considerar se têm algum dados que precisar de ser processado.

Nota: Um exame de cada processo PIX é fora do âmbito deste documento, mas é mencionado momentaneamente para a integralidade. Refira o comando show processes PIX para obter mais informações sobre dos processos PIX.

Resumo de comandos

Em resumo, use o comando show cpu usage a fim identificar a carga que o PIX está abaixo. Recorde que a saída é uma média do corredor; o PIX pode ter uns pontos mais altos do USO de CPU que sejam mascarados pela média do corredor. Uma vez que o PIX alcança o USO de CPU de 80%, a latência com o PIX aumenta lentamente a aproximadamente 90% CPU. Quando o USO de CPU é mais de 90%, o PIX começa deixar cair pacotes.

Se o USO de CPU é alto, use o comando show processes a fim identificar os processos que usam a maioria de processador central - tempo. Use esta informação a fim reduzir algum do tempo que é consumido pelos processos intensivos (como o registo).

Se o CPU não executa quente, mas você acredita que os pacotes estão deixados cair ainda, use o comando show interface a fim verificar a interface de PIX para ver se há sem bufferes e colisões, causada possivelmente por uma incompatibilidade duplex (bidirecional). Se os incrementos da contagem do sem buffer, mas o USO de CPU não são baixos, a relação não pode apoiar o tráfego que corre através d.

Se não houver problemas com os buffers, verifique os blocos. Se a coluna de CNT atual na saída dos blocos da mostra é próxima a 0 nos blocos 1550-byte (blocos 16384-byte para cartões da atuação 66 megahertz), o PIX deixa cair muito provavelmente pacotes de Ethernet porque é demasiado ocupado. Nesta instância, os aumentos de CPU altos.

Se você experimenta o problema quando você faz novas conexões com o PIX, use o comando show conn count a fim verificar o contagem atual de conexões com o PIX.

Se a contagem atual é alta, verifique a memória da mostra output a fim assegurar-se de que o PIX não seja executado fora da memória. Se a memória é baixa, investigue a fonte das conexões com o show conn ou o comando show local-host a fim verificar que sua rede não experimentou um ataque de recusa de serviço.

Você pode usar outros comandos a fim medir a quantidade de tráfego que passa com o PIX. O comando show traffic indica os pacotes e os bytes agregados pela relação, e o perfmon da mostra quebra o tráfego para baixo nos tipos diferentes que o PIX inspeciona.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 22040