FabricPad omgekeerd pad doorsturen controle voor een VPC+ emulatie-ID

Inleiding

In dit document wordt beschreven hoe u kunt bepalen welke interface u moet gebruiken voor de controle Omgekeerd Pad Forwarding (RPF) met een Emulated Switch-ID (ESID).

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van de basale terminologie en concepten van FabricPath. Gebruikers moeten vooral weten hoe ze Tags (FTAG's) doorsturen en gebruiken. Zie De Multibestemming Boom voor meer informatie over FTAG's in kaart brengen voor een FTAG.

Opmerking: De termen FTAG, Trees en FTAG Trees worden in dit document met elkaar gebruikt. Op het moment dat dit document werd geschreven, zijn alleen FTAG1 en FTAG2 geïmplementeerd. In de toekomst kunnen er wellicht nog meer FTAG's zijn.

Gebruikte componenten

De informatie in dit document is gebaseerd op de Nexus 7000. Sommige opdrachten kunnen op andere Nexus-platforms verschillen, maar de concepten blijven hetzelfde.

Topologie

Opmerking: Dit is slechts een gedeeltelijke topologie. Er is een andere Spine1 aangesloten op Spine2 en zowel Leaf1 als Leaf2, maar deze wordt voor de eenvoud van dit document uitgesloten. Spine1 is de wortel voor FTAG1 en Spine2 is de wortel voor FTAG2.

Achtergrondinformatie

In een FabricPath-domein wordt elke switch geïdentificeerd door een switch-ID (SID). In het geval van een Virtual Port Channel+ (vPC+)-instelling heeft elke peer-switch twee SID’s. Eén voor de fysieke schakelaar en één voor de logische schakelaar die door vPC+ wordt gevormd. De logische SID wordt op beide peers gedeeld en staat bekend als een ESID.

Wanneer een pakket voor meerdere bestemmingen op een vPC+ interface wordt ontvangen en in het FabricPath-domein wordt doorgestuurd, wordt het pakket ingekapseld met een FabricPath-header en wordt de bron SID ingesteld op de ESID. Nadat dit pakket op een FabricPath core poort is ontvangen, wordt een RPF-controle uitgevoerd om er zeker van te zijn dat het pakket op de juiste interface is ontvangen. In het kort, de controle van RPF kruisverwijzingen de bron SID en FTAG van het pakket naar de interface op het werd ontvangen. Als deze niet op de PDF-interface is ontvangen, levert het pakket de PDF-controle niet op en wordt de functie ingetrokken.

RPF controles komen slechts in spel voor multibestemmingspakketten die onbekende unicast, multicast, en uitgezonden pakketten omvatten. De controles van RPF worden niet uitgevoerd op eenastpakketten omdat zij in meervoudige interfaces met Gelijk Koop Meervoudig Pading kunnen komen. De multidoelpakketten zouden slechts in één interface per bron SID op basis van de FTAG-boom moeten komen.

In dit document wordt de VPF-controle op een ESID onderzocht. Een ESID vertegenwoordigt een vPC+ domein. Dit betekent dat het één logische schakelaar is die uit twee fysieke schakelaars bestaat. Als u het topologieschema bekijkt, zult u zien dat er twee fysieke links naar één ESID zijn die meestal het geval zijn. Onthoud, de controle RPF staat slechts toe dat de pakketten met meerdere bestemmingen in één interface op basis van de FTAG boom worden geaccepteerd.

Procedure

Stap 1. Controleer de PF-staat

In dit voorbeeld, is Spine2 de wortel voor FTAG2. Eerst, controleer Spine2 voor de huidige RPF interface voor ESID 34 en FTAG2. Er zijn twee plaatsen om de RPF status te controleren, die in de software en in de hardware zijn. Beide uitgangen tonen aan dat Eth4/41 de RPF-interface is voor FTAG2, ESID 34.

Softwarecontrole

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 

Hardware controle

Bepaal eerst het VDC-nummer en de module de pakketadressen.

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

Koppel vervolgens de module van de ontvangende interface aan om de hardwarestatus te controleren.

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

Stap 2. Controleer de vPC+ affiniteit

Om te begrijpen waarom Spine2 Eth4/41 tot Leaf1 koos in plaats van Eth4/45 tot Leaf2 wanneer beide deel uitmaken van het ESID, moet je eerst het concept van een affiniteit begrijpen.

In een niet vPC+ opstelling, worden de multibestemmingspakketten voornamelijk doorgestuurd op de eerste boom in de topologie, die Tree1 is. In een vPC+ omgeving heeft elke boom (FTAG1 of FTAG2) een affiniteit voor één of de andere peer schakelaar. In deze situatie, omroep, onbekende unicast, en niet-IP multicast frames doorkruisen de boom waarvoor de specifieke peer schakelaar een affiniteit heeft.

U moet controleren welke peer de affiniteit voor FTAG2 heeft. Om dit te doen, log in aan één van de bladwissels in het vPC+ domein. De controle kan van elke peer schakelaar worden gedaan omdat beiden de affiniteit van hun peer zowel als hun eigen moeten kennen.

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

Met deze informatie kun je zien dat als een frame met meerdere doelen op Leaf1 wordt ontvangen, de schakelaar het langs de FTAG2 boom door gaat. Als het frame op Leaf2 wordt ontvangen, wordt het langs de FTAG1-boom doorgestuurd.

Zie De multidoelboom voor meer informatie over FTAG-bomen in kaart brengen voor een FTAG.

Deze informatie wordt gebruikt op Spine2 om de RPF-staat voor ESID 34 te bouwen. Dit is Eth4/41 als RPF-interface voor FTAG2 ESID 34. 

verwantschap

De FTAG-affiniteit wordt met deze methode geselecteerd:

• Er is een systeem dat gebaseerd is op de SID. De SID is afgeleid van de pool van MAC-adressen die aan het chassis in kwestie is toegewezen.

• De laagste systeem-ID heeft de hoogste rang.

• De vPC+ peer met de laagste systeem ID, en daarom de hoogste rang, heeft de affiniteit voor FTAG1.

• De op één na laagste systeem-ID, en dus op één na hoogste rang, heeft de affiniteit voor FTAG2.

Conclusie

De RPF-status wordt gebouwd in overeenstemming met de vPC+-affiniteitsstatus op elke peer. De RPF-interface naar een ESID voor een bepaalde FTAG is de interface die zich verbindt met de peer-schakelaar met de affiniteit.