Cisco Catalyst 8000Vにおける、clear arp-cacheコマンド実行時の挙動について検証した結果を記載する。
検証１
内容
Catalyst 8000V(以降、C8000V)の対向機器がリンクダウンしている状態でclear arp-cacheコマンドを実行した際のARPキャッシュ消去までの所要時間を確認
環境
- Catalyst 8000V(IOS XE 17.9.4)
- Ubuntu Server 22.04.4
手順
1. Tera TermでC8000Vにアクセスし、タイムスタンプ付きでログを開始
2. C8000Vでshow arpコマンドを実行し、ARPテーブルにUbuntu Server(以降、VM)のエントリが登録されていることを確認
3. VMのインターフェイスをvSwitchから切断
4. C8000VからVMへpingが失敗することを確認
5. C8000Vでshow arpコマンドを実行し、VMのエントリが登録されていることを確認
6. C8000Vでclear arp-cacheコマンドを実行
7. C8000VでARPテーブルからVMのエントリがクリアされるまで、show arpコマンドを連続で実行（コピー・ペーストで大量のshow arpコマンドを流し込む）
8. ログを停止し、手順6でclear arp-cacheコマンドを実行した時刻と手順7でARPテーブルからVMのエントリが消去された時刻の差分を算出
結果
- 36秒
【ログ抜粋】
[2024-06-25 15:36:54.607] Catalyst8000v#clear arp
…
[2024-06-25 15:37:30.424] Catalyst8000v#
[2024-06-25 15:37:30.424] Catalyst8000v#show arp | i 192.168.2.1
[2024-06-25 15:37:30.461] Internet 192.168.2.1 1 0050.56a1.b5dc ARPA GigabitEthernet1
[2024-06-25 15:37:30.461] Catalyst8000v#
[2024-06-25 15:37:30.461] Catalyst8000v#show arp | i 192.168.2.1
[2024-06-25 15:37:30.486] Catalyst8000v#
検証２
内容
C8000Vの対向機器がリンクアップしている状態でポートを切り替え、clear arp-cacheコマンドを実行した際のARPキャッシュ消去までの所要時間を確認
環境
- Catalyst 8000V(IOS XE 17.9.4)
- Catalyst 3750X(IOS 15.0)
- Ubuntu Server 22.04.4
- MACアドレス：00:50:56:a1:b5:dc
- Windows 11 PC
- MACアドレス：90:2E:16:C8:C1:2F
手順
1. Catalyst 3750X(以降、C3750X)とWindows 11 PC(以降、PC)をコンソール接続し、C3750XとPCが接続するポート(G1/0/20)を192.168.0.0/16(VLAN172)以外のVLANに設定
2. Tera TermでC8000Vにアクセスし、タイムスタンプ付きでログを開始
3. C8000Vでshow arpコマンドを実行し、ARPテーブルにVMのエントリが登録されていることを確認
4. VMのインターフェイスをvSwitchから切断し、C3750XのG1/0/20をVLAN192(192.168.0.0/16)に変更
5. VMからC8000Vへpingが失敗することを確認
6. C8000Vでshow arpコマンドを実行し、VMのエントリが登録されていることを確認
7. C8000Vでclear arp-cacheコマンドを実行
8. C8000VでARPテーブルからVMのエントリが消去される、またはPCのエントリが登録されるまでshow arpコマンドを連続実行
9. ログを停止し、手順7でclear arp-cacheコマンドを実行した時刻と手順8でARPテーブルからVMのエントリが消去されるまたはPCのエントリが登録された時刻の差分を算出
結果
- 31秒
- PCのエントリは登録されず、VMのエントリが消去された。
【ログ抜粋】
[2024/07/18, 4:47:09.529 PM] Catalyst8000v#clear arp-cache
[2024/07/18, 4:47:40.020 PM] Catalyst8000v#sh arp | i 192.168.2.1
[2024/07/18, 4:47:40.039 PM] Internet 192.168.2.1 5 0050.56a1.b5dc ARPA GigabitEthernet1
[2024/07/18, 4:47:40.039 PM] Catalyst8000v#sh arp | i 192.168.2.1
[2024/07/18, 4:47:40.060 PM] Catalyst8000v#sh arp | i 192.168.2.1
検証３
内容
C8000Vと同一セグメントでARPテーブルに登録されていない機器に対してclear arp-cacheコマンドを実行した際のARPリクエストの送信有無を確認
環境
- Catalyst 8000V(IOS XE 17.9.4)
- MACアドレス：00:50:56:a1:91:48
- Catalyst 3750X(IOS 15.0)
- Windows 11 PC
- MACアドレス：90:2E:16:C8:C1:2F
手順
1. Tera TermでC8000Vにアクセスし、タイムスタンプ付きでログを開始
2. C8000Vでshow arpコマンドを実行し、ARPテーブルにPCのエントリが登録されていないことを確認
3. PCのWiresharkでパケットキャプチャを開始
4. C8000Vでclear arp-cacheコマンドを実行
5. パケットキャプチャを停止し、PCに対するC8000VからのARPリクエストの送信有無を確認
結果
- clear arp-cache実行後、C8000VからブロードキャストでGARPを送信していた
- C8000VからPCに対してARPリクエストは送信していなかった
【ログ抜粋】
[2024-07-30 16:30:27.402] Catalyst8000v#sh arp | i 192.168.2.1
[2024-07-30 16:30:27.402] Catalyst8000v#
[2024-07-30 16:30:59.096] Catalyst8000v#clear arp-cache
送信元または宛先がC8000Vのパケットキャプチャフレームを抜粋
| Arrival Time | Source | Destination | Packet |
|---|---|---|---|
| 2024-07-30 16:31:00 | 00:50:56:a1:91:48 (C8000V) | Broadcast (ff:ff:ff:ff:ff:ff) | Address Resolution Protocol (reply/gratuitous ARP) |
検証４
内容
C8000Vと同一セグメントでARPテーブルに登録されている機器に対してclear arp-cacheコマンドを実行した際のARPリクエストの送信有無を確認
環境
- Catalyst 8000V(IOS XE 17.9.4)
- MACアドレス：00:50:56:a1:91:48
- Catalyst 3750X(IOS 15.0)
- Windows 11 PC
- MACアドレス：90:2E:16:C8:C1:2F
手順
1. Tera TermでC8000Vにアクセスし、タイムスタンプ付きでログを開始
2. PCからC8000Vへpingを実行
3. C8000Vでshow arpコマンドを実行し、ARPテーブルにPCのエントリが登録されていることを確認
4. PCのWiresharkでパケットキャプチャを開始
5. C8000Vでclear arp-cacheコマンドを実行
6. パケットキャプチャを停止し、PCに対するC8000VからのARPリクエストの送信有無を確認
結果
- clear arp-cache実行後、C8000VからブロードキャストでGARPを送信していた
- C8000VからPCに対してARPリクエストを送信していた
【ログ抜粋】
[2024-07-30 16:06:03.505] sh arp
[2024-07-30 16:06:04.504] Internet 192.168.2.1 0 902e.16c8.c12f ARPA GigabitEthernet1
[2024-07-30 16:06:04.520] Catalyst8000v#
[2024-07-30 16:07:13.716] Catalyst8000v#clear arp-cache
送信元または宛先がC8000Vのパケットキャプチャフレームを抜粋
| Arrival Time | Source | Destination | Packet |
|---|---|---|---|
| 2024-07-30 16:07:14 | 00:50:56:a1:91:48 (C8000V) | Broadcast (ff:ff:ff:ff:ff:ff) | Address Resolution Protocol (reply/gratuitous ARP) |
| 2024-07-30 16:07:14 | 00:50:56:a1:91:48 (C8000V) | 90:2e:16:c8:c1:2f (PC) | Address Resolution Protocol (request) |
| 2024-07-30 16:07:14 | 90:2e:16:c8:c1:2f (PC) | 00:50:56:a1:91:48 (C8000V) | Address Resolution Protocol (reply) |
考察
- C8000Vにおけるclear arp-cacheコマンド実行後のARPキャッシュ消去までの所要時間は、35秒前後
- clear arp-cacheコマンドを実行すると、ARPテーブルに登録されている機器に対してユニキャストでARPリクエストを送信する
参考
An Ethernet Address Resolution Protocol
Related issue:
https://www.rfc-editor.org/rfc/rfc826
Another alternative is to have a daemon perform the timeouts.
After a suitable time, the daemon considers removing an entry.
It first sends (with a small number of retransmissions if needed)
an address resolution packet with opcode REQUEST directly to the
Ethernet address in the table. If a REPLY is not seen in a short
amount of time, the entry is deleted. The request is sent
directly so as not to bother every station on the Ethernet.
Difference between clear arp-cache and clear ip arp
https://community.cisco.com/t5/switching/difference-between-clear-arp-cache-and-clear-ip-arp/td-p/1755557
In my testing, both 'clear ip arp' and 'clear arp-cache' send an ARP request to the MAC address that last held the IP to see if it still has it.
以上