/

こんにちは!ICTSC8 問題リーダーの中西です。

大変遅くなりましたが、ICTSC8で出題された全問題の問題解説を公開します!
解けた問題は別解法の確認を、解けなかった問題は次回から解けるようになるために、是非勉強にお役立てください!

 


始まりの国

始まりの国には、様々な種族が住んでいる。エイトもこの国の出身である。
立地からか、外国との交流が盛んで旅人も多い。

永遠の国

エルフは魔法を使って生活を便利にすることが上手な種族である。
エルフの国はたくさんの村から構成され、村を指導する長は村人の尊敬を集めている。

謎の国 ICTSC

この国は未だに多くのことが謎に包まれている。
外国との交流は少なく、内情を知るものはほとんどいない。
一説では、政府が強大な力を持ち、魔法陣を使った交信を厳しく制限しているという。

荒廃の国

かつては栄えた国だったが、長く続いた内乱のせいで今は見る影もない。
治安は悪く、盗賊が人々を悩ませているという。

伝統の国

この国はドワーフを中心に構成されている。
ドワーフは何よりも繋がりを大切にしている種族である。
しかし自分の種族以外の人を冷たい目で見ることがある。

研究の国

この国では研究が盛んであり、教育にも力を入れている。
国の各地に学校があり、見習い魔導師たちが机を並べて勉強している。

ホビットの国

この国には、サーバが得意なホビットがたくさん住んでいる。 ホビットは商売が上手く、この国最大の会社であるホビットカンパニーは他国にもその名を轟かせる。

妖精の国

妖精の国がどこにあるのかは知られていない。しかし、たまに迷い込む者がいるという。妖精は様々なものに姿を変えて、出会ったものを惑わすと伝えられている。

 /
カテゴリー

問題文

エイト「早速だけど、ギルドに案内するね。ギルドっていうのは国を超えて様々な情報を交換するところなの。クエストの依頼もたくさん集まっているわ」

エイト「ほら着いた! ここがギルドよ。……あら、あのドワーフ、なにか考え込んでいるようね。ちょっと話を聞いてみましょう」

ドワーフ「魔法陣を構築したんやけど、上手くsshができへんねん。なんとかしてくれへん?」

エイト「ちょっと見てあげてくれない? あっそうだった……『魔法陣』の説明をしないとね。魔法陣はあなたたちの世界におけるネットワークのことよ。ネットワーク機器に関してはあんたたちの世界の物と一緒だから安心しなさい!」

起こっていたトラブル

192.168.200.253(2960-A)にsshするとconnection refusedと表示される。

トラブルの概要

vtyと呼ばれるネットワーク機器の仮想コンソールが枯渇していることにより、
sshしても仮想コンソールがないのでconnection refusedと表示されるというものでした。

採点基準

始まりの国の1問目ということもあり、sshができるようになれば方法は問わない、という採点基準で出題しました。

解法一覧

想定外な解法もありましたので、想定していた解法とともにご紹介いたします。

想定していた解法

  • show userなどでユーザー情報を確認し、clear line vty でvtyを解放する。
  • vtyへのアクセス制御設定

未想定だった解法

  • 秘密鍵の再作成を含む、sshの再設定

講評

解答は15チーム中14チームから来ており、採点基準を他の問題よりも多少低く設定していたため全ての解答が満点でした。
個々の解答を見ると connection refused というエラーメッセージのためなのか、
sshの設定が不十分あるいは未設定でsshできていなかったと判断したチームが数多くありました。
その際の不足している設定で transport input ssh との記載が多く見受けられましたが、
今回使用した機械では上記の設定を入れなくてもvtyが空いていればsshは可能になっていました。

14チーム中1チームだけvtyの枯渇について言及している解答があり、
状況をよく調べられていると感じました。

 /
カテゴリー

問題文

トラブルを解決したことで、宿の料金は無料になった。

エイト「お金も浮いたことだし、服を買いにいきたいの。近くに服屋さんはないかパソコンで調べるわ……ってめちゃくちゃ重たくて調べられない〜!」

エイト「たぶんトラフィック量が多いのね。服を買うために何とかできない?」

トポロジー図

トラブルの概要

AS65100からAS65300宛の通信(大会中はICMP)がAS65200を経由して行われていたため、
AS65200内のトラフィックが多くなっていた。

採点基準

BGPのピアを切断せずにAS65200内のトラフィックを削減すること。

解法

as-path access-listを用いてAS65100への広告経路に対してフィルタリングをかける

ip as-path access-list 1 permit ^$
router bgp 65200
neighbor 192.168.4.19 filter-list 1 out
neighbor 192.168.4.3 filter-list 1 out
exit

講評

6チームから回答があり、1チームが基準点、1チームが満点となりました。
基準点に満たない解答にはBGPのピアを切断したり、AS番号を変更したりしてトラフィック量を減らす回答が見受けられました。
しかし、BGPピアの切断やAS番号の変更は行ってよいものではないため、0点の解答と判断しました。
BGPピアを切断しないこと、AS番号の変更をしてはいけないことを注意事項として問題に明記していればよかったと反省しています。

その中、 想定していた解答ではありませんでしたがas-path prepend を用いてトラフィックを削減した解答があり、BGPのピアを切断せずにトラフィックを削減していたことで満点としました。
BGPはインターネットで欠かせない技術であるため、問題を通してBGPへの理解を深めていただければ幸いです。

 /
カテゴリー

問題文

スイッチの問題を解決した後、ドワーフに話しかけられた。

ドワーフ「いや~まさか本当にトラブルを解決するとはビックリしたぜ。ついでにもう一つ頼まれてくれないか?」

ドワーフ「実は魔法陣の構成を 892j から 1941 に変更して、同じ呪文を書き込んだんだがNAT-PTが動作しないんだ。頼む……この通りだ」

エイト「コンフィグを使いまわしたってこと? そんなことするから動かないのよ。悪いけど、あんたたちやってあげてくれない?」

起こっていたトラブル

NAT-PTが機能していないため、v4の宛先にpingが飛ばない。

トラブルの概要

Cisco Express Forwardingと呼ばれるスイッチング技術がCiscoの機器ではデフォルトで有効になっているのですが、
この技術がNAT-PTに対応していないことで、pingが飛ばない状況になっていました。

採点基準

  • NAT-PTを機能させること
  • IPv6アドレスのみを持つPCからIPv4のホストに対してpingが通ること

解法


no ip cef
no ipv6 cef

上記のコマンドでcefを無効化する。

講評

この問題を解放した時期の差はありますが、全てのチームが解放しているにもかかわらず、
8チームからしか解答が来ていない問題となっていました。
解答をしてくれたチームで見ると、8チーム中7チームが満点となっていました。
NAT-PTはIPv4/IPv6の共存技術の中でもあまり知られていない技術だと個人的に思っているので、
皆さんの調べる力を試す問題として出題しました。

最終的に7チームが解答未提出となり、チーム間での調べる力の差なのかなと感じました。

 /
カテゴリー

こんにちは!始まりの国 第二のトラブルの問題解説をします。

この問題はLinuxの機能であるiproute2を使うことでLinuxでもポリシールーティングのような機能を使うことができ、それが原因でGoogle public DNSに接続できないという問題でした。ウォーミングアップ問題の割に解答率が低くなってしまい、知らなきゃ解きにくい問題だったので少し申し訳ないことになってしまったと反省しています。

問題文

問題文は以下の通りです。

エイトが一行を案内していると、ギルドでの活躍が伝わったのか、エルフのお姉さんが話しかけてきた。

エルフ「サーバに呪文を書き込んだんだけど、DNSの魔法が動いてないっぽいのよ。ドワーフのおっさんから話は聞いたけど、君たちバリバリできるんだって? いい感じにしてくれない?」

エイト「ちょっとあんたたち呼ばれているわよ。……『呪文』が何かわからないって? 呪文は……そうねたしか設定ファイルとかコンフィグって意味だったと思うわ。はやく解決してきなさい」

また、補足事項として以下のような情報を与えました。

Google public DNSの8.8.8.8もしくは8.8.4.4で名前解決をできるようにしてください。

問題の再現

以下の内容を /etc/networking/if-up.d/static-route に記載して再起動を行うことで、 8.8.0.0/16 に接続できなくなります。

ip rule add table 100 prio 200
ip route add 8.8.0.0/16 via 127.0.0.1 table 100

設定された内容は以下のコマンドで確認することができます。実際に試してみるとよいかもしれません。

# ip rule show
# ip route show table 100

何故このようなトラブルが起きるかというと、Linuxのデフォルトのルーティングテーブルは ip rule show では優先度のpriorityが低く設定されています。それよりも高い優先度でヌルルーティングされてしまったため、パケットが送られないように見えているというわけです。また、 ip rule はあまり見るものではないので気づきにくかったかと思います。

採点基準

この問題の採点基準は以下の3点になっています。

  • ルーティングされていないことに気づく
  • 修正しつながることを確認する
  • ip rule が原因であることに気づく

また、どんな形でもGoogle public DNSにつながり名前解決できていることを確認できれば次に進むことができるようになっていました。

解答例

  • pingtraceroute を使い、DNSが引けない原因がL3疎通性にあることを確認する
    • その際、宛先が 8.8.8.8 のパケットに対して一切外のデバイスから返答がないことからヌルルーティングなどをされていると検討を付ける
  • ip route などの現在のルーティング情報や /etc/networking/ 配下などネットワーク系の設定をするファイルを探し原因を特定する
  • /etc/networking/if-up.d/static-routeをバックアップを取ったうえで削除し、 ip rule del table 100 とすることでGoogle public DNSにつながることを確認する

以上の点を作業経過とともに報告書形式で提出してもらえれば満点を与えました。

講評

冒頭でも書きましたが、iproute2を一切触ったことのない人にとっては非常に解きにくい良くない問題だったかなと反省しています。

ただし、原因について言及せずに /etc/networking/if-up.d/static-route を削除して再起動したら治りました、という回答が多く見られました。その際には

ip rule が原因であることに気づく

という採点基準をもとに減点をしています。大抵の場合はトラブルをどんな形でさえ解決すれば次の問題に進むことができます。しかし、次回以降参加する際にはとりあえず治ったからOKではなくトラブルの原因について言及すると満点を得ることができ、上位を狙うことができるかと思いますので参考にしていただきたいと思います。

 /

おはようございます、作問者のやつはしです。

今回は、リソース削減・ネットワーク基盤に依存しないために全て一つのVM上で完結させました。

残念ながら、この問題に辿りついたチームは1つで、解答数は0でした。

日の目を見ることはなかった問題ですが、SDNに関する問題は、今までなかったので参考問題として公開します。

 

問題文

無事に課題が終わったパトリシアは、学校を案内してくれることになった。

パトリシア「課題を手伝ってくれてありがとう♪。じゃあ学校を案内するね」

食堂や教室、体育館などを案内してもらった。

パトリシア「ここが最後よ–ここは私が志望してる研究室で、魔法陣の仮想化を研究しているの」

パトリシア「教授は、OpenFlowを使って特殊なNATを作成しているの……でも、昨日Dockerコンテナに移行してから動いていないそうなの」

エイト「ふむ、ここで教授に恩を売っておきたいところね」

パトリシア「そうなの、でも、私一人じゃできなくて……何度も悪いんだけど、手伝ってくれないかな?」

アクセスできるサーバー

  • サーバ名 : openflow
  • アドレス : openflow.3.mgi
  • ユーザ : admin
  • パスワード : hello_openflow

注意事項

  • VyOS1・VyOS2・VyOS3・VyOS4のIPアドレス・サブネット・VLANに変更を加えてはいけない。(Config自体は変えてもよい)
  • コンテナの停止・再起動は許可する。

達成すべき事項

  • VyOS4で ping 172.16.100.150 を実行し、VyOS3より返答を受け取れる。
  • OpenFlow を使って、 192.168.1.2->172.16.100.150 の SNAT と 172.16.100.150->192.168.1.2 の DNAT を実現する。

その他

OVSがインストールされたUbuntu上に、以下の5つのコンテナが存在する。
– VyOS1(192.168.1.1/24 & 172.16.100.100/24)
– VyOS2(172.16.100.200/24 & 10.30.100.1/24)
– VyOS3(192.168.1.2/24)
– VyOS4(10.30.100.2/24)
– OpenFlowController(Docker Default Network)

以下に簡単なトポロジーを示す。
VyOS3(192.168.1.2)-(192.168.1.1)VyOS(172.16.100.100)-(172.16.100.200)VyOS2(10.30.100.1)-VyOS4(10.30.100.2)

解説

この問題は、OpenvSwitch上でOpenFlowを動かしたもの。

まず、この問題の初期状態は、このようになっている。

OVSの設定を

sudo ovs-vsctl show

で確認すると、VyOS3-VyOS1,VyOS2-VyOS4では、

sudo ovs-vsctl set-fail-mode br0 standalone
sudo ovs-vsctl set-fail-mode br2 standalone

で設定してあり、L2スイッチとして動作している。
次にVyOS1-VyOS2では、

sudo ovs-vsctl set-fail-mode br1 secure

で、OpenFlowのエントリーによって処理されている。
そこで、

sudo ovs-ofctl dump-flows br1 --protocols=OpenFlow13

でエントリーを確認できる。
エントリーでは、図に書いてあるようなIP変換のみ処理されている。
ここでarpによるmacアドレスの解決ができないことに注目する。
なのでVyOS1とVyOS2でお互いにstaticでmacアドレスをお互いに登録する。
しかし、VyOSのconfigにインターフェースの設定を書いた場合、OVSにインターフェースの主導権をとられているため、反映されない。
VyOS1とVyOS2には以下のコマンドでvbashに入る

docker exec -it vyos1 /bin/vbash
docker exec -it vyos2 /bin/vbash

そして、linuxの処理として

arp -s 172.16.100.100 "VyOS2のmacアドレス" dev eth1
arp -s 172.16.100.200 "VyOS1のmacアドレス" dev eth1

staticでmacアドレスと登録する。
これでL2を解決できた。
次に、VyOS3からVyOS4にICMPパケットを飛ばすには、
VyOS1で

docker exec -it vyos1 /bin/vbash
su - vyos
configure
set protocols static route 10.30.100.0/24 next-hop 172.16.100.200
commit
save

のように設定する。
この設定で、ルーティングができるようになったのでICMPパケットが飛ぶ。

これでSDNの一端であるOpenFlowを用いた問題は解決である。
SDNでは、arpやDHCPなどL2の処理をプログラムしなければならない煩わしさがあるが、この問題のようにトポロジーを工夫することで、こういったNATやファイアーウォールなどのフィルターを、簡単に書き導入することが可能である。
ICTSC7では、運営でNAVT(Network Address Vlan Translation[作問者命名])と呼ばれるVLAN+IPaddressを全く別のIPに割り当てることでそれぞれのチームのセグメントIPを同じにし、運営からは、任意のIPアドレスで全チームにアクセスできるようにした。

 

 /

伝統の国 第3のトラブルの問題解説を以下に示します。

問題文 

NAT-PTの問題を解決した後、再びドワーフが話しかけてきた。

ドワーフ「2つもトラブルを解決してくれるとは驚いた。俺とあんたたちはもう家族も同然だよな? だから最後にあと1つだけいいか?」

エイト「え~まだあるの?」

ドワーフ「実は新しく喫茶店の支店作っていてなぁ~。そことIPsecで魔法陣をつなぎたいんだが、うまくつながらないんだ。なんとかしてくれよ~俺たち家族だろう?」

エイト「もう~調子がいいんだから。何度もごめんね。これだけ手伝ってあげてくれない?」

トポロジー図

採点基準

  1. IKEPhase1の成功が確認することができる。
  2. IKEPhase2の成功が確認することができる。
  3. 参加者手元PC及びルータからpingコマンドが通ることを確認することができる

解説

今回、1841と1941双方のルータには、通常のIPsec(NAPT前のアドレスによる記述)が設定されていました。
そのため、真ん中のルータにより、NAPT変換されることによって正しく通信が行えない状況でした。
今回はTEDによる解決方法による解答方法を記述します。(別解は後述)
1841に設定されたIPsecの記述を全て消した後
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 30 periodic
crypto ipsec transform-set T-IPSEC esp-3des esp-md5-hmac

これによりTEDによるIKEPhase1が成功します。
次に
crypto map M-IPSEC 1 ipsec-isakmp
set peer 192.168.140.2
set transform-set T-IPSEC
match address 101

interface Gi0/0
crypto map M-IPSEC

以上の記述でIKEPhase2が成功します。
そして、対向からのpingですが、帰りのパケットに対するルート情報が記述されていないため
ip route 192.168.130.0 255.255.255.0
を追記します。
別解としては、NAPT変換されていることが根本的な問題ですから、IPsecのアドレスをNAPT後のアドレスにすれば解決することができます。

まとめ

いかがでしたか?
この問題は基準点以上の正答チームは7チーム(前問のtypo)中1チームでした。
真ん中のルータを触れなくした理由は単純に真ん中のNAPTルータの設定を消すことを阻止するためでした。
debugコマンド、手元環境の論理図を書くこと等を用いると解答しやすかったのではないかと思います。

 /
カテゴリー

こんにちは,ぱろっくです.

妖精の国 第二のトラブルに関する解説を書かせていただきます.

問題文

国から国への船旅の途中、激しい嵐に遭った。荒れ狂う海の中で波に流され、気がつけば小さな島に漂着していた。

エイト「何とか元の航路に戻りたいけど……船の修理が終わるまでこの島で過ごすことになりそうね」

探索していると、島の中央に神殿があることに気づいた。神殿の柱には見知らぬ文字と美しい模様が刻まれていたが、何を表しているのかはわからなかった。そして、祭壇には大きな黒い箱が安置されていた。

エイト「何だろうこの箱……ってサーバじゃない」

詳しく調べてみると、そのサーバは強大な力を持っていることがわかった。そして、その中には先人の訪れた形跡があった。

エイト「どうやらこのサーバの力を試してみようとしたけど、途中で力尽きてしまったようね。この強大な力を使えれば、魔法の研究や応用が爆発的に発展するに違いないわ! よくわからないけど、私たちで動かしてみましょう」

採点基準

  1. CUDAのシンボリックリンクがcuda-8.0ではなくcuda-7.5にはられているのに気づき,修正してmakeが通るようになっている.
  2. GPUのスレッド数をTitanXの上限まで落としてsuccessと出力できている.

解説

この問題では,近年流行しているGPUプログラミングに関するものでした.普段触ったことのない方には新鮮に感じたと思います.これをきっかけにGPUプログラミングに興味を持ってもらえたら嬉しいです.

今回起きていたトラブルは,まずCUDAを新しいバージョンに入れ替えた際にシンボリックリンクが張り替えられていない問題が発生していました.

makeファイル内で記述されていたコンパイル時の-arch及び-codeコンパイラオプションをTitanX(pascal)に合わせていたのですが,古いバージョンの方にシンボリックリンクがはられたままであったためコンパイルが通りませんでした.

そのため,まずシンボリックリンクを張り替えれば,このトラブルは解決し,コンパイルが通るようになります.

次に,実行ファイルの出力がfailedになってしまうトラブルが起きます.

これは,ファイル内でGPUの1ブロックあたりのスレッド上限数である1024を超えてしまい,処理が正常に行われていないため起こるトラブルです.

そのため,ソースコード内のスレッド数の指定を1024以下に変更するなどの対策をすればトラブルが解決しsuccessと出力されるようになります.

まとめ

以上が本問題の解説となります.

この問題は,さくらインターネット株式会社様の「高火力コンピューティング」サービスから機材提供をしていただきました.ご提供していただき本当にありがとうございました.問題提供していた環境を普段も使いたいという方はこちらをご参照ください.

 /
カテゴリー

問題文

一行は学校に行ってみたいというエイトの夢を叶えるために、学校を訪れた。

エイト「ここが学校か~、頭が良さそうな感じがしていいわね!」

女の子「いっけない、遅刻遅刻〜」

「「いたっ!?」」

女の子「ごめんなさい。昨日から魔法陣は動かないし寝坊して遅刻するし踏んだり蹴ったりだわっ」

エイト「最後は自分のせいなんじゃ……。ちょっと待って! この人たちなら力になれるかもしれないわ!」

女の子「学内のWebページにも繋がらない。色々触ってみたけど無理だったの……DNSサーバが原因じゃないかと思うんだけど」

エイト「うーん……。いったいどのあたりを触ってみたの?」

女の子「学内のWebサーバに繋がらなくて、でも学外のWebサーバには繋がってたの。よくわからなくて、スイッチも設定を見ていろいろやってたら今度は学外サーバにも繋がらなくなっちゃって…もうよくわからないわ」

エイト「なんだか他人事とは思えないわ……助けてあげてくれない?」

達成すべき事項

  • http://devtest.dns.1.mgi(コンテストネットワークでのみアクセス可能なドメイン)から任意のHTML(テストページを含む)を取得する。
    • スイッチ(2960-A_fa0/11)に接続したPCのDNSをdns.1.mgi(192.168.19.10) に設定した上でアクセスできることが達成条件です。

解説

発生していたトラブルは
① 手元のスイッチからDNSサーバへ疎通が取れない
② DNSサーバが学内ドメインの名前解決に失敗している
の2点でした。

トラブル①について

お手持ちのPCとスイッチを接続しIPアドレスを設定してもDNSサーバへ疎通が取れなかったと思います。
ここでスイッチのコンフィグを見てみると、

 interface FastEthernet11
 switchport access vlan <各チームに割り当てられたVLAN ID>
 switchport mode trunk

となっています。
“switchport mode trunk”を削除するか、”switchport mode access” と設定をしてあげることでトラブル①は解決します。

トラブル②について

用意されたDNSサーバに対して学外ドメイン(google.comやyahoo.co.jpなど)の名前解決を行う場合はしっかりIPアドレスが返ってきます。
一方で学内ドメイン(devtest.dns.1.mgi)はIPアドレスが返ってきません。しかし、会場に提供されていたWi-Fiを経由して運営が用意したDNSサーバを使ってdevtest.dns.1.mgiにアクセスすると、正常に名前解決は成功し、テストページを開くことができました。
女の子が用意したDNSサーバに何か問題がありそうです。

DNSサーバにはdnsmasqがインストールされていました。何かあったときはエラーログです。/var/log/syslogを見てみると

 Aug 25 11:19:23 dns daemon.warn dnsmasq[18697]: possible DNS-rebind attack detected: devtest.dns.1.mgi

のような出力がされています。
DNS-rebind attackとは、

DNS Rebindingは、DNSの返すIPアドレスを巧妙に変化させることにより、JavaScriptやJavaアプレットなどのsame origin policyを破り、インターネットからローカルネットワーク(通常外部からはアクセスできない)などに対してアクセスする手法をいう。

DNS Rebinding ~今日の用語特別版~ – 徳丸浩の日記より引用)

と説明されています。TTLを極端に短くした状態で(5秒など)ターゲットに悪意のあるドメインへアクセスさせ何らかのスクリプトを読み込ませます。その後、攻撃者は悪意のドメインのレコードをプライベートIPアドレスへ変更することで、攻撃者はスクリプトを使用して情報取得を行うことが可能となります。

先ほどのdnsmasqのログは 「DNS Rebinding攻撃と思われる挙動を検知した」、と言っていることがわかります。
思えば、devtest.dns.1.mgiのレコードを引くと返ってくるのはプライベートIPアドレス(172.16.67.2)です。

となれば、dnsmasqの防御機能を無効化する or ドメインのホワイトリストを設定してあげればOKです。

/etc/dnsmasq.confを見てみると、

 stop-dns-rebind

という設定が末尾に書かれています。これをコメントアウトしdnsmasqを再起動すると名前解決ができるようになります。
あるいは、

 rebind-domain-ok=1.mgi

という設定を加えることでも名前解決ができるようになります。

余談

どちらのトラブルも私の実体験で起こったものです。
トラブル①に関しては、スイッチの設定をあれこれいじったり試していて、いつの間にかこうなっていた…というトラブルでした。
トラブル②に関しては、大学の研究室に一時的にOpenWRTを載せたルータを設置したときのことでした。Webアクセスは問題なく行えるのに、なぜか学内のNTPサーバに対する時刻同期が出来ないと研究室のメンバーに言われ、最初は学内のNTPサービスが終わっちゃったんだなあ…と思ってました。IPアドレスが返ってこないということは抹消されたんだな、と。授業中、ふと学内無線LANを使用してNTPサーバの名前解決を行ったところ、消えたと思っていたIPアドレスが返ってきました。奴は生きていた。帰ってきたんだ…。ここからは必死に原因を調査して解決した…というお話でした。

 /
カテゴリー

荒廃の国 第一のトラブルの問題文

ドワーフが経営している寂れた宿に訪れた。

ドワーフ「いらっしゃいませ……何もないところですがごゆっくりしてください……。」

エイト「ありがとうございます。 あれ? 宿の魔法陣が繋がらないわ?」

ドワーフ「すいません……。盗賊対策にACLを書いたんですが、繋がらなくなって困っているんです……」

エイト「なるほどね。これはあんたたちの出番じゃない?」

達成すべき事項

参加者手元PCからloopback0にpingが通る。

概要

この問題では、ACLとVRFサポートの設定の不備によりIPアドレスが付与されなくなっていたため、そもそもPCにIPアドレスが付与されていないことに気付く必要がありました。

この問題は、ACLとVRFサポートの設定の両方を変更することで解決できます。

問題の達成条件はpingを通すことだったので、手動でIPアドレスを設定することで達成できますが、DHCP問題を解決することで追加点がありました。

解法

以下の設定をすることで、DHCPの問題が解決されます。

ena
conf t
ip access-list extended guild
permit udp any any eq 67
exit
ip dhcp use vrf remote
exit

講評

前回に引き続きVRFを使用した問題を出題しましたがいかがだったでしょうか?

参加者の解答状況は前回よりも多くなっていたため、過去の問題解説からVRFの対策をしていたように見受けられましたが、手動でIPアドレスを設定して通過するチームが多くDHCPの問題まで解決できているチームはほとんどいませんでした。

最近のコメント