コンテンツにスキップ

Overlay 発展トピック

ここでは、基本の VXLAN / VNET / EVPN の延長に見えるが、別の前提や別の orch を持つ機能を整理します。設計検討では同じ overlay として並びますが、運用手順や実装成熟度は同一ではありません。

ハンドオフ

  • 概念とアーキテクチャは本章の concept / architecture と、area HLD の vxlan-sonic, sonic-dash-hld, evpn-vxlan-multihoming に集約されている。tunnel orchagent と FRR EVPN の協調は area HLD 側で詳細化されている。
  • 設定とリファレンスは reference/cli の config vxlan / config vnet 系コマンド、reference/config_db/VXLAN_TUNNEL, VNET, VNET_INTERFACE, EVPN_NVO に集約されている。
  • 本ページ は基本 VXLAN/VNET/EVPN を踏まえた読者向けに、EVPN MH, NVGRE, Subnet decap, Overlay ECMP w/ BFD, DASH 連携といった発展領域だけを扱う。

EVPN multihoming

EVPN multihoming は、host を複数 leaf に接続し、BGP-EVPN の Type-1 / Type-4、ESI、DF election、split-horizon で重複転送とループを避ける機能です。通常の EVPN VXLAN が Type-2 / Type-5 で MAC/IP/prefix を配るのに対し、multihoming は Ethernet Segment の制御を追加します。

既存ページでは、EVPN_ETHERNET_SEGMENT や EVPN-MH 用 CLI / YANG が現行 master で確認できない可能性も示されています。利用判断では FRR、SAI、ASIC、SONiC schema の対応状況を個別に確認してください。

DASH / SmartSwitch 連携

SmartSwitch ENI based forwarding は、ENI と DPU の対応を NPU 側に理解させ、ACL の REDIRECT で local nexthop または tunnel nexthop へ送る設計です。VXLAN tunnel nexthop 表記を ACL action が解釈するため、VNET/VXLAN の tunnel nexthop 管理と接点があります。

VNET local endpoint forwarding は、DPU が local にいる場合に tunnel route ではなく通常 ECMP route を使う最適化です。failover 中の transient state では、tunnel decap 後のパケットを local nexthop へ redirect する高優先 ACL が使われます。

NVGRE

NVGRE は VXLAN と同じく overlay encapsulation ですが、GRE と VSID を使います。SONiC の NVGRE HLD は decap 側を中心にしており、NVGRE_TUNNEL / NVGRE_TUNNEL_MAP と nvgreorch は VXLAN 系 orch とは別です。

VXLAN/VNET の章で一緒に読む価値があるのは、tenant ID を tunnel map で inner L2 domain に戻す考え方、ASIC tunnel resource、inner packet hashing の課題が似ているためです。EVPN control plane と一体に扱うべき機能ではありません。

Subnet decap

Subnet decap は VXLAN overlay ではなく、VLAN subnet 宛の IPinIP decap を自動生成して Netscan probe を処理する platform 機能です。TUNNEL_DECAP_TABLE や tunnel term という部品は共通ですが、tenant overlay を作るものではありません。

この機能を VXLAN のトラブルシュートに混ぜると判断を誤ります。見るべきポイントは SUBNET_DECAP、自動生成される IPINIP_SUBNET / IPINIP_V6_SUBNET、warm reboot 後の APPL_DB 再投入です。

関連ページ

発展トピック

  • Overlay ECMP with BFD monitoring: VNET tunnel nexthop に BFD を貼ることで、underlay の障害を検出して nexthop group から外す。overlay-ecmp-with-bfd-monitoring HLD と overlay-ecmp-enhancements で扱う。VNET の規模が大きいときに収束時間を支配する要素になる。
  • EVPN Type-5 (IP Prefix Route): tenant VRF の prefix を route target 経由で配る方法。Type-2 ベースの MAC/IP モデルと、Type-5 ベースの prefix モデルが共存するときの優先度を意識する。
  • DSCP remapping for tunnel traffic: outer DSCP を VNET 単位で書き換える機能。overlay/dscp-remapping-for-tunnel-traffic で扱われ、QoS 章 (08 QoS) の DSCP-to-TC マップと組み合わさる。
  • Symmetric IRB: ingress / egress 双方で L3VNI を経由する設計。FRR 側設定と SONiC schema 双方で VXLAN_TUNNEL_MAP に L3 mapping を入れる。
  • VXLAN counters / drop visibility: COUNTERS_DB に tunnel ごとの ingress/egress カウンタが入る。tunnel drop の切り分けは ASIC SAI 側のカウンタも併用する。

既知の制約と回避方法

  • EVPN multihoming (Type-1/Type-4) の SONiC 対応: master でも YANG / orch / SAI 全層が揃っているかは ASIC 依存。production 投入前に EVPN_ETHERNET_SEGMENT の有無、FRR evpn mh es の動作、SAI の split horizon サポートを個別に確認する。
  • inner hashing が不十分なケース: VXLAN inner header の 5-tuple がハッシュに入らない ASIC では、ECMP / LAG の偏りが出る。SAI hash setting (SAI_SWITCH_ATTR_LAG_HASH_*) と platform docs を照合する。
  • NVGRE と VXLAN の同居: 同じ port での同時受信は ASIC によっては未対応。nvgreorch の HLD は decap 中心で、encap シナリオは限定されている。
  • Subnet decap を VNET の障害切り分けに使わない: 名前が似ているが目的が違う。SUBNET_DECAP は VLAN subnet 宛 IPinIP の自動 decap で、VNET overlay とは別経路。

将来計画 / ロードマップ

  • evpn-vxlan-hld には Type-2 MAC mobility、ARP suppression、ND suppression、Type-5 集約などの拡張が "Future Work" として継続議論されている。
  • DASH / SmartSwitch との接続で、VNET tunnel nexthop と ENI redirect の責務分担が再整理されつつある。13 DASH / SmartSwitch の advanced と相互参照。
  • IPv6 overlay (VXLAN over IPv6 underlay) のサポート拡大が議題。

関連 RFC / 仕様書

upstream 開発の最新動向

  • FRR 側の EVPN 機能拡張に追従して bgpcfgd の Jinja2 と YANG モジュールが更新されることが多い。EVPN MH の SONiC 対応は段階的で、PR 単位で SAI 側依存を確認する必要がある。
  • sonic-swss 配下の vnetorch / vxlanorch は tunnel nexthop group の扱いに関する PR が継続しており、scale 改善と memory 削減が主軸。
  • SmartSwitch / DASH 関連で vnet-local-endpoint-forwarding のような近接最適化 HLD が追加されており、VNET の用途が DC overlay から DASH service へ広がっている。

トラブルシュート観点

  • VTEP の show vxlan tunnel で remote VTEP が学習されない場合は、BGP-EVPN のセッションと Type-3 (Inclusive Multicast Ethernet Tag) の advertise 状況を vtysh -c "show bgp l2vpn evpn" で確認する。
  • MAC 学習が片寄っている場合、Type-2 経路の VNI と local VLAN-VNI mapping の整合を VXLAN_TUNNEL_MAP で点検。FRR 側 evpn vni <id> も必須。
  • inner hash の偏りは show interfaces counters の per-port 分布で見える。ASIC SAI の SAI_SWITCH_ATTR_LAG_HASH_IPV4 に inner 5-tuple が含まれていない場合、SAI vendor docs と platform hash.json の見直しが必要。

検証パスとラボ要件

  • KVM-based VS lab (sonic-mgmt ansible playbook 中の vxlan-evpn topology) で EVPN Type-2/3/5 の基本動作を再現できる。virsh で VTEP を 3 台立て、leaf-spine で bgp l2vpn evpn を運用する。
  • DASH/SmartSwitch 系の検証は DPU sim (sonic-dash-kvm HLD 参照) を併用する。VNET tunnel と ENI redirect の責務分担を観察できる。

関連ページ (追補)