Entender a inundação de ARP e a limpeza de ARP na ACI

Introdução

Este documento descreve o uso da inundação do Address Resolution Protocol (ARP) e da limpeza do ARP na estrutura da Application Centric Infrastructure (ACI).

Entendendo a inundação ARP

Na Cisco ACI, há uma opção para usar a inundação ARP ou desativá-la quando necessário. É obrigatório conhecer o comportamento da estrutura em relação à inundação de ARP para que você possa solucionar problemas da Camada 2.

Se a inundação ARP estiver habilitada, o tráfego ARP será inundado dentro da estrutura de acordo com o tratamento ARP regular em redes tradicionais. A inundação de ARP é necessária quando você precisa de solicitações do ARP Gratuito (GARP) para atualizar caches ARP do host ou caches ARP do roteador. Esse é o caso quando um endereço IP pode ter um endereço MAC diferente (por exemplo, com clustering de failover de balanceadores de carga e firewalls).

Se a inundação ARP estiver desativada, a estrutura tentará usar o unicast para enviar o tráfego ARP ao destino. Portanto, ocorre uma consulta de Camada 3 para o endereço IP de destino do pacote ARP. O ARP se comporta como um pacote unicast de Camada 3 até alcançar o switch leaf de destino.

Em seguida, você verá alguns casos de uso relacionados ao uso da inundação ARP.

Caso de uso 1. Os endpoints são aprendidos na ACI

Este caso de uso se aplica quando ambos os pontos finais são conhecidos pelo switch leaf.

Não há função de inundação ARP nesse cenário. O tráfego é comutado localmente quando o switch leaf conhece suas informações de endpoint. Esse comportamento é o mesmo quando um endpoint, como H1, envia uma solicitação ARP para o outro (H2) e a inundação ARP é desativada. Como o switch leaf sabe onde o H2 está conectado e verifica o endereço IP de destino ARP (que é um endereço IP H2), não há necessidade de inundar o tráfego ou redirecioná-lo para a camada spine. Portanto, ele envia a solicitação ARP para H2. 

Independentemente das configurações de grupo de endpoint (EPG), domínio de bridge ou acesso/encapsulamento, se os endpoints forem conhecidos pelo leaf, eles serão tratados da mesma maneira. 

Exemplo 1. Endpoints conhecidos pela malha, trabalhando no mesmo EPG, domínio de bridge e acesso/encapsulamento.

Exemplo 2. Endpoints conhecidos pela malha, trabalhando no mesmo EPG, domínio de Bridge, mas em diferentes Access/Encapsulation.

Exemplo 3. Endpoints conhecidos pela malha, trabalhando em EPGs diferentes, mas no mesmo domínio de bridge.

Quando a inundação ARP é desativada e os pontos finais são parte dos diferentes EPGs no mesmo domínio de bridge, enquanto conectados ao mesmo switch leaf, o tráfego ARP é roteado localmente se o switch leaf souber o endereço IP de destino ARP (o roteamento unicast está ativado).

Caso de uso 2. Endpoints são aprendidos no COOP

Este caso de uso se aplica quando ambos os pontos finais estão conectados a switches leaf diferentes; presentes no banco de dados do COOP (Cooperative Protocol) do Switch Spine.

A solicitação ARP deve ser encaminhada através da estrutura. O fluxo de tráfego ARP de H1 para H3 é:

• H1 envia uma solicitação ARP para H3 usando um MAC de destino de broadcast.

• A ACI tenta usar o encaminhamento unicast para enviar a solicitação ARP, de modo que o switch leaf local verifique o endereço IP de destino ARP, que é o endereço IP H3. Como o switch leaf local não sabe o endereço IP do ponto final H3, ele envia a solicitação ARP ao switch spine para spine-proxy.

• O spine tem as informações de H3 no banco de dados COOP (o roteamento unicast está ativado) e encaminha a solicitação ARP ao switch leaf de destino através da estrutura, que a encaminha para o H3. Quando o H3 recebe o tráfego, ele responde ao H1.

Exemplo 1. Endpoints conhecidos pela malha, trabalhando no mesmo EPG, domínio de bridge e acesso/encapsulamento.

Exemplo 2. Endpoints conhecidos pela malha, trabalhando no mesmo EPG, domínio de Bridge, mas em diferentes Access/Encapsulation.

Exemplo 3. Endpoints conhecidos pela malha, trabalhando em EPGs diferentes, mas no mesmo domínio de bridge.

Caso de uso 3. IP de destino desconhecido, inundação ARP desativada

Este caso de uso é aplicado quando a Folha de ingresso não sabe o local do endereço IP de destino (inundação de ARP desativada, roteamento unicast ativado).

Em um cenário semelhante, quando a inundação ARP é desativada e a folha de entrada não sabe onde o endereço IP de destino ARP está localizado, uma solicitação ARP é enviada ao ponto final de túnel (TEP) spine-proxy anycast em vez de inundação. O fluxo de tráfego ARP de H1 para H2 é:

• O H1 envia uma solicitação ARP para o H2 usando um MAC de destino de broadcast.

• A ACI tenta usar o encaminhamento unicast para enviar a solicitação ARP. O switch leaf local não sabe o endereço IP do ponto final H2 (o IP de destino ARP é desconhecido para a folha de entrada), portanto, ele envia a solicitação ARP ao switch spine para o proxy spine.

• Como as informações do ponto final H2 estão ausentes do banco de dados COOP no switch spine, o spine descarta o pacote original, mas, em vez disso, aciona o glean ARP para detectar o IP de destino, de modo que as solicitações ARP subsequentes não sejam descartadas.

Exemplo 1. Independentemente das configurações de EPG, domínio de Bridge ou Acesso/Encapsulamento, o fluxo de solicitações ARP permanece o mesmo mencionado anteriormente.

Caso de uso 4. IP de destino desconhecido, inundação ARP ativada

Este caso de uso se aplica quando a Folha de ingresso não sabe o local do endereço IP de destino (inundação de ARP ativada, roteamento unicast ativado).

Se a inundação ARP estiver habilitada no domínio da ponte, a solicitação ARP de H1 alcança H2 através da inundação. O fluxo de tráfego ARP de H1 para H2 é:

• O H1 envia uma solicitação ARP para o H2 usando um MAC de destino de broadcast.

• A solicitação ARP é inundada para todas as interfaces no domínio de bridge. O H2 recebe o quadro e responde, enquanto é aprendido na estrutura.

Exemplo 1.

Um dos benefícios de habilitar a inundação de ARP é poder detectar um IP silencioso que se moveu de um local para outro sem notificar uma folha de ACI. Como a solicitação ARP é inundada dentro do domínio de ponte, mesmo que a folha da ACI ainda pense que o IP está no local antigo, o host com o IP silencioso responde adequadamente para que a folha da ACI possa atualizar sua entrada de acordo.

Se a inundação de ARP for desativada, a folha da ACI continuará encaminhando a solicitação ARP somente para o local antigo até que o ponto final de IP se esgote. Por outro lado, o benefício de desativar a inundação ARP é poder otimizar o fluxo de tráfego enviando a solicitação ARP diretamente ao local do IP de destino, assumindo que nenhum endpoint se move sem notificar seu movimento através do GARP e assim por diante.

Caso de uso 5. Endpoints em diferentes EPGs e BDs

Este caso de uso é aplicado quando os endpoints estão conectados em diferentes EPGs e diferentes domínios de bridge.

Quando os endpoints fazem parte de diferentes EPGs e de diferentes domínios de bridge, o tráfego entre eles deve ser roteado. A inundação não atravessa os domínios de bridge, incluindo a inundação ARP. Portanto, se o H1 precisar se comunicar com o H2, que está conectado no mesmo switch leaf, o tráfego será enviado para o endereço MAC do gateway padrão, portanto, a inundação ARP não é relevante neste exemplo.

Entendendo a limpeza ARP

A Cisco ACI tem vários mecanismos para detectar hosts silenciosos, em que uma folha da ACI não aprendeu um endpoint local. A ACI tem alguns mecanismos para detectar esses hosts silenciosos. Para o tráfego comutado de Camada 2 para um MAC desconhecido, você pode definir a opção unicast desconhecido de Camada 2 no domínio de ponte (BD) para inundação, enquanto para as solicitações ARP com um MAC de destino de broadcast, você pode usar a opção de inundação ARP no domínio de ponte para controlar o comportamento de inundação. Além disso, a Cisco ACI usa a coleta ARP para enviar solicitações ARP para resolver o endereço IP de um endpoint que ainda não foi aprendido (detecção silenciosa de host).

Com a limpeza do ARP, se o spine não tiver informações sobre onde o destino da solicitação ARP está conectado (o IP de destino não está no banco de dados COOP), a estrutura gerará uma solicitação ARP originada do endereço IP da interface virtual do switch (SVI) (gateway difundido) do domínio de bridge. Essa solicitação ARP é enviada para todas as interfaces de borda dos nós de folha que fazem parte do domínio de bridge. Além disso, a coleta de ARP é acionada para tráfego roteado (Camada 3) independentemente da configuração, como inundação de ARP, desde que o tráfego seja roteado para um IP desconhecido.

A limpeza ARP tem alguns requisitos:

• O endereço IP é usado para encaminhamento (solicitações ARP com inundação ARP desativada ou tráfego através de sub-redes com SVI BD ACI como o gateway)

• Roteamento unicast ativado

• Sub-rede criada no domínio de bridge

Caso de uso 1. IP de destino desconhecido, inundação ARP desativada

Este caso de uso se aplica quando o ponto final destino/destino não é conhecido pela estrutura (inundação ARP desativada).

Quando os pontos finais estão em switches leaf diferentes, enquanto fazem parte do mesmo EPG e domínio de bridge, e usam o mesmo mapeamento de acesso de VLAN, a solicitação ARP (por exemplo, de H1 para H3) tem que ser encaminhada através da estrutura. Se as informações de H3 estiverem faltando no banco de dados COOP no switch spine (host silencioso) e a inundação ARP estiver desativada, a limpeza ARP também poderá ser utilizada, conforme ilustrado nesta figura.

O fluxo de tráfego ARP de H1 para H3 é:

• H1 envia uma solicitação ARP para H3 usando um MAC de destino de broadcast.

• A ACI tenta usar o encaminhamento unicast para enviar a solicitação ARP, de modo que o switch leaf local verifique o endereço IP de destino ARP (IP H3). Como o switch leaf local não sabe o endereço IP do ponto final H3, ele envia a solicitação ARP ao switch spine para spine-proxy.

• As informações de H3 estão ausentes do banco de dados COOP no switch spine e acionam a coleta ARP usando o endereço IP do gateway difundido como origem. Esta solicitação ARP está inundada no domínio.

• O H3 recebe a solicitação ARP e responde, enquanto é aprendido na estrutura.

Independentemente das configurações de EPG, domínio de Bridge ou Acesso/Encapsulamento, o recurso de glean ARP funciona da mesma maneira quando dois endpoints estão tentando se comunicar (independentemente de sua conectividade com o mesmo ou com um switch de leaf diferente dentro da estrutura).

Caso de uso 2. Endpoints em diferentes EPGs e BDs

Este caso de uso se aplica quando os terminais estão conectados em diferentes EPGs e domínios de ponte (inundação ARP ativada).

Quando os endpoints fazem parte de diferentes EPGs e de diferentes domínios de bridge, o tráfego entre eles deve ser roteado. A inundação não atravessa os domínios de bridge, incluindo a inundação ARP que pode ser gerada pela limpeza ARP. Portanto, se o H1 precisar se comunicar com o H2, que está conectado no mesmo switch leaf, o tráfego será enviado para o endereço MAC do gateway padrão, portanto, a obtenção de ARP não é relevante neste exemplo.