Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations du plan de contrôle

Vérifier les propriétés locales du contrôle

Vérifier les connexions de contrôle

Protocole de gestion des superpositions

Vérifier si les TLOC OMP sont annoncés à partir des contours

Vérifier si vSmart reçoit et annonce les TLOC

Détection de transfert bidirectionnel

Comprendre la commande show bfd sessions

Commande show tunnel statistics

Liste d'accès

Traduction d’adresses réseau

Comment utiliser les outils stun-client pour détecter le mappage et le filtrage NAT

Types NAT pris en charge pour les tunnels du plan de données

Pare-feu

Sécurité

Problèmes de FAI avec le trafic marqué DSCP

Déboguer BFD

Informations connexes

Introduction

Ce document décrit les problèmes de connexion au plan de données qui peuvent survenir sur les routeurs vEdge après que vous vous êtes correctement connecté au plan de contrôle, mais il n'y a toujours pas de connectivité au plan de données entre les sites.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître la solution SDWAN (Software Defined Wide Area Network) de Cisco.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Note: Toutes les sorties de commande présentées dans ce document proviennent de routeurs vEdge, mais l'approche de dépannage sera la même pour le routeur qui exécute le logiciel SDWAN IOS®-XE. Utilisez le mot clé sdwan afin d'obtenir les mêmes sorties sur le logiciel SDWAN IOS®-XE. Par exemple ; show sdwan control connections au lieu de show control connections.

Informations du plan de contrôle

Vérifier les propriétés locales du contrôle

Afin de vérifier l'état des interfaces WAN sur un vEdge, utilisez la commande show control local-properties wan-interface-list. Dans ce résultat, vous pouvez voir le type de traduction d'adresses de réseau (NAT) RFC 4787. Lorsque le vEdge se trouve derrière un périphérique NAT (pare-feu, routeur, etc.), des adresses IPv4 publiques et privées, des ports UDP (Public and Private Source User Datagram Protocol) sont utilisés pour construire les tunnels du plan de données. Vous pouvez également trouver l'état de l'interface de tunnel, la couleur et le nombre maximal de connexions de contrôle configurées.

vEdge1# show control local-properties wan-interface-list

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/0      203.0.113.225   4501   10.19.145.2     ::               12386    1/1  gold           up    2    no/yes/no   No/No  7:02:55:13   0:09:02:29  N    5

ge0/1      10.20.67.10     12426  10.20.67.10     ::               12426    0/0  mpls           up    2    yes/yes/no  No/No  0:00:00:01   0:11:40:16  N    5

Avec ces données, vous pouvez identifier certaines informations sur la façon dont les tunnels de données doivent être construits et sur les ports que vous devez attendre du point de vue des routeurs afin d'utiliser lorsque vous formez les tunnels de données.

Vérifier les connexions de contrôle

Il est important de s'assurer que la couleur qui ne forme pas les tunnels de plan de données dispose d'une connexion de contrôle établie avec les contrôleurs dans la superposition. Sinon, le vEdge n'envoie pas les informations TLOC (Transport Locator) à vSmart via le protocole OMP (Overlay Management Protocol). Vous pouvez vous assurer qu'il fonctionne ou non avec l'utilisation de la commande show control connections, et rechercher l'état connect.

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     STATE           UPTIME      ID

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

vsmart  dtls 1.1.1.3         3          1      203.0.113.13                          12446 203.0.113.13                          12446 gold            up              7:03:18:31  0

vbond   dtls -               0          0      203.0.113.12                          12346 203.0.113.12                          12346 mpls            connect                     0

vmanage dtls 1.1.1.1         1          0      203.0.113.14                          12646 203.0.113.14                          12646 gold            up              7:03:18:31  0

Si l'interface qui ne forme pas de tunnels de données tente de se connecter, vous pouvez la résoudre en obtenant une amélioration réussie des connexions de contrôle via cette couleur. Vous pouvez également contourner ce problème en définissant les connexions max-control-connections 0 dans l'interface sélectionnée sous la section interface de tunnel.

vpn 0

interface ge0/1

ip address 10.20.67.10/24

tunnel-interface

encapsulation ipsec

color mpls restrict

max-control-connections 0

no allow-service bgp

allow-service dhcp

allow-service dns

allow-service icmp

no allow-service sshd

no allow-service netconf

no allow-service ntp

no allow-service ospf

no allow-service stun

!

no shutdown

!

Note: Parfois, vous pouvez utiliser la commande no control-connections afin d'atteindre le même objectif. Cependant, cette commande n'établit pas un nombre maximal de connexions de contrôle. Cette commande est déconseillée à partir de la version 15.4 et ne doit pas être utilisée sur un logiciel plus récent.

Protocole de gestion des superpositions

Vérifier si les TLOC OMP sont annoncés à partir des contours

Comme vous l'avez remarqué, à l'étape précédente, les TLOC OMP ne peuvent pas être envoyés car l'interface tente de créer des connexions de contrôle via cette couleur et n'est pas en mesure d'atteindre les contrôleurs. Vérifiez donc si la couleur que les tunnels de données ne fonctionnent pas ou s'affiche envoie le TLOC pour cette couleur particulière aux vSmarts. Utilisez la commande show omp tlocs annoncés afin de vérifier les TLOC qui sont envoyés aux homologues OMP.

Exemple : Couleurs pls et or. Aucun TLOC n'est envoyé à vSmart pour les mappages de couleurs.

vEdge1# show omp tlocs advertised

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         gold             ipsec  0.0.0.0          C,Red,R   1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up

1.1.1.20         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        down

1.1.1.20         blue             ipsec  1.1.1.3          C,I,R     1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        up

1.1.1.30         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        down

1.1.1.30         gold             ipsec  1.1.1.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up

1.1.1.40         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        down

1.1.1.40         gold             ipsec  1.1.1.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Exemple : Couleurs pls et or. TLOC est envoyé pour les deux couleurs.

vEdge2# show omp tlocs advertised

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         gold             ipsec  1.1.1.3          C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up

1.1.1.20         mpls             ipsec  0.0.0.0          C,Red,R   1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        up

1.1.1.20         blue             ipsec  0.0.0.0          C,Red,R   1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        up

1.1.1.30         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        up

1.1.1.30         gold             ipsec  1.1.1.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up

1.1.1.40         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        up

1.1.1.40         gold             ipsec  1.1.1.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Note: Pour toute information de plan de contrôle générée localement, le champ « FROM PEER » sera défini sur 0.0.0.0. Lorsque vous recherchez des informations locales, assurez-vous qu'elles correspondent en fonction de cette valeur.

Vérifier si vSmart reçoit et annonce les TLOC

Maintenant que vous savez que vos TLOC sont annoncés au vSmart, confirmez qu'il reçoit les TLOC du bon homologue et l'annonce à l'autre vEdge.

Exemple : vSmart reçoit les TLOC de 1.1.1.20 vEdge1.

vSmart1# show omp tlocs received

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         gold             ipsec  1.1.1.10         C,I,R     1       203.0.113.225  4501    10.19.145.2      12386    ::      0       ::       0        -

1.1.1.20         mpls             ipsec  1.1.1.20         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -

1.1.1.20         blue             ipsec  1.1.1.20         C,I,R     1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        -

1.1.1.30         mpls             ipsec  1.1.1.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -

1.1.1.30         gold             ipsec  1.1.1.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -

1.1.1.40         mpls             ipsec  1.1.1.40         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -

1.1.1.40         gold             ipsec  1.1.1.40         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Si vous ne voyez pas les TLOC ou si vous voyez d'autres codes ici, vous pouvez vérifier :

vSmart-vIPtela-MEX# show omp tlocs received

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         gold             ipsec  1.1.1.10         C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        -

1.1.1.20         mpls             ipsec  1.1.1.20         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -

1.1.1.20         blue             ipsec  1.1.1.20         Rej,R,Inv 1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        -

1.1.1.30         mpls             ipsec  1.1.1.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -

1.1.1.30         gold             ipsec  1.1.1.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -

1.1.1.40         mpls             ipsec  1.1.1.40         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -

1.1.1.40         gold             ipsec  1.1.1.40         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Vérifiez s'il n'existe aucune stratégie qui bloque les TLOC.

show run policy control-policy - recherchez toute liste de tloc qui refuse que vos TLOC soient annoncés ou reçus dans vSmart.

vSmart1(config-policy)# sh config

policy

lists

tloc-list SITE20

tloc 1.1.1.20 color blue encap ipsec

!

!

control-policy SDWAN

sequence 10

match tloc

tloc-list SITE20

!

action reject ----> here we are rejecting the TLOC 1.1.1.20,blue,ipsec

!

!

default-action accept

!

apply-policy

site-list SITE20

control-policy SDWAN in -----> the policy is applied to control traffic coming IN the vSmart, it will filter the tlocs before adding it to the OMP table.

Note: Si un TLOC est Rejeté ou Non valide, il ne sera pas annoncé aux autres contours.

Assurez-vous qu'une stratégie ne filtre pas le TLOC lorsqu'il est annoncé à partir de vSmart. Vous pouvez voir que le TLOC est reçu sur le vSmart, mais vous ne le verrez pas sur l'autre vEdge.

Exemple 1 : vSmart avec TLOC en C, I, R.

vSmart1# show omp tlocs

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         mpls             ipsec  1.1.1.10         C,I,R     1       10.20.67.10      12406   10.20.67.10      12406    ::      0       ::       0        -

1.1.1.10         gold             ipsec  1.1.1.10         C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        -

1.1.1.20         mpls             ipsec  1.1.1.20         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -

1.1.1.20         blue             ipsec  1.1.1.20         C,I,R     1       198.51.100.187   12426   10.19.146.2      12426    ::      0       ::       0        -

1.1.1.30         mpls             ipsec  1.1.1.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -

1.1.1.30         gold             ipsec  1.1.1.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -

1.1.1.40         mpls             ipsec  1.1.1.40         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -

1.1.1.40         gold             ipsec  1.1.1.40         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Exemple 2 : vEdge1 ne voit pas le TLOC de couleur bleue provenant de vEdge2. Il ne voit que le TLOC MPLS.

vEdge1# show omp tlocs

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Stg -> staged

Inv -> invalid

PUBLIC           PRIVATE

ADDRESS                                                                      PSEUDO                   PUBLIC                   PRIVATE  PUBLIC  IPV6    PRIVATE  IPV6     BFD

FAMILY   TLOC IP          COLOR            ENCAP  FROM PEER        STATUS    KEY     PUBLIC IP        PORT    PRIVATE IP       PORT     IPV6    PORT    IPV6     PORT     STATUS

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ipv4     1.1.1.10         mpls             ipsec  0.0.0.0          C,Red,R   1       10.20.67.10      12406   10.20.67.10      12406    ::      0       ::       0        up

1.1.1.10         gold             ipsec  0.0.0.0          C,Red,R   1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up

1.1.1.20         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        up

1.1.1.30         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        up

1.1.1.30         gold             ipsec  1.1.1.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up

1.1.1.40         mpls             ipsec  1.1.1.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        up

1.1.1.40         gold             ipsec  1.1.1.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Lorsque vous vérifiez la stratégie, vous pouvez voir pourquoi le TLOC n'apparaît pas sur vEdge1.

vSmart1# show running-config policy

policy

lists

tloc-list SITE20

tloc 1.1.1.20 color blue encap ipsec

!

site-list SITE10

site-id 10

!

!

control-policy SDWAN

sequence 10

match tloc

tloc-list SITE20

!

action reject

!

!

default-action accept

!

apply-policy

site-list SITE10

control-policy SDWAN out

!

!

Détection de transfert bidirectionnel

Comprendre la commande show bfd sessions

Voici les éléments clés à rechercher dans le résultat :

vEdge-2# show bfd sessions

SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX

SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME          TRANSITIONS

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1.1.1.10         10       down        blue             gold             10.19.146.2                     203.0.113.225                   4501        ipsec  7           1000           NA              7

1.1.1.30         30       up          blue             gold             10.19.146.2                     192.0.2.129                     12386       ipsec  7           1000           0:00:00:22      2

1.1.1.40         40       up          blue             gold             10.19.146.2                     203.0.113.226                   12386       ipsec  7           1000           0:00:00:22      1

1.1.1.40         40       up          mpls             mpls             10.20.67.10                     10.20.67.40                     12426       ipsec  7           1000           0:00:10:11      0

- IP SYSTÈME : Homologues system-ip

- COULEUR TLOQUE SOURCE ET DISTANTE : Ceci est utile pour savoir quel TLOC vous attendez à recevoir et envoyer.

- SOURCE IP : Il s'agit de l'adresse IP privée. Si vous êtes derrière une NAT, ces informations ne seront pas affichées ici (elles peuvent être vues avec l'utilisation de show control local-properties <wan-interface-list> qui est expliquée au début du document).

- DST PUBLIC IP : Il s'agit de la destination que le vEdge utilise pour former le tunnel du plan de données, qu'il soit ou non derrière NAT. (Par exemple : Ponts directement connectés à Internet ou liaisons MPLS (Multi-Protocol Label Switching)

- DST PUBLIC PORT : port public NAT-ed que le vEdge utilise afin de former le tunnel du plan de données vers le vEdge distant.

- TRANSITIONS : Nombre de fois où la session BFD a modifié son état, de NA à UP et vice versa.

Commande show tunnel statistics

La commande show tunnel statistics peut afficher des informations sur les tunnels du plan de données. Vous pouvez facilement voir si vous envoyez ou recevez des paquets pour un tunnel IPSEC particulier entre les contours. Cela peut vous aider à comprendre si des paquets arrivent à chaque extrémité et à isoler les problèmes de connectivité entre les noeuds.

Dans l'exemple, lorsque vous exécutez la commande plusieurs fois, vous pouvez remarquer un incrément ou aucun incrément dans les tx-pkts ou rx-pkts.

Astuce : Si votre compteur est incrémenté de tx-pkts, vous transmettez des données à l'homologue. Si votre paquet rx ne s'incrémente pas, cela signifie que vous ne recevez pas de données de votre homologue. Dans ce cas, vérifiez l'autre extrémité et vérifiez si les tx-pkts sont incrémentés.

TCP

vEdge2# show tunnel statistics

TUNNEL                                   SOURCE  DEST                                                  TUNNEL                                          MSS

PROTOCOL  SOURCE IP      DEST IP         PORT    PORT   SYSTEM IP    LOCAL COLOR      REMOTE COLOR     MTU     tx-pkts  tx-octets  rx-pkts  rx-octets  ADJUST

---------------------------------------------------------------------------------------------------------------------------------------------------------------

ipsec     172.16.16.147  10.88.244.181   12386   12406  1.1.1.10     public-internet  default          1441    38282    5904968    38276    6440071    1361

ipsec     172.16.16.147  10.152.201.104  12386   63364  100.1.1.100  public-internet  default          1441    33421    5158814    33416    5623178    1361

ipsec     172.16.16.147  10.152.204.31   12386   58851  1.1.1.90     public-internet  public-internet  1441    12746    1975022    12744    2151926    1361

ipsec     172.24.90.129  10.88.244.181   12426   12406  1.1.1.10     biz-internet     default          1441    38293    5906238    38288    6454580    1361

ipsec     172.24.90.129  10.152.201.104  12426   63364  100.1.1.100  biz-internet     default          1441    33415    5157914    33404    5621168    1361

ipsec     172.24.90.129  10.152.204.31   12426   58851  1.1.1.90     biz-internet     public-internet  1441    12750    1975622    12747    2152446    1361

TUNNEL                                   SOURCE  DEST                                                  TUNNEL                                          MSS

PROTOCOL  SOURCE IP      DEST IP         PORT    PORT   SYSTEM IP    LOCAL COLOR      REMOTE COLOR     MTU     tx-pkts  tx-octets  rx-pkts  rx-octets  ADJUST

---------------------------------------------------------------------------------------------------------------------------------------------------------------

ipsec     172.16.16.147  10.88.244.181   12386   12406  1.1.1.10     public-internet  default          1441    39028    6020779    39022    6566326    1361

ipsec     172.16.16.147  10.152.201.104  12386   63364  100.1.1.100  public-internet  default          1441    34167    5274625    34162    5749433    1361

ipsec     172.16.16.147  10.152.204.31   12386   58851  1.1.1.90     public-internet  public-internet  1441    13489    2089069    13487    2276382    1361

ipsec     172.24.90.129  10.88.244.181   12426   12406  1.1.1.10     biz-internet     default          1441    39039    6022049    39034    6580835    1361

ipsec     172.24.90.129  10.152.201.104  12426   63364  100.1.1.100  biz-internet     default          1441    34161    5273725    34149    5747259    1361

ipsec     172.24.90.129  10.152.204.31   12426   58851  1.1.1.90     biz-internet     public-internet  1441    13493    2089669    13490    2276902    1361

Une autre commande utile est show tunnel statistics bfd qui peut être utilisée pour vérifier le nombre de paquets BFD envoyés et reçus dans un tunnel de plan de données particulier :

vEdge1# show tunnel statistics bfd

BFD   BFD   BFD     BFD

BFD      BFD                            PMTU  PMTU  PMTU    PMTU

TUNNEL                                  SOURCE  DEST   ECHO TX  ECHO RX  BFD ECHO   BFD ECHO   TX    RX    TX      RX

PROTOCOL  SOURCE IP      DEST IP        PORT    PORT   PKTS     PKTS     TX OCTETS  RX OCTETS  PKTS  PKTS  OCTETS  OCTETS

---------------------------------------------------------------------------------------------------------------------------

ipsec     192.168.109.4  192.168.109.5  4500    4500   0        0        0          0          0     0     0       0

ipsec     192.168.109.4  192.168.109.5  12346   12366  1112255  1112253  186302716  186302381  487   487   395939  397783

ipsec     192.168.109.4  192.168.109.7  12346   12346  1112254  1112252  186302552  186302210  487   487   395939  397783

ipsec     192.168.109.4  192.168.110.5  12346   12366  1112255  1112253  186302716  186302381  487   487   395939  397783

Liste d'accès

Une liste d'accès est une étape utile et nécessaire après avoir examiné la sortie show bfd sessions. Maintenant que les adresses IP et les ports privés et publics sont connus, vous pouvez créer une liste de contrôle d'accès (ACL) qui correspond à SRC_PORT, DST_PORT, SRC_IP et DST_IP. Cela peut vous aider à confirmer si vous recevez et envoyez des messages BFD ou non.

Vous trouverez ici un exemple de configuration d’une liste de contrôle d’accès :

policy

access-list checkbfd-out

sequence 10

match

source-ip        192.168.0.92/32

destination-ip   198.51.100.187/32

source-port      12426

destination-port 12426

!

action accept

count bfd-out-to-dc1-from-br1

!

!

default-action accept

!

access-list checkbfd-in

sequence 20

match

source-ip        198.51.100.187/32

destination-ip   192.168.0.92/32

source-port      12426

destination-port 12426

!

action accept

count bfd-in-from-dc1-to-br1

!

!

default-action accept

!

vpn 0

interface ge0/0

access-list checkbfd-in in

access-list checkbfd-out out

!

!

!

Dans l’exemple, cette liste de contrôle d’accès utilise deux séquences. La séquence 10 correspond aux messages BFD qui sont envoyés de ce vEdge à l'homologue. La séquence 20 fait le contraire.

Il correspond aux ports source (privé) et de destination (public). Si vEdge utilise NAT, vérifiez les ports source et de destination appropriés.

Pour vérifier les résultats de chaque numéro de compteur de séquence, utilisez la commande show policy access-list counters <nom de liste d'accès>

vEdge1# show policy access-list-counters

NAME      COUNTER NAME               PACKETS  BYTES

-----------------------------------------------------

checkbfd  bfd-out-to-dc1-from-br1    10       2048

bfd-in-from-dc1-to-br1        0        0

Traduction d’adresses réseau

Comment utiliser les outils stun-client pour détecter le mappage et le filtrage NAT

Si vous avez effectué toutes les étapes mentionnées et que vous êtes derrière NAT, l'étape suivante consiste à identifier le comportement de mappage et de filtrage NAT UDP Traversal (RFC 4787). Cet outil est vraiment utile pour découvrir l'adresse IP externe vEdge locale lorsque ce vEdge est situé derrière un périphérique NAT. Cette commande obtient un mappage de port pour le périphérique et découvre éventuellement les propriétés de la NAT entre le périphérique local et un serveur (serveur public : exemple google stun server).

Note: Pour plus d'informations, visitez : Docs Viptela - Client STUN

vEdge1# tools stun-client vpn 0 options "--mode full --localaddr 192.168.12.100 12386 --verbosity 2 stun.l.google.com 19302"

stunclient --mode full --localaddr 192.168.12.100 stun.l.google.com in VPN 0

Binding test: success

Local address: 192.168.12.100:12386

Mapped address: 203.0.113.225:4501

Behavior test: success

Nat behavior: Address Dependent Mapping

Filtering test: success

Nat filtering: Address and Port Dependent Filtering

Sur les versions plus récentes du logiciel, la syntaxe peut être légèrement différente :

vEdge1# tools stun-client vpn 0 options "--mode full --localaddr 192.168.12.100 --localport 12386 --verbosity 2 stun.l.google.com 19302"

Dans cet exemple, vous exécutez un test de détection NAT complet avec l'utilisation du port source UDP 12386 au serveur Google STUN. La sortie de cette commande vous donnera le comportement NAT et le type de filtrage NAT basé sur RFC 4787.

Note: Lorsque vous utilisez des outils, pensez à autoriser le service STUN dans l'interface du tunnel, sinon il ne fonctionnera pas. Utilisez allow-service stun afin de laisser passer les données stun.

vEdge1# show running-config vpn 0 interface ge0/0

vpn 0

interface ge0/0

ip address 10.19.145.2/30

!

tunnel-interface

encapsulation ipsec

color gold

max-control-connections 1

no allow-service bgp

allow-service dhcp

allow-service dns

no allow-service icmp

no allow-service sshd

no allow-service netconf

no allow-service ntp

no allow-service ospf

allow-service stun

!

no shutdown

!

!

Ceci montre le mappage entre la terminologie STUN (Full-Cone NAT) et RFC 4787 (NAT Behavioral for UDP).

Types NAT pris en charge pour les tunnels du plan de données

Dans la plupart des cas, vos couleurs publiques telles que biz-internet ou public-internet peuvent être directement reliées à Internet. Dans d'autres cas, il va y avoir un périphérique NAT derrière l'interface WAN vEdge et le fournisseur d'accès Internet réel, de sorte que le vEdge peut avoir une adresse IP privée et l'autre périphérique (routeur, pare-feu, etc.) peut être le périphérique avec des adresses IP publiques.

Si vous avez un type NAT incorrect, cela pourrait être l'une des raisons les plus courantes qui ne permettent pas la formation de tunnels du plan de données. Il s'agit des types NAT pris en charge.

Pare-feu

Si vous avez déjà vérifié la NAT et que celle-ci ne figure pas dans les types Source et Destination non pris en charge, il est possible qu'un pare-feu bloque les ports utilisés pour former les tunnels du plan de données.

Assurez-vous que ces ports sont ouverts dans le pare-feu pour les connexions au plan de données : Plan de données vEdge à vEdge :

UDP 12346 à 13156

Pour les connexions de contrôle de vEdge aux contrôleurs :

UDP 12346 à 13156

TCP 23456 à 24156

Assurez-vous d'ouvrir ces ports afin de réussir la connexion des tunnels du plan de données.

Lorsque vous vérifiez les ports source et de destination utilisés pour les tunnels de plan de données, vous pouvez utiliser show tunnel statistics ou show bfd sessions | onglet mais pas show bfd sessions. Il n'affichera aucun port source, uniquement les ports de destination comme vous pouvez le voir :

vEdge1# show bfd sessions

SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX

SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME          TRANSITIONS

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

192.168.30.105   50       up          biz-internet     biz-internet     192.168.109.181                 192.168.109.182                 12346       ipsec  7           1000           1:21:28:05      10

192.168.30.105   50       up          private1         private1         192.168.110.181                 192.168.110.182                 12346       ipsec  7           1000           1:21:26:13      2

vEdge1# show bfd sessions | tab

SRC    DST                    SITE                                     DETECT      TX

SRC IP           DST IP           PROTO  PORT   PORT   SYSTEM IP       ID    LOCAL COLOR   COLOR         STATE  MULTIPLIER  INTERVAL  UPTIME      TRANSITIONS

---------------------------------------------------------------------------------------------------------------------------------------------------------------

192.168.109.181  192.168.109.182  ipsec  12346  12346  192.168.30.105  50    biz-internet  biz-internet  up     7           1000      1:21:28:05  10

192.168.110.181  192.168.110.182  ipsec  12346  12346  192.168.30.105  50    private1      private1      up     7           1000      1:21:26:13  2

Note: Vous trouverez plus d'informations sur les ports de pare-feu SD-WAN utilisés ici.

Sécurité

Si vous voyez que votre compteur ACL augmente en entrée et en sortie, vérifiez plusieurs itérations show system statistics diff et assurez-vous qu'il n'y a pas de perte.

vEdge1# show policy access-list-counters

NAME      COUNTER NAME               PACKETS  BYTES

-----------------------------------------------------

checkbfd  bfd-out-to-dc1-from-br1    55       9405

bfd-in-from-dc1-to-br1     54      8478

Dans cette sortie, rx_replay_integritops augmente à chaque itération de la commande show system statistics diff.

vEdge1#show system statistics diff

rx_pkts : 5741427

ip_fwd : 5952166

ip_fwd_arp : 3

ip_fwd_to_egress : 2965437

ip_fwd_null_mcast_group : 26

ip_fwd_null_nhop : 86846

ip_fwd_to_cpu : 1413393

ip_fwd_from_cpu_non_local : 15

ip_fwd_rx_ipsec : 1586149

ip_fwd_mcast_pkts : 26

rx_bcast : 23957

rx_mcast : 304

rx_mcast_link_local : 240

rx_implicit_acl_drops : 12832

rx_ipsec_decap : 21

rx_spi_ipsec_drops : 16

rx_replay_integrity_drops : 1586035

port_disabled_rx : 2

rx_invalid_qtags : 212700

rx_non_ip_drops : 1038073

pko_wred_drops : 3

bfd_tx_record_changed : 23

rx_arp_non_local_drops : 19893

rx_arp_reqs : 294

rx_arp_replies : 34330

arp_add_fail : 263

tx_pkts : 4565384

tx_mcast : 34406

port_disabled_tx : 3

tx_ipsec_pkts : 1553753

tx_ipsec_encap : 1553753

tx_pre_ipsec_pkts : 1553753

tx_pre_ipsec_encap : 1553753

tx_arp_replies : 377

tx_arp_reqs : 34337

tx_arp_req_fail : 2

bfd_tx_pkts : 1553675

bfd_rx_pkts : 21

bfd_tx_octets : 264373160

bfd_rx_octets : 3600

bfd_pmtu_tx_pkts : 78

bfd_pmtu_tx_octets : 53052

rx_icmp_echo_requests : 48

rx_icmp_network_unreach : 75465

rx_icmp_other_types : 47

tx_icmp_echo_requests : 49655

tx_icmp_echo_replies : 48

tx_icmp_network_unreach : 86849

tx_icmp_other_types : 7

vEdge1# show system statistics diff

rx_pkts : 151

ip_fwd : 157

ip_fwd_to_egress : 75

ip_fwd_null_nhop : 3

ip_fwd_to_cpu : 43

ip_fwd_rx_ipsec : 41

rx_bcast : 1

rx_replay_integrity_drops : 41

rx_invalid_qtags : 7

rx_non_ip_drops : 21

rx_arp_non_local_drops : 2

tx_pkts : 114

tx_ipsec_pkts : 40

tx_ipsec_encap : 40

tx_pre_ipsec_pkts : 40

tx_pre_ipsec_encap : 40

tx_arp_reqs : 1

bfd_tx_pkts : 40

bfd_tx_octets : 6800

tx_icmp_echo_requests : 1

vEdge1# show system statistics diff

rx_pkts : 126

ip_fwd : 125

ip_fwd_to_egress : 58

ip_fwd_null_nhop : 3

ip_fwd_to_cpu : 33

ip_fwd_rx_ipsec : 36

rx_bcast : 1

rx_implicit_acl_drops : 1

rx_replay_integrity_drops : 35

rx_invalid_qtags : 6

rx_non_ip_drops : 22

rx_arp_replies : 1

tx_pkts : 97

tx_mcast : 1

tx_ipsec_pkts : 31

tx_ipsec_encap : 31

tx_pre_ipsec_pkts : 31

tx_pre_ipsec_encap : 31

bfd_tx_pkts : 32

bfd_tx_octets : 5442

rx_icmp_network_unreach : 3

tx_icmp_echo_requests : 1

tx_icmp_network_unreach : 3

vEdge1# show system statistics diff

rx_pkts : 82

ip_fwd : 89

ip_fwd_to_egress : 45

ip_fwd_null_nhop : 3

ip_fwd_to_cpu : 24

ip_fwd_rx_ipsec : 22

rx_bcast : 1

rx_implicit_acl_drops : 1

rx_replay_integrity_drops : 24

rx_invalid_qtags : 2

rx_non_ip_drops : 14

rx_arp_replies : 1

tx_pkts : 62

tx_mcast : 1

tx_ipsec_pkts : 24

tx_ipsec_encap : 24

tx_pre_ipsec_pkts : 24

tx_pre_ipsec_encap : 24

tx_arp_reqs : 1

bfd_tx_pkts : 23

bfd_tx_octets : 3908

rx_icmp_network_unreach : 3

tx_icmp_echo_requests : 1

tx_icmp_network_unreach : 3

vEdge1# show system statistics diff

rx_pkts : 80

ip_fwd : 84

ip_fwd_to_egress : 39

ip_fwd_to_cpu : 20

ip_fwd_rx_ipsec : 24

rx_replay_integrity_drops : 22

rx_invalid_qtags : 3

rx_non_ip_drops : 12

tx_pkts : 66

tx_ipsec_pkts : 21

tx_ipsec_encap : 21

tx_pre_ipsec_pkts : 21

tx_pre_ipsec_encap : 21

bfd_tx_pkts : 21

bfd_tx_octets : 3571

Premièrement, exécutez une requête ipsec-rekey sur vEdge. Ensuite, passez en revue plusieurs itérations de show system statistics diff et vérifiez si vous voyez toujours rx_replay_integritops. Si c'est le cas, vérifiez votre configuration de sécurité.

vEdge1# show running-config security

security

ipsec

authentication-type sha1-hmac ah-sha1-hmac

!

!

Si vous avez la configuration mentionnée, essayez d'ajouter ah-no-id au type authentication sous ipsec.

vEdge1# show running-config security

security

ipsec

authentication-type sha1-hmac ah-sha1-hmac ah-no-id

!

!

Astuce : ah-no-id active une version modifiée d'AH-SHA1 HMAC et d'ESP HMAC-SHA1 qui ignore le champ ID dans l'en-tête IP externe du paquet. Cette option prend en charge certains périphériques non-Viptela, qui incluent la fonction NAT d'Apple AirPort Express, qui a un bogue qui provoque la modification du champ ID de l'en-tête IP, un champ non modifiable. Configurez l'option ah-no-id dans la liste des types d'authentification pour que le logiciel AH de Viptela ignore le champ ID dans l'en-tête IP afin que le logiciel de Viptela puisse fonctionner conjointement avec ces périphériques

Problèmes de FAI avec le trafic marqué DSCP

Par défaut, tout le trafic de contrôle et de gestion du routeur vEdge vers les contrôleurs passe par des connexions DTLS ou TLS et est marqué avec une valeur DSCP de CS6 (48 décimales). Pour le trafic des tunnels de lieu de données, les routeurs vEdge utilisent l'encapsulation IPsec ou GRE pour envoyer le trafic de données entre eux. Pour la détection des défaillances du plan de données et la mesure des performances, les routeurs s'envoient régulièrement des paquets BFD. Ces paquets BFD sont également marqués avec une valeur DSCP de CS6 (48 décimales).

Du point de vue d'ISP, ce type de trafic sera également considéré comme trafic UDP avec la valeur DSCP CS6, car les routeurs vEdge et les contrôleurs SD-WAN copient par défaut le DSCP qui marque l'en-tête IP externe.

Voici à quoi pourrait ressembler le fonctionnement de tcpdump sur un routeur FAI de transit :

14:27:15.993766 IP (tos 0xc0, ttl 64, id 44063, offset 0, flags [DF], proto UDP (17), length 168)

192.168.109.5.12366 > 192.168.20.2.12346: [udp sum ok] UDP, length 140

14:27:16.014900 IP (tos 0xc0, ttl 63, id 587, offset 0, flags [DF], proto UDP (17), length 139)

192.168.20.2.12346 > 192.168.109.5.12366: [udp sum ok] UDP, length 111

14:27:16.534117 IP (tos 0xc0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 157)

192.168.109.5.12366 > 192.168.110.6.12346: [no cksum] UDP, length 129

14:27:16.534289 IP (tos 0xc0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 150)

192.168.110.6.12346 > 192.168.109.5.12366: [no cksum] UDP, length 122

Comme vous pouvez le voir ici, tous les paquets sont marqués avec l'octet TOS 0xc0 également appelé champ DS (qui est égal à 192 décimal, ou 110 000 00 en binaire. Les 6 premiers bits d’ordre haut correspondent à la valeur 48 des bits DSCP en notation décimale ou CS6).

Les 2 premiers paquets de la sortie correspondent à un tunnel de plan de contrôle et les 2 restants à un trafic de tunnel de plan de données. En fonction de la longueur de paquet et du marquage TOS, il peut conclure avec une grande confiance qu'il s'agissait de paquets BFD (directions RX et TX). Ces paquets sont également marqués avec CS6.

Certains fournisseurs de services, en particulier les fournisseurs de services VPN L3/MPLS L2 MPLS, peuvent parfois conserverdifférents SLA avec le client et peuvent gérer une classe de trafic différente selon le marquage DSCP du client. Par exemple, vous pouvez bénéficier d'un service haut de gamme pour hiérarchiser le trafic voix et signalisation DSCP EF et CS6. Puisque le trafic prioritaire est presque toujours contrôlé, même si la bande passante totale d'une liaison ascendante n'est pas dépassée, pour ce type de perte de paquets de trafic peut être visible et donc les sessions BFD peuvent également être bloquées.

Dans certains cas, si la file d'attente prioritaire dédiée sur le routeur du fournisseur de services est épuisée, vous ne verrez aucune perte pour le trafic normal (par exemple, exécution d'une requête ping simple à partir du routeur vEdge), car ce trafic est marqué avec la valeur DSCP par défaut 0 comme indiqué ici (octet TOS) :

15:49:22.268044 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 142)

192.168.110.5.12366 > 192.168.109.7.12346: [no cksum] UDP, length 114

15:49:22.272919 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 142)

192.168.110.5.12366 > 192.168.109.7.12346: [no cksum] UDP, length 114

15:49:22.277660 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 142)

192.168.110.5.12366 > 192.168.109.7.12346: [no cksum] UDP, length 114

15:49:22.314821 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 142)

192.168.110.5.12366 > 192.168.109.7.12346: [no cksum] UDP, length 114

Mais en même temps, vos sessions BFD seront battantes :

show bfd history

DST PUBLIC       DST PUBLIC                                  RX      TX

SYSTEM IP        SITE ID  COLOR            STATE       IP               PORT        ENCAP  TIME                     PKTS    PKTS    DEL

---------------------------------------------------------------------------------------------------------------------------------------

192.168.30.4     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:54:23+0200 127     135     0

192.168.30.4     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:54:23+0200 127     135     0

192.168.30.4     13       public-internet  down        192.168.109.4    12346       ipsec  2019-05-01T03:55:28+0200 140     159     0

192.168.30.4     13       public-internet  down        192.168.109.4    12346       ipsec  2019-05-01T03:55:28+0200 140     159     0

192.168.30.4     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:55:40+0200 361     388     0

192.168.30.4     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:55:40+0200 361     388     0

192.168.30.4     13       public-internet  down        192.168.109.4    12346       ipsec  2019-05-01T03:57:38+0200 368     421     0

192.168.30.4     13       public-internet  down        192.168.109.4    12346       ipsec  2019-05-01T03:57:38+0200 368     421     0

192.168.30.4     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:58:05+0200 415     470     0

192.168.30.6     13       public-internet  up          192.168.109.4    12346       ipsec  2019-05-01T03:58:05+0200 415     470     0

192.168.30.6     13       public-internet  down        192.168.109.4    12346       ipsec  2019-05-01T03:58:25+0200 464063  464412  0

Et ici nping est utile pour dépanner :

vedge2# tools nping vpn 0 options "--tos 0x0c --icmp --icmp-type echo --delay 200ms -c 100 -q" 192.168.109.7

Nping in VPN 0

Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2019-05-07 15:58 CEST

Max rtt: 200.305ms | Min rtt: 0.024ms | Avg rtt: 151.524ms

Raw packets sent: 100 (2.800KB) | Rcvd: 99 (4.554KB) | Lost: 1 (1.00%)

Nping done: 1 IP address pinged in 19.83 seconds

Déboguer BFD

Parfois, si une enquête plus approfondie est nécessaire, vous pouvez exécuter le débogage de BFD sur le routeur vEdge. Le gestionnaire de trafic de transfert (FTM) est responsable des opérations BFD sur les routeurs vEdge et vous devez donc déboguer ftm bfd. Toutes les sorties de débogage sont stockées dans le fichier /var/log/tmplog/vdebug et si vous voulez avoir ces messages sur la console (comme le comportement de l'analyse de terminal Cisco IOS®), vous pouvez utiliser monitor start /var/log/tmplog/vdebug. Afin d'arrêter la journalisation, vous pouvez utiliser monitor stop /var/log/tmplog/vdebug. Voici à quoi ressemblera le résultat pour une session BFD qui s'arrête en raison du délai d'attente (le TLOC distant avec l'adresse IP 192.168.110.6 n'est plus accessible) :

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_state[1008]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346,l-tloc(32771)->r-tloc(32772),TLOC 192.168.30.5:biz-internet->192.168.30.6:public-internet IPSEC: BFD Session STATE update, New_State :- DOWN, Reason :- LOCAL_TIMEOUT_DETECT Observed latency :- 7924, bfd_record_index :- 8, Hello timer :- 1000, Detect Multiplier :- 7

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_proc_tunnel_public_tloc_msg[252]: tun_rec_index 13 tloc_index 32772 public tloc 0.0.0.0/0

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_increment_wanif_bfd_flap[2427]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346, : Increment the WAN interface counters by 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_state[1119]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346,l-tloc(32771)->r-tloc(32772),TLOC 192.168.30.5:biz-internet->192.168.30.6:public-internet IPSEC BFD session history update, old state 3 new state 1 current  flap count 1 prev_index 1 current 2

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1140]: Attempting to add TLOC : from_ttm 0 origin remote tloc-index 32772 pub 192.168.110.6:12346 pub v6 :::0 system_ip 192.168.30.6 color 5 spi 333

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_0

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346,l-tloc(32771)->r-tloc(32772),TLOC 192.168.30.5:biz-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 484 to 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32771:32772) src 192.168.110.5:12366 dst 192.168.110.6:12346 record index 8 ref-count 1 sa-idx 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346,l-tloc(32770)->r-tloc(32772),TLOC 192.168.30.5:public-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 485 to 485

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32770:32772) src 192.168.109.5:12366 dst 192.168.110.6:12346 record index 9 ref-count 1 sa-idx 485

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_state[1008]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346,l-tloc(32770)->r-tloc(32772),TLOC 192.168.30.5:public-internet->192.168.30.6:public-internet IPSEC: BFD Session STATE update, New_State :- DOWN, Reason :- LOCAL_TIMEOUT_DETECT Observed latency :- 7924, bfd_record_index :- 9, Hello timer :- 1000, Detect Multiplier :- 7

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_proc_tunnel_public_tloc_msg[252]: tun_rec_index 14 tloc_index 32772 public tloc 0.0.0.0/0

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_increment_wanif_bfd_flap[2427]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346, : Increment the WAN interface counters by 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_state[1119]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346,l-tloc(32770)->r-tloc(32772),TLOC 192.168.30.5:public-internet->192.168.30.6:public-internet IPSEC BFD session history update, old state 3 new state 1 current  flap count 1 prev_index 1 current 2

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1140]: Attempting to add TLOC : from_ttm 0 origin remote tloc-index 32772 pub 192.168.110.6:12346 pub v6 :::0 system_ip 192.168.30.6 color 5 spi 333

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_0

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346,l-tloc(32771)->r-tloc(32772),TLOC 192.168.30.5:biz-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 484 to 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32771:32772) src 192.168.110.5:12366 dst 192.168.110.6:12346 record index 8 ref-count 1 sa-idx 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346,l-tloc(32770)->r-tloc(32772),TLOC 192.168.30.5:public-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 485 to 485

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32770:32772) src 192.168.109.5:12366 dst 192.168.110.6:12346 record index 9 ref-count 1 sa-idx 485

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_send_bfd_msg[499]: Sending BFD notification Down notification to TLOC id 32772

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1140]: Attempting to add TLOC : from_ttm 1 origin remote tloc-index 32772 pub 192.168.110.6:12346 pub v6 :::0 system_ip 192.168.30.6 color 5 spi 333

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_set_del_marker_internal[852]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1285]: UPDATE local tloc

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_0

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32771:32772) proto 50 src 192.168.110.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_create[238]: Attempting BFD session creation. Remote-tloc: tloc-index 32772, system-ip 192.168.30.6, color 5 encap 2from local WAN Interface ge0_1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_clear_delete_marker[828]: (32770:32772) proto 50 src 192.168.109.5:12366 dst 192.168.110.6:12346 ref_count 1

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.110.5:12366->192.168.110.6:12346,l-tloc(32771)->r-tloc(32772),TLOC 192.168.30.5:biz-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 484 to 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32771:32772) src 192.168.110.5:12366 dst 192.168.110.6:12346 record index 8 ref-count 1 sa-idx 484

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: bfdmgr_session_update_sa[1207]: BFD-session TNL 192.168.109.5:12366->192.168.110.6:12346,l-tloc(32770)->r-tloc(32772),TLOC 192.168.30.5:public-internet->192.168.30.6:public-internet IPSEC: session sa index changed from 485 to 485

log:local7.debug: May  7 16:23:09 vedge2 FTMD[674]: ftm_tloc_add[1653]: BFD (32770:32772) src 192.168.109.5:12366 dst 192.168.110.6:12346 record index 9 ref-count 1 sa-idx 485

log:local7.info: May  7 16:23:09 vedge2 FTMD[674]: %Viptela-vedge2-ftmd-6-INFO-1400002: Notification: 5/7/2019 14:23:9 bfd-state-change severity-level:major host-name:"vedge2" system-ip:192.168.30.5 src-ip:192.168.110.5 dst-ip:192.168.110.6 proto:ipsec src-port:12366 dst-port:12346 local-system-ip:192.168.30.5 local-color:"biz-internet" remote-system-ip:192.168.30.6 remote-color:"public-internet" new-state:down deleted:false flap-reason:timeout

log:local7.info: May  7 16:23:09 vedge2 FTMD[674]: %Viptela-vedge2-ftmd-6-INFO-1400002: Notification: 5/7/2019 14:23:9 bfd-state-change severity-level:major host-name:"vedge2" system-ip:192.168.30.5 src-ip:192.168.109.5 dst-ip:192.168.110.6 proto:ipsec src-port:12366 dst-port:12346 local-system-ip:192.168.30.5 local-color:"public-internet" remote-system-ip:192.168.30.6 remote-color:"public-internet" new-state:down deleted:false flap-reason:timeout

Un autre débogage précieux afin d'activer est Tunnel Traffic Manager (TTM) events debug est debug ttm events. Voici à quoi ressemble l'événement BFD DOWN du point de vue de TTM :

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Received TTM Msg LINK_BFD, Client: ftmd, AF: LINK

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[413]:     Remote-TLOC: 192.168.30.6 : public-internet : ipsec, Local-TLOC: 192.168.30.5 : biz-internet : ipsec, Status: DOWN, Rec Idx: 13 MTU: 1441, Loss: 77, Latency: 0, Jitter: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Received TTM Msg LINK_BFD, Client: ftmd, AF: LINK

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[413]:     Remote-TLOC: 192.168.30.6 : public-internet : ipsec, Local-TLOC: 192.168.30.5 : public-internet : ipsec, Status: DOWN, Rec Idx: 14 MTU: 1441, Loss: 77, Latency: 0, Jitter: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Received TTM Msg BFD, Client: ftmd, AF: TLOC-IPV4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[402]:     TLOC: 192.168.30.6 : public-internet : ipsec, Status: DOWN

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_af_tloc_db_bfd_status[234]:   BFD message: I SAY WHAT WHAT tloc 192.168.30.6 : public-internet : ipsec status is 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Sent TTM Msg TLOC_ADD, Client: ompd, AF: TLOC-IPV4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[213]:     TLOC: 192.168.30.6 : public-internet : ipsec, Index: 32772, Origin: REMOTE, Status: DOWN, LR enabled: 0, LR hold time: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[217]:       Attributes: GROUP PREF WEIGHT GEN-ID VERSION TLOCv4-PUB TLOCv4-PRI TLOCv6-PUB TLOCv6-PRI SITE-ID CARRIER ENCAP RESTRICT

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[220]:         Preference: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[223]:         Weight: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[226]:         Gen-ID: 2147483661

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[229]:         Version: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[232]:         Site-ID: 13

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[235]:         Carrier: 4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[241]:         Restrict: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[249]:         Group: Count: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[262]:         Groups: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[269]:         TLOCv4-Public: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[273]:         TLOCv4-Private: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[277]:         TLOCv6-Public: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[281]:         TLOCv6-Private: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[285]:         TLOC-Encap: ipsec-tunnel

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[295]:           Authentication: unknown(0x98) Encryption: aes256(0xc) SPI 334 Proto ESP

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[312]:           SPI 334, Flags 0x1e           Integrity: 1, encrypt-keys: 1 auth-keys: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[317]:           Number of protocols 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[328]:           Number of encrypt types: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[0] AES256-GCM

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[1] AES256-CBC

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[339]:           Number of integrity types: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[344]:           integrity type[0] HMAC_SHA1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[349]:       #Paths: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Sent TTM Msg TLOC_ADD, Client: ftmd, AF: TLOC-IPV4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[213]:     TLOC: 192.168.30.6 : public-internet : ipsec, Index: 32772, Origin: REMOTE, Status: DOWN, LR enabled: 0, LR hold time: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[217]:       Attributes: GROUP PREF WEIGHT GEN-ID VERSION TLOCv4-PUB TLOCv4-PRI TLOCv6-PUB TLOCv6-PRI SITE-ID CARRIER ENCAP RESTRICT

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[220]:         Preference: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[223]:         Weight: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[226]:         Gen-ID: 2147483661

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[229]:         Version: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[232]:         Site-ID: 13

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[235]:         Carrier: 4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[241]:         Restrict: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[249]:         Group: Count: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[262]:         Groups: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[269]:         TLOCv4-Public: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[273]:         TLOCv4-Private: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[277]:         TLOCv6-Public: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[281]:         TLOCv6-Private: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[285]:         TLOC-Encap: ipsec-tunnel

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[295]:           Authentication: unknown(0x98) Encryption: aes256(0xc) SPI 334 Proto ESP

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[312]:           SPI 334, Flags 0x1e           Integrity: 1, encrypt-keys: 1 auth-keys: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[317]:           Number of protocols 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[328]:           Number of encrypt types: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[0] AES256-GCM

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[1] AES256-CBC

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[339]:           Number of integrity types: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[344]:           integrity type[0] HMAC_SHA1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[349]:       #Paths: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Sent TTM Msg TLOC_ADD, Client: fpmd, AF: TLOC-IPV4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[213]:     TLOC: 192.168.30.6 : public-internet : ipsec, Index: 32772, Origin: REMOTE, Status: DOWN, LR enabled: 0, LR hold time: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[217]:       Attributes: GROUP PREF WEIGHT GEN-ID VERSION TLOCv4-PUB TLOCv4-PRI TLOCv6-PUB TLOCv6-PRI SITE-ID CARRIER ENCAP RESTRICT

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[220]:         Preference: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[223]:         Weight: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[226]:         Gen-ID: 2147483661

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[229]:         Version: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[232]:         Site-ID: 13

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[235]:         Carrier: 4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[241]:         Restrict: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[249]:         Group: Count: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[262]:         Groups: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[269]:         TLOCv4-Public: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[273]:         TLOCv4-Private: 192.168.110.6:12346

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[277]:         TLOCv6-Public: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[281]:         TLOCv6-Private: :::0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[285]:         TLOC-Encap: ipsec-tunnel

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[295]:           Authentication: unknown(0x98) Encryption: aes256(0xc) SPI 334 Proto ESP

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[312]:           SPI 334, Flags 0x1e           Integrity: 1, encrypt-keys: 1 auth-keys: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[317]:           Number of protocols 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[328]:           Number of encrypt types: 2

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[0] AES256-GCM

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[333]:           Encrypt type[1] AES256-CBC

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[339]:           Number of integrity types: 1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[344]:           integrity type[0] HMAC_SHA1

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[349]:       #Paths: 0

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[194]: Sent TTM Msg DATA_DEVICE_ADD, Client: pimd, AF: DATA-DEVICE-IPV4

log:local7.debug: May  7 16:58:19 vedge2 TTMD[683]: ttm_debug_announcement[431]:     Device: 192.168.30.6, Status: 2

log:local7.info: May  7 16:58:19 vedge2 FTMD[674]: %Viptela-vedge2-ftmd-6-INFO-1400002: Notification: 5/7/2019 14:58:19 bfd-state-change severity-level:major host-name:"vedge2" system-ip:192.168.30.5 src-ip:192.168.110.5 dst-ip:192.168.110.6 proto:ipsec src-port:12366 dst-port:12346 local-system-ip:192.168.30.5 local-color:"biz-internet" remote-system-ip:192.168.30.6 remote-color:"public-internet" new-state:down deleted:false flap-reason:timeout

log:local7.info: May  7 16:58:20 vedge2 FTMD[674]: %Viptela-vedge2-ftmd-6-INFO-1400002: Notification: 5/7/2019 14:58:19 bfd-state-change severity-level:major host-name:"vedge2" system-ip:192.168.30.5 src-ip:192.168.109.5 dst-ip:192.168.110.6 proto:ipsec src-port:12366 dst-port:12346 local-system-ip:192.168.30.5 local-color:"public-internet" remote-system-ip:192.168.30.6 remote-color:"public-internet" new-state:down deleted:false flap-reason:timeout

Informations connexes

- Documentation produit SDWAN

- Anatomie : Un aperçu des traducteurs d'adresses réseau

- Support et documentation techniques - Cisco Systems