Vérification du transfert inverse du chemin FabricPath pour un ID de commutateur émulé VPC+

Introduction

Ce document décrit comment déterminer l'interface à utiliser pour la vérification du transfert inverse de chemin (RPF) avec un ID de commutateur émulé (ESID).

Prérequis

Conditions requises

Cisco vous recommande de connaître la terminologie et les concepts de base de FabricPath. Plus précisément, les utilisateurs doivent connaître les balises de transfert (FTAG) et leur utilisation. Pour plus d'informations sur les FTAG, consultez Mapping Out the Multidestination Tree for a FTAG.

Note: Les termes FTAG, Trees et FTAG Trees sont utilisés de manière interchangeable dans ce document. Au moment de la rédaction de ce document, seuls FTAG1 et FTAG2 ont été mis en oeuvre. Il pourrait y avoir d'autres GAFI à l'avenir.

Components Used

Les informations de ce document sont basées sur le Nexus 7000. Certaines commandes peuvent varier sur d'autres plates-formes Nexus, mais les concepts resteront les mêmes.

Topologie

Note: Il ne s’agit que d’une topologie partielle. Il y a une autre Spine1 connectée à Spine2 et à Leaf1 et Leaf2, mais elle est exclue de ce document pour plus de simplicité. Spine1 est la racine de FTAG1 et Spine2 la racine de FTAG2.

Informations générales

Dans un domaine FabricPath, chaque commutateur est identifié par un ID de commutateur (SID). Dans le cas d'une configuration Virtual Port Channel+ (vPC+), chaque commutateur homologue a deux SID. Un pour le commutateur physique et un pour le commutateur logique formé par vPC+. Le SID logique est partagé sur les deux homologues et est appelé ESID.

Lorsqu'un paquet multidestination est reçu sur une interface vPC+ et transféré dans le domaine FabricPath, le paquet est encapsulé avec un en-tête FabricPath et le SID source est défini sur ESID. Une fois que ce paquet est reçu sur un port principal FabricPath, une vérification RPF est effectuée afin de s'assurer que le paquet a été reçu sur la bonne interface. En bref, la croix de contrôle RPF fait référence au SID source et au FTAG du paquet à l'interface sur laquelle il a été reçu. Si elle n’a pas été reçue sur l’interface RPF, le paquet échoue au contrôle RPF et est abandonné.

Les contrôles RPF entrent en jeu uniquement pour les paquets multidestination qui incluent des paquets de monodiffusion, de multidiffusion et de diffusion inconnus. Les contrôles RPF ne sont pas effectués sur des paquets de monodiffusion, car ils peuvent être effectués dans plusieurs interfaces avec le multiacheminement à coût égal. Les paquets multidestination ne doivent être acheminés que dans une seule interface par SID source en fonction de l'arborescence FTAG.

Dans ce document, la vérification RPF pour un ESID est étudiée. Un ESID représente un domaine vPC+. Cela signifie qu’il s’agit d’un commutateur logique qui se compose de deux commutateurs physiques. Si vous considérez le schéma de topologie, vous verrez qu'il existe deux liaisons physiques à un ESID, ce qui est généralement le cas. N’oubliez pas que le contrôle RPF permet uniquement l’acceptation de paquets multidestination dans une interface basée sur l’arborescence FTAG.

Procédure

Étape 1. Vérifier l'état RPF

Dans cet exemple, Spine2 est la racine de FTAG2. Tout d'abord, vérifiez Spine2 pour l'interface RPF actuelle pour ESID 34 et FTAG2. Il y a deux endroits pour vérifier l'état du RPF, qui sont dans le logiciel et dans le matériel. Les deux sorties montrent que Eth4/41 est l'interface RPF pour FTAG2, ESID 34.

Vérification du logiciel

Spine2# show l2 multicast trees

<snip>

ftag/2, topo/0, Switch-id 34), uptime: 04:55:59, isis
 Outgoing interface list: (count: 1, '*' is the preferred interface)
* Interface Ethernet4/41, [RPF]  [admin distance/115] uptime: 02:09:32, isis 

Vérification du matériel

Tout d'abord, déterminez le numéro de VDC et le module que le paquet entre.

Spine2# show vdc

Switchwide mode is m1 f1 m1xl f2 m2xl

vdc_id  vdc_name           state          mac                 type        lc

------  --------           -----          ----------          ---------   ---
6       Spine2             active         84:78:ac:0b:60:46   Ethernet    f2

Ensuite, connectez-vous au module de l'interface de réception afin de vérifier l'état du matériel.

Spine2# attach module 4

module-4# show fabricpath unicast routes vdc 6 ftag 2 switchid 34
Route in VDC 6
---------------
--------------------------------------------------------------------------------
 FTAG | SwitchID  | SubSwitchID | Loc/Rem | RPF | RPF Intf | Num Paths | Merge V
--------------------------------------------------------------------------------
 0002 |    0034   |    0000     |  Remote | Yes |  Eth4/41 |      0    |   1
--------------------------------------------------------------------------------
PD Information for Prefix:

FE num  |   ADDR TYPE   | HTBL ADDR | TCAM ADDR | SWSI
----------------------------------------------------------
     10 |   HASH TABLE  |  00001440 |  000000ff | 0000124c
     11 |   HASH TABLE  |  00001440 |  000000ff | 0000124c
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Étape 2. Vérifier l'affinité vPC+

Afin de comprendre pourquoi Spine2 a choisi Eth4/41 pour Leaf1 au lieu de Eth4/45 pour Leaf2 lorsque les deux font partie de l'ESID, vous devez d'abord comprendre le concept d'affinité.

Dans une configuration autre que vPC+, les paquets multidestinations sont principalement transférés sur la première arborescence de la topologie, à savoir Tree1. Dans un environnement vPC+, chaque arborescence (FTAG1 ou FTAG2) a une affinité pour l'un ou l'autre commutateur homologue. Dans ce cas, les trames de diffusion, de monodiffusion inconnue et de multidiffusion non IP traversent l'arborescence pour laquelle le commutateur homologue particulier a une affinité.

Vous devez vérifier quel homologue a l'affinité pour FTAG2. Pour ce faire, connectez-vous à l'un des commutateurs Leaf du domaine vPC+. La vérification peut être effectuée à partir de l'un ou l'autre commutateur homologue, car les deux doivent connaître l'affinité de leur homologue ainsi que la leur.

Leaf1# show fabricpath isis database detail | i Affinity|Hostname|Nickname

<snip>

    Hostname      :  Leaf2              Length : 5
      Affinity        : 
       Nickname: 34 Numgraphs: 1 Graph-id: 1       Nickname        :
       Priority: 0 Nickname: 4 BcastPriority: 64
       Priority: 0 Nickname: 34 BcastPriority: 0
      Nickname Migration :

    Hostname      :  Leaf1              Length : 5
      Affinity        :
       Nickname: 34 Numgraphs: 1 Graph-id: 2
      Nickname Migration :
      Nickname        :
       Priority: 0 Nickname: 3 BcastPriority: 64
       Priority: 0 Nickname: 34 BcastPriority: 0

Avec ces informations, vous pouvez voir que si une trame multidestination est reçue sur Leaf1, le commutateur la transfère le long de l’arborescence FTAG2. Si la trame est reçue sur Leaf2, elle est transférée le long de l’arborescence FTAG1.

Pour plus d'informations sur les arborescences FTAG, consultez Mapping Out the Multidestination Tree for a FTAG.

Ces informations sont utilisées sur Spine2 afin de créer l'état RPF pour l'ESID 34. Il s’agit de Eth4/41 utilisé comme interface RPF pour FTAG2 ESID 34. 

Sélection d'affinité

L'affinité FTAG est sélectionnée avec la méthode suivante :

• Il existe un système de classement basé sur le SID. Le SID provient du pool d'adresses MAC attribué au châssis en question.

• L'ID système le plus bas a le rang le plus élevé.

• L'homologue vPC+ ayant l'ID système le plus bas, et donc le rang le plus élevé, a l'affinité pour le FTAG1.

• Le deuxième ID système le plus bas, et donc le deuxième rang le plus élevé, a l'affinité pour le FTAG2.

Conclusion

L'état RPF est construit conformément à l'état d'affinité vPC+ sur chaque homologue. L'interface RPF à un ESID pour une FTAG donnée est l'interface qui se connecte au commutateur homologue avec l'affinité.