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

はじめに

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

前提条件

要件

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

1. Virtual Port Channel(vPC):vPCは、説明されているネットワーキングシナリオを理解するために不可欠な設定、設定、および運用管理に精通しています。

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

3. Cisco Nexus Operating System(NX-OS):NX-OSの実用的な知識。コマンドラインインターフェイス(CLI)と、Nexus 9000シリーズスイッチに関連する一般的な設定に重点を置いています。

使用するコンポーネント

• スイッチモデル：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. ユーザ定義のMACアドレスを使用せずにスイッチ仮想インターフェイス(SVI)を設定した場合。

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アドレステーブルの両方が最初は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要求を送信します。この要求は、Nexus 9000スイッチA(N9K-A)のポートチャネル21(Po21)からブロードキャストされます。これは、VLANフラッディングの原因となります。同時に、ポートチャネル20(Po20)経由でCisco Fabric Services(CFS)経由で要求をトンネリングすることもできます。 直接的な結果として、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
---------+-----------------+--------+---------+------+----+------------------


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コマンドの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はARP応答をコントロールプレーンに転送し、ピアゲートウェイvPCドメイン機能拡張を活用します。この設定により、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ピアリンクを誤って参照するという確認された動作は、通常、特定の状況で発生します。ユーザ定義MACアドレスが非vPCスイッチ仮想インターフェイス(SVI)で設定されていない場合は、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個だけです。スイッチには16個のユーザ定義MACアドレス（MEv6/スタティック）の制限があるため、この問題は『Cisco Nexus 9000シリーズNX-OSインターフェイスコンフィギュレーションガイド』に記載されています。 この制限を超えて設定すると、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要件の詳細については、『仮想ポートチャネルを介したルーティングのトポロジの作成』のドキュメントを参照してください。