見出し画像

JANOG52振り返り(ネットワークチーム奮闘記)

sasakipochi

JANOG52が終わった。

JANOG43ぶり(4年ぶり)にスタッフ的なお仕事(Wi-Fiネットワーク構築)をしたので、振り返り記事を書いてみる。
私の目線での振り返りになるので、是非他の人の話も聞いてみてね。


なぜネットワークチームに参加したのか

JANOG52のホストの1社の株式会社長崎再興の代表の甲斐さんが昔の上司なんだよね。
いろいろお世話になったので、山梨のJANOG51のときに、何か手伝うことあればやるよー、と言ったらネットワークチーム見てよ、と言われたのよ。

チーム分け

大規模イベント向けWi-Fiを作るためには以下のことをしていけば良い。

  1. 充分な帯域の上流接続回線を調達する

  2. 多くの端末で利用しても問題がないネットワーク環境を構築する

  3. 集中管理できるWi-Fiアクセスポイントを充分な数設置する

  4. 稼働中は適切に監視し、問題があったらすみやかに対処する

これを実現するために今回は以下のようにチーム分けをした。

  • コア: 全体マネジメント、いろいろなお財布管理

  • バックボーン: 上流回線調達

  • L2L3: 会場内ネットワーク設計構築

  • AP、監視: アクセスポイント設置運用、監視システム構築

  • ケーブリング: 会場内ケーブル配線設計、ケーブル作成、配線

  • サーバ、なんでもやる: サーバ基盤構築、サーバ構築、その他なんでもやる

ネットワークチーム募集が開始されたときに、申し込みフォームに、なんでもやるよ、と書いたら「サーバ、なんでもやる」チームに配属されたよ。
希望通りなのかな？？？

プロジェクト内で利用したツール

使ったツールは以下。

  • Slack

  • Notion

  • GitHub

  • Google Drive

  • LINEグループアルバム

  • Metro Retro

  • Zoom

  • Trello

Slack は長崎県立大で用意してもらった。
フリー版じゃないのでハドルでの音声チャットも利用できた。
後半のサーバチームの定例会はハドルを使ったのでZoomは全然使わなくなった。

Notion も長崎県立大で用意してもらった。
データベースとかも作れちゃう便利で高機能なイケてるWiki。
使ったことがないとちょっとハードルが高いかなあ、と思ってたんだけど、若者はすぐに馴染んでサクサクいろいろなデータベースを作って便利に使いこなしてくれた。
若者の適応能力すごいわー。
タスクカンバンにはTrelloを使おうと思ったんだけど、一番最初に使っただけで、カンバンもすぐにNotionに移行した。
ほとんどの情報はNotionに集約できたんじゃないかと思う。
Notion AI は最初は面白がって遊びまくってたんだけど、そんなに使わなかったかなあ。

GitHub も長崎県立大で用意してもらった。
設定ファイル等を置く場所ね、と言っただけで、運用方法とかも特に決めなかったんだけど、なんとなくコード集約はできた感じ。
docker-compose の設定ファイルが沢山置かれたのは今風だよな、と思った。

Google Drive は共同作業にはやっぱり便利。
プレゼン資料とかをみんなで一緒に編集できるのはとても良い。

みんなで撮った写真の共有には、LINEのグループアルバムを使った。
タイムスタンプ等の情報がなくなったり、画質が変わったり、とイマイチなところはあるんだけど、みんなで手軽にわいわい写真を共有できたのは楽しかった。
思い出作りにはとても良いね。

Metro Retro はサーバチームのキックオフで利用。
リモートミーティングで会話をしながら、やりたいことをカードにしてペタペタ貼っていって整理するのには、こういう専用ツールはやっぱり便利だ。
クローズミーティングでも利用するつもり。

チームの方針決め

サーバチームのメンバーは5人。
私以外の平均年齢は21歳。
まあ血気盛んな若者だ。

最初のキックオフのときに、やりたいことを書き出してもらったら、まあ沢山あることあること。
ジョルノ・ジョバァーナには『夢』がある！、そんな感じ。
方向性を合わせとかなきゃヤバイのでは、とちょっと思ったけど、まあ暴走するのも面白いかな、の方が勝ったので、チームの方針としては、

  • 「楽しくやりたいことをやろー」

  • 「なんでもやろー」

みたいな感じにした。

チーム運営

やりたいことはたくさんあるのはわかった。
でもやりたいことばかりやってて、やるべきことがおろそかになっちゃうとまずい。
初顔合わせのメンバー同士のコミュニケーションも取っていかなきゃいけない。
ということで、スクラムっぽい感じで運営してみた。

  • 日曜と水曜の夜に定例会を実施

  • 1スプリントは2週間、2週間毎の日曜の夜にスプリントレビュー

  • 定例会の記録はNotionのテンプレートを使って作成

  • タスクカンバンもNotionで作成

  • 定例会では、アイスブレイクの近況報告、タスクカンバンの確認、各種相談、勉強会、等を実施

ただ、厳密にやると、お仕事感が出ちゃってなんかイヤなので、

  • 定例会参加はベストエフォートでOK、他チームからの参加も歓迎

  • タスク見積り(ストーリーポイント)は省略

  • 進捗管理はしない、自主性にお任せ

  • やるべきことの見える化、やってることの見える化だけしておく

  • 雑談を大目にする

という形でゆるふわにドライブした。

サーバチームでやるべきこと

サーバチームで確実にやるべきこと、は今回は以下の3つ。

  • 利用者向けのDHCPサーバ構築

  • 利用者向けのフルサービスリゾルバ（キャッシュDNSサーバ)構築

  • 監視システム作成等のためのサーバ基盤構築

これだけ普通に作るなら、わりと簡単。
ぶっちゃけ手を抜いて作るなら、1日あれば頑張れる量だよなあ、と思っている。
なので、進捗が多少遅れてもなんとかなるさー、とわりとのんびりしてたらどんどん遅れまくる。
ゆるふわにドライブしたのでまあ仕方ないんだけどね。

暴走するサーバチーム

やるべきことが遅れていても、みんながやりたいことは止められない。

  • ヤフオクで安いサーバを見つけてしまい、なし崩し的にそれを使うことが決定

  • ESXiサーバをインストールして長崎県立大学内に仮想化基盤を構築

  • VPNサーバを用意して外からログインできるようにして

  • VPNごしに、いろいろなVMを構築開始

  • DHCPサーバは新しめの Kea DHCP を採用、Prometheus で格好良い監視を実現

  • DHCP option を利用して Wi-Fi APへのアドレス配布、IPv6-Mostly Access 対応

  • DNSキャッシュサーバ用に dnsdist をロードバランサとして利用

  • dnsdist の裏側に BIND、Knot DNS、PowerDNS、Unbound の4つの実装を並べて

  • Elastic Stack を用いて速度比較を可視化

  • NTP の勉強会をしたら PTP を使ってみたい、と言われてしまって SEIKO Solutions さんから PTP サーバを急遽借りたり

  • お値段高めのパトライトを調達してみたり

  • nautobot のサーバを準備して構成を見える化できるようにしたり

他チームも暴走

他のチームもやりすぎ感があった。

上流回線は特にアタマオカシかった。
自分達のASを立てて、いろいろなところでピアリングをしまくって、2ヶ月半でバックボーン200倍とか。
どさくさにしてもヤバすぎる。

上流ネットワークが自前で用意できると、会場のネットワークも自由に設計できる。
利用者向けのNAT用にグローバルIPアドレスを10個用意したり、いろいろな実験ネットワークやグローバルセグメントを用意したり。
VLANは10個以上作られた。
CISCOさんがスイッチをたくさん貸してくれたので贅沢に配置。
NATルータも強め。

CISCOさんはAP(Wi-Fiアクセスポイント)も大量に貸してくれたので、会場内には沢山設置することができた。
それでも余ったものは予備機として準備。

監視システムはZabbixで構築しただけじゃなくて、Grafanaで格好良く見せるダッシュボードを作りこんだり。

ケーブルチームも3kmを箱買い。
光るケーブルなんかもついでに買ってたり。

現地での構築作業

ミーティングを重ねつつ、設計を進めつつ、VPNを活用して構築作業を進めていたら、あっという間に時間が経ってしまい、本番1週間前になってしまった。
本番1週間から、現地で行なった作業等を時系列順にまとめてみた。

ホットステージ1日目

JANOG52の1週間前の水曜から3日間、ネットワーク構築のためのホットステージが出島メッセの会議室等で行なわれた。
来れる人は現地に集合。
初日のタスクは以下。

  • 仮NOC部屋設営(NOC＝Network Operation Center)

  • 機材搬入

  • 大量に届いた借用物のチェック

  • 上流接続の確認

  • 上流スイッチの設定

  • 大量のケーブル作成

サーバチームは、サーバを搬入して設置しただけ。
仮NOC部屋にネットワークが開通するまでは何もやることがないので、わりとのんびりモード。

夜は参加メンバー全員で決起飲み会。
とても楽しかった。
レシートの長さが120cmを超えてた。

ホットステージ2日目

2日目もサーバチームはわりと暇だったので、コーヒー豆を買いに行くついでに眼鏡橋を観光したり、のんびり過ごしてた。

午後に仮NOC部屋にネットワークが開通。
ホットステージの前にVPNごしに最低限のサーバ構築は完了しているので、繋いで電源を入れればOK。

だと思ってたんだけどなあ、、、、
繋いでも動かない。。。。
もう大慌てだよ。

本番環境と事前準備環境でVLANの設定が微妙に異なっていたり、マネジメントラインとサービスラインが混在してたのが原因だったんだけど、夜遅くまでトラブルシュートを続けたけど結局時間切れ。
慌てると、電源ケーブルをうっかり抜いちゃったりもするんだよね。

DHCPサーバが動かないと、アクセスポイントの設定ができないのよね。
APチームにごめんなさいしつつ、駅ビルの台湾料理屋で反省会と作戦会議をしたよ。

ホットステージ3日目

午前中頑張って、ようやく事前準備していたものが動き出した。。
VPNも無事に復活したので、現地に来れないメンバーもオペレーションができるようになった。
とはいえホットステージ中に作ろうと思ってたものが全然作れてない。
まあ、こんなこともあろうかと、ハッカソンに応募しておいたんだけどね。

楽しい週末

土日は健全にお休み。
みんなで長崎県立大学を見学してピザを食べてゲームをしたり、ペンギン水族館でペンギンを愛でたり、高さ120cmのパフェを食べたり、寿司を食べたり。
息抜きは大事。

でも夜はNOC部屋に機材搬入したり、作業してたりする人もいたんだけどね。

本番NOC部屋へ移動

月曜日に本番用のNOC部屋が利用可能になったのでお引越し。
機材を移動させて、MDF室の配線を変更して、すみやかに引っ越し完了。
終わってない宿題の続きができるぞー。

会場ネットワーク設営

火曜日、JANOG52本番の前日は設営日。
午前中に展示会場がオープン、午後から本会議場もオープン。
ネットワーク配線をしつつ、スイッチを設置し、APも沢山設置。

サーバチームはきっと暇だから、他のチームの作業を手伝ってねー、とか言ってたはずなんだけど、全然暇じゃなかった。
ずーっとサーバのチューニングとか監視設定とかをしてた気がする。
現地に到着したばかりのメンバーは、PCがBIOSから立ち上がらなくなって、延々と復旧作業をしていた。

本番 1日目

まあ結局サーバチームは、最低限のやるべき作業はできてたんだけど、やりたいことは全然できてなかったんだよ。
ハッカソンで頑張って集中して沢山ガリガリ作りこんだよ。

頑張った結果、優勝!!!
優勝プレゼンは以下。

でもネットワークチームは金曜日の午後に発表枠があるので、ハッカソンのWinnerプレゼンは2位のチームに譲ったのよね。

他のチームが何をやってたかは良くわからないけど、良い日だった。

本番 2日目

ハッカソンが終わってもやり残しがあったので、NOC部屋で作業。
PTPサーバをいじったり、nautobotのデータ投入をしたり。

一部繋がりにくトラブルもあったみたいだけど、APチームが対処していた。

本番 3日目

全体的にネットワークが繋りにくい、という状況が発生してたので、NOC部屋にこもって、みんなでトラブルシュート。
NATに問題があることがわかったけど、下手にオペレーションをすると配信に影響があるかも、ということで対処をしたのは昼。
みなさまには迷惑をかけてしまって申しわけなかったけど、NOCメンバー側はとても勉強になった。

その裏で午後のネットワークチームの発表↓の資料をギリギリまでブラッシュアップ。
発表は以下。

発表の後は、みんなで撤収作業。
まずは展示会場、本会議場1F、の順に撤収。
本会議終了を待ってから、全機器を撤収。

設定消去、機材チェック、梱包、配送ラベル貼り、も流れるように行なわれ、ケーブル巻きもサクサク進み、予想以上に早く撤収完了。
構築は未経験だったはずの若者が、設営等の経験を経て戦力になってたのが素晴しかった。

3日の夜のスタッフ打ち上げはとても楽しかった。
若者は朝まで飲んでたんだろうなあ。
そんな写真が共有アルバムに上がってたよ。

トラブル、対処方法、知見

構築中も運用中も様々なトラブルが発生した。
その中でも勉強になったことをいくつか書いていきたい。

PTPは難しい

PTP(Precision Time Protocol)は高い精度での時刻同期を実現するプロトコルなんだけど、なかなか動かなかった。

  • そもそも仕組み自体が難しい

  • ITU、IEEEで規格化がされているがユースケースによって規格が違う

  • 高い精度での時刻同期をするためには合わせる側も対応が必要

血気盛んな若者の、いじってみたい、という声に SEIKO Solutions さんが応えてくれて、TS-2950をお借りすることができて、会期中にいろいろいじってたんだけど、なかなか通信ができなかったんだよね。

  • プロファイルをきちんと合わせる

  • 接続スイッチの IGMP snooping を disable にする

ということで、ようやく時刻同期ができた。

時刻合わせの仕組みとしては圧倒的にNTPのほうが簡単だと思った。
TS-2950 はNTPサーバとしても動くので、今回はNTPも併用している。

Cisco WLC は default では Rate Limit 設定されていない

APに遅い端末が接続されていると、その端末にひっぱられて、APに接続されている他の端末の通信まで遅くなってしまう。
そのために Rate Limit を設定して遅い端末の接続を切断する必要がある。

最初はちゃんと Rate Limit の設定を入れてたんだけど、トラブルシュートをしていた際に、default から設定を入れなおす、ということをした際に Rate Limit を入れ忘れて、通信が遅くなってしまった、という事があった。

Ciscoの機器は default 設定ののままでも、わりとちゃんと動く、というところが個人的には好きなので、WLC も default で Rate Limit の設定を入れといて欲しいなあ、と思った。
Meraki とかだと default で Rate Limit が設定されてた気がするのよね。

CISCOのルータでNATをさせて特殊な通信をすると 1対1 NATが生成されてしまう

大人数でインターネットアクセスをすると、NATのセッション数が足りなくなってしまう可能性がある。
今回はグローバルIPアドレスを1つではなく、複数(今回は10個)持たせることで解決させることにした。

ところが TCPでもUDPでもない通信(今回はおそらくなんらかのVPN?)を検知すると、通常の1対多NATのテーブルを生成せずに、1対1 NATのテーブルが生成されてしまい、グローバルIPアドレスが丸々1つ使えなくなってしまう。
3日目のネットワークが不安定だった時間帯では、9個のアドレスが1対1 NATに使われてしまって、1個だけですべての利用者のセッションをさばくみたいな状態になってしまっていた。

NATのタイムアウトの値を短くしておけば良かったんだろうけど、グローバルアドレスが10個あるから余裕、と思ってしまうよねえ。。。

IPv6-Mostly Access でも Apple の端末は DNS64 が必要

IPv6-Mostly Access の実験ネットワークも提供してみた。
IPv4とIPv6のデュアルスタックのネットワーク環境なんだけど、対応端末だとIPv4アドレスが割り当てられずに、IPv6アドレスだけが割りあてられる。
そしてIPv6アドレスだけを持った端末でも、端末側でアドレス変換を行なうことでIPv4アドレスの機器への通信が可能になる。
IPv4でしかサービスをしていないTwitterが、IPv6アドレスだけしか持っていないはずのAndroidのスマホからなぜか見える、というキモい体験を提供できた。

IPv6-Mostly Accessに対応していない端末だとデュアルスタックで普通に使える。

ただ iOS と macOS は中途半端な対応に見えた。
IPv6アドレスだけにはなるんだけど、IPv4の機器と通信することはできない。
iOS と macOS の場合は DNS64 が必要になるっぽいということはわかったんだけど、それだとあんまり面白くないんだよねえ。

IPv6-Mostly Access の詳細については以下の記事等から辿ってみてくださいませ。

IPv6-Mostly Access
https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/

端末側の CLAT アドレスが不正アドレスとして検知されてしまう

IPv6-Mostly Access のネットワークでは、Android端末側でCLAT用のアドレスが生成される。
そのアドレスをWi-Fiコントローラ(WLC)が不正なアドレスとして検知してしまってブロックされる、という事があった。
普通に使っている分にはありがたい機能のはずなんだけど、、、、
検知機能をオフにして解決。

隠れオープンリゾルバ対応

いろいろあってキャッシュDNSサーバはグローバルセグメントに置くことになったんだけど、隠れオープンリゾルバになってると指摘があった。
ネットワークチーム側にBCP38の設定をしてもらって対応。

隠れオープンリゾルバについては以下を参照のこと。

浸透しない隠れオープンリゾルバ対策

反省点

若者がガリガリ手を動かして凄いスピードで作りこんんでいったので、全部追いきれてないんだよね。
監視ツールのconfigも見れてないし、DNSの設定とかも全然追えてない。
PTP とか nautobot とかで時間を潰さずに、もっと余裕を作って、全部見とけば良かったなあ。
勉強不足を痛感することもいろいろあった。

若者は手も早いし、好奇心旺盛でネットで見たことをなんでも自分でやってみたくなる。
そして熱中力も凄い。
おじさんがそれに付いていくのは正直無理。

でも若者は経験がまだ少ないので、全体像や全体スケジュールは実感できていない感があるのよね。
おじさんとしては経験を生かして、付いていくことはできなくても、経験を行かして先回りをすることはできたはず。
でも若者と一緒にわちゃわちゃするのが楽しすぎて、先回りできなかったなあ。
ごめんねえ。

我々は勝利することができたのか？

いろいろな敗北感も味わったけど、JANOG52も無事に終わったので、まあ勝ったと言って良いんじゃないかな。
打ち上げのときの写真もみんな満足そうな顔をしている。
変な顔をしている人もいるけどそういう芸風だから気にしないであげてね。

JANOG52スタッフ打ち上げ後のネットワークチーム集合写真

この写真を見ればわかるけど、私自身はじゃんけんで大勝利している。
これが老獪なおじさん力というものだよ。

この記事が気に入ったらサポートをしてみませんか？