要約

  • revision 18 は、明示的な二重タグ、明示条件と any の組み合わせ、単一外側タグ、priority-tagged、untagged、default の順で分類する。同じ段階で同一フレームを奪い合う設定は拒否される。
  • この順序が示すのは、適合する分類器の選択である。適用済み状態、分離したカウンター差分、書換え前後のキャプチャ、FIB またはサービス接続、遠端での到達は別々に立証する必要がある。

外側が S-VLAN 10、内側が C-VLAN 21 のフレームを考える。10/21 の二重タグ規則、外側 10・内側 any、外側 10 だけの規則、default が並んでいる。四つの候補が見えても、受け取れるのは一つだけだ。

NETMOD 草案 revision 18 は、この選択を厳密に並べる。二つの明示値または範囲が第一、片側が明示・もう片側が any の二重タグが第二、単一の外側タグが第三である。その後に priority-tagged、untagged、default が続く。同順位で同じフレームに合致する範囲は装置が受理してはならない。

この規則は、設定順やベンダー固有の偶然を排除する。だが「10/21 はこのサブインターフェースへ行くはずだ」という予測を、「実際にサービスを通過した」という観測へ変えるものではない。

読むのは最大二枚のタグ

モデルの分類範囲は外側と第二タグまでである。二枚の場合は外側 S-VLAN、内側 C-VLAN が前提となる。match-exact-tags は優先順位を変えず、照合したタグで 802.1Q スタックが終わることを要求する。未設定なら追加タグを許すが、追加分はこのモデルでは不透明なペイロードとして扱われ、分類にも書換えにも参加しない。

従って 10/21 の成功試験は、10/21/300 の結果を保証しない。exact の有無を分け、両方の入力を実際にキャプチャしなければ境界を試したことにならない。

default は周囲の否定で成立する

default は単なる全一致ではない。より具体的な peer サブインターフェースが取らなかったフレームだけを受ける。default を証明するには、同階層の全規則と、それらのカウンターが増えなかった証拠が要る。

priority-tagged と untagged も異なる。前者には 802.1Q タグが残り、後者にはタグ EtherType がない。試験名ではなく入口キャプチャが、実行したケースを確定する。

分類に成功してもサービスは空かもしれない

柔軟なモデルは、分類後に外側タグを最大二枚 pop または push できる。変換は pop と push の組合せで表し、照合していないタグは pop できない。対称書換えと方向別書換えも区別される。

それでもフィールドは意図を記述するだけだ。草案の L2VPN 例には、フレームを分類してタグを除去できるが、サービスへ結び付いていないサブインターフェースが登場する。結果は drop である。正しい分類先が、転送先を持たない場合が仕様例の中に明示されている。

観測点をつないで初めて主張になる

最初に装置が公表するモジュール、revision、feature を保存し、NETCONF または RESTCONF の要求と応答を残す。次に intended と operational を比較する。RFC 8342 が示すように、資源不足などで意図した設定が適用されない場合がある。

次はトラフィック試験だ。親と全候補サブインターフェースの基準値を取り、一度に一種類のフレームだけを流す。インターフェース拡張 revision 19 の in-discard-unknown-encaps と、RFC 8343 の packet、octet、discard を組み合わせる。期待したサブインターフェースだけが増えれば分類を支持し、未知封装の負試験で discard だけが増えれば drop を支持する。

ただしカウンターは集計値である。入口キャプチャでタグスタックを、書換え後のキャプチャで実際の出力バイトを確認する。L3 では RFC 8349 の active route もコントロールプレーン情報にすぎない。FIB、隣接、想定出口、遠端受信まで追う。L2VPN ならローカルと遠端の attachment を調べる。

最終的な表現は限定的でよい。このフローが、この時間帯に、このタグで入り、このカウンターを動かし、このバイト列で出て、この遠端に届いた。明確な分類規則は、この文章を試験可能にする。真実にするのは観測である。

一次資料

閉じた一次資料集合は、revision 18 の二つの公開形式、Datatracker の文書ページと履歴、補完するインターフェース拡張ドラフトの二つの公開形式、RFC 6241、7950、7799、8040、8341、8342、8343、8349で構成する：https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.html; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/history/; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc7799.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8343.html; https://www.rfc-editor.org/rfc/rfc8349.html。