要約

  • RFC 5309は媒体種別とIGPのネットワーク種別を分離する。LAN上でP2P動作を選べるが、正しいマルチキャストMACとVLANは引き続き必要である。
  • 両端の設定が一致しなければHelloは破棄され、フォールバックはない。隣接成立後もIP転送にはARP、ND、静的設定またはMAC学習が要る。

消えたのは擬似ノードだった

ブロードキャスト回線ではDR/DISと仮想的なネットワーク表現が多参加者をまとめる。二台だけの物理LANまたはVLANなら、直接のP2Pリンクとして表現する方が簡潔である。選挙や擬似ノード、LAN固有のフラッディング処理を省ける。

ただし、二台だけだという事実をIGPが測るわけではない。設定がそう宣言する。スイッチ側で第三ポートが同じVLANへ加わっても、P2Pコマンドは自動で撤回されない。

IS-IS制御パケットはリンク層ではなおLANフレームであり、AllISsが推奨される。VLAN IDも正しくなければならない。論理モデルの単純化は、フレーム配送を置換しない。

合意できなければ止まる

P2P設定側がLAN Helloを受けた場合、またはLAN設定側がP2P Helloを受けた場合、パケットは破棄される。確立済み隣接と異なるSystem IDやRouter IDも破棄対象である。

両端は拡張を実装し、同じ設定を選ばなければならない。意見が違えば隣接は形成されず、手動変更以外のフォールバックはない。これは誤りを別の意味へ自動変換しない設計である。

変更管理は二端を一つの契約として扱う必要がある。実行順序、予想停止時間、Hello種別、相手ID、破棄カウンタ、対称なロールバックを記録する。片側のCLI成功は完了証明ではない。

制御フレームからデータフレームへ

通常のP2P媒体なら送信先は一つで、IP next hopを省略できる。LANではEthernet宛先MACが必要なため、RFC 5309は隣接ルータの有効なインターフェースまたは内部IPをnext hopに求める。

IPv4 unnumberedでは借用した内部アドレスをARPが解決し、実装によっては送信元がローカルサブネットに属するという検査を緩和する。IPv6ではlink-localアドレスをNDが解決する。

MACを静的設定する方法、ルーティングプロトコルを運んだフレームから学習する方法もある。後者ではHello到着がMACの材料になるが、その値が正しいVLANのFIBへ入り、期限内で、実データに使われたことは別に確かめる必要がある。

マルチキャストHelloは届き続けても、ユニキャストのneighbor bindingが失効すればデータは止まり得る。隣接Upと転送失敗は矛盾ではない。

省アドレスと観測の交換

unnumberedはアドレスを節約する一方、個別インターフェースをpingする手段を失わせる。ポート/VLAN、隣接ID、ARP/ND、MAC由来、FIB、カウンタ、往復プローブで証拠を補うべきである。

多接続LANを多数の二台VLANへ分割すると、各関係は単純になるが、LSDB、フラッディング、計算量は増え得る。一か所の簡潔さが全体のスケールを改善するとは限らない。

範囲

RFC 5309はInformationalでありInternet Standardではない。現在の製品、VLANの排他性、独自MAC解決の相互運用、実転送は別の証拠を要する。RFC 5303の三方向状態、RFC 5304の認証、RFC 5305のリンク属性も、MAC解決やパケット配送の代わりにはならない。

実運用では両端設定、Hello、ID、VLAN、隣接、next hop、ARP/NDまたはmapping、route/FIB、パケット、サービス結果を追う。P2Pという名前が証拠連鎖を短縮するわけではない。

出典