Controles de conexión del Troubleshooting
Opciones de descarga
-
ePub (80.8 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone -
Mobi (Kindle) (89.3 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 algo de las causas probables que llevan a un problema con los controles de conexión y de cómo resolverlos problemas. Usted puede referir a los controles de conexión del Troubleshooting en el sitio de Viptela.
Contribuido por Shankar Vemulapalli y Eugene Khabarov, ingenieros del TAC de Cisco.
Antecedentes
Nota: La mayor parte de las salidas del comando presentadas en este documento son de Routers del vEdge. Sin embargo, el acercamiento del troubleshooting es lo mismo para el Routers que ejecuta el IOS® - software XE SDWAN. Utilice la palabra clave sdwan para conseguir las mismas salidas en el IOS® - software XE SDWAN, e.g los controles de conexión showsdwan en vez de los controles de conexión de la demostración.
Antes de que usted comience a resolver problemas, asegúrese de que usted confirme que el vEdge que está en la pregunta se ha configurado correctamente.
Incluye:
- Certificado válido que ha estado instalado.
- Estos configs establecidos bajo bloque del “sistema”:
- SISTEMA-IP
- SITIO-identificación
- Nombre de la organización
- direccionamiento del vBond
- Interfaz de transporte VPN 0 que se configura con la opción y la dirección IP del túnel.
- Reloj del sistema que se configura correctamente en el vEdge y los que hacen juego con los otros dispositivos/los reguladores:
- el reloj de la demostración confirma el conjunto de la hora actual
- Utilice el conjunto del reloj para fijar el momento adecuado en el dispositivo
Para todos los casos mencionados anterior, asegúrese de que TLOC está para arriba. Controle las local-propiedades CLI del control de la demostración.
Ejemplo de la salida válida:
branch-vE1# show control local-properties personality vedge organization-name vIPtela Inc Regression certificate-status Installed root-ca-chain-status Installed certificate-validity Valid certificate-not-valid-before Sep 06 22:39:01 2018 GMT certificate-not-valid-after Sep 06 22:39:01 2019 GMT dns-name trainingvbond.viptela.com site-id 10 domain-id 1 protocol dtls tls-port 0 system-ip 172.1.10.1 chassis-num/unique-id 66cb2a8b-2eeb-479b-83d0-0682b64d8190 serial-num 12345718 vsmart-list-version 0 keygen-interval 1:00:00:00 retry-interval 0:00:00:17 no-activity-exp-interval 0:00:00:12 dns-cache-ttl 0:00:02:00 port-hopped TRUE time-since-last-port-hop 20:16:24:43 number-vbond-peers 2 INDEX IP PORT ------------------------------- 0 10.3.25.25 12346 1 10.4.30.30 12346 number-active-wan-interfaces 2 PUBLIC PUBLIC PRIVATE PRIVATE RESTRICT/ LAST MAX SPI TIME LAST-RESORT INTERFACE IPv4 PORT IPv4 PORT VS/VM COLOR CARRIER STATE CONTROL CONNECTION CNTRL REMAINING INTERFACE --------------------------------------------------------------------------------------------------------------------------------------------- ge0/1 10.1.7.11 12346 10.1.7.11 12346 2/1 gold default up no/yes 0:00:00:16 2 0:07:33:55 No ge0/2 10.2.9.11 12366 10.2.9.11 12366 2/0 silver default up no/yes 0:00:00:12 2 0:07:35:16 No
A partir de la versión de software 16.3 del vEdge, la salida tiene algunos campos adicionales:
number-vbond-peers 1 number-active-wan-interfaces 1
NAT TYPE: E -- indicates End-point independent mapping A -- indicates Address-port dependent mapping N -- indicates Not learned Note: Requires minimum two vbonds to learn the NAT type PUBLIC PUBLIC PRIVATE PRIVATE PRIVATE MAX RESTRICT/ LAST SPI TIME NAT VM INTERFACE IPv4 PORT IPv4 IPv6 PORT VS/VM COLOR STATE CNTRL CONTROL/ LR/LB CONNECTION REMAINING TYPE CON STUN PRF ---------------------------------------------------------------------------------------------------------------------------------------------------- ge0/4 73.241.233.20 12386 192.168.0.20 2601:647:4380:ca75::c2 12386 2/1 public-internet up 2 no/yes/no No/Yes 0:10:34:16 0:03:03:26 E 5
Decorados
Error de la conexión DTL (DCONFAIL)
Éste es uno de los problemas frecuentes de la Conectividad del control que no sube. Las causas probables incluyen el Firewall o algunos otros problemas de la Conectividad.
Podría ser que algunos o todos los paquetes están caídos/filtrados en alguna parte. El ejemplo con los más grandes se da en los resultados del “tcpdump” aquí.
- El router de saltos siguiente no es accesible
- El valor por defecto GW no está instalado en el RIB
- El puerto DTL no está abierto en los reguladores
Estos comandos show pueden ser utilizados:
#Check that Next hop
show ip route vpn 0
#Check ARP table for Default GW
show arp
#Ping default GW
ping <...>
#Ping Google DNS
ping 8.8.8.8
#Ping vBond if ICMP is allowed on vBond
ping <vBond IP>
#Traceroute to vBond DNS
traceroute <...>
Cuando usted tiene un error de la conexión DTL, usted puede ser que lo vea en conexión-historial del control de la demostración.
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE ERROR ERROR COUNT DOWNTIME
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 vsmart tls 1.1.1.5 160000000 1 10.0.2.73 23456 10.0.2.73 23456 default trying DCONFAIL NOERR 10407 2019-04-07T22:03:45+0000
Esto es qué sucede cuando los paquetes grandes no alcanzan el vEdge cuando usted utiliza el tcpdump, por ejemplo en el lado SD-WAN (vSmart):
tcpdump vpn 0 interface eth1 options "host 198.51.100.162 -n" 13:51:35.312109 IP 198.51.100.162.9536 > 172.18.10.130.12546: UDP, length 140 <<<< 1 (packet number) 13:51:35.312382 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 1024 <<< not reached vEdege 13:51:35.318654 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 1024 <<< not reached vEdege 13:51:35.318726 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 853 <<< not reached vEdege 13:51:36.318087 IP 198.51.100.162.9536 > 172.18.10.130.12546: UDP, length 140 <<<< 5 13:51:36.318185 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 79 <<<< 6 13:51:36.318233 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 1024 << not reached vEdege 13:51:36.318241 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 879 << not reached vEdege 13:51:36.318257 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 804 << not reached vEdege 13:51:36.318266 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 65 <<<< 10 13:51:36.318279 IP 172.18.10.130.12546 > 198.51.100.162.9536: UDP, length 25 <<<< 11
En el lado del vEdge:
tcpdump vpn 0 interface ge0/1 options "host 203.0.113.147 -n"
13:51:35.250077 IP 198.51.100.162.12426 > 203.0.113.147.12746: UDP, length 140 <<<< 1 13:51:36.257490 IP 198.51.100.162.12426 > 203.0.113.147.12746: UDP, length 140 <<<< 5 13:51:36.325456 IP 203.0.113.147.12746 > 198.51.100.162.12426: UDP, length 79 <<<< 6 13:51:36.325483 IP 203.0.113.147.12746 > 198.51.100.162.12426: UDP, length 65 <<<< 10 13:51:36.325538 IP 203.0.113.147.12746 > 198.51.100.162.12426: UDP, length 25 <<<< 11
Nota: En el IOS® - Software XE SDWAN, usted puede utilizar a la captura de paquetes integrada (EPC) en vez del tcpdump.
Usted puede utilizar el traceroute o las utilidades nping también para generar el tráfico con los diversos tamaños de paquetes y marcas del punto del código de los Servicios diferenciados (DSCP) para controlar la Conectividad porque su proveedor de servicio pudo tener problemas con la salida de paquetes UDP más grandes, de los paquetes UDP hechos fragmentos (especialmente pequeños fragmentos UDP) o del paquete marcado DSCP. Aquí está un ejemplo con nping cuando Conectividad acertada.
Del vSmart:
vSmart# tools nping vpn 0 198.51.100.162 options "--udp -p 12406 -g 12846 --source-ip 172.18.10.130 --df --data-length 555 --tos 192" Nping in VPN 0 Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2019-05-17 23:28 UTC SENT (0.0220s) UDP 172.18.10.130:12846 > 198.51.100.162:12406 ttl=64 id=16578 iplen=583 SENT (1.0240s) UDP 172.18.10.130:12846 > 198.51.100.162:12406 ttl=64 id=16578 iplen=583
Del vEdge:
vEdge# tcpdump vpn 0 interface ge0/1 options "-n host 203.0.113.147 and udp" tcpdump -i ge0_1 -s 128 -n host 203.0.113.147 and udp in VPN 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ge0_1, link-type EN10MB (Ethernet), capture size 128 bytes 18:29:43.492632 IP 203.0.113.147.12846 > 198.51.100.162.12406: UDP, length 555 18:29:44.494591 IP 203.0.113.147.12846 > 198.51.100.162.12406: UDP, length 555
Y aquí está un ejemplo de la Conectividad fracasada con el traceroute (esos funcionamientos del vShell) en el vSmart:
vSmart$ traceroute 198.51.100.162 1400 -F -p 12406 -U -t 192 -n -m 20 traceroute to 198.51.100.162.162 (198.51.100.162.162), 20 hops max, 1400 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 10.65.14.177 0.435 ms 10.65.13.225 0.657 ms 0.302 ms 7 10.10.28.115 0.322 ms 10.93.28.127 0.349 ms 10.93.28.109 1.218 ms 8 * * * 9 * * * 10 * 10.10.114.192 4.619 ms * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 10.68.72.61 2.162 ms * * 17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
paquetes notreceive de los vEdgedoes enviados del vSmart (solamente algún otro tráfico o fragmentos):
vEdge# tcpdump vpn 0 interface ge0/1 options "-n host 203.0.133.147 and udp" tcpdump -i ge0_1 -s 128 -n host 203.0.133.147 and udp in VPN 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ge0_1, link-type EN10MB (Ethernet), capture size 128 bytes 18:16:30.232959 IP 203.0.133.147.12846 > 198.51.100.162.12386: UDP, length 65
18:16:30.232969 IP 203.0.133.147.12846 > 198.51.100.162.12386: UDP, length 25
18:16:33.399412 IP 203.0.133.147.12846 > 198.51.100.162.12386: UDP, length 16
18:16:34.225796 IP 198.51.100.162.12386 > 203.0.133.147.12846: UDP, length 140
18:16:38.406256 IP 203.0.133.147.12846 > 198.51.100.162.12386: UDP, length 16
18:16:43.413314 IP 203.0.133.147.12846 > 198.51.100.162.12386: UDP, length 16
TLOC inhabilitado (DISTLOC)
Los activadores a los mensajes inhabilitados TLOC pueden ser debido a estas causas.
Las causas probables incluyen:
- Claro de los controles de conexión
- Cambio del color en TLOC
- Cambie en el sistema IP
- Cambie en los configs uces de los mencionados en el bloque de sistema o en las propiedades del túnel en conexión-historial CLI del control de la demostración
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ vmanage dtls 192.168.30.101 1 0 192.168.20.101 12346 192.168.20.101 12346 biz-internet tear_down DISTLOC NOERR 3 2019-06-01T14:43:11+0200 vsmart dtls 192.168.30.103 1 1 192.168.20.103 12346 192.168.20.103 12346 biz-internet tear_down DISTLOC NOERR 4 2019-06-01T14:43:11+0200 vbond dtls 0.0.0.0 0 0 192.168.20.102 12346 192.168.20.102 12346 biz-internet tear_down DISTLOC NOERR 4 2019-06-01T14:43:11+0200
ID de tarjeta no inicializado (BIDNTPR)
¿?
En altamente una red inestable, en donde las conexiones de red están agitando continuamente, usted puede ser que vea que “TXCHTOBD - no podido para enviar un desafío al ID de tarjeta fallado” y/o a “RDSIGFBD - firma leída del ID de tarjeta falló”. También, a veces debido a bloquear los problemas, el envío de un desafío al ID de tarjeta falla y cuando sucede ése, reajustamos el ID de tarjeta e intentamos otra vez. No debe suceder a menudo, él retrasa el traer para arriba de los controles de conexión. Esto se fija en las versiones más recientes.
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- vbond dtls - 0 0 203.0.113.109 12346 203.0.113.109 12346 silver challenge TXCHTOBD NOERR 2 2019-05-22T05:53:47+0000 vbond dtls - 0 0 203.0.113.56 12346 203.0.113.56 12346 silver challenge TXCHTOBD NOERR 0 2019-05-21T09:50:41+0000
Pegado en el “Conectar”: Problemas de ruteo
Los controles de conexión no pudieron subir si hay problemas de ruteo en la red.
Asegure para tener una ruta válido en la base de información de encaminamiento (RIB) con el salto siguiente derecho (NH) /TLOC.
Los ejemplos incluyen:
- Una ruta más específica al vBond en la punta del RIB a un NH/TLOC que no se utiliza para establecer los controles de conexión.
- El IP TLOC se escapa entre el servicio ascendente proporciona a que encaminamiento incorrecta de la causa.
Verifique con:
show ip routes vpn 0
show ip routes vpn 0 <prefix/mask>
ping <vBond IP>
Busque el valor de distancia y qué protocolo para el IP-prefijo.
los intentos del vEdge para establecer un control de conexión sin el éxito o las conexiones a los reguladores guardan el agitar.
Usted puede verificar con los controles de conexión de la demostración y/o mostrar el conexión-historial del control.
vedge1# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR PROXY STATE UPTIME ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vbond dtls 0.0.0.0 0 0 192.168.20.102 12346 192.168.20.102 12346 biz-internet - connect 0
Errores de socket (LISFD)
Si hay un IP duplicado en la red, los controles de conexión no pudieron subir. Usted puede ser que vea LISFD - Error FD del socket del módulo de escucha - mensaje. Esto puede suceder por otros motivos también, por ejemplo el daño del paquete, recibiendo una RESTAURACIÓN, la discordancía entre el vEdge y los reguladores en TLS contra los puertos DTL o si los puertos FW no están abiertos, el etc.
La mayoría de la causa común es un IP duplicado del transporte. Controle la Conectividad y asegúrese de que los direccionamientos son únicos.
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- vbond dtls - 0 0 203.0.113.21 12346 203.0.113.21 12346 default up LISFD NOERR 0 2019-04-30T15:46:25+0000
Problema de tiempo de espera del par (VM_TMO)
Una condición del descanso del par se acciona por cuando un vEdge pierde el reachability al regulador en la pregunta.
En este ejemplo, captura un msg del descanso del vManage (par VM_TMO). Otros incluyen el vBond del par, el vSmart y/o los descansos del vEdge (VB_TMO, VP_TMO, VS_TMO).
Como parte del troubleshooting, asegúrese de que usted tenga la Conectividad al regulador. Utilice el Internet Control Message Protocol (ICMP) y/o el traceroute al IP address en la pregunta. Los casos donde hay porciones de tráfico caen (la pérdida es alta). El ping rápido y se asegura de que sea bueno.
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- vmanage tls 1.1.1.3 3 0 10.0.2.42 23456 203.0.113.124 23456 default tear_down VM_TMO NOERR 21 2019-04-30T15:59:24+0000
Además, controle el comando detail del conexión-historial del control de la demostración hecho salir para mirar las estadísticas del control TX/RX para ver si hay alguna discrepancia significativa en los contadores. Note en hecho salir la diferencia entre los números de los paquetes RX y TX hola.
----------------------------------------------------------------------------------------
LOCAL-COLOR- biz-internet SYSTEM-IP- 192.168.30.103 PEER-PERSONALITY- vsmart
----------------------------------------------------------------------------------------
site-id 1
domain-id 1
protocol dtls
private-ip 192.168.20.103
private-port 12346
public-ip 192.168.20.103
public-port 12346
UUID/chassis-number 4fc4bf2c-f170-46ac-b217-16fb150fef1d
state tear_down [Local Err: ERR_DISABLE_TLOC] [Remote Err: NO_ERROR]
downtime 2019-06-01T14:52:49+0200
repeat count 5
previous downtime 2019-06-01T14:43:11+0200
Tx Statistics-
--------------
hello 597
connects 0
registers 0
register-replies 0
challenge 0
challenge-response 1
challenge-ack 0
teardown 1
teardown-all 0
vmanage-to-peer 0
register-to-vmanage 0
Rx Statistics-
--------------
hello 553
connects 0
registers 0
register-replies 0
challenge 1
challenge-response 0
challenge-ack 1
teardown 0
vmanage-to-peer 0
register-to-vmanage 0
Números de serie no presentes (CRTREJSER, BIDNTVRFD)
Si el número de serie no está presente en los reguladores para un dispositivo dado, usted verá que los controles de conexión fallan.
Puede ser verificado con los reguladores de la demostración [válidos-vsmarts | ] salidas válidas-vedges y fijado la mayor parte del tiempo. Navegue a la configuración > a los Certificados > envían a los reguladores o envían a los botones del vBond de las tabulaciones correspondientes del vManage. En el vBond, controle el orchestrator de la demostración válido-vedges/al orchestrator de la demostración válido-vsmarts.
En abre una sesión el vBond que usted puede ser que también observe estos mensajes con la razón ERR_BID_NOT_VERIFIED:
messages:local7.info: Dec 21 01:13:31 vBond-1 VBOND[1677]: %Viptela-vBond-1-vbond_0-6-INFO-1400002: Notification: 12/21/2018 1:13:31 vbond-reject-vedge-connection severit y-level:major host-name:"vBond-1" system-ip:1.1.1.11 uuid:"11OG301234567" organization-name:"Example_Orgname" sp-organization-name:"Example_Orgname"" reason:"ERR_BID_NOT_VERIFIED"
Cuando usted resuelve problemas tal problema, asegúrese de que el número de serie y el modelo del dispositivo correctos fueran configurados y provisioned en el portal de PnP (software.cisco.com) y el vManage.
Para controlar el número y el número de serie del certificado de chasis, este comando se puede utilizar en el Routers del vEdge:
vEdge1# show control local-properties | include "chassis-num|serial-num" chassis-num/unique-id 11OG528180107 serial-num 1001247E
En el router que ejecuta el ® del Cisco IOS - Software XE SDWAN, usted puede utilizar:
cEdge1#show sdwan control local-properties | include chassis-num|serial-num chassis-num/unique-id C1111-4PLTEEA-FGL223911LK serial-num 016E9999
or
Router#show crypto pki certificates CISCO_IDEVID_SUDI | s ^Certificate
Certificate
Status: Available
Certificate Serial Number (hex): 016E9999
Certificate Usage: General Purpose
Issuer:
o=Cisco
cn=High Assurance SUDI CA
Subject:
Name: C1111-4PLTEEA
Serial Number: PID:C1111-4PLTEEA SN:FGL223911LK
cn=C1111-4PLTEEA
ou=ACT-2 Lite SUDI
o=Cisco
serialNumber=PID:C1111-4PLTEEA SN:FGL223911LK
Validity Date:
start date: 15:33:46 UTC Sep 27 2018
end date: 20:58:26 UTC Aug 9 2099
Associated Trustpoints: CISCO_IDEVID_SUDI
Para los problemas con vEdge/vSmart
Aquí es cómo el error mira en vEdge/vSmart del conexión-historial del control de la demostración:
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ vbond dtls 0.0.0.0 0 0 192.168.0.231 12346 192.168.0.231 12346 biz-internet challenge_resp RXTRDWN BIDNTVRFD 0 2019-06-01T16:40:16+0200
En el vBond del conexión-historial del orchestrator de la demostración:
PEER PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE LOCAL/REMOTE COUNT DOWNTIME
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 unknown dtls - 0 0 :: 0 192.168.10.234 12346 default tear_down BIDNTVRFD/NOERR 1 2019-06-01T18:44:34+0200
También, usted no encontrará el número de serie del dispositivo en el vBond en la lista de vEdges válidos:
vbond1# show orchestrator valid-vedges | i 11OG528180107
Para los problemas con los reguladores
Si el fichero serial entre los reguladores sí mismo no hace juego, el error local en el vBond es el número de serie que no está presente contra el certificado revocado para vSmarts/vManage.
En el vBond:
PEER PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE LOCAL/REMOTE COUNT DOWNTIME
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 unknown dtls - 0 0 :: 0 192.168.0.229 12346 default tear_down SERNTPRES/NOERR 2 2019-06-01T19:04:51+0200
vbond1# show orchestrator valid-vsmarts SERIAL NUMBER ORG ----------------------- 0A SAMPLE - ORGNAME 0B SAMPLE - ORGNAME 0C SAMPLE - ORGNAME 0D SAMPLE - ORGNAME
En vSmart/vManage afectado:
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE ERROR ERROR COUNT DOWNTIME
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 vbond dtls 0.0.0.0 0 0 192.168.0.231 12346 192.168.0.231 12346 default tear_down CRTREJSER NOERR 9 2019-06-01T19:06:32+0200
vsmart# show control local-properties| i serial-num serial-num 0F
También, usted puede ser que vea los mensajes ORPTMO en el vSmart afectado en lo que respecta al vEdge:
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE ERROR ERROR COUNT DOWNTIME
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 unknown tls - 0 0 :: 0 192.168.10.238 54850 default tear_down ORPTMO NOERR 0 2019-06-01T19:18:16+0200
0 unknown tls - 0 0 :: 0 192.168.10.238 54850 default tear_down ORPTMO NOERR 0 2019-06-01T19:18:16+0200
0 unknown tls - 0 0 :: 0 198.51.100.100 55374 default tear_down ORPTMO NOERR 0 2019-06-01T19:18:05+0200
0 unknown tls - 0 0 :: 0 198.51.100.100 59076 default tear_down ORPTMO NOERR 0 2019-06-01T19:18:03+0200
0 unknown tls - 0 0 :: 0 192.168.10.240 53478 default tear_down ORPTMO NOERR 0 2019-06-01T19:18:02+0200
En el vSmart afectado vEdge en la demostración controle el error del conexión-historial “SERNTPRES” se ve:
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ vsmart tls 10.10.10.229 1 1 192.168.0.229 23456 192.168.0.229 23456 biz-internet tear_down SERNTPRES NOERR 29 2019-06-01T19:18:51+0200 vsmart tls 10.10.10.229 1 1 192.168.0.229 23456 192.168.0.229 23456 mpls tear_down SERNTPRES NOERR 29 2019-06-01T19:18:32+0200
Perjudique Chasis-numérico/el ID único
Otro ejemplo del mismo error “CRTREJSER/NOERR” puede ser considerado si el ID del producto incorrecto (modelo) se utiliza en el portal PNP. Por ejemplo:
vbond# show orchestrator valid-vedges | include ASR1002 ASR1002-HX-DNA-JAE21050110 014EE30A valid Cisco SVC N1
Sin embargo, el modelo del dispositivo real es diferente (la nota que el sufijo “DNA” no es en el nombre):
ASR1k#show sdwan control local-properties | include chassis-num chassis-num/unique-id ASR1002-HX-JAE21050110
Discordancía de la organización (CTORGNMMIS)
El nombre de la organización es un componente crítico para el control de conexión trae para arriba. Para un recubrimiento dado, el Org. el nombre tiene que hacer juego a través de todos los reguladores y vEdges de modo que los controles de conexión puedan subir.
Si no, usted verá el “certificado Org. discordancía del nombre” según lo visto aquí:
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ vbond dtls - 0 0 203.0.113.197 12346 203.0.113.197 12346 biz-internet tear_down CTORGNMMIS NOERR 14 2019-04-08T00:26:19+0000 vbond dtls - 0 0 198.51.100.137 12346 198.51.100.137 12346 biz-internet tear_down CTORGNMMIS NOERR 13 2019-04-08T00:26:04+0000
el certificado vEdge/vSmart revocó/invalidado (VSCRTREV/CRTVERFL)
En los casos cuando el certificado se revoca en los reguladores o número de serie se invalida del vEdge, el usuario verá un mensaje revocado certificación del vSmart o del vEdge respectivamente.
Aquí están las salidas de ejemplo del certificado del vSmart revocan los mensajes. Éste es el certificado que se revoca en el vSmart:
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE ERROR ERROR COUNT DOWNTIME
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 vbond dtls 0.0.0.0 0 0 192.168.0.231 12346 192.168.0.231 12346 default up RXTRDWN VSCRTREV 0 2019-06-01T18:13:22+0200
1 vbond dtls 0.0.0.0 0 0 192.168.0.231 12346 192.168.0.231 12346 default up RXTRDWN VSCRTREV 0 2019-06-01T18:13:22+0200
Asimismo, en otro vSmart en el mismo recubrimiento, éste es cómo ve el vSmart cuyo se revoca certificado:
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE ERROR ERROR COUNT DOWNTIME
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 vsmart tls 10.10.10.229 1 1 192.168.0.229 23456 192.168.0.229 23456 default tear_down VSCRTREV NOERR 0 2019-06-01T18:13:24+0200
Y aquí es cómo el vBond considera esto:
PEER PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC REPEAT
INSTANCE TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT REMOTE COLOR STATE LOCAL/REMOTE COUNT DOWNTIME
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 vsmart dtls 10.10.10.229 1 1 192.168.0.229 12346 192.168.0.229 12346 default tear_down VSCRTREV/NOERR 0 2019-06-01T18:13:14+0200
La falla de verificación de la certificación es cuando el certificado no se puede verificar con el CERT de la raíz instalado:
1. Controle el tiempo con el comando show clock. Debe estar por lo menos dentro del rango de la validez del certificado de los vBond (local-propiedades del orchestrator de la demostración del control).
2. Esto se puede causar por la corrupción CERT de la raíz en el vEdge.
Entonces el conexión-historial del control de la demostración en el router del vEdge pudo mostrar la salida similar:
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- vbond dtls - 0 0 203.0.113.82 12346 203.0.113.82 12346 default tear_down CRTVERFL NOERR 32 2018-11-16T23:58:22+0000 vbond dtls - 0 0 203.0.113.81 12346 203.0.113.81 12346 default tear_down CRTVERFL NOERR 31 2018-11-16T23:58:03+0000
En este caso, el vEdge no puede validar el certificado del regulador también. Para fijar este problema, usted puede reinstalar el encadenamiento de certificado raíz. En caso de que si utilizan a la autoridad de certificación de Symantec, usted pueda copiar el encadenamiento de certificado raíz del sistema de ficheros inalterable:
vEdge1# vshell vEdge1:~$ cp /rootfs.ro/usr/share/viptela/root-ca-sha1-sha2.crt /home/admin/ vEdge1:~$ exit exit vEdge1# request root-cert-chain install /home/admin/root-ca-sha1-sha2.crt Uploading root-ca-cert-chain via VPN 0 Copying ... /home/admin/root-ca-sha1-sha2.crt via VPN 0 Installing the new root certificate chain Successfully installed the root certificate chain
plantilla del vEdge no asociada en el vManage
A la hora de traer para arriba de ZTP, si el dispositivo no se asocia con una plantilla en el vManage, después usted no verá “ningún Config. en el vManage para el dispositivo”.
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT D OWNTIME ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------- vmanage dtls 1.1.1.1 1 0 10.0.2.80 12546 203.0.113.128 12546 default up RXTRDWN NOVMCFG 35 2 019-02-26T12:23:52+0000
Condiciones transitorias (DISCVBD, SYSIPCHNG)
Aquí están algunas condiciones transitorias donde los controles de conexión agitan. Incluyen:
- Sistema-IP cambiado en el vEdge
- Msg del desmontaje. al vBond (el control de conexión al vBond es transitorio)
PEER PEER PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC LOCAL REMOTE REPEAT TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE ERROR ERROR COUNT DOWNTIME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ vmanage dtls 10.0.0.1 1 0 198.51.100.92 12646 198.51.100.92 12646 default tear_down SYSIPCHNG NOERR 0 2018-11-02T16:58:00+0000
Con la colaboración de ingenieros de Cisco
- Shankar VemulapalliIngeniero del TAC de Cisco
- Eugene KhabarovIngeniero del TAC de Cisco
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)