IPSec ASA y debugs IKE (modo principal IKEv1) que resuelven problemas la Nota Técnica
Opciones de descarga
-
ePub (90.4 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone -
Mobi (Kindle) (102.0 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Acerca de esta traducción
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Contenido
Introducción
Este documento describe los debugs en el dispositivo de seguridad adaptante (ASA) cuando utilizan al modo principal y la clave previamente compartida (PSK). También se trata la traducción de ciertas líneas de debug en la configuración.
Los temas no discutidos en este documento incluyen el paso del tráfico después de que se haya establecido el túnel y los conceptos básicos de IPSec o de Internet Key Exchange (IKE).
Prerequisites
Requisitos
Los Quien lea este documento deben tener conocimiento de estos temas.
-
PSK
-
IKE
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software y hardware.
-
Cisco ASA 9.3.2
-
Routers que ejecuta el ® 12.4T del Cisco IOS
Cuestión central
Los debugs IKE y del IPSec son a veces secretos, pero usted puede utilizarlos para entender donde se localiza un problema del establecimiento del túnel del IPSec VPN.
Situación
Utilizan al modo principal típicamente entre los túneles de LAN a LAN o, en el caso del Acceso Remoto (EzVPN), cuando los Certificados se utilizan para la autenticación.
Los debugs son a partir de dos ASA que funcionen con la versión de software 9.3.2. Los dos dispositivos formarán un túnel de LAN a LAN.
Se describen dos escenarios principales:
- ASA como el iniciador para el IKE
- ASA como el respondedor para el IKE
Comandos Debug usados
debug crypto ikev1 127
IPSec 127 del debug crypto
Configuración ASA
Configuración IPSec:
crypto ipsec transform-set TRANSFORM esp-aes esp-sha-hmac
crypto map MAP 10 match address VPN
crypto map MAP 10 set peer 10.0.0.2
crypto map MAP 10 set transform-set TRANSFORM
crypto map MAP 10 set reverse-route
crypto map MAP interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group 10.0.0.2 type ipsec-l2l
tunnel-group 10.0.0.2 ipsec-attributes
pre-shared-key cisco
access-list VPN extended permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list VPN extended permit icmp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
Configuración IP:
ciscoasa#
show ip
System IP Addresses:
Interface Name IP address Subnet mask Method
GigabitEthernet0/0 inside 192.168.1.1 255.255.255.0 manual
GigabitEthernet0/1 outside 10.0.0.1 255.255.255.0 manual
Current IP Addresses:
Interface Name IP address Subnet mask Method
GigabitEthernet0/0 inside 192.168.1.1 255.255.255.0 manual
GigabitEthernet0/1 outside 10.0.0.1 255.255.255.0 manual
Configuración del NAT:
object network INSIDE-RANGE
subnet 192.168.1.0 255.255.255.0 object network FOREIGN_NETWORK
subnet 192.168.2.0 255.255.255
nat (inside,outside) source static INSIDE-RANGE INSIDE-RANGE destination static
FOREIGN_NETWORK FOREIGN_NETWORK no-proxy-arp route-lookup
Depuración
|
Descripción del mensaje del iniciador |
Depuraciones |
Descripción del mensaje del respondedor |
|||
|
El intercambio del modo principal comienza; no se ha compartido ningunas directivas, y los pares todavía están adentro MM_NO_STATE. Como el iniciador, el ASA comienza a construir el payload. |
DEBUG [IKEv1]: Jarra: recibió una clave adquieren el mensaje, el spi 0x0 |
||||
|
Construcción MM1 Este proceso incluye la oferta inicial para el IKE y los vendedores soportados NAT-T. |
DEBUG [IKEv1]: IP= 10.0.0.2, construyendo el DEBUG del payload [IKEv1 ISAKMP SA]: IP= 10.0.0.2, construyendo el payload del ver 02 del NAT-Traversal VID |
||||
|
Envíe MM1. |
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + SA (1) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NINGUNOS (0) longitudes totales: 168 |
||||
|
==========================MM1=============================> |
|||||
|
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + SA (1) + VENDEDOR (13) +VENDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NINGUNOS (0) longitudes totales: 164 |
MM1 recibido del iniciador. |
||||
|
DEBUG [IKEv1]: IP= 10.0.0.2, procesando el payload SA DEBUG [IKEv1]: El IP= 10.0.0.2, oferta del Oakley es aceptable DEBUG [IKEv1]: IP= 10.0.0.2, procesando el payload VID DEBUG [IKEv1]: El IP= 10.0.0.2, oferta IKE SA # 1, transforma # 1 entrada global de las coincidencias aceptables IKE # 2 |
Proceso MM1. La comparación de las directivas ISAKMP/IKE comienza. El peer remoto hace publicidad que puede utilizar el NAT-T. Configuración relacionada: authentication pre-share cifrado 3des sha del hash group2 lifetime 86400 |
||||
|
DEBUG [IKEv1]: IP= 10.0.0.2, construyendo el payload ISAKMP SA |
Construcción MM2. En este mensaje el respondedor selecciona que las configuraciones de la política isakmp a utilizar. También hace publicidad de las versiones NAT-T que puede utilizar. |
||||
|
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + SA (1) + VENDEDOR (13) + longitud total del VENDEDOR (13) + NONE(0): 128 |
Envíe MM2. |
||||
|
<========================MM2============================== |
|||||
|
MM2 recibido del respondedor. |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + SA (1) + VENDEDOR (13) + NINGUNOS (0) longitudes totales: 104 |
||||
|
Proceso MM2. |
DEBUG [IKEv1]: IP= 10.0.0.2, procesando el payload SA |
||||
|
Construcción MM3. Cargas útiles de esta del proceso detección del includesNAT, cargas útiles del intercambio de claves del Diffie-Hellman (DH) (KE) (el initator incluye g, p, y A al respondedor), y soporte DPD. |
30 de noviembre DEBUG [IKEv1 de 10:38:29]: IP= 10.0.0.2, construyendo el payload KE |
||||
|
Envíe MM3. |
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + KE (4) + NONCE (10) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NAT-D (20) + NAT-D (20) + NINGUNOS (0) longitudes totales: 304 |
||||
|
==============================MM3========================> |
|||||
|
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + KE (4) + NONCE (10) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NAT-D (130) + NAT-D (130) + NINGUNOS (0) longitudes totales: 284 |
MM3 recibido del iniciador. |
||||
|
DEBUG [IKEv1]: IP= 10.0.0.2, procesando el payload KE |
Proceso MM3. De las cargas útiles NAT-D el respondedor puede determinar si el initator está detrás de NAT y si el respondedor está detrás de NAT. Del DH KE, el respondedor del payload consigue los valores de p, de g y del A. |
||||
|
DEBUG [IKEv1]: IP= 10.0.0.2, hash computacional de la detección NAT |
Construcción MM4. Este proceso incluye el payload de la detección NAT, el respondedor DH KE genera “B” y “s” (devuelve “B” al initator), y DPD VID. |
||||
|
[IKEv1]: IP= 10.0.0.2, conexión aterrizada en el tunnel_group 10.0.0.2 |
Asocian al par al grupo de túnel de 10.0.0.2 L2L, y el cifrado y las claves del hash se generan del “s” arriba y de la clave previamente compartida. |
||||
|
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + KE (4) + NONCE (10) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NAT-D (130) + NAT-D (130) + NINGUNOS (0) longitudes totales: 304 |
Envíe MM4. |
||||
|
<===========================MM4=========================== |
|||||
|
MM4 recibido del respondedor. |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + KE (4) + NONCE (10) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + VENDEDOR (13) + NAT-D (20) + NAT-D (20) + NINGUNOS (0) longitudes totales: 304 |
||||
|
Proceso MM4. De las cargas útiles NAT-D, el initator puede ahora determinar si el iniator está detrás de NAT y si el respondedor está detrás de NAT.
|
DEBUG [IKEv1]: IP= 10.0.0.2, procesando el payload del ike |
||||
|
Asocian al par al grupo de túnel de 10.0.0.2 L2L, y el initator genera las claves del cifrado y del hash usando “s” arriba y la clave previamente compartida. |
[IKEv1]: IP= 10.0.0.2, conexión aterrizada en el tunnel_group 10.0.0.2 DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, generando las claves para el iniciador… |
||||
|
Construcción MM5. Configuración relacionada: auto crypto de la identidad del isakmp |
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, construyendo el payload ID |
||||
|
Envíe MM5. |
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + ID (5) + HASH (8) + KEEPALIVE IOS (128) +VENDOR (13) + NINGUNOS (0) longitudes totales: 96 |
||||
|
===========================MM5===========================> |
|||||
|
El respondedor no está detrás de ningún NAT. Ningún NAT-T requerido. |
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, estatus automático de la detección NAT: El extremo remoto no está detrás de un dispositivo NAT para este fin no está detrás de un dispositivo NAT |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + ID (5) + HASH (8) + NINGUNOS (0) longitudes totales: 64 |
MM5 recibido del iniciador. Este proceso incluye la identidad del peer remoto (ID) y el aterrizaje de la conexión en un grupo del túnel particular. |
||
|
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, payload identificador de proceso [IKEv1]: IP= 10.0.0.2, conexión aterrizada en el tunnel_group 10.0.0.2 |
Proceso MM5. La autenticación con las claves previamente compartidas ahora comienza. La autenticación ocurre en ambos pares; por lo tanto, usted verá dos conjuntos de los procesos de autenticación correspondientes. Configuración relacionada: |
||||
|
Estatus de la detección: El extremo remoto no está detrás de un dispositivo NAT para este fin no está detrás de un dispositivo NAT |
Ningún NAT-T requerido en este caso. |
||||
|
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, construyendo el payload ID |
Construcción MM6. Envíe la identidad incluye reintroducen las épocas comenzadas y la identidad enviada al peer remoto. |
||||
|
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=0) con las cargas útiles: HDR + ID (5) + HASH (8) + KEEPALIVE IOS (128) +VENDOR (13) + NINGUNOS (0) longitudes totales: 96 |
Envíe MM6. |
||||
|
<===========================MM6=========================== |
|||||
|
MM6 recibido del respondedor. |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=0) con las cargas útiles: HDR + ID (5) + HASH (8) + NINGUNOS (0) longitudes totales: 64 |
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, FASE 1 COMPLETADA |
Fase 1 completa. El isakmp del comienzo reintroduce el temporizador. Configuración relacionada: |
||
|
Proceso MM6. Este proceso incluye la identidad remota enviada del par y de la decisión final con respecto al grupo de túnel de escoger. |
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, payload identificador de proceso |
||||
|
Fase 1 completa. El comienzo ISAKMP reintroduce el temporizador. Configuración relacionada: tipo ipsec-l2l de 10.0.0.2 del grupo de túnel IPSec-atributos de 10.0.0.2 del grupo de túnel pre-shared-key cisco |
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, FASE 1 COMPLETADA |
||||
|
La fase 2 (Quick Mode) comienza. |
IPSEC: Nuevo @ 0x53FC3C00 creado SA embrionario, |
||||
|
Construcción QM1. Este proceso incluye los ID de proxy y las directivas del IPSec. Configuración relacionada: la lista de acceso VPN extendió ICMP 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 del permiso |
DEBUG [IKEv1]: El grupo = 10.0.0.2, IP= 10.0.0.2, IKE consiguieron SPI del motor dominante: SPI = 0xfd2d851f [IKEv1 DECODIFICAN]: Grupo = 10.0.0.2, IP= 10.0.0.2, iniciador IKE que envía el contacto inicial |
||||
|
Envíe QM1. |
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=7b80c2b0) con las cargas útiles: HDR + HASH (8) + SA (1) + NONCE (10) + el ID (5) + ID (5) + NOTIFICA (11) + NINGUNOS (0) longitudes totales: 200 |
||||
|
===============================QM1========================> |
|||||
|
[IKEv1 DECODIFICAN]: IP= 10.0.0.2, respondedor IKE que comienza el QM: msg identificación = 52481cf5 [IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=52481cf5) con las cargas útiles: HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) + ID (5) + NINGUNOS (0) longitudes totales: 172 |
QM1 recibido del iniciador. El respondedor comienza la fase 2 (QM). |
||||
|
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, procesando el payload del hash |
Proceso QM1. Este proceso compara los proxys remotos con el local y selecciona la directiva aceptable del IPSec. Configuración relacionada: el transforme el conjunto crypto del IPSec TRANSFORMA el esp-sha-hmac del ESP-aes la lista de acceso VPN extendió ICMP 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 del permiso direccionamiento VPN de la coincidencia del MAPA 10 de la correspondencia de criptografía |
||||
|
[IKEv1 DECODIFICAN]: Grupo = 10.0.0.2, IP= 10.0.0.2, ID_IPV4_ADDR_SUBNET ID received--192.168.2.0--255.255.255.0[IKEv1]: El grupo = 10.0.0.2, IP= 10.0.0.2, recibieron los datos de la subred del proxy del IP remoto en el payload ID: Dirija 192.168.2.0, máscara 255.255.255.0, el protocolo 1, el puerto 0 DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, payload identificador de proceso |
Se reciben el telecontrol y las subredes locales (192.168.2.0/24 y 192.168.1.0/24). |
||||
|
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, sa viejo QM IsRekeyed no encontrado por el addr |
Se busca y se encuentra una entrada crypto estática que corresponde con. |
||||
|
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, IKE: ¡petición de SPI! |
Construcción QM2. Este proceso incluye la confirmación de las identidades de representación, tipo de túnel, y un control se realiza para el ACL de criptografía duplicado. |
||||
|
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=52481cf5) con las cargas útiles: HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) + ID (5) + NINGUNOS (0) longitudes totales: 172 |
Envíe QM2. |
||||
|
<============================QM2=========================== |
|||||
|
QM2 recibido del respondedor. |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=7b80c2b0) con las cargas útiles: HDR + HASH (8) + SA (1) + NONCE (10) + el ID (5) + ID (5) + NOTIFICA (11) + NINGUNOS (0) longitudes totales: 200 |
||||
|
Proceso QM2. En este proceso, el extremo remoto envía los parámetros y se escogen los cursos de la vida propuestos más cortos de la fase 2. |
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, procesando el payload del hash |
||||
|
Correspondencia de criptografía que corresponde con “MAPA” Found y entrada 10 y correspondido con le contra la lista de acceso “VPN.” |
DEBUG [IKEv1]: El grupo = 10.0.0.2, IP= 10.0.0.2, NP cifran la regla miran para arriba para el MAPA 10 ACL que corresponde con VPN de la correspondencia de criptografía: cs_id=53f11198 vuelto; rule=53f11a90 |
||||
|
El dispositivo ha generado el tráfico entrante y saliente 0xfd2d851f y 0xdde50931for SPI respectivamente. |
DEBUG [IKEv1]: ¡Grupo = 10.0.0.2, IP= 10.0.0.2, generando la clave del Quick Mode! |
||||
|
Construcción QM3. Confirme todos los SPI creados al peer remoto. |
IPSEC: Actualización completada del host IBSA, SPI 0xFD2D851F |
||||
|
Envíe QM3. |
[IKEv1 DECODIFICAN]: Grupo = 10.0.0.2, IP= 10.0.0.2, iniciador IKE que envía el 3ro pkt QM: msg identificación = 7b80c2b0 |
||||
|
=============================QM3==========================> |
|||||
|
Fase 2 completa. El iniciador está listo ahora para cifrar y para desencriptar los paquetes usando estos valores de SPI. |
[IKEv1]: IP= 10.0.0.2, IKE_DECODE QUE ENVÍA el mensaje (msgid=7b80c2b0) con las cargas útiles: HDR + HASH (8) + NINGUNOS (0) longitudes totales: 76 |
[IKEv1]: El IP= 10.0.0.2, IKE_DECODE RECIBIÓ el mensaje (msgid=52481cf5) con las cargas útiles: HDR + HASH (8) + NINGUNOS (0) longitudes totales: 52 |
Iniciador del fom del receivd QM3. |
||
|
DEBUG [IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, procesando el payload del hash |
Proceso QM3. Las claves de encripción se generan para los datos SA. Durante este proceso, Los SPI se fijan para pasar el tráfico. |
||||
|
[IKEv1]: Grupo = 10.0.0.2, IP= 10.0.0.2, negociación de seguridad completa para el respondedor del grupo del LAN a LAN (10.0.0.2), SPI entrante = 0x1698cac7, SPI saliente = 0xdb680406 IPSEC: Actualización completada del host IBSA, SPI 0x1698CAC7 |
Los SPI se asignan a los datos SA. |
||||
|
DEBUG [IKEv1]: El grupo = 10.0.0.2, IP= 10.0.0.2, comenzando el P2 reintroducen el temporizador: 3060 segundos. |
El IPSec del comienzo reintroduce las épocas. |
||||
|
[IKEv1]: El grupo = 10.0.0.2, IP= 10.0.0.2, la FASE 2 COMPLETARON (msgid=52481cf5) |
Fase 2 completa. El respondedor y el iniciador pueden cifrar/tráfico del decrypt. |
||||
Verificación del túnel
Note: Puesto que el ICMP se utiliza para accionar el túnel, sólo un IPSec SA está para arriba. Protocolo 1 = ICMP.
show crypto ipsec sa
interface: outside
Crypto map tag: MAP, seq num: 10, local addr: 10.0.0.1
access-list VPN extended permit icmp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/1/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/1/0)
current_peer: 10.0.0.2
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 10.0.0.1/0, remote crypto endpt.: 10.0.0.2/0
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: DB680406
current inbound spi : 1698CAC7
inbound esp sas:
spi: 0x1698CAC7(379112135)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 16384, crypto-map: MAP
sa timing: remaining key lifetime (kB/sec): (3914999/3326)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000001F
outbound esp sas:
spi: 0xDB680406 (3681027078)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 16384, crypto-map: MAP
sa timing: remaining key lifetime (kB/sec): (3914999/3326)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.0.0.2
Type :L2LRole :responder
Rekey : no State :MM_ACTIVE
Información Relacionada
- Un lugar bueno a comenzar es artículo del wikipedia sobre el IPSec. El estándar y las referencias contiene mucha información útil
- Troubleshooting de IPSec: Entendiendo y con los comandos debug
- Soporte Técnico y Documentación - Cisco Systems
Con la colaboración de ingenieros de Cisco
- Atri Basu, Marcin Latosiewicz, and Jay Young TaylorCisco TAC Engineers.
ComentariosDéjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)