Identificar e solucionar problemas de encaminhamento entre estruturas da ACI - encaminhamento de camada 2
Contents
Introduction
Este documento descreve as etapas para entender e solucionar problemas de encaminhamento de camada 2 na ACI
Informações de Apoio
O material deste documento foi extraído do Solução de problemas da Cisco Application Centric Infrastructure, segunda edição livro, especificamente o Encaminhamento dentro da estrutura - encaminhamento L2: dois pontos finais no mesmo BD - sem roteamento unicast capítulo.
Overview
Esta seção explica um exemplo de Troubleshooting em que os pontos finais no mesmo domínio de bridge e na mesma sub-rede não podem se comunicar. A figura abaixo ilustra a topologia em que o BD não tem nenhuma sub-rede e tem o roteamento unicast desabilitado.
Normalmente, ao solucionar problemas de fluxos de tráfego com conectividade de endpoint, a sugestão é começar a identificar um par de endpoints. Consulte a topologia abaixo com os EPs A e B. Eles terão, respectivamente, os endereços IP 10.1.1.1/24 e 10.1.1.2/24. Os endereços MAC serão, respectivamente, 00:00:10:01:01:01 e 00:00:10:01:01:02.
Topologia
Nesta seção, há três cenários:
- Fluxo unicast de camada 2 conhecido.
- Fluxo unicast de Camada 2 desconhecido com BD no modo de inundação.
- Fluxo unicast de Camada 2 desconhecido com BD no modo proxy de hardware.
Os fluxos de Troubleshooting que serão seguidos podem ser resumidos pelo seguinte esquema:
- Verificação de nível 1: Validação GUI da configuração, falhas e endpoints aprendidos.
- Verificação de nível 2: CLI nos switches leaf:
- Verifique se os switches leaf de origem e destino aprendem os pontos finais.
- Verifique se os nós spine aprendem o ponto final no COOP.
- Verificação de nível 3: Captura do pacote:
- O ELAM (ELAM Assistant ou CLI) para validar o quadro está lá.
- Triagem para rastrear o fluxo.
verificação de GUI
O primeiro nível de solução de problemas é validar pela GUI que o MAC do endpoint foi aprendido corretamente. Isso pode ser feito na guia operacional do EPG onde o endpoint está localizado.
'Guia EPG Operacional > Pontos de extremidade do cliente'
Neste cenário, os endpoints A e B são mostrados na GUI. A GUI mostra seus endereços MAC, a interface na qual eles estão conectados à estrutura e o encapsulamento — nesse caso, ambos estão na VLAN 2501 de encapsulamento.
Espera-se que o endereço IP não seja aprendido da estrutura da ACI, pois o roteamento unicast foi desabilitado no nível BD.
Consulte a coluna fonte de aprendizagem na captura de tela acima. Se ele denota "aprendido", o switch leaf da ACI recebeu pelo menos um pacote do endpoint.
Como nesse caso os endpoints são aprendidos da estrutura da ACI, vá para o próximo caso de solução de problemas para o tráfego unicast da camada 2 conhecido.
Troubleshooting de fluxo de trabalho para tráfego unicast de Camada 2 conhecido
Aprendizado MAC EP de origem de folha de entrada
No caso de encaminhamento de Camada 2 no mesmo BD, a ACI só aprenderá o MAC origem e o encaminhamento com base no MAC destino. Os endereços MAC são aprendidos no escopo do BD.
Primeiro, verifique se o endpoint foi aprendido:
leaf1# show endpoint mac 0000.1001.0101
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
4/Prod:VRF1 vlan-2501 0000.1001.0101 L eth1/3
A saída acima fornece as seguintes informações:
- O endereço MAC 0000.1001.0101 é aprendido localmente (a flag é L para local) na porta ethernet 1/3 com encapsulamento vlan-2501 em vrf Prod:VRF1.
- Consulte a coluna 'VLAN/Domínio' na saída acima. A ID da VLAN listada lá é a VLAN interna.
Pesquisa de ponto de extremidade MAC de destino de folha de entrada
Suponha que o MAC destino seja conhecido (unicast conhecido).
leaf1# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
7/Prod:VRF1 vxlan-16351141 0000.1001.0102 tunnel4
A saída acima fornece as seguintes informações:
- O endereço MAC 0000.1001.0102 não é aprendido localmente.
- É aprendido da interface tunnel 4.
- É aprendido no encapsulamento VXLAN-16351141 que corresponde ao BD_VNID (ID de rede VXLAN) do domínio de bridge.
Em seguida, verifique o destino da interface túnel usando o comando 'show interface tunnel <x>'
leaf1# show interface tunnel 4
Tunnel4 is up
MTU 9000 bytes, BW 0 Kbit
Transport protocol is in VRF "overlay-1"
Tunnel protocol/transport is ivxlan
Tunnel source 10.0.88.95/32 (lo0)
Tunnel destination 10.0.96.66
Last clearing of "show interface" counters never
Tx
0 packets output, 1 minute output rate 0 packets/sec
Rx
0 packets input, 1 minute input rate 0 packets/sec
Assim, o pacote será encapsulado em VXLAN com o IP de origem TEP 10.0.88.95 (atribuído a loopback0) e enviado para o IP de destino TEP 10.0.96.66.
Confirme o IP de origem:
leaf1# show ip interface loopback 0 vrf overlay-1
IP Interface Status for VRF "overlay-1"
lo0, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: ptep
IP address: 10.0.88.95, IP subnet: 10.0.88.95/32
IP broadcast address: 255.255.255.255
IP primary address route-preference: 0, tag: 0
O destino TEP IP 10.0.96.66 pode ser um dos seguintes:
- Endereço PTEP de outra folha (pode ser verificado usando acidiag fnvread)
- VPC VIP (pode ser visto em 'GUI > Fabric > Access Policies > Policies > Switch > Virtual Port Channel default' (veja a captura de tela abaixo)
- Algum IP de loopback em um switch spine. Use o comando 'show ip interface vrf overlay-1' no switch spine para verificar isso.
Grupos de Proteção VPC Explícitos
Switch leaf de entrada enviando para switch spine
A folha de ingresso agora encapsulará o quadro na VXLAN com o IP de destino externo definido como 10.0.96.66, que é o IP de destino do túnel listado no comando anterior 'show interface tunnel 4'. Ele o encapsulará em VXLAN com o VNID do domínio de bridge - vxlan-16351141 - como mostrado na saída anterior do comando 'show endpoint mac 0000.1001.0102'.
Com base na rota IS-IS na sobreposição VRF-1, determine para onde enviá-la:
leaf1# show ip route 10.0.96.66 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.96.66/32, ubest/mbest: 4/0
*via 10.0.88.65, Eth1/49.10, [115/3], 2w5d, isis-isis_infra, isis-l1-int
*via 10.0.88.94, Eth1/50.128, [115/3], 2w5d, isis-isis_infra, isis-l1-int
Portanto, há roteamento ECMP (multipath de custo igual) para o destino usando eth1/49 e 1/50, que são os uplinks de estrutura para os switches spine.
Encaminhamento spine
A tabela de roteamento overlay-1 do VRF na coluna mostra que a rota de host 10.0.96.66 pode ser alcançada através da folha3 ou da folha4. Isso é esperado porque 10.0.96.66 é o VPC VIP dos switches de folha 103 e 104:
spine1# show ip route 10.0.96.66 vrf overlay-1
IP Route Table for VRF "overlay-1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.0.96.66/32, ubest/mbest: 2/0
*via 10.0.88.91, eth1/3.35, [115/2], 02w05d, isis-isis_infra, isis-l1-int
*via 10.0.88.90, eth1/4.39, [115/2], 02w05d, isis-isis_infra, isis-l1-int
spine1# show lldp neighbors | egrep "1\/3 |1\/4 "
leaf3 Eth1/3 120 BR Eth1/49
leaf4 Eth1/4 120 BR Eth1/49
Aprendizado MAC EP remoto de folha de saída
Nesse caso, o TEP de destino é um par VPC, de modo que o pacote chegará em leaf3 ou leaf4. Consulte as saídas do comando abaixo. Leaf4 deve mostrar saída semelhante. Como fazem parte do mesmo par de VPCs, todos os endpoints são sincronizados entre os dois switches leaf.
O aprendizado de endpoint para tráfego de Camada 2 na folha de saída é baseado no endereço MAC origem que é aprendido no BD correspondente ao VNID no pacote recebido. Isso pode ser verificado na tabela de endpoint.
O endereço MAC origem está atrás do túnel 26 no VXLAN-16351141.
O túnel 26 vai para o IP TEP 10.0.88.95 que é leaf1:
leaf3# show endpoint mac 0000.1001.0101
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
136/Prod:VRF1 vxlan-16351141 0000.1001.0101 tunnel26
leaf3# show interface tunnel 26
Tunnel26 is up
MTU 9000 bytes, BW 0 Kbit
Transport protocol is in VRF "overlay-1"
Tunnel protocol/transport is ivxlan
Tunnel source 10.0.88.91/32 (lo0)
Tunnel destination 10.0.88.95
Last clearing of "show interface" counters never
Tx
0 packets output, 1 minute output rate 0 packets/sec
Rx
0 packets input, 1 minute input rate 0 packets/sec
leaf3# acidiag fnvread | egrep "10.0.88.95"
101 1 leaf1 FDO20160TPA 10.0.88.95/32 leaf active 0
Pesquisa MAC de destino de folha de saída
O comando 'show endpoint' confirma que o MAC de destino é aprendido por trás do canal de porta 1 e usa o encapsulamento VLAN-2501
leaf3# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
135/Prod:VRF1 vlan-2501 0000.1001.0102 LpV po1
Isso indica que o quadro está deixando a estrutura da ACI no canal de porta 1 da interface leaf3 com a ID de VLAN de encapsulamento 2501. Você pode encontrar o BD VNID na guia Tenant Operational na GUI.
Valide se os dois endpoints foram aprendidos corretamente no repositório COOP EP do switch spine
O repositório COOP EP deve ser sincronizado em todos os nós spine. o repositório COOP EP pode ser verificado usando o BD VNID como uma chave e inserindo o endereço MAC EP.
O endereço MAC origem desse fluxo é aprendido do próximo salto do túnel 10.0.88.95, que é o IP TEP do leaf1. Além disso, a saída do comando mostra 16351141 VNID que corresponde ao domínio de bridge correto.
spine1# show coop internal info repo ep key 16351141 00:00:10:01:01:01
Repo Hdr Checksum : 24197
Repo Hdr record timestamp : 10 01 2019 10:16:50 278195866
Repo Hdr last pub timestamp : 10 01 2019 10:16:50 283699467
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:01
flags : 0x80
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 10:16:50 278195866
Tunnel nh : 10.0.88.95
MAC Tunnel : 10.0.88.95
IPv4 Tunnel : 10.0.88.95
IPv6 Tunnel : 10.0.88.95
ETEP Tunnel : 0.0.0.0
O MAC destino desse fluxo é aprendido no VPC VIP 10.0.96.66 da folha3 e da folha4. O 16351141 VNID EP BD também é listado, o que corresponde ao BD correto.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Repo Hdr Checksum : 16897
Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334
Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:02
flags : 0x90
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 11:05:46 351360334
Tunnel nh : 10.0.96.66
MAC Tunnel : 10.0.96.66
IPv4 Tunnel : 10.0.96.66
IPv6 Tunnel : 10.0.96.66
ETEP Tunnel : 0.0.0.0
Saída do ELAM usando o Assistente do ELAM
O ELAM Assistant é um poderoso aplicativo da ACI que pode simplificar a execução de capturas do ELAM em uma estrutura da ACI.
Os acionadores do Assistente do ELAM podem ser iniciados simultaneamente em vários nós de folha. Como resultado, pacotes específicos podem ser verificados em paralelo em leaf1, leaf3 e leaf4.
A captura ELAM configurada será exibida conforme mostrado abaixo. Como observado, o pacote é visto em leaf1 (nó-101) e leaf3 (nó-103).
Assistente do ELAM — parâmetros
O relatório do leaf1 (nó-101) mostra o seguinte:
- A saída Captured Packet Information confirma que o pacote entra em eth1/3 e tem as informações MAC e IP corretas.
- As informações de encaminhamento de pacotes mostram que ele é encaminhado em eth1/49 para TEP IP 10.0.96.66.
Assistente do ELAM — leaf1 (nó-101) — Informações do pacote capturado
Assistente ELAM — leaf1 (nó-101) — Informações de encaminhamento de pacotes
Na folha 3 (nó 103) na folha de saída, observa-se o seguinte:
Nas Informações do Pacote Capturado em leaf3, ele entra a partir de eth1/49. O endereço IP externo confirma o seguinte:
- TEP de origem: 10.0.88.95
- TEP de destino: 10.0.96.66
- VNID: 16351141 (BD VNID)
ELAM Assistant — leaf3 (nó-103) — informações do pacote capturado
As informações de encaminhamento de pacotes mostram que o tráfego é encaminhado no canal de porta 1 e especificamente na ethernet 1/12.
ELAM de folha de entrada usando CLI
É recomendável usar o ELAM Assistant, pois ele simplifica a operação de execução de capturas do ELAM. No entanto, também é possível usar comandos CLI em switches ACI para gerar um relatório ELAM. Veja a seguir um exemplo de como isso seria feito.
Use a sequência de gatilho mostrada para capturar o pacote na folha de entrada. Consulte a seção "Ferramentas" para obter mais informações sobre as opções do ELAM.
- Neste exemplo, o ASIC é 'tah' como folha (número de peça que termina com '-EX').
- 'in-select 6' é usado para capturar um pacote vindo de uma porta de downlink sem um encapsulamento de VXLAN.
- 'out-select 1' garante que o vetor de queda também seja mostrado (no caso de uma queda de pacote).
- O comando 'reset' é necessário para garantir que todos os gatilhos anteriores tenham sido limpos.
- Embora esse seja um fluxo interligado, o ELAM tem visibilidade no cabeçalho IP.
- Como resultado, 'ipv4 src_ip' e 'dst_ip' podem ser usados para configurar o disparador.
module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger init in-select ?
10 Outerl4-innerl4-ieth
13 Outer(l2|l3|l4)-inner(l2|l3|l4)-noieth
14 Outer(l2(vntag)|l3|l4)-inner(l2|l3|l4)-ieth
15 Outer(l2|l3|l4)-inner(l2|l3|l4)-ieth
6 Outerl2-outerl3-outerl4
7 Innerl2-innerl3-innerl4
8 Outerl2-innerl2-ieth
9 Outerl3-innerl3
module-1(DBG-elam)# trigger init in-select 6 out-select 1
module-1(DBG-elam-insel6)# reset
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2
module-1(DBG-elam-insel6)# start
Para ver se o pacote foi recebido, verifique o status do ELAM. Se houver um disparador, significa que um pacote correspondente às condições foi capturado.
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
Asic 0 Slice 1 Status Armed
A próxima saída mostra que o relatório é exibido com o comando 'report'. A saída é muito longa, então somente o início é colado aqui. Mas observe que o relatório completo é salvo para análise posterior em um local no sistema de arquivos leaf. O nome do arquivo também contém os timestamps de quando o ELAM foi obtido.
leaf1# ls -al /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt
-rw-rw-rw- 1 root root 699106 Sep 30 23:03 /var/log/dme/log/elam_2019-09-30-03m-23h-14s.txt
O "relatório" valida se o pacote foi recebido e se as informações são as esperadas (MAC origem e destino, IP origem e destino, etc.)
module-1(DBG-elam-insel6)# ereport
Python available. Continue ELAM decode with LC Pkg
ELAM REPORT
===========================================================================================================
Trigger/Basic Information
===========================================================================================================
ELAM Report File : /tmp/logs/elam_2019-09-30-03m-23h-14s.txt
In-Select Trigger : Outerl2-outerl3-outerl4( 6 )
Out-Select Trigger : Pktrw-sideband-drpvec( 1 )
ELAM Captured Device : LEAF
Packet Direction : ingress
Triggered ASIC type : Sugarbowl
Triggered ASIC instance : 0
Triggered Slice : 0
Incoming Interface : 0x24( 0x24 )
( Slice Source ID(Ss) in "show plat int hal l2 port gpd" )
===========================================================================================================
Captured Packet
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes : l2uc ipv4 ip ipuc ipv4uc
Opcode : OPCODE_UC
-----------------------------------------------------------------------------------------------------------
Outer L2 Header
-----------------------------------------------------------------------------------------------------------
Destination MAC : 0000.1001.0102
Source MAC : 0000.1001.0101
802.1Q tag is valid : yes( 0x1 )
CoS : 0( 0x0 )
Access Encap VLAN : 2501( 0x9C5 )
-----------------------------------------------------------------------------------------------------------
Outer L3 Header
-----------------------------------------------------------------------------------------------------------
L3 Type : IPv4
IP Version : 4
DSCP : 0
IP Packet Length : 84 ( = IP header(28 bytes) + IP payload )
Don't Fragment Bit : not set
TTL : 255
IP Protocol Number : ICMP
IP CheckSum : 51097( 0xC799 )
Destination IP : 10.1.1.2
Source IP : 10.1.1.1
===========================================================================================================
Forwarding Lookup ( FPB )
===========================================================================================================
-----------------------------------------------------------------------------------------------------------
Destination MAC (Lookup Key)
-----------------------------------------------------------------------------------------------------------
Dst MAC Lookup was performed : yes
Dst MAC Lookup BD : 522( 0x20A )
( Hw BDID in "show plat int hal l2 bd pi" )
Dst MAC Address : 0000.1001.0102
-----------------------------------------------------------------------------------------------------------
Destination MAC (Lookup Result)
-----------------------------------------------------------------------------------------------------------
Dst MAC is Hit : yes
Dst MAC is Hit Index : 6443( 0x192B )
( phy_id in "show plat int hal objects ep l2 mac (MAC) extensions" )
or ( HIT IDX in "show plat int hal l3 nexthops" for L3OUT/L3 EP)
.....
Usando Triagem para seguir o fluxo
A triagem é executada a partir de uma CLI do APIC e pode ser usada para seguir o caminho completo pela estrutura da ACI. Especifique pelo menos a folha de entrada (nó-101), o IP de origem e o IP de destino. Neste caso específico, é um fluxo interligado (Camada 2), portanto, a opção de ponte Triagem deve ser usada.
Observe que a Triagem gera um arquivo de log no diretório atual. Esse arquivo de log conterá todos os logs e relatórios ELAM coletados. Isso permite que o pacote seja capturado a cada salto. A versão curta da saída está abaixo:
apic1# ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "12181", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-18-53-24-125.txt
2019-10-01 18:53:24,129 INFO /controller/bin/ftriage bridge -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.1.2
2019-10-01 18:53:49,280 INFO ftriage: main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 18:54:10,204 INFO ftriage: main:839 L2 frame Seen on leaf1 Ingress: Eth1/3 Egress: Eth1/49 Vnid: 15302583
2019-10-01 18:54:10,422 INFO ftriage: main:242 ingress encap string vlan-2501
2019-10-01 18:54:10,427 INFO ftriage: main:271 Building ingress BD(s), Ctx
2019-10-01 18:54:12,288 INFO ftriage: main:294 Ingress BD(s) Prod:BD1
2019-10-01 18:54:12,288 INFO ftriage: main:301 Ingress Ctx: Prod:VRF1
2019-10-01 18:54:12,397 INFO ftriage: pktrec:490 leaf1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:54:30,079 INFO ftriage: main:933 SMAC 00:00:10:01:01:01 DMAC 00:00:10:01:01:02
2019-10-01 18:54:30,080 INFO ftriage: unicast:973 leaf1: <- is ingress node
2019-10-01 18:54:30,320 INFO ftriage: unicast:1215 leaf1: Dst EP is remote
2019-10-01 18:54:31,155 INFO ftriage: misc:659 leaf1: L2 frame getting bridged in SUG
2019-10-01 18:54:31,380 INFO ftriage: misc:657 leaf1: Dst MAC is present in SUG L2 tbl
2019-10-01 18:54:31,826 INFO ftriage: misc:657 leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']
2019-10-01 18:56:16,249 INFO ftriage: main:622 Found peer-node spine1 and IF: Eth1/1 in candidate list
2019-10-01 18:56:21,346 INFO ftriage: node:643 spine1: Extracted Internal-port GPD Info for lc: 1
2019-10-01 18:56:21,348 INFO ftriage: fcls:4414 spine1: LC trigger ELAM with IFS: Eth1/1 Asic :0 Slice: 0 Srcid: 32
2019-10-01 18:56:54,424 INFO ftriage: main:839 L2 frame Seen on spine1 Ingress: Eth1/1 Egress: LC-1/0 FC-24/0 Port-0 Vnid: 15302583
2019-10-01 18:56:54,424 INFO ftriage: pktrec:490 spine1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:57:15,093 INFO ftriage: fib:332 spine1: Transit in spine
2019-10-01 18:57:21,394 INFO ftriage: unicast:1252 spine1: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66
2019-10-01 18:57:21,508 INFO ftriage: unicast:1417 spine1: EP is known in COOP (DIPo = 10.0.96.66)
2019-10-01 18:57:25,537 INFO ftriage: unicast:1458 spine1: Infra route 10.0.96.66 present in RIB
2019-10-01 18:57:25,537 INFO ftriage: node:1331 spine1: Mapped LC interface: LC-1/0 FC-24/0 Port-0 to FC interface: FC-24/0 LC-1/0 Port-0
2019-10-01 18:57:30,616 INFO ftriage: node:460 spine1: Extracted GPD Info for fc: 24
2019-10-01 18:57:30,617 INFO ftriage: fcls:5748 spine1: FC trigger ELAM with IFS: FC-24/0 LC-1/0 Port-0 Asic :0 Slice: 2 Srcid: 0
2019-10-01 18:57:49,611 INFO ftriage: unicast:1774 L2 frame Seen on FC of node: spine1 with Ingress: FC-24/0 LC-1/0 Port-0 Egress: FC-24/0 LC-1/0 Port-0 Vnid: 15302583
2019-10-01 18:57:49,611 INFO ftriage: pktrec:487 spine1: Collecting transient losses snapshot for FC module: 24
2019-10-01 18:57:53,110 INFO ftriage: node:1339 spine1: Mapped FC interface: FC-24/0 LC-1/0 Port-0 to LC interface: LC-1/0 FC-24/0 Port-0
2019-10-01 18:57:53,111 INFO ftriage: unicast:1474 spine1: Capturing Spine Transit pkt-type L2 frame on egress LC on Node: spine1 IFS: LC-1/0 FC-24/0 Port-0
2019-10-01 18:57:53,530 INFO ftriage: fcls:4414 spine1: LC trigger ELAM with IFS: LC-1/0 FC-24/0 Port-0 Asic :0 Slice: 0 Srcid: 64
2019-10-01 18:58:26,497 INFO ftriage: unicast:1510 spine1: L2 frame Spine egress Transit pkt Seen on spine1 Ingress: LC-1/0 FC-24/0 Port-0 Egress: Eth1/3 Vnid: 15302583
2019-10-01 18:58:26,498 INFO ftriage: pktrec:490 spine1: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:59:28,634 INFO ftriage: main:622 Found peer-node leaf3 and IF: Eth1/49 in candidate list
2019-10-01 18:59:39,235 INFO ftriage: main:839 L2 frame Seen on leaf3 Ingress: Eth1/49 Egress: Eth1/12 (Po1) Vnid: 11364
2019-10-01 18:59:39,350 INFO ftriage: pktrec:490 leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-01 18:59:54,373 INFO ftriage: main:522 Computed egress encap string vlan-2501
2019-10-01 18:59:54,379 INFO ftriage: main:313 Building egress BD(s), Ctx
2019-10-01 18:59:57,152 INFO ftriage: main:331 Egress Ctx Prod:VRF1
2019-10-01 18:59:57,153 INFO ftriage: main:332 Egress BD(s): Prod:BD1
2019-10-01 18:59:59,230 INFO ftriage: unicast:1252 leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66
2019-10-01 18:59:59,231 INFO ftriage: unicast:1257 leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip
2019-10-01 18:59:59,231 INFO ftriage: unicast:1784 leaf3: <- is egress node
2019-10-01 18:59:59,377 INFO ftriage: unicast:1833 leaf3: Dst EP is local
2019-10-01 18:59:59,378 INFO ftriage: misc:657 leaf3: EP if(Po1) same as egr if(Po1)
2019-10-01 18:59:59,378 INFO ftriage: misc:659 leaf3: L2 frame getting bridged in SUG
2019-10-01 18:59:59,613 INFO ftriage: misc:657 leaf3: Dst MAC is present in SUG L2 tbl
2019-10-01 19:00:06,122 INFO ftriage: main:961 Packet is Exiting fabric with peer-device: n3k-3 and peer-port: Ethernet1/16
Troubleshooting de fluxo de trabalho para tráfego unicast de Camada 2 desconhecido — BD em modo de inundação
Neste exemplo, o MAC destino é desconhecido. A pesquisa MAC de destino na folha de entrada não mostra nenhuma saída.
leaf1# show endpoint mac 0000.1001.0102
Legend:
s - arp H - vtep V - vpc-attached p - peer-aged
R - peer-attached-rl B - bounce S - static M - span
D - bounce-to-proxy O - peer-attached a - local-aged m - svc-mgr
L - local E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+
VLAN/ Encap MAC Address MAC Info/ Interface
Domain VLAN IP Address IP Info
+-----------------------------------+---------------+-----------------+--------------+-------------+
Considerando que o BD está definido como 'Flood' para L2 unicast desconhecido, eis o que acontecerá em um nível alto:
- A folha de entrada mistura o cabeçalho do pacote para atribuí-lo a um dos FTAGs (de 0 a 15).
- A folha de entrada encapsulará o quadro em um pacote VXLAN com o VNID BD. O IP destino externo será o BD GIPo + FTAG.
- Ele será inundado na estrutura após uma topologia em árvore e deve alcançar cada nó folha que tenha o BD implantado.
Esta seção destacará o que pode ser verificado.
Localizando BD GIPo
A GUI identifica o grupo multicast 225.1.5.48 usado pelo BD para tráfego multidestino.
BD GIPo
ELAM — folha de entrada — tráfego inundado
Usando o Assistente do ELAM, o relatório do ELAM na folha de entrada é verificado. Isso mostra que o quadro foi inundado no BD e está saindo de todos os uplinks de estrutura (aqui eth1/49, 1/50,1/51 e 1/52).
Assistente ELAM - folha de entrada - Informações de encaminhamento de pacotes
Para localizar o valor FTAG selecionado pela folha de entrada, vá para o relatório bruto do Assistente do ELAM.
sug_lu2ba_sb_info.mc_info.mc_info_nopad.ftag: 0xC
Ao converter o valor hexadecimal de 0xC em decimal, isso resulta em FTAG 12.
Desenhando a topologia FTAG
A topologia FTAG é calculada pelo IS-IS. Uma topologia em árvore é criada para cada valor FTAG, com uma lista de interface de raiz e saída que permite uma topologia de distribuição de carga ideal.
Exiba a topologia FTAG local usando o seguinte comando. No exemplo abaixo, estamos usando a topologia FTAG ID 12 em spine1.
spine1# show isis internal mcast routes ftag
IS-IS process: isis_infra
VRF : default
FTAG Routes
====================================
FTAG ID: 12 [Enabled] Cost:( 2/ 11/ 0)
----------------------------------
Root port: Ethernet1/4.39
OIF List:
Ethernet1/11.11
Ethernet1/12.12
Desenhar a topologia FTAG completa em uma grande estrutura da ACI pode ser uma tarefa longa e complexa. O script Python 'aci-ftag-viewer' (https://github.com/agccie/aci-ftag-viewer) pode ser copiado em um APIC. Gera a topologia FTAG completa da estrutura em uma única passagem.
A saída abaixo exibe a árvore FTAG 12 no Pod1 de uma estrutura Multi-Pod e inclui a topologia FTAG nos dispositivos IPN.
Isso mostra que, se o tráfego entrar na estrutura da ACI a partir do leaf101, ele passará pelos seguintes caminhos, conforme listado na saída do script abaixo.
admin@apic1:tmp> python aci_ftag_viewer.py --ftag 12 --pod 1
################################################################################
# Pod 1 FTAG 12
# Root spine-204
# active nodes: 8, inactive nodes: 1
################################################################################
spine-204
+- 1/1 -------- 1/52 leaf-101
+- 1/2 -------- 1/52 leaf-102
+- 1/3 -------- 1/52 leaf-103
+- 1/4 -------- 1/52 leaf-104
+- 1/49 -------- 1/4 spine-201
| +- 1/11 ...... (EXT) Eth2/13 n7706-01-Multipod-A1
| +- 1/12 ...... (EXT) Eth2/9 n7706-01-Multipod-A2
|
+- 1/50 -------- 1/4 spine-202
| +- 1/11 ...... (EXT) Eth2/14 n7706-01-Multipod-A1
| +- 1/12 ...... (EXT) Eth2/10 n7706-01-Multipod-A2
|
+- 1/51 -------- 2/4 spine-203
+- 2/11 ...... (EXT) Eth2/15 n7706-01-Multipod-A1
+- 2/12 ...... (EXT) Eth2/11 n7706-01-Multipod-A2
+- 1/11 ...... (EXT) Eth2/16 n7706-01-Multipod-A1
+- 1/12 ...... (EXT) Eth2/12 n7706-01-Multipod-A2
ELAM — folha de saída — tráfego inundado
Nesse caso, o tráfego inundado atinge todas as folhas da estrutura da ACI. Assim, ele alcançará ambos leaf3 e leaf4, que são o par VPC. Ambos os nós de folha têm um VPC para o destino. Para evitar pacotes duplicados, o par VPC escolhe apenas uma folha para encaminhar o tráfego inundado para o destino. A folha selecionada é chamada de folha VPC DF (folha de encaminhador designada VPC).
Isso pode ser verificado no ELAM usando o seguinte gatilho em ambos os nós de folha.
module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 14 out-select 1
module-1(DBG-elam-insel14)# set inner ipv4 src_ip 10.1.1.1 dst_ip 10.1.1.2
module-1(DBG-elam-insel14)# start
saída leaf3:
module-1(DBG-elam-insel14)# ereport | egrep vpc.*df
sug_lub_latch_results_vec.lub4_1.vpc_df: 0x1
saída leaf4:
module-1(DBG-elam-insel14)# ereport | egrep vpc.*df
sug_lub_latch_results_vec.lub4_1.vpc_df: 0x0
Na saída acima, leaf3 tem o valor '0x1' definido para o campo 'vpc_df', enquanto leaf4 tem '0x0' definido para o campo 'vpc_df'. Portanto, o encaminhador designado será leaf3. O leaf3 encaminhará o pacote inundado em seu link VPC para o EP de destino.
Troubleshooting de fluxo de trabalho para tráfego unicast de Camada 2 desconhecido — BD no proxy de hardware
O cenário atual listado é aquele para o tráfego unicast desconhecido da camada 2 com o BD no modo proxy de hardware. Nesse cenário, como a folha de entrada não sabe o endereço MAC destino, ela encaminhará o pacote para o endereço proxy-mac anycast spine. O spine realizará uma pesquisa COOP no MAC de destino.
Se a pesquisa for bem-sucedida, como mostrado abaixo, o spine regravará o IP de destino externo no destino do túnel (aqui 10.0.96.66) e o enviará ao par VPC leaf3-leaf4.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Repo Hdr Checksum : 16897
Repo Hdr record timestamp : 10 01 2019 11:05:46 351360334
Repo Hdr last pub timestamp : 10 01 2019 11:05:46 352019546
Repo Hdr last dampen timestamp : 01 01 1970 00:00:00 0
Repo Hdr dampen penalty : 0
Repo Hdr flags : IN_OBJ EXPORT ACTIVE
EP bd vnid : 16351141
EP mac : 00:00:10:01:01:02
flags : 0x90
repo flags : 0x122
Vrf vnid : 2097154
Epg vnid : 0
EVPN Seq no : 0
Remote publish timestamp: 01 01 1970 00:00:00 0
Snapshot timestamp: 10 01 2019 11:05:46 351360334
Tunnel nh : 10.0.96.66
MAC Tunnel : 10.0.96.66
IPv4 Tunnel : 10.0.96.66
IPv6 Tunnel : 10.0.96.66
ETEP Tunnel : 0.0.0.0
Se a pesquisa falhar (o endpoint é desconhecido na estrutura da ACI), o spine descartará o unicast desconhecido.
spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02
Key not found in repo
Resumo de encaminhamento de camada 2
O diagrama a seguir resume o possível comportamento de encaminhamento do tráfego da Camada 2 na estrutura da ACI.
Comportamento de encaminhamento da camada 2 da estrutura da ACI
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
08-Aug-2022 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)