aci concetto di bridge-domain pervasive gateway capability and glean packet

Home » Blog » Switching » Software-Defined » aci application centric infrastructure » aci funzionalità » aci concetto di bridge-domain pervasive gateway capability and glean packet

aci concetto di bridge-domain pervasive gateway capability and glean packet

07.01 2020 | by massimiliano

ACI concetto di Bridge-Domain, pervasive gateway and glean packet     Un bridge-domain è un dominio logico layer 2 per […]


https://www.ingegnerianetworking.com/wp-content/uploads/2020/01/pervasive-gateway-1-ee4.png

ACI concetto di Bridge-Domain, pervasive gateway and glean packet

 

 

Un bridge-domain è un dominio logico layer 2 per subnets che appartengono allo stessa rete broadcast; può essere paragonato ad un distributed switch nel quale un nodo Leaf può essere interpretato localmente come una vlan con significato locale.

Nessun protocollo di routing è abilitato al suo interno.

 

Per un routed BD (Bridge Domain) un layer 3 è abilitato attraverso la funzionalità di pervasive gateway capability.

 

Un ” pervasive gateway capability” permette di avere un virtual MAC address ed un virtual IP address in comune attraverso multiple Fabric ACI; quindi ciascun endpoint o devices appartenente ad uno specifico BD punta come default gateway all’indirizzo pervasive in comune (virtual IP)

 

Le regole, in ogni caso, prevedono di avere un IP address non virtuale per ogni Bridge Domain della Fabric ACI in modalità “on-top” al virtual IP Address (pervasive).

Questo IP address non virtuale dovrebbe essere nella stessa subnet dell’indirizzo IP virtuale e dovrebbe essere unico per ogni Fabrics ACI.

E’ inoltre richiesto di avere un indirizzo fisico MAC address (custom MAC address in APIC) in ciascun BD ed in ogni Fabric ACI in modalità “stretched”.

 

 

 

pervasive gateway 1 

 

 

 

 

1)  H1 trasmette un ARP request verso il Gateway VIP 172.16.1.200
     L1 risponde all’ARP con il vMAC

 

2)  H1 trasmette, quindi un pacchetto con Dest-MAC come vMAC e Dest-IP come 172.16.3.20

 

3)  L1 ruota il pacchetto verso il livello Spine Proxy
      Nota: ” quando un vMAC è configurato in un Bridge-Domain, un pacchetto avente come Dest-MAC l’indirizzo fisico (phy-MAC) non può essere ruotato perchè   l’indirizzo MAC router per il BD è quello del vMAC “

 

4)  Gli Spine non riuscendo a trovare una entry per l’indirizzo 172.16.3.20, inviano un “glean packets”

 

5)  BL4 trasmette un ARP request by glean packet verso l’indirizzo 172.16.3.20 con il MAC address phy-MAC-H1 come ARP-sender-MAC e Dest-IP l’indirizzo 172.16.3.1 come ARP-sender-IP.      # entrambe le coppie MAC/IP sono settate su indirizzi fisici, non virtuali
   BL1, quindi, impara l’indirizzo phy-MAC-H1 e l’IP 172.16.3.1

 

6)  Se l’indirizzo 172.16.3.20 non è stato ancora appreso:
     BL4 invia una richiesta ARP verso il livello di Spine Proxy e trasmette un glean packet per l’indirizzo 172.16.3.20 affinchè sia imparato come end-point
     Di seguito, BL4 invia una richiesta ARP verso H2

 

     Se la funzionalità di ARP Flood è abilitata:
     BL1 invia una richiesta ARP trasmessa verso H2

 

7) H2 risponde con un ARP reply con Dest-MAC il phy-MAC-H1, Dest-IP l’indirizzo 172.16.3.1, il Source-MAC come phy-MAC-H2 e Source-IP come 172.16.3.20
    L4 impara il phy-MAC-H2, l’indirizzo IP 172.16.3.20 ed aggiorna la tabella COOP (database mapping) a livello Spine in ACI Fabric-B

 

8) L4 bridges il pacchetto verso BL1

 

9) BL1 bridge il pacchetto verso BL4
    BL4 impara l’indirizzo phy-MAC-H2, l’IP 172.16.3.20 ed aggiorna la tabella COOP (database mapping) a livello Spine in ACI Fabric-A

 

 

Di conseguenza i pacchetti da nodo H1 sono ruotati verso la Fabric-B attraverso BL4
BL4 trasmette questi pacchetti in L2-out mode con Source-MAC come phy-MAC-H1 e Dest-MAC come phy-MAC-H2

 

 

 

 

 

 

Torna in alto