/

問題文

仮想機密伝送路課では、ルータの検証中に疎通が取れないトラブルにぶつかっており、現在在室している社員では解決できないらしい。
代わりにこの問題を解決し、社員に対して説明してほしい。
ただし、疎通先のルータは他部署が管理しているものであり設定を書き換えることができない。

トラブルの概要

この問題はciscoルータをブロードバンドルータとして使えるように設定する際に問題が発生したという設定であった。
configを読み解くと、一般的なISPで使用されるPPPoEを使用してWAN側のIPアドレスを取得し、ローカル側にはプライベートIPアドレスをDHCPで配布してNAPTを行うことで割り当てられた一つのアドレスでWAN側へ接続していることがわかる。

解説

この問題の場合PPPoEを利用しているため、NAPTのWAN側インターフェースはdialerであるのに対し、NATのoutsideが物理配線のインターフェースに設定されていた。
この個所を特定し、正しいconfigに書き換えることでISP側に設定したIPアドレスに対し疎通が取れるようになっていた。

解答例

ip nat inside source list 11 interface dialer 11 vrf vrf11 overload
interface Dialer 11
ip nat outside
exit
ip route vrf vrf11 0.0.0.0 0.0.0.0 dialer 11 permanent

採点基準

この問題は以下のポイントを押さえていれば部分点が与えられるようになっていた。

  • NAPTが原因であることを指摘できているかどうか
  • 正しく設定を変更しPCから指定のアドレスにpingで疎通を確認できる

講評

この問題を解くためには、参加者はPPPoEやNATに関する知識が必要な問題であった。
参加者の中には何度も関係のない解答を送ってきたチームもあったが、落ち着いて問題を切り分けることでより問題に気付きやすくなるだろう。
また、今回のコンテストで初めてPPPoEを知った参加者がいるのであれば、少し複雑ではあるが一般的な家庭とISPの間で接続を確立する手段としてよく利用されるプロトコルであるため、これを機に理解を深めるのもいいだろう。
本問題はコンテスト向けに一部の設定を省略しているため、本問題の状態で運用するとセキュリティ面などに問題がある。
そのため、実際に家庭に導入する際は正しくDNSやACLを設定しなければならない。

 /

問題文

この部署ではAS番号を持たない組織に対して、プロバイダのルータと組織内のルータの間に境界ルータを設置し、プロバイダのルータと境界ルータの間で双方向にStatic Routeを書くことで対応している。
ある組織は複数のIPアドレス(192.168.23.0/24)を持っており、組織内では独自でルーティングしている。
組織内では、割り当てられた中で使ってないIPアドレスがあり、その箇所に対しpingを行うと余計な帯域を食われてしまう問題が発生しているという苦情が届いた。
この問題に対して組織側のネットワークに影響が出ないようこの問題を解決し、原因を報告してほしい。

トラブルの概要

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。

解説

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。
この場合、未使用アドレス帯にパケットを投げた場合、組織内では、自身のルーティングテーブルに情報が乗っていないため、Default Routeである境界ルータに転送する。
境界ルータはStaticRouteより、プロバイダのルータにパケットを送るが、プロバイダは組織内のIPアドレスであると判断し境界ルータにパケットを送る。その結果、境界ルータとプロバイダのルータ間でループが発生しパケットのTTL倍の帯域を無駄に消費していた。
この問題を解決するためにはパケットを破棄するNullInterfaceを設定しNullRoutingの設定を行う必要があった。

解答例(一例)

ip route 192.168.23.128 255.255.255.128 Null 0

講評

この問題はPCからpingを実行した際のエラー文からループが発生していることを見抜けるかどうかを問う問題であった。
解答方法はチームごとに異なり、Nullを使用していない場合でも現状のネットワークに支障の出ないACLを書いているチームにも等しく点数を与えていた。
しかし、ACLを使用する場合既に書かれてある場合もあり導入が困難なケースや、設定次第で新たなトラブルの原因になりやすいため扱いには十分注意が必要である。
参加者の中にはdenyが一行書かれたACLを解答として送ってきたチームもあった。これでは全てのパケットが対外に出ることができなくなるため、暗黙のdenyに関する知識やaccess-listに関する理解を深める必要がある。
ルーティングプロトコルが集約されるときには常に、集約内のすべての IPアドレスに対するトラフィックをルータが受信する可能性がある。
しかし、すべてのIPアドレスが常に使用されているわけではないので、集約対象のトラフィックを受信するルータでデフォルトルートが使用されている場合にはパケットがループする危険性があるので注意する必要がある。

 /

問題文

我社では、新しい部署の開設に伴い新たなネットワークレンジを割り当てることになった。

担当者はメールで渡された情報に従ってコンフィグを作成し、新しく導入した機材に流し込んだ。
しかし、いざ設定してみると他部署のネットワークとの疎通が取れないことが分かった。
各担当者に問い合わせたが原因は特定できなかったという。

そこで、この問題を解決し、原因およびその根拠、また修正したコンフィグを報告してほしい。

担当者に送られたメール:

件名: ○○部署開設に伴うネットワーク情報まとめ

本文:
お疲れ様です。
○○部署で使うネットワーク情報についてのまとめです。
192.168.38.0/24、デフォゲは192.168.38.1
ipv6アドレスの割り当てなし。

新しく使うアドレス
192.168.39.0/24
ipv6アドレスの割り当てなし。

新しく導入した機材で192.168.38.39を介して192.168.39.0/24を接続し、RIPで社内LAN向けに経路情報を投げてください。

制約・情報

routerAの192.168.39.0/24のネットワークにPCを接続して192.168.37.1にPingが飛ぶように設定を修正してください。

PCは、2960Bのfa0/1に接続してください。

routerAは1941です、routerBは操作できません。
enable password : ZWKKEFzV

この問題に関係のあるIP及びvrfは192.168.37.0/24,192.168.38.0/24,192.168.39.0/24,vrf05です。それを除く他のIP,vrfは当問題とは関係ありません。

回答していただく項目は以下の通りです。

  • トラブルの原因とその根拠(使用したツールやコマンド等も明記して)
  • 修正したコンフィグ

問題のスタート

192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ばない

問題のゴール

問題を解決し、192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ぶように設定を修正する。

トラブルの概要

RIPのバージョン指定を忘れたときに経路情報は見えてるのにPCからPingが飛ばなくなる

解説

routerAではripのバージョンを指定せず、routerBのみripにversion2を指定した。

ciscoルーターの場合ripのバージョンを指定しなければversion1で動作するが、version2の経路情報も受け取るため、routerAでは192.168.37.0/24を受け取ることができる。しかしrouterBはversion2で固定しているため、version1の経路情報を受け取らない。

そのため、routerBには192.168.39.0/24が伝わらないため疎通が取れなくなる。

この問題はルーター2台のコンフィグを見比べて問題を特定することができない為、流れているパケットを読む(debugなど)必要がある。

routerAでdebug ip ripコマンドで自分はversion1をsend、相手からはversion2をreceiveしていることが分かる

手元のRIPのバージョンを2に変更すると正しく疎通できるようになる。

回答例

1941でdebug ip rip コマンドを使用したところ、手元がRIPv1、対向がRIPv2を使っていることが分かりました。

そこで
router rip
address-family ipv4 vrf vrf05
version 2
と入力したところ、PCから正しくPingが飛ぶことを確認しました。

最低限これだけの情報が書かれていたらOKです。

 /

どうも、作問者のnasuと言います。

問題文

今回ある学校のL2部分をalaxala製のL2SWで構築することになった。
そして回線障害、機器障害が起きても通信を問題なく行えるように、alaxalaの独自プロトコル(リングプロトコル、GSRP)で冗長化をする。
しかし検証環境で設定を入れて、ALA-CとALA-Bを繋いでいるケーブルの障害試験を行なった際に、正常に切り替わることができず検証用のホスト(192.168.19.200/26)へ一切疎通が取れなくなってしまった。
またコンソールにはたくさんのログが流れており、状況がつかめずにいる。
あなたは疎通が取れない原因の報告と、そして障害が起きた状態で疎通が出来るように対処をしてもらいたい。

制約

  • ALA-B,ALA-C,2960-B間は必ずgsrpを使った冗長設定、またALA-A,ALA-B,ALA-Cはリングプロトコルを使った冗長設定にしてください。プロトコルを使わないという解答は点数になりません。

トラブルの概要

  • 両方のスイッチのgsrpにno-neighbor-to-master direct-downと設定が入っている為、障害時に両方のスイッチがお互いに障害が発生したと判断してパケットが両方のスイッチでフォワードされるようになり無限ループする構成となってしまった
  • リングプロトコルのhealth-checkの値が間違っている

解説

ALA-B,ALA-Cでつながっているインターフェースはgsrp-directlinkになっており、gsrpの切り替えがno-neighbor-to-master direct-downと設定されている為、障害時お互いがお互いに障害が起きたと判断して2台ともマスター状態で動いているためブロードキャストストームが起きた為パケットが正常に飛ばなくなるということです。
またringプロトコルのヘルスチェックの送信間隔時間及び保護時間が間違っている為

解答例

ALA-B,ALA-Cをどちらかのgsrpの設定をno-neighbor-to-master direct-downと設定しgsrpをリスタートさせることで片方がバックアップとなりパケットを流さなくなります。
これによってpingが正常に飛ぶようになります。
ALA-B or ALA-C

ena
conf t
gsrp 1
no-neighbor-to-master manual
exit
exit
restart gsrp

またリングプロトコルのヘルスチェックの値に不備がある為これもパケットがおかしくなるという言及、及び設定変更
ALA-A

enable
conf ter
axrp 1
health-check interval 500
health-check holdtime 1600

採点基準

pingが届くだけならgsrpの設定のみで済むので以下の配点となっています
1. gsrpの挙動への言及とgsrpの設定変更をしpingが正常に飛ぶ → 基準点
2. gsrpの解答をした上でaxrpのヘルスチェックの値に不備があることへの言及及び設定変更 → 満点

講評

先に講評から
15チーム中5チームからの解答があり4チームが基準点を突破しそのうち1チームが満点でした。
また満点のチームは外部のドキュメントを引用して何が起きているかの言及、また設定変更の手順を1つずつ丁寧に説明せれており芸術点も追加されています。
さて学生のみなさんはRS232cを使うネットワーク機器を扱ったことはありますでしょうか?
初めて見る学生さんは「なんだこのコンソールポートの口は?」と驚いたかもしれません
最近では比較的rj45を使う機器しか見ないと思いますが、ベンダーによってはちらちらと出しているところを私は見ます。
世間のネットワーク機器はcisco以外にもあらゆるベンダーで構成されています。
そして一度も触ったことがないのに突如上司から「ネットにドキュメントがあるから読んでやって」というのも大人の世界ではあるかもしれません(私のバイト先ではありました。)
今回出したalalaxaはコマンド体系がシスコライクなので学生でもcisco機器を勉強していれば、そこまで扱うのにはそこまで難しくないと思われます。
今回cisco以外の機器を触って「あ、おもしろいな」って思った学生のみなさんはこれを機にあらゆるのベンダーのネットワーク機器に触れてみるのもいいかもしれません。
次回も”出来ればですが”cisco以外のネットワーク機器を使った問題を作ってみたいと考えていますので楽しみにしてください。(確実に出るという保証は無いorz)

問題文

社内にVyOSを導入することが決まった。
そこで、社内のインフラを構築する前に以下の図の様なテスト環境で検証を行った。
VyOSにDNSのキャッシュサーバとDHCPサーバを起動し、下に接続されているUbuntuにIPアドレスを割り当てた。
しかし、Ubuntuから外部のサーバにアクセスしようとしたが接続できずICMPを送っても応答がない。ところが、VyOSからICMPを外部のサーバに送ると応答が返ってくる。
なので、Ubuntuから外にアクセスできる様に解決してほしい。ただし、Ubuntuに直接接続することはできず、VyOSからはアクセスできるようになっている。

スタート

  • Ubuntuから外部のサーバにアクセスできない
  • VyOSからはアクセスが可能

ゴール

  • Ubuntuから外部にアクセスできる

情報

サーバIP アドレスアカウントパスワード
vyos192.168.20.80adminPxZsMqycN4a4nzlk1Xg7
client192.168.20.2adminkopvVL3cT2tkALu4nQnD

トラブルの概要

この問題ではVyOSがNATをして下に接続されているUbuntu Server(以下clientとする)が外とアクセスできるような構成になっていました。しかし、何らかトラブルでclientが外と全く疎通が取れない状態でした。VyOSから8.8.8.8にpingをすると応答が帰ってくるという状態でした。

解説

問題文を読んだだけで大抵の人はVyOS側に問題があることに気づいたかと思われます。答えはVyOSのNATの設定に不備がありclientが外に繋げられなかったということです。

解答例

NATの設定を確認するためにshow natを打つと以下のように表示されます。

nat {
source {
rule 1 {
outbound-interface eth1
source {
address 192.168.20.0/26
}
translation {
address masquerade
}
}
}
}

今回の場合、VyOSが対外に接続しているインターフェースはeth0なのにoutbound-interface eth1となっています。これが原因な訳でこれを消すか上書きしてあげることで疎通が取れるようになるはずです。以下のような手順で上書きをしてみます。

# set nat source rule 1 outbound-interface eth0
# commit
# save

この後に8.8.8.8に対してpingをすると以下のように接続できていることがわかります。

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=12.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=10.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=9.57 ms

採点基準

  • 外部に疎通できないことを指摘
  • 解決方法の提示
  • そのあとに疎通できることを提示

講評

この問題はウォームアップ問題として作成しました。なのでほとんどのチームが解答してくれました。実はVyOSは一回も触ったことがありませんでした。だそうにも難しくすることができないので実際に自分がミスしたところを出せばいいのではと思い出題しました。