【IWSC静岡】NeGI NOCによる会場NW構築の舞台裏

はじめに

Internet Week Showcase in 静岡では、会場ネットワークの構築・運用をNeGI NOCが担いました。各チームが担当したネットワークの設計・構築・運用や、本番中に発生したトラブルへの対応、活動を通じて得られた学びを、参加メンバーの視点から振り返りたいと思います！

NeGI NOCとは

NeGI NOC（Next Generation Ikusei NOC）は、次世代のネットワークエンジニア育成を目的としたNOCチームです。総務省の「ネットワークエンジニアリング業界における人材確保・育成に関する調査研究」の一環として、2025年12月にJPNICで誕生しました。これまでChuNOGや3SNOGなどの地域NOGで活動してきましたが、今回、Internet Week Showcase では初めての取り組みとなりました。

NeGI NOCのコンセプトは、イベントネットワークを自分たちの手でゼロから設計し、構築・運用、そして撤収まで一通り体験することです。実際の機器に触れながら、メンバー同士で協力して、実運用に近い環境でのネットワークづくりを学びます。

今回のIWSC静岡での活動

今回のNOCメンバーは公募で募集し、東海地域だけでなく、全国各地から学生や若手技術者が集まりました。メンバーは、以下の3チームに分かれて活動しました。

• 　L2/L3-BB Team
• 　AP/Cable Team
• 　Server Team

また、各チームのリーダーも公募で集まったメンバーの中から選出しました。ネットワーク構築の技術だけでなく、チームをまとめるリーダーとしての経験も体験していただきました。

活動は5月下旬からスタートし、本番までの約1か月間、設計や構成の検討、機器の設定などをチームごとに進めました。準備はオンラインを中心に進め、本番の約2週間前に静岡で1日ホットステージを実施しました。その後、前日に会場へ入りネットワークをデプロイし、当日の午前中に設営を行うというややタイトなスケジュールでした。会期中はネットワークを提供しながら、発生したトラブルにもメンバーで対応し、運用までやり切ることができました。

ここからは、各チームがどのようなことに取り組み、どのようにIWSC静岡のネットワークを作り上げていったのかをご紹介します！

L2L3 BB Team

L2L3・BBチームは、会場ネットワークの根幹となるL2/L3機器の設定・構築と、上流トランジットとの接続開通を担当しました。

【作業内容】

• 各機器（floorスイッチ／コアスイッチ／コアルータ／BGPルータ）の設定
• 設定後の疎通検証
• VLAN・SNMPなどの基本設定投入
• FW・BGP・VPNの設定
• BGPによる上流トランジットへの経路広告

【L2L3】

L2L3チームでは、最終調整の都合上ホットステージ（本番設営）時に投入したスイッチの設定を消去し、前日に改めて設定を投入するという変更がありました。事前準備していたコマンドの中にはFS機器が対応していないものも含まれており、その場で臨機応変に対応する場面もありました。

実際の作業では、同じ設定を複数のスイッチへ誤投入してしまったり、ポートのズレが原因でスイッチ間の疎通が取れなかったり、IPv6のデフォルトルートが未設定だったためルータとスイッチ間で疎通できなくなるなど、さまざまなハプニングに見舞われました。

こうしたトラブルシューティングは、実際に機材を使ってconfigを投入する機会がなければ経験できないことだったと思います。

【L2L3メンバー感想】

• 入念に事前準備していても、実際に機材に触れ設定していく過程で想定外のことに苦戦したり、うまくいかない歯がゆさに直面し辛抱強く対処したことは、NOCでなければ経験できないことでした。今回のNeGI NOCでは、まさに知識を経験に変えることができました！
• 他チームのために想定より多めに予備ポートを設定したり、分かりやすいようにテープでポート番号を表示したりと工夫したことが、NOC本番で役立ったのも嬉しかったです！ 
• SyslogやSNMPなど普段あまり設定したことのないコマンドについて学べたり、ネットワークの構築・運用・破壊を経験できる貴重な時間を過ごすことができました。

【BB】

BBチームは、上流トランジットとの開通作業と、VPNを用いて上流と現地の接続、コアルーターを中心に担当しました。

ACL誤設定による接続不可や上流からIPv6経路が降ってこない等の問題に対処しながら当日を迎えました。

今回のBBチーム最大のトラブルが、WireGuardによる拠点間VPNで発生した「2分に1回、通信が切れる」現象です。

症状を調べていくと、ちょうど2分間隔で発生するWireGuardのhandshakeのタイミングに合わせて接続が落ちていることが分かりました。1回の切断につき5〜20秒程度の接続断が発生しました。「怪しいのはWireGuardのhandshake周りだ」と当たりをつけられたものの、原因の特定と解消にはチームで大苦戦しました。

最終的にWireGuardの鍵を作り直して両拠点に再設定したところ、瞬断は解消されました。

【BBメンバー感想】

• 初めてBBに触れたため、実践でやったら大目玉をくらうインシデントをやらかしまくりました…. いい経験をさせてもらいました。
• 今回のNOCを通じて、構築から運用、トラブルシューティングと幅広く知識を得ることができました。個人では触ることができない機器や環境を体験できてとても楽しかったです。
• 初めてのNOCでしたが、トラブルシューティングなど実践から得られるものが大きいと感じました。大学で勉強している時はパケットキャプチャに苦手意識がありましたが、実践になるとそんなことを言ってられず、パケットキャプチャへの抵抗はほとんどなくなりました。

AP Cable Team

AP Cableチームでは配線図をはじめとした各種構成図の作成、ケーブルの敷設、無線APの設定と本番中の監視を担当しました。

【作業内容】

• 配線図の作成(ケーブル長算出、APの配置決定など)
• ケーブル作成
• 機材設置作業
• 配線作業
• 無線APの設定(SSID作成、チャネルボンディング、帯域制御など)

【AP】

APチームでは、事前準備としてアクセスポイント(AP)の配置やWi-Fi提供におけるSSIDや認証方式を決定しました。今回使用したAPはCiscoのMeraki MR46で無指向性（電波が全方向に均等に飛ぶタイプ）であるため、自由度のある配置計画になりました。

前日準備では、Merakiがクラウド管理型AP（インターネット上の管理画面からまとめて設定する仕組み）であることに起因するトラブルが発生しました。ダッシュボード上ではAPのIPアドレスやDNSサーバ、DHCPサーバを正しく設定していましたが、APは「オフライン（接続切れ）」と表示されたままでした。

しかし、このときAPが提供しているWi-Fi自体には接続できており、PCからインターネットを見ることはできました。「ネットは繋がるのに、なぜAP自体は管理画面と通信できずオフラインになっているのか？」が疑問として挙げられていました。

上記の画像についてダッシュボード上（上半分）に表記されているap-04のMACアドレスの後半部分とターミナル上（下半分）で表記されているAP BSSIDの後半部分が一致していることから、端末がap-04と接続していることがわかります。しかしダッシュボード上ではap-04がオフラインと表記されています。

これはPC→AP→インターネットの通信はできていた一方で、AP自身がMeraki Cloudと正常に通信できていなかったため、Dashboard上ではAPがオフラインと表示されていました。

Merakiはクラウド管理型APであり、AP本体側の設定とDashboard側（クラウド側）の設定があります。APを物理的に初期化すると本体側の設定は消去されますが、APがMeraki Cloudと通信できる状態になると、Dashboard側に保存されている設定を取得して反映します。

今回の事象では、DNSやDHCP、VLANなどネットワーク側の問題も影響しており、APチームだけでは原因の切り分けが難しい状況でした。そのため、L2/L3チームやServerチームと連携しながら、ネットワーク全体の設定を確認し、問題を一つずつ解消していきました。

その後、APを初期化してMeraki Cloudと再同期させることで復旧しました。今回の対応を通じて、無線APのトラブルであっても、AP単体の知識だけではなく、VLANやDHCP、DNSなどネットワーク全体を理解することの重要性を学びました。

【Cable】

Cableチームでは、構成図や配線図の作成、配線図からケーブル長の算出、結線表の作成、ケーブルの成端、敷設等の作業を担当しました。

まず、会場の図面、下見に行った際の会場の写真などを元に各種機材の配置計画、配線計画を練りました。配線図の作成には Draw.io を、ケーブル長の算出には nk-cable-planner を利用しました。

配置/配線計画を立てる際には、NeGI NOCの備品としてファイバーケーブルの数と長さに限りがあったため、ファイバーを使用する区間（主にSwitch-To-Switch間）は手持ちの最長である30m以下であることを最低条件として、「ある程度手元にある資源として余裕のあるUTPケーブルの区間が長くなるのはやむなし」と許容する方向性で進めていきました。

ケーブル長算出は、nk-cable-plannerで実寸値を出し、それらをスプレッドシートの結線表で管理、余長を持たせるためにも実寸値を1.25倍し、小数点以下を切り捨てた内のキリのいい長さ(必要長)で出しました。

ケーブル作成では、ケーブル外皮に印字されているレングスマークを確認しながら切り出しました。

また成端作業の際、貫通型コネクタに苦戦していたところ、COREの塩沢さんから「貫通型のRJ-45コネクタを使う際、芯線を斜めにカットすると穴へ通しやすい」というちょっとしたコツを伝授していただき、その後はスムーズに成端作業を進めることができました。

こうした準備と作業を経て、機材設置と配線作業を無事に完了させ、いよいよ本番の運用を行いました。

当初は順調に稼働しているように見えましたが、実際の運用中、NOC部屋に設置していたAPがオフラインになるトラブルが発生しました。調査の結果、ドアの開閉時にLANケーブルが挟まれ、断線してしまったことが原因でした。設営時にその可能性は認識していたものの、「ドアの開閉頻度は少ないだろう」という想定と、当時の作業時間や優先順位を考慮した結果、対策を見送ったことがトラブルの原因になってしまいました。

復旧作業として、断線箇所のケーブルを切断し、新たにRJ-45コネクタを成端し直しました。その上で、ドアの隙間を通る部分にはフラットケーブルを採用し、両端をJJコネクタで接続することで無事に解決しました。この経験から、問題の切り分けを行う際には、物理層のような「低いレイヤー」の要因からもしっかりと着目していくことが重要だと感じました。

Cableチームとしてはこれ以外に大きなトラブルもなく、無事に運用を終えることができました。

一方で、配線の美観や取り回しについては有識者の方々から「まだ改善の余地がある」とフィードバックをいただきました。今回得られたアドバイスを活かし、次回はよりきれいで運用しやすい配線を目指して参ります！今回学んだことを活かして、今後参加するNOCでもさらに成長していけるよう頑張りたいと思います！！

Server Team

Serverチームでは、準備日までに会場ネットワークへデプロイするDNSサーバ・DHCPサーバの選定と構築、監視スタックの選定、各サービスの動作検証を行いました。

【作業内容】

• DNSサーバ・DHCPサーバとして使用するソフトウェアの選定
• 監視・可視化に使用するツールや構成の選定
• Proxmox VEのセットアップ
• Dockerを利用した各種サービスの構築
• DNSサーバの設定 (Unbound)
• DHCPサーバの設定 (Kea DHCP)
• Shumoku・Grafanaを用いたモニタリング
• 各サービスの事前検証および本番環境での動作確認
• 発生した問題のトラブルシューティング

Serverチームは2人と比較的少人数でしたが、それぞれが自由に利用できるProxmox環境を持っていたため、担当領域を分担しながら、仮想環境上で構築と動作検証を進めました。

DNSサーバにはUnbound、DHCPサーバにはKea DHCPを採用しました。DNSとDHCPをサーバ上で提供することで、会場内の端末やネットワーク機器に対する名前解決とIPアドレスの払い出しを行いました。

DHCP機能をルータ上ではなく専用のサーバとして構築することで、IPアドレスのリース状況や払い出し数を一元的に管理しやすくなります。また、Zabbixなどの監視システムとも連携しやすくなり、利用状況の確認やトラブル発生時の原因調査を行いやすい構成にしました。

また、会場ネットワークの状態を把握するため、Shumoku・Zabbix・SNMP・Grafanaを利用した監視・可視化環境を構築しました。Shumokuではネットワークトポロジを可視化し、SNMPによって取得したネットワーク機器の情報をGrafana上で確認できるようにしました。さらに、Zabbixによる監視も併用し、機器の稼働状況や異常を把握しやすい環境を整備しました。

【トラブル対応】

構築中には、DNSサーバが使用する53番ポートを開けない問題が発生しました。原因を調査したところ、Ubuntuで標準動作しているsystemd-resolvedが53番ポートを使用していました。そこで、/etc/systemd/resolved.confの設定を変更し、DNSStubListenerを無効化することで対応しました。

また、構築したDNSサーバへ接続できないトラブルも発生しました。調査の結果、トランクポートを経由して届いた通信に対して、仮想マシン側でVLANタグが正しく処理されていなかったことが原因でした。仮想マシンにVLAN 30を設定することで、DNSサーバへの接続を復旧しました。

これらの問題については、L2/L3チームと連携しながら切り分けを行いました。トラブル対応を通じて、DNSの名前解決の流れや、コンテナネットワークにおけるhostモードとbridgeモードの違い、Linuxにおける53番ポートの扱いなどについて理解を深めることができました。

【感想】

今回のNOCでは、サーバ単体の知識だけでなく、L2/L3チームをはじめとした他チームとの連携が重要であることを実感しました。 トラブルが発生した際も、サーバ側だけを確認するのではなく、VLANやネットワーク機器の設定も含めて原因を切り分けることで、問題を解決することができました。 今回学んだことを今後参加するNOCでも活かし、よりスムーズな構築やトラブル対応ができるようにしていきたいです！

おわりに

会期中にはさまざまなトラブルも発生しましたが、チームの枠を越えて原因を切り分け、一つずつ改善しながらネットワークを運用することができました。技術面だけでなく、メンバー同士で協力して問題を解決することも、今回の活動で得られた大きな経験だったと思います！

また、IWSC静岡のプログラムでは、NeGI NOCの取り組みや活動内容について発表する機会もいただきました。発表資料は以下からご覧いただけます。

C15 Internet Week Showcase in 静岡の会場ネットワーク〜NeGINOCによる構築の舞台裏〜

今回、ホットステージの会場や会場ネットワークの回線は株式会社TOKAIコミュニケーションズ様にご提供いただきました。この場を借りて、改めて御礼申し上げます。また、活動にご協力いただいた皆さまにも、心より感謝申し上げます。

最後に、2026年11月開催のInternet Week 2026では、IWNOCの活動を予定しています。メンバーの募集も行う予定ですので、イベントネットワークの構築や運用に興味のある方は、ぜひご応募ください！

IWSC静岡 / NeGI NOC メンバー

L2/L3 BB Team

AP/Cable Team

Server Team

Core Team