Detección bidireccional de la expedición del Troubleshooting y problemas planos de las conexiones de los datos

Opciones de descarga

PDF (293.0 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (220.6 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (417.0 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:24 de junio de 2019

ID del documento:214510

Acerca de la traducción

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

prerrequisitos

Requisitos

Componentes Utilizados

Controle la información plana

Controle las propiedades del Local del control

Controle los controles de conexión

Cubrió el protocolo de la Administración

Controle si los OMP TLOCs se hacen publicidad de los vEdges

Controle si el vSmart recibe y hace publicidad del TLOCs

Bidirectional Forwarding Detection

Entienda el comando sessions del bfd de la demostración

Estadísticas del túnel del comando show

Lista de acceso

Traducción de la dirección de red

Cómo utilizar al aturdir-cliente de las herramientas para detectar la asignación y la filtración NAT

Tipos utilizados NAT para los túneles del avión de los datos

Firewall

Security

Problemas ISP con el tráfico marcado DSCP

Depuración BFD

Información Relacionada

Introducción

Este documento describe los Problemas de conexión planos de los datos que pudieron presentarse en el Routers del vEdge después de que usted conecte con éxito con el avión del control pero todavía no hay Conectividad del avión de los datos entre los sitios.

Prerrequisitos

Requisitos

Cisco recomienda que usted tiene conocimiento de la solución definida software de Cisco de la red de área extensa (SDWAN).

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Nota: Las salidas del comando all presentadas en este documento son de Routers del vEdge, pero el acercamiento del troubleshooting será lo mismo para el router que ejecuta el IOS® - software XE SDWAN. Utilice la palabra clave sdwan para conseguir las mismas salidas en el IOS® - software XE SDWAN. Por ejemplo; muestre los controles de conexión sdwan en vez de los controles de conexión de la demostración.

Controle la información plana

Controle las propiedades del Local del control

Para controlar el estatus de los interfaces de Red de área ancha (WAN) en un vEdge, utilice la WAN-interfaz-lista de las local-propiedades del control del comando show. En esta salida, usted puede ver el tipo del Network Address Translation (NAT) del RFC 4787. Cuando el vEdge está detrás de un direccionamiento del dispositivo NAT (Firewall, router, etc), público y del soldado IPv4, los puertos del User Datagram Protocol (UDP) de la fuente del público y del soldado se utilizan para construir los túneles del avión de los datos. Usted puede también encontrar el estado de la interfaz del túnel, del color y del número máximo de controles de conexión configurados.

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

Con estos datos, usted puede identificar cierta información sobre cómo los túneles de los datos deben ser construidos y qué puertos usted debe esperar que de la perspectiva del Routers para utilizar cuando usted forma los túneles de los datos.

Controle los controles de conexión

Es importante asegurarse de que el color que no forma los túneles planos de los datos tiene un control de conexión establecido con los reguladores en el recubrimiento. Si no, el vEdge no envía la información del localizador del transporte (TLOC) al vSmart vía el protocolo de la Administración del recubrimiento (OMP). Usted puede asegurarse de si esté para arriba o no con el uso de los controles de conexión de la demostración ordene, y busca el estado conecta.

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 el interfaz que no forma los túneles de los datos intenta conectar, usted puede solucionarlo alcanzando acertada trae-para arriba de los controles de conexión vía ese color. O, usted puede trabajar alrededor de él fijando las máximo-control-conexiones 0 en la interfaz seleccionada bajo sección de la interfaz del túnel.

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
 !

Nota: A veces, usted puede utilizar el comando ningunos controles de conexión para alcanzar la misma meta. Sin embargo, ese comando no establece un número máximo de controles de conexión. Este comando se desaprueba a partir de 15.4 y no se debe utilizar en un más nuevo software.

Protocolo de la Administración del recubrimiento

Controle si los OMP TLOCs se hacen publicidad de los vEdges

Pues usted notó, en el paso anterior, OMP TLOCs no puede ser enviado porque el interfaz intenta formar los controles de conexión vía ese color y no puede alcanzar los reguladores. Así pues, el control si el color que los datos hacen un túnel no trabaja o sube envía el TLOC para ese color determinado a los vSmarts. Utilice los tlocs del omp del comando show des divulgación para controlar el TLOCs que se envían a los pares OMP.

Ejemplo: Mpls y oro de los colores. No se envía ningún TLOC al vSmart para los mpls del color.

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

Ejemplo: Mpls y oro de los colores. TLOC se envía para ambos los colores.

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

Nota: Para cualquier información localmente generada del avión del control, “el campo del PAR” será fijado a 0.0.0.0. Cuando usted busca la información localmente originada, asegure para hacer juego basado en este valor.

Controle si el vSmart recibe y hace publicidad del TLOCs

Ahora que usted sabe que su TLOCs está hecho publicidad hacia fuera al vSmart, confirme que recibe TLOCs del par correcto y hace publicidad de él al otro vEdge.

Ejemplo: el vSmart recibe el TLOCs 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        -

En caso de que usted no vea el TLOCs o le ver ninguna otra códigos aquí, usted puede controlar éstos:

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        -

Controle si no hay directiva que bloquea el TLOCs.

muestre la control-directiva de la directiva del funcionamiento - mire para cualquier tloc-lista que rechace su TLOCs de la publicidad o recepción en el 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.

Nota: Si un TLOC es rechazado o inválido, no será hecho publicidad a los otros vEdges.

Asegúrese de que una directiva no filtre el TLOC cuando se hace publicidad del vSmart. Usted puede ver que el TLOC está recibido en el vSmart, pero usted no lo verá en el otro vEdge.

Ejemplo 1: vSmart con TLOC en el 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        -

Ejemplo 2: vEdge1 no ve el TLOC del azul del color que viene de vEdge2. Ve solamente MPLS TLOC.

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

Cuando usted controla la directiva, usted puede ver porqué el TLOC no aparece en el 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
 !
!

Bidirectional Forwarding Detection

Entienda el comando sessions del bfd de la demostración

Éstas son las cosas dominantes a buscar en la salida:

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

SISTEMA IP: Mira el sistema-IP
FUENTE y COLOR REMOTO TLOC: Esto es útil para saber qué TLOC usted está esperando recibir y enviar.
IP DE ORIGEN: Es el IP privado de la fuente. Si usted está detrás de un NAT, esta información no será visualizada aquí (puede ser visto con el uso del <wan-interface-list> de las local-propiedades del control de la demostración que se explica al inicio del documento).
IP DEL PÚBLICO DST: Es el destino que el vEdge está utilizando para formar el túnel del avión de los datos, cueste lo que cueste si está detrás de NAT o no. (Ejemplo: vEdges asociados directamente a Internet, o links de la transferencia de la escritura de la etiqueta del multi-protocol (MPLS))
PUERTO PÚBLICO DST: Puerto público del Nacional-ed que el vEdge utiliza para formar el túnel del avión de los datos al vEdge remoto.
TRANSICIONES: La cantidad de veces la sesión BFD ha cambiado su estatus, del NA a ASCENDENTE y vice versa.

Estadísticas del túnel del comando show

Las estadísticas del túnel de la demostración pueden el mostrar información sobre los túneles del avión de los datos, usted puede ver fácilmente si usted es de envío o recibiendo los paquetes para un IPSEC determinado haga un túnel entre los vEdges. Esto puede ayudarle a entender si los paquetes lo están haciendo en cada extremo, y aísla los problemas de la Conectividad entre los Nodos.

En el ejemplo, cuando usted funciona con los tiempos múltiples del comando, usted puede notar un incremento o ningún incremento en los tx-pkts o los rx-pkts.

Consejo: Si su contador para los tx-pkts incrementa, usted está transmitiendo los datos hacia fuera al par. Si sus rx-pkts no incrementan, significa que usted no está recibiendo los datos de su par. En este evento, controle el otro extremo y confirme si los tx-pkts están incrementando.

                                                                                                                                                       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

Otro comando útil es el bfd de las estadísticas del túnel de la demostración que se puede utilizar para controlar el número de paquetes BFD enviados y recibido dentro de los datos determinados acepille el túnel:

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

Lista de acceso

Una lista de acceso es una útil y un paso necesario después de que usted mire la salida de las sesiones del bfd de la demostración. Ahora que se saben el soldado, y el público IPS y los puertos, usted puede crear una lista de control de acceso (ACL) para hacer juego contra el SRC_PORT, DST_PORT, SRC_IP, DST_IP. Esto puede ayudarle a confirmar si usted es de recepción y de envío de los mensajes BFD o no.

Aquí usted puede encontrar un ejemplo de una configuración ACL:

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
  !
 !
!

En el ejemplo, este ACL utiliza dos secuencias. La secuencia 10 hace juego los mensajes BFD que se envían de este vEdge al par. La secuencia 20 hace el contrario.

Hace juego contra los puertos del puerto y del destino de la fuente (soldado) (público). Si el vEdge utiliza el NAT, asegure para controlar los puertos de origen y de destino derechos.

Para controlar los golpes en cada problema del contador de la secuencia la acceso-lista de la directiva de la demostración contradice el name> de la <access-lista

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

Traducción de la dirección de red

Cómo utilizar al aturdir-cliente de las herramientas para detectar la asignación y la filtración NAT

Si usted ha hecho todos los pasos mencionados y usted está detrás de NAT, el siguiente paso es identificar el comportamiento de la asignación y de la filtración del Traversal UDP NAT (RFC 4787). Esta herramienta es realmente útil para descubrir la dirección IP externa del vEdge local cuando ese vEdge está situado detrás de un dispositivo NAT. Este comando obtiene una correlación de puertos para el dispositivo y descubre opcionalmente las propiedades sobre el NAT entre el dispositivo local y un servidor (servidor público: el ejemplo Google aturde el servidor).

Nota: Para la visita de una información más detallada: Doc. Viptela - ATURDA al cliente

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

En las versiones más recientes del software, el sintaxis puede ser diferente mordido:

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

En este ejemplo, usted realiza una prueba completa de la detección NAT con el uso del puerto de origen 12386 UDP a Google ATURDE el servidor. La salida de este comando le dará la conducta NAT y el tipo de filtración NAT basado en el RFC 4787.

Nota: Cuando usted utiliza las herramientas aturden, recuerdan permitir el servicio del ATURDIR en la interfaz del túnel, si no no trabajará. El permitir-servicio del uso aturde para dejar el paso de los datos del aturdir.

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
 !
!

Esto muestra que la asignación en medio ATURDE la terminología (Lleno-cono NAT) y el RFC 4787 (NAT del comportamiento para el UDP).

Los tipos utilizados NAT para los datos acepillan los túneles

En la mayor parte de los casos, sus colores del público como negocio-Internet o público-Internet se pueden asociar directamente a Internet. En otros casos, va a ser un dispositivo NAT detrás de la interfaz de WAN del vEdge y del proveedor de servicio real de Internet, así que el vEdge puede tener un IP privado y el otro dispositivo (router, Firewall, etc) puede ser el dispositivo con los IP Addresses públicos del revestimiento.

Si usted tiene un tipo incorrecto NAT, después podría potencialmente ser una de la mayoría de las razones comunes que no permiten la formación de túneles del avión de los datos. Éstos son los tipos utilizados NAT.

Firewall

Si usted llegó ya el NAT y su la fuente y los tipos de destino sin apoyo, es posible que un Firewall está bloqueando los puertos usados para formar los túneles del avión de los datos.

Asegúrese de que estos puertos estén abiertos en el Firewall para las conexiones del avión de los datos: vEdge al avión de los datos del vEdge:

UDP 12346 a 13156

Para los controles de conexión del vEdge a los reguladores:

UDP 12346 a 13156

TCP 23456 a 24156

Asegúrese de que usted abra estos puertos para alcanzar la conexión satisfactoria de los túneles del avión de los datos.

Cuando usted controla los puertos de origen y de destino usados para los datos acepillan los túneles, usted puede utilizar las estadísticas del túnel de la demostración o mostrar las sesiones del bfd | tabulación pero no sesiones del bfd de la demostración. No mostrará ninguna puertos de origen, sólo los puertos de destino como usted puede ver:

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

Nota: Más información sobre los puertos de firewall SD-WAN usados se puede encontrar aquí.

Security

Si usted ve su que su contador ACL es aumento entrante y saliente, controle el diff de las estadísticas del sistema de la demostración de varias iteraciones y asegúrese que no hay descensos.

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

En esta salida, los rx_replay_integrity_drops aumentan con cada iteración del comando diff de las estadísticas del sistema de la demostración.

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

Primero, realice una Seguridad de la petición ipsec-reintroducen en el vEdge. Entonces, pase con varias iteraciones del diff de las estadísticas del sistema de la demostración y vea si usted todavía ve los rx_replay_integrity_drops. Si usted hace, controlar su configuración de Seguridad.

vEdge1# show running-config security  
security
 ipsec
 authentication-type sha1-hmac ah-sha1-hmac
 !
!

Si usted tiene la configuración mencionada, intente agregar la ah-ninguno-identificación al autenticación-tipo bajo ipsec.

vEdge1# show running-config security  
security
 ipsec
 authentication-type sha1-hmac ah-sha1-hmac ah-no-id
 !
!

Consejo: la ah-ninguno-identificación activa una versión modificada de AH-SHA1 HMAC y de la ESP HMAC-SHA1 que ignora el campo identificación en la encabezado externa IP del paquete. Esta opción acomoda algunos dispositivos no--Viptela, eso incluye el Apple Airport NAT expreso, que tiene un bug que cause el campo identificación en la encabezado IP, un campo no-mutable, para ser modificada. Configure la opción ah-ninguno-identificación en la lista de tipos de la autenticación para hacer que el software de Viptela AH ignore el campo identificación en la encabezado IP de modo que el software de Viptela pueda trabajar conjuntamente con estos dispositivos

Problemas ISP con el tráfico marcado DSCP

Por abandono, todo el control y tráfico de administración del router del vEdge a los viajes de los reguladores sobre los DTL o las conexiones TLS y marcados con un valor DSCP de CS6 (decimal 48). Para los datos coloque los túneles trafican, uso IPsec del Routers del vEdge o encapsulación GRE de enviar el tráfico de datos el uno al otro. Para los datos acepille la detección de error y la medición de rendimiento, Routers periódicamente se envía los paquetes BFD. Estos paquetes BFD también se marcan con un valor DSCP de CS6 (decimal 48).

Desde la perspectiva de la ISP, esa considerarán al tipo de tráfico como tráfico UDP con el valor CS6 DSCP también porque el Routers del vEdge y los reguladores SD-WAN copian DSCP ese las marcas a la encabezado externa IP por abandono.

Aquí es cómo puede ser que parezca si el tcpdump se ejecuta en el router del ISP del tránsito:

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

Como puede ser visto aquí, todos los paquetes se marcan con el byte 0xc0 TOS también conocido como campo DS (que es igual al decimal 192, o 110 000 00 en el binario. Los primeros 6 bits de orden alto corresponden al valor de bits DSCP 48 en el decimal o CS6).

Los primeros 2 paquetes en la salida corresponden a un túnel del avión del control y los 2 que permanecen, a los datos acepillan el tráfico de túnel. De acuerdo con la Longitud del paquete y la marca TOS, puede concluir con la alta confianza que era paquetes BFD (las direcciones RX y TX). Estos paquetes se marcan con CS6 también.

Algo mide el tiempo de algunos proveedores de servicio y especialmente los proveedores de servicio MPLS L3 VPN/MPLS L2 VPN pueden SLA maintaindifferent con el cliente y pueden manejar una diversa clase de tráfico basada en el cliente DSCP que marca diferentemente. Por ejemplo, usted puede ser que tenga el servicio superior para dar prioridad a la Voz DSCP EF y CS6 y a la señalización de tráfico. Puesto que el tráfico de prioridad se limpia casi siempre, incluso si el ancho de banda total del uplink no se excede, porque esta pérdida del paquete del tipo de tráfico puede ser considerada y por lo tanto las sesiones BFD pueden agitar también.

Fue visto en algunos casos que si el priority queue dedicado en el router del proveedor de servicio es hambriento, usted no verá ninguna descensos para el tráfico normal (e.g ping simple que se ejecuta del router del vEdge) porque tal tráfico se marca con el valor 0 del valor por defecto DSCP como puede ser visto aquí (byte 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

Pero al mismo tiempo, sus sesiones BFD agitarán:

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

Y aquí el nping viene práctico para resolver problemas:

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

Depuración BFD

Algunas veces, si se requiere una investigación más profunda, usted puede ser que quiera ejecutar el depuración del BFD en el router del vEdge. El encargado del tráfico de reenvío (FTM) es responsable de las operaciones BFD en el Routers del vEdge y por lo tanto usted necesita el bfd del ftm de la depuración. Toda la salida del depuración se salva en el fichero de /var/log/tmplog/vdebug y si usted quiere tener esos mensajes en la consola (similar al comportamiento del monitor del ®terminal del Cisco IOS), usted puede utilizar el comienzo /var/log/tmplog/vdebug del monitor. Para parar el registrar, usted puede utilizar la parada /var/log/tmplog/vdebug del monitor. Aquí es cómo la salida parecerá para la sesión BFD que va abajo debido al descanso (el telecontrol TLOC con la dirección IP 192.168.110.6 no es accesible más):

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

Otra depuración valiosa para activar es eventos del encargado del tráfico de túnel (TTM) que la depuración es eventos del ttm de la depuración. Aquí es cómo el evento BFD ABAJO parece desde la perspectiva del 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