はじめに
VyOS rolling では VPP dataplane の利用が進みつつあり、従来の Linux kernel dataplane とは異なる高速なパケット処理基盤として注目できます。VPP / DPDK を利用することで、単純な L3 forwarding や特定の dataplane 処理において性能上の利点を得られる可能性があります。
一方で、実運用中のルーターに VPP を導入する場合、単純に「interface を VPP に置き換えればよい」という話にはなりません。特に VyOS の通常機能を組み合わせて、Firewall、NAT、PBR、QoS、OSPF、DHCP、DNS forwarding、VPN などを一台に集約している構成では、VPP 化は interface の置換ではなく、dataplane の責任分界を再設計する作業になります。
本記事では、自宅インフラの物理 VyOS ルーターを対象に、VyOS VPP の導入可能性を検討した結果を整理します。
対象環境の概要
検討対象は、実運用中の物理 VyOS ルーターです。
このルーターは、単純な Ethernet / L3 forwarding 装置ではなく、以下のような複数の機能を同時に担っています。
- 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
- Web proxy
- QoS
- management VRF
- Prometheus exporter
- LLDP
interface 構成としては、内部側に eth1 と bond0、外部側に eth4 と pppoe0、管理系に eth0 + mgmt VRF、VPN / tunnel 系に vtun1000 と tun1000 が存在します。
このうち特に重要なのが bond0 です。bond0 は単なる内部 uplink ではなく、OSPF / OSPFv3、DHCP、QoS、Firewall trust、PBR の適用点になっています。
最初の仮説
当初は、VPP の導入候補として bond0 が最も自然に見えました。
理由は単純です。bond0 は内部 core 側の高速転送経路であり、MTU 9000 の jumbo frame を使用し、物理 NIC を LACP bonding しているためです。高速 dataplane の恩恵を受ける対象としては、外部 PPPoE 側よりも内部 forwarding 側のほうが適しているように見えます。
しかし、設定を確認すると bond0 は単純な forwarding interface ではありませんでした。
bond0 には IPv4 / IPv6 の Policy Based Routing が直接適用されており、source が public 系 prefix に該当する通信を routing table 10 に振り分けています。そして table 10 の default route は tunnel 側に向いています。
概念的には、以下のような構造です。
bond0 ingress
├─ 宛先 private / ULA は通常経路
├─ OSPF は通常扱い
└─ source public は table 10
├─ IPv4 default -> tunnel next-hop
└─ IPv6 default -> tunnel next-hop
つまり bond0 は、高速転送の入口であると同時に、経路制御上の重要な分岐点でもあります。
VPP 化で問題になる点
VyOS VPP を利用する場合、パケット転送の主経路は Linux kernel dataplane ではなく VPP dataplane 側へ移ります。
そのため、Linux kernel 側の interface に適用されている機能は、そのままでは VPP dataplane 上の転送に効きません。
今回の構成では、特に以下が問題になります。
| 機能 | 現行構成 | VPP 化時の論点 |
|---|---|---|
| PBR | bond0 ingress に適用 | pure VPP path では kernel PBR が効かない |
| Firewall | VyOS firewall / nftables 前提 | VPP path では kernel firewall の適用点を通らない |
| QoS | bond0 egress に適用 | kernel QoS の前提が崩れる |
| OSPF / OSPFv3 | bond0 / tun1000 / lo で動作 | FRR と VPP / LCP の境界確認が必要 |
| DHCP | bond0 / eth1 で listen | kernel service への受信経路が論点になる |
| NAT44 | pppoe0 masquerade | PPPoE と絡むため VPP 化しにくい |
| NAT66 | eth4 masquerade | VPP 側での再現性確認が必要 |
| OpenVPN | vtun1000 | VPP の主対象外 |
| management VRF | eth0 | 管理アクセス維持のため kernel 側に残すべき |
この時点で、VPP 化は「interface を置き換える作業」ではなくなります。
PBR、Firewall、QoS、NAT、service listen、routing protocol の境界をすべて再定義する必要があります。
bond0 を VPP 化した場合の結論
bond0 を pure VPP dataplane 側へ移すと、現行の policy route ... interface bond0 による kernel 側 PBR は、そのままでは効かなくなると判断しました。
これは今回の検討における最も重要な結論です。
bond0 は単純な L3 forwarding interface ではありません。source prefix に応じて table 10 へ振り分ける policy routing の入口です。そのため、bond0 を VPP 化する場合は、PBR 相当の処理を VPP 側、LCP 境界、Linux routing table、FRR のいずれで保持するかを再設計する必要があります。
つまり、bond0 は性能面では VPP 導入候補に見えますが、制御面では初期移行対象にしにくい interface です。
PPPoE / outside 側はさらに難しい
外部接続側には eth4 と pppoe0 があります。
IPv4 は pppoe0 で NAT masquerade、IPv6 は eth4 側で autoconf と NAT66 masquerade を利用しています。また outside 側 firewall の入口にもなっています。
ここを VPP 化しようとすると、少なくとも以下が同時に絡みます。
- PPPoE
- IPv6 autoconf
- NAT44
- NAT66
- outside firewall
- MSS adjust
- default route
- ISP 側接続性
これは初期検証対象として重すぎます。実運用ルーターの外部接続を VPP 化するには、得られる利点に対して失う制御点と検証負荷が大きすぎます。
VPP が向く領域
今回の検討から、VPP が向く領域はかなり明確になりました。
VPP は、以下のような用途には適しています。
- 単純な高速 L3 forwarding
- DPDK NIC を使った dataplane 検証
- VPP ACL で完結できる通信制御
- 条件が合う場合の NAT44
- GRE / VXLAN / IPsec など、VPP 側の機能範囲に収まる tunnel 処理
- CNF / NFV dataplane の研究
- 既存ルーターから分離した検証用 forwarding path
逆に、以下のような構成では導入難度が高くなります。
- Linux kernel firewall に強く依存している
- interface ingress に PBR を適用している
- QoS を kernel dataplane 側で実装している
- PPPoE が外部接続の中心になっている
- NAT44 / NAT66 / firewall / VPN / DHCP / DNS を一台に統合している
- FRR と service listen の境界を維持する必要がある
- 管理系 VRF を含む実運用ルーターである
最終判断
今回の物理 VyOS ルーターに対して、VyOS VPP を本番 dataplane として導入することは採用しません。
理由は以下です。
bond0に PBR が適用されている- VPP 化すると kernel dataplane 上の PBR がそのままでは効かない
- firewall / QoS / conntrack / service listen の前提が崩れる
- outside 側は PPPoE / NAT44 / NAT66 / firewall が密結合している
- OpenVPN / GRE / management VRF も含む統合ルーターである
- VPP 化による性能上の利点より、制御機能の再設計負荷が大きい
- interface 置換ではなく dataplane 責任分界の再設計になる
したがって、本番ルーターとしての VPP 導入は見送ります。
今後の扱い
VyOS VPP は、本番ルーター構成には組み込まず、研究・検証テーマとして保持します。
具体的には、以下のような範囲で扱います。
- 未使用 NIC または検証 VLAN での VPP interface 検証
- VPP / DPDK / hugepage / LCP の挙動確認
- VPP bonding の検証
- VPP ACL の検証
- VPP NAT44 の検証
- VPP GRE / VXLAN の検証
- CNF / NFV dataplane 研究との接続
一方で、以下は対象外とします。
- 現行物理ルーター全体の VPP 化
bond0本番 interface の直接 VPP 化pppoe0/ outside 側の VPP 化- management VRF の VPP 化
- OpenVPN / NAT66 / QoS / PBR を含む統合移行
まとめ
VyOS VPP は強力な dataplane 技術ですが、既存の VyOS ルーター構成に対して常にそのまま適用できるものではありません。
特に、PBR、Firewall、QoS、NAT、PPPoE、VPN、DHCP、DNS forwarding、OSPF / OSPFv3 などを一台に統合している実運用ルーターでは、VPP 化は高速化のための単純な置換ではなく、dataplane 全体の責任分界を再設計する作業になります。
VPP は、単純で高速な forwarding path や CNF / NFV dataplane の検証には有効な候補です。しかし、現在のような高機能な統合ルーターに対しては、まず Linux kernel dataplane 側の制御機能との依存関係を分解し、VPP に任せる領域を限定する必要があります。
今回の検討では、その境界が明確になりました。
