Ce document décrit comment dépanner au mieux la fonctionnalité ZBFW (Zone Based Firewall) sur le routeur ASR 1000, avec des commandes utilisées pour interroger les compteurs de pertes matérielles sur l'ASR. L'ASR1000 est une plate-forme de transfert matérielle. La configuration logicielle de Cisco IOS-XE® programme les ASIC matériels (QFP) afin d'exécuter des fonctionnalités de transfert de fonctionnalité. Cela permet un débit plus élevé et de meilleures performances. L'inconvénient est qu'il représente un plus grand défi à résoudre. Les commandes Cisco IOS traditionnelles utilisées pour interroger les sessions en cours et les compteurs de perte via le pare-feu basé sur une zone (ZBFW) ne sont plus valides car les pertes ne sont plus dans le logiciel.
Afin de dépanner le chemin de données, vous devez identifier si le trafic est correctement transmis par le code ASR et Cisco IOS-XE. Spécifique aux fonctions de pare-feu, le dépannage de la couche de données suit les étapes suivantes :
Le résultat de show tech support firewall est résumé ici :
-------- show clock --------
-------- show version -------
-------- show running-config --------
-------- show parameter-map type inspect --------
-------- show policy-map type inspect -------
-------- show class-map type inspect --------
-------- show zone security --------
-------- show zone-pair security --------
-------- show policy-firewall stats global --------
-------- show policy-firewall stats zone --------
-------- show platform hardware qfp active feature firewall datapath <submode> --------
-------- show platform software firewall RP <submode> --------
Les informations de connexion peuvent être obtenues afin que toutes les connexions sur ZBFW soient répertoriées. Entrez cette commande :
ASR#show policy-firewall sessions platform
--show platform hardware qfp active feature firewall datapath scb any any any any any all any --
[s=session i=imprecise channel c=control channel d=data channel]
14.38.112.250 41392 14.36.1.206 23 proto 6 (0:0) [sc]
Elle montre une connexion Telnet TCP de 14.38.112.250 à 14.36.1.206.
La table de connexion peut être filtrée jusqu'à une adresse source ou de destination spécifique. Utilisez des filtres après le sous-mode plateforme. Les options à filtrer sont les suivantes :
radar-ZBFW1#show policy-firewall sessions platform ?
all detailed information
destination-port Destination Port Number
detail detail on or off
icmp Protocol Type ICMP
imprecise imprecise information
session session information
source-port Source Port
source-vrf Source Vrf ID
standby standby information
tcp Protocol Type TCP
udp Protocol Type UDP
v4-destination-address IPv4 Desination Address
v4-source-address IPv4 Source Address
v6-destination-address IPv6 Desination Address
v6-source-address IPv6 Source Address
| Output modifiers
<cr>
Cette table de connexion est filtrée de sorte que seules les connexions provenant de 14.38.112.250 sont affichées :
ASR#show policy-firewall sessions platform v4-source-address 14.38.112.250
--show platform hardware qfp active feature firewall datapath scb 14.38.112.250
any any any any all any --
[s=session i=imprecise channel c=control channel d=data channel]
14.38.112.250 41392 14.36.1.206 23 proto 6 (0:0) [sc]
Une fois la table de connexion filtrée, les informations détaillées de connexion peuvent être obtenues pour une analyse plus complète. Pour afficher ce résultat, utilisez le mot clé detail.
ASR#show policy-firewall sessions platform v4-source-address 14.38.112.250 detail
--show platform hardware qfp active feature firewall datapath scb 14.38.112.250
any any any any all any detail--
[s=session i=imprecise channel c=control channel d=data channel]
14.38.112.250 41426 14.36.1.206 23 proto 6 (0:0) [sc]
pscb : 0x8c5d4f20, bucket : 64672, fw_flags: 0x204 0x20419441,
scb state: active, scb debug: 0
nxt_timeout: 360000, refcnt: 1, ha nak cnt: 0, rg: 0, sess id: 117753
hostdb: 0x0, L7: 0x0, stats: 0x8e118e40, child: 0x0
l4blk0: 78fae7a7 l4blk1: e36df99c l4blk2: 78fae7ea l4blk3: 39080000
l4blk4: e36df90e l4blk5: 78fae7ea l4blk6: e36df99c l4blk7: fde0000
l4blk8: 0 l4blk9: 1
root scb: 0x0 act_blk: 0x8e1115e0
ingress/egress intf: GigabitEthernet0/0/2 (1021), GigabitEthernet0/0/0 (131065)
current time 34004163065573 create tstamp: 33985412599209 last access: 33998256774622
nat_out_local_addr:port: 0.0.0.0:0 nat_in_global_addr:port: 0.0.0.0:0
syncookie fixup: 0x0
halfopen linkage: 0x0 0x0
cxsc_cft_fid: 0x0
tw timer: 0x0 0x0 0x372ba 0x1e89c181
Number of simultaneous packet per session allowed: 25
bucket 125084 flags 1 func 1 idx 8 wheel 0x8ceb1120
La sortie du compteur de dépôt a changé pendant XE 3.9. Avant XE 3.9, les raisons de perte du pare-feu étaient très génériques. Après XE 3.9, les raisons de perte de pare-feu ont été étendues pour devenir plus granulaires.
Afin de vérifier les compteurs de perte, effectuez deux étapes :
La commande de base sur laquelle s'appuyer fournit toutes les pertes sur le QFP :
Router#show platform hardware qfp active statistics drop
Cette commande vous montre les abandons génériques globalement sur QFP. Ces pertes peuvent être associées à n'importe quelle fonction. Voici quelques exemples de fonctionnalités :
Ipv4Acl
Ipv4NoRoute
Ipv6Acl
Ipv6NoRoute
NatIn2out
VfrErr
...etc
Pour afficher toutes les pertes, incluez les compteurs dont la valeur est égale à zéro, utilisez la commande :
show platform hardware qfp active statistics drop all
Pour effacer les compteurs, utilisez cette commande. Il efface le résultat après l'avoir affiché à l'écran. Cette commande est désactivée en lecture, de sorte que la sortie est réinitialisée à zéro après qu'elle soit affichée à l'écran.
show platform hardware qfp active statistics drop clear
Vous trouverez ci-dessous une liste de compteurs de perte de pare-feu global QFP et une explication :
Motif de suppression globale du pare-feu | Explication |
Pare-feuBackpression | Débit de paquets dû à la contre-pression par le mécanisme de journalisation. |
ZoneNonPare-Feu | Aucune zone de sécurité configurée pour l'interface. |
Pare-feu L4Inspecteur | Échec du contrôle de la stratégie de couche 4. Reportez-vous au tableau ci-dessous pour obtenir des raisons de suppression plus précises (raisons de suppression des fonctionnalités du pare-feu). |
ZoneNonTransfertPare-feu | Le pare-feu n'est pas initialisé et aucun trafic n'est autorisé à passer. |
FirewallNonsession | La création de session échoue. Cela peut être dû à une limite de session maximale atteinte ou à une défaillance d'allocation de mémoire. |
StratégiePare-feu | La stratégie de pare-feu configurée est abandonnée. |
Pare-feuL4 | Échec de l'inspection de couche 4. Reportez-vous au tableau ci-dessous pour obtenir des raisons de suppression plus précises (raisons de suppression de la fonction de pare-feu). |
Pare-feuL7 | Paquet abandonné en raison de l'inspection L7. Reportez-vous à la liste ci-dessous pour obtenir une liste plus détaillée des raisons de suppression de la couche 7 (raisons de suppression de la fonctionnalité de pare-feu). |
Pare-feuPasInitiateur | Pas un initiateur de session pour TCP, UDP ou ICMP. Aucune session n'est créée. Par exemple, pour ICMP, le premier paquet reçu n'est pas ECHO ou TIMESTAMP. Pour TCP, il ne s’agit pas d’un SYN. Cela peut se produire dans le traitement normal des paquets ou dans un traitement de canal imprécis. |
Pare-feuAucuneNouvelleSession | La haute disponibilité du pare-feu n'autorise pas les nouvelles sessions. |
FirewallSyncookieMaxDst | Afin de fournir une protection de la propagation SYN basée sur l'hôte, il y a un taux SYN par destination comme limite d'inondation SYN. Lorsque le nombre d'entrées de destination atteint la limite, de nouveaux paquets SYN sont abandonnés. |
FirewallSyncookie | La logique SYNCOOLIE est déclenchée. Cela indique que SYN/ACK avec le cookie SYN a été envoyé et que le paquet SYN d'origine est abandonné. |
FirewallARStandby | Le routage asymétrique n'est pas activé et le groupe de redondance n'est pas actif. |
La limitation avec le compteur de pertes global QFP est qu'il n'y a pas de granularité dans les raisons de pertes, et certaines des raisons de pertes telles que FirewallL4 deviennent si surchargées au point qu'elles sont peu utiles pour le dépannage. Cela a depuis été amélioré dans Cisco IOS-XE 3.9 (15.3(2)S), où des compteurs de perte de fonctionnalité de pare-feu ont été ajoutés. Ceci donne un ensemble de raisons de chute beaucoup plus granulaires :
ASR#show platform hardware qfp active feature firewall drop all
-------------------------------------------------------------------------------
Drop Reason Packets
-------------------------------------------------------------------------------
Invalid L4 header 0
Invalid ACK flag 0
Invalid ACK number 0
....
Vous trouverez ci-dessous une liste des raisons et des explications de suppression des fonctionnalités de pare-feu :
Motif de suppression des fonctionnalités du pare-feu | Explication |
Longueur d'en-tête non valide | Le datagramme est si petit qu’il ne peut pas contenir l’en-tête TCP, UDP ou ICMP de couche 4. Elle peut être causée par :
|
Longueur de données UDP non valide | La longueur du datagramme UDP ne correspond pas à la longueur spécifiée dans l’en-tête UDP. |
Numéro ACK non valide | Cette baisse peut être due à l'une des raisons suivantes :
|
Indicateur ACK non valide |
Cette baisse peut être due à l'une des raisons suivantes :
|
Initiateur TCP non valide |
Cela se produit lorsque :
|
SYN avec données | Le paquet SYN contient la charge utile. Ceci n'est pas pris en charge. |
Indicateurs TCP non valides | Les indicateurs TCP non valides peuvent être provoqués par :
|
Segment non valide dans l'état SYNSENT |
Un segment TCP non valide dans l'état SYNSENT est causé par :
|
Segment non valide dans l'état SYNRCVD |
Un segment TCP non valide dans l'état SYNRCVD peut être causé par :
|
SEQ non valide |
Cela se produit à l'état SYNRCVD lorsque des segments proviennent de l'initiateur. Elle est causée par :
|
Option d'échelle de fenêtre non valide |
L'option d'échelle de fenêtre TCP non valide est due à une longueur d'octet d'option d'échelle de fenêtre incorrecte. |
TCP hors fenêtre | Le paquet est trop ancien - une fenêtre derrière l'ACK de l'autre côté. Cela pourrait se produire dans les états ESTABLISHED, CLOSEWAIT et LASTACK. |
Charge utile supplémentaire TCP après envoi du FIN |
Charge utile reçue après l'envoi de FIN. Cela pourrait se produire dans l'état CLOSEWAIT. |
Débordement de fenêtre TCP |
Cela se produit lorsque la taille du segment entrant dépasse la fenêtre du destinataire. Cependant, si vTCP est activé, cette condition est autorisée car le pare-feu doit mettre en mémoire tampon le segment pour qu'ALG puisse le consommer ultérieurement. |
Retourner avec indicateurs non valides |
Un paquet retransmis a déjà été reconnu par le récepteur. |
Segment TCP hors service | Le paquet hors commande est sur le point d'être livré à L7 pour inspection. Si L7 n'autorise pas le segment OO, ce paquet sera abandonné. |
Inondation SYN | Dans le cadre d'une attaque par inondation TCP SYN. Dans certaines conditions, lorsque les connexions actuelles à cet hôte dépassent la valeur semi-ouverte configurée, le pare-feu rejette toute nouvelle connexion à cette adresse IP pendant un certain temps. Par conséquent, les paquets seront abandonnés. |
Erreur interne - échec de la vérification de la synchronisation alloc |
Lors du contrôle de synchronisation, l'allocation de hostdb échoue. Action recommandée : cochez « show platform hardware qfp active feature firewall memory » pour vérifier l'état de la mémoire. |
Abandon d'interruption de la synchronisation |
Si les connexions semi-ouvertes configurées sont dépassées et que le temps d'arrêt est configuré, toute nouvelle connexion à cette adresse IP est abandonnée. |
Limite de session semi-ouverte dépassée |
Paquet abandonné en raison du dépassement des sessions semi-ouvertes autorisées. Vérifiez également les paramètres « max-incomplet high/low » et « one minute high/low » pour vous assurer que le nombre de sessions semi-ouvertes n'est pas limité par ces configurations. |
Trop de Pkt par flux |
Le nombre maximal de paquets inspectables autorisé par flux est dépassé. Le nombre maximal est 25. |
Trop de paquets d'erreur ICMP par flux |
Le nombre maximal de paquets d'erreur ICMP autorisé par flux est dépassé. Le nombre maximal est 3. |
Charge utile TCP inattendue de Rsp à Init |
Dans l'état SYNRCVD, TCP reçoit un paquet avec charge utile du répondeur vers l'initiateur. |
Erreur interne - Direction non définie | Direction de paquet non définie. |
SYN dans la fenêtre active | Un paquet SYN apparaît dans la fenêtre d'une connexion TCP déjà établie. |
RST dans la fenêtre actuelle | Un paquet RST est observé dans la fenêtre d'une connexion TCP déjà établie. |
Segment d'arrêt |
Un segment TCP qui n’aurait pas dû être reçu par l’intermédiaire de la machine d’état TCP, tel qu’un paquet SYN TCP reçu à l’état d’écoute par le répondeur, est reçu. |
Erreur interne ICMP - Informations NAT ICMP manquantes |
Le paquet ICMP n'est pas entré mais les informations NAT internes sont manquantes. Il s'agit d'une erreur interne. |
Paquet ICMP en état de fermeture SCB |
Réception d'un paquet ICMP dans l'état SCB CLOSE. |
En-tête IP manquant dans le paquet ICMP |
En-tête IP manquant dans le paquet ICMP. |
Erreur ICMP No IP ou ICMP |
Paquet d'erreur ICMP sans IP ou ICMP dans la charge utile. Probablement causée par un paquet mal formé ou une attaque. |
Pkt d'erreur ICMP trop court |
Le paquet d'erreur ICMP est trop court. |
Err ICMP dépassant la limite de rafale | Le pkt d'erreur ICMP dépasse la limite de rafale de 10. |
Erreur ICMP inaccessible |
Le pkt d'erreur ICMP inaccessible dépasse la limite. Seul le 1 er paquet inaccessible est autorisé à passer. |
Numéro de séquence d'erreur ICMP non valide |
Le numéro de séquence du paquet incorporé ne correspond pas au numéro de séquence du paquet qui génère l'erreur ICMP. |
Accusé de réception d'erreur ICMP non valide |
ACK non valide dans le paquet incorporé Erreur ICMP. |
Liste des actions ICMP |
L'action ICMP configurée est abandonnée. |
Zone-pair sans policy-map |
Stratégie non présente sur la paire de zones. cela peut être dû au fait qu'ALG (Application Layer Gateway) n'a pas été configuré pour ouvrir le trou de broche pour le canal de données d'application, ou qu'ALG n'a pas ouvert correctement le trou de broche, ou qu'aucun trou de broche n'est ouvert en raison de problèmes d'évolutivité. |
Session Manquée Et Stratégie Non Présente |
La recherche de session a échoué et aucune stratégie n'est présente pour inspecter ce paquet. |
Erreur ICMP et stratégie non présente |
Erreur ICMP sans stratégie configurée sur la zone-pair. |
Échec de la classification |
Échec de classification dans une paire de zones donnée lorsque le pare-feu tente de déterminer si le protocole est inspectable. |
Suppression de l'action de classification |
L'action de classification est abandonnée. |
Erreur de configuration de la stratégie de sécurité |
Échec de la classification en raison d'une mauvaise configuration de la stratégie de sécurité. Cela peut également être dû à l'absence de pinpole pour le canal de données L7. |
Envoyer la TVD au répondeur |
Envoyer la TVD au répondeur dans l'état SYNSENT lorsque ACK# n'est pas égal à ISN+1. |
Suppression de la stratégie de pare-feu |
L'action politique est à abandonner. |
Dépose de fragments | Déposez les fragments restants lorsque le premier fragment est supprimé. |
Abandon de la stratégie de pare-feu ICMP | L'action de stratégie du paquet intégré ICMP est DROP. |
Retours d'inspection L7 DROP |
L7 (ALG) décide de supprimer le paquet. La raison en est tirée de différentes statistiques ALG. |
Pkt de segment L7 non autorisé | Paquet segmenté reçu lorsque ALG ne l'honore pas. |
Paquet de fragments L7 non autorisé | Réception de paquets fragmentés (ou VFR) lorsque ALG ne l'honore pas. |
Type de proto L7 inconnu |
Type de protocole non reconnu. |
Une fois que la raison de la perte est identifiée à partir des compteurs de perte de fonctionnalité globale ou de pare-feu ci-dessus, des étapes de dépannage supplémentaires peuvent être nécessaires si ces pertes sont inattendues. Outre la validation de configuration afin de s'assurer que la configuration est correcte pour les fonctionnalités de pare-feu activées, il est souvent nécessaire de prendre des captures de paquets pour le flux de trafic en question pour voir si les paquets sont mal formés ou s'il y a des problèmes de mise en oeuvre de protocole ou d'application.
La fonctionnalité de journalisation ASR génère des syslogs afin d'enregistrer les paquets abandonnés. Ces Syslogs fournissent plus de détails sur les raisons pour lesquelles le paquet a été abandonné. Il existe deux types de slogans :
Afin d'isoler la cause des pertes, vous pouvez utiliser le dépannage ZBFW générique, comme activer les pertes de journal. Il y a deux façons de configurer la journalisation des pertes de paquets.
Méthode 1 : Utilisez inspect-global paramètres-map afin de consigner tous les paquets abandonnés.
parameter-map type inspect-global log dropped-packets
Méthode 2 : Utilisez custom inspect paramètre-map afin de consigner les paquets abandonnés pour une classe spécifique uniquement.
parameter-map type inspect LOG_PARAM
log dropped-packets
!
policy-map type inspect ZBFW_PMAP
class type inspect ZBFW_CMAP
inspect LOG_PARAM
Ces messages sont envoyés au journal ou à la console selon la configuration de l'ASR pour la journalisation. Voici un exemple de message de journal de suppression.
*Apr 8 13:20:39.075: %IOSXE-6-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:103
TS:00000605668054540031 %FW-6-DROP_PKT: Dropping tcp pkt from GigabitEthernet0/0/2
14.38.112.250:41433 => 14.36.1.206:23(target:class)-(INSIDE_OUTSIDE_ZP:class-default)
due to Policy drop:classify result with ip ident 11579 tcp flag 0x2, seq 2014580963,
ack 0
policy-map type inspect ZBFW_PMAP
class class-default
drop log
La journalisation à haut débit (HSL) génère des syslogs directement à partir de QFP et les envoie au collecteur HSL de netflow configuré. Il s'agit de la solution de journalisation recommandée pour ZBFW sur ASR.
Pour HSL, utilisez cette configuration :
parameter-map type inspect inspect-global
log template timeout-rate 1
log flow-export v9 udp destination 1.1.1.1 5555
Pour utiliser cette configuration, un collecteur NetFlow compatible avec Netflow version 9 est requis. Ceci est détaillé dans
Activez les débogages conditionnels afin d'activer le suivi des paquets, puis activez le suivi des paquets pour ces fonctionnalités :
ip access-list extended CONDITIONAL_ACL
permit ip host 10.1.1.1 host 192.168.1.1
permit ip host 192.168.1.1 host 10.1.1.1
!
debug platform condition feature fw dataplane submode all level info
debug platform condition ipv4 access-list CONDITIONAL_ACL both
Activez la fonction de suivi des paquets :
debug platform packet-trace copy packet both
debug platform packet-trace packet 16
debug platform packet-trace drop
debug platform packet-trace enable
Il existe deux façons d'utiliser cette fonction :
Activer les débogages conditionnels :
debug platform condition start
Exécutez le test, puis désactivez les débogages :
debug platform condition stop
Maintenant, les informations peuvent être affichées à l'écran. Dans cet exemple, les paquets ICMP ont été abandonnés en raison d'une stratégie de pare-feu :
Router#show platform packet-trace statistics
Packets Summary
Matched 2
Traced 2
Packets Received
Ingress 2
Inject 0
Packets Processed
Forward 0
Punt 0
Drop 2
Count Code Cause
2 183 FirewallPolicy
Consume 0
Router#show platform packet-trace summary
Pkt Input Output State Reason
0 Gi0/0/2 Gi0/0/0 DROP 183 (FirewallPolicy)
1 Gi0/0/2 Gi0/0/0 DROP 183 (FirewallPolicy)
Router#show platform packet-trace packet 0
Packet: 0 CBUG ID: 2980
Summary
Input : GigabitEthernet0/0/2
Output : GigabitEthernet0/0/0
State : DROP 183 (FirewallPolicy)
Timestamp
Start : 1207843476722162 ns (04/15/2014 12:37:01.103864 UTC)
Stop : 1207843477247782 ns (04/15/2014 12:37:01.104390 UTC)
Path Trace
Feature: IPV4
Source : 10.1.1.1
Destination : 192.168.1.1
Protocol : 1 (ICMP)
Feature: ZBFW
Action : Drop
Reason : ICMP policy drop:classify result
Zone-pair name : INSIDE_OUTSIDE_ZP
Class-map name : class-default
Packet Copy In
c89c1d51 5702000c 29f9d528 08004500 00540000 40004001 ac640e26 70fa0e24
01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
Packet Copy Out
c89c1d51 5702000c 29f9d528 08004500 00540000 40003f01 ad640e26 70fa0e24
01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
La commande show platform packet-trace packet <num> decode décode les informations et le contenu de l'en-tête de paquet. Cette fonctionnalité a été introduite dans XE3.11 :
Router#show platform packet-trace packet all decode
Packet: 0 CBUG ID: 2980
Summary
Input : GigabitEthernet0/0/2
Output : GigabitEthernet0/0/0
State : DROP 183 (FirewallPolicy)
Timestamp
Start : 1207843476722162 ns (04/15/2014 12:37:01.103864 UTC)
Stop : 1207843477247782 ns (04/15/2014 12:37:01.104390 UTC)
Path Trace
Feature: IPV4
Source : 10.1.1.1
Destination : 192.168.1.1
Protocol : 1 (ICMP)
Feature: ZBFW
Action : Drop
Reason : ICMP policy drop:classify result
Zone-pair name : INSIDE_OUTSIDE_ZP
Class-map name : class-default
Packet Copy In
c89c1d51 5702000c 29f9d528 08004500 00540000 40004001 ac640e26 70fa0e24
01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
ARPA
Destination MAC : c89c.1d51.5702
Source MAC : 000c.29f9.d528
Type : 0x0800 (IPV4)
IPv4
Version : 4
Header Length : 5
ToS : 0x00
Total Length : 84
Identifier : 0x0000
IP Flags : 0x2 (Don't fragment)
Frag Offset : 0
TTL : 64
Protocol : 1 (ICMP)
Header Checksum : 0xac64
Source Address : 10.1.1.1
Destination Address : 192.168.1.1
ICMP
Type : 8 (Echo)
Code : 0 (No Code)
Checksum : 0x172a
Identifier : 0x2741
Sequence : 0x0001
Packet Copy Out
c89c1d51 5702000c 29f9d528 08004500 00540000 40003f01 ad640e26 70fa0e24
01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
ARPA
Destination MAC : c89c.1d51.5702
Source MAC : 000c.29f9.d528
Type : 0x0800 (IPV4)
IPv4
Version : 4
Header Length : 5
ToS : 0x00
Total Length : 84
Identifier : 0x0000
IP Flags : 0x2 (Don't fragment)
Frag Offset : 0
TTL : 63
Protocol : 1 (ICMP)
Header Checksum : 0xad64
Source Address : 10.1.1.1
Destination Address : 192.168.1.1
ICMP
Type : 8 (Echo)
Code : 0 (No Code)
Checksum : 0x172a
Identifier : 0x2741
Sequence : 0x0001
La prise en charge de la capture de paquets intégrée a été ajoutée dans Cisco IOS-XE 3.7 (15.2(4)S). Pour plus d'informations, reportez-vous à la section
Exemple de configuration de la capture de paquets intégrée pour Cisco IOS et IOS-XE.
Dans XE3.10, les débogages conditionnels seront introduits. Des instructions conditionnelles peuvent être utilisées afin de s'assurer que la fonctionnalité ZBFW ne consigne que les messages de débogage qui sont pertinents à la condition. Les débogages conditionnels utilisent des listes de contrôle d'accès afin de restreindre les journaux qui correspondent aux éléments de la liste de contrôle d'accès. En outre, avant XE3.10, les messages de débogage étaient plus difficiles à lire. La sortie de débogage a été améliorée dans XE3.10 pour les rendre plus faciles à comprendre.
Afin d'activer ces débogages, émettez cette commande :
debug platform condition feature fw dataplane submode [detail | policy | layer4 | drop]
debug platform condition ipv4 access-list <ACL_name> both
debug platform condition start
Notez que la commande condition doit être définie via une liste de contrôle d’accès et une directive. Les débogages conditionnels ne seront pas implémentés tant qu'ils ne seront pas démarrés avec la commande debug platform condition start. Afin de désactiver les débogages conditionnels, utilisez la commande debug platform condition stop.
debug platform condition stop
Afin de désactiver les débogages conditionnels, NE PAS utiliser la commande undebug all. Afin de désactiver tous les débogages conditionnels, utilisez la commande :
ASR#clear platform condition all
Avant XE3.14, les débogages ha et event ne sont pas conditionnels. Par conséquent, la commande debug platform condition feature fw dataplane submode all entraîne la création de tous les journaux, indépendamment de la condition sélectionnée ci-dessous. Cela peut créer un bruit supplémentaire qui rend le débogage difficile.
Par défaut, le niveau de journalisation conditionnelle est info. Pour augmenter/diminuer le niveau de journalisation, utilisez la commande :
debug platform condition feature fw dataplane submode all [verbose | warning]
Les fichiers de débogage ne s'impriment pas sur la console ou le moniteur. Tous les débogages sont écrits sur le disque dur de l'ASR. Les débogages sont écrits sur le disque dur sous le dossier tracelogs portant le nom cpp_cp_F0-0.log.<date>. Pour afficher le fichier dans lequel les débogages sont écrits, utilisez la sortie :
ASR# cd harddisk:
ASR# cd tracelogs
ASR# dir cpp_cp_F0*Directory of harddisk:/tracelogs/cpp_cp_F0*
Directory of harddisk:/tracelogs/
3751962 -rwx 1048795 Jun 15 2010 06:31:51 +00:00
cpp_cp_F0-0.log.5375.20100615063151
3751967 -rwx 1048887 Jun 15 2010 02:18:07 +00:00
cpp_cp_F0-0.log.5375.20100615021807
39313059840 bytes total (30680653824 bytes free)
Chaque fichier de débogage sera stocké en tant que fichier cpp_cp_F0-0.log.<date>. Il s'agit de fichiers texte ordinaires qui peuvent être copiés à partir de l'ASR avec TFTP. Le nombre maximal de fichiers journaux sur l'ASR est de 1 Mo. Après 1 Mo, les débogages sont écrits dans un nouveau fichier journal. C'est pourquoi chaque fichier journal est horodaté afin d'indiquer le début du fichier.
Les fichiers journaux peuvent exister dans ces emplacements :
harddisk:/tracelogs/
bootflash:/tracelogs/
Étant donné que les fichiers journaux ne sont affichés qu'après leur rotation, le fichier journal peut être tourné manuellement à l'aide de la commande suivante :
ASR# test platform software trace slot f0 cpp-control-process rotate
Cela crée immédiatement un fichier journal « cpp_cp » et en lance un nouveau sur le QFP. Exemple :
ASR#test platform software trace slot f0 cpp-control-process rotate
Rotated file from: /tmp/fp/trace/stage/cpp_cp_F0-0.log.7311.20140408134406,
Bytes: 82407, Messages: 431
ASR#more tracelogs/cpp_cp_F0-0.log.7311.20140408134406
04/02 10:22:54.462 : btrace continued for process ID 7311 with 159 modules
04/07 16:52:41.164 [cpp-dp-fw]: (info): QFP:0.0 Thread:110 TS:00000531990811543397
:FW_DEBUG_FLG_HA:[]: HA[1]: Changing HA state to 9
04/07 16:55:23.503 [cpp-dp-fw]: (info): QFP:0.0 Thread:120 TS:00000532153153672298
:FW_DEBUG_FLG_HA:[]: HA[1]: Changing HA state to 10
04/07 16:55:23.617 [buginf]: (debug): [system] Svr HA bulk sync CPP(0) complex(0)
epoch(0) trans_id(26214421) rg_num(1)
Cette commande permet de fusionner les fichiers de débogage en un seul fichier pour faciliter le traitement. Il fusionne tous les fichiers du répertoire et les entrelace en fonction du temps. Cela peut aider lorsque les journaux sont très détaillés et sont créés sur plusieurs fichiers :
ASR#request platform software trace slot rp active merge target bootflash:MERGED_OUTPUT.log
Creating the merged trace file: [bootflash:MERGED_OUTPUT.log]
including all messages
Done with creation of the merged trace file: [bootflash:MERGED_OUTPUT.log]
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
10-Dec-2015 |
Première publication |