/

問題文

我が社では事業拡大に向けて、これまで別々に活躍していた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日目の午後付近で回答可能になった問題だった&問題が複雑過ぎた為か
回答できたチームはいませんでした。
個人的には意外と解いてくれるチームが出るのかな。と思っていたので少し残念な気分です。
とはいえ、私が参加者でもこの問題は意地悪すぎる部分が多いと感じるところもありますので
その辺は反省してます…。

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

 /
カテゴリー

こんにちは、ICTSC9 問題リーダーの金澤です。参加者の皆さん、コンテストお疲れ様でした。

ICTSC9 で出題された各問題の解答と解説記事を公開しました。ここに、各問題の記事へのリンクをまとめます。コンテスト本番から1ヶ月ほどと、大変遅くなってしまって申し訳ありません。

※ 2018/04/02 現在、解説が未公開の問題があります。申し訳ありませんが、今しばらくお待ちください。

ICTSC9 参加者の方は復習に、次回以降参加するつもりの方は予習に役立ててください!

続きを読む

 /

 

問題文

社内Networkの定期メンテナンス以降、Router(c1941)に対してVPN接続が出来なくなったため管轄である経路安定課に派遣されることとなった。

この部署では、定期メンテナンス以前からも他部署からVPNに接続すると、外部へのアクセスが出来なくなるとの苦情が寄せられているらしい。

今回のトラブルと同時にこちらのトラブルも含めて原因を特定し修正してほしい。

トラブルシュートするにあたり、configの修正点と修正したコマンドも合わせて報告し、部署内で情報共有できるよう努めてほしい。

トラブルの概要

  • VPNの設定ミスでVPNに接続できない
  • Cisco機器のVPN用仮想IFにNATの設定をしていない為、外部接続が出来ない

 

解説

この問題は社外から社内にVPNに接続する際のトラブルについての問題です。

問題文の「VPN」のキーワードを元にconfigを注視するとL2TP over IPSecを使用していることがわかります。

今回のこの問題でVPNが繋がらないトラブルに関しては原因が2つあります。

1つ目は、VPNの仮想IFを識別する為のIF番号が、VPNを使用する設定で定義したIF番号と異なっていることです。

2つ目は、VPNの接続を受け付ける為の設定[crypto map]がIFに適応されていないことです。

この2つの原因を発見し修正する事でVPNに繋がらないトラブルを解決できます。

VPNに接続するとWEB(外部Network)に接続できなくなるトラブルに関しては、VPNに接続する際に使用する仮想IFにNATの設定(ip nat inside)を設定していないことが原因となっています。

このトラブルを修正すると、3点のトラブルの原因をすべて修正したことになり、この問題のゴールであるVPNに接続した状態でのWEB(外部Network)接続が出来るようになります。

 

解答例

vpdn-group L2TP

accept-dialin
virtual-template 15

interface gigabitEthernet [参加者手元アクセス用 IF]
crypto map CRYPTO_MAP_L2TP

interface Virtual-Template15
ip nat inside

採点基準

  • VPNへの接続成功
  • 外部サイト(google,yahoo等)への接続成功
 /

問題文

Topology.png

我社では、社内で上記のトポロジーでマルチホーム接続を実施している。
だが、通信状況が良くないと社員から苦情がきたため、回線断の状況などを調べる目的で、新しく通信監視のサービスを自社に導入することが決定し、監視サービス提供事業者に依頼した。
監視サービス提供事業者の仕様としては以下の通りである。

最初にテストの設定をしてもらったが、内部からの通信の疎通は問題なく出来るにもかかわらず、一部のIPでは疎通が取れずにアラートが上がりっぱなしになるという現象が発生した。
その原因を突き止めてほしい :pray: 。

当該ISPとの通信ではuRPFが設定されており、また両方で利用されているネットワーク帯は異なる。
当社に存在する ネットワーク帯 は以下の通りである。

このうち、192.168.2.128/30192.168.2.132/30 はISPとの接続用でISPより提供されたIPであり、この組織が利用できるIP帯は 192.168.2.136/29 である。
ISP内ではISPではuRPF Loose modeと団体ごとの接続に利用しているBGPプロトコルでの経路フィルタが設定されている。

また、自社のコンピュータは192.168.2.0/25をNAPTを利用して接続している。

この問題では、当社が保有するCoreルータ以外の設定変更は不可能である。
また、広報する経路の設定は変更してはならない。

監視用サーバーはISP-A・ISP-B双方から疎通が可能であり、またISP・CORE間はBGPにて動的ルーティングが行われている。監視用サーバーのIPは現地店では開示されていない。
監視用サーバーの監視結果やその他必要な情報については問い合わせることで確認することが可能である。

注意

この問題は「外部から疎通ができない」というものであり、
内部からの疎通は全て成功する状態が正常である。
また、この問題のネットワークは他の問題のネットワーク、無線LANとの疎通性とインターネットへの対外疎通は存在しない。そのため、当問題のセグメント(192.168.2.0/24)以外には疎通不可能な状態が正常である。

制約

上流ルータ等、当該ルータ以外の設定変更はしてはならない。
BGPで広報する経路の設定は変更してはならない。
NATの変換IPを変更してはならない。
使用するネットワーク帯を変更してはならない。
クライアント側ネットワークを1つに集約してはならない。
この問題ではVRFを使用していないため、VRFを利用するネットワークを変更してはならない。

スタート

上記のように設定されたネットワーク帯とページ最上部に置かれたトポロジーで、インターフェイスにつけられたIPアドレスへの疎通が取れない
この設問では、サーバーはCore Loopbackに接続されているものとする

ゴール

Core Loopback、 ISP-A – Core、 ISP-B – Core のネットワークに所属していて実際にインターフェイスに割り当てがされている全てのIPとICMPによる疎通が外部から取れるようになる。
(Pingコマンドで疎通が確認できる)

情報

接続できるルータの情報は以下の通りである。

サブインターフェイスの数値に付与されているxはチームIDである。
例えばチームIDが30かつISP-A側インターフェイスの名前は GigabitEthernet 0.3010 となる。

トラブルの解説

この問題は、一部のインターネットサービスプロバイダー等で利用されるセキュリティ確保の方法の一つであるuRPF (Unicast Reverse Path Forwarding)に関する問題でした。

本来は自組織・相手組織を接続するネットワークは通信に使うためのものではないのですが、今回はそのIPに対して疎通確認を行なっており、どちらの回線が断絶したかを確認できるようにするという意図で問題が展開されていました。

uRPFとは
http://www.infraexpert.com/study/aclz22.html
このURLを見ていただくと理解ができるでしょう。

IPルーティングを行うルーターでは、パケット送出時にルーティングテーブルを確認します。

今回正常に接続ができていたLoopback IPへのパケットの送出手順は以下の通りとなります。

Topology.png

Coreルータのルーティングテーブル

ISP-Aルータのルーティングテーブル

ISP-Bルータのルーティングテーブル

Untitled Diagram (7).png
上記の図では行きと帰りの経路が異なる様に記述していますが、今回の場合はどちらのISPからパケットが来ても、どちらのISPに返しても正常な動作です。

これは、この組織が割り当てを受けている/29のIPを双方のルータから経路広告しているため、また割り当てられているIPのため経路フィルタをされることなく当該IPに対するアクセスが全て許可されるためです。

今回正常に接続ができなかったISP側インターフェイスへのパケットフローは以下の通りとなります。

Topology.png

Coreルータのルーティングテーブル

ISP-Aルータのルーティングテーブル

ISP-Bルータのルーティングテーブル

Untitled Diagram (8).png

当該ルータのルーティングテーブルをみて、デフォルトルートが向いている方のISPからISP-Coreのつなぎのインターフェイスには、発信パケットが同じISPを通るため正常にICMPパケットの返答が帰って来ます。

しかし、デフォルトルートが向いていない側のISPから着信した場合、そのパケットの送信元IPは通信が許可されていないが向いていない側のISPであるにもかかわらずデフォルトルートが向いている方のISPにパケットが送信されます。

CoreルータでICMPパケットが処理された後に、そのパケットの送出処理の際の出力インターフェイスはルーティングテーブルを参照した結果によるものであるからです。

今回は双方のISPで送信元IPがルーティングテーブルに乗っているかどうかを判断しパケットを送信するuRPFとBGPでの経路フィルタが設定されているため、デフォルトルートが向いていない側のISP側の送信元IPでデフォルトルートが向いている方のISPにパケットが送信された場合、ISP側ルータでパケットが破棄されます。

それにより、Ping疎通が不可能となっていました。

また、問題文として「経路フィルタを行なっている」ことから、CoreルータとISPを接続する線を経路広告しても疎通を取ることはできませんでした。

回答例

access-list 21 permit 192.168.2.128 0.0.0.3
access-list 22 permit 192.168.2.132 0.0.0.3

route-map REPLY-ISP permit 10
 match ip address 21
 set ip next-hop 192.168.2.129

route-map REPLY-ISP permit 20
 match ip address 22
 set ip next-hop 192.168.2.133

ip local policy route-map REPLY-ISP

パケット送信元のIPをベースに、ネクストホップ(パケット送信先インターフェイス)を変更することでこのトラブルの回避が可能になります。

採点基準

パケットが本来出力されるべきインターフェイスから出力されていないことを指摘できる(10%)
ルーティングポリシーの設定を追加する(80%)
設定を保存する(10%)

講評

問題の点数が高かったことと、問題名から滲み出る頭おかしい臭、また出題形式の都合で前の問題でブロックされていたことにより出題時間が短かったことによって、解答もチェック依頼も0件でした。問題内容くらいはちょろっと見てくれてたら良いなあと思いつつ、この解説を読んで「あー!なるほど!」ってなってくれる人がいると良いなと思っています。
この問題を見て「😔」してた人もいたのかな、相当意地悪な作りにしたのは申し訳ない限りです。

今回の問題で出題したuRPFについては、BCP38(Best Current Practice 38)で提唱されている、ISPレベルでの不正な通信(送信元IPなりすまし)のブロックにも用いられる技術で、最近のISPでも採用例が増えてきている技術です。「繋ぐ」技術だけではなく「繋がせない」技術にも目を向けてもらえればいいなと思い出題しました。

何はともあれありがとうございました、次回も運営をしていれば、もっと簡単な問題で会いましょう。

(追加補足) バックボーンの裏話

実はuRPFなんて大層なことを言っていますが、今回の問題環境で行なっていることは「BGP経路フィルタ」・「ACLによるアクセス制御」のみでした。ルーティングテーブルを参照する方法がうまく行かなかったため、同じ制御が行われた想定で通信を制御していました。
また、ブラフとしてLANを2つ用意したり、敢えてルーティングにBGPを利用、NAPTの必須化などで「Configを読むだけでは何を聞きたいかわからなくする」様な戦略を取り、また疎通のチェックをチーム内で行うことはできなくする、ISP側設定は聞くことができない等で参加者のみなさま、また運営の祭典担当の方々に大変なお手間をおかけする様な問題にしました。

 /

資料

 

問題文

社内インフラ管理をする部署に所属しているエンジニアがRouter(c1941)のメンテナンスをしていると潜在的なトラブルを発見した。

アクセスが出来なければいけない宛先[192.168.25.254]にRouterから疎通確認(ping)が出来ない。
しかし他部署からの苦情は寄せられておらず、PCをSwitch(2960B)に接続して確認してみると正常に疎通確認が出来ている。

現状は大きな問題にはなってはいないが、潜在的なトラブルを放置しては置けない。

だが、この潜在的なトラブルを発見したエンジニアは「明日から有給とるから後はよろしく!!」と言って退社してしまった。

そこで諸君にはこの潜在的なトラブルを修正しトラブルの原因と解決方法を報告して欲しい。

トラブルの概要

  • CBACの設定ミスによりRouterからの指定された宛先への疎通確認(ping)が出来ない。

解説

この問題はRouterにACL(deny any any)とCBACを使用してセキュリティの設定をした場合のトラブルです。

通常はクライアントが宛先となるIPに疎通確認(ping)が成功する場合は、それを中継しているRouterからも宛先に疎通確認(ping)が出来ます。

しかし今回はCBACの「Routerから発信するtrafficを無視する」という特性が働き、参加者のPCからの疎通確認(ping)の戻りのtrafficはCBACによって許可されますが、Router発信のtrafficが無視される為、Router発信の疎通確認(ping)の戻りのtrafficが許可されません。

この特性への対策としてCBACのコマンドのオプションに[router-traffic]を使用します。

このオプションを使用するとCBACがRouter発信のtrafficを無視しなくなり、Router発信の疎通確認(ping)に対しての戻りのtrafficが許可され疎通が出来るようになります。

解答例

ip inspect name ip-ipcp icmp router-traffic timeout 5

採点基準

  • Routerから指定された宛先への疎通確認成功
    ※想定回答(CBAC)以外の回答(ACLの編集)等での条件達成は+10点
 /

問題文

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

トラブルの概要

この問題は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 アドレス アカウント パスワード
vyos 192.168.20.80 admin PxZsMqycN4a4nzlk1Xg7
client 192.168.20.2 admin kopvVL3cT2tkALu4nQnD

トラブルの概要

この問題では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は一回も触ったことがありませんでした。だそうにも難しくすることができないので実際に自分がミスしたところを出せばいいのではと思い出題しました。

最近のコメント