En las topologías de vPC, el tráfico de usuario se verá en el link de par solamente para el tráfico de puerto huérfano o el tráfico saturado (unidifusión desconocida, difusión, multidifusión). Para este tráfico de inundación, existe el requisito de que los switches se aseguren de que el tráfico de inundación recibido en un segmento del vPC no se envíe de vuelta en el otro tramo vPC, de modo que los paquetes no se envíen de vuelta al origen o se dupliquen en otros vPC.
En los switches basados en Carmel (Nexus 55xx), la implementación para evitar loops de vPC es diferente en comparación con la implementación basada en Gatos (Nexus 5010/5020) que utiliza una VLAN de MCT interna independiente para el tráfico inundado a través del link de peer.
Debido a que los switches basados en Carmel admiten L2MP o ruta de fabricación, la ingeniería decidió utilizar el reenvío basado en L2MP a través del link de peer. Con este modelo, el switch principal vPC tendrá un switch-id de 2748(0xabc) mientras que el vPC secundario tendrá un switch-id de 2749(0xabd). El switch-id emulado de 2750(0xabe) se utilizará como switch-id de origen para las tramas que ingresan a un vPC pero se envían a través del link de par. Todos los puertos en el vPC primario serán miembros de FTAG 256, mientras que en el vPC secundario serán miembros de FTAG 257. En el switch principal vPC, sólo los puertos huérfanos serán miembros del FTAG 257 mientras que en el switch secundario vPC, los puertos huérfanos serán miembros del FTAG 256.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Para las tramas de difusión/unidifusión/multidifusión desconocida que ingresan al switch principal vPC, se enviarán con un FTAG de 256 a través del link de peer. Cuando el switch secundario vPC obtiene esta trama a través del enlace de par vPC, inspecciona el FTAG y, desde su 256, el switch secundario vPC sólo la enviará a los miembros FTAG 256 que serán puertos huérfanos solamente. Para el tráfico de inundación de vPC secundario, se enviará con FTAG de 257 y cuando el switch principal vPC obtenga esta trama, envía la trama de inundación recibida solamente a los miembros de FTAG 257 que serán solamente puertos huérfanos. Así es como los switches basados en Carmel implementan la prevención del loop de vPC.
Para profundizar el reenvío basado en L2MP/FTAG de tramas de inundación a través del link de peer, se utiliza esta topología:
N5K-C5596UP-109 y N5K-C5596UP-100 son un par de vPC de switches Nexus 5596 que ejecutan NX-OS 5.2(1)N1(2a). N5K-C5596UP-109 es el switch principal vPC y N5K-C5596UP-110 es el switch secundario vPC. Port-channel 1 es el enlace de par vPC. Las direcciones IP mostradas pertenecen a la interfaz VLAN 1 de los switches. El Host 1 y el Host 2 son switches Cisco conectados a través de vPC en VLAN 1. Estos se llaman host 1 y host 2 en este documento. Hay un puerto huérfano en la VLAN 1 conectado a Eth1/32 en ambos switches.
A continuación se muestra el resultado de algunos comandos de los switches:
N5K-C5596UP-109# show vpc Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 2 Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : primary Number of vPCs configured : 2 Peer Gateway : Enabled Peer gateway excluded VLANs : - Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 Po1 up 1 vPC status ---------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans ------ ----------- ------ ----------- -------------------------- ----------- 111 Po111 up success success 1 200 Po200 up success success 1 N5K-C5596UP-109# show platform fwm info l2mp myswid switch id ------------------------------------------------------------------- switch id manager ------------------------------------------------------------------- vpc role: 0 my primary switch id: 2748 (0xabc) emu switch id: 2750 (0xabe) peer switch id: 2749 (0xabd) N5K-C5596UP-109# show vpc orphan-ports Note: --------::Going through port database. Please be patient.::-------- VLAN Orphan Ports ------- ------------------------- 1 Eth1/32 N5K-C5596UP-110# show vpc Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 2 Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : secondary Number of vPCs configured : 2 Peer Gateway : Enabled Peer gateway excluded VLANs : - Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 Po1 up 1 vPC status ---------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans ------ ----------- ------ ----------- -------------------------- ----------- 111 Po111 up success success 1 200 Po200 up success success 1 N5K-C5596UP-110# show platform fwm info l2mp myswid switch id ------------------------------------------------------------------- switch id manager ------------------------------------------------------------------- vpc role: 1 my primary switch id: 2749 (0xabd) emu switch id: 2750 (0xabe) peer switch id: 2748 (0xabc) N5K-C5596UP-110# show vpc orphan-ports Note: --------::Going through port database. Please be patient.::-------- VLAN Orphan Ports ------- ------------------------- 1 Eth1/32 Now lets check on default FTAGs used and its members. N5K-C5596UP-109# show platform fwm info l2mp ftag all L2MP FTAG ------------------------------------------------------------------- ftag[0x9565b1c] id: 256 (0x100) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x973eca4] ifindex array: 0x160000c7 0x1600006e 0x1a01f000 0x15010000 0x15020000 0x1600007e 0x16000000 ifmap[0x88400fc] ifmap idx 6: ref 1, lu_mcq_alloced 0, lu_mcq 15 (orig 15) 'not pruned' ifmap idx 6: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 6: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 6: ifs - sup-eth1 sup-eth2 Po200 Po1 Po111 Eth1/32 Po127 rpf: (0x0) alternate: 0 intf: Po1 (0x16000000) ftag_ucast_index: 1 ftag_flood_index: 1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 ------------------------------------------------------------------- ftag[0x9565e3c] id: 257 (0x101) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x95612b4] ifindex array: 0x1a01f000 0x15010000 0x15020000 0x16000000 ifmap[0x883b81c] ifmap idx 11: ref 1, lu_mcq_alloced 0, lu_mcq 14 (orig 14) 'not pruned' ifmap idx 11: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 11: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 11: ifs - sup-eth1 sup-eth2 Po1 Eth1/32 rpf: (0x0) alternate: 1 intf: Po1 (0x16000000) ftag_ucast_index: 0 ftag_flood_index: -1 ftag_mcast_index: 0 ftag_alt_mcast_index: 0 ------------------------------------------------------------------- N5K-C5596UP-109# N5K-C5596UP-110# show platform fwm info l2mp ftag all L2MP FTAG ------------------------------------------------------------------- ftag[0x956a99c] id: 256 (0x100) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x98b4764] ifindex array: 0x16000066 0x1a01f000 0x15010000 0x15020000 0x16000000 ifmap[0x9635adc] ifmap idx 4: ref 1, lu_mcq_alloced 0, lu_mcq 15 (orig 15) 'not pruned' ifmap idx 4: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 4: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 4: ifs - sup-eth1 sup-eth2 Po103 Po1 Eth1/32 rpf: (0x0) alternate: 1 intf: Po1 (0x16000000) ftag_ucast_index: 1 ftag_flood_index: -1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 ------------------------------------------------------------------- ftag[0x956acbc] id: 257 (0x101) Topology ID: 0x111 Ftag flags: 0 (invalid ftag-flags) Is stale: FALSE ftag_mask[0x97359bc] ifindex array: 0x160000c7 0x16000066 0x1600006e 0x1a01f000 0x15010000 0x15020000 0x1600007e 0x16000000 ifmap[0x95c624c] ifmap idx 7: ref 1, lu_mcq_alloced 0, lu_mcq 16 (orig 16) 'not pruned' ifmap idx 7: prune_ifmap 0, prune ref count 0, prune_unvisited 0 ifmap_idx 7: oifls_macg_ref_cnt 0, num_oifls 0 ifmap idx 7: ifs - sup-eth1 sup-eth2 Po200 Po103 Po1 Po111 Eth1/32 Po127 rpf: (0x0) alternate: 0 intf: Po1 (0x16000000) ftag_ucast_index: 0 ftag_flood_index: 1 ftag_mcast_index: 32 ftag_alt_mcast_index: 48 -------------------------------------------------------------------
Prueba 1: Tráfico ARP de difusión entrante en vPC secundario
Se hace ping a una IP 192.168.1.199 inexistente desde el host 1(192.168.1.101). Debido a esto, el host 1 continúa enviando una solicitud ARP de broadcast preguntando "quién es 192.168.1.199". El host 1 pasa a hash este tráfico de broadcast en el switch secundario vPC N5K-C5596UP-110, que a su vez lo inunda en todos los puertos en la VLAN 1, incluido Po1, que es el link de par vPC.
Se captura un SPAN TX de Port-channel 1 para ver los encabezados de trayectoria de entramado de esta difusión ARP que es una trama de destino múltiple en la terminología FP. Observe el encabezado de trayectoria de estructura de esta trama de destino múltiple.
Debido a que la trama ingresa a través de un vPC(vPC 111), el id del switch de origen es abe.00.0000.
El destino es un MAC de difusión FF:FF:FF:FF:FF
FTAG es 257.
Cuando esta trama entra en el switch principal vPC, inspeccionará el FTAG 257. Debido a que sólo los puertos huérfanos son miembros del FTAG 257, esta trama ARP de broadcast sólo se enviará al Eth 1/32.
Prueba 2: Trama de unidifusión desconocida entrando en el secundario vPC
Para introducir el tráfico unicast desconocido, en el host 1, configuré un ARP estático para 192.168.1.99 con un MAC estático de 0001.0002.0003 y hago un ping a 192.168.1.99. La solicitud de eco ICMP llega a N5K-C5596UP-110 y debido a que no sabe dónde está MAC 0001.0002.0003, inunda esta trama en la VLAN incluyendo el link de peer.
Se captura un SPAN TX de canal de puerto 1 para ver los encabezados de trayectoria de fabric de esta trama de inundación de unidifusión desconocida, que es una trama de destino múltiple en terminología FP. Observe el encabezado de trayectoria de estructura de esta trama de destino múltiple.
Dado que la trama ingresa a través de un vPC(vPC 111), el id del switch de origen es abe.00.0000
El destino es un MAC multicast 01:bb:cc:dd:01:01
FTAG es 257.
Cuando esta trama entra en el switch principal vPC, inspeccionará el FTAG 257. Debido a que sólo los puertos huérfanos son miembros del FTAG 257, este vPC primario inundará esta trama solamente en el puerto huérfano Eth 1/32.
Debido al mecanismo anterior, el siguiente es el flujo del tráfico inundado que llega al switch secundario vPC.
Prueba 3: Tráfico ARP de difusión entrante en vPC principal
Se hace ping a una IP 192.168.1.200 inexistente desde el host 2(192.168.1.69). Debido a esto, el host 2 continúa enviando una solicitud ARP de broadcast preguntando "quién es 192.168.1.200". El host 2 pasa a hash este tráfico de broadcast en el switch principal de vPC N5K-C5596UP-109, que a su vez lo inunda en todos los puertos en la VLAN 1, incluido Po1, que es el link de par de vPC.
Se captura un SPAN TX de Port-channel 1 para ver los encabezados de trayectoria de entramado de esta difusión ARP que es una trama de destino múltiple en la terminología FP. Observe el encabezado de trayectoria de estructura de esta trama de destino múltiple.
Como la trama ingresa a través de un vPC(vPC 200), el id del switch de origen es abe.00.0000
El destino es un MAC de difusión FF:FF:FF:FF:FF
FTAG es 256.
Cuando esta trama entra en el switch secundario vPC, inspeccionará el FTAG 256. Debido a que sólo los puertos huérfanos son miembros del FTAG 256, esta trama ARP de broadcast sólo se enviará al Eth 1/32.
Prueba 4: Trama de unidifusión desconocida entrante en vPC principal
Para introducir el tráfico unicast desconocido, en el host 2, se configura un ARP estático para 192.168.1.200 con un MAC estático de 0003.0004.0005 y 192.168.1.200 con ping. La solicitud de eco ICMP se desplaza al vPC primario N5K-C5596UP-109 y porque no sabe dónde está MAC 0003.0004.0005, inunda esta trama en la VLAN, incluido el link de peer. Se captura un SPAN TX de canal de puerto 1 para ver los encabezados de trayectoria de fabric de esta trama de inundación de unidifusión desconocida, que es una trama de destino múltiple en terminología FP. Observe el encabezado de trayectoria de estructura de esta trama de destino múltiple.
Como la trama ingresa a través de un vPC(vPC 200), el id del switch de origen es abe.00.0000
El destino es un MAC multicast 01:bb:cc:dd:01:01 que se utiliza para la inundación de unidifusión desconocida
FTAG es 256.
Cuando esta trama entra en el switch secundario vPC, inspeccionará el FTAG 257. Debido a que sólo los puertos huérfanos son miembros del FTAG 256, este vPC primario inundará esta trama solamente en el puerto huérfano Eth 1/32.
Debido al mecanismo anterior, el siguiente es el flujo del tráfico inundado que llega al switch principal vPC.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
03-Jul-2014 |
Versión inicial |