Inoltro basato su L2MP su collegamento peer vPC in switch Carmel ASIC (Nexus 5548/5596)

Introduzione

Nelle topologie vPC il traffico degli utenti verrà visualizzato su peer-link solo per il traffico delle porte orfane o il traffico a flusso continuo (unicast sconosciuto, broadcast, multicast). Per questo traffico di allagamento, è necessario che gli switch assicurino che il traffico di allagamento ricevuto su una gamba del vPC non venga rimandato indietro sull'altra gamba del vPC in modo che i pacchetti non vengano rimandati all'origine o duplicati su altri vPC.

Negli switch con Carmel (Nexus 55xx), l'implementazione della funzione di prevenzione del loop vPC è diversa dall'implementazione basata su Gatos (Nexus 5010/5020), che utilizza una VLAN MCT interna separata per il traffico eccessivo su peer-link.

Poiché gli switch Carmel supportano L2MP o fabricpath, la progettazione ha deciso di utilizzare l'inoltro basato su L2MP sul collegamento peer. Con questo modello, lo switch primario vPC avrà un ID switch di 2748(0xabc), mentre lo switch secondario vPC avrà un ID switch di 2749(0xabd). L'id dello switch emulato di 2750(0xabe) verrà usato come id dello switch di origine per i frame in entrata in un vPC ma inviati attraverso il collegamento peer. Tutte le porte sullo switch primario vPC saranno membri di FTAG 256, mentre quelle sullo switch secondario vPC saranno membri di FTAG 257. Nello switch primario vPC, solo le porte orfane saranno membri di FTAG 257, mentre nello switch secondario vPC, le porte orfane saranno membri di FTAG 256.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prevenzione dei loop

Per i frame unicast/multicast broadcast/sconosciuti che entrano nello switch primario vPC, verranno inviati con un FTAG di 256 attraverso il collegamento peer. Quando lo switch secondario vPC riceve questo frame sul collegamento peer vPC, controlla il FTAG e, a partire dal suo 256, lo switch secondario vPC lo invia solo ai membri FTAG 256 che saranno solo porte orfane. Per il traffico di flood dal vPC secondario, verrà inviato con FTAG di 257 e quando lo switch primario vPC ottiene questo frame, invierà il frame di flood ricevuto solo ai membri di FTAG 257 che saranno solo porte orfane. In questo modo gli switch basati su Carmel implementano la prevenzione del loop vPC.

Per l'inoltro in profondità basato su L2MP/FTAG dei frame di flood attraverso il collegamento peer, viene utilizzata questa topologia:

N5K-C5596UP-109 e N5K-C5596UP-100 sono due switch Nexus 5596 con NX-OS 5.2(1)N1(2a). N5K-C5596UP-109 è lo switch primario vPC e N5K-C5596UP-110 è lo switch secondario vPC. Port-channel 1 è il collegamento peer vPC. Gli indirizzi IP mostrati appartengono all'interfaccia VLAN 1 degli switch. L'host 1 e l'host 2 sono switch Cisco connessi tramite vPC nella VLAN 1. In questo documento, questi switch sono denominati host 1 e host 2. La VLAN 1 è collegata alla porta orfana Eth1/32 su entrambi gli switch.

Di seguito sono riportati alcuni output dei comandi dagli switch:

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

Test 1: Trasmissione del traffico ARP in entrata nel sistema secondario vPC

Viene eseguito il ping di un indirizzo IP 192.168.1.199 inesistente dall'host 1 (192.168.1.101). Per questo motivo, l'host 1 continua a inviare una richiesta ARP di trasmissione in cui viene chiesto "chi è 192.168.1.199". L'host 1 esegue l'hashing di questo traffico di trasmissione allo switch secondario vPC N5K-C5596UP-110, che a sua volta lo invia a tutte le porte della VLAN 1, inclusa la Po1, che è il collegamento peer vPC.

Viene acquisita una SPAN TX del Port-channel 1 per osservare le intestazioni dei percorsi fabric di questa trasmissione ARP che è un frame multidestinazione nella terminologia FP. Osservare l'intestazione del percorso di struttura di questo frame con più destinazioni.

• Poiché il frame entra tramite un vPC(vPC 111), l'ID dello switch di origine è superiore a 0,00.0000.

• La destinazione è un MAC broadcast FF:FF:FF:FF:FF

• FTAG è 257.

Quando questo frame entra nello switch primario vPC, ispeziona il FTAG 257. Poiché solo le porte orfane sono membri del FTAG 257, questo frame ARP broadcast verrà inviato solo a Eth 1/32.

Test 2: Frame unicast sconosciuto in ingresso nel sistema secondario vPC

Per introdurre il traffico unicast sconosciuto, sull'host 1 ho configurato un ARP statico per 192.168.1.99 con un MAC statico di 0001.0002.0003 ed eseguo un ping fino a 192.168.1.99. La richiesta echo ICMP arriva all'indirizzo N5K-C5596UP-110 e non sa dove si trovi l'indirizzo MAC 0001.0002.003 e inonda questo frame nella VLAN, incluso il peer-link.

Viene acquisita una SPAN TX del Port-channel 1 per osservare le intestazioni del percorso della struttura di questo frame di flood unicast sconosciuto, che è un frame di multi-destinazione nella terminologia FP. Osservare l'intestazione del percorso di struttura di questo frame con più destinazioni.

• Poiché il frame entra tramite un vPC(vPC 111), l'ID dello switch di origine è superiore a 1.00.0000

• La destinazione è un MAC multicast 01:bb:cc:dd:01:01

• FTAG è 257.

Quando il frame entra nello switch primario vPC, viene ispezionato il FTAG 257. Poiché solo le porte orfane sono membri del FTAG 257, il frame principale vPC invierà il frame solo alla porta orfana Eth 1/32.

A causa del meccanismo sopra descritto, di seguito viene riportato il flusso del traffico in ingresso nello switch secondario vPC.

Test 3: Traffico ARP di trasmissione in ingresso nel sistema primario vPC

Viene eseguito il ping di un indirizzo IP 192.168.1.200 inesistente dall'host 2(192.168.1.69). Per questo motivo, l'host 2 continua a inviare una richiesta ARP di trasmissione in cui viene chiesto "chi è 192.168.1.200". L'host 2 esegue l'hashing di questo traffico di trasmissione allo switch primario vPC N5K-C5596UP-109, che a sua volta lo invia a tutte le porte della VLAN 1, inclusa la Po1 che è il collegamento peer vPC.

Viene acquisita una SPAN TX del Port-channel 1 per osservare le intestazioni dei percorsi fabric di questa trasmissione ARP che è un frame multidestinazione nella terminologia FP. Osservare l'intestazione del percorso di struttura di questo frame con più destinazioni.

• Poiché il frame entra tramite un vPC(vPC 200), l'ID dello switch di origine è superiore a 1.00.0000

• La destinazione è un MAC broadcast FF:FF:FF:FF:FF

• FTAG è 256.

Quando questo frame entra nello switch secondario vPC, ispeziona il FTAG 256. Poiché solo le porte orfane sono membri del FTAG 256, questo frame ARP broadcast verrà inviato solo a Eth 1/32.

Test 4: Frame unicast sconosciuto in ingresso nel sistema primario vPC

Per introdurre il traffico unicast sconosciuto, sull'host 2 viene configurato un ARP statico per 192.168.1.200 con un MAC statico di 0003.0004.0005 e viene eseguito il ping di 192.168.1.200. La richiesta echo ICMP si hash sul server primario vPC N5K-C5596UP-109 e, poiché non sa dove si trovi MAC 0003.0004.0005, inonda questo frame nella VLAN, incluso il peer-link. Viene acquisita una SPAN TX del Port-channel 1 per osservare le intestazioni del percorso della struttura di questo frame di flood unicast sconosciuto che è un frame di multi-destinazione nella terminologia FP. Osservare l'intestazione del percorso di struttura di questo frame con più destinazioni.

• Poiché il frame entra tramite un vPC(vPC 200), l'ID dello switch di origine è superiore a 1.00.0000

• La destinazione è un MAC multicast 01:bb:cc:dd:01:01 utilizzato per flooding unicast sconosciuti

• FTAG è 256.

Quando questo frame entra nello switch secondario vPC, ispeziona il FTAG 257. Poiché solo le porte orfane sono membri del FTAG 256, il frame principale vPC invierà questo frame solo alla porta orfana Eth 1/32.

A causa del meccanismo descritto sopra, di seguito viene riportato il flusso del traffico in entrata nello switch primario vPC.

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems