¿Tiene una cuenta?
Para la documentación de este producto, se ha apuntado a utilizar un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad étnica, orientación sexual, nivel socio-económico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
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).
Este documento describe algunas de las causas probables que llevan a un problema con las Conexiones de Control y cómo resolverlos.
Consulte Resolución de Problemas de Conexiones de Control en el Sitio de Viptela para obtener más información.
Nota: La mayoría de los resultados de los comandos presentados en este documento provienen de routers vEdge. Sin embargo, el enfoque de solución de problemas es el mismo para los routers que ejecutan el software XE SD-WAN de Cisco IOS®. Escriba el sdwan
para obtener los mismos resultados en el software SD-WAN de Cisco IOS XE. Por ejemplo, show sdwan control connections
en lugar de show control connections
.
Antes de comenzar a solucionar problemas, asegúrese de que el vEdge en cuestión se ha configurado correctamente.
Incluye:
system
bloqueo:show clock
confirma la hora actual establecida.clock set
para establecer la hora correcta en el dispositivo.En todos los casos mencionados anteriormente, asegúrese de que Transport Locator (TLOC) esté activo. Marque esta opción con el show control local-properties
CLI.
Aquí se muestra un ejemplo de resultado válido:
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 10.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
En la versión 16.3 y posteriores del software vEdge, el resultado 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 172.16.0.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
Este es uno de los problemas comunes de la conectividad de control que no aparece. Entre las causas probables se incluyen el firewall u otros problemas de conectividad.
Podría ser que algunos o todos los paquetes se descarten/filtren en algún lugar. El ejemplo con los más grandes se da en tcpdump
resultados aquí.
Estos show
comandos se pueden utilizar:
#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 se produce un error en la conexión DTLS, es posible que lo vea en el show control connections-history
resultado del comando.
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.0.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 lo que sucede cuando los paquetes grandes no alcanzan vEdge cuando se utiliza tcpdump
, por ejemplo en el lado de 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
Aquí se muestra un ejemplo para el lado 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 software SD-WAN de Cisco IOS XE, puede utilizar la captura de paquetes integrada (EPC) en lugar de tcpdump.
Puede utilizar las utilidades traceroute o nping también para generar tráfico con diferentes tamaños de paquetes y marcas de punto de código de servicios diferenciados (DSCP) para verificar la conectividad porque su proveedor de servicios podría tener problemas con la entrega de paquetes UDP más grandes, paquetes UDP fragmentados (especialmente fragmentos UDP pequeños) o paquetes marcados por DSCP. Este es un ejemplo con nping cuando la conectividad es exitosa.
Desde 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
Aquí se muestra un ejemplo de 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í hay un ejemplo de conectividad fallida con el comando traceroute (que se ejecuta desde vShell) en 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 * * *
vEdge no recibe paquetes enviados desde vSmart (sólo algunos otros fragmentos o tráfico):
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:16:30.232959 IP 203.0.113.147.12846 > 198.51.100.162.12386: UDP, length 65
18:16:30.232969 IP 203.0.113.147.12846 > 198.51.100.162.12386: UDP, length 25
18:16:33.399412 IP 203.0.113.147.12846 > 198.51.100.162.12386: UDP, length 16
18:16:34.225796 IP 198.51.100.162.12386 > 203.0.113.147.12846: UDP, length 140
18:16:38.406256 IP 203.0.113.147.12846 > 198.51.100.162.12386: UDP, length 16
18:16:43.413314 IP 203.0.113.147.12846 > 198.51.100.162.12386: UDP, length 16
Los desencadenadores de los mensajes TLOC Disabled pueden deberse a estas causas probables:
show control connections-history
Salida de Comando de CLI.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
En una red muy inestable, donde las conexiones de red se inundan continuamente, es posible que vea TXCHTOBD - failed to send a challenge to Board ID failed
y/o RDSIGFBD - Read Signature from Board ID failed
. Además, a veces debido a problemas de bloqueo, un desafío enviado al ID de placa falla y cuando eso sucede, reiniciamos el ID de placa e intentamos de nuevo. No ocurre con frecuencia, y retrasa la activación de las conexiones de control. Esto se corrige en versiones posteriores.
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
Esto indica que el vBond está rechazando el número de chasis/identificador único/número de serie de vEdge. Cuando esto ocurra, confirme la información de vEdge que se muestra en el show control local-properties
salida del comando y compare ese resultado con show orchestrator valid-vedges
en el vBond.
Si no existe una entrada para el vEdge, asegúrese de que dispone de:
Send to controllers
en Configuration > Certificates
.Si existe, compruebe si hay entradas duplicadas en la tabla vEdge válida y póngase en contacto con el Cisco Technical Assistance Center (TAC) para solucionar este problema más adelante
Es posible que las conexiones de control no aparezcan si hay problemas de ruteo en la red.
Asegúrese de que haya una ruta válida en la RIB con el NH/TLOC correcto.
Algunos ejemplos son:
Ingrese estos comandos para la verificación:
show ip routes vpn 0
show ip routes vpn 0 <prefix/mask>
ping <vBond IP>
Busque el valor de distancia y el protocolo para el prefijo IP.
vEdge intenta establecer una conexión de control sin éxito o las conexiones a los controladores siguen inestables.
Verifique con el show control connections
y/o show control connections-history
comandos.
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
Si hay una IP duplicada en la red, es posible que las conexiones de control no se activen. Puede que vea el LISFD - Listener Socket FD Error
mensaje. Esto también puede ocurrir por otras razones, como la corrupción de paquetes, un RESET, la discordancia entre vEdge y los controladores en los puertos TLS versus DTLS, o si los puertos FW no están abiertos, etc.
La causa más común es una IP de transporte duplicada. Verifique la conectividad y asegúrese de que las direcciones son únicas.
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
Se activa una condición de tiempo de espera de peer cuando un vEdge pierde alcance en el controlador en cuestión.
En este ejemplo, captura un vManage Timeout msg (peer VM_TMO)
. Otros incluyen tiempos de espera de vBond, vSmart o vEdge (VB_TMO, VP_TMO, VS_TMO).
Como parte de la resolución de problemas, asegúrese de que tiene la conectividad con el controlador. Utilice el protocolo de mensajes de control de Internet (ICMP) y/o traceroute a la dirección IP en cuestión. Casos en los que se producen muchas caídas de tráfico (la pérdida es alta). Pone ping rápido y asegúrese 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 10.0.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, compruebe el show control connections-history detail
salida del comando para observar las estadísticas de control TX/RX para ver si hay alguna discrepancia significativa en los contadores. Observe en el resultado la diferencia entre los números de paquetes hello RX y TX.
---------------------------------------------------------------------------------------- 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
Si el número de serie no está presente en los controladores de un dispositivo determinado, las conexiones de control fallan.
Se puede verificar con show controllers [ valid-vsmarts | valid-vedges ]
y se ha corregido la mayor parte del tiempo. Vaya a Configuration > Certificates > Send to Controllers or Send to vBond
de las fichas correspondientes de vManage. En vBond, consulte show orchestrator valid-vedges
/ show orchestrator valid-vsmarts
.
En los registros de vBond también puede observar estos mensajes con el motivo 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:10.0.1.11 uuid:"11OG301234567" organization-name:"Example_Orgname" sp-organization-name:"Example_Orgname"" reason:"ERR_BID_NOT_VERIFIED"
Cuando resuelva este problema, asegúrese de que el número de serie y el modelo de dispositivo correctos se configuraron y aprovisionaron en el portal PnP (software.cisco.com) y vManage.
Para verificar el número de chasis y el número de serie del certificado, este comando se puede utilizar en los routers vEdge:
vEdge1# show control local-properties | include "chassis-num|serial-num" chassis-num/unique-id 11OG528180107 serial-num 1001247E
En un router que ejecuta el software SD-WAN de Cisco IOS XE, ingrese este comando:
cEdge1#show sdwan control local-properties | include chassis-num|serial-num chassis-num/unique-id C1111-4PLTEEA-FGL223911LK serial-num 016E9999
o este comando:
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
Así se ve el error en vEdge/vSmart en el show control connections-history
resultado del comando:
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 vBond en el show orchestrator connections-history
resultado del comando:
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
Además, el número de serie del dispositivo en vBond no está en la lista de vEdges válidos:
vbond1# show orchestrator valid-vedges | i 11OG528180107
Si el archivo serial entre los propios controladores no coincide, el error local en vBond es el número de serie que no está presente frente al certificado revocado para vSmarts/vManage.
En 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
Además, puede ver mensajes ORPTMO en el vSmart afectado con respecto a 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 vSmart afectado por vEdge, en la salida show control connections-history se ve el error "SERNTPRES":
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
Se puede ver otro ejemplo del mismo error "CRTREJSER/NOERR" si se utiliza la ID de producto (modelo) incorrecta 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 (observe que el postfijo "DNA" no está en el nombre):
ASR1k#show sdwan control local-properties | include chassis-num chassis-num/unique-id ASR1002-HX-JAE21050110
Organization Name es un componente fundamental para activar la conexión de control. Para una superposición determinada, el nombre de la organización debe coincidir con todos los controladores y extremos para que puedan surgir conexiones de control.
Si no, hay una "organización de certificados". error de discordancia de nombre" como se muestra 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
En los casos en que el certificado se revoque en los controladores o el número de serie de vEdge se invalida, se muestra un mensaje revocado de certificación vSmart o vEdge, respectivamente.
A continuación se muestran ejemplos de resultados de los mensajes de revocación de certificados vSmart. Este es el certificado que se revoca en 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 la misma superposición, así es como ve el vSmart cuyo certificado se revoca:
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 así es como vBond ve 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 se produce cuando el certificado no se puede verificar con el certificado raíz instalado:
1. Compruebe la hora con el show clock
comando. Debe estar al menos dentro del intervalo de validez del certificado de vBond (consulte show orchestrator local-properties
).
2. Esto puede ser causado por la corrupción del certificado raíz en vEdge.
Luego show control connections-history
en el router vEdge puede mostrar un resultado 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, vEdge tampoco puede validar el certificado del controlador. Para solucionar este problema, puede reinstalar la cadena de certificados raíz. En caso de que se utilice Symantec Certificate Authority, puede copiar la cadena de certificados raíz del sistema de archivos de sólo lectura:
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
En el momento en que se activa el dispositivo, si el dispositivo no está conectado con una plantilla en vManage, el "No Config. in vManage for device
" se muestra el mensaje.
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 10.0.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
A continuación se indican algunas condiciones transitorias en las que las conexiones de control se inundan. Estos incluyen:
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
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
29-Apr-2022 |
Se agregó la sección BDSGVERFL - Falla de firma de ID de placa, direcciones IP actualizadas y se editó para la traducción automática. |
1.0 |
13-Jun-2019 |
Versión inicial |