Switches : Switches Cisco Nexus 7000 Series

Verificação do encaminhamento de caminho reverso de FabricPath para um Interruptor-ID emulado VPC+

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como determinar que relação a se usar para a verificação do encaminhamento de caminho reverso (RPF) com um Interruptor-ID emulado (ESID).

Contribuído pelo Al Bryant, engenheiro de TAC da Cisco.

Prerequsities

Requisitos

Cisco recomenda que você tem a terminologia e os conceitos de FabricPath do conhecimento do gerenciamento de recursos básicos. Especificamente, os usuários devem ser familiares com as etiquetas da transmissão (FTAGs) e como são usados. Para obter mais informações sobre de FTAGs, veja o traço para fora da árvore com destinos múltiplos para um FTAG.

Nota: Os termos FTAG, as árvores, e as árvores FTAG são usados permutavelmente neste documento. Então este documento foi redigido, simplesmente FTAG1 e FTAG2 foram executados. Pôde haver FTAGs adicional no futuro.

Componentes Utilizados

A informação neste documento é baseada no nexo 7000. Alguns comandos puderam variar em outras Plataformas do nexo, mas os conceitos permanecerão os mesmos.

Topologia

Nota: Esta é somente uma topologia parcial. Há uns outros Spine1 conectados a Spine2 e Leaf1 e Leaf2, mas é excluído deste documento para a simplicidade. Spine1 é a raiz para FTAG1 e Spine2 é a raiz para FTAG2.

Informações de Apoio

Em um domínio de FabricPath, cada interruptor é identificado por um interruptor-ID (SID). No caso de uma porta virtual Channel+ (vPC+) setup, cada interruptor do par tem dois SID. Um para o interruptor físico e um para o interruptor lógico que é formado por vPC+. SID lógico é compartilhado em ambos os pares e sabido como um ESID.

Quando um pacote com destinos múltiplos é recebido em uma relação vPC+ e enviado no domínio de FabricPath, o pacote está encapsulado com um encabeçamento de FabricPath e a fonte SID é ajustada ao ESID. Uma vez que este pacote é recebido em uma porta do núcleo de FabricPath, uma verificação RPF está executada a fim assegurar-se de que o pacote esteja recebido na relação correta. Em curto, a verificação RPF faz remissão recíproca a fonte SID e FTAG do pacote à relação que foi recebido sobre. Se não foi recebida na relação RPF, o pacote falha a verificação RPF e é deixado cair.

As verificações RPF entram somente o jogo para os pacotes com destinos múltiplos que incluem o unicast desconhecido, o Multicast, e os pacotes de transmissão. As verificações RPF não são executadas em pacotes do unicast porque podem vir nas interfaces múltiplas com o Multi-Pathing dos custos iguais. Os pacotes com destinos múltiplos devem somente vir em uma relação pela fonte SID baseado na árvore FTAG.

Neste documento, a verificação RPF para um ESID é investigada. Um ESID representa um domínio vPC+. Isto significa que é um interruptor lógico que consiste em dois Switches físicos. Se você considera o diagrama de topologia, você verá que há dois enlaces físicos a um ESID que são tipicamente o caso. Recorde, a verificação RPF permite somente que os pacotes com destinos múltiplos sejam aceitados em uma relação baseada na árvore FTAG.

Procedimento

Etapa 1. Verifique o estado RPF

Neste exemplo, Spine2 é a raiz para FTAG2. Primeiramente, verificação Spine2 para a relação atual RPF para o ESID 34 e FTAG2. Há dois lugares para verificar o estado RPF, que estão no software e no hardware. Ambas as saídas mostram aquela que Eth4/41 é a relação RPF para FTAG2, ESID 34.

Verificação do 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

Primeiramente, determine o número VDC e o módulo os ingressos do pacote.

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

Então, anexo ao módulo da relação de recepção a fim verificar o estado de 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 vPC+

A fim compreender porque Spine2 escolheu Eth4/41 a Leaf1 em vez de Eth4/45 a Leaf2 quando ambos são parte dos ESID, você deve primeiramente compreender o conceito de uma afinidade.

Em uma instalação non-vPC+, os pacotes com destinos múltiplos são enviados primeiramente na primeira árvore na topologia, que é Tree1. Em um ambiente vPC+, cada árvore (FTAG1 ou FTAG2) tem uma afinidade para outro um ou interruptor do par. Nesta situação, a transmissão, o unicast desconhecido, e os frames de transmissão múltipla não-IP atravessam a árvore para que o interruptor do peer particular tem uma afinidade.

Você precisa de verificar que par tem a afinidade para FTAG2. A fim fazer isto, o início de uma sessão a uma da folha comuta no domínio vPC+. A verificação pode ser feita de um ou outro interruptor do par porque ambos devem conhecer as seus próprias do seu par a afinidade assim como.

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 esta informação você pode ver aquele se um quadro com destinos múltiplos é recebido em Leaf1, o interruptor para a frente ele ao longo da árvore FTAG2. Se o quadro é recebido em Leaf2, está enviado ao longo da árvore FTAG1.

Para obter mais informações sobre das árvores FTAG, veja o traço para fora da árvore com destinos múltiplos para um FTAG.

Esta informação é usada em Spine2 a fim construir o estado RPF para o ESID 34. Este é Eth4/41 é usado como a relação RPF para FTAG2 ESID 34. 

Seleção da afinidade

A afinidade FTAG é selecionada com este método:

  • Há uma classificação por análise de sistemas fora de SID. SID é derivado do pool dos endereços MAC atribuídos ao chassi na pergunta.

  • O mais baixo ID de sistema tem o grau o mais alto.

  • O par vPC+ com o mais baixo ID de sistema, e consequentemente o grau o mais alto, têm a afinidade para o FTAG1.

  • O segundo mais baixo ID de sistema, e consequentemente o grau em segundo o mais alto, têm a afinidade para o FTAG2.

Conclusão

O estado RPF é construído de acordo com o estado da afinidade vPC+ em cada par. A relação RPF a um ESID para um FTAG dado é a relação que conecta ao interruptor do par com a afinidade.



Document ID: 117297