大規模Wi-FiネットワークでIPv6を提供する際のマルチキャスト対策

まとめ

長くなったので、結論的なことを先に書いておく

• IPv6ではマルチキャストが多用される

• 大きなネットワークにおいて、何も設定しないとネットワークスイッチのマルチキャストのためのテーブルが枯渇するおそれがある

• Wi-Fiはマルチキャストが苦手

• IPv6の提供にあたっては、必要な設定をちゃんと入れたり、設計で回避したりしないとダメだぞ

JANOG56の裏側であったこと

ひとつ前のnoteに書いたけど、JANOG56のときに、NOCメンバーの一員としてネットワークのトラブルシューティングをしてたんだよね。

IPv4でのサービス提供は大きな問題はなかったんだけど、IPv6でのサービス提供がなんかおかしかった。
クライアントは、RAでIPv6アドレスを配布するようにしてたんだけど、RAがなかなか降ってこない、みたいなことがあった。
しばらく待っているとたまにRAが降ってくるので、全面的に使えない、というわけではなく、いわゆる半死というタイプの障害。

あまりにも気持ちが悪いので、2日目の夜に、一部のNOCメンバーや腕利きエンジニアと一緒に残業。
ルータの設定で、RSに対するRAの応答を、マルチキャストではなくユニキャストで行なう、という設定を投入。
正常動作が確認できたので、これでなんとかなるかなあ、と思ったんだよね。

でも3日目もなんかRAがちょいちょい落ちるんだよね。
だいぶマシにはなってたんだけど。

原因を考えてみた

現象からの考察

なんか悔しいので、JANOG56が終わった後に、ひとりであれこれ調べてみたよ。
マルチキャストをユニキャストに変更したことで症状は緩和されたので、マルチキャストの処理に問題があったんだと思う。

• IPv6ではマルチキャストを多用するんだけど

• ネットワークスイッチにはマルチキャストを処理するためのテーブルがあって

• マルチキャストグループ毎にそのリソースが消費される

• 接続端末がとても多いとリソースを使い切ってしまう

ということが発生してたんじゃないかと思う。
実際の環境はもうないので、あくまで仮説ではあるんだけど。

Neighbor Discovery(ND)が使うマルチキャスト

IPv4で使われていたARPは、IPv6では廃止されて、代わりに、Neighbor Dicovery(以下ND)というプロトコルを使っている。
ARPよりいろいろなことができて、DHCPサーバが不要になったり、アドレスの衝突を防ぐような仕組みが備わっていたりする。

• アドレス解決(IPv4のARPの代わり)

• デフォルトルータの検出(RS、RA、SLAAC)

• 重複アドレス検出(DAD)

そしてこれ全部、マルチキャストを使うんだよね。
一番つらいのは、重複アドレス検出の仕組み。
端末が自分自身だけが所属するマルチキャストアドレスを作って、そのアドレス宛にパケットを送信して返事がなければ衝突なし、と判断する。
接続端末の数だけ、マルチキャストグループが作られるんだよね。
そして大抵の端末は複数のIPv6アドレスを持っているので、だいたい3倍ぐらいはテーブルが消費されるわけだ。

ネットワーク機器のマルチキャストテーブルの大きさ

マルチキャストグループ毎に消費されるテーブル(L2MC table)は、ちゃんとしたメーカーの良く使われるスイッチだと1000個以上は確保されている。
なので、だいたいの環境だと普通に使っている分には問題にならない。
でも何も設定をしないまま、2000人とか繋ぐと残念ながら足りなくなっちゃうんだよね。

どんな設定をすれば良いのか

この問題を回避する方法は、各社ちゃんと用意している。
当日気付いてればなあ。

スイッチのモード変更

動作モードを切り替えることができるスイッチの場合には、マルチキャスト用のモードに変更することで、テーブルを増やすことができる。

MLD snoopingを使う

IPv4でのIGMP snoopingと同じように、IPv6でもMLD snoopingという仕組みがある。
この機能を使うことで、DAD等の個々のクライアントからのマルチキャストの伝達を制限することができる。
収容ルータでQuerierを設定するのを忘れずに。

RSに対するRAをユニキャストにする

JANOG56の2日目に設定したのがこれ。
マルチキャストでの通信が微妙な状態でも、ユニキャストであれば問題なく通信できたので、これを入れたことにより、RAの受信がしやすくなった。

マルチキャストからユニキャストへの変換機能を使う

Wi-Fiではマルチキャストがブロードキャスト扱いになってしまい、最低レートで全員に送信される。
これは大規模環境では致命的なので、マルチキャストはユニキャストで送信するようにしておいたほうが良い。

RA Guard の有効化

端末側からのRAも遮断しておくほうが良い。
端末からRAを流されるちゃうと大惨事になるので、これはマルチキャスト削減よりも、セキュリティ対策かな。

ND proxyを有効化

マルチキャストグループの削減に一番効果があるのは、おそらくこの対策。
NDのやりとりを、APや収容機器で代理応答させることで、端末毎に作られてしまうマルチキャストテーブルを収容機器外に出さないようにする。

ただ良いことだけじゃなくて、以下のような問題もあるので注意。

• Proxy役の機器の負荷が上がる

• DADの挙動が素直じゃなくなるのでトラブルシュートが難しくなる

セグメントを分割

たくさん接続しようとするから大変になるわけなので、セグメントを分割して、1つのセグメントに接続する数を減らすことを考えても良いと思う。

リソースの監視

IPv4のネットワークでは、DHCPのアドレス使用数や、NATテーブル使用数、を監視しておくと安心なんだけど、同じように、IPv6のネットワークでは、マルチキャストテーブルの利用数を監視していおくと安心できるんじゃないかと思う。

思ったこと

IPv6なんもわからん

利用者として使っている限りは、普通に使えちゃうので、そんなに真面目にIPv6を勉強したことはなかったんだけど、勉強すればするほど、なんもわからん、って気持ちになった。
OSPFv2とOSPFv3におけるIPv6の扱いの違いとかも今回はじめて知ったよ。
IPv6が誕生してから四半世紀経つわけなんだけど、実際に動かしてきた先人達ってすごいなあ。

とりあえずなんとなく、あきみちさんが書いた本を貼っておく。
無料で読めるよ。

機器メーカーってすごい

だいたいの機器は、上に書いたような対策を簡単にできるようになってる。
1行コンフィグに追加したり、チェックボックスをクリックするだけ。
裏ではすごく大変な処理をしているはずだし、テストも大変だろうし、そりゃあ良いお値段するよなあ、と思った。

マルチキャストパケットはL2レベルではどう処理されるか、みたいなことも、私は今さら知ったんだけど、機器メーカーはずっと前から当たり前のように実装してるんだよねえ。
すごいよなあ。

メーカーによって設定の考え方が違うのは面白い

上に書いたような対策をどこの機材でやるかは、各メーカーによって全然違うんだよね。
CiscoはAPがとても高機能なんだけど、AristaはAPに届いたパケットを外の機材に全部飛ばしてそこで処理させるようにしてる。
Juniperはその間ぐらい。
面白いんだけど、利用者側としては、ちょっとつらいなあ、という気持ちもある。

APの制御方法も違うし、マルチベンダで構成するときは、セグメントを分離しておくほうが幸せになれるのかなあ？
このへんのベストプラクティスは正直わかっていないので、誰か教えて欲しい。

過去のイベントではちゃんとIPv6でのWi-Fi提供はできてたの？

実はできてなかったケースもあるのかもしれない。
たまたま今回は気付いただけ、という可能性もある。
今回も半死状態で、運が良ければRAが降ってきていたしね。

デュアルスタックは良くないかも

IPv4とIPv6のデュアルスタック構成だとトラブルシューティングが大変だと思った。
IPv6のネットワークの一部に問題があっても、IPv4のほうで正常で動いてしまうと、そこの問題に気付きにくいんだよね。

NAT64を使えばだいたいの場合はそんなに困らないので、IPv4、IPv6(NAT64)、の2つのSSIDを用意して、ユーザーに接続先を委ねるほうが良いのかな、と思う。
先日MIXIのイベントに行ったら、そういう風にゲスト用のWi-Fiを提供していて、なんかやっぱり流石だよなあ、と思ったよ。

ちょっと前までは、対応端末だけNAT64になるIPv6 Mostlyは、とってもいいじゃん、と思ってたんだけど、非対応端末のためにデュアルスタックネットワークを作るのは大変かもなあ、とちょっと考えが変わった。

一般ユーザーが簡単にIPv6を使えるようになってるのは、提供を行なっているVNE事業者やISP事業者のおかげなんだけど、デュアルスタック環境でのトラブルとの戦いは結構大変なんだろうなあ。

告知

だいぶ長いことイベント向けのWi-Fi構築に関わってきているけど、問題や障害は毎回必ず発生する。
もし、何も問題がなかったー、と感じたら、多分、障害を見つけることができなかっただけだと思う。
それぐらい多種多用予想外なことがおこる。

問題を発見したら、黙って我慢したりせずに、できれば症状を教えて欲しい。
そしてSNSやアンケートに、Wi-Fiがクソだった、とか書くのは全然前向きじゃないよー。
Slack等で、わいわいしたり、一緒にトラブルシュートしましょ!!
ユーザー側でできる対応もいくつかあるので、Slackで話をするだけでなんとかなることもいっぱいあるよ。

でもまあ、良く知らない人達とわいわいしたり、すごく沢山の人が参加しているSlackに書きんだりするのは、心理的にハードルはそれなりに高いとは思う。

でもイベント向けのWi-Fi構築はそれなりに面白いんだよ。
そういう面白さを共有できたらいいな、と思って、10/7にまたイベントやるよ!!。
良かったら遊びに来てね。
会場で握手しましょう。