Verificar o comportamento de sincronização da tabela do Nexus 9000 Series ARP e MAC

Introdução

Este documento descreve um comportamento de sincronização específico observado nas tabelas de endereços ARP e MAC dos switches Cisco Nexus 9000 Series. 

Pré-requisitos

Requisitos

Para se beneficiar totalmente das discussões neste documento, o leitor pode ter uma compreensão básica de vários conceitos e tecnologias importantes:

1. Virtual Port Channel (vPC): familiaridade com a instalação, a configuração e o gerenciamento operacional de vPCs, pois eles são essenciais para a compreensão dos cenários de rede descritos.

2. Recurso de gateway par de canal de porta virtual NX-OS: conhecimento de como o recurso de gateway par funciona em uma configuração vPC, incluindo sua função nos mecanismos de encaminhamento de tráfego e redundância.

3. Cisco Nexus Operating System (NX-OS): uma compreensão funcional do NX-OS, com foco na interface de linha de comando e configurações típicas relevantes para os switches Nexus 9000 Series.

Componentes Utilizados

• Modelos de switch: switches Nexus 3000 e Nexus 9000 Series (somente primeira geração), que são fundamentais para ilustrar o comportamento específico da tabela ARP e MAC devido às restrições ASIC exclusivas.

• Virtual Port Channel (vPC): configurado para testar comportamentos de sincronização em dispositivos vinculados. 

• Recurso Peer-Gateway do vPC: ativado no domínio do vPC para investigar sua influência na sincronização ARP e MAC.

• Tronco de camada 2 não vPC: usado para conectar os dispositivos pares Nexus.

• Interfaces virtuais de switch (SVIs) não-vPC: configuradas para explorar comportamentos quando os endereços MAC definidos pelo usuário não são usados, destacando o tratamento padrão de sincronização de endereço MAC e ARP.

• Sistema operacional: NX-OS versão 7.0(3)I7(5).

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Em ambientes de rede complexos, a sincronização do Address Resolution Protocol (ARP) e das tabelas de endereços MAC entre dispositivos interconectados é crucial para garantir fluxo de dados consistente e confiabilidade da rede. Este guia tem como objetivo fornecer uma visão geral abrangente desses comportamentos, apoiada por observações e configurações de laboratório reais, para auxiliar na solução de problemas e na configuração dos switches Nexus 9000 Series de forma eficaz. 

Os problemas de sincronização de endereços ARP e MAC detalhados neste documento são específicos de determinadas configurações dos switches Cisco Nexus 9000 Series. Estes problemas surgem sob duas condições principais:

1. Quando as interfaces virtuais do switch (SVIs) são configuradas sem endereços MAC definidos pelo usuário.

2. Quando o recurso de gateway par do Virtual Port Channel (vPC) é ativado nas configurações de domínio do vPC.

Esse comportamento específico é significativo porque afeta o modo como as entradas ARP são mantidas, apesar das entradas de endereço MAC correspondentes estarem potencialmente expiradas ou serem explicitamente eliminadas da tabela de endereços MAC. Isso pode levar a inconsistências no encaminhamento de pacotes e instabilidade da rede.

Além disso, é importante observar que esse comportamento se deve a uma limitação de hardware ASIC presente apenas nos switches Nexus 9000 Series de primeira geração. Essa limitação não se estende aos modelos Nexus 9300 Cloud Scale (versões EX, FX, GX e C) apresentados posteriormente. O problema foi reconhecido e catalogado sob o bug Cisco IDCSCuh94866.

Topologia

Overview

Considere um cenário de rede onde a VLAN 150 é configurada como uma VLAN não-vPC e as tabelas ARP e Endereço MAC estão inicialmente vazias entre o Host-A e o switch B (N9K-B) do Nexus 9000, e um ping é iniciado do Host-A para o N9K-B.

Host-A# ping 192.0.2.3
PING 192.0.2.3 (192.0.2.3): 56 data bytes
36 bytes from 192.0.2.100: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.0.2.3: icmp_seq=1 ttl=254 time=1.011 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=254 time=0.763 ms
64 bytes from 192.0.2.3: icmp_seq=3 ttl=254 time=0.698 ms
64 bytes from 192.0.2.3: icmp_seq=4 ttl=254 time=0.711 ms

--- 192.0.2.3 ping statistics ---
5 packets transmitted, 4 packets received, 20.00% packet loss
round-trip min/avg/max = 0.698/0.795/1.011 ms

Esse ping solicita que o Host-A envie uma solicitação ARP direcionada a N9K-B. Essa solicitação é transmitida do canal de porta 21 (Po21) no switch A (N9K-A) do Nexus 9000, que é responsável pela inundação de VLAN. Simultaneamente, a solicitação também é encapsulada através do Cisco Fabric Services (CFS) através do canal de porta 20 (Po20). Como consequência direta, a tabela de endereços MAC em N9K-B é atualizada para incluir a entrada correta para o Host-A, e uma entrada ARP também é estabelecida na tabela ARP de N9K-B, apontando para Po21—o tronco de Camada 2 não-vPC—como a interface para o endereço MAC do Host-A (0223.e957.6a3a).

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:01:07  0223.e957.6a3a  Vlan150         

N9K-B# show mac address-table address  | i i 6a3a
*  150     0223.e957.6a3a   dynamic  0         F      F    Po21

N9K-B# show ip arp detail | i 3a
192.0.2.100   00:03:22  0223.e957.6a3a  Vlan150          port-channel21   <<<< Expected port-channel

O problema pode ser visto quando o endereço MAC do Host-A é removido da tabela de endereços MAC do N9K-B. Essa remoção pode ocorrer por vários motivos, incluindo o processo de envelhecimento natural do endereço MAC, o recebimento do Spanning Tree Protocol (STP), Topology Change Notifications (TCNs) ou intervenções manuais, como a execução do comando clearmac address-table dynamic.

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:00:29     0223.e957.6a3a  Vlan150             <<< ARP remains populated

N9K-B# show mac address-table address 0223.e957.6a3a
Legend: 
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link,
        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
   VLAN     MAC Address      Type      age     Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
<empty, no MAC>

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
64 bytes from 192.0.2.100: icmp_seq=0 ttl=253 time=1.112 ms
64 bytes from 192.0.2.100: icmp_seq=1 ttl=253 time=0.647 ms
64 bytes from 192.0.2.100: icmp_seq=2 ttl=253 time=0.659 ms
64 bytes from 192.0.2.100: icmp_seq=3 ttl=253 time=0.634 ms
64 bytes from 192.0.2.100: icmp_seq=4 ttl=253 time=0.644 ms

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.634/0.739/1.112 ms

Apesar dessas exclusões, é notável que o tráfego de ping continue bem-sucedido. No entanto, a entrada ARP para o Host-A no N9K-B aponta inesperadamente para o canal de porta 20 (Po20—o vPC Peer Link), em vez do canal de porta 21 (Po21), que é o tronco de Camada 2 não-vPC designado. Esse redirecionamento ocorre apesar da VLAN 150 estar configurada como uma VLAN não vPC, o que leva a uma inconsistência no fluxo de tráfego esperado.

N9K-B# show ip arp detail | i i 6a3a

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry

IP ARP Table for context default
Total number of entries: 2
Address         Age       MAC Address     Interface        Physical Interface  Flags
192.0.2.100   00:15:54   0223.e957.6a3a    Vlan150          port-channel20   <<< Not Po21 once the issue is triggered.

Você pode usar o comando show ip arp internal event-history event em ambos os switches Nexus 9000 para demonstrar que os pacotes são encapsulados via Cisco Fabric Services (CFS):

N9K-B# show ip arp internal event-history event | i i tunnel
    [116] [27772]: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [27772]: Received tunneled packet on iod: Vlan150, physical iod: port-channel20

N9K-A# show ip arp internal event-history event | i i tunnel
    [116] [28142]: Tunnel Packets sent with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [28142]: Tunnel it to peer destined to remote SVI's Gateway MAC. Peer Gateway Enabled

Você também pode usar a série debug ip arp de comandos debug em 9K-B para detalhar esse comportamento também:

N9K-B# debug logfile TAC_ARP
N9K-B# debug ip arp packet 
N9K-B# debug ip arp event 
N9K-B# debug ip arp error 

N9K-B# show debug logfile TAC_ARP | beg "15:31:23"
2018 Oct 11 15:31:23.954433 arp: arp_send_request_internal: Our own address 192.0.2.3 on interface Vlan150,sender_pid =27661 
2018 Oct 11 15:31:23.955221 arp: arp_process_receive_packet_msg: Received tunneled packet on iod: Vlan150, physical iod: port-channel20 
2018 Oct 11 15:31:23.955253 arp: arp_process_receive_packet_msg: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677 
2018 Oct 11 15:31:23.955275 arp: (context 1) Receiving packet from Vlan150, logical interface Vlan150 physical interface port-channel20, (prty 6) Hrd type 1 Prot type 800 Hrd len 6 Prot len 4 OP 2,  Pkt size 46 
2018 Oct 11 15:31:23.955293 arp: Src 0223.e957.6a3a/192.0.2.100 Dst 00be.758e.5677/192.0.2.3 
2018 Oct 11 15:31:23.955443 arp: arp_add_adj: arp_add_adj: Updating MAC on interface Vlan150, phy-interface port-channel20, flags:0x1 
2018 Oct 11 15:31:23.955478 arp: arp_adj_update_state_get_action_on_add: Different MAC(0223.e957.6a3a) Successful action on add Previous State:0x10, Current State:0x10 Received event:Data Plane Add, entry: 192.0.2.100, 0000.0000.0000, Vlan150, action to be taken send_to_am:TRUE, arp_aging:TRUE 
2018 Oct 11 15:31:23.955576 arp: arp_add_adj: Entry added for 192.0.2.100, 0223.e957.6a3a, state 2 on interface Vlan150, physical interface port-channel20, ismct 0. flags:0x10, Rearp (interval: 0, count: 0), TTL: 1500 seconds update_shm:TRUE 
2018 Oct 11 15:31:23.955601 arp: arp_add_adj: Adj info: iod: 77, phy-iod: 91, ip: 192.0.2.100, mac: 0223.e957.6a3a, type: 0, sync: FALSE, suppress-mode: ARP Suppression Disabled flags:0x10

A resposta ARP do Host-A primeiro alcança o switch A (N9K-A) do Nexus 9000 e depois é encapsulada para o switch B (N9K-B) do Nexus 9000. Notavelmente, o N9K-A encaminha a resposta ARP para seu plano de controle, aproveitando o aprimoramento de domínio vPC de gateway par. Essa configuração permite que o N9K-A manipule o roteamento do pacote para o N9K-B, uma operação normalmente não esperada em uma configuração de VLAN não-vPC.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:32:47.378648 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3 <<<< 
2018-10-11 15:32:47.379262 02:23:e9:57:6a:3a -> 00:be:75:8e:56:77 ARP 192.0.2.100 is at 02:23:e9:57:6a:3a

Para validar o comportamento da resposta ARP, o recurso Ethanalyzer no NX-OS pode ser utilizado. Esta ferramenta confirma que o plano de controle de N9K-B não observa diretamente esta resposta ARP, destacando o tratamento especializado do tráfego ARP em configurações de vPC.

N9K-B# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:33:30.053239 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:16.817309 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:42.222965 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.44?  Tell 192.0.2.43
<snip>

Cuidado: Dependendo da sequência de eventos e das circunstâncias, você poderá experimentar a perda de pacotes de N9K-B para Host-A.

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
36 bytes from 192.0.2.3: Destination Host Unreachable
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

Conclusão e solução alternativa

O comportamento observado, em que as entradas ARP fazem referência incorretamente ao link de peer do vPC em vez do tronco não-vPC esperado, geralmente ocorre em circunstâncias específicas: quando os Endereços MAC Definidos pelo Usuário não são configurados em Interfaces Virtuais de Switch (SVIs) não-vPC, mesmo que essas SVIs não sejam usadas para adjacências de roteamento em um vPC.

Esse comportamento aplica-se apenas aos switches Nexus 9000 de primeira geração.

Para atenuar esse problema, é recomendável configurar manualmente os endereços MAC para as SVIs afetadas. Alterar os endereços MAC pode evitar que o desvio ARP ocorra, garantindo que a rede funcione conforme pretendido sem depender do link de peer do vPC em cenários que não sejam vPC. 

Exemplo de solução alternativa abaixo:

N9K-A(config)# interface Vlan150
N9K-A(config-if)# mac-address 0000.aaaa.0030
N9K-A(config-if)# end

N9K-B(config)# interface Vlan150
N9K-B(config-if)# mac-address 0000.bbbb.0030
N9K-B(config-if)# end

Observação: devido a uma limitação de hardware, você pode ter apenas 16 endereços MAC definidos pelo usuário configurados por dispositivo de cada vez. Isso é documentado no Guia de configuração de interfaces NX-OS do Cisco Nexus 9000 Series como o switch tem um limite de 16 endereços MAC definidos pelo usuário (MEv6/static). A configuração além desse limite pode resultar em problemas documentados na ID de bug Cisco CSCux84428

Após a aplicação da solução alternativa, o recurso Ethanalyzer no NX-OS pode ser utilizado para verificar se o switch A (N9K-A) do Nexus 9000 não encaminha a resposta ARP para seu plano de controle, afirmando o tratamento correto das respostas ARP na rede.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:36:11.675108 00:00:bb:bb:00:30 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3

Informações Relacionadas

Consulte o documento Create Topologies for Routing over Virtual Port Channel para obter mais informações sobre troncos não vPC de Camada 2, adjacências de roteamento e requisitos MAC definidos pelo usuário do SVI.