FabricPath Reverse Path Forwarding Verificar se há um VPC+ Emulated Switch-ID

Introduction

Este documento descreve como determinar qual interface usar para a verificação de RPF (Reverse Path Forwarding) com um ESID (Emulated Switch-ID, ID de Switch Emulado).

Pré-requisitos

Requirements

A Cisco recomenda que você tenha conhecimento da terminologia e dos conceitos básicos do FabricPath. Especificamente, os usuários devem estar familiarizados com as FTAGs (Forwarding Tags) e como elas são usadas. Para obter mais informações sobre FTAGs, consulte Mapeando a Árvore Multidestino para um FTAG.

Note: Os termos FTAG, Árvores e Árvores FTAG são usados como sinônimos neste documento. No momento em que este documento foi escrito, apenas FTAG1 e FTAG2 foram implementados. Pode haver mais GTAGs no futuro.

Componentes Utilizados

As informações neste documento são baseadas no Nexus 7000. Alguns comandos podem variar em outras plataformas Nexus, mas os conceitos permanecerão os mesmos.

Topologia

Note: Essa é apenas uma topologia parcial. Há outro Spine1 conectado a Spine2 e Leaf1 e Leaf2, mas ele é excluído deste documento para simplificar. Spine1 é a raiz de FTAG1 e Spine2 é a raiz de FTAG2.

Informações de Apoio

Em um domínio FabricPath, cada switch é identificado por um ID de switch (SID). No caso de uma configuração do Virtual Port Channel+ (vPC+), cada switch peer tem dois SIDs. Um para o switch físico e outro para o switch lógico formado pelo vPC+. O SID lógico é compartilhado em ambos os pares e é conhecido como ESID.

Quando um pacote multidestino é recebido em uma interface vPC+ e encaminhado para o domínio FabricPath, o pacote é encapsulado com um cabeçalho FabricPath e o SID de origem é definido como ESID. Quando esse pacote é recebido em uma porta central do FabricPath, uma verificação de RPF é executada para garantir que o pacote seja recebido na interface correta. Resumindo, a verificação RPF faz referência ao SID e FTAG de origem do pacote para a interface em que ele foi recebido. Se não foi recebido na interface RPF, o pacote falha na verificação RPF e é descartado.

As verificações de RPF só entram em execução para pacotes multidestino que incluem pacotes desconhecidos unicast, multicast e broadcast. As verificações de RPF não são executadas em pacotes unicast porque podem vir em várias interfaces com vários caminhos de custo igual. Os pacotes multidestino devem vir somente em uma interface por SID de origem com base na árvore FTAG.

Neste documento, a verificação RPF de um ESID é investigada. Um ESID representa um domínio vPC+. Isso significa que é um switch lógico que consiste em dois switches físicos. Se você considerar o diagrama de topologia, verá que há dois links físicos para um ESID, que normalmente é o caso. Lembre-se, a verificação RPF permite que somente pacotes multidestino sejam aceitos em uma interface baseada na árvore FTAG.

Procedimento

Etapa 1. Verificar o estado do RPF

Neste exemplo, Spine2 é a raiz de FTAG2. Primeiro, verifique Spine2 para obter a interface RPF atual para o ESID 34 e FTAG2. Há dois locais para verificar o status do RPF, que estão no software e no hardware. Ambas as saídas mostram que Eth4/41 é a interface RPF para FTAG2, ESID 34.

Verificação de software

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 

Verificação de hardware

Primeiro, determine o número VDC e o módulo que o pacote ingressa.

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

Em seguida, conecte-se ao módulo da interface de recebimento para verificar o estado do hardware.

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

Etapa 2. Verifique a afinidade do vPC+

Para entender por que Spine2 escolheu Eth4/41 para Leaf1 em vez de Eth4/45 para Leaf2 quando ambos fazem parte do ESID, você deve primeiro entender o conceito de afinidade.

Em uma configuração que não seja vPC+, os pacotes multidestino são encaminhados primariamente na primeira árvore na topologia, que é a Árvore1. Em um ambiente vPC+, cada árvore (FTAG1 ou FTAG2) tem uma afinidade para um ou outro switch par. Nessa situação, os quadros multicast de broadcast, unicast desconhecido e não IP atravessam a árvore para a qual o switch peer específico tem uma afinidade.

Você precisa verificar qual peer tem a afinidade para FTAG2. Para fazer isso, faça login em um dos switches leaf no domínio vPC+. A verificação pode ser feita a partir de um dos switches, pois ambos devem conhecer a afinidade de seus pares, assim como a sua própria.

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

Com essas informações, você pode ver que se um quadro multidestino for recebido no Leaf1, o switch o encaminhará pela árvore FTAG2. Se o quadro for recebido em Folha2, ele será encaminhado ao longo da árvore FTAG1.

Para obter mais informações sobre árvores FTAG, consulte Mapeando a Árvore Multidestino de um FTAG.

Essas informações são usadas no Spine2 para criar o estado de RPF para o ESID 34. Eth4/41 é usado como interface RPF para FTAG2 ESID 34. 

Seleção de afinidade

A afinidade FTAG é selecionada com este método:

• Há um sistema de classificação baseado no SID. O SID é derivado do pool de endereços MAC alocados ao chassi em questão.

• O ID de sistema mais baixo tem a classificação mais alta.

• O peer vPC+ com o menor ID de sistema e, portanto, a classificação mais alta, tem a afinidade para o FTAG1.

• O segundo ID de sistema mais baixo e, portanto, a segunda classificação mais alta, tem a afinidade para o FTAG2.

Conclusão

O estado RPF é construído de acordo com o estado de afinidade vPC+ em cada peer. A interface RPF para um ESID para um FTAG específico é a interface que se conecta ao switch peer com a afinidade.