Nexus 9000 Series ARP 및 MAC 테이블 동기화 동작 확인

소개

이 문서에서는 Cisco Nexus 9000 Series 스위치의 ARP 및 MAC 주소 테이블에서 관찰되는 특정 동기화 동작에 대해 설명합니다. 

사전 요구 사항

요구 사항

독자는 이 문서의 논의를 통해 다음과 같은 몇 가지 주요 개념과 기술을 기본적으로 이해할 수 있습니다.

1. vPC(Virtual Port Channel): vPC의 설정, 구성 및 운영 관리에 익숙하며, vPC는 앞서 설명한 네트워킹 시나리오를 이해하는 데 필수적입니다.

2. NX-OS Virtual Port Channel Peer Gateway 기능: 피어 게이트웨이 기능이 vPC 설정 내에서 작동하는 방식에 대한 지식(트래픽 전달 및 이중화 메커니즘에서의 역할 포함).

3. Cisco Nexus Operating System(NX-OS): NX-OS에 대한 실무적 이해 - NX-OS의 CLI 및 Nexus 9000 Series 스위치와 관련된 일반적인 구성에 중점을 둡니다.

사용되는 구성 요소

• 스위치 모델: Nexus 3000 및 Nexus 9000 Series 스위치(1세대에만 해당). 고유한 ASIC 제약으로 인해 특정 ARP 및 MAC 테이블 동작을 보여주는 데 핵심적인 역할을 합니다.

• vPC(Virtual Port Channel): 연결된 장치 전반에서 동기화 동작을 테스트하도록 구성되었습니다. 

• vPC 피어 게이트웨이 기능: ARP 및 MAC 동기화에 미치는 영향을 조사하기 위해 vPC 도메인 내에서 활성화됩니다.

• 비 vPC Layer 2 트렁크: Nexus 피어 장치 연결에 사용됩니다.

• 비 vPC SVI(Switch Virtual Interfaces): 사용자 정의 MAC 주소가 사용되지 않을 때 동작을 탐색하도록 구성되어 ARP 및 MAC 주소 동기화의 기본 처리를 강조 표시합니다.

• 운영 체제: NX-OS 버전 7.0(3)I7(5).

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

복잡한 네트워크 환경에서는 상호 연결된 장치 간에 ARP(Address Resolution Protocol) 및 MAC 주소 테이블을 동기화하는 것이 일관된 데이터 흐름과 네트워크 신뢰성을 보장하는 데 매우 중요합니다. 이 가이드는 Nexus 9000 Series 스위치의 효과적인 트러블슈팅 및 구성을 지원하기 위해 실제 랩 관찰 및 컨피그레이션에서 지원하는 이러한 동작에 대한 포괄적인 개요를 제공하는 데 목적이 있습니다. 

이 문서에 설명된 ARP 및 MAC 주소 동기화 문제는 Cisco Nexus 9000 Series 스위치의 특정 구성에 따라 다릅니다. 이러한 문제는 다음과 같은 두 가지 주요 조건에서 발생합니다.

1. 사용자 정의 MAC 주소 없이 SVI(Switch Virtual Interface)가 구성된 경우

2. vPC(가상 포트 채널) 피어 게이트웨이 기능이 vPC 도메인 설정에서 활성화된 경우

이러한 특정 동작은 해당 MAC 주소 항목이 잠재적으로 에이징아웃되거나 MAC 주소 테이블에서 명시적으로 지워지더라도 ARP 항목이 유지되는 방식에 영향을 미치기 때문에 중요합니다. 이로 인해 패킷 전달이 일관되지 않고 네트워크가 불안정해질 수 있습니다.

또한 이러한 동작은 1세대 Nexus 9000 Series 스위치에만 있는 ASIC 하드웨어 제한 때문입니다. 이러한 제한은 나중에 소개되는 Nexus 9300 Cloud Scale 모델(EX, FX, GX, C 버전)에는 적용되지 않습니다. 이 문제는 Cisco 버그 IDCSCuh94866에서 인식 및 카탈로그화되었습니다.

토폴로지

개요

VLAN 150이 비 vPC VLAN으로 구성되고 ARP 및 MAC 주소 테이블이 Host-A와 Nexus 9000 스위치 B(N9K-B) 간에 처음에 비어 있으며 Host-A에서 N9K-B로 ping이 시작되는 네트워크 시나리오를 가정해 보십시오.

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

이 ping은 Host-A에 N9K-B를 대상으로 하는 ARP 요청을 보내라는 프롬프트를 표시합니다. 이 요청은 VLAN 플러딩을 담당하는 Nexus 9000 스위치 A(N9K-A)의 포트 채널 21(Po21)에서 브로드캐스트됩니다. 동시에 요청은 포트 채널 20(Po20) 전반에 걸쳐 CFS(Cisco Fabric Services)를 통해 터널링됩니다. 결과적으로 N9K-B의 MAC 주소 테이블이 Host-A에 대한 올바른 항목을 포함하도록 업데이트되며, N9K-B의 ARP 테이블에서도 ARP 항목이 설정됩니다. 이는 Po21(non-vPC Layer 2 트렁크)을 Host-A의 MAC 주소(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

이 문제는 Host-A의 MAC 주소가 N9K-B의 MAC 주소 테이블에서 제거될 때 나타날 수 있습니다. 이러한 제거는 MAC 주소의 자연 에이징 프로세스, STP(Spanning Tree Protocol) 수신, TCN(Topology Change Notifications) 수신, 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

이러한 삭제에도 불구하고 ping 트래픽이 계속 성공적임을 확인할 수 있습니다. 그러나 N9K-B의 Host-A에 대한 ARP 항목은 예기치 않게 지정된 비 vPC 계층 2 트렁크인 포트 채널 21(Po21)이 아닌 포트 채널 20(Po20 - vPC 피어 링크)을 가리킵니다. 이러한 리디렉션은 VLAN 150이 vPC가 아닌 VLAN으로 구성되었음에도 불구하고 수행되며, 이로 인해 예상되는 트래픽 플로우가 불일치하게 됩니다.

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.

두 Nexus 9000 스위치에서 show ip arp internal event-history event 명령을 사용하여 패킷이 CFS(Cisco Fabric Services)를 통해 터널링됨을 시연할 수 있습니다.

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

또한 9K-B에서 debug ip arp series debug 명령을 사용하여 이 동작을 자세히 설명할 수도 있습니다.

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

Host-A의 ARP 회신은 먼저 Nexus 9000 스위치 A(N9K-A)에 도달한 다음 Nexus 9000 스위치 B(N9K-B)로 터널링됩니다. 특히 N9K-A는 피어 게이트웨이 vPC 도메인 향상을 활용하여 ARP 응답을 제어 플레인으로 전달합니다. 이 컨피그레이션을 사용하면 N9K-A가 N9K-B에 대한 패킷의 라우팅을 처리할 수 있습니다. 일반적으로 비 vPC VLAN 설정에서는 이 작업이 필요하지 않습니다.

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

ARP 회신의 동작을 검증하기 위해 NX-OS의 Ethanalyzer 기능을 활용할 수 있습니다. 이 툴은 N9K-B의 제어 평면이 이 ARP 응답을 직접 관찰하지 않음을 확인하며, vPC 컨피그레이션에서 ARP 트래픽의 특수 처리를 강조 표시합니다.

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>

주의: 이벤트 및 상황의 순서에 따라 N9K-B에서 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

결론 및 해결 방법

ARP 항목이 예상된 비 vPC 트렁크가 아닌 vPC 피어 링크를 잘못 참조하는 경우 관찰된 동작은 일반적으로 특정 상황에서 발생합니다. 즉, 비 vPC SVI(Switch Virtual Interface)에서 사용자 정의 MAC 주소가 구성되지 않은 경우, 이러한 SVI가 vPC를 통한 라우팅 인접성에 사용되지 않는 경우에도 마찬가지입니다.

이 동작은 1세대 Nexus 9000 스위치에만 적용됩니다.

이 문제를 완화하려면 영향을 받는 SVI에 대한 MAC 주소를 수동으로 구성하는 것이 좋습니다. MAC 주소를 변경하면 ARP 잘못된 방향이 발생하는 것을 방지할 수 있으므로, 네트워크가 vPC가 아닌 시나리오에서 vPC 피어 링크에 의존하지 않고 의도한 대로 작동하도록 할 수 있습니다. 

다음은 해결 방법의 예입니다.

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

참고: 하드웨어 제한으로 인해 디바이스당 한 번에 16개의 사용자 정의 MAC 주소만 구성할 수 있습니다. 이 내용은 Cisco Nexus 9000 Series NX-OS Interfaces 컨피그레이션 가이드에 설명되어 있습니다. 스위치에는 16개의 사용자 정의 MAC 주소(MEv6/static)가 있습니다. 이 한도를 초과하여 구성하면 Cisco 버그 ID CSCux에 문서화된 문제가 발생할 수 있습니다84428

해결 방법이 적용되면 NX-OS의 Ethanalyzer 기능을 활용하여 Nexus 9000 스위치 A(N9K-A)가 더 이상 ARP 응답을 제어 평면에 전달하지 않고 네트워크에서 ARP 응답을 올바르게 처리할 수 있음을 확인할 수 있습니다.

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

관련 정보

레이어 2 비 vPC 트렁크, 라우팅 인접성 및 SVI 사용자 정의 MAC 요구 사항에 대한 자세한 내용은 Create Topologies for Routing over Virtual Port Channel(가상 포트 채널을 통한 라우팅에 대한 토폴로지 생성) 문서를 참조하십시오.