要約
- JANOG58初日の来場者は2,578人。アクセスポイントが検出したMACアドレスは1,925件で、そのうち約1,580件、約82％がランダムMACだった。
- NOCメンバーだけが利用したHot Stageでは、約60人、想定約120端末に対し、履歴上のMACアドレスが275件に達した。想定端末数の約2.3倍で、245件がランダムMACだった。
- スイッチのMACテーブルには大きな余裕があり、枯渇は起きなかった。先に問題になったのは、端末識別、ポリシー、DHCP状態、ログの連続性だ。
- NOCはEVPN/VXLAN上でVESPAも実験運用した。ただし、公開資料には導入前後の性能比較がなく、今回の規模で不可欠だったとは結論できない。
JANOG58で「爆発」しなかったものはMACテーブルだった。代わりに増えたのは、一台の端末を追うために扱わなければならない識別状態である。
松山で開かれたJapan Network Operators' Groupの会合後、NOCの実測結果が公開された。初日にAPが検出したMACアドレスは1,925件、スイッチ側では約2,000件。そのうちAPが見た約1,580件、約82％がランダムMACだった。
来場者2,578人という数字と単純比較することはできない。Wi-Fiに接続しなかった人もいれば、複数端末を持つ人もいる。同じ端末が複数のアドレスを残すこともある。この資料が示すのは一人当たりの比率ではなく、会場ネットワークが実際に保持した状態だ。
容量不足ではなく、識別単位の揺らぎ
事前設計はAP 50台に各100クライアント、合計約5,000アドレスを想定した。これに対し、L3ゲートウェイとして使った7050SX3のMACテーブルは160,000件、720XPは64,000件、710Pは32,000件とされている。
十分な余裕があったため、会場はフラットなL2構成を採った。結果資料も、MACテーブルがあふれる状況には至らなかったと明記している。ランダムMACが原因の障害、パケットロス、輻輳も報告していない。
ここに今回の重要性がある。大きなテーブルは「何件保存できるか」を解決する。しかし、その一件が昨日と今日で同じ端末を示すか、アクセスルールが利用者を追えるか、障害時にAPログとスイッチ表を結び付けられるかは解決しない。
転送容量には余裕がある一方、運用上の識別子としての品質はすでに下がっていた。
Hot Stageで見えた2.3倍
より分かりやすいのが、NOCユーザーだけが利用したHot Stageの測定だ。アクティブユーザーは約60人。1人2端末なら約120端末と想定できるが、APの履歴には275件のMACアドレスが残り、245件がランダムMACだった。履歴状態は想定端末数の約2.3倍である。
発表者は、NOC用、ゲスト用、OpenRoaming用など複数SSIDを端末が移動したことを要因の一つとして挙げている。ただし、これは可能性の提示であり、原因別の定量分析ではない。120端末も推計で、275件が同時接続数を意味するわけではない。
それでも運用への影響は具体的だ。MAC認証やMAC ACLは継続性を失いやすい。DHCPリースやARP状態は端末数以上に増える。利用統計が端末ではなくアドレスを数える危険もある。障害調査では、一台の端末が残した複数の短命な識別子をつなぎ直す作業が必要になる。
ランダムMACは、無線環境をまたいだ追跡を防ぐためのプライバシー機能だ。運用側の答えは機能を止めることではない。変わるように設計された識別子を、恒久的な本人確認キーとして扱わないことである。
VESPAは「状態をどこで持つか」の実験
JANOG58のNOCは計測だけで終わらず、2台のVESPAゲートウェイ、EVPN/VXLANのL2VPN、Wi-Fi 6、6E、7のAPを含む実験用無線経路を稼働させた。
技術資料では、VESPA（Virtual Ethernet Segment with Proxy ARP）を、トンネルに接続するEthernet SegmentへEVPNマルチホーミングを広げるArista Networksの実装として説明している。APがL2 Proxyとして動作し、ゲートウェイ側がクライアントのアドレス状態を保持する。ゲートウェイは共通のSet IDと仮想VTEPも使う。
土台となる仕組みには標準がある。RFC 7432はEVPNのEthernet SegmentとMAC Mobilityを定義する。RFC 9161はProxy ARP/NDによってIPとMACの対応を配布し、大規模ブロードキャストドメインでアドレス解決のフラッディングを抑える運用を説明している。
一方、VESPA自体をIETF標準と表現することはできない。また、今回のデータはVESPAがテーブル枯渇回避に必須だったことも示していない。生の容量は余っていた。今回の価値は、揺らぐクライアント状態をAP、ゲートウェイ、スイッチのどこで持つべきかを会場で試した点にある。
公開資料には、導入前後の遅延、ロス、コントロールプレーンCPU、ARP/DHCP状態、ブロードキャスト量、障害対応時間の比較がない。構成が動いたことは分かるが、効果の大きさはまだ測れていない。
次に必要なのは前後比較
次回の検証では、同時接続端末と履歴上のアドレスを分離し、一台が何回識別子を変えたかを測る必要がある。DHCPリース、ARPエントリ、CPU、BUMトラフィック、遅延、失敗率を同じ条件で取り、Proxy有効化の前後を比較すべきだ。
機器選定も最大MAC件数だけでは不十分になる。状態の保持時間、SSIDごとの挙動、L2より上位のアイデンティティ連携、アドレス変更をまたぐ可観測性、Proxy状態が古くなった場合の失敗モードまで確認したい。
JANOG58の成果は、想定した容量障害が起きなかったからこそ有用だ。アドレスが変わることを前提にしたとき、端末、ポリシー、運用証跡の連続性をどの仕組みが担保するのか。次の論点はそこにある。