Informazioni su ARP Flooding e ARP Gleaning in ACI

Introduzione

Questo documento descrive l'utilizzo di ARP (Address Resolution Protocol) flooding e ARP gleaning nel fabric ACI (Application Centric Infrastructure).

Informazioni sulle inondazioni ARP

In Cisco ACI, è possibile usare l'opzione ARP flooding o disabilitarla quando necessario. È obbligatorio conoscere il comportamento del fabric per quanto riguarda l'allagamento ARP in modo da poter risolvere i problemi del layer 2.

Se l'inondazione ARP è abilitata, il traffico ARP viene inondato all'interno del fabric come avviene con la normale gestione ARP nelle reti tradizionali. Il flooding ARP è richiesto quando sono necessarie richieste GARP (Gratuitous ARP) per aggiornare le cache ARP dell'host o le cache ARP del router. Questo è il caso in cui un indirizzo IP può avere un indirizzo MAC diverso (ad esempio, con clustering del failover di bilanciatori di carico e firewall).

Se ARP flooding è disabilitato, il fabric tenta di utilizzare unicast per inviare il traffico ARP alla destinazione. Pertanto, viene eseguita una ricerca di layer 3 per l'indirizzo IP di destinazione del pacchetto ARP. ARP si comporta come un pacchetto unicast di layer 3 finché non raggiunge lo switch foglia di destinazione.

Poi, vedete alcuni casi d'uso relativi all'uso di ARP flooding.

Caso di utilizzo 1. Gli endpoint vengono appresi in ACI

Questo caso di utilizzo si verifica quando entrambi gli endpoint sono noti allo switch foglia.

In questo scenario non c'è alcun ruolo delle inondazioni ARP. Il traffico viene commutato localmente quando lo switch foglia conosce le informazioni sull'endpoint. Questo comportamento è lo stesso quando un endpoint, ad esempio H1, invia una richiesta ARP verso l'altro (H2) e l'allagamento ARP viene disabilitato. Poiché lo switch foglia sa dove è collegato H2 e controlla l'indirizzo IP di destinazione ARP (che è un indirizzo IP H2), non è necessario inondare il traffico o reindirizzarlo allo strato dorsale. Pertanto, invia la richiesta ARP verso H2. 

A prescindere dalle impostazioni di End-Point Group (EPG), Bridge domain o Access/Encapsulation, se gli endpoint sono noti alla foglia, vengono trattati allo stesso modo. 

Esempio 1. Endpoint noti alla struttura che operano nello stesso EPG, dominio Bridge e accesso/incapsulamento.

Esempio 2. Endpoint noti alla struttura, che funzionano nello stesso EPG, dominio Bridge ma con accesso/incapsulamento diverso.

Esempio 3. Endpoint noti alla struttura, che funzionano in EPG diversi ma nello stesso dominio di Bridge.

Quando l'inondazione ARP è disabilitata e gli endpoint fanno parte di diversi EPG nello stesso dominio bridge, mentre sono connessi allo stesso switch foglia, il traffico ARP viene instradato localmente se lo switch foglia conosce l'indirizzo IP della destinazione ARP (il routing unicast è abilitato).

Caso di utilizzo 2. Gli endpoint vengono appresi in COOP

Questo scenario si applica quando entrambi gli endpoint sono connessi a switch foglia diversi. Sono presenti nel database del protocollo cooperativo (COOP) di Spine Switch.

La richiesta ARP deve essere inoltrata nell'infrastruttura. Il flusso del traffico ARP da H1 a H3 è:

• H1 invia una richiesta ARP per H3 utilizzando un MAC di destinazione.

• L'ACI tenta di utilizzare l'inoltro unicast per inviare la richiesta ARP, quindi lo switch foglia locale controlla l'indirizzo IP della destinazione ARP, che è l'indirizzo IP H3. Poiché lo switch foglia locale non conosce l'indirizzo IP dell'endpoint H3, invia la richiesta ARP allo switch dorso per il proxy dorsale.

• La spine ha le informazioni H3 nel database COOP (routing unicast abilitato) e inoltra la richiesta ARP allo switch foglia di destinazione attraverso la struttura, che la inoltra a H3. Una volta che H3 riceve il traffico, risponde a H1.

Esempio 1. Endpoint noti alla struttura, che funzionano nello stesso EPG, dominio Bridge e accesso/incapsulamento.

Esempio 2. Endpoint noti alla struttura, che funzionano nello stesso EPG, dominio Bridge ma con accesso/incapsulamento diverso.

Esempio 3. Endpoint noti alla struttura, che funzionano in EPG diversi ma nello stesso dominio di Bridge.

Caso di utilizzo 3. IP destinazione sconosciuto, ARP Flood disabilitato

Questo use case viene applicato quando Ingress Leaf non conosce la posizione dell'indirizzo IP di destinazione (ARP flooding disabilitato, unicast routing abilitato).

In uno scenario simile, quando il flooding ARP è disabilitato e la foglia in entrata non sa dove si trova l'indirizzo IP di destinazione ARP, viene inviata una richiesta ARP al TEP (Spine-Proxy Tunnel End-point) di anycast. Il flusso del traffico ARP da H1 a H2 è:

• H1 invia una richiesta ARP per H2 utilizzando un MAC di destinazione.

• ACI tenta di utilizzare l'inoltro unicast per inviare la richiesta ARP. Lo switch foglia locale non conosce l'indirizzo IP dell'endpoint H2 (l'indirizzo IP della destinazione ARP non è noto alla foglia in entrata), quindi invia la richiesta ARP allo switch dorso per il proxy dorso.

• Poiché le informazioni sull'endpoint H2 non sono presenti nel database COOP sullo switch spine, la spine scarta il pacchetto originale, ma attiva l'opzione ARP glean per rilevare l'IP di destinazione, in modo che le successive richieste ARP non vengano scartate.

Esempio 1. Indipendentemente dalle impostazioni EPG, Bridge o Access/Encapsulation, il flusso delle richieste ARP rimane lo stesso di cui sopra.

Caso di utilizzo 4. IP destinazione sconosciuto, ARP Flood abilitato

Questo caso di utilizzo si verifica quando Foglia in ingresso non conosce la posizione dell'indirizzo IP di destinazione (ARP flooding abilitato, unicast routing abilitato).

Se l'allagamento ARP è abilitato nel dominio del ponte, la richiesta ARP da H1 raggiunge H2 attraverso l'allagamento. Il flusso del traffico ARP da H1 a H2 è:

• H1 invia una richiesta ARP per H2 utilizzando un MAC di destinazione.

• La richiesta ARP è inviata a tutte le interfacce nel dominio bridge. H2 riceve il frame e le risposte, mentre viene appreso nel fabric.

Esempio 1.

Uno dei vantaggi dell'attivazione dell'ARP flooding è la possibilità di rilevare una IP silenziosa che si è spostata da una postazione all'altra senza avvertire una foglia ACI. Poiché la richiesta ARP viene inondata all'interno del dominio bridge, anche se la foglia ACI ritiene ancora che l'IP si trovi nella vecchia posizione, l'host con l'IP silenzioso risponde in modo appropriato in modo che la foglia ACI possa aggiornare la propria voce di conseguenza.

Se l'inondazione ARP è disabilitata, la foglia ACI continua a inoltrare la richiesta ARP solo alla vecchia posizione fino a quando l'endpoint IP non scade. D'altra parte, il vantaggio di disabilitare il flooding ARP è di essere in grado di ottimizzare il flusso del traffico inviando la richiesta ARP direttamente alla posizione dell'IP di destinazione, presumendo che nessun endpoint si muova senza notificarne lo spostamento tramite GARP e simili.

Caso di utilizzo 5. Endpoint in diversi EPG e BD

Questo caso di utilizzo viene applicato quando gli endpoint sono connessi in EPG e domini bridge diversi.

Quando gli endpoint fanno parte di diversi EPG e domini di bridge, il traffico tra di essi deve essere instradato. L'inondazione non attraversa i domini del ponte, inclusa l'inondazione dell'ARP. Pertanto, se il protocollo H1 deve comunicare con il protocollo H2, connesso allo stesso switch foglia, il traffico viene inviato all'indirizzo MAC del gateway predefinito, quindi l'inondazione ARP non è rilevante nell'esempio.

Informazioni sull'inclinazione ARP

Cisco ACI dispone di diversi meccanismi per rilevare gli host inattivi, quando una foglia ACI non ha imparato un endpoint locale. ACI dispone di alcuni meccanismi per rilevare gli host inattivi. Per il traffico di layer 2 commutato su un MAC sconosciuto, è possibile impostare l'opzione unicast di layer 2 nel dominio bridge (BD) su flood, mentre per le richieste ARP con un MAC di destinazione broadcast, è possibile utilizzare l'opzione ARP flooding nel dominio bridge per controllare il comportamento flooding. Inoltre, Cisco ACI utilizza la funzionalità di acquisizione ARP per inviare richieste ARP e risolvere l'indirizzo IP di un endpoint non ancora individuato (rilevamento automatico dell'host).

Se con il rilevamento ARP il dorso non dispone di informazioni su dove è connessa la destinazione della richiesta ARP (l'IP di destinazione non è nel database COOP), il fabric genera una richiesta ARP che ha origine dall'indirizzo IP SVI (Pervasive Gateway) del dominio bridge. Questa richiesta ARP viene inviata a tutte le interfacce edge dei nodi foglia che fanno parte del dominio bridge. Inoltre, la pulitura ARP viene attivata per il traffico indirizzato (layer 3) indipendentemente dalla configurazione, ad esempio per il flooding ARP, a condizione che il traffico venga indirizzato a un indirizzo IP sconosciuto.

La tecnologia ARP gleaning prevede alcuni requisiti:

• L'indirizzo IP viene usato per l'inoltro (richieste ARP con flooding ARP disabilitato o traffico attraverso le subnet con ACI BD SVI come gateway)

• Routing unicast abilitato

• Subnet creata nel dominio bridge

Caso di utilizzo 1. IP destinazione sconosciuto, ARP Flood disabilitato

Questo caso di utilizzo si verifica quando l'endpoint di destinazione/destinazione non è noto al fabric (flooding ARP disabilitato).

Quando gli endpoint si trovano su switch foglia diversi, sono parte dello stesso dominio EPG e bridge e usano la stessa mappatura dell'accesso VLAN, la richiesta ARP (ad esempio, da H1 a H3) deve essere inoltrata sull'intera struttura. Se le informazioni H3 non sono presenti nel database COOP sullo switch a dorso (host silenzioso) e l'allagamento ARP è disabilitato, è possibile utilizzare anche l'inclinazione ARP come illustrato nella figura.

Il flusso del traffico ARP da H1 a H3 è:

• H1 invia una richiesta ARP per H3 utilizzando un MAC di destinazione.

• L'ACI tenta di utilizzare l'inoltro unicast per inviare la richiesta ARP, quindi lo switch foglia locale controlla l'indirizzo IP della destinazione ARP (IP H3). Poiché lo switch foglia locale non conosce l'indirizzo IP dell'endpoint H3, invia la richiesta ARP allo switch dorso per il proxy dorsale.

• Le informazioni H3 non sono presenti nel database COOP sullo switch a dorso e attivano la pulitura ARP utilizzando l'indirizzo IP del gateway pervasivo come origine. Richiesta ARP propagata nel dominio.

• H3 riceve la richiesta ARP e le risposte, mentre viene appreso nella struttura.

Indipendentemente dalle impostazioni EPG, Bridge o Access/Encapsulation, la funzione di guadagno ARP funziona allo stesso modo quando due endpoint tentano di comunicare tra loro (indipendentemente dalla loro connettività allo stesso o a un diverso switch foglia all'interno della struttura).

Caso di utilizzo 2. Endpoint in diversi EPG e BD

Questo caso di utilizzo si applica quando gli endpoint sono connessi in domini EPG e bridge diversi (ARP flooding abilitato).

Quando gli endpoint fanno parte di diversi EPG e domini di bridge, il traffico tra di essi deve essere instradato. L'inondazione non attraversa i domini del ponte, inclusa l'inondazione ARP che può essere generata dall'inondazione ARP. Pertanto, se il protocollo H1 deve comunicare con il protocollo H2, connesso allo stesso switch foglia, il traffico viene inviato all'indirizzo MAC del gateway predefinito, in modo che la spaziatura ARP non sia rilevante nell'esempio.