Fehlerbehebung bei vEdge-Problemen mit bidirektionaler Weiterleitungserkennung und Verbindungen auf Datenebene

Download-Optionen

PDF (443.8 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (238.9 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (443.7 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:28. September 2022

Dokument-ID:214510

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einleitung

In diesem Dokument werden Verbindungsprobleme auf vEdge-Datenebene nach einer Verbindung auf Kontrollebene beschrieben, jedoch keine Verbindungen auf Datenebene zwischen den Standorten.

Voraussetzungen

Anforderungen

Cisco empfiehlt, sich mit der Cisco Software Defined Wide Area Network (SDWAN) Lösung vertraut zu machen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. Dieses Dokument behandelt vEdge-Plattformen.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Informationen zu Cisco Edge-Routern (Cisco IOS® XE-Router im Controller-Modus) finden Sie unter .

Informationen zur Kontrollebene

Lokale Eigenschaften des Steuerelements überprüfen

Um den Status der Wide Area Network (WAN) Schnittstellen auf einem vEdge zu überprüfen, verwenden Sie den Befehl show control local-properties wan-interface-list.

In dieser Ausgabe sehen Sie den RFC 4787 Network Address Translation (NAT) Type.

Wenn sich der vEdge hinter einem NAT-Gerät (Firewall, Router usw.) befindet, werden öffentliche und private IPv4-Adressen sowie öffentliche und private Quell-User Datagram Protocol (UDP)Ports zum Erstellen der Datenebenen-Tunnel verwendet.

Sie können auch den Status der Tunnelschnittstelle, die Farbe und die maximale Anzahl konfigurierter Steuerverbindungen ermitteln.

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

Mit diesen Daten können Sie bestimmte Informationen darüber identifizieren, wie die Datentunnel aufgebaut werden müssen und welche Ports Sie (aus Routersicht) beim Bilden der Datentunnel erwarten können.

Kontrollverbindungen überprüfen

Wichtig ist, dass die Farbe, die keine Datenebenentunnel bildet, mit den Controllern im Overlay eine Steuerverbindung hat.

Andernfalls sendet der vEdge die Transport Locator (TLOC) Informationen nicht über Overlay Management Protocol (OMP).

Sie können überprüfen, ob es funktioniert, indem Sie den show control connections Befehl verwenden und nach dem connect Status suchen.

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 10.1.0.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 10.1.0.1         1          0      203.0.113.14                          12646 203.0.113.14                          12646 gold            up              7:03:18:31  0

Wenn die Schnittstelle (die keine Datentunnel bildet) versucht, eine Verbindung herzustellen, lösen Sie diese mit einem erfolgreichen Start der Steuerverbindungen über diese Farbe.

Oder legen Sie die max-control-connections 0 in der ausgewählten Schnittstelle unter dem Tunnel-Schnittstellenabschnitt fest.

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
 !

Anmerkung: Manchmal können Sie den no control-connections Befehl verwenden, um dasselbe Ziel zu erreichen. Mit diesem Befehl wird jedoch keine maximale Anzahl von Steuerverbindungen festgelegt. Dieser Befehl ist seit Version 15.4 veraltet und wird in neuerer Software nicht verwendet.

Overlay Management Protocol

Überprüfen Sie, ob OMP-TLOCs von den vEdges angekündigt wurden.

OMP-TLOCs können nicht gesendet werden, da die Schnittstelle versucht, Steuerverbindungen über diese Farbe zu bilden und nicht in der Lage ist, die Controller zu erreichen.

Überprüfen Sie, ob die Farbe (der Datentunnel) den TLOC für diese bestimmte Farbe an vSmarts sendet.

Verwenden Sie den Befehl, show omp tlocs advertised um die TLOCs zu überprüfen, die an die OMP-Peers gesendet werden.

Beispiel: Farben mpls und gold. Es wird kein TLOC für Farbmpls an vSmart gesendet.

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     10.1.0.5         gold             ipsec  0.0.0.0          C,Red,R   1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up      
         10.1.0.2         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        down    
         10.1.0.2         blue             ipsec  10.1.0.3          C,I,R     1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        up      
         10.1.0.30         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        down    
         10.1.0.30         gold             ipsec  10.1.0.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up      
         10.1.0.4         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        down    
         10.1.0.4         gold             ipsec  10.1.0.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Beispiel: Farben mpls und gold. TLOC wird für beide Farben gesendet.

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     10.1.0.5         gold             ipsec  10.1.0.3          C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up      
         10.1.0.2         mpls             ipsec  0.0.0.0          C,Red,R   1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        up      
         10.1.0.2         blue             ipsec  0.0.0.0          C,Red,R   1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        up      
         10.1.0.30         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        up      
         10.1.0.30         gold             ipsec  10.1.0.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up      
         10.1.0.4         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        up      
         10.1.0.4         gold             ipsec  10.1.0.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Anmerkung: Für alle lokal generierten Kontrollebeneninformationen ist das Feld "FROM PEER" auf 0.0.0.0 gesetzt. Wenn Sie nach Informationen suchen, die lokal generiert wurden, stellen Sie sicher, dass diese auf Basis dieses Werts übereinstimmen.

Überprüfen, ob vSmart die TLOCs empfängt und ankündigt

TLOCs werden jetzt dem vSmart angekündigt. Vergewissern Sie sich, dass er TLOCs vom richtigen Peer empfängt, und kündigen Sie dies dem anderen vEdge an.

Beispiel: vSmart empfängt die TLOCs von 10.1.0.2 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     10.1.0.5         gold             ipsec  10.1.0.5         C,I,R     1       203.0.113.225  4501    10.19.145.2      12386    ::      0       ::       0        -       
         10.1.0.2         mpls             ipsec  10.1.0.2         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -       
         10.1.0.2         blue             ipsec  10.1.0.2         C,I,R     1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        -       
         10.1.0.30        mpls             ipsec  10.1.0.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -       
         10.1.0.30        gold             ipsec  10.1.0.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -       
         10.1.0.4         mpls             ipsec  10.1.0.4         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -       
         10.1.0.4         gold             ipsec  10.1.0.4         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Wenn Sie die TLOCs oder andere Codes hier nicht sehen, überprüfen Sie diese:

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     10.1.0.5         gold             ipsec  10.1.0.5         C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        -       
         10.1.0.2         mpls             ipsec  10.1.0.2         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -       
         10.1.0.2         blue             ipsec  10.1.0.2         Rej,R,Inv 1       198.51.100.187   12406   10.19.146.2      12406    ::      0       ::       0        -       
         10.1.0.30         mpls             ipsec  10.1.0.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -       
         10.1.0.30         gold             ipsec  10.1.0.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -       
         10.1.0.4         mpls             ipsec  10.1.0.4         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -       
         10.1.0.4         gold             ipsec  10.1.0.4         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Vergewissern Sie sich, dass keine Richtlinie vorhanden ist, die die TLOCs blockiert.

show run policy control-policy - Suchen Sie nach einer Liste mit Listen, die Ihre TLOCs als advertised oder received im vSmart ablehnt.

vSmart1(config-policy)# sh config 
policy
 lists
  tloc-list SITE20
   tloc 10.1.0.2 color blue encap ipsec
  !
 !
 control-policy SDWAN
  sequence 10
   match tloc
    tloc-list SITE20 
   !
   action reject ----> here we are rejecting the TLOC 10.1.0.2,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.

Anmerkung: Wenn ein TLOC Rejected oder Invalidist, wird er nicht an die anderen vEdges weitergegeben.

Stellen Sie sicher, dass eine Richtlinie den TLOC nicht filtert, wenn sie vom vSmart angekündigt wird. Sie können sehen, dass die TLOC vom vSmart empfangen wird, jedoch nicht vom anderen vEdge.

Beispiel 1: vSmart mit TLOC in 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     10.1.0.5         mpls             ipsec  10.1.0.5         C,I,R     1       10.20.67.10      12406   10.20.67.10      12406    ::      0       ::       0        -       
         10.1.0.5         gold             ipsec  10.1.0.5         C,I,R     1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        -       
         10.1.0.2         mpls             ipsec  10.1.0.2         C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        -       
         10.1.0.2         blue             ipsec  10.1.0.2         C,I,R     1       198.51.100.187   12426   10.19.146.2      12426    ::      0       ::       0        -       
         10.1.0.30         mpls             ipsec  10.1.0.30         C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        -       
         10.1.0.30         gold             ipsec  10.1.0.30         C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        -       
         10.1.0.4         mpls             ipsec  10.1.0.4         C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        -       
         10.1.0.4         gold             ipsec  10.1.0.4         C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        -

Beispiel 2: vEdge1 erkennt die TLOC nicht in der Farbe Blau, die von vEdge2 kommt. Es erkennt nur die 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     10.1.0.5         mpls             ipsec  0.0.0.0          C,Red,R   1       10.20.67.10      12406   10.20.67.10      12406    ::      0       ::       0        up      
         10.1.0.5         gold             ipsec  0.0.0.0          C,Red,R   1       203.0.113.225    4501    10.19.145.2      12386    ::      0       ::       0        up      
         10.1.0.2         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.20      12386   10.20.67.20      12386    ::      0       ::       0        up      
         10.1.0.30         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.30      12346   10.20.67.30      12346    ::      0       ::       0        up      
         10.1.0.30         gold             ipsec  10.1.0.3          C,I,R     1       192.0.2.129      12386   192.0.2.129      12386    ::      0       ::       0        up      
         10.1.0.4         mpls             ipsec  10.1.0.3          C,I,R     1       10.20.67.40      12426   10.20.67.40      12426    ::      0       ::       0        up      
         10.1.0.4         gold             ipsec  10.1.0.3          C,I,R     1       203.0.113.226    12386   203.0.113.226    12386    ::      0       ::       0        up

Wenn Sie die Richtlinie überprüfen, können Sie erkennen, warum der TLOC nicht auf dem vEdge1 angezeigt wird.

vSmart1# show running-config policy 
policy
 lists
  tloc-list SITE20
   tloc 10.1.0.2 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
 !
!

Bidirektionale Weiterleitungserkennung

Grundlegendes zum Befehl show bfd sessions

In der Ausgabe sollten Sie vor allem auf Folgendes achten:

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 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10.1.0.5         10       down        blue             gold             10.19.146.2                     203.0.113.225                   4501        ipsec  7           1000           NA              7           
10.1.0.30         30       up          blue             gold             10.19.146.2                     192.0.2.129                     12386       ipsec  7           1000           0:00:00:22      2           
10.1.0.4         40       up          blue             gold             10.19.146.2                     203.0.113.226                   12386       ipsec  7           1000           0:00:00:22      1       
10.1.0.4         40       up          mpls             mpls             10.20.67.10                     10.20.67.40                     12426       ipsec  7           1000           0:00:10:11      0

SYSTEM IP: Peers System-IP
SOURCE and REMOTE TLOC COLOR: Dies ist nützlich, um zu erfahren, was von TLOC erwartet wird.
SOURCE IP: Dabei handelt es sich um die private Quell-IP. Wenn Sie sich hinter einer NAT befinden, werden diese Informationen hier angezeigt (bei Verwendung von show control local-properties ).

DST PUBLIC IP: Dabei handelt es sich um das Ziel, das der vEdge zur Bildung des Data Plane Tunnels verwendet, unabhängig davon, ob sich dieser hinter NAT befindet oder nicht. (Beispiel: Direkt mit dem Internet verbundene vEdges oder Multi-Protocol Label Switching (MPLS) Links)

DST PUBLIC PORT Öffentlicher Port mit NAT, den der vEdge verwendet, um den Data Plane Tunnel zum Remote-vEdge zu bilden.

TRANSITIONS: Legt fest, wie oft der Status der BFD-Sitzung von NA auf UP und umgekehrt geändert wurde.

Befehl show tunnel statistics

Der show tunnel statistics kann Informationen zu den Tunneln der Datenebene anzeigen. Sie können bestimmen, ob Sie Pakete für einen bestimmten IPSEC-Tunnel zwischen den vEdges senden oder empfangen.

So können Sie ermitteln, ob Pakete an jedem Ende ankommen, und Verbindungsprobleme zwischen den Knoten isolieren.

Wenn Sie den Befehl im Beispiel mehrmals ausführen, können Sie in der tx-pkts oder rx-pktsfeststellen, dass ein Inkrement oder kein Inkrement vorliegt.

Tipp: Wenn Ihr Zähler für tx-pkts inkrementiert ist, übertragen Sie Daten an den Peer. Wenn Ihre rx-pkts nicht inkrementiert werden, bedeutet dies, dass keine Daten von Ihrem Peer empfangen werden. Überprüfen Sie in diesem Fall das andere Ende, und stellen Sie sicher, dass tx-pkts inkrementiert wird.

                                                                                                                                                       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  10.1.0.5     public-internet  default          1441    38282    5904968    38276    6440071    1361    
ipsec     172.16.16.147  10.152.201.104  12386   63364  10.1.0.0  public-internet  default          1441    33421    5158814    33416    5623178    1361    
ipsec     172.16.16.147  10.152.204.31   12386   58851  10.1.0.7     public-internet  public-internet  1441    12746    1975022    12744    2151926    1361    
ipsec     172.24.90.129  10.88.244.181   12426   12406  10.1.0.5     biz-internet     default          1441    38293    5906238    38288    6454580    1361    
ipsec     172.24.90.129  10.152.201.104  12426   63364  10.1.0.0  biz-internet     default          1441    33415    5157914    33404    5621168    1361    
ipsec     172.24.90.129  10.152.204.31   12426   58851  10.1.0.7     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  10.1.0.5     public-internet  default          1441    39028    6020779    39022    6566326    1361    
ipsec     172.16.16.147  10.152.201.104  12386   63364  10.1.0.0  public-internet  default          1441    34167    5274625    34162    5749433    1361    
ipsec     172.16.16.147  10.152.204.31   12386   58851  10.1.0.7     public-internet  public-internet  1441    13489    2089069    13487    2276382    1361    
ipsec     172.24.90.129  10.88.244.181   12426   12406  10.1.0.5     biz-internet     default          1441    39039    6022049    39034    6580835    1361    
ipsec     172.24.90.129  10.152.201.104  12426   63364  10.1.0.0  biz-internet     default          1441    34161    5273725    34149    5747259    1361    
ipsec     172.24.90.129  10.152.204.31   12426   58851  10.1.0.7     biz-internet     public-internet  1441    13493    2089669    13490    2276902    1361

Ein weiterer nützlicher Befehl dient show tunnel statistics bfd zur Überprüfung der Anzahl von BFD-Paketen, die innerhalb eines bestimmten Datenebenentunnels gesendet und empfangen werden:

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

Zugriffsliste

Eine Zugriffsliste ist ein nützlicher und notwendiger Schritt, nachdem Sie sich die show bfd sessions Ausgabe angesehen haben.

Nachdem Sie nun die privaten und öffentlichen IPs und Ports kennen, können Sie eine Access Control List (ACL) für SRC_PORT, DST_PORT, SRC_IP und DST_IP erstellen.

Dies kann dabei helfen, gesendete und empfangene BFD-Nachrichten zu verifizieren.

Ein Beispiel für eine ACL-Konfiguration finden Sie hier:

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

Im Beispiel verwendet diese ACL zwei Sequenzen. Die Sequenz 10 entspricht den BFD-Nachrichten, die von diesem vEdge an den Peer gesendet werden. Sequenz 20 bewirkt das Gegenteil.

Er gleicht mit dem Quell- (Private) und dem Ziel- (Public) Port ab. Wenn der vEdge NAT verwendet, überprüfen Sie die richtigen Quell- und Zielports.

Um die Treffer für jeden Sequenzzähler zu überprüfen, geben Sie den show policy access-list counters

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

Network Address Translation

So verwenden Sie die Tools Stun-Client zum Erkennen von NAT-Zuordnungen und -Filtern.

Wenn Sie alle Schritte durchgeführt haben und sich hinter NAT befinden, besteht der nächste Schritt darin, das UDP NAT Traversal (RFC 4787) Map and Filter Verhalten zu identifizieren.

Dieses Tool wird verwendet, um die lokale externe vEdge-IP-Adresse zu ermitteln, wenn sich der vEdge hinter einem NAT-Gerät befindet.

Dieser Befehl ruft eine Portzuordnung für das Gerät ab und erkennt optional Eigenschaften der NAT zwischen dem lokalen Gerät und einem Server (öffentlicher Server: B. Google Betäubungsserver).

Anmerkung: Weitere Informationen finden Sie unter:

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

Bei neueren Softwareversionen kann die Syntax etwas anders sein:

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

In diesem Beispiel führen Sie einen vollständigen NAT-Erkennungstest mit der Verwendung des UDP-Quell-Ports 12386 zum Google STUN-Server durch.

Die Ausgabe dieses Befehls gibt Ihnen das NAT-Verhalten und den NAT-Filtertyp basierend auf RFC 4787 an.

Anmerkung: Denken Sie daran, tools stunden STUN-Dienst in der Tunnelschnittstelle zuzulassen, da er sonst nicht funktioniert. Benutzen Sie allow-service stun um die Betäubungsdaten passieren zu lassen.

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

Dies zeigt die Zuordnung zwischen STUN-Terminologie (Full-Cone NAT) und RFC 4787 (NAT Behavioral for UDP).

Unterstützte NAT-Typen für das Senden von Datenebenen-Tunneln in CLI

In den meisten Fällen können Sie Ihre öffentlichen Farben wie biz-internet oder public-internet direkt mit dem Internet verbinden.

In anderen Fällen befindet sich hinter der vEdge-WAN-Schnittstelle und dem eigentlichen Internet Service Provider ein NAT-Gerät.

Auf diese Weise kann der vEdge über eine private IP-Adresse verfügen, und das andere Gerät (Router, Firewall usw.) kann das Gerät mit den der Öffentlichkeit zugewandten IP-Adressen sein.

Wenn Sie einen falschen NAT-Typ haben, kann dies einer der häufigsten Gründe sein, die die Bildung von Datenebenentunneln verbieten. Dies sind die unterstützten NAT-Typen.

Firewalls

Wenn Sie die NAT bereits aktiviert haben und nicht in den nicht unterstützten Quell- und Ziel-Typen enthalten sind, ist es möglich, dass eine Firewall die Ports blockiert, die zur Bildung der Data Plane Tunnel verwendet werden.

Stellen Sie sicher, dass diese Ports in der Firewall für Verbindungen auf Datenebene geöffnet sind: vEdge to vEdge Data Plane:

UDP 12346 bis 13156

Für Steuerverbindungen von vEdge zu Controllern:

UDP 12346 bis 13156

TCP 23456 bis 24156

Stellen Sie sicher, dass Sie diese Ports öffnen, um eine erfolgreiche Verbindung der Datenebenentunnel zu erreichen.

Wenn Sie die Quell- und Zielports für Datenebenentunnel überprüfen, können Sie verwenden show tunnel statistics oder show bfd sessions | tab , aber nicht show bfd sessions.

Es werden keine Quell-Ports angezeigt, sondern nur Ziel-Ports, wie Sie sehen können:

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

Anmerkung: Weitere Informationen zu den verwendeten SD-WAN-Firewall-Ports finden Sie hier.

Sicherheit

Wenn Sie feststellen, dass der ACL-Zähler den ein- und ausgehenden Datenverkehr erhöht, überprüfen Sie mehrere Iterationen. show system statistics diff and ensure there are no drops.

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

In dieser Ausgabe rx_replay_integrity_drops erhöhen Sie mit jeder Iteration des show system statistics diff command.

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

Führen Sie zunächst eine request security ipsec-rekey am vEdge durch. Dann, gehen Sie durch mehrere Iterationen von show system statistics diff und sehen Sie, ob Sie noch sehen rx_replay_integrity_drops.

Überprüfen Sie in diesem Fall Ihre Sicherheitskonfiguration.

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

ISP-Probleme mit DSCP-markiertem Datenverkehr

Standardmäßig wird der gesamte Steuerungs- und Verwaltungsdatenverkehr vom vEdge-Router zu den Controllern über DTLS- oder TLS-Verbindungen geleitet und mit einem DSCP-Wert von CS6 (48 Dezimalstellen) markiert.

Für den Datenverkehr über Tunnel an der Dateninfrastruktur verwenden vEdge-Router die IPsec- oder GRE-Kapselung, um Datenverkehr untereinander zu senden.

Zur Erkennung von Ausfällen auf Datenebene und zur Messung der Leistung senden Router regelmäßig BFD-Pakete.

Diese BFD-Pakete werden auch mit einem DSCP-Wert von CS6 (48 Dezimalstellen) markiert.

Aus Sicht des ISP wird diese Art von Datenverkehr auch als UDP-Datenverkehr mit dem DSCP-Wert CS6 betrachtet, da vEdge-Router und SD-WAN-Controller DSCP kopieren, das standardmäßig den äußeren IP-Header markiert.

So kann es aussehen, wenn tcpdump auf einem Transit-ISP-Router ausgeführt wird:

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

Wie hier zu sehen ist, werden alle Pakete mit dem TOS-Byte 0xc0 markiert, das auch als DS-Feld bezeichnet wird (das entspricht dezimal 192 oder 110 000 00 im Binärformat.

Die ersten 6 Bits hoher Ordnung entsprechen dem DSCP-Bitwert (48 dezimal oder CS6).

Die ersten 2 Pakete in der Ausgabe entsprechen einem Kontrollebenen-Tunnel und die 2 verbleibenden einem Datenebenen-Tunnelverkehr.

Basierend auf der Paketlänge und der TOS-Markierung kann mit großer Sicherheit der Schluss gezogen werden, dass es sich um BFD-Pakete (RX- und TX-Richtung) handelt. Diese Pakete werden ebenfalls mit CS6 markiert.

Einige Service Provider (insbesondere MPLS-L3-VPN-/MPLS-L2-VPN-Service Provider) unterhalten in manchen Fällen unterschiedliche SLAs und können eine andere Datenverkehrsklasse auf der Grundlage von DSCP-Markierungen anders handhaben.

Wenn Sie beispielsweise über einen Premium-Service zur Priorisierung des DSCP EF- und CS6-Sprach- und Signalisierungsdatenverkehrs verfügen.

Da der Prioritätsdatenverkehr fast immer geregelt wird, selbst wenn die gesamte Bandbreite eines Uplinks nicht überschritten wird, kann bei dieser Art von Datenverkehr ein Paketverlust auftreten, sodass auch BFD-Sitzungen flapping-fähig sind.

Es hat sich in einigen Fällen gezeigt, dass bei einem Ausfall der dedizierten Prioritätswarteschlange auf dem Service-Provider-Router keine Verluste für den normalen Datenverkehr auftreten (z. B. wenn Sie einen einfachen Ping-Befehl vom vEdge-Router ausführen).

Der Grund hierfür ist, dass dieser Datenverkehr mit dem DSCP-Standardwert 0 markiert ist, wie hier zu sehen ist (TOS-Byte):

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

Gleichzeitig ist aber auch das Flapping bei Ihren BFD-Sitzungen zu beobachten:

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

Und hier ist nping nützlich, um Fehler zu beheben:

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

BFD debuggen

Wenn eine eingehendere Untersuchung erforderlich ist, führen Sie das Debuggen von BFD auf dem vEdge-Router aus.

Der Forwarding Traffic Manager (FTM) ist für BFD-Vorgänge auf vEdge-Routern zuständig und benötigt daher debug ftm bfd.

Alle Debug-Ausgaben werden in einer /var/log/tmplog/vdebug Datei gespeichert. Wenn Sie diese Meldungen auf der Konsole speichern möchten (ähnlich wie beim Cisco IOS-terminal monitorVerhalten), können Sie sie verwenden monitor start /var/log/tmplog/vdebug.

Um die Protokollierung zu beenden, können Sie Folgendes verwenden monitor stop /var/log/tmplog/vdebug

Hier ist, wie die Ausgabe für BFD-Sitzung, die aufgrund der Zeitüberschreitung ausfällt (Remote-TLOC mit IP-Adresse 192.168.110.6 ist nicht mehr erreichbar):

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

Ein weiteres nützliches Debugging zum Aktivieren ist das Debuggen von Tunnel Traffic Manager (TTM) Ereignissen debug ttm events.

Aus der Perspektive des TTM sieht die BFD DOWN Veranstaltung wie folgt aus:

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

Verwenden von Packet-Trace zum Erfassen von BFD-Paketen (20.5 und höher)

Ein weiteres nützliches Tool, das in Version 20.5.1 und höher eingeführt wurde, ist die Paketverfolgung für vEdges.
Da für die BFD-Sitzung die gleichen Standard-Ports verwendet werden (in der Regel 12346), ist es am einfachsten, anhand der Peer-IP-Adresse zu filtern.

Beispiele:

vedge# 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 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10.4.4.1         101      up          default          default          192.168.16.29                   192.168.22.103                  12386       ipsec  7           1000           0:03:23:34      0           
10.4.4.2         102      up          default          default          192.168.16.29                   192.168.29.39                   12346       ipsec  7           1000           0:03:21:24      1

Die Paketverfolgung würde wie folgt konfiguriert:

vedge# debug packet-trace condition ingress-if ge0/0 vpn 0 source-ip 192.168.29.39
vedge# debug packet-trace condition start
vedge# debug packet-trace condition stop

Die Ergebnisse können mit den unten aufgeführten Befehlen zum Anzeigen angezeigt werden. Bei eingehenden Paketen gibt es ein 'isBFD'-Flag, das für BFD-Datenverkehr auf '1' (true) gesetzt ist.

vedge# show packet-trace statistics 
packet-trace statistics 0
 source-ip             192.168.29.39
 source-port           12346
 destination-ip        192.168.16.29
 destination-port      12346
 source-interface      ge0_0
 destination-interface loop0.1
 decision              FORWARD
 duration              25
packet-trace statistics 1
 source-ip             192.168.29.39
 source-port           12346
 destination-ip        192.168.16.29
 destination-port      12346
 source-interface      ge0_0
 destination-interface loop0.1
 decision              FORWARD
 duration              14
packet-trace statistics 2
 source-ip             192.168.29.39
 source-port           12346
 destination-ip        192.168.16.29
 destination-port      12346
 source-interface      ge0_0
 destination-interface loop0.1
 decision              FORWARD
 duration              14
 
vedge# show packet-trace detail 0  
==========================================================================================================================
Pkt-id           src_ip(ingress_if)            dest_ip(egress_if)           Duration           Decision           Protocol
==========================================================================================================================
0         192.168.29.39:12346 (ge0_0)    192.168.16.29:12346 (loop0.1)        25 us             FORWARD              17
INGRESS_PKT:
00 50 56 84 79 be 00 50 56 84 3c b5 08 00 45 c0 00 96 ab 40 40 00 3f 11 e0 c1 c0 a8 1d 27 c0 
a8 10 1d 30 3a 30 3a 00 82 00 00 a0 00 01 02 00 00 0e 3f 4b 65 07 bc 61 03 38 71 93 53 58 
88 d8 08 41 95 7c 1a ff 8b cc b4 d0 d8 61 44 40 67 cc 1a 01 fd 1f c4 45 95 ea 7e 15 c9 08 
2e b6 63 84 00 
EGRESS_PKT: 
a1 5e fe 11 00 00 00 00 00 00 00 00 00 00 04 00 0c 04 00 41 01 02 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 04 00 00 00 00 00 00 00 02 00 3a 30 3a 30 1d 10 a8 c0 00 00 00 00 00 00 
00 00 00 00 00 00 01 00 00 00 27 1d a8 c0 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 
a4 00 01 00 00 
Feature Data 
------------------------------------ 
TOUCH : fp_proc_packet  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_proc_packet2  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_ip_forward  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_ipsec_decrypt  
core_id: 2
DSCP: 48
------------------------------------ 
FP_TRACE_FEAT_IPSEC_DATA: 
src_ip : 192.168.29.39
src_port : 3784
dst_ip : 192.168.16.29
dst_port : 3784
isBFD : 1
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_send_pkt  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_hw_x86_pkt_free  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_proc_remote_bfd_  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : BFD_ECHO_REPLY  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_hw_x86_pkt_free  
core_id: 2
DSCP: 48

Ausgehende BFD-Pakete werden auf ähnliche Weise erfasst. Diese Ergebnisse identifizieren den spezifischen Typ, ob es sich um eine Echoanfrage oder eine Antwort handelt.

vedge# debug packet-trace condition vpn 0 destination-ip 192.168.29.39
vedge# debug packet-trace condition start
vedge# debug packet-trace condition stop

vedge# show packet-trace statistics 
packet-trace statistics 0
 source-ip             192.168.16.29
 source-port           3784
 destination-ip        192.168.29.39
 destination-port      3784
 source-interface      loop0.0
 destination-interface ge0_0
 decision              FORWARD
 duration              15
packet-trace statistics 1
 source-ip             192.168.16.29
 source-port           3784
 destination-ip        192.168.29.39
 destination-port      3784
 source-interface      loop0.0
 destination-interface ge0_0
 decision              FORWARD
 duration              66
packet-trace statistics 2
 source-ip             192.168.16.29
 source-port           3784
 destination-ip        192.168.29.39
 destination-port      3784
 source-interface      loop0.0
 destination-interface ge0_0
 decision              FORWARD
 duration              17

vedge# show packet-trace details 0 
==========================================================================================================================
Pkt-id           src_ip(ingress_if)            dest_ip(egress_if)           Duration           Decision           Protocol
==========================================================================================================================
0         192.168.16.29:3784 (loop0.0)   192.168.29.39:3784 (ge0_0)           15 us             FORWARD              17
INGRESS_PKT:
45 c0 00 4f 00 00 40 00 ff 11 cc 48 c0 a8 10 1d c0 a8 1d 27 0e c8 0e c8 00 3b 00 00 80 c0 07 
00 00 00 00 01 00 00 00 01 00 0f 42 40 00 0f 42 40 00 0f 42 40 01 00 0c 01 00 00 1d 3b b1 
c9 89 d7 03 00 0f c0 a8 10 1d 30 3a c0 a8 1d 27 30 3a a3 96 07 3b 47 1c 60 d1 d5 76 4c 72 
78 1f 9a 0d 00 
EGRESS_PKT: 
00 50 56 84 3c b5 00 50 56 84 79 be 08 00 45 c0 00 96 ab 40 40 00 3f 11 e0 c1 c0 a8 10 1d c0 
a8 1d 27 30 3a 30 3a 00 82 00 00 a0 00 01 01 00 00 5c 3d 88 9a c7 28 23 1b e6 18 ea fe 73 
1b b9 e3 79 bf d9 f4 72 41 96 c1 47 07 44 56 77 5a a2 fb 43 59 c1 97 59 47 62 21 77 d4 f4 
47 8b 30 b0 00 
Feature Data 
------------------------------------ 
TOUCH : fp_send_bfd_pkt  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : BFD_ECHO_REPLY  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_ipsec_loopback_f  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_send_pkt  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_ip_forward  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_send_ip_packet  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_send_pkt  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_hw_x86_pkt_free  
core_id: 2
DSCP: 48
vedge# show packet-trace details 1
==========================================================================================================================
Pkt-id           src_ip(ingress_if)            dest_ip(egress_if)           Duration           Decision           Protocol
==========================================================================================================================
1         192.168.16.29:3784 (loop0.0)   192.168.29.39:3784 (ge0_0)           66 us             FORWARD              17
INGRESS_PKT:
45 c0 00 56 00 00 40 00 ff 11 cc 41 c0 a8 10 1d c0 a8 1d 27 0e c8 0e c8 00 42 00 00 80 c0 07 
00 00 00 00 01 00 00 00 01 00 0f 42 40 00 0f 42 40 00 0f 42 40 01 00 0c 00 00 00 1d b8 35 
a8 09 88 03 00 0f c0 a8 10 1d 30 3a c0 a8 1d 27 30 3a 04 00 07 01 00 05 a6 38 ff 7e 06 1e 
da 23 19 d5 00 
EGRESS_PKT: 
00 50 56 84 3c b5 00 50 56 84 79 be 08 00 45 c0 00 9d ab 40 40 00 3f 11 e0 ba c0 a8 10 1d c0 
a8 1d 27 30 3a 30 3a 00 89 00 00 a0 00 01 01 00 00 5c 3e 2d 3b 9e 81 aa 10 26 54 7f 47 5c 
d8 81 4f 23 2e 3c 39 1e 94 b2 f4 fb a4 ba 98 54 73 99 8f 2e 95 d7 69 fb 91 41 96 93 03 5b 
a4 e4 e8 82 00 
Feature Data 
------------------------------------ 
TOUCH : fp_send_bfd_pkt  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : BFD_ECHO_REQUEST  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_ipsec_loopback_f  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_send_pkt  
core_id: 0
DSCP: 48
------------------------------------ 
TOUCH : fp_ip_forward  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_send_ip_packet  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_send_pkt  
core_id: 2
DSCP: 48
------------------------------------ 
TOUCH : fp_hw_x86_pkt_free  
core_id: 2
DSCP: 48