要約
- 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 の成果は、想定した容量障害が起きなかったからこそ有用だ。アドレスが変わることを前提にしたとき、端末、ポリシー、運用証跡の連続性をどの仕組みが担保するのか。次の論点はそこにある。