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 qué interfaz utilizar para la verificación Reverse Path Forwarding (RPF) con un ID de switch emulado (ESID).

Prioridades

Requirements

Cisco recomienda que conozca la terminología y los conceptos básicos de FabricPath. En concreto, los usuarios deben estar familiarizados con las etiquetas de reenvío (FTAG) y el modo en que se utilizan. Para obtener más información sobre las FTAG, vea Mapping Out the Multidestination Tree for a FTAG.

Nota: Los términos FTAG, Trees y FTAG Trees se utilizan indistintamente en este documento. En el momento de escribir este documento, sólo se han implementado FTAG1 y FTAG2. En el futuro podría haber otros FTAG.

Componentes Utilizados

La información de este documento se basa en el Nexus 7000. Algunos comandos pueden variar en otras plataformas Nexus, pero los conceptos seguirán siendo los mismos.

Topología

Nota: Esta es sólo una topología parcial. Hay otro Spine1 conectado a Spine2 y a Leaf1 y Leaf2, pero se excluye de este documento por simplicidad. Spine1 es la raíz para FTAG1 y Spine2 es la raíz para FTAG2.

Antecedentes

En un dominio FabricPath, cada switch se identifica mediante un ID de switch (SID). En el caso de una configuración de Virtual Port Channel+ (vPC+), cada switch de par tiene dos SID. Uno para el switch físico y otro para el switch lógico formado por vPC+. El SID lógico se comparte en ambos pares y se conoce como ESID.

Cuando se recibe un paquete multidestino en una interfaz vPC+ y se reenvía al dominio FabricPath, el paquete se encapsula con un encabezado FabricPath y el SID de origen se establece en el ESID. Una vez que este paquete se recibe en un puerto de núcleo de FabricPath, se realiza una verificación RPF para asegurarse de que el paquete se recibió en la interfaz correcta. En resumen, la verificación RPF hace referencia cruzada al SID de origen y FTAG del paquete con la interfaz en la que se recibió. Si no se recibió en la interfaz RPF, el paquete falla la verificación RPF y se descarta.

Las verificaciones RPF sólo entran en juego para los paquetes de destino múltiple que incluyen paquetes de unidifusión, multidifusión y difusión desconocidos. Las verificaciones de RPF no se realizan en los paquetes de unidifusión porque pueden venir en varias interfaces con Multi-Pathing de Costo Igual. Los paquetes de destino múltiple sólo deben venir en una interfaz por SID de origen basado en el árbol FTAG.

En este documento, se investiga la verificación RPF de un ESID. Un ESID representa un dominio vPC+. Esto significa que es un switch lógico que consta de dos switches físicos. Si considera el diagrama de topología, verá que hay dos links físicos a un ESID, lo que suele ser el caso. Recuerde, la verificación RPF sólo permite que los paquetes multidestino sean aceptados en una interfaz basada en el árbol FTAG.

Procedimiento

Paso 1. Verifique el estado de RPF

En este ejemplo, Spine2 es la raíz para FTAG2. Primero, verifique Spine2 para la interfaz RPF actual para ESID 34 y FTAG2. Hay dos lugares para verificar el estado de RPF, que están en el software y en el hardware. Ambos resultados muestran que Eth4/41 es la interfaz RPF para FTAG2, ESID 34.

Comprobación 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 

Comprobación de hardware

Primero, determine el número VDC y el módulo que ingresa el 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

Luego, conecte al módulo de la interfaz receptora para verificar el 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. Compruebe la afinidad de vPC+

Para entender por qué Spine2 eligió Eth4/41 a Leaf1 en lugar de Eth4/45 a Leaf2 cuando ambos son parte del ESID, primero debe entender el concepto de afinidad.

En una configuración que no sea vPC+, los paquetes de varios destinos se reenvían principalmente en el primer árbol de la topología, que es Tree1. En un entorno vPC+, cada árbol (FTAG1 o FTAG2) tiene afinidad por uno u otro switch de par. En esta situación, las tramas de difusión, unidifusión desconocida y multidifusión no IP atraviesan el árbol para el cual el switch de peer determinado tiene una afinidad.

Debe verificar qué par tiene la afinidad por FTAG2. Para hacerlo, inicie sesión en uno de los switches de hoja del dominio vPC+. La verificación se puede realizar desde cualquier switch de peer porque ambos deberían conocer la afinidad de su par así como la suya propia.

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 puede ver que si se recibe una trama de destino múltiple en Leaf1, el switch la reenvía a lo largo del árbol FTAG2. Si la trama se recibe en Leaf2, se reenvía a lo largo del árbol FTAG1.

Para obtener más información sobre los árboles FTAG, vea Mapping Out the Multidestination Tree for a FTAG.

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

Selección de afinidad

La afinidad FTAG se selecciona con este método:

• Hay un sistema de clasificación basado en el SID. El SID se deriva del conjunto de direcciones MAC asignadas al chasis en cuestión.

• El ID de sistema más bajo tiene el rango más alto.

• El par vPC+ con la ID de sistema más baja y, por lo tanto, el rango más alto, tiene la afinidad por FTAG1.

• El segundo ID de sistema más bajo, y por lo tanto el segundo rango más alto, tiene la afinidad por el FTAG2.

Conclusión

El estado de RPF se genera de acuerdo con el estado de afinidad de vPC+ en cada peer. La interfaz RPF a un ESID para un FTAG dado es la interfaz que se conecta al switch de peer con la afinidad.