手当たり次第に書くんだ

飽きっぽいのは本能

VyOS VPP の適用条件 – 本番ルーターで dataplane を分けて考える

作者: si62512548投稿日: カテゴリー: VyOSタグ: , , , , , , , , , , , , , , , , VyOS VPP の適用条件 – 本番ルーターで dataplane を分けて考える へのコメントはまだありません

VyOS VPP は、VyOS で VPP dataplane を扱うための機能です。vyos vpp で調べると高速化の話に見えますが、実運用では Linux kernel dataplane を単純に速くする設定ではなく、パケット処理をどの dataplane に任せるかを決める設計テーマになります。

特に、既存の VyOS ルーターが Firewall、NAT、PBR、QoS、OSPF、DHCP、DNS forwarding、VPN、PPPoE、管理系 VRF まで担当している場合、VPP 化は interface の置き換えでは済みません。高速化できる場所と、従来の VyOS 機能に残す場所を分けて考える必要があります。

この記事では、VyOS VPP を本番ルーターに入れる前に確認したい適用条件を、dataplane の責務分界、既存機能との関係、切り戻しのしやすさから確認します。結論から言えば、VPP は有力な技術ですが、統合ルーター全体をそのまま置き換える前提では扱いにくい選択肢です。

まず結論

今回の構成では、既存の物理 VyOS ルーター全体を VPP dataplane へ移す判断はしません。理由は、性能面では魅力があっても、制御面の依存関係が多すぎるためです。

観点判断
単純な L3 forwardingVPP の得意領域。検証対象としては十分に価値がある
PBR / Firewall / QoSLinux kernel dataplane 側の適用点に依存している場合、そのままでは前提が崩れる
PPPoE / NAT / VPN外部接続や状態管理と密結合しやすく、初期移行対象として重い
OSPF / service listenFRR や DHCP / DNS などの control plane / service plane との境界確認が必要
本番ルーター全体interface 置換ではなく、dataplane 責任分界の再設計になる

つまり、VPP が悪いという話ではありません。VPP に向いた dataplane と、Linux kernel / VyOS 通常機能に任せるべき制御機能を混ぜたまま導入しようとすると、運用上の説明責任が曖昧になる、という話です。

VPP は Linux kernel dataplane の高速版ではない

まず前提として、VPP は Linux kernel dataplane を単純に高速化したものではありません。VyOS の公式ドキュメントでも、VPP dataplane は性能上の利点を持つ一方で、Linux kernel dataplane の全機能と feature parity があるわけではないと説明されています。

これは非常に重要です。既存の VyOS 設定で動いている Firewall、PBR、QoS、NAT、service listen、routing protocol が、VPP 側の forwarding path にそのまま同じ意味で適用されるとは限りません。

層主な役割VPP 化時の論点
Linux kernel dataplane通常の interface、routing、nftables、QoS、conntrack など既存の VyOS 機能がここに依存している場合が多い
VPP dataplaneuserspace packet processing、DPDK、VPP ACL、VPP NAT、tunnel など高速だが、使える機能と運用方法を個別に確認する必要がある
control plane / service planeFRR、DHCP、DNS forwarding、NTP、管理アクセスなどどの interface / dataplane から到達させるかを設計する必要がある

対象環境は単純な L3 ルーターではない

検討対象は、単純な Ethernet forwarding 装置ではなく、実運用中の物理 VyOS ルーターです。このルーターは、内部 routing、外部接続、VPN、NAT、Firewall、管理系、監視までを一台で受け持っています。

  • IPv4 / IPv6 dual stack routing
  • OSPF / OSPFv3
  • Static route redistribution
  • Policy Based Routing
  • Firewall
  • NAT44 / NAT66
  • PPPoE
  • OpenVPN site-to-site
  • GRE tunnel
  • DHCP server / DNS forwarding / NTP
  • QoS
  • management VRF
  • Prometheus exporter / LLDP

このような構成では、interface は単なる port ではありません。経路制御、セキュリティ、NAT、QoS、管理アクセス、監視の適用点です。そのため、VPP 化の影響は interface 単位ではなく、ルーター全体の責務に波及します。

bond0 は性能面では候補だが制御面では重い

最初に VPP 化の候補に見えたのは内部側の bond0 です。内部 core 側の高速転送経路であり、MTU 9000 の jumbo frame と LACP bonding を使っているため、性能面だけを見ると VPP の対象として自然に見えます。

しかし、bond0 は単純な uplink ではありません。OSPF / OSPFv3、DHCP、QoS、Firewall trust、PBR の適用点になっています。特に、source prefix に応じて routing table を分ける PBR が入っている場合、ここを VPP 側へ移すと既存の kernel dataplane 前提が崩れます。

bond0 ingress
  private / ULA 宛ては通常経路
  OSPF / OSPFv3 は通常扱い
  public 系 source は別 routing table
  IPv4 default は tunnel next-hop
  IPv6 default は tunnel next-hop

この構造では、bond0 は高速転送の入口であると同時に、経路制御上の分岐点でもあります。つまり、VPP 化するなら、PBR 相当の処理を VPP 側で持つのか、LCP 境界で吸収するのか、Linux routing table に残すのか、FRR との関係をどうするのかを決めなければなりません。

PPPoE / outside 側は初期移行対象にしにくい

外部接続側はさらに慎重に扱う必要があります。IPv4 は PPPoE 上で NAT masquerade、IPv6 は外側 interface で autoconf と NAT66、さらに outside firewall、MSS adjust、default route が絡みます。

  • PPPoE
  • IPv6 autoconf
  • NAT44 / NAT66
  • outside firewall
  • MSS adjust
  • default route
  • ISP 側接続性

ここを VPP 化する場合、単に forwarding path を速くするだけでは済みません。外部接続が落ちた時の切り戻し、NAT / Firewall の適用点、IPv6 prefix の扱い、PPPoE の制約、監視と障害解析まで含めて再設計になります。初期検証対象としては重すぎます。

VPP が向く領域

今回の検討から、VPP が向く領域もかなり明確になります。VPP は、既存ルーターの全部を置き換えるよりも、責務を限定した dataplane として使う方が筋が良いです。

向く領域理由
単純な高速 L3 forwarding制御点が少なく、VPP の性能面の利点を評価しやすい
DPDK NIC を使った dataplane 検証NIC queue、hugepages、CPU worker などを含めて性能検証しやすい
VPP ACL で完結する通信制御Linux firewall に戻さず、VPP 側で責務を閉じやすい
GRE / VXLAN / IPsec などの tunnel 検証VPP 側の機能範囲に収まる場合、NFV / CNF の研究対象になる
既存ルーターから分離した forwarding path本番ルーターの control plane と切り離して検証できる

逆に、Linux kernel firewall、interface ingress PBR、kernel QoS、PPPoE、NAT、VPN、DHCP、DNS forwarding、FRR、管理系 VRF が一台に密結合している場合は、導入難度が一気に上がります。

本番投入するなら分離設計が先に必要

本番に近い形で VPP を扱うなら、まず VPP に任せる領域を狭く切るべきです。既存ルーター全体を置き換えるのではなく、検証 VLAN、未使用 NIC、専用 forwarding segment、専用 tunnel endpoint のように、障害時の影響範囲を限定できる場所から始める方が現実的です。

段階内容
検証 1未使用 NIC または isolated VLAN で VPP interface を作る
検証 2DPDK driver、hugepages、CPU worker、queue 設定を確認する
検証 3VPP ACL / NAT / tunnel を単体で確認する
検証 4Linux kernel dataplane との境界、LCP、FRR、監視を確認する
本番判断既存ルーターの機能を置き換えるのではなく、VPP 専用 dataplane として責務を分ける

最終判断

今回の物理 VyOS ルーターに対して、VPP を本番 dataplane として全面導入することは見送ります。

理由は、bond0 に PBR、Firewall、QoS、OSPF / OSPFv3、DHCP が絡んでおり、outside 側にも PPPoE、NAT44、NAT66、Firewall、MSS adjust が密結合しているためです。この構成では、VPP 化による性能上の利点よりも、制御機能の再設計負荷と切り戻しリスクの方が大きくなります。

ただし、VPP 自体は今後も検証対象として残します。DPDK、VPP ACL、VPP NAT、GRE / VXLAN、CNF / NFV dataplane の研究には価値があります。重要なのは、既存ルーターの全機能を一気に VPP へ寄せることではなく、VPP に任せる dataplane を明確に切り出すことです。

まとめ

VyOS VPP は、高速な dataplane を作るための有力な選択肢です。しかし、実運用中の統合ルーターに対しては、Linux kernel dataplane の高速版として単純に扱うべきではありません。

PBR、Firewall、QoS、NAT、PPPoE、VPN、DHCP、DNS forwarding、OSPF / OSPFv3、管理系 VRF まで含むルーターでは、interface を VPP に移すだけでなく、どの機能をどの dataplane が責任を持つのかを設計し直す必要があります。

今回の結論は、VPP は本番ルーター全体の置換先ではなく、責務を限定した高速 dataplane として扱うべき というものです。性能を上げるために制御点を失うのではなく、性能を求める場所だけを切り出す。その順序が重要です。

参考資料

関連記事

関連する記事
VyOS VPP の適用条件 – 本番ルーターで dataplane を分けて考える

関連記事

VyOS インターフェイス設計 – Ethernet / Bonding / Loopback / VRF の役割 VyOS は今後どうなるのか – ソフトウェアルーターとしての見方 VyOS OpenVPN Site-to-Site TLS 設定 – MTU / MSS / ルーティングを合わせて考える VyOS PPPoE インターネット接続設定 – Firewall / NAPT / MTU を確認する VyOS ネットワーク設定ガイド VyOS PBR 設定 – Policy Based Routing の基本 VyOS NAPT 設定 – IP マスカレードで LAN から外へ出す VyOS DNAT / NAT66 destination 設定 – 公開サービスへの転送と Firewall

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る