Resolución de Problemas de Detección de Reenvío Bidireccional y Conexiones del Plano de Datos

Opciones de descarga

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

Actualizado:24 de junio de 2019

ID del documento:214510

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

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

Prerequisites

Requirements

Componentes Utilizados

Información del plano de control

Comprobar propiedades locales del control

Comprobar conexiones de control

Overlay Management Protocol

Compruebe si las OMP TLOC se anuncian desde los límites

Compruebe si vSmart recibe y anuncia las TLOC

Bidirectional Forwarding Detection

Comprender el comando show bfd sessions

Comando show tunnel statistics

Lista de acceso

Traducción de direcciones de red

Cómo utilizar herramientas stun-client para detectar asignación y filtrado de NAT

Tipos NAT admitidos para túneles de plano de datos

Firewalls

Security

Problemas de ISP con el tráfico marcado por DSCP

Debug BFD

Información Relacionada

Introducción

Este documento describe los problemas de conexión del plano de datos que pueden surgir en los routers vEdge después de conectarse correctamente al plano de control, pero todavía no hay conectividad de plano de datos entre los sitios.

Prerequisites

Requirements

Cisco recomienda que conozca la solución Cisco Software Defined Wide Area Network (SDWAN).

Componentes Utilizados

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

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Nota: Todos los resultados de comandos presentados en este documento son de routers vEdge, pero el enfoque de solución de problemas será el mismo para el router que ejecuta el software IOS®-XE SDWAN. Utilice la palabra clave sdwan para obtener los mismos resultados en el software IOS®-XE SDWAN. Por ejemplo; show sdwan control connections en lugar de show control connections.

Información del plano de control

Comprobar propiedades locales del control

Para comprobar el estado de las interfaces de red de área extensa (WAN) en un vEdge, utilice el comando show control local-properties wan-interface-list. En este resultado, puede ver el tipo de traducción de direcciones de red (NAT) RFC 4787. Cuando el vEdge se encuentra detrás de un dispositivo NAT (firewall, router, etc.), se utilizan los puertos de dirección IPv4 pública y privada, protocolo de datagramas de usuario de origen público y privado (UDP) para crear los túneles del plano de datos. También puede encontrar el estado de la interfaz de túnel, el color y el número máximo de conexiones de control configuradas.

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, puede identificar cierta información acerca de cómo se deben construir los túneles de datos y qué puertos debe esperar desde la perspectiva de los routers para utilizar cuando se forman los túneles de datos.

Comprobar conexiones de control

Es importante asegurarse de que el color que no forma los túneles del plano de datos tenga una conexión de control establecida con los controladores en la superposición. De lo contrario, vEdge no envía la información de Transport Locator (TLOC) al vSmart mediante Overlay Management Protocol (OMP). Puede asegurarse de si está activo o no con el uso del comando show control connections, y buscar el estado 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 la interfaz que no forma túneles de datos intenta conectarse, puede resolverlo logrando la correcta activación de las conexiones de control a través de ese color. O bien, puede resolverlo estableciendo el max-control-connections 0 en la interfaz seleccionada en la sección de interfaz de 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, puede utilizar el comando no control-connections para lograr el mismo objetivo. Sin embargo, ese comando no establece un número máximo de conexiones de control. Este comando está obsoleto a partir de 15.4 y no debe utilizarse en software más reciente.

Overlay Management Protocol

Compruebe si las OMP TLOC se anuncian desde los límites

Como ha observado, en el paso anterior, no se pueden enviar las TLOC de OMP porque la interfaz intenta formar conexiones de control a través de ese color y no puede alcanzar los controladores. Entonces, verifique si el color que los túneles de datos no funcionan o que aparecen envía el TLOC para ese color en particular a vSmarts. Utilice el comando show omp tlocs anunciado para verificar las TLOCs que se envían a los peers OMP.

Ejemplo: Colores mpls y oro. No se envía ningún TLOC a vSmart para los mpls de 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: Colores mpls y oro. TLOC se envía para ambos 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 del plano de control generado localmente, el campo "FROM PEER" se establecerá en 0.0.0.0. Cuando busque información originada localmente, asegúrese de coincidir según este valor.

Compruebe si vSmart recibe y anuncia las TLOC

Ahora que sabe que sus TLOC se anuncian al vSmart, confirme que recibe TLOC del par correcto y lo anuncia al otro vEdge.

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

En caso de que no vea las TLOC o vea otros códigos aquí, puede verificar lo siguiente:

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        -

Verifique si no hay ninguna política que bloquee las TLOC.

show run policy control-policy-look para cualquier tloc-list que rechace que sus TLOCs se anuncien o reciban en 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 se rechaza o no es válido, no se anunciará a los otros vEdges.

Asegúrese de que una política no filtra el TLOC cuando se anuncia desde el vSmart. Puede ver que TLOC se recibe en vSmart, pero no lo verá en el otro vEdge.

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

Ejemplo 2: vEdge1 no ve el TLOC del color azul que viene del vEdge2. Solo ve 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 verifica la política, puede ver por qué 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

Comprender el comando show bfd sessions

Estas son las cosas clave que hay que buscar en el resultado:

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 DEL SISTEMA: Sistema IP de Peers
COLOR DE TLOC FUENTE Y REMOTO: Esto es útil para saber qué TLOC espera recibir y enviar.
IP DE ORIGEN: Es la IP de origen privada. Si está detrás de una NAT, esta información no se mostrará aquí (se puede ver con el uso de show control local-properties <wan-interface-list> que se explica al inicio del documento).
IP PÚBLICA DST: Es el destino que el vEdge está utilizando para formar el túnel del plano de datos, independientemente de si está detrás de NAT o no. (Ejemplo: Bordes conectados directamente a Internet o enlaces MPLS (Multi-Protocol Label Switching)
PUERTO PÚBLICO DST: puerto público NAT-ed que el vEdge utiliza para formar el túnel del plano de datos al vEdge remoto.
TRANSICIONES: Número de veces que la sesión BFD ha cambiado su estado, de NA a UP y viceversa.

Comando show tunnel statistics

El comando show tunnel statistics puede mostrar información sobre los túneles del plano de datos, puede ver fácilmente si está enviando o recibiendo paquetes para un túnel IPSEC determinado entre los vEdges. Esto puede ayudarle a entender si los paquetes lo están haciendo en cada extremo y a aislar los problemas de conectividad entre los nodos.

En el ejemplo, cuando ejecuta el comando varias veces, puede observar un incremento o ningún incremento en los tx-pkts o rx-pkts.

Consejo: Si su contador para tx-pkts se incrementa, está transmitiendo datos al par. Si sus rx-pkts no aumentan, significa que no está recibiendo datos de su par. En este caso, verifique el otro extremo y confirme si los tx-pkts están aumentando.

                                                                                                                                                       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 show tunnel statistics bfd que se puede utilizar para verificar el número de paquetes BFD enviados y recibidos dentro de un túnel de plano de datos determinado:

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 un paso útil y necesario después de ver el resultado show bfd sessions. Ahora que se conocen las IP y los puertos públicos y privados, puede crear una lista de control de acceso (ACL) que coincida con SRC_PORT, DST_PORT, SRC_IP, DST_IP. Esto puede ayudarle a confirmar si está recibiendo y enviando mensajes BFD o no.

Aquí puede encontrar un ejemplo de una configuración de 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, esta ACL utiliza dos secuencias. La secuencia 10 coincide con los mensajes BFD que se envían desde este vEdge al par. La secuencia 20 hace lo contrario.

Coincide con los puertos de origen (privado) y de destino (público). Si el vEdge utiliza NAT, asegúrese de verificar los puertos de origen y de destino correctos.

Para verificar los resultados en cada contador de secuencia, ejecute el comando show policy access-list counters <access-list name>

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 direcciones de red

Cómo utilizar herramientas stun-client para detectar asignación y filtrado de NAT

Si ha realizado todos los pasos mencionados y está detrás de NAT, el siguiente paso es identificar el comportamiento de asignación y filtrado de NAT transversal UDP (RFC 4787). Esta herramienta es muy útil para descubrir la dirección IP externa de vEdge local cuando ese vEdge se encuentra detrás de un dispositivo NAT. Este comando obtiene una asignación de puerto para el dispositivo y, opcionalmente, descubre las propiedades sobre la NAT entre el dispositivo local y un servidor (servidor público: ejemplo de servidor stun de google).

Nota: Para obtener información más detallada, visite: Docs Viptela - Cliente 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

En las versiones más recientes del software, la sintaxis puede ser un poco diferente:

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 de detección NAT completa con el uso del puerto de origen UDP 12386 al servidor Google STUN. El resultado de este comando le dará el comportamiento de NAT y el tipo de filtrado de NAT basado en RFC 4787.

Nota: Cuando utilice tools stun, recuerde permitir el servicio STUN en la interfaz de túnel, de lo contrario no funcionará. Utilice allow-service stun para permitir que pasen los datos 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
 !
!

Muestra la asignación entre la terminología STUN (NAT de conos completos) y RFC 4787 (comportamiento NAT para UDP).

Tipos NAT admitidos para túneles de plano de datos

En la mayoría de los casos, sus colores públicos como internet biz o internet público pueden estar directamente conectados a Internet. En otros casos, habrá un dispositivo NAT detrás de la interfaz WAN de vEdge y el proveedor de servicios de Internet real, de modo que el vEdge pueda tener una IP privada y el otro dispositivo (router, firewall, etc.) pueda ser el dispositivo con las direcciones IP de cara pública.

Si tiene un tipo NAT incorrecto, podría ser potencialmente una de las razones más comunes que no permiten la formación de túneles del plano de datos. Estos son los tipos NAT soportados.

Firewalls

Si ya verificó la NAT y no se encuentra en los tipos de origen y destino no admitidos, es posible que un firewall esté bloqueando los puertos utilizados para formar los túneles del plano de datos.

Asegúrese de que estos puertos estén abiertos en el firewall para las conexiones del plano de datos: Plano de datos de vEdge a vEdge:

UDP 12346 a 13156

Para las conexiones de control de vEdge a los controladores:

UDP 12346 a 13156

TCP 23456 a 24156

Asegúrese de abrir estos puertos para lograr una conexión correcta de los túneles del plano de datos.

Cuando verifica los puertos de origen y destino utilizados para los túneles del plano de datos, puede utilizar show tunnel statistics o show bfd sessions | ficha pero no mostrar sesiones bfd. No mostrará ningún puerto de origen, sólo los puertos de destino como 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: Puede encontrar más información sobre los puertos de firewall SD-WAN que se utilizan aquí.

Security

Si ve que su contador de ACL está aumentando de entrada y de salida, verifique varias iteraciones que muestran las estadísticas del sistema de diff y asegúrese de que no haya caídas.

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 este resultado, rx_replay_Integrity_drops aumenta con cada iteración del comando 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

Primero, realice una solicitud de seguridad ipsec-rekey en el vEdge. Luego, vaya a varias iteraciones de show system statistics diff y vea si aún ve rx_replay_Integrity_drops. Si lo hace, compruebe la configuración de seguridad.

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

Si tiene la configuración mencionada, intente agregar ah-no-id al tipo de autenticación en ipsec.

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

Consejo: ah-no-id habilita una versión modificada de AH-SHA1 HMAC y ESP HMAC-SHA1 que ignora el campo ID en el encabezado IP externo del paquete. Esta opción se adapta a algunos dispositivos que no son de Viptela, que incluyen la NAT Apple AirPort Express, que tiene un error que hace que se modifique el campo ID en el encabezado IP, un campo no mutable. Configure la opción ah-no-id en la lista de tipos de autenticación para que el software Viptela AH ignore el campo ID en el encabezado IP para que el software Viptela pueda funcionar junto con estos dispositivos

Problemas de ISP con el tráfico marcado por DSCP

De forma predeterminada, todo el tráfico de control y gestión desde el router vEdge a los controladores viaja a través de conexiones DTLS o TLS y se marca con un valor DSCP de CS6 (48 decimales). En el caso del tráfico de túneles del lugar de datos, los routers vEdge utilizan la encapsulación IPsec o GRE para enviarse tráfico de datos entre sí. Para la detección de fallas en el plano de datos y la medición del rendimiento, los routers se envían periódicamente paquetes BFD entre sí. Estos paquetes BFD también se marcan con un valor DSCP de CS6 (48 decimales).

Desde la perspectiva del ISP, ese tipo de tráfico se verá como tráfico UDP con valor DSCP CS6 también porque los routers vEdge y los controladores SD-WAN copian DSCP que marca al encabezado IP externo de forma predeterminada.

Así es como podría verse si tcpdump se ejecuta en el router ISP de 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 se puede ver aquí, todos los paquetes se marcan con TOS byte 0xc0 también conocido como campo DS (que es igual a decimal 192 o 110 000 00 en binario). Los primeros 6 bits de orden alto corresponden al valor de bits DSCP 48 en decimal o CS6).

Los primeros 2 paquetes en la salida corresponden a un túnel de plano de control y los 2 que permanecen, a un tráfico de túnel de plano de datos. Basándose en la longitud del paquete y en el marcado de TOS, puede concluir con gran confianza que eran paquetes BFD (direcciones RX y TX). Estos paquetes también se marcan con CS6.

Algunas veces algunos proveedores de servicios y especialmente los proveedores de servicios MPLS L3 VPN/MPLS L2 VPN pueden mantenerdiferentes SLA con el cliente y pueden manejar una clase diferente de tráfico según el marcado DSCP del cliente de manera diferente. Por ejemplo, puede tener un servicio premium para priorizar el tráfico de señalización y voz DSCP EF y CS6. Dado que el tráfico prioritario se controla casi siempre, incluso si no se supera el ancho de banda total de un link ascendente, para este tipo de pérdida de paquetes de tráfico se puede ver y por lo tanto las sesiones BFD también pueden ser inestables.

En algunos casos, se observó que si la cola de prioridad dedicada en el router del proveedor de servicios está indemne, no verá ninguna caída en el tráfico normal (por ejemplo, si ejecuta un ping simple desde el router vEdge) porque dicho tráfico se marca con el valor DSCP predeterminado 0, como se puede ver 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, las sesiones de BFD serán inestables:

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í nping es útil 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

Debug BFD

En algunas ocasiones, si se requiere una investigación más profunda, es posible que desee ejecutar la depuración de BFD en el router vEdge. El administrador de tráfico de reenvío (FTM) es responsable de las operaciones de BFD en los routers vEdge y, por lo tanto, necesita debug ftm bfd. Todos los resultados de depuración se almacenan en el archivo /var/log/tmplog/vdebug y si desea que esos mensajes estén en la consola (similar al comportamiento del monitor de terminal de Cisco IOS®), puede utilizar el comando monitor start /var/log/tmplog/vdebug. Para detener el registro, puede utilizar monitor stop /var/log/tmplog/vdebug. Así es como se verá la salida para la sesión BFD que se interrumpe debido al tiempo de espera (TLOC remoto con dirección IP 192.168.110.6 ya no se puede alcanzar):

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 habilitar es la depuración de eventos del administrador de tráfico de túnel (TTM) es debug ttm events. Así es como se ve el evento BFD DOWN desde la perspectiva 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

Información Relacionada

Con la colaboración de ingenieros de Cisco

Cisco TAC Engineers

Resolución de Problemas de Detección de Reenvío Bidireccional y Conexiones del Plano de Datos

Opciones de descarga

Lenguaje no discriminatorio

Acerca de esta traducción

Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Información del plano de control

Comprobar propiedades locales del control

Comprobar conexiones de control

Overlay Management Protocol

Compruebe si las OMP TLOC se anuncian desde los límites

Compruebe si vSmart recibe y anuncia las TLOC

Bidirectional Forwarding Detection

Comprender el comando show bfd sessions

Comando show tunnel statistics

Lista de acceso

Traducción de direcciones de red

Cómo utilizar herramientas stun-client para detectar asignación y filtrado de NAT

Tipos NAT admitidos para túneles de plano de datos

Firewalls

Security

Problemas de ISP con el tráfico marcado por DSCP

Debug BFD

Información Relacionada

Con la colaboración de ingenieros de Cisco

¿Resultó útil este documento?

Contacte a Cisco

Este documento se aplica a estos productos