Dépannage du transfert intra-fabric ACI - Transfert C3 : Deux terminaux dans différents BD

Introduction

Ce document décrit les étapes à suivre pour comprendre et dépanner un scénario de transfert L3 ACI.

Informations générales

Le matériel de ce document a été extrait de la Dépannage de l'infrastructure axée sur les applications Cisco, deuxième édition , en particulier le Transfert intra-fabric - Transfert C3 : deux terminaux dans différents BD chapitre.

Transfert C3 : deux terminaux dans différents BD

Ce chapitre explique un exemple de dépannage dans lequel les points d'extrémité de différents domaines de pont ne peuvent pas communiquer entre eux. Il s'agit d'un flux acheminé par le fabric ACI. La Figure 1 illustre la topologie.

Terminaux dans différents domaines de pont

Workflow de dépannage de haut niveau

Voici les étapes de dépannage et les commandes de vérification typiques :

Premiers contrôles — validation de la programmation

• La passerelle omniprésente BD doit être poussée vers les noeuds leaf.
• La route vers le sous-réseau BD de destination doit être envoyée aux noeuds leaf.
• Le protocole ARP de la passerelle par défaut des hôtes doit être résolu.

Second contrôle : validation des entrées de table et d'apprentissage via l'interface CLI sur les noeuds leaf

• Vérifiez que les noeuds leaf source et de destination apprennent le point de terminaison et s'ils apprennent le point de terminaison de destination :
  • Table des terminaux : « show endpoint ».
  • Destination TEP : « show interface tunnel <x> ».
  • Localisation de la destination TEP dans la commande « show ip route <adresse TEP> vrf overlay-1 ».
• Vérifier les noeuds spine apprend le point d'extrémité :
  • 'show coop internal info'.

Troisième vérification : capture d’un paquet et analyse des décisions de transmission

• Avec ELAM (ELAM Assistant ou CLI) pour valider la trame est là.
• Ou avec fTriage pour suivre le flux.

Workflow de dépannage des terminaux connus

Vérifiez la passerelle omniprésente du BD

Dans cet exemple, les points de terminaison source et de destination suivants seront utilisés :

• EP A 10.1.1.1 sous leaf1.
• EP B 10.1.2.1 sous la paire VPC leaf3 et leaf4.

Les passerelles omniprésentes suivantes doivent être observées :

• 10.1.1.254/24 pour la passerelle BD1 sur leaf1.
• 10.1.2.254/24 pour la passerelle BD2 sur leaf3 et leaf4.

Vous pouvez le vérifier en utilisant : 'show ip interface vrf <vrf name>' sur les noeuds leaf.

leaf1 :

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

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

Notez que leaf3 et leaf4 ont la même adresse de passerelle omniprésente, mais une encapsulation VLAN différente pour l'interface SVI sera probablement visible.

• leaf3 utilise le VLAN 1.
• leaf4 utilise le VLAN 132.

Cela est attendu, car VLAN 1 ou VLAN 132 est un VLAN local sur le leaf.

Si l'adresse IP de la passerelle omniprésente n'est pas poussée vers le leaf, vérifiez dans l'interface utilisateur graphique du contrôleur APIC qu'il n'y a aucune erreur qui empêcherait le VLAN d'être déployé.

Vérification de la table de routage sur le leaf

Leaf1 ne possède aucun point d’extrémité dans le sous-réseau 10.1.2.0/24, mais il doit disposer de la route vers ce sous-réseau pour l’atteindre :

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

Notez que le prochain saut de la route marquée avec « omniprésente » et « directe » est 10.0.8.65. Il s’agit de l’adresse de bouclage anycast-v4 qui existe sur tous les spines.

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

De même, leaf3 et leaf4 doivent avoir une route pour 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

Si ces routes sont manquantes, c'est probablement parce qu'il n'y a pas de contrat entre un EPG dans BD1 et un EPG dans BD2. S'il n'y a pas de point d'extrémité local dans BD1 sous un leaf, la passerelle omniprésente BD1 n'est pas poussée vers le leaf. S'il y a un terminal local dans un EPG qui a un contrat avec un autre EPG dans BD1, le sous-réseau BD1 est appris sur le leaf.

Résolution ARP pour l'adresse IP de la passerelle par défaut

Puisque le leaf où réside un terminal local doit avoir une passerelle omniprésente, les requêtes ARP pour la passerelle omniprésente doivent toujours être résolues par le leaf local. Ceci peut être vérifié sur le leaf local en utilisant la commande suivante :

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

Apprentissage des terminaux MAC et IP source leaf en entrée

En cas de transfert de couche 3, l'ACI effectue l'apprentissage IP source de couche 3 et la recherche IP de destination. Les adresses IP apprises sont étendues au VRF.

Vous pouvez le vérifier sur l'interface graphique dans l'onglet « opérationnel » d'un EPG. Notez qu’ici, l’adresse IP et l’adresse MAC sont apprises.

Terminaux opérationnels EPG

Terminaux opérationnels EPG - détails

Vérifiez que le point de terminaison local est appris sur le noeud leaf local. Vérifiez ici sur leaf1 que l’adresse IP 10.1.1.1 est apprise :

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

Comme indiqué ci-dessus, le contenu du terminal est le suivant :

• BD (VLAN interne pour BD = 46) avec encapsulation VLAN de l’EPG (vlan-2501) et l’adresse MAC apprise sur eth1/3
• VRF (Prod : VRF1) avec IP 10.1.1.1

Cela peut être interprété comme l’équivalent d’une entrée ARP dans un réseau traditionnel. L'ACI ne stocke pas les informations ARP dans une table ARP pour les terminaux. Les points de terminaison sont uniquement visibles dans la table des points de terminaison.

La table ARP sur un noeud leaf est uniquement utilisée pour les tronçons suivants 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 >

Recherche IP de destination de feuille d'entrée — point terminal distant connu

En supposant que l’adresse IP de destination est connue (monodiffusion connue), voici la sortie « show endpoint » pour l’adresse IP de destination 10.1.2.1. Il s’agit d’un apprentissage à distance puisqu’il ne réside pas sur leaf1, pointant en particulier vers l’interface du tunnel où il est appris localement (tunnel 4).

Les points d'extrémité distants contiennent uniquement l'adresse IP ou l'adresse MAC, jamais les deux dans la même entrée. L'adresse MAC et l'adresse IP du même point d'extrémité se produisent uniquement lorsque le point d'extrémité est appris localement.

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

Le TEP de destination est le TEP anycast de la paire leaf3 et 4 VPC et est appris via les liaisons ascendantes vers la colonne vertébrale.

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

Des informations supplémentaires sur les terminaux pour IP 10.1.2.1 peuvent être collectées à l'aide de la commande « 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|
::::

​Dans ce contrôle de sortie :

• VNID VRF est renseigné : il s'agit du VNID utilisé pour encapsuler la trame dans VXLAN vers le fabric.
• L'adresse MAC est 0000.0000.0000 car elle n'est jamais renseignée sur une entrée IP distante.
• BD VNID est inconnu comme pour les trames routées, le leaf d'entrée agit comme le routeur et effectue une réécriture MAC. Cela signifie que le leaf distant n'aura pas de visibilité sur le BD de la destination, seulement sur le VRF.

La trame sera maintenant encapsulée dans une trame VXLAN allant vers le TEP distant 10.0.96.66 avec un ID VXLAN de 2097154 qui est le VNID du VRF. Il sera routé dans la table de routage de superposition 1 (route IS-IS) et atteindra l’étape de destination. Ici, il atteindra leaf3 ou leaf4 car 10.0.96.66 est l'adresse TEP anycast de la paire de VPC leaf3 et leaf4.

Apprentissage IP source sur leaf de sortie

Les sorties ici proviennent de leaf3 mais seraient similaires sur leaf4. Lorsque les paquets atteignent leaf3 (leaf de destination et propriétaire du TEP), leaf apprendra l'IP source du paquet dans le 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

L'adresse TEP de destination 10.0.88.95 est l'adresse TEP de leaf1 et est apprise via toutes les liaisons ascendantes vers spine.

Recherche IP de destination sur le leaf de sortie

La dernière étape consiste pour le leaf de sortie à rechercher l'IP de destination. Examinez la table des terminaux pour 10.1.2.1.

Cela donne les informations suivantes :

• La feuille de sortie connaît la destination 10.1.2.1 (semblable à une route hôte /32 dans la table de routage) et la route est apprise dans le VRF correct.
• La feuille de sortie connaît l'adresse MAC 0000.1001.0201 (informations sur le point de terminaison).
• La feuille de sortie sait que le trafic destiné à 10.1.2.1 doit être encapsulé dans le VLAN-2502 et envoyé sur le port-channel 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

fTriage pour suivre le chemin de données

Utilisez fTriage dans le contrôleur APIC pour suivre le flux du chemin de données. Rappelez-vous que fTriage s'appuie sur ELAM, donc il a besoin d'un flux de données réel. Cela permet de confirmer le chemin de données complet, avec la confirmation que le paquet quitte le fabric sur le port leaf3 1/16.

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

Capture de paquets sur feuille de sortie avec l'application ELAM Assistant

Voici le paquet capturé avec l'application ELAM Assistant sur leaf3 en provenance de la colonne vertébrale. Cela montre que :

• Le VNID des informations de couche 4 externes (VNID est 2097154).
• En-tête L3 externe source TEP et destination TEP.

ELAM Assistant — leaf de sortie de flux de couche 3 (partie 1)

ELAM Assistant — leaf de sortie de flux L3 (partie 2)

La section Packet Forwarding Information (Informations de transfert de paquets) prouve qu'il est sorti sur le port-channel 1

Assistant ELAM — Leaf de sortie C3 — Informations de transfert de paquets

Workflow de dépannage pour les terminaux inconnus

Cette section montre ce qui diffère lorsque le leaf d'entrée ne connaît pas l'IP de destination.

Recherche IP de destination leaf en entrée

La première étape consiste à vérifier s'il existe un point d'accès pour l'IP de destination.

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>

Il n'y a rien dans la table de terminaux pour la destination, donc l'étape suivante consiste à vérifier la table de routage à la recherche de la route de correspondance de préfixe la plus longue vers la destination :

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

En tombant sur le sous-réseau /24 BD 10.1.2.0/24, le leaf encapsule la trame dans VXLAN avec la destination TEP 10.0.8.65 (anycast-v4 sur spine). La trame utilise un ID VXLAN qui est l'ID de réseau virtuel VRF.

Recherche COOP sur la colonne vertébrale - IP de destination connue

Le paquet atteint l'un des spines qui effectue une recherche COOP dans la base de données IP. La source doit être vérifiée et l'IP de destination doit être apprise correctement à partir de la base de données COOP.

Pour rechercher une adresse IP dans la base de données COOP, la clé est VNID VRF (2097154 dans cet exemple)

Le résultat ci-dessous confirme que l'entrée de la base de données COOP pour l'adresse IP source provient de TEP 10.0.88.95 (leaf1) correctement.

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

La sortie ci-dessous montre que la base de données COOP a l'entrée pour l'IP de destination de TEP 10.0.96.66 (Anycast TEP de la paire leaf3 et 4 VPC) correctement

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

Dans le scénario ici, COOP connaît l'adresse IP de destination de sorte qu'il réécrira l'adresse IP de destination de l'en-tête IP externe dans le paquet VXLAN pour qu'elle soit 10.0.96.66, puis enverra à leaf3 ou leaf4 (selon le hachage ECMP). Notez que l’adresse IP source de la trame VXLAN n’est pas modifiée et qu’il s’agit donc toujours du protocole PTEP leaf1.

Recherche COOP sur la colonne vertébrale - IP de destination inconnue

Dans le cas où l'entrée COOP pour l'IP de destination n'est pas renseignée (point d'extrémité silencieux ou obsolète), la colonne vertébrale générera un glanage ARP pour la résoudre. Pour plus d'informations, référez-vous à la section « Transfert multipod ».

Récapitulatif du transfert ACI

Le schéma suivant résume l'exemple d'utilisation du transfert ACI pour les couches 2 et 3.