Team ShirankedoがIWSC奈良の会場ネットワークを作ってみた

公開日

はじめに

2025年7月、奈良県奈良市でInternet Week ショーケース in 奈良が開催されました。その会場ネットワークを構築・運用したTeam ShirankedoのNOC活動の様子を、学生リーダーを務めた近畿大学大学院の丸岡と各チームメンバーがご紹介します。

Internet Week ショーケース in 奈良について

Internet Week ショーケース in 奈良は、インターネットの基盤技術の基礎知識や最新動向を学び、議論し、理解と交流を深めるためのイベント「Internet Week」の特別版です。2025年7月2日〜3日に奈良市のならまちセンターで、前年のInternet Weekから厳選されたプログラムを2日間に再構成し、JPNICと近鉄ケーブルネットワーク株式会社の共催で開催されました。

Team Shirankedoについて


Team Shirankedoは、関西のネットワーク技術者が集うコミュニティNaniwaNOGで2024年に発足したNOCチームです。チーム名は関西弁の「知らんけど」に由来し、「失敗してもOK。なんか上手く行ったわ、知らんけど。」という考え方のもと、ネットワーク構築に興味を持つ初心者が気軽に取り組める環境を目指して活動しています。今回が2回目の活動で、初めてメンバーの公募制を取り入れました。1回目のNaniwaNOG2での活動については以前のさくらのナレッジをご覧ください。

NaniwaNOG 2ミーティングで会場ネットワークをゼロから構築してみた

ネットワーク構成

今回構築したネットワーク構成を、チームごとの取り組みに沿って紹介します。

バックボーン（BB）チーム

メンバー：小林、山﨑

BBチームは、会場ネットワークの設計、対外接続、L2・L3機器の設定を担当しました。

提供方式

上流回線は 近鉄ケーブルネットワーク（KCN）様に提供していただきました。提供方式はIPv4をDHCP、IPv6をDHCPv6-PDで配布する形となっており、これらの要件に基づいてルーターの設定を行いました。

使用機器

使用機器は、ルーターにYAMAHA RTX1210、PoEスイッチにBUFFALO BS-POE-G2108MとBS-G2016Pを1台ずつ使用しました。ルーター配下に2台のスイッチを接続した非常にシンプルな構成です。こちらが今回の全体構成図です。

今回はさくらのクラウドにDNSなどのネットワークサービスを配置しています。このさくらのクラウドはIPsecによる拠点間VPNをRTXと構築しています。PoEスイッチにはそれぞれAPを3台接続しており、片方のスイッチには配信用、司会用に有線接続用として3ポートを確保しています。機器選定ではルーターをCisco・NEC・YAMAHAの3つから検討しましたが、BBチームの2人はいずれもYAMAHA機を触ったことがなかったため、今回は学習も兼ねてRTXを選ぶことにしました。

設定投入

基本的なNATやフィルターの設定に加え、さくらのクラウドに配置したサーバーを使用するため、VPN・DHCP Relay・syslogサーバー・SNMPでの監視を行うための設定も入れる必要がありました。スイッチには管理用とゲスト用のSSIDを分けるためのタグVLANや、APに電力を供給するためのPoE+の設定を投入しました。これらの設定作業は前日までにチームで行った作業会で完了しており、本番当日は機器の配置と対外接続の設定を行いました。

事前に行った作業会は全3回で、BBチームはアドレス設計などを済ませたあと、ルーターやPoEスイッチの設定などを行いました。最初の2回は、さくらインターネット様のBlooming Campをお借りしました。社会人リーダーの米田さんがオフィスにあるラックに設置した本番用RTXへ外部からSSH接続できるようにしてくださったので、オフィスにいなくともRTXの設定を進めることができました。
3回目は本番前日にKCN様の会議室をお借りし、サーバーチームと連携してVPNの疎通確認や最終調整を行いました。初めて触るベンダーの機器ということもあり、GUIコンソールや慣れないコマンド体系に苦戦したりしましたが、リーダー陣のお力添えもあり、本番までにconfigを完成させることができました。

本番での機器配置・監視・運用

本番では、講演会場の舞台袖にあるルーターへ接続しました。講演会場と展示ブース両方にAPを配置するために、2台のスイッチをそれぞれの会場に配置しました。ルーターとスイッチの監視はサーバーチームが準備したGrafanaで行いました。L2/L3での障害はWi-Fi提供だけでなく配信サービスの停止にも直結するため高い可用性が求められましたが、期間を通して安定した稼働を維持することができました。

さいごに

今回バックボーンという自分自身初めて触る部分ということに加えて、ここが止まるとネットワーク全体が止まるという重要な部分に触れましたが、本番中の大きなトラブルもなく、リーダー陣およびチームメンバーたちにたくさんのことを教えてもらいながら最後まで走り切ったNOCでした。

サーバー（SV）チーム

メンバー：森脇、邪答院

サーバーチームでは、来場者へのDNSとDHCPの提供に加え、ネットワーク全体の監視を担当しました。今回は、さくらインターネット様にご提供いただいたさくらのクラウド上にすべてのサービスを構築し運用しました。会場とはIPsecによる拠点間VPNで接続しました。
全体の構成は以下の図のようになっています。以降でサーバーチームで提供したサービスの詳細について説明します。

VPN

今回のネットワーク構成では、すべてのサービスをさくらのクラウドで構築したため、会場とのVPN接続が必要でした。そのため、IPsec-VPNによるVPN接続を採用しました。

サーバー側のVPNソフトウェアには、IPsecソフトウェアとして歴史が長く、Linuxカーネルとの親和性も高いstrongSwanを採用しました。インターネット上に構築例が豊富なことも利点です。数十行の設定を記述するだけで IPsec通信を行える点も大きな利点です。

今回は、会場ネットワーク（来場者用・管理用）とサーバーネットワークの間をESPトンネルモードで暗号化・トンネリングしました。鍵交換プロトコルにはIKEv2を使用し、会場側ルーターからINITメッセージを流すようにしました。

本番直前の検証では、鍵交換自体は成立しているにもかかわらず、肝心の暗号化通信がトンネルへ正しく流れないというトラブルが発生しました。原因はポリシーベースルーティングの設定誤りで、見直すことで修正できました。IPsecはなかなか奥深いプロトコルです。

会場側のルーターにはYAMAHA RTX1210を採用し、こちらにも対向する形でconfigを投入しました。公式ドキュメントが充実している点も、とても助かりました。実は、当初はL2TPv3/IPsecでのVPN接続を検討していましたが、相性面などを踏まえて、今回はIPsec単体で暗号化・トンネリングの両方を行う構成に変更したという経緯があります。今後はL2TPv3でトンネリングできるよう、プロトコル理解を進めたいです。

DNS

DNSフルリゾルバはKnot Resolverを用いて構築しました。主要なソフトウェアの中でも比較的モダンで、標準でPrometheus形式のメトリクス出力APIを備えているなどの利点があったため採用しました。サーバーチームのメンバーが2人と少なく、クライアント数もあまり多くはならないことが想定されたため、今回はdnsdistなどは導入せず、Knot Resolver単体でのシンプルな構成で安定運用を目指しました。

イベント中のキャッシュヒット率は60%程度でした。キャッシュサイズは初期値の100MBから500MBに増やして設定しました。会場での構築直後は、キャッシュがあまり温まっていないこともあり時間がかかっていると感じる場面もありましたが、NOCメンバーが使っていくうちに自然と解消され、イベント開始時には特に気にならないレベルになっていました。

DHCP

DHCPサーバーにはKea DHCPを採用しました。IPv6についてはSLAAC（+RA RDNSSオプション）で対応する予定だったため、DHCPv6は構築していません。また、Kea DHCPを管理・監視するためStorkも併せて構築しました。

DHCP周辺の構成は以下の図のようになります。Kea DHCPをStorkで管理しつつ、Stork AgentからPrometheusでメトリクスを取得しGrafanaで可視化しています。Kea DHCPでは、ゲスト用とNOC用の2つのサブネットに対してアドレスを配布しています。

DHCP構築時には、「NOC用のサブネットにはアドレスが降ってくるが、ゲスト用のサブネットにはアドレスが降ってこない」というトラブルが発生しました。原因は、ゲスト用のサブネットからブロードキャストされたDHCPリクエストをRTX1210がリレーするときの送信元IPアドレスにありました。RTX1210はリレー時にNOC側のIPアドレスを使用していました。

DHCPサーバーは、DHCPヘッダのgiaddrの値を参照してレスポンスを返すため、DHCPの動作としては問題ありません。しかし、このレスポンスの宛先IPアドレスが元のリクエストの送信元IPアドレスとは異なるため、RTX1210のdynamic filterによってレスポンスが破棄されてしまっていたことが分かりました。

このため、BBチームにRTX1210のフィルタ設定を調整してもらい、DHCPサーバーからのレスポンスを許可するフィルタを追加してもらうことで解決しました。余談ですが、このようなトラブルも考慮して事前に検証できるようにする仕組みについて、現在研究を進めています。

監視

監視基盤はGrafanaとPrometheusを中心に構築しました。メトリクスの取得には以下のexporterを使用しています。

・DNS：Knot Resolver 内蔵のエンドポイント
・DHCP：Stork Agent
・AP：merakiAPI exporter（APチームが開発）
・死活監視：Blackbox exporter
・サーバーリソース：Node exporter
・トラフィックなど：SNMP exporter

これらで取得したメトリクスをもとにGrafanaのダッシュボードを作成し、以下の項目を可視化しました。

・監視対象となる機器のヘルスチェック
・主要サーバーのCPU・メモリ使用率
・APごとのクライアント数
・DHCPリース数
・DNSクエリ数・キャッシュヒット率
・トラフィック量（Network Weathermapプラグインを使用）

死活監視のパネルに1つDOWN表示がありますが、これはIPsecによるVPNがうまく繋がらなかった場合にバックアップ用の機器で使う予定だったアドレスです。今回はVPNが無事繋がったためDOWNが正常状態となります。

また、merakiAPIのexporterは各APのクライアント数などを確認できとても便利でしたが、何度かmeraki側の制限に引っかかってしまい、データが取得できない時間帯が発生しました。この部分については今後改善していきたいです。

NOCを通して

今回はさくらのクラウドでサービスを構築したことで、会期前に大半の構築作業と動作確認を行うことができました。サーバーチームで担当したサービスはアプリケーション層で動くもので、現代のインターネットには不可欠な存在です。これらを安定して運用できたことに大きな達成感がありました。

また、他のチームと連携しながら短期間で1からネットワークを作り上げるという経験はNOCならではの魅力だと思います。同じネットワーク好きの仲間と交流しつつ、ネットワークの全体像を学ぶことができる貴重な経験だったと感じています。今回のNOC活動で得た知見や経験をもとに、今後より良いネットワークを提供できるよう精進したいと思います。

アクセスポイント（AP）チーム

メンバー: 渡邉・井上（筆者）

APチームでは、AP（無線アクセスポイント）の物理設計と物理構築を担当しました。実際には人手が少なかったこともあり、CB（ケーブル）チームと協力しながら進める場面も多くありました。チーム名を「カピバラチーム」にしたいという案もありましたが、最終的には「CB・APチーム」で定着しました。「知らんけど精神」で走り抜けた記録ではありますが、生暖かく読んでいただけると嬉しいです。

構成

今回の会場Wi-Fiは、Cisco Merakiを京都大学からお借りして構築しました。eduroamとOpenRoamingの提供は京都大学岡部研究室様と株式会社Local24様にご協力頂きました。

また、無線LANサービスとして以下の3つを提供しました。

  • WPA2/3 Personal（SSID: IWSC-NARA）
    • パスワード認証（事前配布）
    • 一般参加者向け
  • OpenRoaming（SSID: OpenRoaming）
    • RADIUSサーバーを経由して認証
    • OpenRoaming Profileをインストールした端末が明示的な認証を行わずに接続可能
  • eduroam（SSID: eduroam）
    • 学術系ネットワーク共通認証
    • RADIUSサーバーを経由して認証
    • 参加学生や教職員向け

事前準備

本番前に1ヶ月くらい準備期間がありました。今回は前日設営ができない会場だったので、とにかく「事前に詰めておく」を徹底しました。具体的には、次のようなオフライン作業会を複数回実施しました。

  • さくらインターネット Blooming Camp、KCNのオフィスなどでの作業会
  • Mobility ExpressやMerakiを実際に触って検証

そのおかげで、本番の設営・設定はわずか3時間で完了しました。座学より「実機を触った経験」が効いた感じでした。

オフライン作業会の実施

チームで使う機器のことをもっとよく知るために、さくらインターネット本社で2回のオフライン作業会を開きました。

  • 第1回はMobility Express Access Pointの設定を体験
  • 第2回はMerakiの設定やOpenRoaming／eduroamの仕組みを勉強
  • 第3回はKCNさんのオフィスにて前日作業

実際に触りながら学ぶことで、機器の基本的な動きや管理のコツをしっかり理解できました。さらに、無線LANサービスを運用するうえでのポイントもみんなで共有できて、とても有意義な時間になりました。

AP配置場所の決定

会場の図面をもとにAPチームリーダーと学生リーダーが配置図の叩き台を作成。そこから会場レイアウトや参加者の動線を考えながら、細かい調整を重ねていきました。

設営中に急遽配置変更がありましたが、AP・CBチーム共に柔軟に対応出来てとても良かったです。最終的には、会場の規模・動線・想定利用人数を加味した、バランスの良い配置に落ち着きました。

机上だけの設計ではなく、実際の利用シーンを想定しながら決められたのは、とても実践的な経験になったと思います。

ホットステージ（＝本番）

本番では、PoE+対応スイッチやVLANをBBチームが用意してくれたおかげで、僕らは安心してAPを接続。設置から設定まで、ほぼトラブルなしで完了しました。「会場Wi-Fiってこんなに短時間で立ち上がるんや！」と驚きつつ、裏では地味に汗だくでケーブルを這わせてました（テキパキチーム全体で頑張って、凄く早く終わった…）。

運用と監視

Wi-Fiは立ち上げたら終わりではなく、運用が本番...SVチームが用意してくれたGrafana + Prometheusに、僕らが開発に関わったmerakiAPI exporterを組み合わせて監視しました。

  • 各APのクライアント数
  • 稼働状況（オン/オフ）
  • 接続品質

リアルタイムに見られるダッシュボードを作ったことで、安心感がかなり上がりました。

一方で、僕が作っていたRails + Chartkickダッシュボードは見事に失敗しました。画面には「Loading…」と出たままで、Railsログは200 OKが返ってきており、エラーも出ていませんでした。調べたら、原因はフロント側のJSエラーでした。chartkick/chart.jsがimportmapで解決できておらず、さらにjavascript_include_tagとjavascript_importmap_tagsを二重で読み込んでいたことが問題でした。

教訓: Railsログを見て「エラーないやん！」と安心してはいけない。困ったらブラウザのコンソールを見よう。

まとめ

今回のIWSC奈良での経験は、Wi-Fiを動かす技術以上に、知識をシェアしながらみんなで成長する仕組みがとても良かったと思います。すごくAPというものへのイメージがつきました!!!

  • 経験者が初心者に教える
  • 教わった初心者が、次は別の誰かに教える

まだ分からんけどやってみる → 失敗することを学ぶ → 次に活かす。

僕はリーダーでもベテランでもない、ただの弱々ですが、自分でネットワークを作るってめちゃくちゃ楽しいし、人から実機を使ってモノを教えてもらえる環境はとても大好きなので、今後も続けていきたいです。

ケーブル（CB）チーム

メンバー: 谷崎、滝口

ケーブルチームの谷崎です。私たちケーブルチームは主に事前のケーブル作成と当日の敷設作業を担当しました。今回のイベントに向けたケーブルチームの取り組みについて説明しようと思います。

事前準備

日程調整が難しかったため、他のチームとは別に作業日を設け、ケーブルチーム2人と学生リーダーの丸岡さんの3人で作業を行いました。

トポロジの決定

今回のイベントで繋げるべき機器には以下のようなものがありました。

  • ONU 1台
  • ルーター 1台
  • スイッチ 2台
  • AP 6台

また、これらに加えてステージ上の司会席、客席前方の配信席で用いるためのケーブルも必要だと伺っていました。この要望と会場の図面を元に実際にどの機器とどの機器を繋ぐのか、あるいはどのスイッチからケーブルを出すのかといったことをまず初めに考えました。基本的には素直に近くの機器同士を接続すれば問題ありません。しかし、会場の都合で壁の方に養生することができないため人通りの多いところの配線を避けたり、どちらかのルーターに障害が発生した時にも会場（特にホール内）での通信をカバーできるようにと考え、客席内の4台あるAPのうち1台は別のスイッチに繋げるようなトポロジとして以下の図のように決定しました。

配線図作成

次に取り組んだのは配線図の作成です。決定したトポロジを実現するために会場の図面を見ながら具体的にどこにケーブルを通すかということを考えました。トポロジの決定の時点である程度の配線は考えていましたが、必要なケーブル長を正確に算出するため、また会場当日の配線作業の際に困らないようにということを意識してできるだけ詳細に配線図案を書き込みました。特に客席後方に置くAP に関してはそれを意識しました。

ケーブル長の決定

会場図面に書き込んだ配線図を元にまずはケーブルの必要長を算出しました。ここでいう必要長とは要件を満たすために最低限必要な長さのことです。そして、必要長を元に実際に作成するケーブル長を決定しました。敷設作業の際のちょっとした変更やトラブルに対応できるように、必要長のおよそ1.3倍をケーブル長として設定しました。また今回使用できるケーブルは300メートルだったのでその範囲に収まるかも確認した上でケーブル長を最終的に決定しました。

ケーブル作成

続いて取り組んだのは、今回のメイン作業！ケーブルの作成作業です。ケーブルチーム2人とも初心者だったので、とても苦労しました。

今回のケーブル作成は以下のような手順で行いました。

  1. 決定したケーブル長をケーブル記載の目印に基づいて切り出し
  2. 8の字巻きしたのちケーブルをケーブルタイで固定
  3. 両端にRJ45コネクタを圧着
  4. ケーブル使用時に機器がリンクアップするかを確認
  5. ケーブル長と接続先を書いたタグを両端に貼付

この順に行った作業について説明していこうと思います。

まずはケーブルの切り出しです。先ほど決定したケーブル長に応じて、1mごとにケーブルに記されている目印を元に切り出しを行いました。中にツイストペアケーブルが入っているので当然ではあるのですが、切断する際に力が思ったより必要で驚いたのを覚えています。

次に行ったのは、その切り出したケーブルを8の字巻きしてまとめる作業です。ケーブルチームのメンバーが慣れていないこともあり、8の字巻きの練習も兼ねて短めのケーブルから始めました。元々の癖がついていたこともあり、10mのケーブルの時点でも最初は苦労しましたが徐々に慣れていきました。最後には50mケーブルの8の字巻きに取り組みましたが、径の大きさがなかなか揃わずやり直ししながらなんとか巻き終わりました。個人ではなかなかできない良い経験だったと思います。

その次はRJ45コネクタの圧着に取り組みました。今回は貫通型のコネクタを用意していただいたので、非貫通型と比べて長さズレを気にしなくていい点では楽に取り組むことができました。しかし、かしめの際に上手く力が入らなかった時にはコネクタからはみ出てケーブルを切ってしまうという貫通型ならではの難しさも学ぶことができました。

成端したケーブルは、その後断線していないかの判断のためにそのケーブルを使ってリンクアップするかを確認しました。この確認の際にリンクアップしなかったケーブルもあったので、当日のトラブルを避けるためにもこの確認は意味があるのだなと実感しました。

リンクアップができたケーブルは会場で実際に配線する際に接続先などを迷わないようにケーブル長と接続先を書いたタグを両端に貼付しました。自宅でのちょっとした配線でしかケーブルを使わなかった自分にとってはその発想は全くなかったのですが、今回のように大きな規模で配線する場合にはこういった工夫が必要なんだな、という学びになりました。

ご想像に難くないと思いますが、このケーブル作成作業に最も時間がかかりました...(丸岡さんが立ててくださったスケジュールより1時間以上長引いてしまいました)。しかし、時間がかかりながらも一つ一つケーブルを作っていけたため作業完了時の達成感もひとしおでした（イベント当日ではなく、時間が超過してもどうにかなる事前期間に作業できて本当に良かったです）。

イベント期間中の作業

敷設作業

敷設作業ができるのは当日の朝！会場に入ってすぐに敷設作業が始まりました。

1番のトラブルは今回の会場ネットワークの上流となるONUの設置場所を下手側だと思っていたのですが、実際は上手側だった点です。ここが予定から変更されたことにより20メートル程度のケーブルがもう1本必要になりました…幸い予備のケーブルとして長めのものを持ってきていたため、すぐに対応することができました。対処後すぐに敷設作業に入りました。先述の通り、会場の都合で床養生の配線のみだったため、人通りが多そうな箇所は避けたり、それが無理なら上に布を被せたりなどの対策を行いました。今回作成したケーブルの中で最も長かった50mのケーブルの敷設の際にケーブルが絡まってしまい、それを解くのには少々時間を必要としましたが、特に大きなトラブルも起きなかったこととAPチームの協力のおかげで、2時間もかからない程度で敷設作業は無事に終了しました。その後、BBチームやAPチームがそれぞれ構築作業を行いましたが、ケーブルに関する問題は特になかったため、その後の仕事としては時々見回りをする程度でした。

撤収作業

イベントでの閉会宣言が終わり次第すぐに撤収作業に取り掛かりました。主にケーブルチームとAPチームで撤収作業に取り組みましたが、それ以外のチームのメンバーや会場の方々も手伝ってくださったおかげでトラブルもなくあっという間にケーブルの撤収は完了しました。個人的には「8の字巻きにも慣れてきたぞ...!!」と思っていたら、撤収を手伝ってくださった有志の方々が巻きとる速度も綺麗さも自分を上回っており、まだまだ修行が必要だな...と感じられる良い機会となりました。

まとめ

今回ケーブルチームは2人とも初めてのNOC活動でしたが、担当学生リーダーの丸岡さんをはじめとした周りの方々のサポートもあって、無事にケーブルチームとしての務めを果たすことができました！そして、実際に手を動かす貴重な経験もすることができましたし、作業期間を通して同年代の仲間との交流ができたということも大きな財産となりました。一方で、成端作業に想像以上に時間がかかってしまったり、ケーブルの絡まりが発生してしまったりなどの反省点もあるので、またNOC活動に参加できる機会があればメンバーそれぞれその反省点を活かしていけたらなと思います。改めて、この貴重な経験の場に携わってくださったみなさま、ありがとうございました！

おわりに

今回のNOCでは、大きなトラブルなく快適な会場ネットワークを提供することが出来ました。一方で、事前検証の徹底、当日変更の判断など、改善の余地も見つかりました。次回のTeam Shirankedoの活動では、これらの教訓を活かし、より盤石で安定したネットワーク提供体制を確立したいと思います。最後に、今回の活動にあたり多大なるご支援・ご協力を賜りました関係者の皆様、最後まで走り切った参加メンバーに深く感謝します。この経験を次へと繋げ、関西から継続的に学びと挑戦が循環するイベントNOCを続けていきます。