Nexus 9000シリーズのARPおよびMACテーブルの同期動作の確認

はじめに

このドキュメントでは、Cisco Nexus 9000シリーズスイッチのARPおよびMACアドレステーブルで見られる特定の同期動作について説明します。 

前提条件

要件

このドキュメントの説明を十分に理解するために、読者は次の主要な概念とテクノロジーに関する基本的な知識を持つことができます。

1. 仮想ポートチャネル(vPC):vPCは、説明されているネットワーキングシナリオを理解するために不可欠な設定、設定、および運用管理に関する知識があること。

2. NX-OS仮想ポートチャネル(vPC)ピアゲートウェイ機能：ピアゲートウェイ機能がvPCセットアップ内でどのように機能するかに関する知識（トラフィック転送および冗長性メカニズムでの役割を含む）。

3. Cisco Nexusオペレーティングシステム(NX-OS)：コマンドラインインターフェイス(CLI)とNexus 9000シリーズスイッチに関連する一般的な設定に重点を置いた、NX-OSの実用的な知識。

使用するコンポーネント

• スイッチモデル：Nexus 3000およびNexus 9000シリーズスイッチ（第1世代のみ）。固有のASICの制約による特定のARPおよびMACテーブルの動作を中心に説明します。

• 仮想ポートチャネル(vPC)：リンクされたデバイス間の同期動作をテストするように設定されます。 

• vPCピアゲートウェイ機能：vPCドメイン内でアクティブ化され、ARPおよびMAC同期への影響を調査します。

• 非vPCレイヤ2トランク：Nexusピアデバイスの接続に使用されます。

• 非vPCスイッチ仮想インターフェイス(SVI)：ユーザ定義のMACアドレスが使用されていないときの動作を調査するように設定され、ARPおよびMACアドレス同期のデフォルト処理を強調します。

• オペレーティングシステム：NX-OSバージョン7.0(3)I7(5)。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

複雑なネットワーク環境では、一貫したデータフローとネットワークの信頼性を確保するために、相互接続されたデバイス間でのアドレス解決プロトコル(ARP)とMACアドレステーブルの同期が不可欠です。 このガイドの目的は、Nexus 9000シリーズスイッチの効果的なトラブルシューティングと設定に役立つ、これらの動作の包括的な概要を、実際のラボでの観察と設定でサポートすることです。 

このドキュメントで説明するARPとMACアドレスの同期の問題は、Cisco Nexus 9000シリーズスイッチの特定の設定に固有のものです。これらの問題は、主に次の2つの状況で発生します。

1. スイッチ仮想インターフェイス(SVI)がユーザ定義のMACアドレスなしで設定されている場合。

2. vPCドメイン設定内で仮想ポートチャネル(vPC)ピアゲートウェイ機能をアクティブ化する。

対応するMACアドレスエントリがエージングアウトしたり、MACアドレステーブルから明示的に消去されたりする可能性があるにもかかわらず、この特定の動作はARPエントリの維持方法に影響を与えるため、重要です。これにより、パケット転送の不整合やネットワークの不安定性が発生する可能性があります。

さらに、この動作は第1世代のNexus 9000シリーズスイッチのみに存在するASICハードウェアの制限によるものであることに注意してください。この制限は、後で導入されるNexus 9300クラウドスケールモデル（EX、FX、GX、およびCバージョン）には適用されません。この問題はCisco Bug IDCSCuh94866で認識され、カタログ化されています。

トポロジ

概要

VLAN 150が非vPC VLANとして設定され、ARPとMACアドレステーブルの両方が最初はホストAとNexus 9000スイッチB(N9K-B)の間で空で、ホスト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により、ホストAはN9K-Bを対象としたARP要求を送信します。この要求は、Nexus 9000スイッチA(N9K-A)のポートチャネル21(Po21)からブロードキャストされます。これは、VLANフラッディングの原因となります。同時に、この要求はCisco Fabric Services(CFS)経由でport-channel 20(Po20)経由でトンネリングされます。直接的な結果として、N9K-BのMACアドレステーブルが更新され、ホストAの正しいエントリが含まれます。また、ARPエントリは、ホストAのMACアドレス(0223.e957.6a3a)のインターフェイスとしてPo21（非vPCレイヤ2トランク）を指すように、N9K-Bの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

この問題は、N9K-BのMACアドレステーブルからホストAのMACアドレスが削除されると発生します。この削除は、MACアドレスの自然なエージングプロセス、スパニングツリープロトコル(STP)の受信、トポロジ変更通知(TCN)、または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上のホスト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コマンドを使用すると、パケットが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

また、9K-Bで一連のdebug ip arpコマンドを使用して、この動作の詳細を表示することもできます。

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からの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からホスト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ピアリンクを誤って参照するという現象が発生するのは、通常、ユーザ定義MACアドレス(VMAC)がvPC上のルーティング隣接関係に使用されていない場合でも、非vPCスイッチ仮想インターフェイス(SVI)で設定されていない場合です。

この動作は、第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

注：ハードウェアの制限により、デバイスごとに一度に設定できるユーザ定義MACアドレスは16個のみです。この問題は『Cisco Nexus 9000シリーズNX-OSインターフェイスコンフィギュレーションガイド』に記載されています。スイッチのユーザ定義MACアドレス（MEv6/スタティック）の上限は16です。この制限を超えて設定すると、Cisco Bug ID CSCux84428

回避策を適用した後、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要件の詳細については、『仮想ポートチャネル経由のルーティングにおけるトポロジの作成』のドキュメントを参照してください。