Contenu

Introduction

Informations générales

Aperçu

Topologie

Vérification de GUI

Workflow de dépannage du trafic de monodiffusion de couche 2 connu

Apprentissage MAC EP source leaf en entrée

Recherche de point de terminaison MAC de destination leaf en entrée

Envoi du commutateur leaf d'entrée au commutateur spine

Transfert de spine

Egress leaf remote EP MAC learning

Recherche MAC de destination leaf de sortie

Validez que les deux terminaux sont correctement appris dans le repo COOP EP du commutateur spine

Sortie ELAM avec ELAM Assistant

ELAM leaf d'entrée utilisant CLI

Utilisation de fTriage pour suivre le flux

Workflow de dépannage pour le trafic de monodiffusion de couche 2 inconnu — BD en mode d'inondation

Recherche de BD GIPo

ELAM — leaf d'entrée — trafic inondé

Dessin de la topologie FTAG

ELAM — leaf de sortie — trafic inondé

Workflow de dépannage pour le trafic de monodiffusion de couche 2 inconnu — BD dans le proxy matériel

Résumé du transfert de couche 2

Comportement de transfert de couche 2 du fabric ACI

Introduction

Ce document décrit les étapes à suivre pour comprendre et dépanner le transfert de couche 2 dans l'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 L2 : deux terminaux dans le même BD - pas de routage monodiffusion chapitre.

Aperçu

Cette section explique un exemple de dépannage où les points de terminaison du même domaine de pont et du même sous-réseau ne peuvent pas communiquer entre eux. La figure ci-dessous illustre la topologie dans laquelle le BD ne possède aucun sous-réseau et où le routage de monodiffusion est désactivé.

En général, lors du dépannage des flux de trafic avec la connectivité des terminaux, la suggestion consiste à commencer à identifier une paire de terminaux. Référez-vous à la topologie ci-dessous avec les EP A et B. Ceux-ci auront respectivement les adresses IP 10.1.1.1/24 et 10.1.1.2/24. Les adresses MAC seront respectivement 00:00:10:01:01:01 et 00:00:10:01:01:02.

Topologie

Cette section présente trois scénarios :

1. Flux de monodiffusion de couche 2 connu.

2. Flux de monodiffusion de couche 2 inconnu avec BD en mode d'inondation.

3. Flux de monodiffusion de couche 2 inconnu avec BD en mode proxy matériel.

Les flux de dépannage qui seront suivis peuvent être résumés par le schéma suivant :

- Vérification de niveau 1 : Validation de la configuration, des pannes et des terminaux via l'interface utilisateur graphique.

- Vérification de niveau 2 : CLI sur les commutateurs Leaf :

- Vérifiez si les commutateurs leaf source et de destination apprennent les points d'extrémité.

- Vérifiez si les noeuds spine apprennent le point de terminaison dans COOP.

- Vérification de niveau 3 : Capture de paquets:

- ELAM (ELAM Assistant ou CLI) pour valider la trame.

- fTriage pour suivre le flux.

Vérification de GUI

Le premier niveau de dépannage consiste à valider à partir de l’interface graphique que l’adresse MAC du point d’extrémité a été correctement apprise. Vous pouvez le faire à partir de l'onglet opérationnel de l'EPG où se trouve le terminal.

'Onglet EPG Operational > Client End-Points'

Dans ce scénario, les deux terminaux A et B sont affichés dans l'interface utilisateur graphique. L'interface utilisateur graphique affiche leurs adresses MAC, l'interface à laquelle elles sont connectées au fabric et l'encapsulation. Dans ce cas, les deux sont dans le VLAN 2501 encapsulé.

L'adresse IP n'est normalement pas apprise du fabric ACI car le routage monodiffusion a été désactivé au niveau BD.

Reportez-vous à la colonne source d'apprentissage dans la capture d'écran ci-dessus. S'il indique « acquis », le commutateur leaf ACI a reçu au moins un paquet du point d'extrémité.

Puisque dans ce cas les terminaux sont appris du fabric ACI, passez au cas de dépannage suivant pour le trafic monodiffusion de couche 2 connu.

Workflow de dépannage du trafic de monodiffusion de couche 2 connu

Apprentissage MAC EP source leaf en entrée

Dans le cas d'un transfert de couche 2 dans le même BD, l'ACI apprend uniquement l'adresse MAC source et effectue le transfert en fonction de l'adresse MAC de destination. Les adresses MAC sont apprises dans la portée du BD.

Tout d'abord, vérifiez si le terminal est appris :

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

Le résultat ci-dessus fournit les informations suivantes :

- L'adresse MAC 0000.1001.0101 est apprise localement (l'indicateur est L pour local) sur le port ethernet 1/3 avec encapsulation vlan-2501 dans vrf Prod:VRF1.

- Reportez-vous à la colonne « VLAN/Domain » dans le résultat ci-dessus. L'ID de VLAN indiqué ici est le VLAN interne.

Recherche de point de terminaison MAC de destination leaf en entrée

Supposons que l'adresse MAC de destination est connue (monodiffusion connue).

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

Le résultat ci-dessus fournit les informations suivantes :

- L’adresse MAC 0000.1001.0102 n’est pas apprise localement.

- Il est appris à partir du tunnel d'interface 4.

- Elle est apprise dans l’encapsulation VXLAN-16351141 qui correspond à l’ID de réseau BD_VNID (VXLAN Network ID) du domaine de pont.

Vérifiez ensuite la destination de l'interface de tunnel à l'aide de la commande « 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

Ainsi, le paquet sera encapsulé dans VXLAN avec l'IP source TEP 10.0.88.95 (assigné à loopback0) et envoyé vers l'IP de destination TEP 10.0.96.66.

Confirmez l'adresse IP source :

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

L'adresse IP TEP de destination 10.0.96.66 peut être l'une des suivantes :

- Adresse PTEP d'un autre leaf (peut être vérifiée en utilisant acidiag fnvread)

- VIP VPC (peut être vu dans 'GUI > Fabric > Access Policies > Policies > Switch > Virtual Port Channel default' (voir capture d'écran ci-dessous)

- Une adresse IP de bouclage sur un commutateur Spine. Utilisez la commande « show ip interface vrf overlay-1 » sur le commutateur spine pour vérifier cela.

Groupes de protection VPC explicites

Envoi du commutateur leaf d'entrée au commutateur spine

Le leaf d'entrée encapsule maintenant la trame dans VXLAN avec l'IP de destination externe définie sur 10.0.96.66, qui est l'IP de destination du tunnel répertoriée dans la commande précédente « show interface tunnel 4 ». Il l'encapsule dans VXLAN avec le VNID du domaine de pont - vxlan-16351141 - comme indiqué dans le résultat précédent de la commande « show endpoint mac 0000.1001.0102 ».

En fonction de la route IS-IS dans la superposition VRF-1, déterminez où l'envoyer :

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

Ainsi, il y a le routage ECMP (equal cost multipath) vers la destination en utilisant eth1/49 et eth1/50 qui sont les liaisons ascendantes du fabric vers les commutateurs spine.

Transfert de spine

La table de routage de superposition VRF-1 sur le spine montre que la route hôte 10.0.96.66 est accessible via leaf3 ou leaf4. Ceci est attendu car 10.0.96.66 est le VIP VPC des commutateurs leaf 103 et 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

Egress leaf remote EP MAC learning

Dans ce cas, l’étape de destination est une paire de VPC, de sorte que le paquet arrive sur leaf3 ou leaf4. Reportez-vous aux sorties de commande ci-dessous. Leaf4 doit afficher un résultat similaire. Étant donné qu’ils font partie de la même paire VPC, tous les points d’extrémité sont synchronisés entre les deux commutateurs Leaf.

L’apprentissage des terminaux pour le trafic de couche 2 sur le leaf de sortie est basé sur l’adresse MAC source qui est apprise dans le BD correspondant au VNID dans le paquet reçu. Cela peut être vérifié dans la table des terminaux.

L'adresse MAC source se trouve derrière le tunnel 26 dans VXLAN-16351141.

Le tunnel 26 va à l'IP TEP 10.0.88.95 qui est 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

Recherche MAC de destination leaf de sortie

La commande « show endpoint » confirme que l’adresse MAC de destination est apprise derrière le port-channel 1 et utilise l’encapsulation 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

Cela indique que la trame quitte le fabric ACI sur l'interface leaf3 port-channel 1 avec l'ID de VLAN 2501 d'encapsulation. Vous pouvez trouver le VNID BD sous l'onglet Tenant Operational dans l'interface utilisateur graphique.

Validez que les deux terminaux sont correctement appris dans le repo COOP EP du commutateur spine

Le repo COOP EP doit être synchronisé sur tous les noeuds spine. la repo COOP EP peut être vérifiée en utilisant le VNID BD comme clé et en entrant l'adresse MAC EP.

L’adresse MAC source de ce flux est apprise du tunnel next-hop 10.0.88.95 qui est l’adresse IP TEP de leaf1. En outre, le résultat de la commande indique l’ID de pont VNID 16351141 qui correspond au domaine de pont correct.

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

L’adresse MAC de destination de ce flux est apprise par rapport au VIP 10.0.96.66 du VPC de leaf3 et leaf4. Le VNID BD EP 16351141 est également indiqué, ce qui correspond au BD correct.

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

Sortie ELAM avec ELAM Assistant

ELAM Assistant est une application ACI puissante qui peut simplifier l'exécution des captures ELAM sur un fabric ACI.

Les déclencheurs de l'assistant ELAM peuvent être démarrés simultanément sur plusieurs noeuds leaf. Par conséquent, des paquets spécifiques peuvent être vérifiés en parallèle dans leaf1, leaf3 et leaf4.

La capture ELAM configurée apparaît comme indiqué ci-dessous. Comme observé, le paquet est vu sur leaf1 (noeud-101) et leaf3 (noeud-103).

ELAM Assistant — paramètres

Le rapport de leaf1 (node-101) présente les éléments suivants :

- Le résultat Captured Packet Information confirme que le paquet est entré sur eth1/3 et qu’il contient les informations MAC et IP correctes.

- Les informations de transfert de paquets indiquent qu'il est transféré sur eth1/49 à l'adresse IP TEP 10.0.96.66.

Assistant ELAM — leaf1 (node-101) — Informations sur les paquets capturés

Assistant ELAM — leaf1 (node-101) — Informations de transfert de paquets

Sur leaf3 (node-103) sur la leaf de sortie, les observations suivantes sont effectuées :

Dans les informations sur les paquets capturés sur leaf3, il entre à partir de eth1/49. L’adresse IP du routeur confirme ce qui suit :

- TEP source : 10.0.88.95

- ÉTAPE de destination : 10.0.96.66

- VNID : 16351141 (VNID BD)

Assistant ELAM — leaf3 (node-103) — Informations sur les paquets capturés

Les informations de transfert de paquets indiquent que le trafic est transféré sur le port-channel 1 et en particulier sur ethernet 1/12.

ELAM leaf d'entrée utilisant CLI

Il est recommandé d'utiliser l'assistant ELAM car il simplifie l'exécution des captures ELAM. Cependant, il est également possible d'utiliser les commandes CLI sur les commutateurs ACI pour générer un rapport ELAM. Vous trouverez ci-dessous un exemple de la façon de procéder.

Utilisez la séquence de déclenchement illustrée pour capturer le paquet sur le leaf d’entrée. Reportez-vous à la section « Outils » pour plus d'informations sur les options ELAM.

- Dans cet exemple, l'ASIC est 'tah' en tant que leaf (référence se terminant par '-EX').

- « in-select 6 » est utilisé pour capturer un paquet provenant d'un port de liaison descendante sans encapsulation VXLAN.

- 'out-select 1' garantit que le vecteur d'abandon est également affiché (en cas d'abandon de paquet).

- La commande « reset » est nécessaire pour s'assurer que les déclencheurs précédents ont été nettoyés.

- Même s'il s'agit d'un flux ponté, ELAM a une visibilité sur l'en-tête IP.

- Par conséquent, 'ipv4 src_ip' et 'dst_ip' peuvent être utilisés pour configurer le déclencheur.

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

Pour vérifier si le paquet a été reçu, vérifiez l'état ELAM. S’il existe un déclencheur, cela signifie qu’un paquet correspondant aux conditions a été intercepté.

module-1(DBG-elam-insel6)# status

ELAM STATUS

===========

Asic 0 Slice 0 Status Triggered

Asic 0 Slice 1 Status Armed

Le résultat suivant montre que le rapport est affiché à l'aide de la commande « ereport ». Le résultat est très long, donc seul le début est collé ici. Notez toutefois que le rapport complet est enregistré pour une analyse ultérieure dans un emplacement du système de fichiers leaf. Le nom de fichier contient également les horodatages lorsque l'ELAM a été pris.

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

Le « ereport » valide la réception du paquet et l'information est conforme aux attentes (adresse MAC source et de destination, adresse IP source et de destination, 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)

.....

Utilisation de fTriage pour suivre le flux

Le triage est exécuté à partir d'une interface de ligne de commande APIC et peut être utilisé pour suivre le chemin complet via le fabric ACI. Spécifiez au moins le leaf d'entrée (noeud-101), l'IP source et l'IP de destination. Dans ce cas précis, il s'agit d'un flux ponté (couche 2). L'option de pont fTriage doit donc être utilisée.

Notez que fTriage génère un fichier journal dans le répertoire actif. Ce fichier journal contient tous les journaux et les rapports ELAM collectés. Cela permet de capturer le paquet à chaque saut. La version courte du résultat est la suivante :

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

Workflow de dépannage pour le trafic de monodiffusion de couche 2 inconnu — BD en mode d'inondation

Dans cet exemple, l'adresse MAC de destination est inconnue. La recherche MAC de destination sur le noeud leaf d'entrée n'affiche aucune sortie.

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

+-----------------------------------+---------------+-----------------+--------------+-------------+

Étant donné que le BD est défini sur « Flood » pour la monodiffusion inconnue de couche 2, voici ce qui se passera à un niveau élevé :

1. Le leaf entrant hachera l'en-tête du paquet pour l'attribuer à l'un des FTAG (de 0 à 15).

2. Le leaf d'entrée encapsule la trame dans un paquet VXLAN avec le VNID BD. L'adresse IP de destination du routeur sera le BD GIPo + FTAG.

3. Elle sera diffusée dans le fabric suivant une topologie arborescente et devrait atteindre chaque noeud leaf sur lequel le BD est déployé.

Cette section met en évidence les éléments pouvant être vérifiés.

Recherche de BD GIPo

L'interface utilisateur graphique identifie le groupe de multidiffusion 225.1.5.48 utilisé par le BD pour le trafic multidestination.

BD GIPo

ELAM — leaf d'entrée — trafic inondé

Avec l'assistant ELAM, le rapport ELAM sur le leaf d'entrée est vérifié. Cela montre que la trame a été inondée dans le BD et qu'elle est en train de sortir sur toutes les liaisons ascendantes de fabric (ici eth1/49, 1/50, 1/51 et 1/52).

Assistant ELAM - Leaf d'entrée - Informations de transfert de paquets

Pour rechercher la valeur FTAG sélectionnée par le leaf d'entrée, accédez au rapport brut de l'assistant ELAM.

sug_lu2ba_sb_info.mc_info.mc_info_nopad.ftag: 0xC

Lorsque vous convertissez la valeur hexadécimale de 0xC en valeur décimale, vous obtenez FTAG 12.

Dessin de la topologie FTAG

La topologie FTAG est calculée par IS-IS. Une topologie arborescente est créée pour chaque valeur FTAG, avec une liste d'interfaces racine et de sortie qui permet une topologie de répartition de charge optimale.

Affichez la topologie FTAG locale à l'aide de la commande suivante. Dans l'exemple ci-dessous, nous utilisons la topologie FTAG ID 12 sur 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

Le dessin de la topologie FTAG complète dans un fabric ACI de grande taille peut s'avérer une tâche longue et complexe. Le script Python 'aci-ftag-viewer' (https://github.com/agccie/aci-ftag-viewer) peut être copié sur un APIC. Il génère la topologie FTAG complète du fabric en une seule passe.

La sortie ci-dessous affiche l'arborescence FTAG 12 dans le Pod1 d'un fabric Multi-Pod et inclut la topologie FTAG sur les périphériques IPN.

Cela montre que si le trafic entre dans le fabric ACI à partir de leaf101, il traversera les chemins suivants, comme indiqué dans le résultat du script ci-dessous.

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 — leaf de sortie — trafic inondé

Dans ce cas, le trafic inondé atteint chaque leaf du fabric ACI. Ainsi, il atteindra à la fois leaf3 et leaf4 qui sont la paire VPC. Ces deux noeuds leaf ont un VPC vers la destination. Pour éviter les paquets en double, la paire VPC sélectionne un seul leaf pour transférer le trafic diffusé vers la destination. Le leaf sélectionné est appelé leaf VPC DF (leaf de redirecteur désigné par VPC).

Ceci peut être vérifié dans ELAM en utilisant le déclencheur suivant sur les deux noeuds leaf.

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

sortie leaf3 :

module-1(DBG-elam-insel14)# ereport | egrep vpc.*df

sug_lub_latch_results_vec.lub4_1.vpc_df: 0x1

sortie leaf4 :

module-1(DBG-elam-insel14)# ereport | egrep vpc.*df

sug_lub_latch_results_vec.lub4_1.vpc_df: 0x0

Dans le résultat ci-dessus, leaf3 a la valeur '0x1' définie pour le champ 'vpc_df', tandis que leaf4 a '0x0' définie pour le champ 'vpc_df'. Par conséquent, le redirecteur désigné sera leaf3. leaf3 transfère le paquet diffusé sur sa liaison VPC vers l'EP de destination.

Workflow de dépannage pour le trafic de monodiffusion de couche 2 inconnu — BD dans le proxy matériel

Le scénario actuel répertorié est celui du trafic de monodiffusion inconnu de couche 2 avec le BD en mode proxy matériel. Dans ce scénario, étant donné que le leaf d'entrée ne connaît pas l'adresse MAC de destination, il transfère le paquet à l'adresse proxy-mac anycast spine. La colonne vertébrale effectue une recherche COOP pour l'adresse MAC de destination.

Si la recherche réussit comme indiqué ci-dessous, le spine réécrira l'adresse IP de destination externe vers la destination du tunnel (ici 10.0.96.66) et l'enverra à la paire 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

Si la recherche échoue (le point d'extrémité est inconnu dans le fabric ACI), le spine abandonne la monodiffusion inconnue.

spine1# show coop internal info repo ep key 15302583 00:00:10:01:01:02

Key not found in repo

Résumé du transfert de couche 2

Le schéma suivant résume le comportement de transfert possible pour le trafic de couche 2 dans le fabric ACI.

Comportement de transfert de couche 2 du fabric ACI