O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve problemas de conexão do plano de dados do vEdge após uma conexão do plano de controle, mas não há conectividade do plano de dados entre os locais.
A Cisco recomenda o conhecimento da Cisco Software Defined Wide Area Network (SDWAN) solução.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas. Este documento se concentra nas plataformas vEdge.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Para roteadores Cisco Edge (roteadores Cisco IOS® XE no modo controlador) , leia .
Informações do plano de controle
Verificar Propriedades Locais de Controle
Para verificar o status das
Wide Area Network (WAN) interfaces em um vEdge, use o comando,
show control local-properties wan-interface-list.
Nesta saída, você pode ver o RFC 4787
Network Address Translation (NAT) Type.
Quando o vEdge está por trás de um dispositivo NAT (firewall, roteador, etc.), o endereço IPv4 público e privado, as
User Datagram Protocol (UDP) portas de origem pública e privada são usadas para criar os túneis do plano de dados.
Você também pode encontrar o estado da interface do túnel, a cor e o número máximo de conexões de controle 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 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
Com esses dados, você pode identificar certas informações sobre como os túneis de dados devem ser criados e quais portas você pode esperar (da perspectiva dos roteadores) usar ao formar os túneis de dados.
Verificar Conexões de Controle
É importante garantir que a cor que não forma os túneis de plano de dados tenha uma conexão de controle estabelecida com os controladores na sobreposição.
Caso contrário, o vEdge não enviará as
Transport Locator (TLOC) informações para o vSmart via
Overlay Management Protocol (OMP).
Você pode verificar se ele está operacional com o uso do
show control connections comando e procurar o
connect estado.
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
Se a interface (que não forma túneis de dados) tentar se conectar, resolva-a com uma inicialização bem-sucedida das conexões de controle através dessa cor.
Ou defina o
max-control-connections 0 na interface selecionada na seção tunnel interface.
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 !
Observação: às vezes, você pode usar o
no control-connections comando para atingir o mesmo objetivo. No entanto, esse comando não estabelece um número máximo de conexões de controle. Este comando foi preterido da versão 15.4 e não é usado em software mais recente.
Protocolo de gerenciamento de sobreposição
Verifique se os TLOCs de OMP são anunciados a partir das bordas
TLOCs OMP não podem ser enviados porque a interface tenta formar conexões de controle através dessa cor e não consegue alcançar os controladores.
Verifique se a cor (que os túneis de dados) envia o TLOC dessa cor específica para o vSmarts.
Use o comando
show omp tlocs advertised para verificar os TLOCs que são enviados aos peers OMP.
Exemplo: Cores
mpls e
gold. Nenhum TLOC é enviado para o vSmart para mpls coloridos.
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
Exemplo: Cores
mpls e
gold. TLOC é enviado para ambas as cores.
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
Observação: para qualquer informação de plano de controle gerada localmente, o campo "
FROM PEER" é definido como 0.0.0.0. Ao procurar informações originadas localmente, certifique-se de fazer a correspondência com base nesse valor.
Verificar se o vSmart recebe e anuncia os TLOCs
Os TLOCs agora são anunciados para o vSmart. Confirme se ele recebe TLOCs do peer correto e os anuncia para o outro vEdge.
Exemplo: a vSmart recebe os TLOCs de 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 -
Se você não vir os TLOCs ou vir qualquer outro código aqui, verifique:
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 -
Verifique se não há nenhuma política que bloqueie os TLOCs.
show run policy control-policy - procure qualquer lista de tópicos que rejeite seus TLOCs como
advertised ou
received no vSmart.
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.
Observação: se um TLOC for
Rejected ou
Invalid, ele não será anunciado para as outras Bordas.
Certifique-se de que uma política não filtre o TLOC quando ele for anunciado no vSmart. Você pode ver que o TLOC é recebido no vSmart, mas você não o vê no outro vEdge.
Exemplo 1: vSmart com TLOC em 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 -
Exemplo 2: vEdge1 não vê o TLOC da cor azul que vem do vEdge2. Ele vê apenas 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
Ao verificar a política, você pode ver por que o TLOC não aparece no vEdge1.
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
!
!
Detecção de encaminhamento bidirecional
Entender o comando show bfd sessions
Estas são as principais coisas a serem procuradas na saída:
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: System-ip de mesmo nível
SOURCE and REMOTE TLOC COLOR: Isso é útil para saber qual TLOC deve receber e enviar.
SOURCE IP: É o IP de private origem. Se você estiver por trás de um NAT, essas informações serão exibidas aqui (elas podem ser vistas com o uso de show control local-properties <wan-interface-list).
DST PUBLIC IP: é o destino que o vEdge usa para formar o Data Plane túnel, estando ou não atrás do NAT. (Exemplo: Vedes diretamente conectadas à Internet ou Multi-Protocol Label Switching (MPLS) links)
DST PUBLIC PORT Porta NAT pública que o vEdge usa para formar o Data Plane túnel para o vEdge remoto.
TRANSITIONS: número de vezes que a sessão BFD alterou seu status, de NA para UP e vice-versa.
Comando show tunnel statistics
O
show tunnel statistics pode exibir informações sobre os túneis do plano de dados. Você pode determinar se envia ou recebe pacotes para um túnel IPSEC específico entre as Bordas.
Isso pode ajudá-lo a entender se os pacotes chegam em cada extremidade e a isolar problemas de conectividade entre os nós.
No exemplo, ao executar o comando várias vezes, você pode observar um incremento ou nenhum incremento no
tx-pkts ou
rx-pkts.
Dica: se seu contador para incremento de tx-pkts, você transmitirá dados para o peer. Se seus rx-pkts não incrementam, isso significa que os dados não são recebidos de seu peer. Nesse caso, verifique a outra extremidade e confirme se os tx-pkts são incrementados.
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
Outro comando útil é
show tunnel statistics bfd que pode ser usado para verificar o número de pacotes BFD enviados e recebidos dentro de um túnel de plano de dados específico:
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 acesso
Uma lista de acesso é uma etapa útil e necessária depois de examinar a
show bfd sessions saída.
Agora que os IPs e as portas privados e públicos são conhecidos, você pode criar um
Access Control List (ACL) para corresponder ao SRC_PORT, DST_PORT, SRC_IP, DST_IP.
Isso pode ajudar a verificar mensagens BFD enviadas e recebidas.
Aqui, você pode encontrar um exemplo de uma configuração 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
!
!
!
No exemplo, essa ACL usa duas sequências. A sequência 10 corresponde às mensagens BFD que são enviadas desse vEdge para o peer. A sequência 20 faz o oposto.
Ele compara com as portas origem (
Private) e destino (
Public). Se o vEdge usar NAT, verifique as portas de origem e destino corretas.
Para verificar os acertos em cada problema do contador de sequência, o
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
Tradução de Endereço de Rede
Como usar ferramentas stun-client para detectar mapas e filtros NAT.
Se você tiver executado todas as etapas e estiver por trás do NAT, a próxima etapa será identificar o
UDP NAT Traversal (RFC 4787) Map and Filter comportamento.
Essa ferramenta é usada para descobrir o endereço IP externo do vEdge quando esse vEdge está localizado atrás de um dispositivo NAT.
Esse comando obtém um mapeamento de porta para o dispositivo e, opcionalmente, descobre propriedades sobre o NAT entre o dispositivo local e um servidor (servidor público: exemplo, servidor stun do google).
Observação: para obter informações mais detalhadas, visite: Docs Viptela - STUN Client
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
Em versões mais recentes do software, a sintaxe pode ser um pouco diferente:
vEdge1# tools stun-client vpn 0 options "--mode full --localaddr 192.168.12.100 --localport 12386 --verbosity 2 stun.l.google.com 19302"
Neste exemplo, você executa um teste de detecção de NAT completo com o uso da porta de origem UDP 12386 ao servidor Google STUN.
A saída desse comando fornece o comportamento de NAT e o tipo de filtro de NAT com base no RFC 4787.
Observação: ao usar o
tools stun, lembre-se de permitir o serviço STUN na interface do túnel, caso contrário ele não funcionará. Use
allow-service stun para permitir a passagem dos dados 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 ! !
Isso mostra o mapeamento entre a terminologia STUN (NAT de Cone Completo) e RFC 4787 (Comportamento de NAT para UDP).
Tipos de NAT suportados para túneis de plano de dados "Envio" usados na CLI
Na maioria dos casos, suas cores públicas, como biz-internet ou internet pública, podem ser conectadas diretamente à Internet.
Em outros casos, há um dispositivo NAT por trás da interface WAN vEdge e do provedor de serviços de Internet real.
Dessa forma, o vEdge pode ter um IP privado e o outro dispositivo (roteador, firewall, etc.) pode ser o dispositivo com os endereços IP públicos voltados para o cliente.
Se você tiver um tipo de NAT incorreto, ele pode ser um dos motivos mais comuns que não permitem a formação de túneis de plano de dados. Esses são os tipos de NAT suportados.
Firewalls
Se você já verificou o NAT e ele não está nos tipos Source e Destination não suportados, é possível que um Firewall bloqueie as portas usadas para formar os
Data Plane túneis.
Verifique se essas portas estão abertas no Firewall para conexões de plano de dados:
vEdge to vEdge Data Plane:
12346 UDP para 13156
Para conexões de controle do vEdge para controladores:
12346 UDP para 13156
23456 TCP para 24156
Certifique-se de abrir essas portas para obter uma conexão bem-sucedida dos túneis do plano de dados.
Ao verificar as portas origem e destino usadas para túneis de plano de dados, você pode usar
show tunnel statistics ou
show bfd sessions | tab mas não
show bfd sessions.
Ele não mostra nenhuma porta de origem, apenas portas de destino como você pode 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
Observação: mais informações sobre as portas de firewall SD-WAN usadas podem ser encontradas aqui.
Security
Se você observar que o contador de ACL aumenta a entrada e a saída, verifique várias iterações
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
Nesta saída,
rx_replay_integrity_drops aumente a cada iteração do
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
Primeiro, execute um
request security ipsec-rekey comando no vEdge. Em seguida, examine várias iterações de
show system statistics diff e veja se ainda consegue ver
rx_replay_integrity_drops.
Se você fizer isso, verifique a configuração de segurança.
vEdge1# show running-config security security
ipsec
authentication-type sha1-hmac ah-sha1-hmac
!
!
Problemas do ISP com tráfego marcado de DSCP
Por padrão, todo o tráfego de controle e gerenciamento do roteador vEdge para os controladores trafega por conexões DTLS ou TLS e é marcado com um valor de DSCP de CS6 (48 decimal).
Para tráfego de túneis de local de dados, os roteadores vEdge usam o encapsulamento IPsec ou GRE para enviar tráfego de dados entre si.
Para a detecção de falhas do plano de dados e medição de desempenho, os roteadores enviam periodicamente uns aos outros pacotes BFD.
Esses pacotes BFD também são marcados com um valor de DSCP de CS6 (48 decimais).
Da perspectiva do ISP, esse tipo de tráfego é visto como tráfego UDP com o valor de DSCP CS6 também porque os roteadores vEdge e os controladores SD-WAN copiam o DSCP que marca para o cabeçalho IP externo por padrão.
Veja como ele pode ficar se o tcpdump for executado no roteador 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 pode ser visto aqui, todos os pacotes são marcados com o byte TOS 0xc0 também conhecido como campo DS (que é igual ao decimal 192, ou 110 000 00 em binário.
Os primeiros 6 bits de ordem alta correspondem ao valor de bits de DSCP (48 em decimal ou CS6).
Os primeiros 2 pacotes na saída correspondem a um túnel de plano de controle e os 2 restantes a um tráfego de túnel de plano de dados.
Com base no comprimento do pacote e na marca TOS, pode concluir com alta confiança que foram pacotes BFD (direções RX e TX). Esses pacotes também são marcados com CS6.
Às vezes, alguns provedores de serviços (especialmente os provedores de serviços VPN MPLS L3/VPN MPLS L2) mantêm um SLA diferente e podem lidar com uma classe diferente de tráfego com base nas marcas de DSCP de forma diferente.
Por exemplo, se você tiver um serviço premium para priorizar o tráfego de voz e sinalização DSCP EF e CS6.
Como o tráfego de prioridade é quase sempre policiado, mesmo que a largura de banda total de um uplink não seja excedida, para esse tipo de perda de pacote de tráfego pode ser visto e, portanto, as sessões BFD também podem estar oscilando.
Em alguns casos, observou-se que se a fila de prioridade dedicada no roteador do provedor de serviços estiver esgotada, você não verá nenhum descarte para o tráfego normal (por exemplo, quando você executa um ping simples do roteador vEdge).
Isso ocorre porque esse tráfego é marcado com o valor de DSCP padrão 0, como pode ser visto aqui (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
Mas, ao mesmo tempo, suas sessões de BFD não sincronizam:
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
E aqui o nping é útil para solucionar 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
Depurar BFD
Se uma investigação mais profunda for necessária, execute a depuração do BFD no roteador vEdge.
O FTM (Forwarding Traffic Manager) é responsável pelas operações de BFD em roteadores vEdge e, portanto, você precisa
debug ftm bfdde.
Todas as saídas de depuração são armazenadas no
/var/log/tmplog/vdebug arquivo e, se você quiser ter essas mensagens no console (semelhante ao
terminal monitor comportamento do Cisco IOS), poderá usar
monitor start /var/log/tmplog/vdebug.
Para interromper o registro, você pode usar
monitor stop /var/log/tmplog/vdebug
Veja como a saída procura a sessão BFD que fica inativa devido ao tempo limite (TLOC remoto com endereço IP 192.168.110.6 não pode mais ser acessado):
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
Outra depuração valiosa para habilitar é a depuração de
Tunnel Traffic Manager (TTM) eventos
debug ttm events.
Veja como o
BFD DOWN evento se parece da perspectiva do 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
Usar o Packet Trace para Capturar Pacotes BFD (20.5 e posterior)
Outra ferramenta útil introduzida no 20.5.1 e posterior é o packet-trace para vEdges.
Como a sessão BFD usa as mesmas portas padrão, geralmente 12346, é mais simples filtrar com base no endereço IP do peer.
Por exemplo:
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
O packet-trace seria configurado:
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
Os resultados podem ser exibidos usando os comandos show mostrados abaixo. Para pacotes de entrada, há uma flag 'isBFD' que é definida como '1' (verdadeiro) para o tráfego BFD.
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
Os pacotes BFD de saída são capturados de maneira semelhante. Esses resultados identificam o tipo específico, seja uma solicitação ou resposta de eco.
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
Informações Relacionadas
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
28-Sep-2022 |
Versão inicial |
1.0 |
13-Jun-2019 |
Versão inicial |