はじまり
先日 GNS3 + Nested KVM + OpenStack with RDO でOpenStack環境を構築できることを確認した。
その際、VXLANを用いた仮想サブネットを構築したわけだが、これは単純に考えるとループが発生するトポロジとなる。
今回は、br-tunにインストールされたフローエントリから、トンネルを用いたOpenStackの仮想サブネットがどのようにループを防止しているかを見ていく。
初見
まずは、前回のOpenStackの仮想サブネット構成を例に、仮想スイッチの構成を見てみよう。
compute02で見た場合の仮想スイッチの構成(例)
|
|
問題意識
さて、普通にOpen vSwitchのVXLANを複数点で接続すると、下図のようなループが発生することが予想される。
が、当然OpenStackではループでネットワークの身動きが取れないと言った状況は発生していない。
この問題は、単純に考えると「トンネルから入ってきたパケットは、トンネルにはフラッディングしない」ことで解決すると考えられる。
そして、OpenStackの作るフローエントリはまさにそういう状況になっているのだろう。
答え合わせ
では、同仮想スイッチのフローエントリを見てみよう。
compute02で見た場合の仮想スイッチのフローエントリ(例)
|
|
見やすくするため、不要部分を削って列を揃えて並び替えてテーブル毎で区切るとこうなる。
|
|
文字を追うのはつらいので、雑な絵に描き起こすとこうなる。
と言うわけで、こんな風に「トンネルから入ってきたパケットはフラッディングせず、Uplinkにのみ投げる(Table=10)」と言う状況を実現している。
つまりこうだ。
br-tunを1つのインタフェースとして見れば、これはSplit-Horizonと同義と言える。
そして、この挙動自体はbr-tunを作らない(即ち、br-intに直接VXLANインタフェースを作る)場合でも実現は出来るが、その場合は仮想マシンの数に合わせてフローエントリを増やさなければならず、しかも既存のフローエントリのoutputを変更する必要も出てくる。
br-tunにトンネルインタフェースを専任させることで、トンネルインタフェースとUplink(br-int向)インタフェースをシンプルに分けることが出来るので、フローエントリもスッキリする。
もちろん、これはフルメッシュ構造が基本で、トンネルトポロジがスター型だったりするとパケットが届かない場所が出てきたりするので、使い分けが必要な話。
こいつは当然GREの時点から考慮されていたもので「VXLANでも使えるけどユニキャストなトンネルインタフェースで共通」なお話である。
まとめ
OpenStackはbr-tunをトンネル専用インタフェースとすることで、フローエントリを抑えてSplit-Horizonを実現している。
当然、ovs-ofctl del-flows br-tunを叩くと、トポロジを維持したままループが発生する状況を作れてしまうので、 SDNコントローラ開発中に誤ってbr-tunのフローエントリを消してしまわないよう留意する必要があるだろう。
と言うお話だったとさ。