Pesquise defeitos a detecção bidirecional da transmissão e edições planas das conexões dos dados
Índice
Introdução
Este documento descreve os problemas de conexão planos dos dados que puderam elevarar no Roteadores do vEdge depois que você conecta com sucesso ao plano do controle mas não há ainda nenhuma Conectividade do plano dos dados entre locais.
Pré-requisitos
Requisitos
Cisco recomenda que você tem o conhecimento da solução definida software Cisco do Wide Area Network (SDWAN).
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
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.
Controle a informação plana
Verifique propriedades do Local do controle
A fim verificar o estado das relações do Wide Area Network (WAN) em um vEdge, use a WAN-relação-lista das local-propriedades do controle do comando show. Nesta saída, você pode ver o tipo do Network Address Translation (NAT) do RFC 4787. Quando o vEdge é atrás de um endereço do dispositivo NAT (Firewall, roteador, etc.), o público e o privado do IPv4, as portas públicas e privadas do User Datagram Protocol (UDP) da fonte estão usadas para construir os túneis do plano dos dados. Você pode igualmente encontrar o estado da interface de túnel, de cor e do 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
Note: Requires minimum two vbonds to learn the NAT type
PUBLIC PUBLIC PRIVATE PRIVATE PRIVATE MAX RESTRICT/ LAST SPI TIME NAT VM
INTERFACE IPv4 PORT IPv4 IPv6 PORT VS/VM COLOR STATE CNTRL CONTROL/ LR/LB CONNECTION REMAINING TYPE CON
STUN PRF
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ge0/0 203.0.113.225 4501 10.19.145.2 :: 12386 1/1 gold up 2 no/yes/no No/No 7:02:55:13 0:09:02:29 N 5
ge0/1 10.20.67.10 12426 10.20.67.10 :: 12426 0/0 mpls up 2 yes/yes/no No/No 0:00:00:01 0:11:40:16 N 5
Com estes dados, você pode identificar determinada informação sobre como os túneis dos dados devem ser construídos e que portas você deve esperar da perspectiva do Roteadores a fim se usar quando você forma os túneis dos dados.
Verifique conexões de controle
É importante assegurar-se de que a cor que não forma túneis planos dos dados tenha uma conexão de controle estabelecida com os controladores na folha de prova. Se não, o vEdge não envia a informação do localizador do transporte (TLOC) ao vSmart através do protocolo de gestão da folha de prova (OMP). Você pode assegurar-se de se esteja acima ou não com o uso de conexões de controle da mostra comande, e procura o estado conecta.
vEdge1# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME ID
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 1.1.1.3 3 1 203.0.113.13 12446 203.0.113.13 12446 gold up 7:03:18:31 0
vbond dtls - 0 0 203.0.113.12 12346 203.0.113.12 12346 mpls connect 0
vmanage dtls 1.1.1.1 1 0 203.0.113.14 12646 203.0.113.14 12646 gold up 7:03:18:31 0
Se a relação que não forma túneis dos dados tenta conectar, você pode resolvê-la conseguindo bem sucedido traz-acima das conexões de controle através dessa cor. Ou, você pode trabalhar em torno dela ajustando as MAX-controle-conexões 0 na interface selecionada sob a seção da interface de túnel.
vpn 0 interface ge0/1 ip address 10.20.67.10/24 tunnel-interface encapsulation ipsec color mpls restrict max-control-connections 0 no allow-service bgp allow-service dhcp allow-service dns allow-service icmp no allow-service sshd no allow-service netconf no allow-service ntp no allow-service ospf no allow-service stun ! no shutdown !
Protocolo de gestão da folha de prova
Verifique se os OMP TLOCs são anunciados dos vEdges
Porque você observou, na etapa precedente, OMP TLOCs não pode ser enviado porque a relação tenta formar conexões de controle através dessa cor e não pode alcançar os controladores. Assim, a verificação se a cor que os dados escavam um túnel não trabalha nem vem acima envia o TLOC para essa cor particular aos vSmarts. Use os tlocs do omp do comando show anunciados a fim verificar o TLOCs que são enviados aos pares OMP.
Exemplo: Mpls e ouro das cores. Nenhum TLOC é enviado ao vSmart para mpls da cor.
vEdge1# show omp tlocs advertised
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
ADDRESS PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ipv4 1.1.1.10 gold ipsec 0.0.0.0 C,Red,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 up
1.1.1.20 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 down
1.1.1.20 blue ipsec 1.1.1.3 C,I,R 1 198.51.100.187 12406 10.19.146.2 12406 :: 0 :: 0 up
1.1.1.30 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 down
1.1.1.30 gold ipsec 1.1.1.3 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 up
1.1.1.40 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 down
1.1.1.40 gold ipsec 1.1.1.3 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 up
Exemplo: Mpls e ouro das cores. 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 1.1.1.10 gold ipsec 1.1.1.3 C,I,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 up
1.1.1.20 mpls ipsec 0.0.0.0 C,Red,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 up
1.1.1.20 blue ipsec 0.0.0.0 C,Red,R 1 198.51.100.187 12406 10.19.146.2 12406 :: 0 :: 0 up
1.1.1.30 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 up
1.1.1.30 gold ipsec 1.1.1.3 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 up
1.1.1.40 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 up
1.1.1.40 gold ipsec 1.1.1.3 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 up
Verifique se o vSmart recebe e anuncia o TLOCs
Agora que você sabe que seu TLOCs está anunciado para fora ao vSmart, confirme que recebe TLOCs do par correto e o anuncia ao outro vEdge.
Exemplo: o vSmart recebe o TLOCs de 1.1.1.20 vEdge1.
vSmart1# show omp tlocs received
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
ADDRESS PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ipv4 1.1.1.10 gold ipsec 1.1.1.10 C,I,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 -
1.1.1.20 mpls ipsec 1.1.1.20 C,I,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 -
1.1.1.20 blue ipsec 1.1.1.20 C,I,R 1 198.51.100.187 12406 10.19.146.2 12406 :: 0 :: 0 -
1.1.1.30 mpls ipsec 1.1.1.30 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 -
1.1.1.30 gold ipsec 1.1.1.30 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 -
1.1.1.40 mpls ipsec 1.1.1.40 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 -
1.1.1.40 gold ipsec 1.1.1.40 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 -
Caso que você não o vê o TLOCs ou ver aqui nenhuns outros códigos, você pode verificar estes:
vSmart-vIPtela-MEX# show omp tlocs received
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
ADDRESS PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ipv4 1.1.1.10 gold ipsec 1.1.1.10 C,I,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 -
1.1.1.20 mpls ipsec 1.1.1.20 C,I,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 -
1.1.1.20 blue ipsec 1.1.1.20 Rej,R,Inv 1 198.51.100.187 12406 10.19.146.2 12406 :: 0 :: 0 -
1.1.1.30 mpls ipsec 1.1.1.30 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 -
1.1.1.30 gold ipsec 1.1.1.30 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 -
1.1.1.40 mpls ipsec 1.1.1.40 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 -
1.1.1.40 gold ipsec 1.1.1.40 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 -
Verifique se não há nenhuma política que obstrui o TLOCs.
mostre a controle-política da política da corrida - olhe para toda a tloc-lista que rejeitar seu TLOCs do anúncio ou a recepção no vSmart.
vSmart1(config-policy)# sh config
policy
lists
tloc-list SITE20
tloc 1.1.1.20 color blue encap ipsec
!
!
control-policy SDWAN
sequence 10
match tloc
tloc-list SITE20
!
action reject ----> here we are rejecting the TLOC 1.1.1.20,blue,ipsec
!
!
default-action accept
!
apply-policy
site-list SITE20
control-policy SDWAN in -----> the policy is applied to control traffic coming IN the vSmart, it will filter the tlocs before adding it to the OMP table.
Assegure-se de que uma política não filtre o TLOC quando for anunciada do vSmart. Você pode ver que o TLOC está recebido no vSmart, mas você não o verá no outro vEdge.
Exemplo 1: vSmart com o TLOC no C, I, R.
vSmart1# show omp tlocs
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
ADDRESS PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ipv4 1.1.1.10 mpls ipsec 1.1.1.10 C,I,R 1 10.20.67.10 12406 10.20.67.10 12406 :: 0 :: 0 -
1.1.1.10 gold ipsec 1.1.1.10 C,I,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 -
1.1.1.20 mpls ipsec 1.1.1.20 C,I,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 -
1.1.1.20 blue ipsec 1.1.1.20 C,I,R 1 198.51.100.187 12426 10.19.146.2 12426 :: 0 :: 0 -
1.1.1.30 mpls ipsec 1.1.1.30 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 -
1.1.1.30 gold ipsec 1.1.1.30 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 -
1.1.1.40 mpls ipsec 1.1.1.40 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 -
1.1.1.40 gold ipsec 1.1.1.40 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 -
Exemplo 2: vEdge1 não vê o TLOC do azul da cor que vem de vEdge2. Vê somente MPLS TLOC.
vEdge1# show omp tlocs
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
ADDRESS PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ipv4 1.1.1.10 mpls ipsec 0.0.0.0 C,Red,R 1 10.20.67.10 12406 10.20.67.10 12406 :: 0 :: 0 up
1.1.1.10 gold ipsec 0.0.0.0 C,Red,R 1 203.0.113.225 4501 10.19.145.2 12386 :: 0 :: 0 up
1.1.1.20 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.20 12386 10.20.67.20 12386 :: 0 :: 0 up
1.1.1.30 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.30 12346 10.20.67.30 12346 :: 0 :: 0 up
1.1.1.30 gold ipsec 1.1.1.3 C,I,R 1 192.0.2.129 12386 192.0.2.129 12386 :: 0 :: 0 up
1.1.1.40 mpls ipsec 1.1.1.3 C,I,R 1 10.20.67.40 12426 10.20.67.40 12426 :: 0 :: 0 up
1.1.1.40 gold ipsec 1.1.1.3 C,I,R 1 203.0.113.226 12386 203.0.113.226 12386 :: 0 :: 0 up
Quando você verifica a política, você pode ver porque o TLOC não aparece no vEdge1.
vSmart1# show running-config policy
policy
lists
tloc-list SITE20
tloc 1.1.1.20 color blue encap ipsec
!
site-list SITE10
site-id 10
!
!
control-policy SDWAN
sequence 10
match tloc
tloc-list SITE20
!
action reject
!
!
default-action accept
!
apply-policy
site-list SITE10
control-policy SDWAN out
!
!
Detecção bidirecional da transmissão
Compreenda o comando sessions do bfd da mostra
Estas são as coisas chaves a procurar 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
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.10 10 down blue gold 10.19.146.2 203.0.113.225 4501 ipsec 7 1000 NA 7
1.1.1.30 30 up blue gold 10.19.146.2 192.0.2.129 12386 ipsec 7 1000 0:00:00:22 2
1.1.1.40 40 up blue gold 10.19.146.2 203.0.113.226 12386 ipsec 7 1000 0:00:00:22 1
1.1.1.40 40 up mpls mpls 10.20.67.10 10.20.67.40 12426 ipsec 7 1000 0:00:10:11 0
- SISTEMA IP: Espreita o sistema-IP
- FONTE e COR REMOTA TLOC: Isto é útil saber que TLOC você está esperando receber e enviar.
- IP DE ORIGEM: É o IP privado da fonte. Se você é atrás de um NAT, esta informação não estará indicada aqui (se pode ver com o uso do <wan-interface-list> das local-propriedades do controle da mostra que é explicado no início do documento).
- IP DO PÚBLICO DST: É o destino que o vEdge se está usando para formar o túnel do plano dos dados, de qualquer maneira se é atrás do NAT ou não. (Exemplo: vEdges anexados diretamente ao Internet, ou links (MPLS) Multiprotocol Label Switching)
- PORTA PÚBLICA DST: Porta pública do NAT-ed que o vEdge usa a fim formar o túnel do plano dos dados ao vEdge remoto.
- TRANSIÇÕES: O número de vezes a sessão BFD mudou seu estado, do NA PARA LEVANTAR e vice-versa.
Estatísticas do túnel do comando show
As estatísticas do túnel da mostra enlatam o Exibir informação sobre os túneis do plano dos dados, você pode facilmente ver se você é de emissão ou de recepção pacotes para um túnel de IPsec particular entre os vEdges. Isto pode ajudá-lo a compreender se os pacotes o estão fazendo em cada extremidade, e isola problemas de conectividade entre os Nós.
No exemplo, quando você executa os tempos múltiplos do comando, você pode não observar um incremento ou nenhum incremento nos TX-pacotes ou nos RX-pacotes.
TCP vEdge2# show tunnel statistics
TUNNEL SOURCE DEST TUNNEL MSS PROTOCOL SOURCE IP DEST IP PORT PORT SYSTEM IP LOCAL COLOR REMOTE COLOR MTU tx-pkts tx-octets rx-pkts rx-octets ADJUST --------------------------------------------------------------------------------------------------------------------------------------------------------------- ipsec 172.16.16.147 10.88.244.181 12386 12406 1.1.1.10 public-internet default 1441 38282 5904968 38276 6440071 1361 ipsec 172.16.16.147 10.152.201.104 12386 63364 100.1.1.100 public-internet default 1441 33421 5158814 33416 5623178 1361 ipsec 172.16.16.147 10.152.204.31 12386 58851 1.1.1.90 public-internet public-internet 1441 12746 1975022 12744 2151926 1361 ipsec 172.24.90.129 10.88.244.181 12426 12406 1.1.1.10 biz-internet default 1441 38293 5906238 38288 6454580 1361 ipsec 172.24.90.129 10.152.201.104 12426 63364 100.1.1.100 biz-internet default 1441 33415 5157914 33404 5621168 1361 ipsec 172.24.90.129 10.152.204.31 12426 58851 1.1.1.90 biz-internet public-internet 1441 12750 1975622 12747 2152446 1361
TUNNEL SOURCE DEST TUNNEL MSS
PROTOCOL SOURCE IP DEST IP PORT PORT SYSTEM IP LOCAL COLOR REMOTE COLOR MTU tx-pkts tx-octets rx-pkts rx-octets ADJUST
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ipsec 172.16.16.147 10.88.244.181 12386 12406 1.1.1.10 public-internet default 1441 39028 6020779 39022 6566326 1361
ipsec 172.16.16.147 10.152.201.104 12386 63364 100.1.1.100 public-internet default 1441 34167 5274625 34162 5749433 1361
ipsec 172.16.16.147 10.152.204.31 12386 58851 1.1.1.90 public-internet public-internet 1441 13489 2089069 13487 2276382 1361
ipsec 172.24.90.129 10.88.244.181 12426 12406 1.1.1.10 biz-internet default 1441 39039 6022049 39034 6580835 1361
ipsec 172.24.90.129 10.152.201.104 12426 63364 100.1.1.100 biz-internet default 1441 34161 5273725 34149 5747259 1361
ipsec 172.24.90.129 10.152.204.31 12426 58851 1.1.1.90 biz-internet public-internet 1441 13493 2089669 13490 2276902 1361
Um outro comando útil é o bfd das estatísticas do túnel da mostra que pode ser usado para verificar o número de pacotes BFD enviados e recebidos dentro do túnel particular do plano dos dados:
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 acessos
Uma lista de acessos é uma útil e uma etapa necessária depois que você olha a saída das sessões do bfd da mostra. Agora que o privados, e o público IPs e as portas são sabidos, você pode criar um Access Control List (ACL) para combinar contra o SRC_PORT, DST_PORT, SRC_IP, DST_IP. Isto pode ajudá-lo a confirmar se você é de recepção e de emissão mensagens BFD ou não.
Aqui você pode encontrar um exemplo de uma configuração 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, este ACL usa duas sequências. A sequência 10 combina as mensagens BFD que são enviadas deste vEdge ao par. A sequência 20 faz o oposto.
Combina contra as portas (privadas) da porta e do destino da fonte (público). Se o vEdge usa o NAT, assegure para verificar as portas de origem e de destino direitas.
Para verificar as batidas em cada problema de contador da sequência a lista de acesso da política da mostra opõe o name> da <access-lista
vEdge1# show policy access-list-counters
NAME COUNTER NAME PACKETS BYTES
-----------------------------------------------------
checkbfd bfd-out-to-dc1-from-br1 10 2048
bfd-in-from-dc1-to-br1 0 0
Tradução de endereço de rede
Como usar o aturdir-cliente das ferramentas para detectar o mapeamento e a filtração NAT
Se você executou todas as etapas mencionadas e você é atrás do NAT, a próxima etapa é identificar o UDP NAT comportamento de traço e de filtração de Traversal (RFC 4787). Esta ferramenta é realmente útil descobrir o endereço IP externo local do vEdge quando esse vEdge é ficado situado atrás de um dispositivo NAT. Este comando obtém um mapeamento de porta para o dispositivo e descobre opcionalmente propriedades sobre o NAT entre o dispositivo local e um server (server público: o exemplo Google aturde o server).
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 umas versões de software mais novas, a sintaxe pode ser diferente mordido:
vEdge1# tools stun-client vpn 0 options "--mode full --localaddr 192.168.12.100 --localport 12386 --verbosity 2 stun.l.google.com 19302"
Neste exemplo, você executa um teste completo da detecção NAT com o uso da porta de origem 12386 UDP a Google ATURDE o server. A saída deste comando dar-lhe-á o comportamento do NAT e o tipo de filtração NAT baseado no RFC 4787.
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 ! !
Isto mostra que o mapeamento no meio ATURDE a terminologia (FULL-cone NAT) e o RFC 4787 (NAT comportável para o UDP).
Os tipos apoiados NAT para dados aplanam túneis
Na maioria dos casos, suas cores do público como o negócio-Internet ou o público-Internet podem diretamente ser anexados ao Internet. Em outros casos, está indo estar um dispositivo NAT atrás da interface WAN do vEdge e do provedor de serviço da Internet real, assim que o vEdge pode ter um IP privado e o outro dispositivo (roteador, Firewall, etc.) pode ser o dispositivo com os endereços IP de Um ou Mais Servidores Cisco ICM NT públicos do revestimento.
Se você tem um tipo incorreto NAT, a seguir poderia potencialmente ser um da maioria de motivos comuns que não permitem a formação de túneis do plano dos dados. Estes são os tipos apoiados NAT.
Firewall
Se você já verificou o NAT e seu não dentro os tipos unsupported da fonte e do destino, é possível que um Firewall está obstruindo as portas usadas para formar os túneis do plano dos dados.
Assegure-se de que estas portas estejam abertas no Firewall para conexões do plano dos dados: vEdge ao plano dos dados do vEdge:
UDP 12346 13156
Para conexões de controle do vEdge aos controladores:
UDP 12346 13156
TCP 23456 24156
Assegure-se de que você abra estas portas a fim conseguir a conexão bem sucedida dos túneis do plano dos dados.
Quando você verifica as portas de origem e de destino usadas para dados aplanam túneis, você pode usar estatísticas do túnel da mostra ou mostrar sessões do bfd | aba mas não sessões do bfd da mostra. Não mostrará nenhuma portas de origem, simplesmente portas do 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
Security
Se você vê seu que seu contador ACL é aumentar de entrada e de partida, verifique o diff de diversa estatística de sistema da mostra das iterações e assegure-se de que não haja nenhuma gota.
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, os rx_replay_integrity_drops aumentam com cada iteração do comando diff da estatística de sistema da mostra.
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
Primeiramente, execute uma Segurança do pedido IPsec-rekey no vEdge. Então, atravesse diversas iterações do diff da estatística de sistema da mostra e veja se você ainda vê rx_replay_integrity_drops. Se você faz, para verificar sua configuração de segurança.
vEdge1# show running-config security security
ipsec
authentication-type sha1-hmac ah-sha1-hmac
!
!
Se você tem a configuração mencionada, tente adicionar a AH-nenhum-identificação ao tipo do autenticação sob o IPsec.
vEdge1# show running-config security security
ipsec
authentication-type sha1-hmac ah-sha1-hmac ah-no-id
!
!
Problemas ISP com tráfego marcado DSCP
À revelia, todo o controle e tráfego de gerenciamento do roteador do vEdge aos cursos dos controladores sobre DTL ou conexões TLS e identificados por meio de um valor DSCP de CS6 (decimal 48). Para dados coloque túneis traficam, IPsec ou encapsulamento de GRE do uso do Roteadores do vEdge para enviar entre si o tráfego de dados. Para dados aplane a detecção de falha e a medida de desempenho, Roteadores envia-se periodicamente pacotes BFD. Estes pacotes BFD são identificados igualmente por meio de um valor DSCP de CS6 (decimal 48).
Da perspectiva do ISP, aquele o tipo de tráfego será considerado como o tráfego UDP com valor CS6 DSCP também porque o Roteadores do vEdge e os controladores SD-WAN copiam o DSCP esse marcas ao cabeçalho IP exterior à revelia.
É aqui como pôde olhar como se o tcpdump é executado no roteador ISP do 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 identificados por meio do byte de TOS 0xc0 igualmente conhecido como o campo DS (que é igual ao decimal 192, ou 110 000 00 no binário. Os primeiros bit de alta ordem 6 correspondem ao valor de bit 48 DSCP no decimal ou no CS6).
Os primeiros 2 pacotes na saída correspondem a um túnel do plano do controle e os 2 que permanecem, a uns dados aplanam o tráfego de túnel. Baseado no comprimento do pacote e na marcação TOS, pode concluir com confiança alta que era pacotes BFD (sentidos RX e TX). Estes pacotes são identificados por meio de CS6 também.
Algum cronometra alguns provedores de serviços e especialmente os provedores de serviços MPLS L3 VPN/MPLS L2VPN podem SLA
maintaindifferent com o cliente e podem segurar uma classe de tráfego diferente baseada no cliente DSCP que marca diferentemente. Por exemplo, você pôde ter o serviço superior para dar a prioridade à Voz EF e CS6 DSCP e ao tráfego de sinalização. Desde que o tráfego de prioridade é policiado quase sempre, mesmo se a largura de banda total de um uplink não é excedida, porque esta perda de pacotes do tipo de tráfego pode ser considerada e daqui as sessões BFD podem bater também.
Viu-se em alguns casos que se a fila de prioridade dedicada no roteador do provedor de serviços é morrida de fome, você não verá nenhuma gotas para o tráfego normal (por exemplo ping simples sendo executado do roteador do vEdge) porque tal tráfego é identificado por meio de valor 0 do padrão DSCP como pode ser visto aqui (byte de 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 BFD estarão batendo:
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 nping vem acessível a fim pesquisar defeitos:
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
Debugar o BFD
Certas vezes, se uma investigação mais profunda é exigida, você pôde querer executar a eliminação de erros do BFD no roteador do vEdge. O gerente do tráfego de encaminhamento (FTM) é responsável para operações BFD no Roteadores e daqui onde em você do vEdge a necessidade debuga o bfd do ftm. Todo o resultado do debug é armazenado no arquivo de /var/log/tmplog/vdebug e se você quer ter aquelas mensagens no console (similar ao comportamento do monitor do ®terminal do Cisco IOS), você pode usar o começo /var/log/tmplog/vdebug do monitor. A fim parar de registrar, você pode usar a parada /var/log/tmplog/vdebug do monitor. É aqui como a saída olhará como para a sessão BFD que vai para baixo devido ao intervalo (TLOC remoto com endereço IP 192.168.110.6 não é alcançável anymore):
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
Um outro artigo de valor debuga a fim permitir é o gerente do tráfego de túnel (TTM) que os eventos debugam são debugam eventos do ttm. É aqui como o evento BFD PARA BAIXO olha como 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
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)