Sécurité : Dispositifs de sécurité de la gamme Cisco PIX 500

PIX/ASA : Surveiller et dépanner les problèmes de performance

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit les commandes PIX/ASA que vous pouvez utiliser pour observer et diagnostiquer les performances d'un dispositif de sécurité de la gamme Cisco PIX 500/ASA 5500.

Remarque: Référez-vous à ASA 8.3 et plus tard : Surveillez et dépannez les problèmes de performance pour le dépannage semblable sur l'appliance de sécurité adaptable Cisco (ASA) avec la version 8.3 et ultérieures.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur le logiciel pare-feu Cisco PIX versions 6.2(1) et ultérieures.

Remarque: Les informations contenues dans ce document peuvent également être utilisées avec le dispositif de sécurité de la gamme Cisco ASA 5500 pour versions 7.x et ultérieures.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Dépannez

Pour le dépannage des problèmes de performance, vérifiez les domaines de base décrits dans cette section.

Remarque: Si vous avez accès aux sorties de la commande show émises par votre périphérique Cisco, vous pouvez utiliser l'outil Interpréteur de sortie (réservé aux clients enregistrés) afin d'afficher les problèmes potentiels et leurs correctifs. L'outil Interpréteur de sortie peut traiter certaines commandes show. Pour utiliser l'outil Interpréteur de sortie, vous devez être un client enregistré, vous devez être connecté à votre compte Cisco et vous devez avoir activé Javascript sur votre navigateur.

Paramètres de vitesse et de duplex

Le dispositif de sécurité est préconfiguré pour détecter automatiquement les paramètres de vitesse et de duplex sur une interface. Cependant, il existe certaines situations qui peuvent faire échouer le processus de négociation automatique et qui peuvent provoquer une disparité dans la vitesse ou le duplex (et créer des problèmes de performances). Pour une infrastructure réseau à fonction critique, Cisco va manuellement coder en dur la vitesse et le duplex sur chaque interface afin d'éviter tout risque d'erreur. Ces périphériques sont en général assez fixes, donc si vous les configurez correctement, vous ne devriez pas avoir à les changer.

Quel que soit le périphérique réseau, la vitesse peut être détectée, mais le duplex doit être négocié. Si deux périphériques réseau sont configurés pour négocier automatiquement la vitesse et le duplex, ils vont s'échanger des trames (appelées Fast Link Pulses, ou FLP) qui vont annoncer leurs capacités de vitesse et de duplex. Au regard d'un partenaire de liaison incompatible, ces impulsions sont similaires à des trames habituelles de 10 Mbps. Au regard d'un partenaire de liaison capable de décoder les impulsions, les FLP contiennent tous les paramètres de vitesse et de duplex que le partenaire de liaison peut fournir. La station qui reçoit les FLP va reconnaître les trames et les périphériques vont s'accorder mutuellement sur les paramètres de vitesse et de duplex les plus élevés qu'ils peuvent atteindre. Si un périphérique ne prend pas en charge la négociation automatique, ce sera l'autre périphérique qui se chargera de recevoir les FLP et de passer en mode de détection parallèle. Afin de détecter la vitesse du partenaire, le périphérique se met à l'écoute des longueurs d'impulsions pour définir ensuite la vitesse en conséquence. Le problème surgit lors de la configuration du duplex. Étant donné que le duplex doit être négocié, le périphérique en charge de la négociation automatique ne pourra pas déterminer les paramètres sur l'autre périphérique et passera par défaut au mode semi-duplex, tel que stipulé dans la norme IEEE 802.3u.

Par exemple, si vous configurez l'interface PIX pour la négociation automatique et la connectez à un commutateur codé en dur pour 100 Mbps, duplex intégral, le PIX enverra les FLP. Cependant, le commutateur ne réagira pas, car il est codé en dur pour la vitesse et le duplex et ne participe pas à la négociation automatique. Du fait qu''il ne reçoit aucune réponse du commutateur, les transitions PIX passent au mode de détection parallèle et vont détecter la longueur des impulsions dans les trames envoyées par le commutateur. Autrement dit, le PIX va détecter que le commutateur est réglé sur 100 Mbps, et va donc définir la vitesse d'interface en conséquence. Cependant, du fait que le commutateur n'émet pas de FLP, le PIX ne saura pas déterminer si le commutateur peut tourner en duplex intégral et ira donc définir l'interface duplex en semi-duplex, tel que stipulé dans la norme IEEE 803.2u. Puisque le commutateur est codé en dur pour 100 Mbps et en duplex intégral, et que le PIX vient juste de négocier automatiquement vers 100 Mbps et en semi-duplex (tel que prévu), cela risque de créer une disparité qui pourrait poser des sérieux problèmes de performances.

Une vitesse ou une erreur de correspondance de duplex est le plus souvent indiquée quand les compteurs d'erreur sur les interfaces en question augmentent. Les erreurs les plus communes concernent la trame, les contrôles de redondance cyclique (crc) et les trames trop courtes. Si ces valeurs incrémentent sur votre interface, une vitesse/erreur de correspondance de duplex ou un problème de câblage se produit. Vous devez résoudre ce problème avant de continuer.

Exemple

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

Utilisation du CPU

Si vous observez une utilisation élevée du CPU, suivez les étapes suivantes pour résoudre le problème :

  1. Vérifiez que le nombre de connexions dans la commande show xlate count est bas.

  2. Vérifiez que le bloc mémoire est normal.

  3. Vérifiez que le nombre d'ACL est plus élevé.

  4. Lancez la commande show memory detail et vérifiez que la mémoire utilisée par le PIX est en utilisation normale.

  5. Vérifiez que les nombres dans les commandes show processes cpu-hog et show processes memory sont normaux.

  6. Tout hôte se trouvant à l'intérieur ou à l'extérieur de l'appliance de sécurité peut générer le trafic malveillant ou de masse qui peut être un trafic de diffusion/de multidiffusion et entraîner l'utilisation élevée du CPU. Afin de résoudre ce problème, configurez une liste d'accès pour refuser le trafic entre les hôtes (de bout en bout) et pour vérifier l'utilisation.

  7. Vérifiez les paramètres de duplex et de vitesse dans les interfaces PIX. Le paramètre de non-correspondance avec les interfaces distants peut augmenter l'utilisation du CPU.

    Cet exemple montre le nombre plus élevé d'erreur en entrée et de dépassements dus à la non-correspondance de la vitesse. Employez la commande show interface afin de vérifier les erreurs :

    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
    

    Afin de résoudre ce problème, définissez la vitesse sur auto sur l'interface correspondante.

    Remarque: Le routage Cisco recommande que vous activiez la commande d'interface ip verify reverse-path sur toutes les interfaces, car elle abandonnera les paquets qui n'ont pas une source adresse valide, ce qui entraîne une utilisation moins intensive du CPU. Ceci s'applique à FWSM faisant face aux questions élevées CPU.

  8. Une autre raison pour l'utilisation élevée du CPU peut être due à un trop grand nombre d'itinéraires de multidiffusion. Lancez la commande show mroute afin de vérifier si PIX/ASA reçoit trop d'itinéraires de multidiffusion.

  9. Utilisez la commande show local-host afin de vérifier si le réseau rencontre une attaque de déni de service, qui peut signaler une attaque virale dans le réseau.

    Remarque: L'activité élevée CPU pourrait se produire en raison de la question décrite dans la CPU de haute quand le niveau de nameif/Sécurité a changé pour la nouvelle interface (clients enregistrés seulement). Référez-vous au pour en savoir plus de l'ID de bogue Cisco CSCsq48636 (clients enregistrés seulement).

Remarque: Si la solution fournissait en haut ne résout pas le problème, améliorent la plate-forme ASA selon les conditions requises. Référez-vous à la fiche technique de Dispositifs de sécurité adaptatifs dédiés de la gamme Cisco ASA 5500 pour plus d'informations sur des capacités et des capacités de plate-forme d'appliance de sécurité adaptable. Entrez en contact avec TAC (clients enregistrés seulement) pour de plus amples informations.

Utilisation élevée de la mémoire

Voici quelques causes possibles et résolutions pour l'utilisation élevée de la mémoire :

  • Journalisation des événements : La journalisation des événements peut consommer une grande quantité de mémoire. Afin de résoudre ce problème, installez et consignez tous les événements vers un serveur externe, tel qu'un serveur syslog.

  • Fuite de mémoire : Un problème identifié dans le logiciel d'appliance de sécurité peut mener à une consommation élevée de mémoire. Afin de résoudre ce problème, mettez à niveau le logiciel d'appliance de sécurité.

  • Débogage activé : Le débogage peut consommer une grande quantité de mémoire. Afin de résoudre ce problème, désactivez le débogage à l'aide de la commande undebug all.

  • Blocage des ports : Le blocage des ports sur l'interface externe d'une appliance de sécurité entraîne une très grande consommation de mémoire au niveau de l'appliance de sécurité afin de bloquer les paquets à travers les ports spécifiés. Afin de résoudre ce problème, bloquez le trafic de routage offensant du côté de l'ISP.

  • Menace-détection : La fonctionnalité de détection de menace se compose de différents niveaux de collecte de statistiques pour différentes menaces, aussi bien que de la détection de menaces d'analyse, qui détermine quand un hôte effectue une analyse. Désactivez cette fonctionnalité pour consommer moins de mémoire.

PortFast, transmission et liaison de jonction

Par défaut, beaucoup de commutateurs, tels que les commutateurs Cisco qui exécutent le système d'exploitation (SE) de Catalyst, sont conçus pour être des périphériques prêts à l'emploi. Ainsi, plusieurs des paramètres de port par défaut ne sont pas souhaitables quand un PIX est branché au commutateur. Par exemple, sur un commutateur qui exécute le système d'exploitation de Catalyst, la transmission par défaut et la liaison de jonction sont définies sur Auto et PortFast est désactivé. Si vous connectez un PIX à un commutateur qui exécute le système d'exploitation de Catalyst, désactivez la transmission et la liaison de jonction, et activez PortFast.

La transmission, également connue sous le nom de Fast EtherChannel ou Giga EtherChannel, est utilisée pour relier deux ports physiques ou plus dans un groupe logique afin d'augmenter le débit global à travers la liaison. Quand un port est configuré pour la transmission automatique, il envoie des trames de Protocole d'agrégation de ports (PAgP) pendant que la liaison devient active afin de déterminer s'il fait partie d'un canal. Ces trames peuvent poser des problèmes de routage si un autre périphérique tente de négocier automatiquement la vitesse et le duplex de la liaison. Si la transmission sur le port est définie sur Auto, elle entraîne également un retard supplémentaire d'environ 3 secondes avant que le port commence à transférer le trafic de routage après que la liaison est établie.

Remarque: Sur les commutateurs Catalyst de la série XL, la transmission n'est pas définie par défaut sur Auto. Pour cette raison, vous devez désactiver la transmission sur n'importe quel port de commutation qui se connecte à un PIX.

La liaison de jonction, également connue par les protocoles classiques de jonction Inter-Switch Link (ISL) ou Dot1q, combine plusieurs LAN virtuels (VLAN) sur un port (ou une liaison) unique. La liaison de jonction est typiquement utilisée entre deux commutateurs lorsque les deux ont plus d'un VLAN défini sur eux. Quand un port est configuré pour la liaison de jonction automatique, il envoie des trames Dynamic Trunking Protocol (DTP) pendant que la liaison s'établit afin de déterminer si le port auquel elle se connecte veut effectuer une jonction. Ces trames DTP peuvent poser des problèmes de routage avec la négociation automatique de liaison. Si la liaison de jonction est définie sur Auto sur un port de commutation, elle ajoute un retard supplémentaire d'environ 15 secondes avant que le port commence à transférer le trafic de routage après que la liaison est établie.

PortFast, également connu sous le nom de Fast Start, est une option qui informe le commutateur qu'un périphérique de la couche 3 est connecté hors d'un port de commutation. Le port n'attend pas le routage par défaut de 30 secondes (15 secondes à écouter et 15 secondes à apprendre) ; au lieu de cela, cette action pousse le commutateur à mettre le port en état de transmission juste après que la liaison est établie. Il est important de comprendre que, quand vous activez PortFast, le spanning-tree n'est pas désactivé. Le spanning-tree est encore en activité sur ce port. Quand vous activez PortFast, le commutateur est seulement informé qu'il n'y a pas un autre commutateur ou routeur (périphérique de couche 2 uniquement) connecté à l'autre bout de la liaison. Le commutateur contourne le retard habituel de 30 secondes pendant qu'il essaie de déterminer si une boucle de routage de la couche 2 donne des résultats si elle apporte ce port. Après que la liaison soit évoquée, elle continue de participer au spanning-tree. Le port envoie les unités BPDU (bridge packet data units) et le commutateur écoute toujours les BPDU sur ce port. Pour ces raisons, il est recommandé que vous activiez PortFast sur n'importe quel port de commutation qui se connecte à un PIX.

Remarque: Les versions du système d'exploitation pour Catalyst 5.4 et ultérieures incluent la commande set port host <mod>/<port> qui permet d'utiliser une commande simple pour désactiver la transmission et la liaison de jonction, et activer PortFast.

Traduction d'adresses réseau (NAT)

Toutes les sessions qui se connectent par l'appliance de sécurité doivent subir une certaine forme de traduction d'adresses de réseau ou NAT. À chaque session NAT ou de surcharge NAT (PAT) est attribuée un emplacement de routage de traduction connu sous le nom de xlate. Ces xlate peuvent persister même après des modifications apportées aux règles NAT qui les affectent. Ceci peut entraîner une pénurie en matière d'emplacements ou de comportement inhabituel de routage de traduction ou à chacun des deux par le trafic qui subit le routage de traduction. Cette section explique comment afficher et effacer des xlate sur l'appliance de sécurité.

Remarque: Veillez toujours à supprimer les xlate après avoir ajouté, modifié ou supprimer les commandes aaa-server, access-list, alias, global, nat, route, ou les commandes statiques de votre configuration.

attention Attention : Une interruption momentanée de l'écoulement de tout le trafic de routage par le périphérique peut se produire quand vous supprimez globalement des xlate sur l'appliance de sécurité.

Exemple de configuration PIX pour PAT utilisant l'adresse IP externe de l'interface :

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

Le trafic qui traverse l'appliance de sécurité passe très probablement par un NAT. Afin d'afficher les routages de traduction qui sont en service sur l'appliance de sécurité, lancez la commande 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

Les emplacements de routage de traduction peuvent persister après avoir effectué des modifications majeures. Afin d'effacer les emplacements actuels de routage de traduction sur l'appliance de sécurité, lancez la commande clear xlate :

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

La commande clear xlate efface toute la traduction dynamique actuelle de la table de routage de xlate. Afin d'effacer un routage de traduction particulier d'IP, vous pouvez utiliser la commande clear xlate avec le mot clé de l'[adresse ip] global.

Voici un exemple de configuration PIX pour NAT :

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

Observez le résultat de show xlate pour le routage de traduction de 10.2.2.2 interne à 10.10.10.10 globale externe :

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

Effacez le routage de traduction pour l'adresse IP globale 10.10.10.10 :

pixfirewall# clear xlate global 10.10.10.10

Dans cet exemple, le routage de traduction de 10.2.2.2 interne à 10.10.10.10 globale externe a disparu :

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

Quand vous effacez des emplacements de routage de traduction, soyez sûr de prendre en considération les différents types de routages de traduction :

  • Un xlate statique est un xlate persistant qui est créé avec la commande statique. Afin d'enlever les xlate statiques, vous devez supprimer la commande statique de la configuration. La commande clear xlate ne supprime pas la règle statique de routage de traduction. Si vous supprimez une commande statique de la configuration, les connexions préexistantes qui utilisent la règle statique peuvent encore transférer le trafic de routage. Employez la commande clear local-host afin de désactiver ces connexions.

  • Un xlate dynamique est un xlate créé à la demande créé avec le traitement du trafic de routage (par la commande nat ou global). La commande clear xlate enlève les xlate dynamiques et leurs connexions associées. Si vous enlevez une commande nat ou global de la configuration, le xlate dynamique et les connexions associées peuvent rester actifs.

Syslog

Les Syslog permettent de dépanner les problèmes sur le PIX. Cisco offre un serveur syslog gratuit pour Windows NT, appelé PIX Firewall Syslog Server (PFSS). Vous pouvez télécharger PFSS de la page de téléchargements de logiciels (clients enregistrés seulement).

Plusieurs autres fournisseurs, tels que Kiwi Enterprises , offrent des serveurs syslog pour différentes plates-formes Windows, telles que Windows 2000 et Windows XP.leavingcisco.com La plupart des machines UNIX et Linux ont des serveurs syslog installés par défaut.

Quand vous installez le serveur syslog, configurez le PIX pour pouvoir lui envoyer les journaux.

Exemple :

logging on
logging host <ip_address_of_syslog_server>
logging trap debugging

Remarque: Cet exemple configure le PIX pour envoyer le débogage (niveau 7) et des syslog plus critiques au serveur syslog. Comme ces journaux PIX sont les plus détaillés, utilisez-les seulement quand vous dépannez un problème. Pour une opération normale, configurez le niveau de journalisation sur Warning (niveau 4) ou Error (niveau 3).

Si vous éprouvez un problème de ralentissement des performances, ouvrez Syslog dans un fichier texte et recherchez l'adresse IP source liée au problème de performances. (Si vous utilisez UNIX, vous pouvez utiliser le programme grep par Syslog pour l'adresse IP de la source.) Recherchez les messages qui indiquent que le serveur externe a essayé d'accéder à l'adresse IP interne sur le port TCP 113 (pour le protocole d'identification, ou Ident), mais le PIX a refusé le paquet. Le message devrait être semblable à l'exemple suivant :

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

Si vous recevez ce message, lancez la commande service reset inbound du PIX. Le PIX n'abandonne pas silencieusement des paquets ; au lieu de cela, cette commande pousse le PIX à immédiatement réinitialiser n'importe quelle connexion en entrée refusée par la politique de sécurité. Le serveur n'attend pas le paquet Ident pour arrêter sa connexion TCP ; au lieu de cela, elle reçoit immédiatement un paquet de réinitialisation. Consultez la section Problèmes de performances PIX occasionnés par le protocole IDENT pour plus d'informations sur le PIX et Ident.

Recherches DNS inversées

Si vous observez un ralentissement des performances du PIX, vérifiez que vous avez des enregistrements de pointeur du Système de noms de domaine (DNS PTR), également connus sous le nom d'enregistrements de recherche DNS inversée, dans le serveur DNS de référence pour les adresses externes que le PIX utilise. Ceci inclut n'importe quelle adresse de votre pool global de Traduction d'adresses de réseau (NAT) (ou l'interface externe PIX si vous surchargez sur l'interface), n'importe quelle adresse statique et adresse interne (si vous n'utilisez pas de NAT avec elles). Quelques applications, telles que le Protocole de transfert de fichiers (FTP) et les serveurs Telnet, peuvent employer des recherches DNS inversées afin de déterminer l'origine de l'utilisateur et s'il s'agit d'un hôte valide. Si la recherche DNS inversée ne la résout pas, alors des performances se sont dégradées pendant que la requête de routage s'arrête.

Afin de s'assurer qu'un enregistrement PTR existe pour ces hôtes, lancez la commande nslookup de votre PC ou de votre ordinateur UNIX ; incluez l'adresse IP globale que vous utilisez pour vous connecter au routage Internet.

Exemple

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

Vous devez recevoir une réponse en retour avec le nom de DNS du périphérique attribué à cette adresse IP. Si vous ne recevez pas de réponse, contactez la personne qui contrôle votre DNS afin de demander l'ajout des enregistrements PTR pour chacune de vos adresses IP globales. Consultez la section Performances FTP/HTTP faibles ou intermittentes via un PIX pour plus d'informations sur des problèmes de performances du PIX, causés par les enregistrements PTR perdus.

Dépassements de capacité sur l'interface

Si vous avez une rafale du trafic, les paquets lâchés peuvent se produire si la rafale dépasse la capacité tampon du tampon FIFO sur le NIC et les mémoires tampons de sonnerie de réception. L'activation des trames de pause pour le contrôle de flux peut alléger cette question. La pause (XOFF) et les trames XON sont générées automatiquement par le matériel NIC basé sur l'utilisation de tampon FIFO. Une trame de pause est envoyée quand l'utilisation de mémoire tampon dépasse la marque des grandes marées. Pour activer des trames de la pause (XOFF) pour le contrôle de flux, utilisez la commande suivante :

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

Référez-vous à activer l'interface physique et à configurer le pour en savoir plus de paramètres d'Ethernets.

Commandes show

show cpu usage

La commande show cpu usage a été introduite dans un premier temps dans PIX 6.0(1) et utilisée pour déterminer la charge de trafic placée sur le CPU PIX. Aux moments où le trafic est maximal, le réseau connaît des poussées d'activités ou des attaques et l'utilisation du CPU peut atteindre des pics.

Le PIX a un CPU simple pour traiter un grand choix de tâches ; par exemple, il traite des paquets et imprime des messages de débogage à la console. Chaque processus a sa propre raison de routage, et certains processus requièrent plus de temps du CPU que d'autres. Le cryptage est probablement le processus qui sollicite le plus le CPU. Ainsi, si votre PIX passe beaucoup de trafic de routage par des tunnels cryptés, vous devriez considérer un PIX plus rapide, une carte d'accélérateur de VPN (VAC) [Numéro de référence : PIX-VPN-ACCEL] pour le PIX ou un concentrateur VPN dédié, tel que le VPN 3000. Le VCA décharge le cryptage et le décryptage du CPU PIX et les effectue dans le matériel sur la carte. Ceci permet au PIX de crypter et de décrypter 100 Mbps de trafic de routage avec 3DES (cryptage à 168 bits).

La journalisation est un autre processus qui peut consommer une grande quantité de ressources système. Pour cette raison, il est recommandé de désactiver la console et la surveillance, et de mettre en mémoire tampon l'ouverture d'une session sur le PIX. Vous pouvez activer ces processus quand vous dépannez un problème de routage, mais désactivez-les pour les opérations quotidiennes, particulièrement si vous manquez de capacité de CPU. Il est également conseillé que l'utilisation de Syslog ou la journalisation par Protocole de gestion de réseau simple (SNMP) (historique de journalisation) soit définie au niveau 5 (Notification) ou inférieur. En outre, vous pouvez désactiver des ID spécifiques de messages syslog avec la commande no logging message <id_syslog>.

Le gestionnaire de dispositifs PIX (PDM) fournit également un graphique dans l'onglet de surveillance et qui permet d'afficher l'utilisation du CPU du PIX au fil du temps. Vous pouvez employer ce graphique afin de déterminer la charge sur votre PIX.

La commande show cpu usage peut être utilisée pour afficher des statistiques d'utilisation du CPU.

Exemple

pixfirewall#show cpu usage

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

Description du résultat

Ce tableau décrit les champs dans le résultat de show cpu usage .

Champ Description
Utilisation du CPU pendant 5 secondes Utilisation du CPU pendant les cinq dernières secondes.
1 minute Moyenne d'exemples d'utilisation sur 5 secondes du CPU au cours de la dernière minute
5 minutes Moyenne d'exemples d'utilisation sur 5 secondes du CPU au cours des cinq dernières minutes

show traffic

La commande show traffic montre la quantité de trafic de routage qui traverse le PIX sur une période donnée. Les résultats sont basés sur le délai depuis que la commande a été lancée pour la dernière fois. Pour des résultats exacts, lancez d'abord la commande clear traffic, puis attendez 1 à 10 minutes avant de lancer la commande show traffic. Vous pouvez également lancer la commande show traffic et attendre 1 à 10 minutes avant de lancer la commande de nouveau, mais seul le résultat de la deuxième instance est valide.

Vous pouvez utiliser la commande show traffic afin de déterminer la quantité de trafic de routage traversant votre PIX. Si vous avez plusieurs interfaces, la commande peut vous aider à déterminer les interfaces qui envoient et qui reçoivent la plupart des données. Pour des appliances PIX avec deux interfaces, la somme de trafics en entrée et en sortie sur l'interface externe doit être égale à la somme de trafics en entrée et en sortie sur l'interface interne.

Exemple

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

Si vous vous rapprochez du débit évalué ou si vous l'atteignez sur une de vos interfaces, vous devez mettre à niveau vers une interface plus rapide ou limiter le niveau de trafic entrant ou sortant de cette interface. Si vous ne le faites pas, des paquets risquent d'être abandonnés. Comme expliqué dans la section show interface, vous pouvez examiner les compteurs de l'interface afin de découvrir les détails concernant le débit.

show perfmon

La commande show perfmon est utilisée pour contrôler la quantité et les types de trafics que le PIX inspecte. Cette commande est la seule façon de déterminer le nombre de routages de traduction (xlate) et de connexions (conn) par seconde. Les connexions sont encore décomposées en connexions TCP et connexions de Protocole de datagramme utilisateur (UDP). Voir la section description du résultat pour des descriptions du résultat que cette commande génère.

Exemple

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

Description du résultat

Ce tableau décrit les champs dans le résultat de show perfmon.

Champ Description
Xlates Routages de traduction accumulés par seconde
Connexions Connexions établies par seconde
Conn. TCP Connexions TCP par seconde
Conn. UDP Connexions UDP par seconde
Accès URL Nombre d'URL (sites Web) accédés par seconde
Dem. au serveur URL Demandes envoyées à Websense et à N2H2 par seconde (requiert la commande filter)
Correction de TCP Nombre de paquets TCP que le PIX transfère par seconde
TCPIntercept Nombre de paquets SYN par seconde qui ont dépassé la limite embryonnaire fixée sur un routage statique
Correction de HTTP Nombre de paquets destinés au port 80 par seconde (requiert la commande fixup protocol http)
Correction de FTP Commandes FTP inspectées par seconde
Authen AAA Demandes d'authentification par seconde
Auteur AAA Demandes d'autorisation par seconde
Compte AAA Demandes de compte par seconde

show blocks

Avec la commande show cpu usage , vous pouvez utiliser la commande show blocks afin de déterminer si le PIX est surchargé.

Blocs de traitement de paquet (1 550 et 16 384 octets)

Quand il entre dans l'interface PIX, un paquet est placé sur la file d'attente d'interface d'entrée, passé jusqu'au système d'exploitation et placé dans un bloc. Pour des paquets Ethernet, les blocs de 1 550 octets sont utilisés ; si le paquet arrive sur une carte Gigabit Ethernet de 66 MHz, les blocs 16 384 octets sont utilisés. Le PIX détermine si le paquet est autorisé ou refusé en fonction de l'algorithme de sécurité adaptatif (ASA) et le traite via la file d'attente de sortie sur l'interface de sortie. Si le PIX ne peut pas gérer la charge de trafic, le nombre de blocs de 1 550 octets disponibles (ou blocs de 16 384 octets pour 66 MHz GE) se rapproche de 0 (suivant les indications de la colonne CNT du résultat de la commande). Quand la colonne CNT arrive à zéro, le PIX tente d'allouer plus de blocs, jusqu'à un maximum de 8 192. Si aucun autre bloc n'est disponible, le PIX abandonne le paquet.

Basculement et blocs Syslog (256 octets)

Les blocs de 256 octets sont principalement utilisés pour des messages de basculement dynamique. Le PIX actif génère et envoie des paquets vers le PIX de secours afin de mettre à jour le routage de traduction et la table de routage de connexions. Pendant les périodes de salve de trafic où des haut débits de connexions sont créés ou interrompus, le nombre de blocs de 256 octets disponibles peut chuter à 0. Cet abandon indique qu'un ou plusieurs connexions ne sont pas mises à jour au PIX de secours. C'est généralement acceptable parce que la prochaine fois autour du protocole de basculement dynamique rattrape le xlate ou la connexion qui sont perdus. Cependant, si la colonne CNT pour les blocs de 256 octets demeure sur 0 ou dans les environs pendant des périodes prolongées, le PIX ne peut pas continuer avec les tables de routage de traduction et de connexion qui sont synchronisées en raison du nombre de connexions par seconde que le PIX traite. Si ceci se produit systématiquement, mettez à niveau le PIX vers un modèle plus rapide.

Les messages Syslog envoyés du PIX utilisent également les blocs de 256 octets, mais ils ne sont généralement pas publiés dans une quantité susceptible d'entraîner une pénurie dans le pool de blocs de 256 octets. Si la colonne CNT montre que le nombre de blocs de 256 octets est près de 0, assurez-vous que vous n'effectuez la journalisation en étant sur Debugging (niveau 7) sur le serveur syslog. Ceci est indiqué par la ligne de journalisation de la configuration PIX. Il est recommandé de définir la journalisation au maximum sur Notification (niveau 5), à moins que vous ayez besoin d'informations supplémentaires pour le débogage.

Exemple

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

Description du résultat

Ce tableau décrit les colonnes dans le résultat de show blocs.

Colonne Description
TAILLE Taille, en octets, du pool de blocs.
Max Le nombre maximal de blocs disponibles pour le pool de blocs avec les octets spécifiés. Notez que le nombre maximal de blocs sont découpés hors de la mémoire à l'amorçage. Généralement, le nombre maximal de blocs ne change pas. L'exception concerne les blocs de 256 et de 1 550 octets, où le PIX peut dynamiquement créer plus que nécessaire, jusqu'à un maximum de 8 192.
BAS Limite inférieure. Cette valeur est le nombre le plus peu bas de blocs de cette taille disponibles depuis que le PIX a été mis sous tension, ou depuis la dernière suppression de blocs avec la commande clear blocks.
CNT Le nombre actuel de blocs disponibles pour ce pool de blocs de cette taille spécifique.

Ce tableau décrit les valeurs de la ligne SIZE dans le résultat de la commande show blocks.

Valeur de SIZE Description
4 Utilisation afin de reproduire les blocs qui existent dans le DNS, l'Internet Security Association and Key Management Protocol (ISAKMP), le Filtrage URL, l'uauth, le h323, le tftp et les modules de routage de TCP.
80 Utilisation dans l'interception de TCP afin de générer des paquets d'accusé de réception (ACK) et pour des messages hello de basculement.
256 Utilisation pour des fonctions de mises à jour du routage de basculement dynamique, d'utilisation de Syslog et d'autres de TCP.
1550 Utilisation afin d'enregistrer les paquets Ethernet qui sont traités par le PIX.
16384 Utilisation uniquement pour les cartes Gigabit Ethernet de 64 bits, 66 MHz (i82543) dans le PIX 535.

show memory

La commande show memory affiche toute la mémoire physique (ou la RAM) du PIX, avec le nombre d'octets actuellement disponibles. Afin d'utiliser ces informations, vous devez d'abord comprendre comment le PIX utilise la mémoire. Quand le PIX démarre, il copie le système d'exploitation du flash dans la RAM et exécute le système d'exploitation de la RAM (juste comme des routeurs). Ensuite, le PIX copie la configuration de démarrage du flash et la place dans la RAM. Le PIX alloue enfin la RAM afin de créer les pools de blocs discutés dans la section show blocks. Une fois que cette allocation est complète, le PIX a besoin de RAM supplémentaire seulement si la configuration augmente en taille. En outre, le PIX enregistre les entrées de traduction et de connexion dans la RAM.

Pendant le fonctionnement normal, la mémoire libre sur le PIX ne doit changer que peu ou pas du tout. Généralement, le seul cas où vous aurez une faible capacité de mémoire est lorsque vous êtes soumis à des attaques et lorsque des centaines de milliers de connexions passent par le PIX. Afin de vérifier les connexions, lancez la commande show conn count , qui affiche le nombre maximal actuel de connexions passant par le PIX. Si le PIX manque de mémoire, il finit par tomber en panne. Avant de tomber en panne, vous risquez de voir des messages de défaillance d'allocation mémoire dans le Syslog (PIX-3-211001). Si vous manquez de mémoire parce que vous êtes soumis à des attaques, entrez en contact avec le Centre d'assistance technique Cisco (TAC).

Remarque: Quand Cisco ASA manque de mémoire, elle ne reçoit plus de nouvelles connexions VPN, relâche toutes les connexions existantes, et renvoie cette erreur de message d'erreur : %ASA-3-336003 : Aucune mémoires tampons disponibles pour le paquet d'octet de <bytes>.

Remarque: Employez la commande de mem d'exposition afin de vérifier l'allocation de ressources de mémoire et améliorer la mémoire s'il y a lieu. Si le problème persiste, contactez Cisco TAC pour davantage de dépannage.

Exemple

pixfirewall#show memory
1073741824 bytes total, 1022992384 bytes free

show xlate

La commande show xlate count affiche le nombre actuel et maximal de traductions par PIX. Une traduction est un mappage d'une adresse interne à une adresse externe et peut être un mappage un-à-un, tel que Traduction d'adresses de réseau (NAT), ou un mappage plusieurs-à-un tel que Traduction d'adresses de port (PAT). Cette commande est un sous-ensemble de la commande show xlate qui indique chaque traduction effectuée par le pare-feu PIX. La sortie de commande présente des traductions « in use », ce qui se rapporte au nombre de traductions actives dans le PIX lorsque la commande est émise ; « most used » se rapporte au maximum de traductions maximum observées sur le PIX depuis sa mise sous tension.

Remarque: Un hôte unique peut avoir plusieurs connexions vers différentes destinations, mais seulement une traduction. Si le nombre de xlate est nettement supérieur au nombre d'hôtes sur votre réseau interne, il est possible qu'un de vos hôtes internes ait été compromis. Si votre hôte interne a été compromis, il usurpe l'adresse source et envoie des paquets en dehors du PIX.

Remarque: Quand la configuration vpnclient est activée et l'hôte interne envoie des demandes DNS, la commande show xlate peut répertorier plusieurs xlate pour une traduction statique.

Exemple

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

Cet exemple montre le résultat de la commande show xlate detail avec trois Traductions d'adresses de port actif (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

La première entrée est une traduction d'adresses de port TCP pour le port de hôte (10.1.1.15, 1026) sur le réseau intérieur au port de hôte (192.150.49.1, 1024) sur le réseau extérieur. L'indicateur « r » dénote que la traduction est une traduction d'adresse de port. L'indicateur « i » dénote que la traduction s'applique au port interne de l'adresse.

La deuxième entrée est une traduction d'adresses de port UDP pour le port hôte (10.1.1.15, 1028) sur le réseau interne au port hôte (192.150.49.1, 1024) sur le réseau externe. L'indicateur « r » dénote que la traduction est une traduction d'adresse de port. L'indicateur « i » dénote que la traduction s'applique au port interne de l'adresse.

La troisième entrée est une traduction d'adresse de port ICMP pour l'id de l'hôte ICMP (10.1.1.15, 21505) sur le réseau interne à l'id de l'hôte ICMP (192.150.49.1, 0) sur le réseau externe. L'indicateur « r » dénote que la traduction est une traduction d'adresse de port. L'indicateur « i » dénote que la traduction s'applique au port interne de l'adresse.

Les champs internes d'adresse apparaissent comme adresses sources sur les paquets qui passent de l'interface plus sécurisée à l'interface moins sécurisée. Réciproquement, ils apparaissent comme adresses de destination sur les paquets qui passent de l'interface moins sécurisée à l'interface plus sécurisée.

show conn count

La commande show conn count montre le nombre maximal actuel de connexions passant par le PIX. Une connexion est un mappage des informations de la couche 4 d'une adresse interne à une adresse externe. Des connexions se construisent quand le PIX reçoit un paquet SYN pour des sessions TCP ou quand le premier paquet arrive dans une session UDP. Des connexions sont interrompues quand le PIX reçoit le paquet final ACK, qui se produit quand l'établissement de la session TCP se ferme ou quand le délai de la session UDP expire.

Les nombres extrêmement élevés de connexions (50 à 100 fois plus élevés) peuvent indiquer des attaques. Lancez la commande show memory afin de s'assurer que le nombre élevé de connexions n'entraîne un manque de capacité en mémoire pour le PIX. Si vous êtes soumis à des attaques, vous pouvez limiter le nombre maximal de connexions par entrée statique et également limiter le nombre maximal de connexions embryonnaires. Cette action protège vos serveurs internes et évite leur surcharge. Consultez la section Références des commandes du pare-feu Cisco Secure PIX Firewall pour plus d'informations.

Exemple

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

show interface

La commande show interface peut aider à déterminer des problèmes d'erreur de correspondance de duplex et des problèmes de câbles ; elle peut également fournir un meilleur aperçu si l'interface est dépassée. Si le PIX manque de capacité de CPU, le nombre de blocs de 1 550 octets se rapproche de 0. (Vérifiez les blocs de 16 384 octets sur les cartes Gig de 66 MHz.) Un autre indicateur est l'augmentation de « l'absence de mémoires tampon » sur l'interface. Ce message indique que l'interface ne peut pas envoyer le paquet au système d'exploitation PIX parce qu'il n'y a aucun bloc disponible pour le paquet, et le paquet est abandonné. En cas d'augmentation régulière des niveaux d'absence de mémoires tampon, lancez la commande show proc cpu afin de vérifier l'utilisation du CPU sur le PIX. Si l'utilisation du CPU est élevée en raison d'une charge de trafic intense, mettez à niveau vers un PIX plus puissant capable de gérer la charge.

Quand un paquet arrive dans une interface, il est d'abord placé dans la file d'attente matérielle d'entrée. Si la file d'attente matérielle d'entrée est pleine, le paquet est placé dans la file d'attente logicielle d'entrée. Le paquet est acheminé de sa file d'attente d'entrée au système d'exploitation PIX et placé dans un bloc de 1 550 octets (ou dans un bloc de 16 384 octets sur des interfaces Gigabit Ethernet de 66 MHz). Le PIX détermine ensuite l'interface de sortie pour le paquet et place le paquet dans la file d'attente matérielle appropriée. Si la file d'attente matérielle est pleine, le paquet est placé dans la file d'attente logicielle de sortie. Si les blocs maximaux dans l'une ou l'autre des files d'attente de logiciel sont grands, alors l'interface est débordée. Par exemple, si 200 Mbps arrivent dans le PIX et ressortent sur une seule interface de 100 Mbps, la file d'attente logicielle de sortie indique des nombres élevés sur l'interface de sortie, signalant que l'interface ne peut pas prendre en charge le volume de trafic. Si vous vous trouvez face à cette situation, mettez à niveau vers une interface plus rapide.

Exemple

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)

Vous devez également vérifier l'interface pour des erreurs. Si vous recevez des runts, des erreurs en entrée, des CRC, ou des erreurs de trame, il est probable que vous ayez une erreur de correspondance de duplex. (Le câble peut également être défectueux.) Voir la section Paramètres de vitesse et de duplex pour plus d'informations sur les problèmes de duplex. Souvenez-vous que chaque compteur d'erreur représente le nombre de paquets qui sont abandonnés en raison de cette erreur particulière. Si vous consultez un compteur spécifique qui fait régulièrement l'objet d'une incrémentation, les performances de votre PIX sont très probablement touchées, et vous devez rechercher la cause à l'origine du problème.

Pendant que vous examinez les compteurs d'interface, notez que si l'interface est définie en duplex intégral, vous ne devriez constater de collisions, de collisions tardives ou de paquets reportés. Réciproquement, si l'interface est définie en semi-duplex, vous devriez recevoir des collisions, quelques collisions tardives et probablement quelques paquets reportés. Le nombre total de collisions, de collisions tardives et de paquets reportés ne devrait pas être supérieur à 10 % de la somme de compteurs de paquet en entrée et en sortie. Si vos collisions dépassent 10 % de votre trafic total, alors la liaison est surchargée, et vous devez effectuer une mise à niveau en duplex intégral ou à une vitesse plus rapide (de 10 à 100 Mbps). Souvenez-vous que les collisions de 10 % signifie que le PIX abandonne 10 % des paquets qui passent par cette interface ; chacun de ces paquets doit être retransmis.

Consultez la commande interface dans la section Références des commandes du pare-feu Cisco Secure PIX Firewall pour des informations détaillées sur les compteurs d'interface.

show processes

La commande show processes + sur le PIX affiche tous les processus actifs qui fonctionnent sur le PIX au moment où la commande est exécutée. Ces informations de routage sont utiles pour déterminer les processus qui reçoivent trop de temps du CPU et ceux qui n'en reçoivent aucun. Afin d'obtenir ces informations, lancez la commande show processes deux fois ; attendez environ 1 minute entre chaque instance. Pour le processus en question, soustrayez la valeur d'exécution affichée dans le deuxième résultat de la valeur d'exécution affichée dans le premier résultat. Ce résultat indique le temps du CPU (en millisecondes) dédié au processus dans cet intervalle de temps. Notez que certains processus sont planifiés pour fonctionner à des intervalles particuliers, et une partie traite seulement le passage quand elles ont les informations à traiter. Le processus 577poll a très probablement la plus grande valeur d'exécution de tous vos processus. C'est normal parce que le processus 577poll interroge les interfaces Ethernet afin de déterminer si elles ont des données qui doivent être traitées.

Remarque: Un examen de chaque processus PIX ne rentre pas dans le cadre de ce document, mais est mentionné brièvement à des fins d'exhaustivité. Consultez la section Commande PIX show processes pour plus d'informations sur les processus PIX.

Résumé des commandes

En résumé, utilisez la commande show cpu usage afin d'identifier la charge à laquelle le PIX est assujettie. Souvenez-vous que le résultat est une moyenne d'exécution ; le PIX peut avoir des pointes plus élevées d'utilisation du CPU qui sont masquées par la moyenne d'exécution. Une fois que le PIX atteint l'utilisation du CPU de 80 %, la latence par le PIX grimpe lentement jusqu'à environ 90 % du CPU. Quand l'utilisation du CPU est supérieure à 90 %, le PIX commence à abandonner des paquets.

Si l'utilisation du CPU est élevée, utilisez la commande show processes afin d'identifier les processus qui utilisent la majorité du temps du CPU. Utilisez ces informations afin de réduire une partie du temps consommé par les processus intensifs (comme la journalisation).

Si le processeur ne s'exécute pas chaud, et que vous croyez que des paquets sont encore abandonnés, utilisez la commande show interface afin de vérifier si l'interface PIX ne rencontre des problèmes d'absence de mémoires tampon et de collision, causés éventuellement par une erreur de correspondance de duplex. Si le nombre d'absences de mémoire tampon augmente par incrément, et que l'utilisation du CPU n'est pas faible, l'interface ne peut pas prendre en charge le trafic qui la traverse.

Si les mémoires tampon n'ont aucun problème, vérifiez les blocs. Si la colonne actuelle de CNT dans le résultat de show blocks est proche de 0 sur les blocs de 1 550 octets (blocs de 16 384 octets pour les cartes Gig de 66 MHz), le PIX abandonne très probablement des paquets Ethernet parce qu'il est trop occupé. Dans ce cas, le processeur atteint un pic.

Si vous rencontrez des problèmes quand vous établissez de nouvelles connexions par le PIX, utilisez la commande show conn count afin de vérifier le nombre actuel de connexions passant par le PIX.

Si le nombre actuel est élevé, vérifiez le résultat de show memory afin de s'assurer que le PIX ne manque pas de mémoire. Si la capacité de mémoire est faible, étudiez la source des connexions avec la commande show conn ou show local-host pour vérifier que votre réseau n'a pas fait l'objet d'une attaque de déni de service.

Vous pouvez employer d'autres commandes afin de mesurer le niveau de trafic passant par le PIX. La commande show traffic affiche les paquets et les octets globaux par interface, et la commande show perfmon divise le trafic en différents types que le PIX inspecte.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 22040