Introduction
Ce document décrit comment dépanner et vérifier les messages de journal HAL_PKTMEM-2-OUT_OF_RESOURCES dans les routeurs à services d'agrégation 1000 (ASR 1000) avec processeur de services intégrés 10 (ESP10).
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Transfert de paquets ASR1k
Components Used
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- ASR1k 15.1(3)S2 et versions ultérieures
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Informations générales
PAK_PRIORITY est le mécanisme utilisé par les périphériques pour spécifier le traitement d'un paquet lorsqu'il est transmis à l'intérieur du périphérique. Les paquets qui sont normalement marqués PAK_PRIORITY sont des paquets de protocole de contrôle, par exemple : RIP, OSPF, EIGRP, ISIS, PPP, HDLC, etc.
Symptôme
Normalement, ce problème se présente comme le routeur ne pouvant pas transférer le trafic à partir de certaines interfaces.
Ces journaux sont visibles dans la mémoire tampon des journaux :
.avr 8 18:56:40.808 GMT : %IOSXE-2-PLATFORM : F0 : cpp_cp : QFP:00 Thread:069 TS:0006374345833820173 %HAL_PKTMEM-2-OUT_OF_RESOURCES :
.avr 8 18:57:41.222 GMT : %IOSXE-2-PLATFORM : F0 : cpp_cp : QFP:00 Thread:047 TS:0006374406093385973 %HAL_PKTMEM-2-OUT_OF_RESOURCES :
.avr 8 18:58:43.662 GMT : %IOSXE-2-PLATFORM : F0 : cpp_cp : QFP:00 Thread:009 TS:0006374468373382518 %HAL_PKTMEM-2-OUT_OF_RESOURCES
Ce journal signifie que le périphérique n'a plus de tampons de paquets, en raison d'une sursouscription du trafic pak_priority.
ASR 1k ne supprime pas les paquets PAK_PRIORITY, ce qui leur permet de remplir facilement les tampons sans laisser passer d'autres types de trafic.
Dépannage
Vous commencez par vérifier les valeurs par défaut des interfaces pour les files d'attente pour l'interface avec les problèmes :
R1#sh platf hard qfp infrastructure active bqs file d'attente sortie interface par défaut GigabitEthernet0/0/4
Interface: QFP GigabitEthernet0/0/4 : 0,0 if_h : 19 Num. files d'attente/planifications : 1
Spécifications de la file d'attente :
Index 0 (ID file d'attente : 0x8a, Nom : GigabitEthernet0/0/4)
Informations de contrôle logiciel :
(cache) id de file d'attente : 0x0000008a, filaire : 0x8b670082, qlimit (octets) : 3281312
parent_sid : 0x278, nom_débogage : GigabitEthernet0/0/4
sw_flags : 0x08000091, état_logiciel : 0x00000801, port_uidb : 0
orig_min : 0, min : 105000000
min_qos : 0, min_dflt : 0
orig_max : 0, max. : 0
max_qos : 0, max_dflt : 0
partage : 1
niveau : 0, priorité : 0
defer_obj_refcnt : 0
Statistiques:
restantes (octets) : 0, (paquets) : 0
nombre total de requêtes (octets) : 969986824 , (paquets) : 6713421
queue_deep (octets) : 262736736
Vous pouvez voir que la limite de file d'attente est 3281312 mais que la profondeur de file d'attente est 262736736. La quantité de paquets est dépassée. Cela ne peut se produire que lorsque les paquets pak_priority arrivent à un débit élevé sur l'interface.
Ensuite, vérifiez les pertes sur le QFP (Quantum Flow Processor) de l'ASR 1k, vous remarquerez que BQSOOR (Buffering Queueing and Scheduling out of resource) diminue. Le BQS est l'ASIC de mise en mémoire tampon, de mise en file d'attente et de planification, ce qui signifie que le périphérique ne peut pas mettre en mémoire tampon certains paquets qui arrivent en raison de leur saturation.
R1#show plat hardw qfp active statistics supprime toutes les | e_0_
—
Octets de statistiques de gouttes globales
—
BqsOor 62918 870011
R1#show plat hardw qfp active statistics supprime toutes les | e_0_
—
Octets de statistiques de gouttes globales
—
BqsOor 62923 8700966
R1#show plat hardw qfp active statistics supprime toutes les | e_0_
—
Octets de statistiques de gouttes globales
—
BqsOor 62942 8703894
Vérifiez maintenant l'utilisation des paquets bqs pour voir le pourcentage de mémoire tampon utilisée.
R1#show platform hardware qfp act bqs 0 utilisation des paquets
Détails d'utilisation de la mémoire tampon de paquets :
Total : 256,00 Mo
Utilisé : 253,44 Mo
Gratuit : 2 620,00 Ko
Valeurs de seuil :
Mémoire insuffisante (OOM) : 255,96 Mo, état : Faux
Vital (> 98 %) : 253,44 Mo, état : Vrai
Hors ressource (OOR) : 217,60 Mo, état : Vrai
Utilisation : 99 %
L'utilisation est de 99 %, ce qui confirme que le périphérique manque de ressources pour le tampon.
Vous devez maintenant localiser sur quel groupe de mémoires tampon se trouvent les paquets.
Il existe 4 options :
· files d'attente QoS créées via MQC exécutent la commande “ Show policy-map int | profondeur de file d'attente incluse|limite ”
· files d'attente par défaut pour l'interface de sortie exécutent la commande “ Sho plat hard qfp act inf bqs que out def all | incl queue_deep ”
· recycler les files d'attente utilisées pour l'infrastructure exécuter la commande “ Sho plat hard afp act inf bqs queue out recycle all | incl queue_deep ”
· files d'attente IPC (Interprocess Communication Protocol) exécutent la commande “ Sho plat hard afp act inf bqs queue out ipc | incl queue_deep ”
R1#show platform hardware qfp act inf bqs que out all | i queue_de
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 262736736
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
R1#show platform hardware qfp act inf bqs que out all | i queue_de
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
queue_deep (paquets) : 0
R1#show platform hardware qfp act inf bqs que out ipc | i queue_de
queue_deep (octets) : 0
queue_deep (octets) : 0
queue_deep (octets) : 0
Vous voyez que les paquets sont dans la file d'attente par défaut.
Normalement, ce problème peut être associé à une tempête de paquets marqués PAK_PRIORITY ou d'attaques DDOS qui pourraient être envoyés marqués PAK_PRIORITY afin d'interrompre le transfert de paquets, car cette CoPP(Contro Plane Policing) peut être nécessaire pour abandonner des paquets qui ne proviennent pas d'une source valide.
Le contrôle de flux peut également provoquer cette situation, auquel cas les entrées de pause augmentent également sur l'interface.
R1#show int gi0/0/4
GigabitEthernet0/0/4 activé, protocole de ligne activé
Matériel SPA-10X1GE-V2, adresse 74de.eeee.cccc (bia 74de.eeee.cccc)
Description: inmumpt005rtwn01-G0/2 Airtel 7779861 300 Mbit/s/1 Gbit/s
L'adresse Internet est 10.1.1.1/30
MTU 9000 octets, BW 300000 Kbit/s, DLY 10 usec,
fiabilité 255/255, txload 1/255, rxload 1/255
ARPA d'encapsulation, bouclage non défini
Keepalive non pris en charge
Full Duplex, 1000 Mbits/s, type de liaison forcé, type de support LX
output flow-control is on, input flow-control is on
Type ARP : ARPA, délai ARP 04:00:00
Dernière entrée 00:00:02, sortie 00:00:01, sortie suspendue jamais
Dernière suppression des compteurs « show interface » 8w5d
File d'attente d'entrée : 0/375/0/0 (taille/max/gouttes/pousses); Total des pertes de sortie : 11
Stratégie de mise en file d'attente : Mise en file d'attente basée sur les classes
File d'attente de sortie : 0/40 (taille/max)
Débit d'entrée de 30 secondes 0 bit/s, 0 paquet/s
Débit de sortie de 30 secondes 0 bit/s, 0 paquet/s
16653945560 paquets en entrée, 6397725725851 octets, 91 pas de tampon
339 diffusions reçues (0 multicast IP)
0 trames, 0 géant, 0 trèfle
52 erreurs d'entrée, 52 CRC, 0 trame, 0 dépassement, 0 ignoré
0 watchdog, 2095792 multicast, 166107198 pause input
Sortie de paquets 12240362564, 3785983938723 octets, 0 sous-exécutions