Verificación de Reenvío de Trayectoria Inversa de FabricPath para un ID de Switch Emulado VPC+

Introducción

Este documento describe cómo determinar que interconectan para utilizar para el control del reenvío de trayecto inverso (RPF) con un Switch-ID emulado (ESID).

Prerequsities

Requisitos

Cisco recomienda que usted tiene la terminología y conceptos de FabricPath del conocimietno básico. Específicamente, los usuarios deben ser familiares con las etiquetas de la expedición (FTAGs) y cómo los utilizan. Para más información sobre FTAGs, vea el proyecto del árbol polivalente para un FTAG.

Note: Los términos FTAG, los árboles, y los árboles FTAG se utilizan alternativamente en este documento. Cuando este documento fue escrito, sólo se han implementado FTAG1 y FTAG2. Pudo haber FTAGs adicional en el futuro.

Componentes Utilizados

La información en este documento se basa en el nexo 7000. Algunos comandos pudieron variar en otras Plataformas del nexo, pero los conceptos seguirán siendo lo mismo.

Topología

Note: Esto es solamente una topología parcial. Hay otros Spine1 conectados con Spine2 y Leaf1 y Leaf2, pero se excluye de este documento para la simplicidad. Spine1 es la raíz para FTAG1 y Spine2 es la raíz para FTAG2.

Antecedentes

En un dominio de FabricPath, cada Switch es identificado por un Switch-ID (SID). En el caso de un puerto virtual Channel+ (vPC+) puesto, cada Switch del par tiene dos SID. Uno para el Switch físico y uno para el Switch lógico que es formado por vPC+. El SID lógico se comparte en ambos pares y se conoce como ESID.

Cuando un paquete polivalente se recibe en una interfaz vPC+ y se remite en el dominio de FabricPath, el paquete se encapsula con una encabezado de FabricPath y la fuente SID se fija al ESID. Una vez que este paquete se recibe en un puerto de la base de FabricPath, revisión de "RPF" se realiza para asegurarse que el paquete fue recibido en la interfaz correcta. En fin, revisión de "RPF" hace una remisión la fuente SID y FTAG del paquete a la interfaz que fue recibida encendido. Si no fue recibida en la interfaz RPF, el paquete falla revisión de "RPF" y se cae.

Los controles RPF entran en solamente el juego para los paquetes polivalentes que incluyen la unidifusión desconocida, el Multicast, y los paquetes de broadcast. Los controles RPF no se realizan en los paquetes de unidifusión porque pueden venir en las interfaces múltiples con la Multi-dirección del igual costo. Los paquetes polivalentes deben venir solamente en una interfaz por la fuente SID basada en el árbol FTAG.

En este documento, revisión de "RPF" para un ESID se investiga. Un ESID representa un dominio vPC+. Esto significa que es un Switch lógico que consiste en dos Switches físico. Si usted considera el Diagrama de topología, usted verá que hay dos vículos físicos a un ESID que es típicamente el caso. Recuerde, revisión de "RPF" permite solamente que los paquetes polivalentes sean validados en una interfaz basada en el árbol FTAG.

Procedimiento

Paso 1. Marque el estado RPF

En este ejemplo, Spine2 es la raíz para FTAG2. Primero, control Spine2 para la interfaz actual RPF para el ESID 34 y FTAG2. Hay dos lugares para marcar el estatus RPF, que están en el software y en el hardware. Ambas salidas muestran que ese Eth4/41 es la interfaz RPF para FTAG2, ESID 34.

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

Control de hardware

Primero, determine el número VDC y el módulo los ingresos del paquete.

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

Entonces, fijación al módulo de la interfaz de recepción para marcar al estado del 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
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Paso 2. Marque la afinidad vPC+

Para entender porqué Spine2 eligió Eth4/41 a Leaf1 en vez de Eth4/45 a Leaf2 cuando ambas son parte del ESID, usted debe primero entender el concepto de una afinidad.

En una configuración non-vPC+, los paquetes polivalentes se remiten sobre todo en el primer árbol en la topología, que es Tree1. En un entorno vPC+, cada árbol (FTAG1 o FTAG2) tiene una afinidad para un u otro Switch del par. En esta situación, el broadcast, la unidifusión desconocida, y las tramas de multidifusión del no IP atraviesan el árbol para el cual el Switch del peer particular tiene una afinidad.

Usted necesita marcar qué par tiene la afinidad para FTAG2. Para hacer esto, login a uno del Switches de la hoja en el dominio vPC+. El control se puede hacer de cualquier Switch del par porque ambos deben conocer la afinidad así como sus la propio de su par.

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

Con esta información usted puede ver que si una trama polivalente se recibe en Leaf1, el Switch adelante él a lo largo del árbol FTAG2. Si la trama se recibe en Leaf2, se remite a lo largo del árbol FTAG1.

Para más información sobre los árboles FTAG, vea el proyecto del árbol polivalente para un FTAG.

Esta información se utiliza en Spine2 para construir el estado RPF para el ESID 34. Éste es Eth4/41 se utiliza como la interfaz RPF para FTAG2 ESID 34. 

Selección de la afinidad

La afinidad FTAG se selecciona con este método:

• Hay una graduación basada en el estudio de sistemas apagado del SID. El SID se deriva del pool de las direcciones MAC afectadas un aparato al chasis en la pregunta.

• El ID del sistema más bajo tiene la fila más alta.

• El par vPC+ con el ID del sistema más bajo, y por lo tanto la fila más alta, tiene la afinidad para el FTAG1.

• El segundo ID del sistema más bajo, y por lo tanto la fila en segundo lugar más alta, tiene la afinidad para el FTAG2.

Conclusión

El estado RPF se construye de acuerdo con el estado de la afinidad vPC+ en cada par. La interfaz RPF a un ESID para un FTAG dado es la interfaz que conecta con el Switch del par con la afinidad.