あるIPの端末が、どのスイッチのどのポートにいるかを調べたい。こんなときは、ARP表とMAC表をつなぐと接続先へ近づけます。
ARPでIPからMACを知り、MAC表でそのMACがいる方向を知ります。一回の検索で端末直結ポートが出るとは限らず、別スイッチへのリンクをたどる場合もあります。図のPC-Bを例に、取得する装置と表の意味を確認しましょう。
ARPは、対象端末のLANにつながるL3機器で見る
図のPC-Bは172.27.81.35/24、ゲートウェイはR1の172.27.81.1です。R1のARP表でPC-BのMACを調べ、そこからSW1、SW2を順に追います。
遠隔の管理PCのARP表に、PC-Bが出るとは限りません。別LANへ送るときは、通常、そのPCが最初に渡すゲートウェイのMACを解決するためです。
| 確認対象 | この例の取得元 | そろえる条件 |
|---|---|---|
| 172.27.81.35のARP | R1の端末LAN側 | VRF・インターフェース・取得時刻 |
| 02aa.8100.0035のMAC学習 | SW1 → SW2 | VLAN81・ポート・種別・時刻 |
| 端末の実体 | SW2 Gi1/0/10の先 | NIC、配線、端末のIPとMAC |
Proxy ARPや仮想ゲートウェイがある構成では、表示されたMACが端末NICのものとは限りません。台帳と構成を確認してから、物理ポートを追います。
MACが出たポートの先に、何があるかを確かめる
説明用MACは02aa.8100.0035です。SW1でGi1/0/48に学習していても、PCがそこへ直接挿さっているとは言えません。図では、その先がSW2です。
CDP／LLDPや配線表で対向を確認し、SW2でも同じVLAN・MACを検索します。SW2のGi1/0/10まで来たら、access VLAN81と接続端末のIP・MACを照合します。
説明用の出力例。実機で取得した結果ではありません。
R1# show ip arp 172.27.81.35
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.27.81.35 2 02aa.8100.0035 ARPA GigabitEthernet0/0
SW1# show mac address-table address 02aa.8100.0035
Vlan Mac Address Type Ports
81 02aa.8100.0035 DYNAMIC Gi1/0/48
SW2# show mac address-table address 02aa.8100.0035
Vlan Mac Address Type Ports
81 02aa.8100.0035 DYNAMIC Gi1/0/10接続先とVLANを照合する例
show cdp neighbors detail
show lldp neighbors detail
show interfaces GigabitEthernet1/0/10 switchport
show interfaces GigabitEthernet1/0/10
show interfaces trunkPort-channelと表示された場合は、論理リンクの先を追います。MAC表だけでは、一つのフレームがどの物理メンバーを通ったかまで分かりません。
出力例は実測ではありません。自分の環境で取得した機器、VLAN、ポート、時刻を並べると、どこまで端末の場所を確認できたかが残ります。
Incompleteは、解決できていない状態の手掛かり
ARPがIncompleteなら、MACの解決が完了していません。端末が停止している、別VLANへ入っている、IPやマスクが違うなど、複数の原因候補があります。
まず対象IFとVRFを確認し、正しいLANで見ているかを合わせます。そのあとARP要求が出たか、端末へ届いたか、応答が戻ったかを追います。
| 確認 | 原因候補 | 見る証拠 |
|---|---|---|
| R1の対象IF・VRF | 別の参照範囲を見ている | 対象IPの経路、IFとVRF |
| VLAN81の連続性 | access VLAN違い、trunk許可漏れ | 両端switchport・trunk・STP |
| 要求の到達 | 対象端末へ届かない | R1側と端末側でのARP取得 |
| 端末の応答 | 電源断、NIC・IPの不一致 | 端末状態、応答パケット |
| 応答の復帰 | 途中の制御、L2経路の問題 | 途中SWのMAC、ポート状態 |
ARPは通常のIPv4パケットとは形式が違います。IPのACLにpermitがあることだけで、ARPが通ると証明できるわけではありません。
要求・応答を見た場所と時刻を記録すると、端末側なのか中継区間なのかを絞れます。表示名を、そのまま原因名として報告しないようにします。
ARPあり・MACなしは、保持時間と学習を調べる
ARPと動的MACは、別の条件で保持されます。ルーターにARPが残っていても、スイッチが端末から長くフレームを受け取らなければ、MAC表から消えることがあります。
同じ時刻・VLANで取得し、端末の送信前後を比べます。学習しないのか、学んだあとに消えるのかで、次に調べる対象が変わります。
- 同じVLAN・VRF・機器を見ているか確認する。
- ARPのAge・静的設定とMACの種別を確認する。
- 許可された疎通を短時間発生させ、同じ時刻帯に再取得する。
- 端末からフレームが出ているか、受信ポートの増分と取得で調べる。
- 別SW・スタック・Port-channel配下の学習も確認する。
| 観測したこと | 意味の候補 | 追加確認 |
|---|---|---|
| 同じMACが複数ポート間を移動 | ループ、NICチーミング、仮想マシン移動など | 移動時刻、STP、対向、計画変更 |
| 同じIPのARPが異なるMACへ変わる | 重複IP、機器交換、冗長切替、Proxy ARPなど | IP台帳、ARPパケット、冗長化の状態 |
| MACが想定外VLANで出る | 設定差、別端末、仮想環境の接続 | access／trunk、実NICのMAC |
| 期待ポートでMACあり、通信不可 | L2の学習はあるが別の段階で失敗 | GW、経路、FW、ホスト、アプリ |
同じMACが別ポートへ移るのはMAC移動、同じIPの対応MACが変わるのは重複IPや冗長化などを考える手掛かりです。同じ現象として扱わず、ログと正常な切替を照合します。
調査前に表を消すと、元の状態がなくなります。まず表とログを保存し、必要な検証の範囲を決めます。
接続先の確認後は、元の通信を再試験する
IP、MAC、VLAN、スイッチ、accessポート、端末が一致したら、接続先の追跡は整理できます。設定を直した場合は、学習が安定していることを確認します。
それでも、最初に使えなかった業務アプリが戻ったかは別の確認です。同じ端末と操作で試し、ARPやMACの登録だけを復旧完了にしません。
まず一台について、IPからポートまでの対応表を作ってみてください。コマンド名を覚えることから、どの表で何を確かめたかを説明する練習へ進めます。
取得装置と時刻を添えれば、次の担当者も同じ経路を追いやすくなります。
関連する動画・筆者の投稿：Xで読む
確認に使った公式資料
