Verificar el comportamiento de sincronización de tabla MAC y ARP de Nexus serie 9000

Introducción

Este documento describe un comportamiento de sincronización específico observado en las tablas de direcciones ARP y MAC de los switches Nexus de Cisco serie 9000. 

Prerequisites

Requirements

Para beneficiarse plenamente de las discusiones de este documento, el lector puede tener un entendimiento básico de varios conceptos y tecnologías clave:

1. Virtual Port Channel (vPC): familiarización con la configuración, la configuración y la gestión operativa de vPC, ya que son esenciales para comprender los escenarios de red descritos.

2. Función de gateway de par de canal de puerto virtual de NX-OS: conocimiento de cómo funciona la función de gateway de par en una configuración vPC, incluida su función en el reenvío de tráfico y los mecanismos de redundancia.

3. Sistema operativo Cisco Nexus (NX-OS): un conocimiento práctico de NX-OS, centrado en su interfaz de línea de comandos y en las configuraciones típicas relevantes para los switches Nexus serie 9000.

Componentes Utilizados

• Modelos de switches: switches Nexus serie 3000 y Nexus serie 9000 (solo de primera generación), que son fundamentales para ilustrar el comportamiento específico de las tablas ARP y MAC debido a sus limitaciones ASIC únicas.

• Canal de puerto virtual (vPC): se configura para probar comportamientos de sincronización en los dispositivos vinculados. 

• Función de gateway de par vPC: se activa dentro del dominio vPC para investigar su influencia en la sincronización ARP y MAC.

• Troncal de capa 2 no vPC: se utiliza para conectar los dispositivos de par Nexus.

• Interfaces virtuales de switch (SVI) no vPC: configuradas para explorar comportamientos cuando no se utilizan direcciones MAC definidas por el usuario, destacando la gestión predeterminada de ARP y la sincronización de direcciones MAC.

• Sistema operativo: NX-OS versión 7.0(3)I7(5).

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

En entornos de red complejos, la sincronización del protocolo de resolución de direcciones (ARP) y las tablas de direcciones MAC entre los dispositivos interconectados es fundamental para garantizar un flujo de datos coherente y la fiabilidad de la red. El objetivo de esta guía es proporcionar una descripción general completa de estos comportamientos, respaldada por configuraciones y observaciones de laboratorio reales, para ayudar a solucionar problemas y configurar switches Nexus serie 9000 de forma eficaz. 

Los problemas de sincronización de direcciones ARP y MAC detallados en este documento son específicos de ciertas configuraciones de switches Nexus de Cisco serie 9000. Estas cuestiones se plantean en dos condiciones principales:

1. Cuando las interfaces virtuales del switch (SVI) se configuran sin direcciones MAC definidas por el usuario.

2. Cuando se activa la función de gateway de par del canal de puerto virtual (vPC) en la configuración del dominio vPC.

Este comportamiento específico es significativo porque afecta cómo se mantienen las entradas ARP a pesar de que las entradas de dirección MAC correspondientes potencialmente caducan o se borran explícitamente de la tabla de direcciones MAC. Esto puede conducir a inconsistencias en el reenvío de paquetes e inestabilidad de la red.

Además, es importante tener en cuenta que este comportamiento se debe a una limitación de hardware ASIC presente únicamente en los switches Nexus serie 9000 de primera generación. Esta limitación no se extiende a los modelos de la escala para la nube de Nexus 9300 (versiones EX, FX, GX y C) que se introduzcan más adelante. El problema ha sido reconocido y catalogado bajo el bug Cisco IDCSCuh94866.

Topología

Overview

Considere un escenario de red en el que la VLAN 150 se configura como una VLAN sin vPC y las tablas de direcciones ARP y MAC están vacías inicialmente entre el Host A y el switch B Nexus 9000 (N9K-B), y se inicia un ping desde el Host A al 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

Este ping solicita al Host-A que envíe una solicitud ARP dirigida a N9K-B. Esta solicitud se transmite desde el canal de puerto 21 (Po21) en el switch A Nexus 9000 (N9K-A), que es responsable de la inundación de VLAN. Simultáneamente, la solicitud también se canaliza a través de los servicios de Cisco Fabric (CFS) a través del canal de puerto 20 (Po20). Como consecuencia directa, la tabla de direcciones MAC en N9K-B se actualiza para incluir la entrada correcta para el Host-A, y también se establece una entrada ARP en la tabla ARP de N9K-B, señalando a Po21 —el troncal de Capa 2 que no es vPC— como la interfaz para la dirección MAC del 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

El problema puede observarse cuando la dirección MAC del Host-A se elimina de la tabla de direcciones MAC de N9K-B. Esta eliminación puede producirse por diversos motivos, entre los que se incluyen el proceso de desactualización natural de la dirección MAC, la recepción del protocolo de árbol de extensión (STP), las notificaciones de cambio de topología (TCN) o intervenciones manuales como la ejecución del 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

A pesar de estas eliminaciones, cabe destacar que el tráfico de ping sigue siendo exitoso. Sin embargo, la entrada ARP para el Host A en N9K-B apunta inesperadamente al canal de puerto 20 (Po20, el enlace de par vPC), en lugar del canal de puerto 21 (Po21), que es el enlace troncal designado de capa 2 que no es vPC. Esta redirección se produce a pesar de que la VLAN 150 se ha configurado como una VLAN sin vPC, lo que provoca una incoherencia en el flujo de tráfico 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.

Puede utilizar el comando show ip arp internal event-history event en ambos switches Nexus 9000 para demostrar que los paquetes se tunelizan a través de 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

También puede utilizar la serie debug ip arp de comandos debug en 9K-B para detallar este comportamiento:

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

La respuesta ARP del Host A alcanza primero el switch A Nexus 9000 (N9K-A) y luego se tuneliza al switch B Nexus 9000 (N9K-B). En particular, N9K-A reenvía la respuesta ARP a su plano de control, aprovechando la mejora del dominio vPC de gateway de pares. Esta configuración permite que N9K-A gestione el routing del paquete para N9K-B, una operación que normalmente no se espera en una configuración de VLAN sin 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 el comportamiento de la respuesta ARP, se puede utilizar la función Ethanalyzer en NX-OS. Esta herramienta confirma que el plano de control de N9K-B no observa directamente esta respuesta ARP, destacando el manejo especializado del tráfico ARP en configuraciones 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>

Precaución: Dependiendo de la secuencia de eventos y circunstancias, podría experimentar la pérdida de paquetes de N9K-B al 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

Conclusión y solución

El comportamiento observado, en el que las entradas ARP hacen referencia incorrectamente al enlace de par vPC en lugar del enlace troncal no vPC esperado, suele producirse en circunstancias específicas: cuando las direcciones MAC definidas por el usuario no se configuran en interfaces virtuales de switch (SVI) no vPC, incluso si estas SVI no se utilizan para enrutar adyacencias a través de vPC.

Este comportamiento solo se aplica a los switches Nexus 9000 de primera generación.

Para mitigar este problema, se recomienda configurar manualmente las direcciones MAC para las SVI afectadas. El cambio de las direcciones MAC puede evitar que se produzca el mal direccionamiento de ARP, lo que garantiza que la red funcione según lo previsto sin depender del enlace de par vPC en escenarios que no sean vPC. 

Solución alternativa de ejemplo:

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

Nota: debido a una limitación de hardware, solo puede tener 16 direcciones MAC definidas por el usuario configuradas por dispositivo a la vez. Esto se documenta en la Guía de configuración de interfaces NX-OS para Cisco Nexus serie 9000, ya que el switch tiene un límite de 16 direcciones MAC definidas por el usuario (MEv6/estáticas). La configuración más allá de este límite puede dar lugar a problemas documentados en el ID de bug de Cisco CSCux84428

Una vez aplicada la solución alternativa, la función Ethanalyzer de NX-OS se puede utilizar para verificar que el switch A Nexus 9000 (N9K-A) ya no reenvíe la respuesta ARP a su plano de control, lo que confirma la gestión correcta de las respuestas ARP en la red.

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

Información Relacionada

Consulte el documento Creación de Topologías para el Ruteo sobre el Canal de Puerto Virtual para obtener más información sobre los trunks no vPC de Capa 2, las adyacencias de ruteo y los requisitos de MAC definido por el usuario SVI.