Dépannez les connexions de contrôle
Options de téléchargement
-
ePub (73.8 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone -
Mobi (Kindle) (88.5 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
À propos de cette traduction
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Contenu
Introduction
Ce document décrit certaines des causes probables qui mènent à un problème avec des connexions de contrôle et de la façon les dépanner. Vous pouvez se référer dépannez des connexions de contrôle sur le site de Viptela.
Contribué par Shankar Vemulapalli et Eugene Khabarov, ingénieurs TAC Cisco.
Informations générales
Remarque: La plupart des sorties de commande présentées dans ce document sont des Routeurs de vEdge. Cependant, l'approche de dépannage est identique pour les Routeurs qui exécutent le ® IOS - logiciel XE SDWAN. Employez le mot clé sdwan afin d'obtenir les mêmes sorties sur le ® IOS - logiciel XE SDWAN, par exemple les connexions showsdwan de contrôle au lieu des connexions de contrôle d'exposition.
Avant que vous commenciez à dépanner, assurez-vous que vous confirmez que le vEdge qui est en question a été configuré correctement.
Elle comprend :
- Certificat valide qui a été installé.
- Ces configs mis en place sous le bloc de « système » :
- SYSTÈME-IP
- SITE-ID
- Organisation-nom
- adresse de vBond
- Transport interface VPN 0 qui est configuré avec l'option et l'adresse IP de tunnel.
- Horloge système qui est configurée correctement sur le vEdge et ceux qui apparient avec d'autres périphériques/contrôleurs :
- le show clock confirme l'heure définie en cours
- Employez le clock set pour placer le bon moment sur le périphérique
Pour tous les cas cités précédemment, assurez-vous que TLOC est. Contrôle gens du pays-Properties CLI d'exposition de contrôle.
Exemple de sortie valide :
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
À partir de la version de logiciel 16.3 de vEdge, la sortie a quelques champs supplémentaires :
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
Scénarios
Panne de connexion DTLS (DCONFAIL)
C'est l'un des problèmes courants de la Connectivité de contrôle qui n'est pas soulevée. Les causes probables incluent le Pare-feu ou quelques autres problèmes de connectivité.
Il pourrait être que certains ou tous les paquets sont relâchés/filtrés quelque part. L'exemple avec le plus grand est donné dans des résultats de « tcpdump » ici.
- Le routeur du prochain saut n'est pas accessible
- Le gw par défaut n'est pas installé dans la NERVURE
- Le port DTLS n'est pas ouvert dans les contrôleurs
Ces commandes show peuvent être utilisées :
#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 <...>
Quand vous avez une panne de connexion DTLS, vous pourriez la voir en connexion-historique de contrôle d'exposition.
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
C'est ce qui se produit quand les grands paquets n'atteignent pas le vEdge quand vous utilisez le tcpdump, par exemple du côté 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
Du côté de 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
Remarque: Sur le ® IOS - Logiciel XE SDWAN, vous pouvez utiliser la capture incluse de paquet (CPE) au lieu du tcpdump.
Vous pouvez employer la traceroute ou les utilitaires nping aussi bien afin de générer le trafic avec différentes longueurs de paquet et marques de Differentiated Services Code Point (DSCP) afin de vérifier la Connectivité parce que votre fournisseur de services pourrait avoir des problèmes avec la livraison de plus grands paquets UDP, des paquets UDP fragmentés (particulièrement petits fragments d'UDP) ou du paquet marqué par DSCP. Voici un exemple avec nping quand Connectivité réussie.
Du 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
Du 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
Et voici un exemple de Connectivité infructueuse avec la traceroute (ces passages de vShell) sur le 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 * * *
paquets notreceive de vEdgedoes envoyés du vSmart (seulement quelques autres trafic ou fragments) :
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 désactivé (DISTLOC)
Les déclencheurs aux messages désactivés par TLOC peuvent être dus à ces causes.
Les causes probables incluent :
- Dédouanement des connexions de contrôle
- Changer la couleur sur TLOC
- Changement du système IP
- Changez dans des configs l'uns des mentionnés dans le bloc de système ou dans les propriétés de tunnel en connexion-historique CLI de contrôle d'exposition
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
Panneau-ID non initialisé (BIDNTPR)
?
Dans un réseau fortement instable, où les connexions réseau s'agitent continuellement, vous pourriez voir que « TXCHTOBD - pour envoyer un défi pour embarquer l'ID a manqué » et/ou « RDSIGFBD - signature lue d'ID de panneau a manqué ». En outre, parfois en raison de verrouiller des questions, envoyant un défi au panneau-id échoue et quand cela se produit, nous remettons à l'état initial le panneau-ID et l'essayons de nouveau. Il ne devrait pas se produire souvent, il retarde l'apport des connexions de contrôle. Ceci est réparé dans de plus nouvelles versions.
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
Collé dans « connectez » : Acheminement des questions
des Contrôle-connexions ne pourraient pas être soulevées si là conduisent des questions dans le réseau.
Assurez pour avoir une artère valide dans le Routing Information Base (NERVURE) avec le prochain saut droit (NH) /TLOC.
Exemples :
- Plus d'artère spécifique au vBond au point de NERVURE à un NH/TLOC qui n'est pas utilisé afin d'établir des connexions de contrôle.
- L'IP TLOC est coulé entre le service ascendant fournit que routage incorrect de cause.
Vérifiez avec :
show ip routes vpn 0
show ip routes vpn 0 <prefix/mask>
ping <vBond IP>
Recherchez la valeur de distance et quel protocole pour le préfixe IP.
les essais de vEdge pour établir une connexion de contrôle sans le succès ou des connexions aux contrôleurs continuent le battement.
Vous pouvez vérifier avec des connexions de contrôle d'exposition et/ou afficher le connexion-historique de contrôle.
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
Erreurs de socket (LISFD)
S'il y a un IP en double dans le réseau, des connexions de contrôle ne pourraient pas être soulevées. Vous pourriez voir LISFD - Message d'erreur du socket FD d'auditeur. Ceci peut se produire pour d'autres raisons aussi bien, comme la corruption de paquet, recevant une REMISE, la non-concordance entre le vEdge et les contrôleurs sur le TLS contre des ports DTLS ou si les ports FW ne sont pas ouverts, etc.
La plupart de cause classique est un IP en double de transport. Vérifiez la Connectivité et assurez-vous que les adresses sont seules.
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
Question de délai d'attente de pair (VM_TMO)
Un état de délai d'attente de pair est déclenché par quand un vEdge perd l'accessibilité au contrôleur en question.
Dans cet exemple, il capture un msg de délai d'attente de vManage (pair VM_TMO). D'autres incluent le vBond de pair, le vSmart et/ou les délais d'attente de vEdge (VB_TMO, VP_TMO, VS_TMO).
En tant qu'élément du dépannage, assurez-vous que vous avez la Connectivité au contrôleur. Utilisez le Protocole ICMP (Internet Control Message Protocol) et/ou la traceroute à l'IP address en question. Les cas où il y a un bon nombre de trafic chute (la perte est élevée). Le ping rapide et s'assurent que c'est bon.
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
En outre, vérifiez la sortie de commande de détail de connexion-historique de contrôle d'exposition afin de regarder les statistiques de contrôle TX/RX pour voir s'il y a n'importe quelle anomalie significative dans les compteurs. Notez dans sorti la différence des nombres entre RX et TX bonjour paquets.
----------------------------------------------------------------------------------------
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
Numéros de série non actuels (CRTREJSER, BIDNTVRFD)
Si le numéro de série n'est pas présent sur les contrôleurs pour un périphérique indiqué, vous verrez que les connexions de contrôle échouent.
Il peut être vérifié avec des shows controllers [valides-vsmarts | ] sorties valides-vedges et réparé le plus souvent. Naviguez vers la configuration > les Certificats > envoient aux contrôleurs ou envoient aux boutons de vBond des onglets correspondants de vManage. Sur le vBond, orchestrator d'exposition de contrôle valide-vedges/orchestrator d'exposition valide-vsmarts.
Dans le vBond de logins vous pourriez également observer ces messages avec la raison 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"
Quand vous dépannez un tel problème, assurez-vous que le modèle correct de numéro de série et de périphérique a été configuré et provisioned sur le portail de PnP (software.cisco.com) et le vManage.
Afin de vérifier le numéro de châssis et délivrer un certificat le numéro de série, cette commande peut être utilisée sur des Routeurs de vEdge :
vEdge1# show control local-properties | include "chassis-num|serial-num" chassis-num/unique-id 11OG528180107 serial-num 1001247E
Sur le routeur qui exécute le Cisco IOS® - Logiciel XE SDWAN, vous pouvez utiliser :
cEdge1#show sdwan control local-properties | include chassis-num|serial-num chassis-num/unique-id C1111-4PLTEEA-FGL223911LK serial-num 016E9999
ou
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
Pour des questions avec vEdge/vSmart
Voici comment l'erreur regarde sur vEdge/vSmart de connexion-historique de contrôle d'exposition :
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
Sur le vBond du connexion-historique d'orchestrator d'exposition :
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
En outre, vous ne trouverez pas le numéro de série de périphérique sur le vBond dans la liste de vEdges valides :
vbond1# show orchestrator valid-vedges | i 11OG528180107
Pour des questions avec des contrôleurs
Si le fichier séquentiel entre les contrôleurs lui-même ne s'assortit pas, l'erreur locale sur le vBond est le numéro de série qui n'est pas présent contre le certificat retiré pour vSmarts/vManage.
Sur le 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
Sur vSmart/vManage affecté :
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
En outre, vous pourriez voir des messages ORPTMO sur le vSmart affecté quant au 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
Sur le vSmart affecté par vEdge dans l'exposition contrôlez erreur du connexion-historique la « SERNTPRES » est vu :
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
Châssis-numérique faux/identificateur unique
Un autre exemple de la même erreur « CRTREJSER/NOERR » peut être vu si l'identité de produit fausse (modèle) est utilisée sur le portail PNP. Par exemple :
vbond# show orchestrator valid-vedges | include ASR1002 ASR1002-HX-DNA-JAE21050110 014EE30A valid Cisco SVC N1
Cependant, le modèle de véritable appareil est différent (la note qui le suffixe « DNA » n'est pas dans le nom) :
ASR1k#show sdwan control local-properties | include chassis-num chassis-num/unique-id ASR1002-HX-JAE21050110
Non-concordance d'organisation (CTORGNMMIS)
Le nom d'organisation est un élément essentiel pour la connexion de contrôle apportent. Pour un recouvrement donné, l'Org. le nom doit s'assortir à travers tous les contrôleurs et vEdges de sorte que des connexions de contrôle puissent être soulevées.
Sinon, vous verrez le « certificat Org. non-concordance de nom » comme vu ici :
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
le certificat vEdge/vSmart a retiré/infirmé (VSCRTREV/CRTVERFL)
Dans des cas quand le certificat est retiré sur des contrôleurs ou numéro de série de vEdge est infirmé, l'utilisateur verra un message retiré par certification de vSmart ou de vEdge respectivement.
Voici les exemples de sortie du certificat de vSmart retirent des messages. C'est le certificat qui est retiré sur le 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
De même, sur un autre vSmart dans le même recouvrement, c'est comment il voit le vSmart dont le certificat est retiré :
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
Et voici comment le vBond voit ceci :
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 panne de vérification de certification est quand le certificat ne peut pas être vérifié avec le CERT de racine installé :
1. Vérifiez le temps avec la commande de show clock. Il devrait être au moins dans la marge de validité du certificat des vBond (orchestrator gens du pays-Properties d'exposition de contrôle).
2. Ceci peut sont provoqué par par la corruption de CERT de racine sur le vEdge.
Alors le connexion-historique de contrôle d'exposition sur le routeur de vEdge pourrait afficher la sortie semblable :
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
Dans ce cas, le vEdge ne peut pas valider le certificat de contrôleur aussi bien. Afin de réparer cette question, vous pouvez réinstaller la chaîne de certificat racine. Au cas où si l'autorité de certification de Symantec est utilisée, vous pourriez copier la chaîne de certificat racine du système de fichiers en lecture seule :
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
modèle de vEdge non relié dans le vManage
Au moment de l'apport de ZTP, si le périphérique n'est pas relié avec un modèle sur le vManage, puis vous ne verrez « aucun config. dans le vManage pour le périphérique ».
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
États passagers (DISCVBD, SYSIPCHNG)
Voici quelques conditions passagères où les connexions de contrôle s'agitent. Ils incluent :
- Système-IP changé sur le vEdge
- Msg de démontage. au vBond (la connexion de contrôle au vBond est passagère)
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
Contribution d’experts de Cisco
- Shankar VemulapalliIngénieur TAC Cisco
- Eugene KhabarovIngénieur TAC Cisco
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)