ICTSC2025 本戦 問題解説: [3818] mottoup
概要
あなたは研究室で最近IPv6と冗長性を確保するためにルータをもう一台導入しました。とりあえず、研究室に転がっているサーバ2台と新たに追加したルータを含む2台で検証をします。 冗長性確保のためにVRRPの設定を2台のルータに設定後、IPv6のアドレス設定をサーバに入れようとするとなぜか入らないというトラブルが起きました。
トラブルを解決してIPv4,IPv6ともにVRRPによる冗長が取れていることを確認してください。冗長性の確認には、ルータがダウンした場合、またはルータのどちらかのインターフェイスがダウンした場合を含みます。 ルータのインターフェイスのダウンはVyOSのコンフィグ上から行ってください。

制約
- VRRPのPriority値の変更禁止
- 再起動してもServerのアドレスがついたままの状態
- 再起動してもルータの設定が維持されたままになる
- VRRP Masterのルーターで set interfaces ethernet eth1 disable を実行してインターフェースを落としてもpingが届くこと
初期状態
- SV-01,SV-02ともにeth1にIPv6アドレスが付いていない
終了状態
- SV-01からSV-02へIPv4,IPv6共にpingが通る
- 冗長性の確認が取れていること
- 問題文に示してある通り、どちらかのルータがダウンするか、どちらかのインターフェイスが落ちた場合でも通信が継続すること
解説
まず、今回の問題環境では以下の3つの問題が発生していました。
- SV-01,02ともにIPv6アドレスの設定と経路の設定がなされていない
- VRRPのMASTERが重複して存在していた
- VRRPの設定にてtrack interfaceもしくはsync-groupの設定がなされていないために冗長性が確保されていない
では、一個ずつ解説をしていこうと思います。
1. SV-01,02のIPv6アドレスが設定できない
SV-01,02のeth1にIPv6アドレスが付与できない原因は、インターフェイスのMTUにありました。
RFC 8200にてIPv6ではリンクのMTUは1280バイト以上でなければならないと規定されています。今回の環境ではSV-01,02のeth1のMTUが1000に設定されており、このためIPv6アドレスの付与が拒否されていました。
解決策はeth1のMTUを1280以上に設定することです。
# SV-01, SV-02 それぞれで実行
sudo ip link set eth1 mtu 1500
再起動後も設定が維持されるよう、netplanなどの設定ファイルに記載する必要があります。しかし再起動した際に、作問者が仕込んだ設定が悪さしてしまい期待通りの動作にならずになってしまっていたことを競技終了後に確認しました。申し訳ありませんでした。
想定では、MTUを1500にした後に元々ある/etc/netplan/50-cloud-init.yamlをapplyすることでアドレスの設定と経路の設定のどちらもできるようになっているはずでした。
2. VRRPのMASTERが重複していた
初期状態では各ルータのインターフェイスに以下のアドレスが設定されていました。
| ルータ | インターフェイス | 設定アドレス |
|--------|-----------------|-------------|
| RT-01 | eth1 | 10.200.1.251/24, 10.200.1.252/24 |
| RT-02 | eth1 | 10.200.1.252/24, 10.200.1.253/24 |
| RT-01 | eth2 | 10.200.2.251/24, 10.200.2.252/24 |
| RT-02 | eth2 | 10.200.2.252/24, 10.200.2.253/24 |
今回はIPアドレスの重複によりVyOSでのVRRPをunicastで行うhello-source-addressとpeer-addressの設定がされていることによって不整合が起こり、両方のルータがMASTERになってしまうことが原因でした。
user@3818-RT-02# run show vrrp
Name Interface VRID State Priority Last Transition
---------------- ----------- ------ ------- ---------- -----------------
ictsc-vrrp-10-v4 eth1 104 MASTER 100 5m57s
ictsc-vrrp-10-v6 eth1 106 BACKUP 100 6m1s
ictsc-vrrp-20-v4 eth2 204 MASTER 100 12h37m49s
ictsc-vrrp-20-v6 eth2 206 BACKUP 100 12h37m53s
解決策としては、重複しているIPアドレスを削除することで解決されます。もしくは、VRRPのhello-source-addressとpeer-addressの設定を削除して、VRRPをmulticastで行うようにすることもできますが、今回は前者の方法で解決することを想定としています。
# RT-01での設定例
delete interfaces ethernet eth1 address 10.200.1.252/24
delete interfaces ethernet eth2 address 10.200.2.252/24
commit
save
この修正により、VRRPのStateがPriorityの値によって正しくMASTERとBACKUPに分かれるようになります。
3. VRRPによる冗長性が確保されていない
VRRPはデフォルトの設定では、VRRPグループのMASTERルータ自身がダウンした場合にのみフェイルオーバーが発生します。そのため、MASTERルータのeth1がダウンしてもeth2のVRRPグループには影響がなく、片方のネットワークだけ切断された状態になってしまいます。
これを解決する方法として、track interface と sync-group の2つがあります。
- track interface: 特定のインターフェイスの状態を監視し、ダウンした場合にそのVRRPグループをFAILにする設定です。
- sync-group: 複数のVRRPグループをまとめて同期させる設定で、グループ内のいずれかのVRRPグループのStateが切り替わると、同じsync-groupに属するすべてのグループも連動してStateが切り替わります。
今回は設定が簡単な方であるsync-groupを使用する方法を紹介します。
# RT-01での設定
set high-availability vrrp sync-group ICTSC-SYNC member ictsc-vrrp-10-v4
set high-availability vrrp sync-group ICTSC-SYNC member ictsc-vrrp-10-v6
set high-availability vrrp sync-group ICTSC-SYNC member ictsc-vrrp-20-v4
set high-availability vrrp sync-group ICTSC-SYNC member ictsc-vrrp-20-v6
commit
save
RT-02にも同様にsync-groupの設定を行います。これにより、MASTERルータのいずれかのインターフェイスがダウンした場合でも、すべてのVRRPグループが一括してFAILに切り替わることにより、通信を引き込むことなく通信が継続されて行うことができるようになります。
以上により、終了条件を満たすことができるようになります。
採点基準
- SV-01,02のeth1のMTUが1280以上でIPv6アドレスが付与されていること 100点
- VRRPのStateが片方のルータがMASTER、もう片方のルータがBACKUPになっていること 50点
- VRRPの設定にtrack interfaceもしくはsync-groupが含まれており、MASTERであるRT-01のどちらかのインターフェイスもしくはRT-01がダウンしても通信が続けられること 50点
講評
今回の問題はIPv6アドレスの付与にMTUの値が関係するという問題を軸に、VRRPの設定の不備による冗長性の確保ができていないという問題を解決する問題でした。MTUの値がIPv6アドレスの付与に関係するということは、作問者自身2025年の夏前ぐらいにたまたま読んでいた本に載っていたことから知りました。VRRPの設定に関しては、MTUの問題だけじゃ弱いということでガチャガチャしていたら出会ったトラブルになります。
IPv6については、作問者自身はあまり詳しくないのでこれから皆さんと一緒に勉強を続けていければなと思っております。
おまけ
問題名のmottoupには実はmtuが隠れていたという話(ほんとにそれだけの話)