목차

소개

배경 정보

요구 사항

사용되는 구성 요소

토폴로지

개요

관련 정보

소개

이 문서에서는 비 vPC 레이어 2 트렁크를 공유하는 Nexus 9000 디바이스 간에 발생할 수 있는 ARP 및 MAC 테이블 동작에 대해 설명합니다.

배경 정보

이 동작은 SVI가 사용자 정의 MAC 주소를 사용하지 않고 vPC 피어 게이트웨이 기능이 vPC 도메인 아래에 구성된 경우에만 발생합니다. 또한 ARP 테이블이 채워져 있는 경우에만 볼 수 있으며, MAC 주소 테이블에는 지정된 호스트에 대한 MAC 항목이 없습니다.

이 문서에 설명된 동작은 1세대 Nexus 스위치의 ASIC 제한이며 Nexus 9300 Cloud Scale(EX/FX/GX/C) 스위치 이상에는 영향을 미치지 않으며 Cisco 버그 ID CSCuh94866의 일부로 문서화되었습니다.

요구 사항

vPC(Virtual Port Channel), NXOS Virtual Port Channel 피어 게이트웨이 기능 및 NXOS(Nexus Operating System)에 대한 일반적인 지식

사용되는 구성 요소

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

- Nexus 3000s/Nexus 9000s(1세대 전용)

- vPC(가상 포트 채널 기능)

- vPC 피어 게이트웨이 기능

- 비 vPC L2(Layer 2) 트렁크

- 비 vPC SVI

- NX-OS 7.0(3)I7(5)

토폴로지

개요

ARP 및 MAC 주소 테이블이 Host-A와 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

Host-A의 ping은 Host-A가 9K-B에 대한 ARP 요청을 전송하도록 합니다. ARP 요청은 N9K-A(VLAN에서 플러딩됨)에서 Po21을 벗어나 Po20(CFS[Cisco Fabric Services]를 통해 터널링됨)에서 이그레스(egress)됩니다. 그 결과 9K-B의 MAC 주소 테이블이 올바르게 채워지고, Host-A의 MAC 주소 0223.e957.6a3a에 대한 Po21(비 vPC L2 트렁크)을 가리키는 N9K-B의 ARP 테이블에 ARP 항목이 삽입됩니다.

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 주소는 MAC 주소 에이징, STP(Spanning Tree Protocol) TCN(Topology Change Notifications), 명령줄 인터페이스를 통한 clear mac 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

---------+-----------------+--------+---------+------+----+------------------

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이 여전히 성공적임을 확인합니다. 그러나 ARP 항목은 이제 Po21 대신 Po20(vPC PL)을 가리킵니다. 이는 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

ARP 회신은 Host-A에서 9K-A를 가져온 다음 9K-B로 터널링됩니다. 피어 게이트웨이 vPC 도메인 개선이 활성화되었으므로 9K-A에서 ARP Reply를 제어 평면에 적용합니다. 이렇게 하면 비 vPC VLAN임에도 불구하고 9K-A가 N9K-B를 대신하여 패킷을 라우팅합니다.

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

NX-OS의 Ethanalyzer 컨트롤 플레인 패킷 캡처 기능을 사용하여 9K-B의 컨트롤 플레인에 기본적으로 이 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

이 동작은 SVI 사용자 정의 MAC 주소가 vPC를 통한 라우팅 인접성에 사용되지 않는 경우에도 비 vPC SVI에서 구성되지 않은 경우 발생합니다. 이 동작은 1세대 Nexus 9000 스위치에만 적용됩니다.

이 동작을 해결하려면 영향을 받는 SVI의 MAC 주소를 변경합니다.

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 컨피그레이션 가이드에 설명되어 있습니다.

해결 방법을 적용한 후 NX-OS의 Ethanalyzer 컨트롤 플레인 패킷 캡처 기능을 사용하여 9K-A에서 컨트롤 플레인에 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(가상 포트 채널을 통한 라우팅에 대한 토폴로지 생성) 문서를 참조하십시오.