Solución de problemas de uso de CPU en switches Catalyst en Cisco IOS XE 16.x
Contenido
Introducción
Este documento describe cómo resolver problemas de uso elevado de la CPU debido a interrupciones en las plataformas Cisco IOS® XE que ejecutan las versiones 16.x.
Antecedentes
Este documento ha sido aportado por Raymond Whiting y Yogesh Ramdoss, Ingenieros del TAC de Cisco.
Este documento también presenta varios comandos nuevos en esta plataforma que son integrales para resolver los problemas de uso elevado de la CPU. Es importante comprender cómo se crea Cisco IOS XE. Con Cisco IOS XE, Cisco se ha pasado a un kernel de Linux y todos los subsistemas se han dividido en procesos. Todos los subsistemas que estaban dentro del IOS de Cisco anteriormente, como los controladores de módulos, la alta disponibilidad (HA), etc., ahora se ejecutan como procesos de software dentro del sistema operativo (OS) de Linux. El propio Cisco IOS se ejecuta como un demonio dentro del sistema operativo Linux (IOSd). Cisco IOS XE no solo conserva el mismo aspecto del clásico Cisco IOS, sino también su funcionamiento, compatibilidad y gestión.
Estas son algunas definiciones útiles:
- Motor de reenvío (FED): Se trata del núcleo del switch Cisco Catalyst y es responsable de toda la programación y retransmisión del hardware.
- IOSd: Este es el demonio del IOS de Cisco que se ejecuta en el kernel de Linux. Se ejecuta como un proceso de software dentro del núcleo.
- Sistema de entrega de paquetes (PDS): Esta es la arquitectura y el proceso de cómo se entregan los paquetes hacia y desde los diversos subsistemas. Como ejemplo, controla cómo se entregan los paquetes desde la FED al IOSd y viceversa.
- Plano de control (CP): El plano de control es un término genérico que se utiliza para agrupar las funciones y el tráfico que implican a la CPU del switch Catalyst. Esto incluye el tráfico como el protocolo de árbol de extensión (STP), el protocolo de router en espera en caliente (HSRP) y los protocolos de routing destinados al switch o enviados desde el switch. Esto también incluye protocolos de capa de aplicación como Secure Shell (SSH) y Simple Network Management Protocol (SNMP) que debe gestionar la CPU.
- Plano de datos (DP): Normalmente, el plano de datos incluye los ASIC de hardware y el tráfico que se reenvía sin la ayuda del plano de control.
- Punt.: El paquete de control del protocolo de ingreso interceptado por el DP se envía al CP para procesarlo.
- Inyectar: El paquete de protocolo generado por CP se envía a DP para salir en las interfaces de E/S.
- LSMPI: Interfaz Linux Shared Memory Punt.
Diagrama de alto nivel de la ruta de comunicación entre el plano de datos y el plano de control:
Flujo de trabajo de resolución de problemas de CPU
Esta sección proporciona un flujo de trabajo sistemático para clasificar los problemas de CPU alta en los switches. Tenga en cuenta que cubre un proceso seleccionado en el momento de escribir esta sección.
Caso práctico 1. Interrupciones del protocolo de resolución de direcciones
El proceso de solución de problemas y verificación de esta sección se puede utilizar ampliamente para un uso elevado de la CPU debido a interrupciones.
Paso 1. Identifique el Proceso que Consume Ciclos de CPU
Elshow process cpucomando se utiliza para mostrar el estado actual del proceso dentro del daemon IOSd. Cuando agrega la modificación de resultados| exclude 0.00
Hay dos valiosos fragmentos de información de este resultado:
- Utilización de la CPU durante cinco segundos: 91% / 30%
- El primer número (91%) es la utilización general de la CPU del switch
- El segundo número (30%) es la utilización provocada por interrupciones del plano de datos
- El proceso Address Resolution Protocol
(ARP) Inputes actualmente el proceso principal de Cisco IOS que consume los recursos:
Switch# show processes cpu sort | ex 0.00
CPU utilization for five seconds: 91%/30%; one minute: 30%; five minutes: 8%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
37 14645 325 45061 59.53% 18.86% 4.38% 0 ARP Input
137 2288 115 19895 1.20% 0.14% 0.07% 0 Per-minute Jobs
373 2626 35334 74 0.15% 0.11% 0.09% 0 MMA DB TIMER
218 3123 69739 44 0.07% 0.09% 0.12% 0 IP ARP Retry Age
404 2656 35333 75 0.07% 0.09% 0.09% 0 MMA DP TIMER
Elshow processes cpu platform sortedcomando se utiliza para mostrar el aspecto del proceso de utilización del núcleo Linux. A partir de la salida, se puede observar que el proceso FED es alto, lo que se debe a las solicitudes ARP impulsadas al proceso IOSd:
Switch# show processes cpu platform sorted CPU utilization for five seconds: 38%, one minute: 38%, five minutes: 40% Core 0: CPU utilization for five seconds: 39%, one minute: 37%, five minutes: 39% Core 1: CPU utilization for five seconds: 41%, one minute: 38%, five minutes: 40% Core 2: CPU utilization for five seconds: 30%, one minute: 38%, five minutes: 40% Core 3: CPU utilization for five seconds: 37%, one minute: 39%, five minutes: 41% Pid PPid 5Sec 1Min 5Min Status Size Name -------------------------------------------------------------------------------- 22701 22439 89% 88% 88% R 2187444224 linux_iosd-imag 11626 11064 46% 47% 48% S 2476175360 fed main event 4585 2 7% 9% 9% S 0 lsmpi-xmit 4586 2 3% 6% 6% S 0 lsmpi-rx
Paso 2. Investigue por qué FED está enviando paquetes al plano de control
En el paso 1, puede concluir que el proceso IOSd/ARP funciona con mucha frecuencia pero es víctima del tráfico que se introduce desde el plano de datos. Se necesita una investigación adicional sobre por qué el proceso FED dirige el tráfico a la CPU y de dónde proviene este tráfico.
Elshow platform software fed switch active punt cause summaryofrece una descripción general de alto nivel del motivo de punt. Cualquier número que aumente en varias ejecuciones de este comando indica:
Switch#show platform software fed switch active punt cause summary Statistics for all causes Cause Cause Info Rcvd Dropped ------------------------------------------------------------------------------ 7 ARP request or response 18444227 0 11 For-us data 16 0 21 RP<->QFP keepalive 3367 0 24 Glean adjacency 2 0 55 For-us control 6787 0 60 IP subnet or broadcast packet 14 0 96 Layer2 control protocols 3548 0 ------------------------------------------------------------------------------
Los paquetes que se envían al plano de control desde FED utilizan una estructura de cola dividida para garantizar el tráfico de control de alta prioridad. No se pierde detrás del tráfico de menor prioridad, como ARP. Una descripción general de alto nivel de estas colas se puede ver con el uso deshow platform software fed switch active cpu-interface. Después de ejecutar este comando varias veces, se puede encontrar que la colaForus Resolution(Forus - que significa tráfico destinado a la CPU) aumenta rápidamente.
Switch#show platform software fed switch active cpu-interface queue retrieved dropped invalid hol-block ------------------------------------------------------------------------- Routing Protocol 8182 0 0 0 L2 Protocol 161 0 0 0 sw forwarding 2 0 0 0 broadcast 14 0 0 0 icmp gen 0 0 0 0 icmp redirect 0 0 0 0 logging 0 0 0 0 rpf-fail 0 0 0 0 DOT1X authentication 0 0 0 0 Forus Traffic 16 0 0 0 Forus Resolution 24097779 0 0 0 Inter FED 0 0 0 0 L2 LVX control 0 0 0 0 EWLC control 0 0 0 0 EWLC data 0 0 0 0 L2 LVX data 0 0 0 0 Learning cache 0 0 0 0 Topology control 4117 0 0 0 Proto snooping 0 0 0 0 DHCP snooping 0 0 0 0 Transit Traffic 0 0 0 0 Multi End station 0 0 0 0 Webauth 0 0 0 0 Crypto control 0 0 0 0 Exception 0 0 0 0 General Punt 0 0 0 0 NFL sampled data 0 0 0 0 Low latency 0 0 0 0 EGR exception 0 0 0 0 FSS 0 0 0 0 Multicast data 0 0 0 0 Gold packet 0 0 0 0
El uso deshow platform software fed switch active punt cpuq allofrece una vista más detallada de estas colas. La cola 5 es responsable de ARP y, como se esperaba, aumenta a través de múltiples ejecuciones del comando. Elshow plat soft fed sw active inject cpuq clearcomando se puede utilizar para borrar los contadores para una lectura más fácil.
Switch#show platform software fed switch active punt cpuq all <snip> CPU Q Id : 5 CPU Q Name : CPU_Q_FORUS_ADDR_RESOLUTION Packets received from ASIC : 21018219 Send to IOSd total attempts : 21018219 Send to IOSd failed count : 0 RX suspend count : 0 RX unsuspend count : 0 RX unsuspend send count : 0 RX unsuspend send failed count : 0 RX consumed count : 0 RX dropped count : 0 RX non-active dropped count : 0 RX conversion failure dropped : 0 RX INTACK count : 1050215 RX packets dq'd after intack : 90 Active RxQ event : 3677400 RX spurious interrupt : 1050016 <snip>
A partir de aquí, hay un par de opciones. ARP es tráfico de difusión, por lo que puede buscar interfaces que tengan una velocidad anormalmente alta de tráfico de difusión (también útil para resolver problemas de loops de Capa 2). Es necesario ejecutar este comando varias veces para determinar qué interfaz aumenta activamente.
Switch#show interfaces counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi1/0/1 1041141009678 9 0 16267828358 Gi1/0/2 1254 11 0 1 Gi1/0/3 0 0 0 0 Gi1/0/4 0 0 0 0
La otra opción es utilizar la herramienta Embedded Packet Capture (EPC) para recopilar una muestra de los paquetes que se ven en el plano de control.
Switch#monitor capture cpuCap control-plane in match any file location flash:cpuCap.pcap
Switch#show monitor capture cpuCap
Status Information for Capture cpuCap
Target Type:
Interface: Control Plane, Direction: IN
Status : Inactive
Filter Details:
Capture all packets
Buffer Details:
Buffer Type: LINEAR (default)
File Details:
Associated file name: flash:cpuCap.pcap
Limit Details:
Number of Packets to capture: 0 (no limit)
Packet Capture duration: 0 (no limit)
Packet Size to capture: 0 (no limit)
Packet sampling rate: 0 (no sampling)
Este comando configura una captura interna en el switch para capturar cualquier tráfico que se dirija al plano de control. Este tráfico se guarda en un archivo en la memoria flash. Se trata de un archivo normalwireshark pcapque se puede exportar desde un switch y abrir en Wireshark para su posterior análisis.
Inicie la captura, déjela que se ejecute durante unos segundos y detenga la captura:
Switch#monitor capture cpuCap start
Enabling Control plane capture may seriously impact system performance. Do you want to continue? [yes/no]: yes
Started capture point : cpuCap
*Jun 14 17:57:43.172: %BUFCAP-6-ENABLE: Capture Point cpuCap enabled.
Switch#monitor capture cpuCap stop
Capture statistics collected at software:
Capture duration - 59 seconds
Packets received - 215950
Packets dropped - 0
Packets oversized - 0
Bytes dropped in asic - 0
Stopped capture point : cpuCap
Switch#
*Jun 14 17:58:37.884: %BUFCAP-6-DISABLE: Capture Point cpuCap disabled.
También es posible ver el archivo de captura en el switch:
Switch#show monitor capture file flash:cpuCap.pcap Starting the packet display ........ Press Ctrl + Shift + 6 to exit 1 0.000000 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 2 0.000054 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 3 0.000082 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 4 0.000109 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 5 0.000136 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 6 0.000162 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 7 0.000188 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 8 0.000214 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 9 0.000241 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2
A partir de esta salida, es evidente que el host 192.168.1.2 es el origen de los ARP constantes que causan la alta CPU en el switch. Utilice los comandosshow ip arpyshow mac address-table addresspara rastrear el host y eliminarlo de la red o dirigir los ARP. También es posible obtener detalles completos de cada paquete capturado con el uso de la opción detail en el comando capture view,show monitor capture file flash:cpuCap.pcap detail. Consulte esta guía para obtener más información sobre las capturas de paquetes en un switch Catalyst.
Caso práctico 2. Redireccionamiento de IP con CoPP
Los switches Catalyst de última generación están protegidos de forma predeterminada por la política de plano de control (CoPP). CoPP se utiliza para proteger la CPU de ataques maliciosos y configuraciones erróneas que pueden poner en peligro la capacidad de los switches para mantener funciones críticas como árboles de extensión y protocolos de routing. Estas protecciones pueden llevar a situaciones en las que el switch solo tiene una CPU ligeramente elevada y contadores de interfaz claros, pero el tráfico se descarta mientras atraviesa el switch. Es importante tener en cuenta la utilización de la CPU de referencia en el dispositivo en el momento de las operaciones normales. No es necesariamente un problema tener un uso elevado de la CPU, y depende de las funciones habilitadas en el dispositivo, pero cuando este uso aumenta sin cambios de configuración, esto puede ser una señal de preocupación.
Considere esta situación: los hosts que viven fuera del switch de la puerta de enlace informan de velocidades de descarga lentas y pérdida de ping a Internet. Una comprobación general del estado del switch no muestra errores en las interfaces ni ninguna pérdida de ping cuando se origina en el switch de gateway.
Cuando verifica la CPU, muestra números ligeramente elevados debido a interrupciones.
Switch#show processes cpu sorted | ex 0.00 CPU utilization for five seconds: 8%/7%; one minute: 8%; five minutes: 8% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 122 913359 1990893 458 0.39% 1.29% 1.57% 0 IOSXE-RP Punt Se 147 5823 16416 354 0.07% 0.05% 0.06% 0 PLFM-MGR IPC pro 404 13237 183032 72 0.07% 0.08% 0.07% 0 MMA DP TIMER
Cuando verifica la interfaz de la CPU, observa que el contador de redirección ICMP se incrementa activamente.
Switch#show platform software fed switch active cpu-interface queue retrieved dropped invalid hol-block ------------------------------------------------------------------------- Routing Protocol 12175 0 0 0 L2 Protocol 236 0 0 0 sw forwarding 714673 0 0 0 broadcast 2 0 0 0 icmp gen 0 0 0 0 icmp redirect 2662788 0 0 0 logging 7 0 0 0 rpf-fail 0 0 0 0 DOT1X authentication 0 0 0 0 Forus Traffic 21776434 0 0 0 Forus Resolution 724021 0 0 0 Inter FED 0 0 0 0 L2 LVX control 0 0 0 0 EWLC control 0 0 0 0 EWLC data 0 0 0 0 L2 LVX data 0 0 0 0 Learning cache 0 0 0 0 Topology control 6122 0 0 0 Proto snooping 0 0 0 0 DHCP snooping 0 0 0 0 Transit Traffic 0 0 0 0
Aunque no se observan caídas en FED, si marca CoPP, se pueden observar caídas en la cola de redireccionamiento ICMP.
Switch#show platform hardware fed switch 1 qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes)
-----------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0
1 1 L2 Control Yes 2000 2000 0
2 14 Forus traffic Yes 4000 4000 0
3 0 ICMP GEN Yes 600 600 0
4 2 Routing Control Yes 5400 5400 0
5 14 Forus Address resolution Yes 4000 4000 0
6 0 ICMP Redirect Yes 600 600 463538463
7 16 Inter FED Traffic Yes 2000 2000 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0
<snip>
CoPP es esencialmente una política de QoS que se coloca en el plano de control del dispositivo. CoPP funciona como cualquier otra QoS en el switch: cuando se agota la cola para un tráfico específico, el tráfico que utiliza esa cola se descarta. A partir de estas salidas, sabe que el tráfico está siendo conmutado por software debido a las redirecciones ICMP, y sabe que este tráfico está siendo descartado debido al límite de velocidad en la cola de redirección ICMP. Puede realizar una captura en el plano de control para validar que los paquetes que llegan al plano de control provienen de los usuarios.
Para ver qué lógica de coincidencia utiliza cada clase, tiene una CLI para ayudar a identificar los tipos de paquetes que llegan a una cola determinada. Considere este ejemplo para saber qué golpea lasystem-cpp-routing-controlclase:
Switch#show platform software qos copp policy-info
Default rates of all classmaps are displayed:
policy-map system-cpp-policy
class system-cpp-police-routing-control
police rate 5400 pps
Switch#show platform software qos copp class-info
ACL representable classmap filters are displayed:
class-map match-any system-cpp-police-routing-control
description Routing control and Low Latency
match access-group name system-cpp-mac-match-routing-control
match access-group name system-cpp-ipv4-match-routing-control
match access-group name system-cpp-ipv6-match-routing-control
match access-group name system-cpp-ipv4-match-low-latency
match access-group name system-cpp-ipv6-match-low-latency
mac access-list extended system-cpp-mac-match-routing-control
permit any host 0180.C200.0014
permit any host 0900.2B00.0004
ip access-list extended system-cpp-ipv4-match-routing-control
permit udp any any eq rip
<...snip...>
ipv6 access-list system-cpp-ipv6-match-routing-control
permit ipv6 any FF02::1:FF00:0/104
permit ipv6 any host FF01::1
<...snip...>
ip access-list extended system-cpp-ipv4-match-low-latency
permit udp any any eq 3784
permit udp any any eq 3785
ipv6 access-list system-cpp-ipv6-match-low-latency
permit udp any any eq 3784
permit udp any any eq 3785
<...snip...>
Switch#monitor capture cpuSPan control-plane in match any file location flash:cpuCap.pcap
Control-plane direction IN is already attached to the capture
Switch#monitor capture cpuSpan start
Enabling Control plane capture may seriously impact system performance. Do you want to continue? [yes/no]: yes
Started capture point : cpuSpan
Switch#
*Jun 15 17:28:52.841: %BUFCAP-6-ENABLE: Capture Point cpuSpan enabled.
Switch#monitor capture cpuSpan stop
Capture statistics collected at software:
Capture duration - 12 seconds
Packets received - 5751
Packets dropped - 0
Packets oversized - 0
Bytes dropped in asic - 0
Stopped capture point : cpuSpan
Switch#
*Jun 15 17:29:02.415: %BUFCAP-6-DISABLE: Capture Point cpuSpan disabled.
Switch#show monitor capture file flash:cpuCap.pcap detailed
Starting the packet display ........ Press Ctrl + Shift + 6 to exit
Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
<snip>
Ethernet II, Src: OmronTat_2c:a1:52 (00:00:0a:2c:a1:52), Dst: Cisco_8f:cb:47 (00:42:5a:8f:cb:47)
<snip>
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 8.8.8.8
<snip>
Cuando este host hace ping a 8.8.8.8, envía el ping a la dirección MAC del gateway, ya que la dirección de destino está fuera de la VLAN. El switch de gateway detecta que el siguiente salto está en la misma VLAN, reescribe la dirección MAC de destino en el firewall y reenvía el paquete. Este proceso puede ocurrir en el hardware, pero una excepción a este reenvío de hardware es el proceso de redirección IP. Cuando el switch recibe el ping, detecta que está ruteando el tráfico en la misma VLAN y dirige el tráfico a la CPU para generar un paquete de redirección de regreso al host. Este mensaje de redireccionamiento es para informar al host que hay una trayectoria más óptima hacia el destino. En este caso, el salto siguiente de la capa 2 está diseñado y se espera, el switch debe configurarse para no enviar los mensajes de redirección y reenviar los paquetes en el hardware. Esto se hace cuando inhabilita las redirecciones en la interfaz VLAN.
interface Vlan1 ip address 192.168.1.1 255.255.255.0 no ip redirects end
Cuando se desactivan las redirecciones IP, el switch vuelve a escribir la dirección MAC y las reenvía en el hardware.
Caso práctico 3. Uso intermitente elevado de la CPU
En el caso de que la CPU alta en el switch sea intermitente, es posible configurar una secuencia de comandos en el switch para ejecutar automáticamente estos comandos en el momento de eventos de CPU altos. Esto se hace con el uso de Cisco IOS Embedded Event Manager (EEM).
El valor de entrada se utiliza para determinar el nivel de CPU antes de que se desencadene el script. La secuencia de comandos supervisa el OID SNMP medio de la CPU en 5 segundos. Se escriben dos archivos en la memoria flash,tac-cpu-
contiene los resultados de los comandos ytac-cpu-
contiene la captura de ingreso de la CPU. Estos archivos se pueden revisar posteriormente.
config t
no event manager applet high-cpu authorization bypass
event manager applet high-cpu authorization bypass
event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1 get-type next entry-op gt entry-val 80 poll-interval 1 ratelimit 300 maxrun 180
action 0.01 syslog msg "High CPU detected, gathering system information."
action 0.02 cli command "enable"
action 0.03 cli command "term exec prompt timestamp"
action 0.04 cli command "term length 0"
action 0.05 cli command "show clock"
action 0.06 regex "([0-9]|[0-9][0-9]):([0-9]|[0-9][0-9]):([0-9]|[0-9][0-9])" $_cli_result match match1
action 0.07 string replace "$match" 2 2 "."
action 0.08 string replace "$_string_result" 5 5 "."
action 0.09 set time $_string_result
action 1.01 cli command "show proc cpu sort | append flash:tac-cpu-$time.txt"
action 1.02 cli command "show proc cpu hist | append flash:tac-cpu-$time.txt"
action 1.03 cli command "show proc cpu platform sorted | append flash:tac-cpu-$time.txt"
action 1.04 cli command "show interface | append flash:tac-cpu-$time.txt"
action 1.05 cli command "show interface stats | append flash:tac-cpu-$time.txt"
action 1.06 cli command "show log | append flash:tac-cpu-$time.txt"
action 1.07 cli command "show ip traffic | append flash:tac-cpu-$time.txt"
action 1.08 cli command "show users | append flash:tac-cpu-$time.txt"
action 1.09 cli command "show platform software fed switch active punt cause summary | append flash:tac-cpu-$time.txt"
action 1.10 cli command "show platform software fed switch active cpu-interface | append flash:tac-cpu-$time.txt"
action 1.11 cli command "show platform software fed switch active punt cpuq all | append flash:tac-cpu-$time.txt"
action 2.08 cli command "no monitor capture tac_cpu"
action 2.09 cli command "monitor capture tac_cpu control-plane in match any file location flash:tac-cpu-$time.pcap"
action 2.10 cli command "monitor capture tac_cpu start" pattern "yes"
action 2.11 cli command "yes"
action 2.12 wait 10
action 2.13 cli command "monitor capture tac_cpu stop"
action 3.01 cli command "term default length"
action 3.02 cli command "terminal no exec prompt timestamp"
action 3.03 cli command "no monitor capture tac_cpu"
Información Relacionada
- Guía rápida de Cisco IOS XE 16
- Solución de problemas de uso elevado de la CPU del switch Catalyst de la serie 3850
- Ejemplo de Configuración de Captura de Paquetes Integrada para Cisco IOS y Cisco IOS XE
- Configuración de Punt/Inject FED Packet Capture en Switches Catalyst que Ejecutan Cisco IOS XE 16.x
- Descarga y soporte técnico de Cisco
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
13-Mar-2024 |
Recertificación |
1.0 |
08-Aug-2018 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)