La interfaz del Troubleshooting ASR1000-ESP10 paró el tráfico de reenvío debido al "HAL_PKTMEM-2-OUT_OF_RESOURCES"

Introducción

Este documento describe cómo resolver problemas y verificar los mensajes del registro HAL_PKTMEM-2-OUT_OF_RESOURCES en el Routers 1000 (ASR 1000) de los servicios de la agregación con el procesador de servicio integrado 10 (ESP10).

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Reenvío de paquete ASR1k

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• ASR1k 15.1(3)S2 y arriba

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Antecedentes

El PAK_PRIORITY es el uso de los dispositivos del mecanismo de especificar el tratamiento de un paquete mientras que se transmite dentro del dispositivo. Los paquetes que son normalmente PAK_PRIORITY marcado con etiqueta serían paquetes del Control Protocol, por ejemplo: RIP, OSPF, EIGRP, ISIS, PPP, HDLC, etc.

Síntoma

Este problema se presenta normalmente como el router que no puede remitir el tráfico de las ciertas interfaces.

Esto registra se puede ver en el búfer del registro:

.Apr 8 18:56:40.808 GMT: %IOSXE-2-PLATFORM: F0: cpp_cp: QFP:00 Thread:069 TS:00006374345833820173 %HAL_PKTMEM-2-OUT_OF_RESOURCES:
.Apr 8 18:57:41.222 GMT: %IOSXE-2-PLATFORM: F0: cpp_cp: QFP:00 Thread:047 TS:00006374406093385973 %HAL_PKTMEM-2-OUT_OF_RESOURCES:
.Apr 8 18:58:43.662 GMT: %IOSXE-2-PLATFORM: F0: cpp_cp: QFP:00 Thread:009 TS:00006374468373382518 %HAL_PKTMEM-2-OUT_OF_RESOURCES

Este registro significa que el dispositivo se ejecutó de los almacenes intermedios del paquete, debido al oversubscription del tráfico del pak_priority.
El ASR 1k no caerá los paquetes del PAK_PRIORITY, haciéndolo fácil para que llenen los buffers que no permiten que la otra clase de tráfico vaya a través.

Troubleshooting

Usted comienza marcando los valores predeterminados de las interfaces para las colas de administración del tráfico para la interfaz con los problemas:

R1#sh platf hard qfp active infrastructure bqs queue output default interface GigabitEthernet0/0/4
Interface: GigabitEthernet0/0/4 QFP: 0.0 if_h: 19 Num Queues/Schedules: 1
Queue specifics:
Index 0 (Queue ID:0x8a, Name: GigabitEthernet0/0/4)
Software Control Info:
(cache) queue id: 0x0000008a, wred: 0x8b670082, qlimit (bytes): 3281312
parent_sid: 0x278, debug_name: GigabitEthernet0/0/4
sw_flags: 0x08000091, sw_state: 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
share : 1
plevel : 0, priority: 0
defer_obj_refcnt: 0
Statistics:
tail drops (bytes): 0 , (packets): 0
total enqs (bytes): 969986824 , (packets): 6713421
queue_depth (bytes): 262736736

Usted puede ver que el límite de cola es 3281312 pero la profundidad de espera en cola es 262736736. La cantidad de paquetes se está excediendo. Esto puede suceder solamente cuando los paquetes del pak_priority están llegando a una alta velocidad en la interfaz.

Entonces marque los descensos en el QFP (procesador del flujo de Quantum) del ASR 1k, usted nota que hay aumento de los descensos BQSOOR (mitigando la espera y el Scheduling fuera del recurso). Los BQS son el mitigar, haciendo cola y el Scheduling ASIC, esto significaría que el dispositivo no puede mitigar ciertos paquetes que sean llegada debido a él que es saturado.

R1#show plat hardw qfp active statistics drop all | e _0_
-------------------------------------------------------------------------
Global Drop Stats Packets Octets
-------------------------------------------------------------------------
BqsOor                    62918 8700111


R1#show plat hardw qfp active statistics drop all | e _0_
-------------------------------------------------------------------------
Global Drop Stats Packets Octets
-------------------------------------------------------------------------
BqsOor                   62923 8700966


R1#show plat hardw qfp active statistics drop all | e _0_
-------------------------------------------------------------------------
Global Drop Stats Packets Octets
-------------------------------------------------------------------------
BqsOor                   62942 8703894

Ahora marque la utilización del paquete bqs para ver el porcentaje del buffer usado.

R1#show platform hardware qfp act bqs 0 packet utilization
Packet buffer memory utilization details:
Total: 256.00 MB
Used : 253.44 MB
Free : 2620.00 KB
Threshold Values:
Out of Memory (OOM) : 255.96 MB, Status: False
Vital (> 98%) : 253.44 MB, Status: True
Out of Resource (OOR) : 217.60 MB, Status: True
Utilization: 99 %

La utilización es el 99%, así que ésta confirma el dispositivo se está ejecutando de los recursos para el buffer.

Usted ahora necesita localizar en qué grupo de buffers son los paquetes.

Hay 4 opciones:

• Las colas de administración del tráfico de QoS creadas vía el MQC funcionan con directiva-mapa internacional de la demostración del comando el “ | profundidad de espera en cola del incl|límite”
• Las colas predeterminadas para la interfaz de salida funcionan con sho del comando “plat el def duro todo del que inf bqs del acto del qfp hacia fuera | queue_depth del incl”
• Recicle las colas de administración del tráfico usadas para la infraestructura funcionan con sho del comando “plat el acto duro inf del afp que los bqs hacen cola hacia fuera reciclan todos | queue_depth del incl”
• Las colas de administración del tráfico de IPC (protocolo de comunicación entre procesos) funcionan con sho del comando “plat el acto duro inf del afp que los bqs hacen cola hacia fuera el ipc | queue_depth del incl”

R1#show platform hardware qfp act inf bqs que out def all | i queue_de
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 262736736
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0

R1#show platform hardware qfp act inf bqs que out recy all | i queue_de
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
queue_depth (packets): 0
R1#show platform hardware qfp act inf bqs que out ipc | i queue_de
queue_depth (bytes): 0
queue_depth (bytes): 0
queue_depth (bytes): 0

Usted ve que los paquetes están en la cola predeterminada.

Este problema se puede asociar normalmente a una tormenta de los paquetes marcados o de los ataques DDoS del PAK_PRIORITY que pudieron ser enviados tan marcado que el PAK_PRIORITY para interrumpir el reenvío de paquete, porque este CoPP (policing plano de Contro) pudieron ser necesarios caer los paquetes que no están viniendo de una fuente válida.
El control de flujos puede también causar esto en este caso, usted también vería las entradas de la pausa aumentar en la interfaz.

R1#show int gi0/0/4
GigabitEthernet0/0/4 is up, line protocol is up
Hardware is SPA-10X1GE-V2, address is 74de.eeee.cccc (bia 74de.eeee.cccc)
Description: inmumpt005rtwn01-G0/2 Airtel 7779861 300Mbps/1Gbps
Internet address is 10.1.1.1/30
MTU 9000 bytes, BW 300000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not supported
Full Duplex, 1000Mbps, link type is force-up, media type is LX
output flow-control is on, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:01, output hang never
Last clearing of "show interface" counters 8w5d
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 11
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
16653945560 packets input, 6397725725851 bytes, 91 no buffer
Received 339 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
52 input errors, 52 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2095792 multicast, 166107198 pause input
12240362564 packets output, 3785983938723 bytes, 0 underruns