制御パケットは、隣接・経路・冗長状態など、ネットワークが転送を続けるための情報を交換するメッセージです。OSPF Hello、BGP Keepalive、VRRP Advertisement、STP BPDU、ARPは目的が違います。すべてを「生存確認のHello」と呼ぶと、停止したときの影響を読み違えます。
この記事は、メッセージの役割、送られる層、実パケットと装置の状態の対応を整理します。図はOSPFの交換順序の概念例で、接続構成や全パケットの記録とは区別しています。
この記事でわかること
- ユーザー通信と、転送の前提を作る通信を分ける
- Hello・Keepalive・Advertisementの名前より、何を維持するかを見る
- OSPFの図は、HelloのあとにDB同期を確認する例
ユーザー通信と、転送の前提を作る通信を分ける
Web要求やファイル転送が利用者の処理に使う通信だとすると、OSPFは隣接やリンク状態を交換して経路計算へつなげ、VRRPは仮想ルーターの役割を決めます。同じ機器で処理していても、使う情報と失敗時の影響が違います。
制御の状態が変わった時刻と、利用者の通信が失敗した時刻は必ず一致するわけではありません。別経路や既存の転送情報が残る場合もあります。逆に、制御状態が正常でも業務用のTCPが制御されていれば、その処理は失敗します。
| 見る面 | 確認するもの | 証拠の例 |
|---|---|---|
| 制御 | ネイバー、役割、タイマー、経路の交換 | 状態出力、ログ、制御メッセージ |
| 転送 | 採用経路、隣接、MAC、実際の出口 | RIB/FIB、ARP/MAC、両端キャプチャ |
| 利用者 | 要求・応答、認証、既存セッション | ICMPと対象アプリの時刻付き結果 |
Hello・Keepalive・Advertisementの名前より、何を維持するかを見る
| メッセージ | 主な役割 | 確認する層・状態 |
|---|---|---|
| OSPFv2 Hello | ネイバーの発見・双方向性・維持 | IPv4 protocol89、OSPFネイバー |
| BGP Keepalive | BGPセッションの維持 | TCPセッション内、BGPの状態とHold条件 |
| VRRPv3 Advertisement | Activeの情報を伝え役割を維持 | IP protocol112、VRID・priority・広告間隔 |
| STP BPDU | L2ループを防ぐための情報交換 | Ethernet、root・port role・state |
| ARP | IPv4次ホップのL2アドレス解決 | Ethernet、ARPとMACの情報 |
ARPは周期的なkeepaliveとして定義されるものではありません。BGPも経路を知らせるUPDATEとKeepaliveを分けます。「制御パケット」という括りは役割を整理するために使い、各プロトコルの仕様を一つの動作へまとめないでください。
参考：RFC 2328：OSPFv2のHelloとDB同期（2026年10月5日確認）
参考：RFC 4271：BGPメッセージ（2026年10月5日確認）
参考：RFC 9568：VRRP Advertisement（2026年10月5日確認）
OSPFの図は、HelloのあとにDB同期を確認する例
図はOSPFv2のpoint-to-pointで、R1とR2がHelloを交換して相手を認識し、DBD、LS Request、LS Update、LS AckなどによるDB同期へ進む概念例です。実際は複数かつ双方向の交換があり、図の4本の矢印だけで通信が完了するわけではありません。
Helloの受信を見つけたら、area、認証、Hello/Dead条件、network typeなどを照合し、ネイバーがどの状態へ進んだかを確認します。DB同期で止まるならMTUやDBDなどの候補を、状態とメッセージで絞ります。
broadcast LANではDR/BDRと隣接を組み、DROther同士は2-Wayで正常な場合があります。「FULLでないから異常」という判定は、構成とnetwork typeを無視しています。隣接の期待値を決めてから、LSDB、RIB、実通信へ進んでください。学習順はルーティングのラボ課題で確認できます。
IPプロトコル番号とTCP/UDPポートを混同しない
OSPFの89やVRRPの112はIPヘッダーのProtocol値で、TCP/UDPのポート番号ではありません。BGPはTCPを使い、通常は179への接続でセッションを作ります。FWやACLで同じ種類の条件として記述すると、必要な制御が許可されないことがあります。
IPv4のVRRP宛先224.0.0.18は同一リンク内のマルチキャストです。これは端末へ割り当てるプライベートIPの例ではなく、仕様で決まる宛先です。装置間をルーティングして転送する利用者通信と扱いを分けます。OSPFもnetwork typeや隣接先によって宛先を読む必要があります。
SPANは取得した方向とVLAN、対象ポートを記録します。Wiresharkの表示フィルタでパケットが見えない場合も、取得点の不足、ミラー方向、フィルタ誤りなどが候補で、送信自体がないと直ちに断定はできません。
Wireshark：表示フィルタの例
ospf || bgp || vrrp || stp || arp
Cisco IOS系：状態を確認する例
show ip ospf neighbor
show ip bgp summary
show vrrp
show spanning-tree detail
show ip arp状態・パケット・経路・通信を、同じ時刻に並べる
| 観測 | 言えること | 次に照合すること |
|---|---|---|
| 自装置で送信が見える | その取得点へ出た | 対向の受信、受理条件 |
| 対向の取得点で受信 | 相手側まで届いた | VRID/area等、エラーと状態 |
| ネイバー・役割が正常 | 制御上の状態が成立 | 必要prefix、RIB/FIB、実通信 |
| 制御パケットの欠落 | 観測条件で欠落した | 損失、CPU、CoPP、取得点 |
| 状態downだが通信継続 | その通信は継続した | 別経路、保持、転送先とタイマー |
受信できることと受理することは別です。間違った版や条件、認証などで捨てられるなら、対向のログや状態を取得します。フィルタを変えただけで説明せず、何を見落としていたかを記録してください。
試験の完了は、メッセージが見えたところで止めない
正常時の制御間隔、役割、必要経路、利用者通信を保存し、検証では一条件だけ変えます。障害操作、最後の制御受信、状態変化、転送情報、業務要求の復旧を同じ時刻軸へ整理すると、何が先に起きたかを追えます。
VRRPの広告と役割はAdvertisementの切り替わり、測定と判定は冗長化試験の切替時間へ進みます。取得方法はミラーポートとWiresharkで確認してください。目的を一つ決め、装置の状態と実際の通信の両方で説明を完成させましょう。
筆者の関連ポスト：Xで読む
