Geekly Articles each Day

難しい言語でのOpen vSwitchのセットアップについて

翻訳者から
SDN-ソフトウェア定義ネットワーク-は私たちの生活にしっかりと入っていますが、ロシア語での低レベルの仕事についてはあまり資料がありません。 VLANをサポートする自律型仮想スイッチを作成する例を示すトレーニング記事の翻訳に注目してください。 そのような基本機能のスイッチは、ネットワークコントローラーがなくても機能します。 想定される。 読者は一般的なネットワーク構築の基本と用語に精通しており、ソフトウェア定義ネットワークの一般的な考え方も持っていることを理解してください。

使用される用語：

OpenFlowは、ネットワーク内のデータ転送を管理するためのプロトコルです。 コントローラとスイッチ間の相互作用のプロセス、およびスイッチにロードされるルールの形式を説明します。
Open vSwitchは、OpenFlowプロトコルと互換性のあるスイッチのソフトウェア実装です。 OpenStackやoVirt（実験的）などの仮想化システムのトラフィックを制御するために使用されます。
802.1Q（VLAN）-単一のスイッチ内およびローカルネットワーク内の両方でトラフィックを区切るためのメカニズム。 データパケット内のVLANタグ（番号）の実装に基づく
802.1p（QoS）-トラフィックの優先順位付け制御メカニズム。 802.1Q標準の一部
集約ポート（トランクポート）-アップストリームスイッチに接続されているスイッチポート。 集約ポートにより、任意のVLAN番号でパケットを送信できます
アクセスポート—特定のVLANからのパケットのみを許可するスイッチポート。

はじめに


Webには多くのOpenFlowの基本ガイドがありますが、この記事は別の記事です。 ただし、この記事を理解するには、OpenFlowの基本的な知識が必要です。 OpenFlowルールがどのように機能するかを完全に理解していない場合は、 基本 を学習してからこの記事に戻ってください。
また、Open vSwitchの基本に関する知識も必要です。 ovs-vsctlまたはovs-ofctl管理ユーティリティを使用したことがない場合は、続行する前にそれらについて少し読む必要があります。

このガイドで説明されている機能のほとんどは、Open vSwitchに実装されているOpenFlowプロトコルの拡張バージョンに関連しています。ASICチップに基づくスイッチの形でハードウェア実装を使用する場合、このガイドは役に立ちません。

議論される技術の背景全体を詳細に検討することはしません。 詳細については、Open vSwitchのドキュメント、特にovs-vsctlヘルプファイル、およびinclude / openflow / nicira-ext.hおよびinclude / openvswitch / meta-flow.hファイルのコメントを参照できます 。

はじめに


Open vSwitchの実行可能ファイルがシステムにすでにインストールされていると想定しています。 コンピューター自体以外の特別なハードウェアは必要ありません。 代わりに、 ここにあるovs-sandboxスクリプトを使用します 。 このスクリプトは、Open vSwitchに基づいてソフトウェア定義のネットワーク環境を作成するために必要です。

ovs-sandboxは、次の3つの方法で使用できます。


スクリプトは次のことを行います。

  1. 注意：現在のディレクトリのsandboxという名前のサブディレクトリおよびこのサブディレクトリ内のすべてのファイルからすべてのサブディレクトリを削除します
  2. 現在のディレクトリに新しいサンドボックスディレクトリを作成します。
  3. 環境変数を設定して、Open vSwitchユーティリティがOpen vSwitchインストールディレクトリではなく、「sandbox」ディレクトリを現在のディレクトリとして使用するようにします。
  4. Open vSwitchをビルドしたがインストールしなかった場合、ヘルプファイルが「sandbox」サブディレクトリにコピーされ、このサブディレクトリの名前がMANPATH環境変数に書き込まれます。 これは、たとえば、man ovs-vsctlコマンドを使用すると、ビルドしたOpen vSwitchのバージョン専用のヘルプが表示されることを意味します。
  5. 「sandbox」ディレクトリに空のOpen vSwitch構成データベースを作成します
  6. 「sandbox」ディレクトリでovsdb-serverを起動します
  7. 「sandbox」ディレクトリでovs-vswitchdを実行し、特別なテストモードのパラメーターを渡します。
  8. サンドボックスディレクトリからインタラクティブシェルセッションを開始します

これ以降、使い慣れたすべてのOpen vSwitchコマンドをシェルセッションから実行できます。 たとえば、ovs-vsctlを実行して仮想スイッチを作成できます。

 $ ovs-vsctl add-br br0

Open vSwitchの観点から見ると、作成したスイッチは他のスイッチと同じくらいリアルです。 たとえば、OpenFlowコントローラーに接続するか、ovs-ofctlを使用して、トラフィック制御ルールを確認および変更できます。 一方、スイッチはホストネットワーク構成に表示されないため、ifconfigおよびipユーティリティはスイッチを使用できません。 さらに、pingおよびtcpdumpユーティリティも機能しません。 しかし、これには良い面もあります。サンドボックスのスイッチ設定を変更してホストネットワーク設定をノックダウンすることはできません。

Open vSwitchでの作業を終了する必要がある場合は、シェルで「終了」コマンドを入力するか、Ctrl + Dを押します。 これにより、ovs-sandboxスクリプトによって開始されたプロセスは終了しますが、「sandbox」ディレクトリの内容はすべてそのまま残されます。

サンドボックスディレクトリには、すべてのOpen vSwitchサービスのログファイルが含まれているため、Open vSwitchでの作業が終了した後にそれらを表示できます。

GDBデバッガーの使用


このチュートリアルでは、GDBデバッガーを必ず使用する必要はありませんが、GDBを使用してOpen vSwitchユーティリティの内部構造を理解できます。

GDBは、gdb <process-id>コマンドを使用して、既に実行中のプロセスをデバッグするために使用できます。

ovs-sandboxスクリプトには、GDBでovs-vswitchdを実行する-gオプションがあります。 このパラメーターは、ovs-vswitchdを実行する前にブレークポイントを設定する必要がある場合、またはサービスを開始する初期段階で障害をデバッグする必要がある場合に使用できます。 さらに、GDBの下でovsdb-serverサービスを開始する-dオプションがあります。 両方のパラメーターを同時に使用できます。

また、GDBの下でovs-vswitchdサービスを開始する-eオプションもありますが、gdb>プロンプトを表示せず、コマンドの入力を待機しませんが、すぐにサービスの実行を開始します。 -rオプションを使用すると、ovs-vswitchdと同様に、ovsdb-serverサービスがGDBですぐに開始されます。

GDBを起動するときの誤った端末の動作を避けるために、ovs-sandboxスクリプトは、GDBセッションごとに新しいxtermセッションを開きます。 X Windowsグラフィックサーバーのないシステムでは、GDBサポートは無効になっています。

メイクファイルからテスト環境を開始する場合、SANDBOXFLAGS環境変数を使用して-gパラメーターをスクリプトに渡すことができます。 したがって、make sandboxコマンドSANDBOXFLAGS = -gは、GDBデバッガーの別のX端末のovs-vswitchdサービスでテスト環境を起動します。

問題の声明


このガイドの主な目的は、広範なOpen vSwitchトラフィック管理機能を実証することです。 作業の過程で、MACアドレスを保存し、アクセスポートと集約ポートをVLANで分離できるスイッチを構築します。 少し後で説明するOpen vSwitchの機能を考慮しない場合、OpenFlowはそのようなスイッチを実装する少なくとも2つの方法を提供します。


残念ながら、両方のアプローチに欠点がないわけではありません。 前者の場合、コントローラーを使用すると、帯域幅が大幅に減少し、遅延が増加します。 さらに、コントローラーは多数のスイッチに対応するために適切に拡張できません。これは、それぞれが独自のOpenFlowスイッチを持つ数千のハイパーバイザーの環境で特に重要です。 当然、コントローラーを使用したMACアドレスの保存は、コントローラーに障害が発生したり、要求の処理が遅くなったり、ネットワークの問題が原因で利用できない場合は機能しません。

2番目のケース（通常）では、別の種類の問題を扱っています。 まず、「通常の」動作のごく一部のみが標準化されており、異なるメーカーの機器では異なる動作をします。 使用可能な機能とそれらを構成する方法（原則として、OpenFlow経由ではありません）はメーカーによって異なります。 第二に、NORMALモードは他のOpenFlowルールとの組み合わせではうまく機能しません。 NORMALは「all or nothing」の概念を実装しており、その動作をカスタマイズしたり、他の機能と対話したりする可能性が非常に限られています。

テストスクリプト


OpenFlowスイッチを構築し、MACアドレスを保存してVLANを操作するためのテーブルを構成します。 スイッチには4つのポートがあります。


ポート名は問題ではありません。eth1-eth4などの名前を付けることができます。
OpenFlowスイッチには1つのポートもあり、ホスト上でローカルインターフェイスとして表示されます。 このスクリプトはその使用を提供していません。

このスイッチには、ルールを含む5つのテーブルが含まれ、それぞれがトラフィック処理パイプラインの一部を実装します。


以下に、このようなスイッチをテーブルごとに作成する方法を示します。

以下の例のパラメーターを使用してovs-vsctlおよびovs-ofctlコマンドをコピーし、ovs-sandboxによって作成されたシェルに貼り付けることができます。 パラメーター付きのovs-appctlコマンドはテスト用であり、他の例とは別に使用しないでください。

設置


ovs-sandboxを実行し、開く対話型シェルで次のコマンドを入力します。

 $ ovs-vsctl add-br br0 -- set Bridge br0 fail-mode=secure

このコマンドは、新しい仮想スイッチbr0を作成し、いわゆるフェールセキュアモードにします。 現時点では、これはスイッチが空のテーブルで始まることを意味するだけです。

そうしないと、スイッチはNORMAL動作を満たす単一のルールで開始されます。 この機会を利用して、上記と同じスイッチを作成できますが、上記の「問題の設定」セクションで説明した制限があります。

これまでの新しいスイッチには、ローカルbr0という1つのポートしかありません。 ポートp1、p2、p3、およびp4を追加する必要があります。 コマンドのシェルは、これを行う1つの方法です。

 $ for i in 1 2 3 4; do ovs-vsctl add-port br0 p$i -- set Interface p$i ofport_request=$i ovs-ofctl mod-port br0 p$i up done

チームはポートを追加するだけでなく、ポートp1がOpenFlowのポート1と一致し、ポート2がOpenFlowのポート2と一致するようにofport_request属性も設定します。

ofport_request属性の設定をスキップして、OpenFlowが自分でポートを選択できるようにしますが、トレーニングのために、たとえばOpenFlowポート1について話すために自分でポート番号を割り当て、ポートp1を参照していることを認識します。

ovs-ofctlコマンドは、OpenFlowへの要求を使用して、作成時にオフになるインターフェースを起動します。 ifconfig upコマンドは同じ効果をもたらしますが、テスト環境インターフェースはホストOSに表示されず、ifconfigはそれらを制御できません。

トラフィック制御テーブルを使用して以下でこれを行う予定なので、まだVLANとMACアドレスストレージを構成していません。

作業の結果を確認するには、ovs-vsctl showまたはovs-ofctl show br0コマンドを使用できます。

テーブル0の作成：着信検査


表0には、スイッチに到着したばかりのパケットが含まれています。 何らかの理由でパケットを拒否するために使用します。 たとえば、ブロードキャスト送信者アドレスを持つパケットは正しくないため、スイッチの入り口でドロップできます。

 $ ovs-ofctl add-flow br0 "table=0, dl_src=01:00:00:00:00:00/01:00:00:00:00:00, actions=drop"

また、スイッチはIEEE 802.1Dスパニングツリープロトコル（STP）のパケットを転送してはならないため、このようなパケットおよび他の予約済みマルチキャストプロトコルのパケットを破棄するルールを追加します。

 $ ovs-ofctl add-flow br0 "table=0, dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0, actions=drop"

上記の原則に従って、他のプロトコルのパケットを拒否するルールを追加できます。

優先度がデフォルトの優先度よりも低い別のルールが必要です。これにより、より高いルールによって破棄されなかったパケットは、次の段階、つまりOpenFlowのテーブル1に進みます。

 $ ovs-ofctl add-flow br0 "table=0, priority=0, actions=resubmit(,1)"

再送信アクションは、OpenFlowのOpen vSwitch拡張機能の一部です。

表0を確認してください


Open vSwitchを使用して物理スイッチまたは仮想スイッチを構成する場合、たとえば、よく知られているpingおよびtcpdumpユーティリティまたはScapyなどのより特殊なツールを使用して、さまざまな方法でパケットを送信してテストする必要があります。 これは、オペレーティングシステムからは見えないため、仮想スイッチでは困難です。

ただし、仮想スイッチにはいくつかの特別なテストツールがあります。 最も広範な機能は、ofproto / traceを提供します。 スイッチ名とトラフィックの説明を入力として受け入れることにより、ofproto / traceがどのルールが影響を受けるかを段階的に示します。

例1


コマンドを試してください：

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:05

出力は次のようになります。

 Bridge: br0 Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:05,dl_type=0x0000 Rule: table=0 cookie=0 dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

最初の行は、コマンドラインで記述するよりも詳細な形式で、処理されたパッケージのパラメーターを示しています。

2番目の数行は、br0スイッチ内のパケットパスを示しています。 表0から、特定の優先度と特定のアクションを持つ対応するルールが見つかったことがわかります。 パッケージが複数のルールに該当する場合、そのような行がいくつかあります。

行の最後のグループには結果が表示されます。 ここでは詳しく検討しません。

例2


コマンドを実行してみましょう

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:10

その結論は次のようになります。

 Bridge: br0 Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:10,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:10,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:10/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:10/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

この場合、パケットはテーブル0の「ドロップ」アクションを含むルールに対応しないため、再送信アクションを含むルールに該当します。 再送信アクションは、次の行に示すように、パケットをテーブル1にリダイレクトします

 OpenFlow actions=resubmit(,1)

OpenFlowテーブル1にはまだルールが追加されていないため、パッケージはルールに準拠しません。 したがって、パケットは破棄されるため、サイドからの結果は最初の例と同じになります。

表1の作成：入力VLAN処理


表1に届くパケットは、表0のすべての基本チェックに既に合格しています。表1は、パケットをVLANに接続するためのものです。 このチェックは、VLANと、パケットがスイッチに入るポートの比較に基づいています。 また、テーブルを使用して、VLANヘッダーをアグリゲーションポートに向かうパケットに添付します。これにより、VLANに関連する処理ステップが遅延します。VLAN番号は常にヘッダーの一部であるためです（特別な場合を除く）。

すべてのパケットを破棄する優先度の低いルールを追加することから始めます。 その前に、必要なパッケージをスキップするルールを追加します。 「デフォルトで破棄」タイプのルールとします

 $ ovs-ofctl add-flow br0 "table=1, priority=0, actions=drop"

集約ポートp1（またはよりシンプルなOpenFlowポート1）は、VLANヘッダーがあるかどうか、およびこのヘッダーが何であるかに関係なく、すべてのパケットを受け入れます。 したがって、ポート1からのすべてのトラフィックを次のテーブルにリダイレクトするルールを追加できます。

 $ ovs-ofctl add-flow br0 "table=1, priority=99, in_port=1, actions=resubmit(,2)"

アクセスポートでは、VLANヘッダーのないパケットを受け入れ、対応するVLANを割り当てて、次のステージに渡すことができます。

 $ ovs-ofctl add-flows br0 - <<'EOF' table=1, priority=99, in_port=2, vlan_tci=0, actions=mod_vlan_vid:20, resubmit(,2) table=1, priority=99, in_port=3, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2) table=1, priority=99, in_port=4, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2) EOF

ルールは書きません。 アクセスポートに着信する既存のVLANタグ（802.1Q）を持つパケットを処理するため、これらのパケットはデフォルトで破棄されます。 これはまさにアクセスポートに期待される動作です。

その他の場合、アクセスポートはVLAN 0に属するパケット（つまり、802.1pトラフィックの優先順位付けメカニズムに従ってマークされたパケット）を渡します。 このようなパッケージを有効にするには、上記のルールでvlan_tci = 0をvlan_tci = 0 / 0xfffに置き換えます。

テスト表1


ofproto / traceユーティリティを使用すると、スイッチの入り口でVLANを管理するために追加されたルールを確認できます。

例1.集約ポート上のパケット


集約ポートからスイッチに着信したパケットを確認します。

 $ ovs-appctl ofproto/trace br0 in_port=1,vlan_tci=5

コマンドの出力から、パケットはテーブル0を通過し、テーブル1に送信され、次にテーブル2（まだルールはありません）に送信されます。

 Bridge: br0 Flow: in_port=1,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=1,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=1 OpenFlow actions=resubmit(,2) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

例2.アクセスポート上の有効なパケット


ポートp2に到着する正しいパケット（802.1Qヘッダーのないパケット）をテストしています：

 $ ovs-appctl ofproto/trace br0 in_port=2

このコマンドの出力は、前の出力と似ていますが、パケットにVLAN 20というラベルが付けられてから、表2に送信される点が異なります。

 Bridge: br0 Flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000 OpenFlow actions=mod_vlan_vid:20,resubmit(,2) Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

例3.ポートp2の無効なパケット（ヘッダー801.2Q）


 $ ovs-appctl ofproto/trace br0 in_port=2,vlan_tci=5

コマンドの出力は、パケットがテーブル1に到着し、デフォルトルールによって破棄されることを示しています。

 Bridge: br0 Flow: in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=0 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

テーブル2を作成する：着信ポートのMAC + VLANペアを覚えて


表2により、スイッチは指定されたポートおよびパケットVLANタグと一致する送信側MACアドレスを記憶できます。

次の表は、アクセスポートを介してスイッチに到着したパケットにVLANタグが追加された理由、つまり表1を示しています。パケットが到着したときにすでにVLANに属しているかどうかに関係なく、VLAN + MACペアをポートにマッピングしたいまたは、VLANタグがスイッチ自体によってパケットにスタンプされました。

私たちのアイデアを実現するために必要なルールは1つだけです。 ここにあります：

 $ ovs-ofctl add-flow br0 \ "table=2 actions=learn(table=10, NXM_OF_VLAN_TCI[0..11], \ NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]), \ resubmit(,3)"

学習アクションは、現在処理中のパッケージの内容に基づいてルールテーブルを変更します。 このアクションは、Open vSwitchに実装されているOpenFlowプロトコルの拡張機能です。

「学習」アクションのパラメーターは、次のように説明できます。

 table=10

表10を変更します。この表では、MACアドレスを記憶します

 NXM_OF_VLAN_TCI[0..11]

表10のルールを作成します。これは、現在のパケットのVLANと等しいVLANを持つすべてのパケットに対応します。これにより、VLAN対応スイッチが通常行うように、MACを単一のVLAN番号にマッピングできます。

 NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[]

パラメータ「受信者のMACアドレス」を作成されたルールに追加します。これは、現在のパケットの送信者のMACアドレスと等しくなります。

 load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]
前のコマンドは、新しいルールによって処理されるパケットのパラメーターを設定し、このコマンドはパケットに対するアクションを定義します。このアクションは、パケットがレジスタ0（OpenFlowプロトコルのOpen vSwitch拡張で定義された特別なフィールド）に入ったポート番号をロードします
MACアドレスを保存する実際のプロセスでは、さらに2つのパラメーターが関係する場合があります。最初に、「学習」アクションは新しいタイプのトラフィックのhard_timeoutパラメーターを設定して、合理的な時間内にこのアドレスからパケットが届かない場合にスイッチがMACアドレスを「忘れる」ようにする必要があります。次に、Open vSwitch構成データベースのFlow_Tableテーブルを使用して、表10の行数を制限することにより、リソース消費を制限する必要があります。

ルールがどのように機能するかを理解するための例が必ず必要です。

テスト表2


例1


開始するには、次のコマンドを実行します。

 $ ovs-appctl ofproto/trace br0 in_port=1,vlan_tci=20,dl_src=50:00:00:00:00:01 -generate

コマンドの出力は、「学習」アクションが完了し、新しいルールが表10に追加されたことを示しています。

 Bridge: br0 Flow: in_port=1,vlan_tci=0x0014,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=1,vlan_tci=0x0014,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=1 OpenFlow actions=resubmit(,2) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=2 cookie=0 OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x1fff,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

-generateオプションに注意してください。通常、ofproto / traceはシステムに影響を与えません。「output」アクションは実際にパケットを送信せず、「learn」アクションはテーブルを変更しません。-generateオプションを使用すると、ofproto / traceユーティリティはシステムに「学習」アクションを強制的に実行させます。これは、表10の「学習」アクションのアプリケーションを確認するために重要です。

コマンドを実行します。

 $ ovs-ofctl dump-flows br0 table=10

次のように表示されます。

 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=4315.181s, table=10, n_packets=0, n_bytes=0, idle_age=4315, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15]

VLAN 20および送信者アドレス50：00：00：00：00：01のパケットは、VLAN 20および受信者アドレス50：00：00：00：00：01のパケットに一致するルールの作成につながったことがわかります。ルールは、スイッチをテストしたポート番号1をレジスタ0にロードします。

例2


2番目のコマンドを実行します。

 $ ovs-appctl ofproto/trace br0 in_port=2,dl_src=50:00:00:00:00:01 -generate 

 Bridge: br0 Flow: in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000 OpenFlow actions=mod_vlan_vid:20,resubmit(,2) Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=2 cookie=0 OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Datapath actions: drop

このコマンドで作成されたパケットは、前の例と同じVLANとMACを持ちますが、アクセスポートから来て、最初はVLANタグを持ちません。前の例のパケットはアクセスポートから送信され、802.1Qヘッダーがすでにありました。表10の内容を印刷します

 $ ovs-ofctl dump-flows br0 table=10 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=4355.977s, table=10, n_packets=0, n_bytes=0, idle_age=4355, hard_age=15, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x2->NXM_NX_REG0[0..15]

パケットがポート2から送信されたという事実を反映して、ルールが変更されたことがわかります。これはまさに私たちが期待したものです。

テーブル3の作成：宛先ポート検索


このテーブルは、スイッチが宛先MACアドレスとVLAN番号に基づいてパケットを転送する宛先ポートを定義します。同じ送信者と受信者のアドレスを持つパケットが表2ですでに処理されている場合、すでに受信者のアドレスが保存されているので、すぐにパケットを転送します。

この場合、必要なルールは1つだけです

 $ ovs-ofctl add-flow br0 "table=3 priority=50 actions=resubmit(,10), resubmit(,4)"

このルールは最初にパケットをテーブル10にリダイレクトし、「学習」ルールを実行します。前述のように、保存されたパケットのポート番号はレジスタ0に書き込まれます。パケットの宛先ポートが記憶されていない場合、表10のルールは機能せず、「再送信」アクションは何も終了しません。レジスタはゼロに初期化されるので、次の処理段階のパケットをすべてのポートに送信する必要があることを示すインジケータとして、レジスタ番号0の値0を使用できます。

2番目のアクションは、パケットを表4にリダイレクトして、次の処理段階に送ります。

常にすべてのポートに送信する必要があるため、マルチキャストおよびブロードキャストパケットの表10の検索をスキップするルールをもう1つ追加できます。

 $ ovs-ofctl add-flow br0 "table=3 priority=99 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,4)"

ブロードキャストパケットは表10に表示されないため、マルチキャストプロトコルパケットを破棄する規則を表0に配置したため、上記の規則はあまり必要ありません。


テスト表3


例


このコマンドにより、Open vSwitchはVLAN'a 20のポートp1のアドレスf0：00：00：00：00：01を記憶します。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 -generate

コマンドからの出力は、表10に一致する行が見つからなかったため、パケットの受信者が不明であることを示しています。

 Bridge: br0 Flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=1 OpenFlow actions=resubmit(,2) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=2 cookie=0 OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=3 cookie=0 priority=50 OpenFlow actions=resubmit(,10),resubmit(,4) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: unchanged Megaflow: recirc_id=0,in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Datapath actions: drop

送信者のアドレスが記憶されていることを確認する2つの方法がある場合。最も簡単な方法は、次のコマンドを使用して表10の内容を表示することです。

 $ ovs-ofctl dump-flows br0 table=10

次のように表示されます。

 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=54.661s, table=10, n_packets=0, n_bytes=0, idle_age=54, vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15]

前の例を実行した場合、または独自のコマンドを実行しようとした場合、出力に追加の行が表示されます。これらの行は、コマンドの実行に影響しないはずですが、混乱を招く場合は、ovs-ofctl del-flows br0 table = 10コマンドを使用して削除できます。

2番目の方法は、アドレスを記憶するルールを実施するパッケージを生成することです。たとえば、ポートp2でパケットを生成し、その宛先アドレスをポートp1で記憶しました。

 $ ovs-appctl ofproto/trace br0 in_port=2,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01 -generate

コマンドの出力を以下に示します。アクション「resubmit（、10）」の操作を表示する行に注意してください。これらの行から、使用した最初のMACアドレスに基づいて作成されたルールにパケットが一致し、このルールがポート番号p1をレジスタ0にロードすると結論付けることができます。

 Bridge: br0 Flow: in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=2,vlan_tci=0x0000 OpenFlow actions=mod_vlan_vid:20,resubmit(,2) Resubmitted flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=2 cookie=0 OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=3 cookie=0 priority=50 OpenFlow actions=resubmit(,10),resubmit(,4) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Rule: table=10 cookie=0 vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 OpenFlow actions=load:0x1->NXM_NX_REG0[0..15] Resubmitted flow: reg0=0x1,in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x1 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,reg0=0/0xffff,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: reg0=0x1,in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 Datapath actions: drop

, , , MAC- . , ovs-appctl

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 -generate

, “load” 10 :

 Bridge: br0 Flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=0 cookie=0 priority=0 OpenFlow actions=resubmit(,1) Resubmitted flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=1 cookie=0 priority=99,in_port=1 OpenFlow actions=resubmit(,2) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=2 cookie=0 OpenFlow actions=learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]),resubmit(,3) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 Rule: table=3 cookie=0 priority=50 OpenFlow actions=resubmit(,10),resubmit(,4) Resubmitted flow: unchanged Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=10 cookie=0 vlan_tci=0x0014/0x0fff,dl_dst=90:00:00:00:00:01 OpenFlow actions=load:0x2->NXM_NX_REG0[0..15] Resubmitted flow: reg0=0x2,in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Resubmitted regs: reg0=0x2 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0 reg13=0x0 reg14=0x0 reg15=0x0 Resubmitted odp: drop Resubmitted megaflow: recirc_id=0,reg0=0/0xffff,in_port=1,vlan_tci=0x0014/0x0fff,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Rule: table=254 cookie=0 priority=0,reg0=0x2 OpenFlow actions=drop Final flow: reg0=0x2,in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Megaflow: recirc_id=0,in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 Datapath actions: drop

4:


4 0, , , 0 . , VLAN (802.1Q), .

— . p1:

 $ ovs-ofctl add-flow br0 "table=4 reg0=1 actions=1"

宛先ポートに送信するには、パケットを送信する前にVLANヘッダーを切り取ります。

 $ ovs-ofctl add-flows br0 - <<'EOF' table=4 reg0=2 actions=strip_vlan,2 table=4 reg0=3 actions=strip_vlan,3 table=4 reg0=4 actions=strip_vlan,4 EOF

ブロードキャスト、マルチキャスト、およびユニキャストパケットのごく一部については、宛先MACアドレスは記憶されません。この場合、ポートの出力パケットのみにVLANタグがあることを確認する必要があり、集約ポートではなくアクセスポートのみで送信する場合は802.1Qヘッダーを添付します。

 $ ovs-ofctl add-flows br0 - <<'EOF' table=4 reg0=0 priority=99 dl_vlan=20 actions=1,strip_vlan,2 table=4 reg0=0 priority=99 dl_vlan=30 actions=1,strip_vlan,3,4 table=4 reg0=0 priority=50 actions=1 EOF

ルールは標準のOpenFlowの動作に基づいており、出力ルールはパケットを送信元のポートに送信しないため、パケットがポートp1から送信され、宛先ポートをp1として記憶している場合、アクションでパラメーターを指定する必要がありますactions = 1、この場合、スイッチは送信元のポートにパケットを送信しません。マルチキャスト、ブロードキャスト、およびユニキャストパケットもこの規則に従います。

テスト表4


例1


VLAN 30でポートp1に到達したパケットパスをトレースしてみましょう。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=30

最も興味深いのは、コマンド出力の最後の行で、スイッチが802.1Qヘッダーを削除してから、VLANの出力ポートであるポートp3およびp4にパケットを送信することです。

 Datapath actions: pop_vlan,3,4

ポートp3に送信されたブロードキャストパケットのパスをトレースすると、同じことが起こります。

 $ ovs-appctl ofproto/trace br0 in_port=3,dl_dst=ff:ff:ff:ff:ff:ff

ここで、パケットはラベル802.1Qを使用してポートp1を出て、それなしでポートp4から出ていることがわかります。

 Datapath actions: push_vlan(vid=30,pcp=0),1,pop_vlan,4

Open vSwitchは、このエントリを4、push_vlan（vid = 30、pcp = 0）に簡素化できますが、そのためには十分にスマートではありません

次のコマンドもブロードキャストパケットを送信しますが、このようなVLANはポートp1にのみ存在できるため、破棄されます。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=ff:ff:ff:ff:ff:ff $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=55

ブロードキャストパケットを自分で送信してみてください。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=20 $ ovs-appctl ofproto/trace br0 in_port=2,dl_dst=ff:ff:ff:ff:ff:ff $ ovs-appctl ofproto/trace br0 in_port=4,dl_dst=ff:ff:ff:ff:ff:ff

同じ動作は、受信者アドレスを記憶できるマルチキャストパケットとユニキャストパケットでも観察できます。

 $ ovs-appctl ofproto/trace br0 in_port=4,dl_dst=01:00:00:00:00:00 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=90:12:34:56:78:90,dl_vlan=20 $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=90:12:34:56:78:90,dl_vlan=30

例2：MACアドレスの保存


表3の場合と同じようにします。最初に、VLAN 30のポートp1のMACアドレスを覚えておいてください。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_vlan=30,dl_src=10:00:00:00:00:01,dl_dst=20:00:00:00:00:01 -generate

出力の最後の行では、パケットの宛先アドレスが不明であることがわかります。そのため、VLAN 30が存在するポートp3およびp4に送信されます。

 Datapath actions: pop_vlan,3,4

次に、送信者と受信者のMACアドレスを交換し、ポートp4の受信者アドレスを記憶します

 $ ovs-appctl ofproto/trace br0 in_port=4,dl_src=20:00:00:00:00:01,dl_dst=10:00:00:00:00:01 -generate

コマンド出力の最後の行は、このパケットの宛先ポートがp1であることを示しています。これは前のコマンドの結果です

 Datapath actions: push_vlan(vid=30,pcp=0),1

最初のコマンドを再度実行します。

 $ ovs-appctl ofproto/trace br0 in_port=1,dl_vlan=30,dl_src=10:00:00:00:00:01,dl_dst=20:00:00:00:00:01 -generate

結果はブロードキャストではなく、1つの宛先ポート（p4）のみにパケットを送信することがわかります。

 Datapath actions: pop_vlan,4

これで、スイッチを使用する準備が整いました。

Source: https://habr.com/ru/post/J325560/

More articles:


All Articles