OpenFlowをWiresharkで見たい人が最初につまずくポイント
OpenFlowの学習や検証を始めたとき、まず気になるのが「コントローラとスイッチの間で、実際にどんなメッセージが流れているのか」です。設定ファイルやコントローラのログだけでもある程度は追えますが、通信そのものを目で確認したくなる場面は多くあります。そんなときに役立つのがWiresharkです。
ただ、実際に試してみると、ここで最初の壁にぶつかります。表示フィルタに openflow と入れても何も出てこない。Packet-Inを見たいのに表示されない。6633を見ているつもりが、環境によっては6653を使っていた。私自身も最初は「OpenFlowの通信が流れていないのでは」と疑いましたが、原因はもっと単純で、見ている場所と絞り込み方がずれていただけでした。
この記事では、OpenFlowをWiresharkで確認したい人に向けて、ありがちな失敗を踏まえながら、実際にどうキャプチャし、どこを見れば理解が進むのかを整理していきます。
OpenFlowをWiresharkで解析する前に押さえたい基本
OpenFlowは、スイッチとコントローラの間でやり取りされる制御用の通信です。つまり、L2スイッチの転送そのものを見るというより、制御プレーンの会話を観察するイメージに近いです。
ここで大事なのは、Wiresharkで最初から「OpenFlow」という名前だけを頼りにしないことです。OpenFlowはTCP上で流れるため、まずは通信が使っているポートを見つける必要があります。環境によっては6633、別の構成では6653が使われます。この違いを見落とすと、フィルタをいくら工夫しても何も表示されません。
私が最初に試したときも、OpenFlowは6633の印象が強く、そのポートだけを見ていました。ところが実際の環境では6653でコントローラと接続しており、当然ながら肝心のパケットは1つも出ませんでした。こういうズレは本当に起きやすいです。
まずはWiresharkで通信を捕まえるところから始める
OpenFlowの解析では、いきなり細かいメッセージ内容を読むより先に、そもそも通信を捕まえられているかを確認することが重要です。
監視するインターフェースを間違えない
これがいちばん多い失敗です。Open vSwitchのブリッジを見ていても、期待したOpenFlow通信が表示されないことがあります。特にMininetや仮想環境では、スイッチとコントローラの通信がローカルホスト内で完結していて、見ているNICには流れていないことが珍しくありません。
私が最初にハマったのもここでした。仮想スイッチのインターフェースを開いて待っていても、画面は静かなままです。通信が発生していないように見えるのですが、実際には別の場所を通っていました。loopbackを監視対象に変えた途端、ハンドシェイクが一気に見えたときは拍子抜けしたほどです。
その経験から言うと、最初は特定のインターフェースに決め打ちせず、広めに確認したほうが早いです。特にローカル環境なら、loopbackや any 相当の見方を意識したほうが成功率は上がります。
キャプチャ開始のタイミングも重要
OpenFlowは接続直後にやり取りされるメッセージが多く、あとからWiresharkを起動すると、大事な初期通信を取り逃がしてしまいます。
たとえば、スイッチとコントローラが接続した直後には、HelloやFeatures関連のやり取りが発生します。これを見たいなら、コントローラを立ち上げる前、あるいは接続を張り直す前からキャプチャしておくのが安全です。
後から起動して「Packet-Inが出ない」「Flow-Modしか見えない」と感じることもありますが、単に最初の会話を逃しているだけの場合があります。実際に何度か試すうち、私も“キャプチャは早めに始める”というだけで見える景色がかなり変わると実感しました。
Wiresharkで使いたい基本の見方
通信そのものが見えたら、次はWireshark上でOpenFlowとして読みやすくする段階です。
まずはTCPポートで絞る
OpenFlowかどうか確信が持てない段階では、まずTCPポートで絞るのが手堅いです。コントローラとスイッチがどのポートで会話しているか分かれば、余計な通信をかなり減らせます。
環境によってポートが異なるため、最初から一つに決めつけず確認しながら進めるのが無難です。ここを雑にすると、「OpenFlowを見ているつもりで別のTCP通信を眺めていた」ということも起こります。
表示フィルタでOpenFlowを読みやすくする
通信が絞れたら、OpenFlow用の表示フィルタで中身を見ていきます。OpenFlow全般をざっくり見るなら openflow が使いやすく、バージョンによっては openflow_v4 のようなフィルタが有効なこともあります。
このあたりは環境差が出やすい部分ですが、感覚としては「まず通信を捕まえる」「その後、OpenFlowとして解釈できる形に寄せる」という順番が大切です。最初からフィルタだけで解決しようとすると、どこで詰まっているのか分からなくなります。
OpenFlow解析で最初に見るべきメッセージ
OpenFlowにはさまざまなメッセージがありますが、最初から全部理解しようとするとかえって混乱します。実際に追うときは、いくつかの代表的なメッセージに絞って見ると流れをつかみやすいです。
Features Replyを見ると全体像がつかみやすい
接続直後のやり取りの中で、まず注目したいのがFeatures Replyです。ここでは、スイッチの識別に関わる情報やポート情報が見えてくることがあり、「いまWiresharkで見ている相手がどのスイッチなのか」が分かりやすくなります。
初めて解析したとき、私はPacket-Inばかりを探していましたが、先にFeatures Replyを確認したほうが理解しやすいと気づきました。誰と誰が会話しているのかが見えてからのほうが、その後のメッセージの意味も整理しやすいからです。
Packet-Inは“なぜコントローラに上がったか”を考える材料になる
OpenFlowの勉強で特に面白いのがPacket-Inです。フローがまだ入っていないときや、スイッチが自力で処理できないとき、パケットがコントローラへ通知されます。
このPacket-Inを観察すると、「最初のpingでなぜコントローラに問い合わせが行ったのか」「どの通信がフローテーブル未一致だったのか」が見えてきます。手元で簡単なトポロジを作ってpingを流したとき、最初だけPacket-Inがまとまって出て、その後は落ち着く様子を見たときは、フローが投入された手応えがかなり実感しやすかったです。
Flow-Modはコントローラの判断結果を見るのに向いている
Packet-Inで通知されたあと、コントローラは必要に応じてFlow-Modを送ります。つまり、Flow-Modを見ると「コントローラがどういうルールをスイッチに入れたか」が分かります。
ここが見えるようになると、OpenFlowの理解が一段深まります。単にパケットが上がってきたことを確認するだけでなく、その後どんな制御をかけたのかを追えるからです。特に、最初の通信時だけ制御メッセージが増え、その後は静かになる動きは、実験していても印象に残りやすい部分です。
Packet-Outも合わせて見ると制御の流れがつながる
場合によってはPacket-Outも重要です。コントローラが一時的にパケットの出し先を指示する場面では、Packet-InとFlow-Modの間をつなぐような役割で見えてきます。
Packet-Inだけ見ていると「通知された」ことしか分かりませんが、Packet-OutやFlow-Modも並べて追うと、「受け取った」「判断した」「転送ルールを入れた」という一連の流れが見えてきます。Wiresharkの強みは、まさにこの連続性を可視化できるところにあります。
Mininet環境で試すと理解しやすい理由
OpenFlowを学ぶなら、最初の検証環境としてMininetはかなり相性がいいです。構成がシンプルで、意図的に通信を発生させやすく、Packet-InやFlow-Modの観察もしやすいからです。
私も最初は複雑な構成で始めようとして失敗しました。スイッチが複数あると、どの通信がどの経路を通っているのか把握しづらく、Wiresharkの画面も一気に見通しが悪くなります。最終的には、1スイッチ構成で最初からやり直したことで、一つひとつのメッセージの意味がかなり腹落ちしました。
最初の検証では、できるだけ小さいトポロジで、通信も単純なping程度から始めたほうがいいです。大きな環境にいきなり入るより、OpenFlowの基本メッセージの流れを一度体感しておくほうが、結果的に早く理解できます。
OpenFlowをWiresharkで見るときによくある失敗
何も表示されない
これは本当によくあります。原因として多いのは、インターフェースが違う、キャプチャ開始が遅い、ポート番号の想定が違う、この3つです。
私も最初は「設定ミス」だと思い込んで設定ファイルばかり見直していましたが、実際はWireshark側の確認不足でした。通信が流れていないと決めつける前に、どこを見ているかを疑うほうが先です。
OpenFlowのはずなのにデコードされない
通信自体は見えているのに、OpenFlowとしてきれいに読めないケースもあります。こういうときは、OpenFlowのバージョンやWireshark側の解釈の違いを疑ったほうがいいです。
闇雲にフィルタを増やすより、まずTCPの会話として見えているか、次にOpenFlowとしての表示に切り替えられるか、段階的に確認するほうが整理しやすいです。
Packet-Inが思ったより出ない
これは不具合ではなく、正常動作のことも多いです。最初の通信でフローが入れば、以後は同じパターンの通信がコントローラに上がらなくなるからです。
実際にpingを何回か連続で打ってみると、最初の数回とその後でWireshark上の見え方が変わります。ここを観察すると、「OpenFlowで制御されている感覚」がかなり得られます。
OpenFlow解析を効率よく進めるコツ
OpenFlowをWiresharkで見る作業は、最初はどうしても画面に圧倒されがちです。ですが、見る順番を決めておくとかなり楽になります。
まずは接続直後のメッセージを見る。次にPacket-Inが出る瞬間を探す。そのあとにFlow-Modを追う。この順番だけでも、かなり理解しやすくなります。
私自身、最初はパケット一覧を上から順番に読もうとして挫折しました。しかし、イベントの意味ごとに探すようにしてからは、かなり楽になりました。OpenFlow解析は、全件精読よりも「重要な転換点を見つける」発想のほうが向いています。
openflow wiresharkで悩んだら思い出したいこと
OpenFlowをWiresharkで見る作業は、理屈だけなら難しくありません。けれど実際には、表示されない、場所が違う、最初の通信を逃すといった小さなつまずきが連続しやすい分野です。
だからこそ、うまくいかないときは難しいことを考えすぎず、監視インターフェース、キャプチャ開始タイミング、TCPポート、表示フィルタの順に確認していくのが近道です。私も何度か遠回りしましたが、結局はそこに戻ることで解決できました。
OpenFlowの理解を深めたいなら、Wiresharkはとても有効です。Packet-In、Flow-Mod、Packet-Outの流れが自分の目で追えるようになると、設定やコードの意味がぐっと立体的に見えてきます。まずは小さな環境で、最初の1本のOpenFlow通信をきちんと捕まえるところから始めてみてください。
コメント