Solucionar problemas do encaminhamento entre estruturas da ACI - encaminhamento de L3: Dois endpoints em BDs diferentes

Introduction

Este documento descreve as etapas para entender e solucionar problemas de um cenário de encaminhamento de ACI L3.

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 L3: dois endpoints em BDs diferentes capítulo.

Encaminhamento L3: dois endpoints em BDs diferentes

Este capítulo explica um exemplo de Troubleshooting em que os endpoints em diferentes domínios de bridge não podem se comunicar. Isso seria um fluxo roteado pela estrutura da ACI. A Figura 1 ilustra a topologia.

Endpoints em diferentes domínios de bridge

Fluxo de trabalho de solução de problemas de alto nível

A seguir estão etapas típicas de solução de problemas e comandos de verificação:

Primeiras verificações — validação da programação

• O gateway difundido de BD deve ser enviado aos nós folha.
• A rota para a sub-rede BD de destino deve ser enviada aos nós folha.
• O ARP para o gateway padrão dos hosts deve ser resolvido.

Segundas verificações — valide o aprendizado e as entradas da tabela via CLI em nós de folha

• Verifique se os nós folha de origem e folha de destino aprendem o ponto final e se aprendem o ponto final de destino:
  • Tabela de endpoint — 'show endpoint'.
  • Destino TEP — 'show interface tunnel <x>'.
  • Localizando o destino TEP no comando 'show ip route <endereço TEP> vrf overlay-1'.
• Verificar os nós spine aprende o ponto final:
  • 'show coop internal info'.

Terceiros cheques — pegar um pacote e analisar as decisões de encaminhamento

• Com o ELAM (Assistente do ELAM ou CLI) para validar o quadro está lá.
• Ou com Triagem para rastrear o fluxo.

Fluxo de trabalho de solução de problemas para endpoints conhecidos

Verifique o gateway difundido do BD

Neste exemplo, os seguintes pontos finais de origem e destino serão usados:

• EP A 10.1.1.1 sob leaf1.
• EP B 10.1.2.1 sob o par VPC leaf3 e leaf4.

Os seguintes gateways difundidos devem ser vistos:

• 10.1.1.254/24 para gateway BD1 no leaf1.
• 10.1.2.254/24 para gateway BD2 em leaf3 e leaf4.

Isso pode ser verificado usando: 'show ip interface vrf <vrf name>' nos nós de folha.

folha1:

leaf1# show ip interface vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan7, Interface status: protocol-up/link-up/admin-up, iod: 106, mode: pervasive
 IP address: 10.1.1.254, IP subnet: 10.1.1.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

folha 3 e 4:

leaf3# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan1, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

leaf4# show ip interface  vrf Prod:VRF1
IP Interface Status for VRF "Prod:VRF1"
vlan132, Interface status: protocol-up/link-up/admin-up, iod: 159, mode: pervasive
 IP address: 10.1.2.254, IP subnet: 10.1.2.0/24
 IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0

Observe que leaf3 e leaf4 têm o mesmo endereço de gateway difundido, mas diferentes encapsulamentos de VLAN para o SVI provavelmente serão vistos.

• leaf3 usa VLAN 1.
• leaf4 usa a VLAN 132.

Isso é esperado porque a VLAN 1 ou a VLAN 132 é a VLAN local na folha.

Se o endereço IP do gateway difundido não for enviado para o leaf, verifique na GUI do APIC se não há falhas que impeçam a implantação da VLAN.

Verificando a tabela de roteamento na folha

Leaf1 não tem nenhum ponto final na sub-rede 10.1.2.0/24, no entanto, ele deve ter a rota para essa sub-rede para acessá-la:

leaf1# show ip route 10.1.2.0/24 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:22:37, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Observe que a rota indicada com 'pervasive' e 'direct' tem o próximo salto de 10.0.8.65. Esse é o endereço de loopback anycast-v4 que existe em todos os spines.

leaf1# show isis  dteps  vrf overlay-1 | egrep 10.0.8.65
10.0.8.65          SPINE   N/A             PHYSICAL,PROXY-ACAST-V4

Da mesma forma, leaf3 e leaf4 devem ter rota para 10.1.1.0/24.

leaf3# show ip route 10.1.1.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 00:30:25, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Se essas rotas estiverem ausentes, é provável que não haja contrato entre um EPG em BD1 e um EPG em BD2. Se não houver um ponto final local em BD1 sob uma folha, o gateway difundido de BD1 não será enviado para a folha. Se houver um endpoint local em um EPG que tenha um contrato com outro EPG no BD1, a sub-rede do BD1 será aprendida na folha.

Resolução ARP para o IP do gateway padrão

Como a folha onde reside um endpoint local deve ter um gateway pervasivo, as solicitações ARP para o gateway pervasivo devem sempre ser resolvidas pela folha local. Isso pode ser verificado no leaf local usando o seguinte comando:

leaf1# show ip arp internal event-history event  | egrep 10.1.1.1
   [116] TID 26571:arp_handle_arp_request:6135: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_inteface = Ethernet1/3; flood = 0; Info = Sent ARP response.
    [116] TID 26571:arp_process_receive_packet_msg:8384: log_collect_arp_pkt; sip = 10.1.1.1; dip = 10.1.1.254;interface = Vlan7; phy_interface = Ethernet1/3;Info = Received arp request

Aprendizado de endpoint MAC e IP de origem de folha de entrada

No caso de encaminhamento de Camada 3, a ACI realizará o aprendizado do IP de origem da Camada 3 e a consulta do IP de destino. Os endereços IP aprendidos têm o escopo definido para o VRF.

Isso pode ser verificado na GUI em uma guia "operacional" do EPG. Observe que aqui o IP e o MAC são aprendidos.

Terminais operacionais do EPG

Terminais operacionais do EPG — detalhes

Verifique se o ponto de extremidade local foi aprendido na folha local. Aqui, verifique no leaf1 que o IP 10.1.1.1 foi aprendido:

leaf1# show endpoint ip 10.1.1.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
46                                        vlan-2501    0000.1001.0101 L                      eth1/3
Prod:VRF1                                 vlan-2501          10.1.1.1 L                      eth1/3

Como mostrado acima, o conteúdo do endpoint é:

• BD (a VLAN interna para BD é 46) com encapsulamento de VLAN do EPG (vlan-2501) e o endereço MAC aprendido na eth1/3
• VRF (Prod:VRF1) com o IP 10.1.1.1

Isso pode ser entendido como equivalente a uma entrada ARP em uma rede tradicional. A ACI não armazena informações ARP em uma tabela ARP para endpoints. Os endpoints só são visíveis na tabela de endpoints.

A tabela ARP em uma folha é usada apenas para próximos saltos L3Out.

leaf1# show ip arp vrf Prod:VRF1    
Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       D - Static Adjacencies attached to down interface    IP ARP Table for context Prod:VRF1
Total number of entries: 0
Address         Age       MAC Address     Interface    
< NO ENTRY >

Pesquisa de IP de destino de folha de entrada — endpoint remoto conhecido

Supondo que o IP de destino seja conhecido (unicast conhecido), abaixo está a saída 'show endpoint' para o IP de destino 10.1.2.1. Isso é um aprendizado remoto, pois não reside no leaf1, apontando especificamente para a interface do túnel onde é aprendido localmente (túnel 4).

Os endpoints remotos contêm apenas o IP ou o MAC, nunca ambos na mesma entrada. O endereço MAC e o endereço IP no mesmo endpoint só acontecem quando o endpoint é aprendido localmente.

leaf1# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.2.1 p                     tunnel4

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

O TEP de destino é o TEP de anycast do par VPC leaf3 e 4 e é aprendido através de uplinks para a coluna.

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], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.128.64, eth1/51.8, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.64, eth1/52.126, [115/3], 02w06d, isis-isis_infra, isis-l1-int
   *via 10.0.88.94, eth1/50.128, [115/3], 02w06d, isis-isis_infra, isis-l1-int

Informações adicionais de endpoint para IP 10.1.2.1 podem ser coletadas usando o comando 'show system internal epm endpoint ip <ip>'.

leaf1# show system internal epm endpoint ip 10.1.2.1
MAC : 0000.0000.0000 ::: Num IPs : 1
IP# 0 : 10.1.2.1 ::: IP# 0 flags :  ::: l3-sw-hit: No
Vlan id : 0 ::: Vlan vnid : 0 ::: VRF name : Prod:VRF1
BD vnid : 0 ::: VRF vnid : 2097154
Phy If : 0 ::: Tunnel If : 0x18010004
Interface : Tunnel4
Flags : 0x80004420 ::: sclass : 32771 ::: Ref count : 3
EP Create Timestamp : 10/01/2019 13:53:16.228319
EP Update Timestamp : 10/01/2019 14:04:40.757229
EP Flags : peer-aged|IP|sclass|timer|
::::

​Nessa verificação de saída:

• VRF VNID é preenchido — este é o VNID usado para encapsular o quadro em VXLAN para a estrutura.
• O endereço MAC é 0000.0000.0000, pois o endereço MAC nunca é preenchido em uma entrada de IP remota.
• O BD VNID é desconhecido quanto aos quadros roteados, a folha de entrada atua como o roteador e faz uma regravação MAC. Isso significa que o leaf remoto não terá visibilidade no BD do destino, apenas no VRF.

O quadro agora será encapsulado em um quadro VXLAN indo para o TEP remoto 10.0.96.66 com um ID de VXLAN de 2097154 que é o VNID do VRF. Ele será roteado na tabela de roteamento overlay-1 (rota IS-IS) e alcançará o TEP de destino. Aqui ele alcançará leaf3 ou leaf4, pois 10.0.96.66 é o endereço TEP anycast do par VPC leaf3 e leaf4.

Aprendizado do IP de origem na folha de saída

As saídas aqui são tiradas do leaf3, mas seriam semelhantes no leaf4. Quando os pacotes chegarem ao leaf3 (folha de destino e proprietário do TEP), o leaf aprenderá o IP de origem do pacote no VRF.

leaf3# show endpoint ip 10.1.1.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
Prod:VRF1                                                    10.1.1.1 p                    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

O destino TEP 10.0.88.95 é o endereço TEP do leaf1 e é aprendido por meio de todos os uplinks até a coluna.

Pesquisa de IP de destino em folha de saída

A última etapa é que a folha de saída procure o IP de destino. Procure 10.1.2.1 na tabela de endpoint.

Isso fornece as seguintes informações:

• A folha de saída conhece o destino 10.1.2.1 (semelhante a uma rota de host /32 na tabela de roteamento) e a rota é aprendida no VRF correto.
• A folha de saída conhece o MAC 0000.1001.0201 (informações de endpoint).
• A folha de saída sabe que o tráfego destinado a 10.1.2.1 deve ser encapsulado em vlan-2502 e enviado no canal de porta 1 (po1).

leaf3# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+-------------+
2                                         vlan-2502    0000.1001.0201 LpV                       po1
Prod:VRF1                                 vlan-2502          10.1.2.1 LpV                       po1

Triagem para seguir o caminho de dados

Use a Triagem no APIC para seguir o fluxo do caminho de dados. Lembre-se de que a triagem depende do ELAM, portanto ela precisa de um fluxo de dados real. Isso permite a confirmação do caminho de dados completo, com a confirmação de que o pacote sai da estrutura na porta 1/16 do leaf3.

apic1# ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "6888", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-21-17-54-175.txt
2019-10-01 21:17:54,179 INFO     /controller/bin/ftriage route -ii LEAF:101 -sip 10.1.1.1 -dip 10.1.2.1
2019-10-01 21:18:18,149 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 21:18:39,194 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf1 Ingress: Eth1/3 Egress: Eth1/51 Vnid: 2097154
2019-10-01 21:18:39,413 INFO     ftriage:     main:242  ingress encap string vlan-2501
2019-10-01 21:18:39,419 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-01 21:18:41,240 INFO     ftriage:     main:294  Ingress BD(s) Prod:BD1
2019-10-01 21:18:41,240 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-01 21:18:41,349 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf1: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:19:05,747 INFO     ftriage:     main:933  SIP 10.1.1.1 DIP 10.1.2.1
2019-10-01 21:19:05,749 INFO     ftriage:  unicast:973  bdsol-aci32-leaf1: <- is ingress node
2019-10-01 21:19:08,459 INFO     ftriage:  unicast:1215 bdsol-aci32-leaf1: Dst EP is remote
2019-10-01 21:19:09,984 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-01 21:19:09,984 INFO     ftriage:     misc:659  bdsol-aci32-leaf1: L3 packet getting routed/bounced in SUG
2019-10-01 21:19:10,248 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: Dst IP is present in SUG L3 tbl
2019-10-01 21:19:10,689 INFO     ftriage:     misc:657  bdsol-aci32-leaf1: RwDMAC DIPo(10.0.96.66) is one of dst TEPs ['10.0.96.66']
2019-10-01 21:20:56,148 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-spine3 and IF: Eth2/1 in candidate list
2019-10-01 21:21:01,245 INFO     ftriage:     node:643  bdsol-aci32-spine3: Extracted Internal-port GPD Info for lc: 2
2019-10-01 21:21:01,245 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: Eth2/1 Asic :0 Slice: 0 Srcid: 32
2019-10-01 21:21:33,894 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-spine3 Ingress: Eth2/1 Egress: LC-2/0 FC-22/0 Port-1 Vnid: 2097154
2019-10-01 21:21:33,895 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:21:54,487 INFO     ftriage:      fib:332  bdsol-aci32-spine3: Transit in spine
2019-10-01 21:22:01,568 INFO     ftriage:  unicast:1252 bdsol-aci32-spine3: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:22:01,682 INFO     ftriage:  unicast:1417 bdsol-aci32-spine3: EP is known in COOP (DIPo = 10.0.96.66)
2019-10-01 21:22:05,713 INFO     ftriage:  unicast:1458 bdsol-aci32-spine3: Infra route 10.0.96.66 present in RIB
2019-10-01 21:22:05,713 INFO     ftriage:     node:1331 bdsol-aci32-spine3: Mapped LC interface: LC-2/0 FC-22/0 Port-1 to FC interface: FC-22/0 LC-2/0 Port-1
2019-10-01 21:22:10,799 INFO     ftriage:     node:460  bdsol-aci32-spine3: Extracted GPD Info for fc: 22
2019-10-01 21:22:10,799 INFO     ftriage:     fcls:5748 bdsol-aci32-spine3: FC trigger ELAM with IFS: FC-22/0 LC-2/0 Port-1 Asic :0 Slice: 2 Srcid: 24
2019-10-01 21:22:29,322 INFO     ftriage:  unicast:1774 L3 packet Seen on FC of node: bdsol-aci32-spine3  with Ingress: FC-22/0 LC-2/0 Port-1  Egress: FC-22/0 LC-2/0 Port-1 Vnid: 2097154
2019-10-01 21:22:29,322 INFO     ftriage:   pktrec:487  bdsol-aci32-spine3: Collecting transient losses snapshot for FC module: 22
2019-10-01 21:22:31,571 INFO     ftriage:     node:1339 bdsol-aci32-spine3: Mapped FC interface: FC-22/0 LC-2/0 Port-1 to LC interface: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,572 INFO     ftriage:  unicast:1474 bdsol-aci32-spine3: Capturing Spine  Transit pkt-type L3 packet on egress LC on Node: bdsol-aci32-spine3 IFS: LC-2/0 FC-22/0 Port-1
2019-10-01 21:22:31,991 INFO     ftriage:     fcls:4414 bdsol-aci32-spine3: LC trigger ELAM with IFS: LC-2/0 FC-22/0 Port-1 Asic :0 Slice: 1 Srcid: 0
2019-10-01 21:22:48,952 INFO     ftriage:  unicast:1510 bdsol-aci32-spine3: L3 packet Spine egress  Transit pkt Seen on bdsol-aci32-spine3 Ingress: LC-2/0 FC-22/0 Port-1 Egress: Eth2/3 Vnid: 2097154
2019-10-01 21:22:48,952 INFO     ftriage:   pktrec:490  bdsol-aci32-spine3: Collecting transient losses snapshot for LC module: 2
2019-10-01 21:23:50,748 INFO     ftriage:     main:622  Found peer-node bdsol-aci32-leaf3 and IF: Eth1/51 in candidate list
2019-10-01 21:24:05,313 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/51 Egress: Eth1/12 (Po1) Vnid: 11365
2019-10-01 21:24:05,427 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-01 21:24:24,369 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4326 scope:34 filter:65534
2019-10-01 21:24:25,698 INFO     ftriage:     main:522  Computed egress encap string vlan-2502
2019-10-01 21:24:25,704 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-01 21:24:27,510 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-01 21:24:27,510 INFO     ftriage:     main:332  Egress BD(s): Prod:BD2
2019-10-01 21:24:30,536 INFO     ftriage:  unicast:1252 bdsol-aci32-leaf3: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.96.66
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1257 bdsol-aci32-leaf3: dbg_sub_nexthop invokes dbg_sub_eg for vip
2019-10-01 21:24:30,537 INFO     ftriage:  unicast:1784 bdsol-aci32-leaf3: <- is egress node
2019-10-01 21:24:30,684 INFO     ftriage:  unicast:1833 bdsol-aci32-leaf3: Dst EP is local
2019-10-01 21:24:30,685 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-01 21:24:30,943 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-01 21:24:31,242 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11365 in SUG same as EP segid:11365
2019-10-01 21:24:37,631 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/12

Captura de pacotes na folha de saída usando o aplicativo Assistente do ELAM

Abaixo está o pacote capturado com o aplicativo ELAM Assistant no leaf3 vindo da coluna. Isso mostra que:

• O VNID das informações da Camada 4 externa (VNID é 2097154).
• TEP de origem do cabeçalho L3 externo e TEP de destino.

ELAM Assistant — folha de saída de fluxo L3 (parte 1)

ELAM Assistant — folha de saída de fluxo L3 (parte 2)

A seção Informações de encaminhamento de pacotes prova que ele saiu do canal de porta 1

ELAM Assistant — folha de saída L3 — informações de encaminhamento de pacotes

Fluxo de trabalho de solução de problemas para terminais desconhecidos

Esta seção mostra o que difere quando a folha de entrada não conhece o IP de destino.

Pesquisa de IP de destino de folha de entrada

A primeira etapa é verificar se há um ponto final aprendido para o IP de destino.

leaf1# show endpoint ip 10.1.2.1
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
+-----------------------------------+---------------+-----------------+--------------+------------+   
<NO ENTRY>

Não há nada na tabela de endpoint para o destino, portanto, a próxima etapa é verificar a tabela de roteamento procurando a rota de correspondência de prefixo mais longo para o destino:

leaf1# show ip route 10.1.2.1 vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.1.2.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.8.65%overlay-1, [1/0], 01:40:18, static, tag 4294967294
        recursive next hop: 10.0.8.65/32%overlay-1

Cair na sub-rede 10.1.2.0/24 de /24 BD significa que a folha encapsulará o quadro na VXLAN com o destino TEP 10.0.8.65 (anycast-v4 na coluna). O quadro usará um ID de VXLAN que é o VNID de VRF.

Consulta de COOP em spine — o IP de destino é conhecido

O pacote alcançará um dos spines que faz a pesquisa COOP no banco de dados IP. A origem deve ser verificada e o IP de destino precisa ser aprendido corretamente do banco de dados COOP.

Para encontrar um IP no banco de dados COOP, a chave é VRF VNID (2097154 neste exemplo)

Na saída abaixo, há a confirmação de que o banco de dados COOP tem a entrada para o IP de origem do TEP 10.0.88.95 (leaf1) corretamente.

spine1# show coop internal info ip-db key 2097154 10.1.1.1
IP address : 10.1.1.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15302583
EP mac :  00:00:10:01:01:01
Publisher Id : 10.0.88.95
Record timestamp : 10 01 2019 14:16:50 522482647
Publish timestamp : 10 01 2019 14:16:50 532239332
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.88.95
       Tunnel ref count : 1

A saída abaixo mostra que o banco de dados COOP tem a entrada para o IP de destino de TEP 10.0.96.66 (TEP Anycast do par VPC leaf3 e 4) corretamente

spine1# show coop internal info ip-db key 2097154 10.1.2.1
IP address : 10.1.2.1
Vrf : 2097154
Flags : 0
EP bd vnid : 15957974
EP mac :  00:00:10:01:02:01
Publisher Id : 10.0.88.90
Record timestamp : 10 01 2019 14:52:52 558812544
Publish timestamp : 10 01 2019 14:52:52 559479076
Seq No: 0
Remote publish timestamp: 01 01 1970 00:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.96.66
       Tunnel ref count : 1

Neste cenário, o COOP conhece o IP de destino, portanto, ele regravará o IP de destino do cabeçalho IP externo no pacote VXLAN como 10.0.96.66 e enviará para a folha3 ou folha4 (dependendo do hash ECMP). Observe que o IP de origem do quadro VXLAN não é alterado e, portanto, ainda é o PTEP leaf1.

Pesquisa COOP na coluna - o IP de destino é desconhecido

No caso em que a entrada COOP para o IP de destino não é preenchida (endpoint silencioso ou envelhecida), o spine gerará um glean ARP para resolvê-lo. Para obter mais informações, consulte a seção "Encaminhamento de vários pods".

Resumo de encaminhamento da ACI

O desenho a seguir resume o encaminhamento da ACI para o caso de uso das Camadas 2 e 3.