JANOG50 NETCON問題解説 Level1-4, Level1-6

はじめに

JANOG50 NETCONにご参加いただいた皆様ありがとうございました。
本記事ではJANOG50 NETCON にて出題した「Level1-4」、及び「Level1-6」について解説します。

Level1-4について

問題概要

問題文と構成図を以下に記載します。

新入社員のA君はセキュリティに関する勉強をし始めた。
手始めに、Cisco iOSACLについて勉強するつもりで上記の構成で設定を実施した。
ただ、うまくCisco iOS側にpingが届かないようだ。
下記IPアドレスに対してVPCからpingが到達できるようにA君を助けてあげてほしい。
1. 192.168.0.254
2. 192.168.10.1

Level1-4構成図


この問題では下記3点について誤りがありました。

  1. vIOSのACLが誤っていること
  2. vIOSにloopback0が存在しない(指定のIPアドレスを有さない)こと
  3. VPCデフォルトゲートウェイが設定されていないこと

Level1-4では、合計30点の問題でした。
採点基準は以下となります。
15点条件: 上記「1.」を修正し、「192.168.0.254 への疎通確認」ができること
満点条件: 15点条件に加え、残り全てを修正し、「192.168.10.1 への疎通確認」ができること

問題解決手順

  1. 15点条件について
    問題開始時点のvIOSのConfigについて以下に抜粋します。
access-list 1 permit 192.168.0.0 255.255.255.0
int gigabitEthernet 0/0
ip address 192.168.0.254 255.255.255.0
ip access-group 1 in

access-listではワイルドカードマスクと呼ばれるものを使用します。
しかし、現在設定されているワイルドカードマスクはサブネットマスクと同じ形で記載されているため、正常に通信できない状態となっていました。
従って、permit 192.168.0.0 0.0.0.255 が正しいaccess-listとなります。

access-listの設定について特に指定は設けていませんでしたので、以下の解法が想定されました。
①既存access-listを削除し、新たに作成
②新しいaccess-listを作成して適用

最後に解決条件である 192.168.0.254 への疎通確認を行います。

VPCS> ping 192.168.0.254
 
84 bytes from 192.168.0.254 icmp_seq=1 ttl=255 time=2.678 ms
84 bytes from 192.168.0.254 icmp_seq=2 ttl=255 time=1.940 ms
  1. 満点条件(15点条件差分)について
    ⅰ. loopback 0の設定追加
    改めてvIOSのConfigについて確認します。
access-list 1 permit 192.168.0.0 0.0.0.255
int gigabitEthernet 0/0
ip address 192.168.0.254 255.255.255.0
ip access-group 1 in

Configとトポロジー図を見比べると「loopback 0」の設定がありませんので、トポロジー図に記載がある設定を投入します。

int loopback 0
ip address 192.168.10.1 255.255.255.0

ⅱ. VPCデフォルトゲートウェイを設定
ⅰを実施した状態で、VPCからpingを送ってもping疎通に失敗します。
次はVPCの設定状態を確認します。

ip 192.168.0.1
上記から、ipアドレスのみ記載されていることが分かりました。
loopback0である「192.168.10.1」に対し、疎通性がある状態にするにはデフォルトゲートウェイが必要なため、設定します。
ip 192.168.0.1/24 192.168.0.254

上記2点を実施した後、改めて「192.168.10.1」に疎通確認を行います。

VPCS> ping 192.168.10.1
 
84 bytes from 192.168.10.1 icmp_seq=1 ttl=255 time=2.633 ms
84 bytes from 192.168.10.1 icmp_seq=2 ttl=255 time=1.936 ms

Level1-6について

問題概要

問題文と構成図を以下に記載します。

検証環境を新入社員に自由に使って良いと伝え、Config変更を行ったみたいだ。
ただ、触れてはいけない機器まで触ってしまい、通信が通らなくなってしまった。
さらに、新入社員は頑張って復旧させようと各機器で手当たり次第にcommitをしてしまったらしい。
元の設定はわからないが、前の設定に戻して、正常にVyOS - XRv間でping通信が届くようにしてほしい。
どうやら、正しいcommitにはメモが書いてあるらしい。

Level1-6_構成図

この問題ではrollbackコマンドを用いて、意図したConfig設定に変更してもらう問題でした。
正解時のIPアドレス等は以下構成図の通りです。

Level1-6_rollback後-構成図

Level1-6は、合計50点の問題でした。
採点基準は以下となります。
25点条件: VyOSで「ping 172.24.10.254」によりXRvに到達できること
満点条件: 25点条件に加え、XRvで「ping 172.24.0.1」によりVyOSに到達できること

問題解決手順

1.各機器のcommit状態の確認
以下、各機器のcommit状態を確認します。

  • VyOS
janoger@vyos> show system commit
0   2022-07-04 14:54:46 by root via vyos-boot-config-loader
1   2022-07-04 14:53:07 by janoger via cli
    init
2   2022-07-04 14:51:43 by janoger via cli
    ans
3   2022-07-04 14:45:20 by root via vyos-boot-config-loader
4   2022-04-23 17:40:14 by janoger via cli
5   2022-04-23 17:39:27 by vyos via cli
6   2022-04-23 17:37:39 by root via vyos-boot-config-loader
7   2022-04-23 17:37:38 by root via init
  • vSRX
janoger> show system commit
0   2022-07-04 11:16:09 UTC by root via cli
    init
1   2022-07-04 11:11:05 UTC by root via cli
    ans
2   2022-07-04 10:45:47 UTC by root via other
  • XRv
RP/0/0/CPU0:ios#show configuration commit list detail
Wed Jul 13 07:54:19.819 UTC
 
   1) CommitId: 1000000003                 Label: NONE
      UserId:   janoger                    Line:  con0_0_CPU0
      Client:   CLI                        Time:  Mon Jul  4 14:11:50 2022
      Comment:  NONE
 
   2) CommitId: 1000000002                 Label: NONE
      UserId:   janoger                    Line:  con0_0_CPU0
      Client:   CLI                        Time:  Mon Jul  4 14:11:19 2022
      Comment:   ans
 
   3) CommitId: 1000000001                 Label: NONE
      UserId:   janoger                    Line:  con0_0_CPU0
      Client:   CLI                        Time:  Mon Jul  4 14:10:37 2022
      Comment:  NONE

以下の記載がありました。

どうやら、正しいcommitにはメモが書いてあるらしい。

この文章から考えると、下記が答えとなるcommit内容であることが分かります。

  • VyOS: 「1」もしくは「2」
  • vSRX: 「0」もしくは「1」
  • XRv: 「2」

ここで、XRvのコメントを確認するとansと記載されています。
同様にVyOS,vSRXにもansという記載がありますので、XRvに合わせる形で以下のcommit内容にrollbackしていくことにします。

  • VyOS: 「2」
  • vSRX: 「1」
  • XRv: 「2」

2.各機器のrollbackについて
各機器のrollback方法を記載します。

  • VyOS
janoger@vyos# rollback 2
Proceed with reboot? [confirm]
  • vSRX
janoger# rollback 1
load complete
  • XRv
RP/0/0/CPU0:ios#rollback configuration 1000000003

XRvのrollbackでは、本来直近のコミットを実行する前に存在していたコンフィギュレーションロールバックします。
今回はlevel-1の問題ということで、コメントが記載されている「1000000002」のrollbackでも正解となるように設定しました。

3.確認
正常にrollbackできるとVyOSからXRv間が疎通可能になります。

さいごに

いかがだったでしょうか?

Level1-4は、access-listの書き方や戻りのトラフィックが返ってこれるか、について出題しました。
access-listの書き方は"?"コマンドでConfigで記載する内容を確認すれば、自然と点数がもらえるようにしました。
戻りのトラフィックについては、理由はわかったものの、VPCの設定に少し苦労された方もいらっしゃるかな、と想像しています。

Level1-6は、rollbackコマンドの使い方やcommitログの確認について出題しました。
各機器で確認する階層やコマンドが違う点を理解を深めていただけたら幸いです。
実は問題は難易度調整の観点から、ヒントや複数回答の用意など細かい工夫が苦労した点です。。

Level1-6は実際の職場で発生すると大きな問題になります。
対策としては以下が挙げられます。
1.commit コマンドにcomfirmedオプションを記載
- 指定の時間内にcommitがなかった場合、自動で設定の切り戻しが行われます。
- 例. XRv: commit confirmed 60, vSRX:commit comfirmed 1

2.commitする内容が意図したConfigであることを確認
- 現状のConfigとの差分を取るために、compareやdiffを取ります。
- 例. XRv: "show commit changes diff", vSRX: "show |compare"

上記を参考にしていただき安全にcommitしていただければ、と思います。