☰

Open vSwitchデータパスとLinuxブリッジ

tag-icon • tag-icon networking bridge iproute
Open vSwitchデータパスとLinuxブリッジ

私は、Open vSwitchがLinuxインフラストラクチャの内部要素、特にOVSブリッジとbr-xx（Linuxブリッジ）の違いをどのように活用するかを理解しようとしています。私はこの分野に慣れていないので、いくつかのレベルで間違っている可能性があります。

背景：これまで、仮想ネットワークを作成するためにネットワークネームスペースを使用してホスト（ネットワークのエンドポイント）をシミュレートし、vethペアを2つのノードを接続するリンクとして使用できることを知っています。また、iproute2パッケージを使用すると、ブリッジ（br-xx）を設定し、ここに仮想インターフェイスを追加して仮想ネットワークを完成させることができます。

OVSブリッジとiproute2で作成されたLinuxブリッジの違いを理解するために、mininetコードを見ました。私が知っていることの1つは、mininetがovs-vsctlを使用してOVSブリッジを生成することです。私はOVSコードを調べて、実際にどのように設定されているのか、そしてLinuxブリッジとどう違うのかを調べましたが、大きな成功を収めませんでした。

質問：OVSブリッジ（ovs-vsctlを使用して作成）とLinuxブリッジ（iproute2を使用して作成）の内部違いは何ですか？私は直感的に両方の背後にある2つの異なるカーネルモジュールに基づいていると思います（Open vSwitchの文脈ではデータパスと呼ばれ、Linuxブリッジのカーネルモジュールが何であるかはわかりません）。私の直感は正しいですか？それでは、独自のカーネルモジュールを作成し、それを「バックエンド」として使用してブリッジを設定するにはどうすればよいですか？

答え1

ここでいくつかの理解を共有すると、このレベル/側面に多くの努力を払わないため、これは思ったほど低いレベルではないかもしれません。

まず、Linuxブリッジはカーネルスタックに依存しています。シンプルL2転送。つまり、パケットはシステムARPキャッシュに格納されているマッピングルールsrc_macに従って転送されます。in_port

転送ルールのリスト（マッピング）iproute2：

$ ip neigh show
192.168.157.2 dev ens33 lladdr f0:50:54:fd:b2:34 STALE
192.168.157.254 dev ens33 lladdr f0:50:54:fd:b2:34 STALE

昔ながらの印刷がきれいなコマンドを使用してくださいarp。

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.157.2            ether   f0:50:54:fd:b2:34   C                     ens33
192.168.157.254          ether   f0:50:54:fd:b2:34   C                     ens33

さらに、すべての一般的なネットワークツールは、Linuxブリッジ（veth pair、tun / tap）のデバイスで正常に動作します。

flow table代わりに、OVSはそれぞれと呼ばれる独自の転送テーブルと転送ルールを維持しますflow。パケットがOVSブリッジに入ると、フロー（ルール）と一致することを確認してから、ルールで指定された操作を実行します。この配信メカニズムは、より柔軟でスケーラブルであり、最も重要なのはプログラミングが可能です。

次のフローテーブルの2番目のルールを例に挙げます。

$ ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x9661, duration=8986958.206s, table=0, n_packets=2285, n_bytes=82852, idle_age=0, hard_age=65534, priority=1 actions=NORMAL
 cookie=0x9661, duration=2944224.063s, table=0, n_packets=148, n_bytes=32018, idle_age=0, hard_age=65534, priority=3,in_port=1,dl_vlan=18 actions=mod_vlan_vid:43,NORMAL
 cookie=0x9661, duration=8986823.648s, table=0, n_packets=9151, n_bytes=17148, idle_age=0, hard_age=65534, priority=3,in_port=1,dl_vlan=21 actions=mod_vlan_vid:7,NORMAL
  • in_port=1一致基準：VLANタグ18（）を持つポート1（）のdl_vlan=18着信パケット（このOVSブリッジへ）
  • 処置：データパケットのVLANタグを43（）に変更してから、OVSブリッジ内でmod_vlan_vid=43通常のL2転送を実行してください（）（）。NORMALbr-int

そのsrc_mac:in_portマッピングはそれ自体fdb（転送データベース）にも保存されます。

$ ovs-appctl fdb/show br-int
 port  VLAN  MAC                Age
    1     5  fb:26:3f:e8:1e:1c  298
    1     8  fb:26:3f:b7:26:55  297

具体的には、フローテーブルに他のルールが指定されていない場合、OVSブリッジはデフォルトルール（action=NORMAL）に従い、通常のLinuxブリッジと同様に通常のL2転送を実行します。。

第二に、OVSはカーネルスタックからパケットを抽出するため、カーネルスタックに依存するネットワークツールは、OVStcpdumpからパケットをキャプチャできないなど、OVSデバイス（ポート）で動作を停止でき、ルールはpatch portOVSiptablesでは機能しません。両方のポートを使用してください。

第三に、実装に関して：Linuxブリッジは非常に簡単です。それはおそらくカーネルスタックの中で最も初期のネットワークデバイスの1つであり、たった数百行のコードしか必要ありません。確認してみてください。ここにコードを入力してくださいカーネル5.1で。これとは対照的に、OVSコードは、プログラム可能で強力で効率的で、すべての機能を備えたOpenFlowスイッチで処理する必要がある部分が多いため、はるかに複雑です。最新情報を入手するには、機能が少ない以前のバージョンを確認してください。

関連情報