/

問題文

上記のトポロジー図の通りに配線してある機材に設定を投入しましたが、Router-Bから対外への疎通が取れません。
そのため、Router-Bから対外疎通がとれるようにしたいと考えています。
Router-AにGigabitEthernet1側が外部ネットワーク、
GigabitEthernet2側が内部ネットワークとなるようにNATの設定を書き加え、
Router-Bからインターネット(例えばIPアドレス8.8.8.8)へpingを飛ばせるようにしてください。
pingを飛ばす際、経路はRouter-Aを経由します。
Router-AでIPアドレスの設定変更をする必要はありません。

解答メールを送る際は、
・参加者が設定したコンフィグ
・Router-Bからのpingコマンド実行結果
を添えて下さい。

ゴール

Router-AにNATの設定を書き加え、Router-BからRouter-Aを経由してインターネットにpingを飛ばせるようにする。

トラブルの概要

Router-Bから、Router-Aを経由して対外接続がはかれない。

解説

今回はCiscoのルータにNATの設定を書き加えてもらう問題でした。
Router-Bは、Router-AにNATの設定を施すことによって対外疎通が可能になります。
こちらの解説では、当初想定していた回答とよく見られた別解を説明します。

まず、当初想定していたNAPT(PAT)の説明をします。
NAPTの設定をする際はまずNAPT変換対象とする送信元IPアドレスをAccess-listで定義する必要があります。
access-list 1 permit any
例えば上記のように設定すると、全ての送信元IPアドレスを許可します。
続いて先程定義したAccess-listと外部インターフェースを関連付けさせます。
ip nat inside source list 1 interface GigabitEthernet1 overload
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

続いてよく見られた別解であるスタティックNATを説明します。
NAT変換する 「 内部ローカルアドレス 」 と 「 内部グローバルアドレス 」を定義します。
ip nat inside source static 10.0.0.100 192.168.0.100
上記では最も多かった192.168.0.100を内部グローバルアドレスとして定義しています。
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

なお、Poolを用いたNATやNAPTで設定していても正答となります。

解答例

NAPT(PAT)の場合

!Router-A
!
enable
!
configure terminal
!
!
access-list 1 permit any
ip nat inside source list 1 interface GigabitEthernet1 overload
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

 

[別解]スタティックNATの場合

!Router-A
!
enable
!
configure terminal
!
!
ip nat inside source static 10.0.0.100 192.168.0.100
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

採点基準

  • グローバルコンフィグレーションモードでNATの設定をしている(30%)
  • 内部ネットワーク,外部ネットワークの指定を各インターフェースに適切に設定している(30%)
  • 8.8.8.8等グローバルIPアドレスにpingが通る(40%)

講評

こちらはトラブルを解決するのではなく、参加者に一部だけ構築してもらう問題でした。そのためか回答結果がチームによってさまざまでとても面白かったです。回答を提出してくださったチームのうち、正答であるチームは多かったです。

 /

問題文

Router1とRouter2は最近、EBGPピアを張ることを決定しました。Router1に設定を行い、Router2とEBGPピアを張ってください。EBGPピアを張ることができたかどうかは、「show ip bgp summary」で確認できます。
なお、以下の注意事項に沿って設定してください。
・ 設定できるルータはRouter1のみです。
・ Router1のAS番号は「1」で設定してください。
・ Router1のebgp neighborを張る宛先はRouter2のLoopbackを指定してください。

情報

この問題のトポロジー図は以下になります。

「sh ip bgp summary」の結果の一番下の行の右端が「0」になっていれば、ピアを張ることができています。

実行例を以下に記載します。この結果では下の行の右端が「0」になっています。

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 6 8 1 0 0 00:03:39 0

スタート

Router1とRouter2間のEBGPピアの設定を行なっていない状態。

ゴール

Router1とRouter2間でEBGPピアが張ることが出来ている。

トラブルの概要

neighborやremote-asの設定だけでLoopback間のEBGPピアを張ることができない。

解説

Router1からRouter2にEBGPピアを張るには、BGP Neighborの設定が必要です。
今回の問題ではCisco機材を使用しているため、Cisco用のコマンドによる設定になります。
具体的には以下のような設定が必要になります。

enable
configure terminal
router bgp 1
neighbor 2.2.2.2 remote-as 2

ですが、これだけではEBGPピアを確立させることはできません。
本来、EBGPピアは、実際に接続されているインターフェース間で行われることが一般的で、
追加の設定をしない限りは、それを前提にピアを張ろうとします。

しかし、今回の問題では、Loopbackインターフェース同士でピアを張る必要があるため、
追加の設定が必要になります。具体的な設定は以下になります。

ip route 2.2.2.2 255.255.255.255 192.168.1.2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop

3つの設定をBGPの設定に加えることで、Loopbackインターフェース間でEBGPピアを張ることができるようになります。

上から、説明していきます。

ip route 2.2.2.2 255.255.255.255 192.168.1.2

これは、Router1がRouter2のLoopbackのアドレスを知らないから疎通性がないことを解消するための設定です。ピアを張る際は、そのインターフェースと疎通性が取れないと張ることができないからです。

neighbor 2.2.2.2 update-source loopback 0

BGPメッセージを送る際の送信元をRouter1 のLoopback 0に指定します。デフォルトでは、送信元はRouter1の物理インターフェースに指定されているため、送信元を変える必要があります。

neighbor 2.2.2.2 ebgp-multihop

EBGPでピアを張る際のBGPのメッセージのTTL(Time to live)の数を増やすために設定します。
EBGPピアを張る際のBGPメッセージのTTLはデフォルトで「1」に設定されているため、Loopbackインターフェース間だとTTLが足りなくパケットロスが起きてしまいます。なお、「ebgp-multihop」の後に引数を指定しないと「255」になります。

以上の設定を踏まえて、最終的な解答コンフィグを以下に記載します。

解答例

!Router-A
!
enable
!
configure terminal
!
ip route 2.2.2.2 255.255.255.255 192.168.1.2
!
router bgp 1
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop
!

採点基準

  • Router2のASに向けて、neighborやremote-asのコマンドが正しく設定できている(10%)
  • Router2のLoopbackに向けて静的ルートを追加されている(30%)
  • update-sourceコマンドでLoopbackを指定することでアドレスが一致している(30%)
  • ebgp-multihopコマンドでTTLの値を「1」より大きな値に変更できている(30%)

講評

この問題はBGPでルーティングを行う際に、最初に行うEBGPピアを張ってもらう問題でした。
Loopbackインターフェースを用いることを前提に設定を組んでいたチームが半分を超えていて、出題してよかったと思います。
EBPGピアを張る際に、Loopbackを用いることもできることを知っていただけたら幸いです。

 /

問題文

toporogy.png
この問題の世界では172.20.0.0/16はインターネットで使われるアドレスで、ISPから割り当てられるものとする。192.168.0.0/16はプライベートIPアドレスである。
ある企業に東京本部と大阪支部があり、大阪支部はISPから172.20.1.1、東京本部には172.20.2.1がそれぞれISPから割り当てられている。またどちらもそれぞれルータ osaka , tokyo でNAPTして使用している。

事前準備

VNCサーバにSSHしたら、そこからPCfumidaiにSSHしてください。アクセス情報は以下の通り。
・IPアドレス:192.168.0.10
・ユーザー名:admin
・パスワード:password

このPCfumidaiはルータosaka配下に設置されたPCで、もう一つのIPアドレス192.168.10.1が割り当てられている。
まず疎通確認として、CloudflareのPublicDNS1.1.1.1にtracerouteして下さい。大体以下のようになればOK。

[admin@fumidai:~]%traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 gateway (192.168.10.254) 1.220 ms 1.138 ms 1.110 ms
2 172.20.1.254 (172.20.1.254) 1.299 ms 1.290 ms 1.298 ms
以下省略

STEP1. GREトンネル開通

現時点では、大阪支部と東京本部では別々にNATしているため、大阪支部から東京にあるサーバにアクセスすることはできない。
これを解決するため、各ルータで拠点間VPNを張る必要がある。(上図紫の部分)
今回は、拠点間VPNの一つであるGRE TunnelをルータosakaにSSHして設定してください。(ルータtokyoの設定は不要)

アクセス情報、および設定要件は以下の通り。
・IPアドレス:192.168.10.254
・ユーザー名:gre
・パスワード:tunnel
・enableパスワード:tunnel

要件
・プロトコル:GRE
・IPアドレス:192.168.100.1/24
・tunnel送信元アドレス:172.20.1.1
・tunnel宛先アドレス:172.20.2.1
・MTU:1400byte

STEP2. default route切替

GRE Tunnelの設定ができましたら、次は、大阪支部から外部へのパケットがすべて東京本部を経由するようにルータosakaに設定してください。

回答項目

以下の内容を回答してください。
・ STEP1で入力したコンフィグ
・ PCfumidaiから東京本部のサーバ192.168.20.1へのtracerouteの結果のコピペ
・ STEP2で入力したコンフィグ
・ 1.1.1.1へtracerouteした結果のコピペ
show running-configのコピペ

ゴール

ゴール (STEP1)

拠点間VPNの一つであるGRE Tunnelをルーターosaka側に設定する

ゴール (STEP2)

大阪支部から外部へのパケットがすべて東京本部を経由するようにルーターosakaに設定する

トラブルの概要

GREトンネルの構築とデフォルトルートの切り替え

解説

GRE(Generic Routing Encapsulation)は、トンネルプロトコルの1つです。トンネルプロトコルにはLayer2トンネリングのL2F、PPTP、L2TPと、Layer3トンネリングのGRE、IPsecなどがあります。このトンネリングとは、あるトラフィックを別のプロトコルでカプセル化して伝送する技術のことです。パケットのカプセル化とその解除はトンネルの両端の機器で行うため、両端の機器が直結しているように見えます。GREトンネリングでは、任意のプロトコルのパケットをIPトンネル内でカプセル化しています。GREトンネリングを行なう両端のルータで、あるトラフィックに対するカプセル化とその解除を行います。
(ネットワークエンジニアとして(https://www.infraexpert.com/study/rp8gre.htm)より)

今回はCiscoのルータでGREトンネルを一から張ってもらい、デフォルトルートを切り替える問題でした。
STEP1はトンネルインターフェースのIPアドレス、GREトンネルの送信元・送信先アドレス、プロトコルとMTUを要件に従って設定するだけで完了します。
STEP2はデフォルトルートの切り替えですが、それだけではGREトンネルでカプセル化されたパケットの経路情報がなくなるため、そのためのスタティックルートを別途設定する必要があります。

解答例

STEP1.

interface Tunnel0
ip address 192.168.100.1 255.255.255.0
tunnel source 172.20.1.1
tunnel destination 172.20.2.1
ip mtu 1400
tunnel mode gre ip
[admin@fumidai:~]%traceroute 192.168.20.1
traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  1.766 ms  1.706 ms  1.706 ms
 2  192.168.100.2 (192.168.100.2)  2.638 ms  2.633 ms  2.640 ms
 3  192.168.20.1 (192.168.20.1)  2.875 ms  2.845 ms  2.793 ms
[admin@fumidai:~]%

STEP2.

no ip route 0.0.0.0 0.0.0.0 172.20.1.254
ip route 0.0.0.0 0.0.0.0 192.168.100.2
ip route 172.20.2.1 255.255.255.255 172.20.1.254
[admin@fumidai:~]%traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  0.753 ms  0.722 ms  0.704 ms
 2  192.168.100.2 (192.168.100.2)  0.891 ms  0.875 ms  0.817 ms
 3  172.20.2.254 (172.20.2.254)  1.389 ms  1.365 ms  1.338 ms
以下省略

送られてきた解答の中にこれかこれに準ずる内容が含まれていたら得点としています。

講評

今回は1次予選ということで、競技ではあるもののどちらかというとハンズオンセミナーのようなイベントで出されそうな問題を意識して作りました。
その中でSTEP1はそこそこのレベル、STEP2は発展レベルの問題という感覚だったのですが、STEP1まで解けたチームがおよそ6割、STEP2まで完答したチームがおよそ3割程度だったので、思ったよりも解けていた印象でした。
今回はすべてIPv4を用いての問題でしたが、このようなトンネリング技術はIPv6移行技術としてもよく用いられる技術であるためこの機会にぜひ勉強してみてください。

 /

1問目

問題文

IPv6問題 No.1 ステートレスアドレス自動設定(SLAAC)

以下の選択肢のうち、ノード起動時におけるSLAACの順序として正しいものを選択してください。
a. ノードはリンクローカルユニキャストアドレスを生成する
b. ノードはユニークローカルユニキャストアドレスを生成する
c. ノードはグローバルユニキャストアドレスを生成する
d. ノードはマルチキャストでRSパケットを送信する
e. ノードはエニーキャストでRSパケットを送信する
f. ルータはRSパケットを受け取ったらRAパケットを返信する
g. ルータはRSパケットを受け取ったらDHCPv6でアドレスを作りRAパケットで返信する

選択肢

  • b → e → f → c
  • a → e → f → b
  • a → d → f → b
  • a → d → g → c
  • a → d → f → c
  • a → e → g → b

解説

IPv6ではDHCPがなくてもIPアドレスとデフォルトゲートウェイが設定できるようになりました。
この問題はそのステートレスアドレス自動設定(SLAAC)の手順に関するものです。
選択肢がやたらと多いのは勘や順序の傾向から適当に解くのを防ぐためです。
その結果としてですが正解が2つできてしまいました、採点中に気がついたのでどちらでも得点が入っていますが、競技中に悩んだ方は無駄に時間を取らせてしまい申し訳ないです。

さて正解ですが、以下の2つです。

  • a → d → f → c
  • a → d → f → b

文章にすると以下になります。
1. ノードはまず、リンクローカルユニキャストアドレスを生成する
2. リンクローカル全ルータマルチキャストでRS(ルータ要請)パケットを送信する
3. ルータがRSパケットを受け取るとリンクローカルユニキャストでRA(ルータ応答)パケットを返信する
4. ノードはRAからグローバル(or ユニーク)ユニキャストアドレスを生成する

講評

調べれば簡単に分かる問題なので正答率は高かったです。

2問目

問題文

IPv6問題 No.2 EUI-64

以下のMACアドレスからユニキャストアドレスのインターフェースIDを自動生成した場合に適切なものを選択肢から選んでください。

94:de:80:6c:8e:4d

選択肢

  • fe80::94de:80ff:ff6c:8e4d
  • 94de:80ff:fe6c:8e4d
  • ffff:94de:806c:8e4d
  • 96de:80ff:fe6c:8e4d
  • 94de:80ff:ff6c:8e4d

解説

IPv6のSLAACではEUI-64でMACアドレスを変換し使用することによってユニークなアドレスを生成できます。
IPv6のアドレスはプレフィックスとインターフェースIDからなり、これはIPv4のネットワークアドレスとホストアドレスに対応します。
この問題はEUI-64でMACアドレスからインターフェースIDを生成した場合どうなるかを答えるものです。

変換の手順は以下です。
1. MACアドレスを24ビットずつに分割(半分)
2. 分割した間に0xfffeを挿入
3. 7ビット目を反転

正解は 96de:80ff:fe6c:8e4d です。

講評

不正解の解答ではステップ3を忘れているケースや、ステップ2で0xfffeではなく0xffffを挿入しているケースが多く見られました。
ちなみに検索するとEUI-64コンバーターが出てきます。
http://silmor.de/ipaddrcalc.html#ip6

この手の計算問題は自分でやると間違えるのでコンバータに任せましょう。

3問目

問題文

IPv6問題 No.3 IPv6豆知識

以下のIPv6に関する文章の中から最も正しいものを選んでください。

選択肢

  • IPv6ではアドレス解決にARPv6を使う
  • RA(Router Advertisement)パケットではDNSアドレスを通知することができない
  • ICMPv6はDos攻撃に利用されるため常にフィルタしたほうが良い
  • ユニークローカルアドレスはルータを超えられる
  • IPv6にはIPv4射影アドレスがあるので、宛先ノードがIPv6非対応でもIPv6で通信することができる

解説

IPv6について雑多に知識を付けてもらおうと思い出題しました。
選択肢の中で最も正しいのは ユニークローカルアドレスはルータを超えられる です。

それぞれの選択肢を解説していきます。

IPv6ではアドレス解決にARPv6を使う

IPv6ではL2でのアドレス解決にARPではなくICMPv6を使います。

RA(Router Advertisement)パケットではDNSアドレスを通知することができない

策定当初はRAでDNSアドレスを配布することはできませんでしたが現在は可能です。
ただし実装されているとは限りません。
不幸なことに、DNSアドレス配布周りでは幾つかの規格があり、端末とルータによって実装がバラバラです。

ICMPv6はDos攻撃に利用されるため常にフィルタしたほうが良い

上にも書いてありますが、ICMPv6をフィルタするとL2でのアドレス解決ができない、SLAACが使えないなどの問題があります。

ユニークローカルアドレスはルータを超えられる

リンクローカルアドレスはルータ超えできませんが、ユニークローカルアドレスはルータを超えられます。
これが正解です。

IPv6にはIPv4射影アドレスがあるので、宛先ノードがIPv6非対応でもIPv6で通信することができる

IPv4射影アドレスを使うとアプリケーションはIPv4アドレスをIPv6アドレスとして処理できますが、実際の通信ではIPv4を使います。
そのため、宛先ノードがIPv6非対応でもIPv6通信ができるというのは厳密には間違いです。

講評

おおよその正否は調べれば分りますが、「射影アドレス」と「ルータ越え」のどちらにするかで悩んだチームが多いようです。
この場合、問題文に「最も正しい」とあるので少し悩みどころのある前者ではなく、後者が正解となります。

 /

問題文

背景

あなたは今、とあるネットワークに参加しています。
このネットワークはIPv6で構成されていて、あなた以外にも不特定多数のユーザーが参加しています。
このネットワークには管理者によって1台のルーターが設置されていて、ユーザーはネットワークに参加すると自動でIPアドレスが設定されるようになっています。
このルーターは別のIPv6ネットワークにも繋がっていて、そこには1台のサーバーが動いていて、ルーターは2つのセグメント間を繋げています。
本来なら、あなたはルーターを経由して別セグメントにあるサーバーにアクセスできるのですが、なぜかできません。

※ この世は性善説で成り立っているわけではありません

問題

このネットワークは下記の画像の用になっています。
あなたはクライアント1です。
IPv6セグメント1には複数の端末が繋がっていますが、あなたが操作できるのはクライアント1とルーターのみです。
踏台サーバーはマネジメントセグメントでルーターとクライアント1に繋がっていてIPv4でsshできます。
IPv6セグメントに繋がっている端末は自動でIPv6アドレスが設定されます。
クライアント1とルーターは設定変更や再起動など自由にして構いません。

クライアント1からサーバーにpingが通らない原因を調査し、報告してください。
正常に通信できるようにする必要はありません。

情報

ssh用のIPv4アドレスは図にある通り

  • ルーター: 192.168.0.1/24
  • クライアント1: 192.168.0.2/24

ルーターとクライアント1のユーザー名とパスワード(共通)

  • ユーザー名: admin
  • パスワード: ipvvvvvv

サーバーのIP確認方法

  • ルーターにログインし、運営が予め用意したtargetコマンドを実行する
  • 注) コマンド実行時に補完しようとするとエラーがでますが実行はできます

例)
admin@vyos:~$ target
fd00:2::9999:8888:7777:6666

捕捉、注意等

環境破壊やシャットダウンしてしまった場合

  • メールで知らせてください
  • 減点はありませんが、復旧に時間がかかる場合があります

ゴール

この問題のゴールはクライアント1からサーバーに疎通が取れない原因を調査し報告することです。

トラブルの概要

IPv6ネットワークが用意されていて、そこでクライアントからサーバーに通信したいがなぜか疎通が取れない。
その原因を調べるという問題でした。

解説

この問題はざっくり言うとDHCP snoopingのRA版です。
実際には以下の図のように競技者が操作するクライアント1の他にもう一台、クライアント2(仮称)があります。
実はこのクライアント2がただのクライアントではなく悪意のあるルーターになっていて、ルーターと同じようにRouter Advertisement(以下RA)を流しています。
ただし、悪意のあるルーターが流すRAは正規のルーターのRAより優先度が高くなっています。
そのため、クライアント1がマルチキャストでRouter Solicitation(以下RS)を送り、両方のルーターからRAが帰って気た場合、優先度の高い悪意のあるルーターのRAが使われてしまい、IPv6のデフォルトゲートウェイが悪意のあるルーターになります。
クライアント1がサーバーと通信するために、正規のルーターにパケットを送ったつもりが、悪意のあるルーターにパケットが行ってしまうためサーバーとの疎通が取れないというわけです。

解答例

原因の調査手順としては以下です。

  1. pingを送る -> 通らない
  2. tracerouteのネクストホップとルーターのアドレスが違うことに気づく

  3. IPv6セグメント1で ip neigh を確認しルーターとクライアント1以外にも端末(クライアント2)があることに気づく
  4. tracerouteのネクストホップがクライアント2なことに気づく
  5. クライアント1のルーティングを確認する -> デフォルトゲートウェイがRAになっている

上記の1~6をまとめて「ルーターでは無いところにパケットを飛ばしてる」ことが明記されていれば50%です。
その後パケットを見るなどしてLAN内にクライアント2が存在することと、RAを流していることを明記すると50%です。

採点基準

大まかな採点基準は以下です。
1. tracerouteでパケットがルーターでは無いところに送られていることを明記する 50%
2. パケットキャプチャし、LAN内に悪意のあるルーターがありRAが流れてきていることを明記する 50%

惜しい所まで書かかれている解答には適宜、部分点を付けました。
問題文に「原因を調査し、報告してください」と書いてあるので原因について明記されていない場合は減点しました。

講評

この問題はIPv6をちょっと触って欲しい、RAによるステートレスアドレス自動設定(SLAAC)を知って欲しいという意図で出しました。
その上でIPv6のRA関連のトラブルってなんだろうなー と考えたとき思いついたのが偽RAです。
問題の性質上、後半でどうしてもエスパー感が出てしまうのでLAN内に悪意のある端末があるヒントとして問題文に「この世は性善説で成り立っているわけではありません」と記述しました。

最高得点は70%(245点)で、残念ながら満点はいませんでした。
50%のボーダーを超えたのは3チームです。
大半の解答が0点となりましたが、その理由の多くは「問題文を読んでない」、「出力の勘違い」、「明記してない」です。
普段使うツールでもIPv6の表記に慣れていないため、コマンドの出力結果を読み間違えたような解答がちらほらと見受けられました。

問題文

[トラブル1] ZabbixからSNMPで監視ができない。。。

自宅の検証環境でZabbixからVyosをSNMPで監視したいのだがSNMPのホストをZabbixに登録しても監視ができない。原因を突き止めトラブル対応をし、ZabbixからVyosを監視できるようにしてください。
踏み台サーバにログインをして以下のアクセス情報を使ってトラブルシュートすることができる。

情報

接続情報

  • Zabbix
    IPアドレス: 192.168.0.5
    SSH-ID: admin
    SSH-パスワード: fG9bycDJ
    ZabbixコントロールパネルURL: https://192.168.0.5:8080 (VNCサーバからFirefoxを使ってアクセスすることができます)
    ZabbixログインID: admin
    Zabbixパスワード: zabbix

  • Vyos
    IPアドレス:192.168.0.10
    SSH-ID: admin
    SSH-パスワード: fG9bycDJ
    SNMPのcommunity: ictsc2018-pre1

ゴール

Zabbixのコントロールのパネルホスト一覧からVyosのSNMPの監視のところが赤色から緑色なればゴールです

[トラブル2] Grafanaが起動できない。。。

自宅の検証環境をZabbixではグラフの可視化がいけてないのでGrafanaというOSSをdocker-composeで構築・可視化をしていたのだがGrafanaのアップデートが来ていたのでアップデートしたら起動できなくなってしまった。原因をつきとめてGrafanaのコントロールパネルを見れるようにしてください。

情報

- docker-compose.ymlはadminユーザのホームディレクトリにあるdocker-composeフォルダにあります
- バージョンアップ前はdocker-compose.yml.old、バージョンアップ後はdocker-compose.ymlです
- docker-compose up -dするとエラーが吐かれて起動できません。
- バージョンアップ前のdocker-compose.ymlを試しに使うと起動できます
- ~/docker-compose/.volume/ にGrafanaコンテナで使うデータが入っています。このデータは必ずアップデート後も引き継いでください

接続情報

  • Grafanaサーバ
    IPアドレス:192.168.0.6
    SSH-ID: admin
    SSH-PW: fG9bycDJ
    GrafanaのコントロールパネルURL: 192.168.0.6 (VNCサーバからFirefoxを使ってアクセスすることができます)
    GrafanaID: admin
    GrafanaPW: grafana

ゴール

Grafanaが無事起動ができ踏み台のVNCサーバのWebブラウザからGrafanaのコントロールパネルのログイン画面が見れればゴールです。

禁止事項

- ~/docker-compose/.volumeを削除する・アップデート後のコンテナで使わないというのは禁止です。
  必ずGrafanaコンテナにマウントしてデータを引き継いでください。

トラブルの概要

[トラブル1]

これはVyos側の snmp communitysnmp portが間違っている単純な設定ミスのトラブルでした。

[トラブル2]

このトラブルはこのGrafanaというOSSの特有のトラブルとなっております。トラブル自体はとても簡単でGrafanaの公式ドキュメントの Installing using Docker を読まれた方はすぐに解けたのではないでしょうか。
公式ドキュメント

解説

[トラブル1]

よくみるとVyos側のcommunity側の文字が ictc2018-pre1 でとなっており問題文で指定されたcommunity名と違います。ちなみにZabbix側の設定は ictsc2018-pre1 となっており正しいものとなっています。
またVyosのSNMPのportの設定が 162 と指定されおり、これも修正する必要があります。

[トラブル2]

このトラブルはGrafanaのバージョン5.1以降からはUIDが変更されております。ですので5.1以前に作成されたファイルはそれ以降のバージョンでは正しいアクセス権を持たないので使えません。
これを解決するには新しいコンテナ作成時にUIDを変えてしまうという手段があります。
user-id-changes

解答例

[トラブル1]

admin@vyos# delete  service snmp community ictc2018-pre1
admin@vyos# set service snmp community ictsc2018-pre1 authorization ro
admin@vyos# delete service snmp listen-address
admin@vyos# set service snmp listen-address 192.168.0.10 port 161
admin@vyos# commit
admin@vyos# save

[トラブル2]

docker-compose.ymlのGrafanaのサービスのところに以下を追記する

    user: "104"

講評

全49チーム中
トラブル1だけ解けたチーム: 5チーム
トラブル2だけ解けたチーム: 0チーム
トラブル1,2両方解けたチーム: 9チーム

トラブル1はVyosを使ったことある人なら簡単に解けたかと思います。
SNMP?Vyos?Zabbix?なにそれ思った方は是非一度自分で調べて自分で構築することをおすすめします。
どんどん自分だけの検証環境を作って試してみるといいかもしれません。
トラブル自体はとてもとても簡単なので解けなかったチームはしっかり復習しましょう。

トラブル2を解けたチームはログを見る・ドキュメントを調べる・ぐぐるという基本的なことがしっかりできていた印象が解答から感じられました。
解けたチームはしっかりとエビデンスやドキュメントのURLを貼って報告してくれてました。
またあるチームはGithubのissueまで調べたというのもありました。

 /

1問目

問題文

SNMPが使うポート番号は次のうちどれでしょうか。
– 160/TCP
– 160/UDP
– 161/TCP
– 161/UDP

解説

161/UDPはSNMPエージェント(監視されるもの)が使用し、
162/UDPをSNMP TRAPで使用します。
TCP/IP – SNMP

解答例

  • 161/UDP

講評

調べれば誰でも解ける問題ということもあり全チームが正解してました。

2問目

問題文

対象機器のホスト名(sysName)を取得するOIDは次のうちどれでしょうか。
– .1.3.6.1.2.1.1.5
– .1.3.6.1.2.1.1.4
– .1.3.6.1.2.1.2.1
– .1.3.6.1.2.1.2.5
– .1.3.6.1.2.2.2.5
– .1.3.6.1.2.1.1.3

解説

OIDとはオブジェクトIDのことです。SNMPで監視する際はOIDを指定して監視したいデータを選択し取得します。

解答例

  • .1.3.6.1.2.1.1.5

講評

こちらの問題も調べれば誰でも解ける問題ということもあり、全チームが正解していました。

 /

問題文

我が社では事業拡大に向けて、これまで別々に活躍していた2つの会社を統合することにした。

事務所を新たに開設したのだが、ネットワーク設計がまだ途中のため、
暫くの間は本社で余ったルーター1台を間に挟んで通信をすることにした。

しかし、エンジニアは既に設計の方に出払ってしまっているため本社にいる手の空いている人間に構築をさせた。

本人から完成しましたと連絡を受けネットワークを使ってみたのだが2つの事務所から疎通が全く取れず、困っている状況である。

早急に担当したエンジニアに設計をやり直せといったのだが本人は「めとりっく?の値とかワケワカンナイ…無理っしょ」なんてブツブツつぶやき

「ユ○バで彼女とデートがあるんで。」

と言い残して帰ってしまった。

こちらでは君たちだけが頼りである。すまないが早急に対応をお願いしたい。
帰った部下にはきついお灸を据えたいので原因の報告も合わせて頼みたい。

それからエンジニアの数人には連絡が取れるので、もし何か必要なことがあれば彼らに聞いてくれ。

本社から持ち込んだルーターは892jである。

制約

  • 禁止事項
    • 892jを除くルーターへのアクセス全般(設定変更、コンフィグ参照など)
    • ルーティングプロトコルの変更
    • IPアドレス、サブネットマスクの変更

スタート

  • 各拠点のルーターから892jに疎通が取れない
  • 892jを超えて拠点間で通信ができない

ゴール

  • 892jと隣接が結べていること
  • 892jを超えて各拠点で通信ができること
    • 対向拠点ルーターに192.168.12.1/26が存在します。疎通確認に使用してください。
  • 報告事項
    • 疎通が出来なかった原因(複数ある場合は全て)
    • 上記にともない追加、削除、変更を行ったコマンド全て
    • 892jのshow run結果 ## 情報 (任意)

トラブルの概要

この問題は、これまで別々に活躍していた支社を統合し新たな事務所への移行作業を行っている最中を想定しました。

ネットワークのトポロジは次のようになっています。

トポ図

問題の初期状態では参加者の手元PCからLoopBackに疎通がとれません。

解説 (必須)

まずはshow run の結果を見てみます。
するとと下記のようになっているはずです。

!
router ospf 721 vrf vrf12
    router-id 2.2.2.2
    network 192.168.12.0 0.0.0.3 area 12
    exit
!
!
router eigrp 406
    address-family ipv4 vrf vrf12 autonomous-system 406
      eigrp router-id 2.2.2.2
      network 192.168.12.0 0.0.0.3
      exit

ちなみですが、参加者から設定できるルータ間ではEIGRPが動作しています。
ですのでまずは、EIGRPのルーティングの設定部分を見てみます

892j#show run | begin eigrp
router eigrp 406
    address-family ipv4 vrf vrf12 autonomous-system 406
      eigrp router-id 2.2.2.2
      network 192.168.12.0 0.0.0.3
~(後略)~

次にインターフェイスのIPを見てみます

892J#show run | begin interface

interface FastEthernet8.0.{$team_id}39
 encapsulation dot1Q 0.{$team_id}39
 ip vrf forwarding vrf12
 ip address 192.168.12.65 255.255.255.192
!
interface GigabitEthernet0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0.0.{$team_id}40
 encapsulation dot1Q 0.{$team_id}40
 ip vrf forwarding vrf12
 ip address 192.168.12.129 255.255.255.192

2つを抜き出して比較します

 network 192.168.12.0 0.0.0.3
 ip address 192.168.12.129 255.255.255.192

ネットワークアドレスとサブネット(ワイルドカードマスク)が一致していません。

動的においてはマスク値が一致していないと経路情報の交換が出来ず、
互いに隣接を結ぶことは出来ません。

まずはこの部分から書き換えます。
問題文の制約としてIPアドレス、サブネットマスクの変更を設けてあるので
変更するのはEIGRPの設定部分になります。

892j#conf t
892J(config)#router eigrp 406
892J(config-router)#no network 192.168.12.0 0.0.0.3 
892J(config-router)network 192.168.12.128 0.0.0.63

これでEIGRPの隣接問題が解消します。

しかし、まだこの状態ではLoopBackの経路情報が来ていません。

今回、この問題ではトポロジ図上ではこのようになっています。

BlackBoxは今回参加者の皆さんが触ることの出来ない装置になっています。
中ではVRFが稼働しています。このVRFを問題に関係する部分だけ抜き出してみると
下記のようなトポロジに変化します

LoopBackと892jの間はOSPFが動作しているのです。
今回参加者の一部から「二種類のルーティングプロトコルが動作しているがどちらが正しいのか?」
という質問を受けたことがありますがこの問題においてはどちらも動作するのが正常な動きとしています。

892jに入っているOSPFのコンフィグを見てみます。
(この問題に関係する部分だけを抜き出します)

892j#show run | begin ospf

router ospf 721 vrf vrf12
 router-id 2.2.2.2
 network 192.168.12.0 0.0.0.3 area 12

先程と同じくインターフェイスも見てみます。

892j#show run | begin interface 

interface FastEthernet8.0.{$team_id}39
 encapsulation dot1Q 0.{$team_id}39
 ip vrf forwarding vrf12
 ip address 192.168.12.65 255.255.255.192

比較します。

network 192.168.12.0 0.0.0.3 area 12
ip address 192.168.12.65 255.255.255.192

ここでも値が一致していません。
同じように修正を行います。

892j#conf t
892J(config)#router ospf 721 vrf vrf12
892J(config-router)#no network 192.168.12.0 0.0.0.3 area 12
892J(config-router)#network 192.168.12.64 0.0.0.63 area 12

これで値が一致します。
ですが、まだ隣接を結びません。

OSPFが隣接を結ぶ条件として大まかですが

  • IP、ワイルドカードマスクの一致。
  • hello-time,hold-timeの一致

となります。
BlackBoxの一部を抜き出すと設定には以下が投入されています。

!
!
interface fa 0/1.{$team_id}9
    ip vrf forwarding vrf12-ospf
    encapsulation dot1Q {$team_id}9
    ip address 192.168.12.126 255.255.255.192
    no shut
    ip ospf hello-interval 15
    exit
!
!

OSPFのHello-intervalはデフォルト設定で10秒になっています。
しかし今回の設定では15秒に設定しているのでこのままでは対向と設定が合いません。
設定を15秒に合わせなければなりませんがそもそもBlackBoxは設定も参照もできません。
では、15秒感覚で送信されていることを突き止めるのか。

892jで下記のコマンドを叩けば何秒で送信されているのか確認することが出来ます。

892j# debug ip ospf hello

これを叩いて数秒待つと対向からHelloパケットが送信されている様子を確認する事ができます。
今回は15秒ですのでおおよそ15秒感覚で受信をします。

確認したら設定を変更します。

892j#no debug all
892j#conf t
892j(config)#interface fa 8.139
892j(config-if)#ip ospf hello-interval 15
892j(config-if)#exit

これでやっとOSPFとEIGRP両方の設定が完了し隣接を結ぶことが出来ます。
ですが、この状態で疎通確認をしても疎通はできません。

今回、参加者側とLoopBack側ではルーティングプロトコルが使用されているため
境目となる892jでは特殊な設定が必要になってきます。

ここで使われるのがルート再配送と呼ばれるものです。

ルート再配送とは
http://www.infraexpert.com/study/routecontrol01.html

こちらを参考にするとわかりやすいかと思われます。

まずはOSPFから設定を加えます。

892j#conf t
892J(config)#router ospf 721 vrf vrf12 
892J(config-router)#Redistribute eigrp 406 subnets
892J(config-router)#exit

今回のOSPF再配送設定ではサブネット化されたネットワークをEIGRPにも含む形になるので
subnetsコマンドが必要になってきます。

上記を加えるとOSPFの設定は完了です。

同様にEIGRP側の設定も行います。

892j#conf t
892J(config)#router eigrp 406
892J(config-router)#Redistribute ospf 721 
892J(config-router)#default-metric 100000 100 255 1 1500
892J(config-router)#exit

先程とは違いコマンドが一行増えています。
EIGRPでは、OSPFで再配布されたネットワークはメトリック値がデフォルトで
∞(無限大)に設定されているので、メトリック値の値を適切にしなければ
到達不能のネットワークになってしまいます。
そのため、default-metricコマンドで値を詳細に設定する事により
値を適切なものに変更し、到達性のあるネットワークにします。

サブコマンドの意味は次の通りになっています。

892J(config-router)#default-metric <bandwidth> <delay> <reliability> <load> <MTU>

以上ですべての設定が完了です。

解答例

ちなみにですが、最後のに記載されてあるdefault-metric 100000 100 255 1 1500については
数値全指定なので運営へ質問をしなければ満点を獲得することが出来ない状況でした。

router ospf 721 vrf vrf12

    router-id 2.2.2.2
    network 192.168.12.64 0.0.0.63 area 12
    Redistribute eigrp 406 subnets
    default-metric 64 ←(なくてもOK。)
    exit
!
!
interface fa 8.{$team_id}9
    ip ospf hello-interval 15
    exit

!
!

router eigrp 406
  address-family ipv4 vrf vrf12 autonomous-system 406
    eigrp router-id 2.2.2.2
    network 192.168.12.128 0.0.0.63
    Redistribute ospf 721 
    default-metric 100000 100 255 1 1500 
    exit
  exit

採点基準(任意)

  • EIGRPのワイルドカードマスクが間違っているのを指摘&修正
  • OSPFのワイルドカードマスクが間違っていることを指摘&修正
  • OSPFのHELLOタイマーが隣接と一致していない事の指摘&修正
  • ルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値以外)
    • 指定の値以外を指定した場合は満点を与えない
  • ルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値)
    • 指定の値は運営に質問が来た場合に答えるものとする

講評(任意)

最後の方に出題されるライスボス問題でした。
2日目の午後付近で回答可能になった問題だった&問題が複雑過ぎた為か
回答できたチームはいませんでした。
個人的には意外と解いてくれるチームが出るのかな。と思っていたので少し残念な気分です。
とはいえ、私が参加者でもこの問題は意地悪すぎる部分が多いと感じるところもありますので
その辺は反省してます…。

この問題解説で参加者の皆さんが少しでも理解をしていただけたら
出題者としても嬉しい限りです。

 /

執筆担当: 新留

新留です。
HomeNOCと今回のコンテスト会場を接続する機材として、Juniper Networks(以下Juniper)様からお貸出しいただいたSRX1500を利用しました。
この機材では、Chassis Clusterでのクラスタ構成による冗長化やフルルートの受信と経路制御を行い、コンテスト参加者や運営、協賛とインターネットとの橋渡しを行っていました。

トポロジー図

ご満悦の表情でトラフィックを裁くSRX1500

Chassis Cluster

下流との接続と設定の簡略化、何よりロマンを求めて、今回はこの2台でChassis Clusterを構築し、Active-Activeとなるような構成にしました。
この構成のおかげで2つの機材の設定を1つのコンソール接続で管理でき、またルーティングテーブル・NAPTテーブルが同期されるため、とても便利でした。
Chassis Clusterを生かしてSRX1500と下流のQFX5100との接続をLAGで構築する予定もあったのですが、時間の都合で今回は達成することが叶いませんでした。

余談で、この設定はホットステージ開始前に行ったのですが、再起動必須なことを失念してリモートで設定投入 -> 再起動 -> 接続断 -> DCダッシュ ということをしてしまったのを今でも覚えています。

ルーティング

HomeNOCの説明でも軽く紹介した、大阪側から広告されたフルルートと東京側から広告されたデフォルトルートは、このSRX1500で受信していました。

HomeNOCから受けたIPv4 約69万経路 + IPv6 約5万経路をこの機材で収容し、ルーティングを行なっていました。
フルルートを受けている時の show bgp summary

受信経路の説明の図

また、SRX1500とその下流のQFX5100間ではOSPFで経路を広告していました。

内部経路の広報の図

SRX1500からはデフォルトルートを広告し、下流のQFX5100からはライフサーバー群、NAVT変換後のネットワーク、デバッグ用のチーム16(実際には存在しないチーム番号)を広告していました。OSPFでの経路数はトータルで30程度でした。

個人的に一番驚いたのが、ルーティングプロトコルでデフォルトルートを広告してくれるコマンドが存在しないことでした。
そのため、Juniperの公式HPにある情報などを頼りに以下の設定でデフォルトルートを広告しています。

set routing-options static route 0.0.0.0/0 discard
set routing-options static route 0.0.0.0/0 no-install
set routing-options static route 0.0.0.0/0 preference 200

set policy-options policy-statement bgp-redistribute term default from route-filter 0.0.0.0/0 exact
set policy-options policy-statement bgp-redistribute term default then accept

set protocols ospf export bgp-redistribute

この設定で、RIBに乗らない経路を作成し、その経路を広告するように設定しています。
Policy Statementの名前が bgp-redistribute なのは、BGPで流れてきたデフォルトルートを再広告する設定の名残です。
ちゃんと直さないとなあと思いながら本番が来てしまい、直せず仕舞いでした。

構築途中で「BGPで流れてきたデフォルトルートを再広告する設定」のミスにより、HomeNOCから来たフルルートをQFX5100にOSPFで再広告するという設定をしていました。
その結果、60万を超える経路を受信しようとしたQFX5100がハングアップし、その設定を行なった私は「うわあ・・・やっちまった・・・」とうなだれていました。

その直後にHomeNOCの山口様がこんなツイートを残していて、胸が痛くなりました。


十分勉強になりました、ありがとうございました。

ハングアップした原因としては、経路広告先であるQFX5100のIPv4の最大経路数が208,000経路であるにもかかわらず、69万もの経路を流してしまったため性能的に無理だったというものでした。
フルルートをOSPFで流した時の概要の図

また、事前の連絡ではデフォルトルートを大阪・東京双方から受信するという話で、そのため横着をしてBGPの経路をOSPFに広告する設定でデフォルトルートだけが広告されると想定し設定していました。
その設定途中でSRX1500にフルルートを流してみよう!ということになり、と同時にその時に再広告の設定を失念していた人的ミスのせいでQFX5100が一時応答不能になるというトラブルに発展しました。

やはり横着はよくない、eBGPで受けた経路をIGPに再広告するのではなく、きちんとDefault Gatewayを生成することが必要だとしっかり理解した瞬間でした。

このトラブル以外SRX1500でのトラブルはなく、とても安定して稼働してくれました。

コンテストを終えて

今回のコンテストでは、SRX1500で見た最大フロー数は7500程度、最大帯域は150Mbpsでした。
今回利用したネットワーク機材の中では通信量はそこまでないことがわかっていたのですが、フルルートが乗っているということもあり、私はCPU負荷やメモリ負荷といった部分を比較的注視して見ていました。
しかし、実際にコンテストが始まってからも多少の増減はありましたが特に詰まることなくパケットを処理している様子で、心配することはなかったなと思いながら見てました。
個人的な感想になりますが、Juniper機材を触ったことのなかった自分にとって新しい体験ができ、とても楽しく触らせていただきました。
機材提供をしていただいたJuniper Networks様、ありがとうございました。

 /

執筆担当: 新留

前回から引き続き、Home NOC Operators Group(以下HomeNOC)様よりインターネットへの接続をご提供いただきました。
その中で、トラコン初となる10G回線と対外接続2経路、フルルートをご提供いただき、大阪・東京の2拠点と接続して冗長化しました。

HomeNOC - SRX1500のトポロジー図

10G回線

本戦会場であるさくらインターネット株式会社様のDWDM装置を利用し、実際にHomeNOCの大阪DCと会場の間をダークファイバーを利用し、10GBase-LRにて直接接続しました。

光ファイバーを通る通信について、HomeNOCの山口様が記事にしているので、こちらにリンクを掲載させていただきます。

DWDM装置は知識のない人が触れるものではないため、HomeNOCの方に実際に現地で設定・調整を行っていただきました。

10GでHomeNOCと接続していますが、ホットステージ中は当初の想像よりもパフォーマンスが出ないことに気づきました。

その理由として、インターネット上でのルーティングが関わっています。
インターネットの世界は非常に大量のルーターが相互接続されており、また自組織のルーターから見たベストパスが他組織においてもベストパスとは限りません。

一般的な経路制御の方法として、ホットポテトルーティングというものがあります。
これは、経路が最も近い場所から広告されているピアに向かってパケットを投げる制御です。

HomeNOC 大阪DCからインターネットに出る通信は、HomeNOCのルーティングポリシーに従い、MEDやAS_PATHなどを見た上でベストパスを選択しルーティングします。
しかし、戻り経路はどこから来るのかは相手組織のルーティングポリシー次第であり、また相手組織から見たベストパス次第となります。

例えば東京のとあるサーバーに大阪からパケットを飛ばしたとします。
そのパケットがもし大阪から出たとして、帰って来るパケットは相手から見て最も近い場所から吸い込まれます。
非対称パスでの通信速度の解説の図
その結果、行きは早くても戻りパケットが回線速度の遅い場所を通り、そこがボトルネックとなり通信が遅くなります。

これを知らずにパフォーマンスの確認メールを送り、詳細を理解することができました。ありがとうございました。
その後、会期期間中はバックボーンが計11Gbpsの場所と接続されている大阪からできるだけパケットが流入するよう制御していただきました。
おかげでバックボーンネットワークに関してはとても快適に通信できていました。

後から聞いた話なのですが、eBGPでは大抵のASが/24より細かい経路を無視するように設定されているということで、ICTSCが利用するネットワーク(103.202.216.16/28)よりもずっと大きいネットワーク(103.202.216.0/24)を大阪優先になるよう経路広告を変更していただいていました。
本当にありがとうございました。

対外接続2経路・フルルート

今回のテーマである「冗長化」を達成するため、ダークファイバー回線が切断された場合のバックアップとしてHomeNOCの東京DCとEtherIPトンネルを利用した接続を行い、大阪との通信が途絶えた際に利用されるよう設定していました。
対外接続2経路化に伴い、HomeNOCからSRX1500へ到達するパケットの経路制御が必要になるため、SRX1500でBGPを利用した経路広告を行い、MED値を制御することで出来るだけ大阪から通信を吸い込むような制御を行いました。
その際の設定として、大阪からの経路広告はMED値100、東京からの経路広告はMED値200で広告していました。
MED値は低い方が優先されるので、この広告を行なった結果、トラフィックはMED値の小さい大阪の方から流れてくることが確認できました。

HomeNOC側からの経路広告としては大阪からフルルートを、東京からデフォルトルートの広告をいただきました。
実は当初はデフォルトルートのみを広告してもらう予定だったのですが、会場で設定中に100万経路を処理可能なSRX1500にフルルートを流してみよう!ということになり、実際に流したら安定して動作できたため、この設定をそのまま利用することになりました。
東京からフルルートを受け取ることについては、PPPoEの回線品質から見送りました。

その結果、こちらからのパケット送出についてはフルルートが受信できている(HomeNOCの大阪データセンターが生きている)場合は大阪からパケットが送出され、もし大阪DCとの回線がダウンした場合はバックアップとして利用することができるようになりました。

コンテストを終えて

コンテスト二日目の午前中にHomeNOCよりも上流の回線で障害が発生し、5000経路くらいが消失、さらに一時的に下り通信が東京から来ていた現場を目の当たりにするというとてもレアな経験ができました。
この原因は、HomeNOCがバックボーンとの接続で使用しているフレッツ網で発生した障害の影響だったそうです。

5000経路も消えた図

(しかしこの時にICTSC側で通信障害が起きていました・・・設定不足・・・:innocent:ご迷惑をおかけしました)

また、ホットステージ期間中に10G回線でエラーカウンタが回り続けている連絡を受け、光ファイバー清掃で対応するなども行いました。
他にもNTT東日本とNTT西日本のフレッツ回線における閉域網は直接接続できない等、大阪ということも相まって面白い体験ができました。

最近のコメント