ASA 8.3 et versions ultérieures : Surveiller et dépanner les problèmes de performance
Contenu
Introduction
Ce document fournit des informations sur les commandes ASA que vous pouvez utiliser pour surveiller et dépanner les performances d'un appareil de sécurité adaptatif (ASA) Cisco.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Les informations de ce document sont basées sur un appareil de sécurité adaptatif (ASA) Cisco qui exécute les versions 8.3 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. All of the devices used in this document started with a cleared (default) configuration. 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épannage
Pour le dépannage des problèmes de performance, vérifiez les domaines de base décrits dans cette section.
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 mode bidirectionnel doit être négocié, le périphérique configuré pour la négociation automatique ne peut pas déterminer les paramètres de l'autre périphérique. Par défaut, il est défini sur le mode bidirectionnel non simultané, comme indiqué dans la norme IEEE 802.3u.
Par exemple, si vous configurez l'interface ASA pour l'autonégociation et que vous la connectez à un commutateur codé en dur pour 100 Mbits/s et duplex intégral, l'ASA envoie des 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. Comme il ne reçoit aucune réponse du commutateur, l'ASA passe en mode de détection parallèle et détecte la longueur des impulsions dans les trames que le commutateur envoie. En d'autres termes, l'ASA détecte que le commutateur est réglé sur 100 Mbits/s, de sorte qu'il définit la vitesse d'interface en conséquence. Cependant, comme le commutateur n'échange pas de FLP, l'ASA ne peut pas détecter si le commutateur peut exécuter le mode bidirectionnel simultané, de sorte que l'ASA définit le mode bidirectionnel de l'interface en mode bidirectionnel non simultané, comme indiqué dans la norme IEEE 803.2u. Comme le commutateur est codé en dur à 100 Mbits/s et duplex intégral, et que l'ASA vient d'être autonégocié à 100 Mbits/s et semi-duplex (comme il se doit), il en résulte une incompatibilité de duplex qui peut causer de graves 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 GigabitEthernet0/0 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 0013.c480.b2b8, MTU 1500
IP address 192.168.17.4, subnet mask 255.255.255.0
311981 packets input, 20497296 bytes, 0 no buffer
Received 311981 broadcasts, 157 runts, 0 giants
379 input errors, 107 CRC, 273 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
121 packets output, 7744 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 1 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops, 0 tx hangs
input queue (blocks free curr/low): hardware (255/249)
output queue (blocks free curr/low): hardware (255/254)
Utilisation du CPU
Si vous avez remarqué que l'utilisation du processeur est élevée, procédez comme suit afin de dépanner :
- Vérifiez que le nombre de connexions dans la commande show xlate count est bas.
- Vérifiez que le bloc mémoire est normal.
- Vérifiez que le nombre d'ACL est plus élevé.
- Exécutez la commande show memory detail et vérifiez que la mémoire utilisée par l'ASA est une utilisation normale.
- Vérifiez que les nombres dans les commandes show processes cpu-hog et show processes memory sont normaux.
- 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.
- Vérifiez les paramètres de mode bidirectionnel et de vitesse dans les interfaces ASA. 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 :
Ciscoasa#sh int GigabitEthernet0/1 Interface GigabitEthernet0/1 "inside", is up, line protocol is up Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps) Input flow control is unsupported, output flow control is unsupported MAC address 0013.c480.b2b8, MTU 1500 IP address 192.168.17.4, subnet mask 255.255.255.0 311981 packets input, 20497296 bytes, 0 no buffer Received 311981 broadcasts, 157 runts, 0 giants 7186 input errors, 0 CRC, 0 frame, 7186 overrun, 0 ignored, 0 abort 0 pause input, 0 resume input 0 L2 decode drops 121 packets output, 7744 bytes, 0 underruns 0 pause output, 0 resume output 0 output errors, 0 collisions, 1 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops, 0 tx hangs input queue (blocks free curr/low): hardware (255/249) output queue (blocks free curr/low): hardware (255/254)Afin de résoudre ce problème, définissez la vitesse sur auto sur l'interface correspondante.
- Une autre raison pour l'utilisation élevée du CPU peut être due à un trop grand nombre d'itinéraires de multidiffusion. Émettez la commande show mroute afin de vérifier si ASA reçoit trop de routes de multidiffusion.
- 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.
- Une CPU élevée peut se produire en raison de l'ID de bogue Cisco CSCsq48636 . Référez-vous à l'ID de bogue Cisco CSCsq48636 (clients enregistrés uniquement) pour plus d'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'un dispositif de sécurité entraîne une consommation élevée de mémoire par le dispositif de sécurité pour bloquer les paquets via les ports spécifiés.Pour résoudre ce problème, bloquez le trafic offensant à l'extrémité du FAI.
- Détection des menaces : 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. De ce fait, de nombreux paramètres de port par défaut ne sont pas souhaitables lorsqu'un ASA est branché sur le 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 ASA à un commutateur qui exécute le système d'exploitation Catalyst, désactivez l'acheminement, désactivez l'agrégation 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.
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é d'activer PortFast sur n'importe quel port de commutateur qui se connecte à un ASA.
Traduction d'adresses réseau (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é.
Exemple de configuration ASA pour PAT qui utilise l'adresse IP de l'interface externe :
object network OBJ_GENERIC_ALL subnet 0.0.0.0 0.0.0.0 nat (inside,outside) source dynamic OBJ_GENERIC_ALL interface
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 :
Ciscoasa#show xlate
5 in use, 5 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from any:192.168.1.10 to any:172.16.1.1/24
flags s idle 277:05:26 timeout 0:00:00
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 :
Ciscoasa#clear xlate
Ciscoasa#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 ASA pour NAT :
object network inside-net subnet 0.0.0.0 0.0.0.0 object network outside-pat-pool range 10.10.10.10 10.10.10.100 nat (inside,outside) source dynamic inside-net outside-pat-pool
Observez le résultat de show xlate pour le routage de traduction de 10.2.2.2 interne à 10.10.10.10 globale externe :
Ciscoasa#show xlate 2 in use, 2 most used Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice TCP PAT from inside:10.2.2.2/1429 to any:10.10.10.10/64768 flags ri idle 62:33:57 timeout 0:00:30 TCP PAT from inside:10.5.5.5/1429 to any:10.10.10.11/64768 flags ri idle 62:33:57 timeout 0:00:30
Effacez le routage de traduction pour l'adresse IP globale 10.10.10.10 :
Ciscoasa# 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 :
Ciscoasa#show xlate 1 in use, 2 most used Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice TCP PAT from inside:10.5.5.5/1429 to any:10.10.10.11/64768 flags ri idle 62:33:57 timeout 0:00:30
SYSLOG
Les Syslogs vous permettent de résoudre les problèmes sur l'ASA. Cisco propose un serveur syslog gratuit pour Windows NT appelé ASA 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. 
La plupart des machines UNIX et Linux ont des serveurs syslog installés par défaut.
Lorsque vous configurez le serveur syslog, configurez l'ASA afin de lui envoyer des journaux.
Exemple :
logging on
logging host <ip_address_of_syslog_server>
logging trap debugging
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 tenté d'accéder à l'adresse IP interne sur le port TCP 113 (pour le protocole d'identification, ou Ident), mais l'ASA a refusé le paquet. Le message devrait être semblable à l'exemple suivant :
%ASA-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, émettez la commande service resetinbound à l'ASA. L'ASA ne supprime pas silencieusement les paquets ; au lieu de cela, cette commande entraîne la réinitialisation immédiate de toute connexion entrante refusée par la stratégie 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.
SNMP
La surveillance des performances de Cisco ASA à l'aide du protocole SNMP est la méthode recommandée pour les déploiements d'entreprise. Cisco ASA prend en charge la surveillance du réseau avec SNMP versions 1, 2c et 3.
Vous pouvez configurer l'appliance de sécurité pour envoyer des interruptions à un serveur de gestion de réseau (NMS) ou utiliser le NMS pour parcourir les MIB sur l'appliance de sécurité. Les MIB sont un ensemble de définitions et l'appliance de sécurité gère une base de données de valeurs pour chaque définition. Pour plus d'informations à ce sujet, référez-vous à Configuration de SNMP sur Cisco ASA.
Toutes les MIB prises en charge pour Cisco ASA se trouvent sur la liste de support MIB ASA. À partir de cette liste, ces MIB sont utiles pour la surveillance des performances :
- CISCO-FIREWALL-MIB — Contient des objets utiles pour le basculement
- CISCO-PROCESS-MIB — Contient des objets utiles pour l'utilisation du CPU
- CISCO-MEMORY-POOL-MIB — Contient des objets utiles pour les objets de mémoire.
Recherches DNS inversées
Si les performances de l'ASA sont lentes, vérifiez que vous disposez d'enregistrements PTR (Domain Name System Pointer), également appelés enregistrements Reverse DNS Lookup, sur le serveur DNS faisant autorité pour les adresses externes utilisées par l'ASA. Cela inclut toute adresse dans votre pool NAT (Network Address Translation) global (ou l'interface externe ASA si vous surchargez l'interface), toute adresse statique et toute adresse interne (si vous n'utilisez pas NAT avec eux). 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.
Dépassements sur l'interface
Si vous avez une rafale de trafic, des paquets abandonnés peuvent se produire si la rafale dépasse la capacité de la mémoire tampon FIFO sur la carte réseau et les tampons de sonnerie de réception. L'activation des trames de pause pour le contrôle de flux peut atténuer ce problème. Les trames Pause (XOFF) et XON sont générées automatiquement par le matériel de la carte réseau en fonction de l'utilisation de la mémoire tampon FIFO. Une trame de pause est envoyée lorsque l'utilisation de la mémoire tampon dépasse la limite supérieure. Afin d'activer les trames de pause (XOFF) pour le contrôle de flux, utilisez cette commande :
hostname(config)#interface tengigabitethernet 1/0 hostname(config-if)# flowcontrol send on
Référez-vous à Activation de l'interface physique et configuration des paramètres Ethernet pour plus d'informations.
Commandes show
show cpu usage
La commande show cpu usage est utilisée pour déterminer la charge de trafic placée sur le processeur ASA. 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.
L'ASA dispose d'un processeur unique pour traiter une variété 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 le plus intensif en CPU. Par conséquent, si votre ASA achemine beaucoup de trafic via des tunnels cryptés, vous devriez envisager un ASA plus rapide, un concentrateur VPN dédié, tel que le VPN 3000. Le VAC décharge le chiffrement et le déchiffrement du processeur ASA et l'exécute dans le matériel de la carte. Cela permet à l'ASA de chiffrer et de déchiffrer 100 Mbits/s de trafic 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 journalisation de la console, du moniteur et de la mémoire tampon sur l'ASA. 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>.
Cisco Adaptive Security Device Manager (ASDM) fournit également un graphique sur l'onglet Surveillance qui vous permet d'afficher l'utilisation du processeur de l'ASA au fil du temps. Vous pouvez utiliser ce graphique afin de déterminer la charge sur votre ASA.
La commande show cpu usage peut être utilisée pour afficher des statistiques d'utilisation du CPU.
Exemple
Ciscoasa#show cpu usage CPU utilization for 5 seconds = 1%; 1 minute: 2%; 5 minutes: 1%
Affichage de l'utilisation du processeur sur ASDM
Complétez ces étapes afin d'afficher l'utilisation du CPU sur l'ASDM :
- Accédez à Monitoring > Properties > System Resources Graphics > CPU dans ASDM et choisissez le titre de la fenêtre de graphique. Ensuite, choisissez les graphiques requis dans la liste des graphiques disponibles et cliquez sur Ajouter comme indiqué.
- Une fois le nom de graphique requis ajouté sous la section Graphiques sélectionnés, cliquez sur Afficher les graphiques.
L'image suivante montre le graphique Utilisation du processeur sur l'ASDM. Différentes vues de ce graphique sont disponibles et peuvent être modifiées en sélectionnant la vue dans la liste déroulante Vue. Ce résultat peut être imprimé ou enregistré sur l'ordinateur selon les besoins.
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 indique la quantité de trafic qui passe par l'ASA 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 combien de trafic passe par votre ASA. 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 les appliances ASA avec deux interfaces, la somme du trafic entrant et sortant sur l'interface externe doit être égale à la somme du trafic entrant et sortant sur l'interface interne.
Exemple
Ciscoasa#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 permet de surveiller la quantité et les types de trafic inspectés par l'ASA. 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 l'ASA transfère par seconde |
| Interception TCPI | 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 l'ASA est surchargé.
Blocs de traitement de paquet (1 550 et 16 384 octets)
Lorsqu'il entre dans l'interface ASA, un paquet est placé sur la file d'attente de l'interface d'entrée, transmis 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. L'ASA détermine si le paquet est autorisé ou refusé en fonction de l'algorithme de sécurité adaptatif (ASA) et traite le paquet jusqu'à la file d'attente de sortie sur l'interface de sortie. Si l'ASA ne peut pas prendre en charge la charge du trafic, le nombre de blocs de 1 550 octets disponibles (ou de blocs de 1 6384 octets pour GE de 66 MHz) est proche de 0 (comme indiqué dans la colonne CNT du résultat de la commande). Lorsque la colonne CNT atteint zéro, l'ASA tente d'allouer plus de blocs, jusqu'à un maximum de 8192. Si aucun autre bloc n'est disponible, l'ASA abandonne le paquet.
Basculement et blocs Syslog (256 octets)
Les blocs de 256 octets sont principalement utilisés pour des messages de basculement dynamique. L'ASA actif génère et envoie des paquets à l'ASA de secours afin de mettre à jour la table de traduction et de connexion. 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. Cette perte indique qu'une ou plusieurs connexions ne sont pas mises à jour vers l'ASA 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 reste à 0 ou près pendant de longues périodes, l'ASA ne peut pas suivre les tables de traduction et de connexion qui sont synchronisées en raison du nombre de connexions par seconde traitées par l'ASA. Si cela se produit de manière cohérente, mettez à niveau l'ASA vers un modèle plus rapide.
Les messages Syslog envoyés à partir de l'ASA utilisent également les blocs de 256 octets, mais ils ne sont généralement pas libérés en une quantité telle qu'ils provoquent une épuisement du 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 déroutement de journalisation dans la configuration ASA. 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
Ciscoasa#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 E, en octets, du pool de blocs. Chaque taille représente un type particulier |
| MAXIMUM | Nombre maximal de blocs disponibles pour le pool de blocs d'octets spécifié. Le nombre maximal de blocs est découpé en mémoire au démarrage. Généralement, le nombre maximal de blocs ne change pas. L'exception concerne les blocs de 256 et 1 550 octets, où l'appliance de sécurité adaptative peut créer dynamiquement plus lorsque nécessaire, jusqu'à un maximum de 8 192. |
| FAIBLE | Limite basse. Ce nombre indique le nombre le plus faible de blocs de cette taille disponibles depuis la mise sous tension de l'appliance de sécurité adaptative ou depuis la dernière suppression des blocs (avec la commande clear blocks). Un zéro dans la colonne FAIBLE indique un événement précédent où la mémoire était pleine. |
| CNT | Nombre actuel de blocs disponibles pour ce pool de blocs de taille spécifique. Un zéro dans la colonne CNT signifie que la mémoire est saturée maintenant. |
Ce tableau décrit les valeurs de la ligne SIZE dans le résultat de la commande show blocks.
| Valeur de SIZE | Description |
|---|---|
| 0 | Utilisé par des blocs dupb. |
| 4 | Duplique les blocs existants dans des applications telles que DNS, ISAKMP, le filtrage des URL, uauth, TFTP et les modules TCP. En outre, ce bloc de taille peut être utilisé normalement par le code pour envoyer des paquets aux pilotes, etc. |
| 80 | Utilisé dans l'interception TCP pour générer des paquets d'accusé de réception et pour les messages Hello de basculement. |
| 256 | Utilisé pour les mises à jour de basculement dynamique, la journalisation syslog et d'autres fonctions TCP. Ces blocs sont principalement utilisés pour les messages de basculement dynamique. L'appliance de sécurité adaptative active génère et envoie des paquets à l'appliance de sécurité adaptative de secours pour mettre à jour la table de traduction et de connexion. Dans le trafic en rafale, où des débits élevés de connexions sont créés ou détruits, le nombre de blocs disponibles peut chuter à 0. Cette situation indique qu'une ou plusieurs connexions n'ont pas été mises à jour vers le dispositif de sécurité adaptatif de secours. Le protocole de basculement dynamique récupère la traduction ou la connexion manquante la prochaine fois. Si la colonne CNT pour les blocs de 256 octets reste à 0 ou à proximité pendant de longues périodes, alors l'appliance de sécurité adaptative a du mal à maintenir la synchronisation des tables de traduction et de connexion en raison du nombre de connexions par seconde traitées par l'appliance de sécurité adaptative. Les messages Syslog envoyés à partir de l'appliance de sécurité adaptative utilisent également les blocs de 256 octets, mais ils ne sont généralement pas libérés en quantité suffisante pour provoquer une épuisement du pool de blocs de 256 octets. Si la colonne CNT indique que le nombre de blocs de 256 octets est proche de 0, assurez-vous que vous ne vous connectez pas au niveau de débogage (niveau 7) au serveur syslog. Ceci est indiqué par la ligne de déroutement de journalisation dans la configuration du dispositif de sécurité adaptatif. Nous vous recommandons de définir la journalisation au niveau Notification (niveau 5) ou inférieur, sauf si vous avez besoin d'informations supplémentaires à des fins de débogage. |
| 1550 | Utilisé pour stocker les paquets Ethernet à traiter via l'appliance de sécurité adaptative. Lorsqu'un paquet entre dans une interface d'appareil de sécurité adaptatif, il est placé dans la file d'attente de l'interface d'entrée, transmis au système d'exploitation et placé dans un bloc. L'appliance de sécurité adaptative détermine si le paquet doit être autorisé ou refusé en fonction de la stratégie de sécurité et traite le paquet jusqu'à la file d'attente de sortie sur l'interface de sortie. Si le dispositif de sécurité adaptatif ne parvient pas à suivre la charge de trafic, le nombre de blocs disponibles est proche de 0 (comme indiqué dans la colonne CNT du résultat de la commande). Lorsque la colonne CNT est égale à zéro, le dispositif de sécurité adaptatif tente d'allouer plus de blocs, jusqu'à un maximum de 8 192. Si aucun autre bloc n'est disponible, le dispositif de sécurité adaptatif abandonne le paquet. |
| 16384 | Uniquement utilisé pour les cartes Gigabit Ethernet 64 bits et 66 MHz (i82543). Reportez-vous à la description du routeur 1550 pour plus d'informations sur les paquets Ethernet. |
| 2048 | Trames de contrôle ou guidées utilisées pour les mises à jour de contrôle. |
show memory
La commande show memory affiche la mémoire physique totale (ou RAM) de l'ASA, ainsi que le nombre d'octets actuellement disponibles. Pour utiliser ces informations, vous devez d'abord comprendre comment l'ASA utilise la mémoire. Lorsque l'ASA démarre, il copie le système d'exploitation de la mémoire Flash dans la mémoire vive et exécute le système d'exploitation de la mémoire vive (tout comme les routeurs). Ensuite, l'ASA copie la configuration de démarrage à partir de la mémoire Flash et la place dans la mémoire vive. Enfin, l'ASA alloue de la mémoire vive afin de créer les pools de blocs décrits dans la section show blocks. Une fois cette allocation terminée, l'ASA a besoin de mémoire vive supplémentaire uniquement si la configuration augmente en taille. En outre, l'ASA stocke les entrées de traduction et de connexion dans la mémoire vive.
En fonctionnement normal, la mémoire libre sur l'ASA devrait changer très peu, voire pas du tout. En règle générale, la seule fois où vous devez manquer de mémoire est lorsque vous êtes attaqué et que des centaines de milliers de connexions passent par l'ASA. Afin de vérifier les connexions, émettez la commande show conn count, qui affiche le nombre actuel et maximal de connexions via l'ASA. Si l'ASA manque de mémoire, il finit par tomber en panne. Avant le plantage, vous remarquerez peut-être des messages d'échec d'allocation de mémoire dans le syslog (%ASA-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).
Exemple
Ciscoasa# show memory Free memory: 845044716 bytes (79%) Used memory: 228697108 bytes (21%) ------------- ---------------- Total memory: 1073741824 bytes (100%)
show xlate
La commande show xlate count affiche le nombre actuel et maximal de traductions via l'ASA. 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 génère chaque traduction via l'ASA. Le résultat de la commande affiche les traductions « en cours d'utilisation », qui fait référence au nombre de traductions actives dans l'ASA lorsque la commande est exécutée ; « le plus utilisé » désigne le nombre maximal de traductions jamais vu sur l'ASA depuis sa mise sous tension.
Exemple
Ciscoasa# show xlate count 84 in use, 218 most used
Ciscoasa(config)#show xlate
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
idle 62:33:57 timeout 0:00:30
UDP PAT from 10.1.1.15/1028 to outside:192.150.49.1/1024 flags ri
idle 62:33:57 timeout 0:00:30
ICMP PAT from inside:10.1.1.15/21505 to outside:192.150.49.1/0 flags ri
idle 62:33:57 timeout 0:00:30
La première entrée est une traduction d'adresses de port TCP pour le port hôte (10.1.1.15, 1026) 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 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 affiche le nombre maximal et actuel de connexions via l'ASA. Une connexion est un mappage des informations de la couche 4 d'une adresse interne à une adresse externe. Les connexions sont établies lorsque l'ASA reçoit un paquet SYN pour les sessions TCP ou lorsque le premier paquet d'une session UDP arrive. Les connexions sont désactivées lorsque l'ASA reçoit le paquet ACK final, qui se produit lorsque la connexion de la session TCP se ferme ou lorsque le délai d'attente expire dans la session UDP.
Un nombre de connexions extrêmement élevé (50 à 100 fois normal) peut indiquer que vous êtes attaqué. Émettez la commande show memory afin de vous assurer que le nombre élevé de connexions n'entraîne pas l'épuisement de la mémoire de l'ASA. 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. Référez-vous à Références des commandes des dispositifs de sécurité adaptatifs de la gamme Cisco ASA 5500 pour plus d'informations.
Exemple
Ciscoasa#show conn count 2289 in use, 44729 most used
show interface
La commande show interface peut aider à déterminer les problèmes de non-correspondance de mode duplex et de câblage. Elle peut également fournir un meilleur aperçu si l'interface est dépassée. Si l'ASA manque de capacité du processeur, le nombre de blocs de 1 550 octets est proche de 0. (Regardez les blocs de 1 6384 octets des cartes Gig 66 MHz.) Un autre indicateur est l'augmentation de « l'absence de mémoires tampon » sur l'interface. Le message no buffers indique que l'interface n'est pas en mesure d'envoyer le paquet au système d'exploitation ASA car il n'y a pas de bloc disponible pour le paquet et le paquet est abandonné. Si une augmentation des niveaux de tampon n'a pas lieu régulièrement, émettez la commande show proc cpu afin de vérifier l'utilisation du CPU sur l'ASA. Si l'utilisation du processeur est élevée en raison d'une charge de trafic importante, mettez à niveau vers un ASA plus puissant qui peut 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 transmis à partir de sa file d'attente d'entrée et placé dans un bloc de 1 550 octets (ou dans un bloc de 1 6 384 octets sur des interfaces Gigabit Ethernet de 66 MHz). L'ASA détermine ensuite l'interface de sortie du 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 Mbits/s arrivent dans l'ASA et sortent tous d'une seule interface de 100 Mbits/s, la file d'attente logicielle de sortie indique des nombres élevés sur l'interface de sortie, ce qui indique que l'interface ne peut pas gérer le volume de trafic. Si vous vous trouvez face à cette situation, mettez à niveau vers une interface plus rapide.
Exemple
Ciscoasa#show interface
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 0013.c480.b2b8, MTU 1500
IP address 192.168.17.4, subnet mask 255.255.255.0
311981 packets input, 20497296 bytes, 0 no buffer
Received 311981 broadcasts, 157 runts, 0 giants
379 input errors, 107 CRC, 273 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
121 packets output, 7744 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 1 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops, 0 tx hangs
input queue (blocks free curr/low): hardware (255/249)
output queue (blocks free curr/low): hardware (255/254)
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 voyez un compteur spécifique qui s'incrémente régulièrement, les performances de votre ASA en pâtissent probablement et vous devez trouver la cause première 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). N'oubliez pas que les collisions de 10 % signifient que l'ASA abandonne 10 % des paquets qui passent par cette interface ; chacun de ces paquets doit être retransmis.
Référez-vous à la commande interface dans Références des commandes des dispositifs de sécurité adaptatifs de la gamme Cisco ASA 5500 pour des informations détaillées sur les compteurs d'interface.
show processes
La commande show processes sur l'ASA affiche tous les processus actifs qui s'exécutent sur l'ASA au moment de l'exécution de la commande. 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 vous montre le temps processeur (en millisecondes) que le processus a reçu 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.
Résumé des commandes
En résumé, utilisez la commande show cpu usage afin d'identifier la charge sous laquelle l'ASA se trouve. Souvenez-vous que le résultat est une moyenne d'exécution ; l'ASA peut avoir des pics d'utilisation du CPU plus élevés qui sont masqués par la moyenne d'exécution. Une fois que l'ASA atteint 80 % d'utilisation du CPU, la latence via l'ASA augmente lentement pour atteindre environ 90 % du CPU. Lorsque l'utilisation du processeur dépasse 90 %, l'ASA commence à supprimer 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 fonctionne pas à chaud, mais que vous croyez que les paquets sont toujours abandonnés, utilisez la commande show interface afin de vérifier l'interface ASA pour ne pas mettre en mémoire tampon et les collisions, peut-être en raison d'une non-correspondance de mode 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 CNT actuelle dans la sortie show blocks est proche de 0 sur les blocs de 1 550 octets (blocs de 1 6384 octets pour les cartes Gig de 66 MHz), l'ASA abandonne très probablement les paquets Ethernet car il est trop occupé. Dans ce cas, le processeur atteint un pic.
Si vous rencontrez des problèmes lorsque vous établissez de nouvelles connexions via l'ASA, utilisez la commande show conn count afin de vérifier le nombre actuel de connexions via l'ASA.
Si le nombre actuel est élevé, vérifiez la sortie show memory afin de vous assurer que l'ASA 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 utiliser d'autres commandes afin de mesurer la quantité de trafic qui passe par l'ASA. La commande show traffic affiche les paquets agrégés et les octets par interface, et la commande show perfmon divise le trafic en différents types inspectés par l'ASA.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)