ネットワークエンジニアの必読！実務に役立つTips 〜ARPと疎通編〜
この「ネットワークエンジニアの必読！実務に役立つTips」シリーズでは、意外と知られていなかったり、デファクトスタンダードとして扱われているが、知ってみるとかなり便利だったり、知らない方でも何故それがそんなに評価されているのか理解してもらうことを目的として、Tipsを紹介しています。
課題
ARPプロトコルと疎通について理解する
エンドツーエンドの通信が行われる基本的な仕組みについて今一度理解しよう
基本的なICMPの流れ(同じセグメント)
宛先が自分と同じネットワークアドレスか確認する。今回は同じであることが確認される
自身のARPテーブルを確認する。宛先IPのエントリが存在する場合は5へ進む
無い場合、宛先IPに対し宛先MACアドレスFF:FF:FF:FF:FF:FFのARP Requestパケットを送信する(ブロードキャスト)
ARP Request要求に、宛先IPがARP Replyをユニキャストで返す。宛先の端末には、ARP Requestを受け取った時点で、送信元端末のARPエントリが登録される
送信元端末のARPテーブルにエントリが記録される
宛先IP、宛先MACアドレスをARPテーブルに従って生成し、ICMP Echo Requestを送信する
宛先の端末がICMP Echo Replyを返し通信が完了する
基本的なICMPの流れ(別セグメント)
宛先が自分と同じネットワークアドレスか確認する。今回は異なることが確認される
自身のルーティングテーブルを確認する。従うべきスタティックルートが無ければ、通常デフォルトルートのエントリに該当する
自身のARPテーブルを確認し、デフォルトゲートウェイのエントリを確認する(無ければ先に解決する)
ARPテーブルに従い、宛先IPは宛先のもの、宛先MACアドレスはデフォルトゲートウェイのもので生成し、ICMP Echo Requestを送信する
デフォルトゲートウェイも、上述の「基本的なICMPの流れ」に従い、パケットを転送する
最終的に宛先がICMP Echo Requestを受信、ICMP Echo Replyを送信、送信元が受信すれば通信が完了する
強調したいこと
同セグ内はARPでアドレス解決して通信する
別セグとは、スタティックルートがあればネクストホップのアドレスを解決して通信する
別セグとは、スタティックルートに該当しなければデフォルトゲートウェイのアドレスを解決して通信する
ARPリクエストは、同じセグメントの宛先のアドレスを解決しようとする時に行われ、ブロードキャストで行われる
ARPリプライは、ユニキャストで行われる
ネットワーク機器自身が同じセグメントの特定のIPに通信しようとするのは、よくあることである。例えば、
上流の機器をNTPサーバーとして指定している
閉域網内のBGPネイバー
スタティックルートのネクストホップ
忘れがちだが重要なポイント
ARPリクエストはブロードキャストなので、ARPリクエストか一度でも発呼されれば同セグの機器に送信元IPのARPエントリが必ず記録される
逆に言えば、ARPリクエストが発呼されない限りは記録されない。つまり、ネットワーク機器がNTPや、ネクストホップや、諸々同セグ内の宛先にARPリクエストを絶対に発呼しないならば、学習は永遠にされない
上記は特に、ネットワーク機器交換作業を行う際にしばしばトラブルとなる。何故なら往々にしてIPアドレスは引き継ぐものの、MACアドレスが変わってしまうからである
これを考慮すると、ネットワーク機器交換作業を行う際は、同セグの機器に対しARPテーブルが更新されるよう、どこかへ一度で良いのでPingを送信すべきである
結論
この根本的な挙動について忘れると、トラブルが起きた時に勝手に"未知のピラミッドパワーが働いている"と切り分けて、根本的な原因を見失ってしまうことになるので気を付けること
宣伝
弊社、株式会社CRE-COエンジニアリングサービスは、自社エンジニア成長＆満足を第一に運営しています。
エンジニアが高い意欲で仕事ができれば顧客にも喜ばれ、最後に自社にも返ってくると考えるからです！
是非あなたも一緒にメンバーに加わりませんか！詳細は下記のURLから！
エンジニアファーストの会社 株式会社CRE-COエンジニアリングサービス 藤井 博文
この記事が気に入ったらサポートをしてみませんか？