問題文

概要

あなたは、ある会社の社内ネットワークを運用するエンジニアである。

この会社では、拠点内の端末やサーバの増加、老朽化したネットワーク機器の置き換え、そして今後の運用効率化を目的として、社内ネットワークの大幅な更新を実施した。 更新作業では、L3 構成の見直し、アドレス設計の整理、各種インフラサービスの配置変更などがまとめて行われた。

更新作業自体は深夜帯に完了し、翌朝には多くの社員が通常どおり業務を開始していた。 しかし、始業後しばらくして情報システム部に「時刻同期が正しく行えていない」という報告が来た。

この会社では、セキュリティおよび監査の都合上、端末は必ず社内の内部 NTP サーバを利用して時刻同期を行う というポリシーになっている。 外部の NTP サーバへの直接アクセスは禁止されており、ファイアウォールでも制限されている。

あなたの役目は、「与えられたネットワーク環境を調査し、端末が社内ポリシーどおり内部 NTP サーバと正常に時刻同期できる状態へ復旧すること」である。

制約

• クライアント端末に静的経路を追加してはならない
• クライアント端末に NTP サーバアドレスを手動設定してはならない
• クライアント端末のネットワーク設定を手動で固定化してはならない
• クライアント端末の時刻同期設定ファイルを直接編集してはならない
• クライアントセグメントは IPv6 only を維持すること
• クライアントの IPv6 ユニキャストアドレス取得は SLAAC のみにより行われること
• 内部 NTP サーバのアドレス変更をしてはならない
• クライアントセグメント内に新たな NTP サーバを追加してはならない
• 時刻同期先は内部 NTP サーバとすること
• 新たなルータ、リレー、サーバを追加してはならない
• 既存機器の設定修正のみで解決すること
• 一時的な手動操作ではなく、恒久的な設定修正で解決すること

既存のネットワーク設計意図を尊重し、最小限かつ妥当な修正で解決すること

初期状態

• クライアントで timedatectl timesync-status などを確認すると、時刻同期が正常に行われていない
• クライアントは内部 NTP サーバ以外への UDP/123 通信が制限されている

終了状態

• クライアントで時刻同期が正常に行われる
• timedatectl show-timesync --all または timedatectl timesync-status で、内部 NTP サーバを参照していること、パケットカウントが増えていることが確認できる

ネットワーク図

解説

マリオカートのコース「チクタクロック」は、個人的に世界観がとても好きなコースでした。
その名前にちなんで「チグハグロック」という問題名にしてみました。
いかにも NTP に関する問題に見せかけつつ、実際には DHCPv6 の理解が問われる問題です。
名前に引っかかった人もいたかもしれませんね。
……え、LLM に解かせたから名前なんて見ていなかった？ そんな……。

今回の問題のテーマは、「DHCPv6 の意義を理解すること」でした。

IPv6 の自動設定には、主に SLAAC と DHCPv6 の二つがあります。
SLAAC は、ホストがルータ広告（RA）で受け取った情報をもとに、自身でアドレスを構成する仕組みです。
RFC 4862 でも、SLAAC は追加サーバを必要とせず、ルータが広告するプレフィックスとホスト側の識別子を組み合わせてアドレスを生成する方式として定義されています。
そのため、「SLAAC だけで十分なのでは？」と思うかもしれません。
しかし、SLAAC はあくまで 端末が最低限ネットワークにつながるための仕組みであり、各種の管理情報を柔軟に配る用途には向いていません。
今回の問題で重要になるのが、まさにその点です。

そして、SLAAC では配布できない情報の代表例の一つが、NTP サーバの情報です。
この点は、2025 年一次予選の問 13 でも扱われていました。
ICTSC2025 一次予選 問題解説: 問12 - 問15

この問題を覚えていれば、「IPv6 で NTP サーバ情報を配れていない」という状況を見たときに、DHCPv6 の設定に問題があるのではないかと疑えたはずです。
それでは、実際にルータの設定を見ていきましょう。

まず、比較的見つけやすい誤りとして、DHCPv6 で配布する SNTP サーバのアドレスが誤っていました。
本来は ::10 を指定すべきところが、誤って ::2 になっていた、という想定です。

set service dhcpv6-server shared-network-name 'CLIENT-LAN' subnet '2001:db8:100:1::/64' option sntp-server '2001:db8:200:1::10'

次に重要なのが、VyOS の DHCPv6 設定では、どのインターフェースで DHCPv6 を提供するのかを明示する必要があるという点です。
VyOS の公式ドキュメントでも、DHCPv6 の設定例では shared-network-name に対して interface を明示しています。
DHCPv4 ではあまり意識しないかもしれませんが、DHCPv6 ではリンクとの対応がより明確に求められるため、次のような設定が必要になります。
そのため、今回の問題でも次の設定が必要でした。

set service dhcpv6-server shared-network-name 'CLIENT-LAN' interface 'eth1'

（余談ですが、JANOG55 の NETCON でも、DHCPv6 の設定でインターフェース指定が抜けている問題を出題していました。
JANOG55 Level3-3 問題解説
こちらを解いたことがある人であれば、今回も比較的スムーズに気づけたかもしれません。）

ただし、これらを修正しただけでは、まだクライアントは NTP サーバ情報を受け取れません。

ここで鍵になるのが、RA（Router Advertisement）の O フラグです。
IPv6 の RA には、端末がどの情報をどこから取得するかを示すフラグがあり、代表的なものが M フラグ と O フラグです。
RFC 4861 では、M フラグは「アドレスは DHCPv6 により取得できる」ことを、O フラグは「アドレス以外の追加情報が DHCPv6 により取得できる」ことを示すと定義されています。さらに、M も O も立っていない場合は、DHCPv6 経由で取得できる情報はないことを意味します。

• M フラグ: アドレス設定を DHCPv6 で行うことを示す
• O フラグ: アドレス以外の追加情報を DHCPv6 で取得することを示す

今回のように、アドレス自体は SLAAC で設定しつつ、NTP サーバ情報のような追加情報だけを DHCPv6 で配布したい場合には、O フラグが有効になっている必要があります。

したがって、この問題では DHCPv6 サーバの設定だけでなく、RA 側でも次の設定が必要でした。

set service router-advert interface eth1 other-config-flag

ここまで設定したら、クライアント側でネットワーク設定を反映し直します。

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-timesyncd

すると、クライアントが DHCPv6 から NTP サーバ情報を受け取れていることが確認できるはずです。
……とはいえ、これで「めでたしめでたし」ではありません。
実際には、まだ時刻同期のパケットカウントが増えていないことに気づいた人もいたのではないでしょうか。

では、何が問題なのでしょうか。
試しにクライアントから NTP サーバへ ping を打ってみると、そもそも疎通が取れていないことが分かります。

原因は、NTP サーバ側に戻りルートが設定されていないことです。
クライアントから NTP サーバへの到達性だけでなく、NTP サーバからクライアントネットワークへの返り道も必要です。
そのため、NTP サーバ側でデフォルトゲートウェイをルータに向けるか、少なくともクライアントセグメントへの静的ルートを追加する必要があります。

たとえば、今回の構成であれば次のように設定できます。

sudo ip route add 2001:db8:100:1::/64 via 2001:db8:200:1::1 dev eth1

そのうえで、もう一度クライアント側から timedatectl timesync-status --all を確認すると、今度は NTP 関連のパケットがきちんと増えていることが分かるはずです。

この問題は、一見すると「NTP の設定ミス」を探す問題のように見えます。
しかし実際には、

• IPv6 における SLAAC と DHCPv6 の役割分担
• DHCPv6 で配る追加情報と RA の M/O フラグの関係
• そして最後に、単純な L3 到達性の確認

までを一通り押さえられているかを問う問題でした。

採点基準

• 50点: RA に other-config-flag を設定できる
• 30点: DHCPv6 サーバの interface 設定を修正できる
• 10点: DHCPv6 の sntp-server を正しいアドレスに修正できる
• 10点: NTP サーバにクライアント LAN 宛の経路を追加できる

※ VM 上では解決されていても、報告書に記載されてない場合は、該当箇所を減点とした。

講評

この問題を通して、私は LLM のすごさと限界の両方を改めて実感しました。

まず驚かされたのは、多くのチームがこの問題を解き切ったことです。
昨年であれば、ここまでの難易度の問題を出した場合、解けるのは数チーム程度だったのではないかと思います。
そう考えると、LLM の支援能力そのものの高さにも驚かされますし、それを参加者の皆さんがしっかり使いこなしていることにも感嘆しました。

一方で、LLM の限界も見えました。
それは「必ずしもベストプラクティスでは解いてくれない」ということです。
その代表例が、DHCPv6 のインターフェース設定を行うべき場面で、多くのチームが Kea の設定ファイルを直接書き換えていたことです。

本来であれば、今回必要だった修正は次の 1 行でした。

set service dhcpv6-server shared-network-name 'CLIENT-LAN' interface 'eth1'

今回は、「再起動後も設定が保持されること」といった制約を明示していなかったため、そこは問題作成側として反省すべき点でもあります。
その意味では、Kea の設定ファイルを直接書き換える解法も、問題の制約上は必ずしも誤りとは言えませんでした。

ただし、実際のネットワーク運用という観点から見ると、一般には直接ファイルを書き換えるのではなく、正規の config を変更するほうが望ましいと言えます。

その理由はいくつかあります。
まず、ネットワークエンジニアが障害対応や設定確認を行う際、最初に参照するのは多くの場合 config です。
したがって、config に記録されている内容と、実際に動作している設定が食い違っていると、その時点で調査を大きく難しくしてしまいます。
「設定は正しそうに見えるのに、なぜか動かない」あるいは「動いているが、なぜそうなっているのか分からない」といった状況は、現場では非常に厄介です。

さらに、config への変更は保存・記録されやすい一方で、Kea のような個別ソフトウェアの設定ファイルへの直接編集は、変更履歴に残りにくいことがあります。
そのため、後から見返したときに「誰が、いつ、何を変えたのか」が追いにくくなります。
加えて、再起動や設定再生成のタイミングで変更が消える可能性もあり、再現性の面でも不利です。

つまり、設定ファイルの直接編集という解法は、今回の競技では成立していたとしても、運用・保守・再現性という観点ではコストの高い方法だったと言えます。
そして今回のケースでは、本来は config を 1 行追加するだけで解決できる問題でした。
そう考えると、より複雑で壊れやすい方法を選ぶ必要は、実際にはほとんどありませんでした。

さらに驚いたのは、一部のチームが Kea の設定ファイルだけでなく、Kea のソフトウェア実装そのものに手を入れていたことです。
これは競技として見れば、「そこまでやるのか」と感心させられる行動でもありました。
一方で、実運用を前提に考えると、これはさらに慎重であるべき対応です。

基幹ソフトウェアの実装を直接変更すると、その場の問題は解決できたとしても、新たな不具合を埋め込んでしまう可能性があります。
また、一般に配布されているバージョンとは異なる独自実装になってしまうため、障害発生時に他の環境と比較しながら原因を切り分けることが難しくなります。
いわば、その環境が「世界に一つだけの挙動をするシステム」になってしまうわけです。
これは保守性や検証可能性の面で、非常に大きな負債になり得ます。

もちろん、今回はトラブルシューティングコンテストであり、問題文の制約に違反しない限り、どのような方法で解いてもよいという側面がありました。
その意味では、設定ファイルの直接編集も、ソフトウェア実装の改変も、競技上は成立する解法だったと言えます。
ただ、そこから一歩進んで考えたいのは、「解けたかどうか」と「その解き方が現場で妥当かどうか」は別の問題であるということです。

ここで見えてくるのが、LLM の特徴と限界です。
LLM は、与えられた状況に対して「とにかく動きそうな解決策」を幅広く提示するのは得意です。
実際、今回のようにかなり短い時間の中でも、多くのチームが問題を解き切ったという事実からは、LLM の支援能力の高さがよく分かります。
昨年であれば、この難易度の問題を解けるチームは数チーム程度だったのではないか、という感覚もあり、そういう意味では本当に大きな変化を感じました。

しかしその一方で、LLM が提示する解決策は、必ずしも運用上の妥当性やベストプラクティスまで十分に考慮したものとは限りません。
特に今回のようなネットワーク設定の問題では、その傾向がより強く表れたように思います。

LLM は、コードや数学のようにインターネット上に大量の学習データが存在する分野では非常に強力です。
一方で、ネットワーク設定、とりわけ VyOS のような比較的ニッチな製品や、実運用に根ざした設定作法になると、学習できる情報は相対的に少なくなります。
その結果、「確かに動くかもしれないが、現場ではあまり採りたくない方法」や、「一時的には通るが、保守性の低い方法」を、もっともらしく提示してしまうことがあります。
今回見られた、設定ファイルの直接編集や実装改変への誘導は、まさにその一例だったのではないかと思います。

つまり今回の経験から分かったのは、LLM は解答への到達を加速する力を持つ一方で、その解答が現場で望ましいかどうかの判断までは保証してくれない、ということです。
この点を意識せずに LLM の出力をそのまま採用すると、「とりあえず動いたが、あとで困る」構成を自ら作ってしまう危険があります。

だからこそ重要なのは、LLM が出してきた設定や解決策を、そのまま採用しないことです。
その方法は本当に適切なのか。
運用上安全なのか。
将来の保守や再現性まで含めて妥当なのか。
そうした観点から、人間が最後に判断する必要があります。

もちろん、LLM がさらに発展して、よりベストプラクティスに沿った解決策を提示できるようになる可能性は十分にあります。
一方で、いわゆる「2026年問題」として、インターネット上の質の高い公開データが学習に使い尽くされつつあるのではないか、という議論もあります。
そのため、LLM が今後もこれまでと同じペースで進歩し続けると考えるのは、やや楽観的かもしれません。
少なくとも、ネットワーク運用や設計のように、公開情報だけでは十分に表現しきれない領域では、なお人間の判断が重要であり続けるように思います。

単に「動く解」を選ぶのではなく、「なぜその方法を選ぶのか」「もっと簡単で安全な方法はないか」「それはベストプラクティスに沿っているか」まで考えられること。
それこそが、これからの時代のインフラエンジニアにますます求められる姿勢なのではないかと、私は考えるようになりました。