JANOG53 NETCON問題解説 チュートリアル4, Level1-3, Level1-4

はじめに

JANOG53 NETCONにご参加いただいた皆様ありがとうございました。
本記事ではJANOG53 NETCON にて出題した「チュートリアル 4」、「Level1-3」、及び「Level1-4」について解説します。

チュートリアル 4について

問題概要

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

Aさんはα部署に所属し、とある検証の環境設計を実施していました。
この検証はβ部署と共同で行っています。
Aさんの先輩社員がメモとして渡していた当初の論理構成は以下の通りです。
しかし、Aさんの構成はコストの圧縮で設計変更せざるを得なくなりました。
コスト圧縮後の物理構成は下記の通りです。

Aさんは先輩のメモを忠実に再現するため、慣れない仮想化技術を用いました。
ただし、検証環境がうまく動かないようです。
状況を解消し、検証環境を正常にしてください。

達成条件
- c1からc2に対し、疎通性があること
- c3からc4に対し、疎通性があること
- 先輩社員の論理構成になっていること
制約
- c1-4へのアクセスはできません。
- 達成条件を満たした時、下記の状態になっていないこと
 - c1からc3、及びc4に疎通性がある状態
 - c2からc3、及びc4に疎通性がある状態
 - c3からc1、及びc2に疎通性がある状態
 - c4からc1、及びc2に疎通性がある状態


この問題は下記2点の問題に接続できない状態になっていました。

  • VRFに紐づいたI/Fの不足
  • 論理インターフェースに紐づくI/Fのlink down 順を追って解説します。

まず、問題文中の「仮想技術」に何が使われているかConfigから確認します。

rt01#show running-config | include vrf
vrf definition beta
 vrf forwarding beta
router ospf 10 vrf beta
rt01#show running-config | include interface
interface GigabitEthernet2
interface GigabitEthernet3
interface GigabitEthernet3.100
interface GigabitEthernet3.200
interface GigabitEthernet4
interface GigabitEthernet5
 
---
rt02#show running-config | include vrf
vrf definition beta
 vrf forwarding beta
router ospf 10 vrf beta
rt02#show running-config | include interface
interface GigabitEthernet2
interface GigabitEthernet3
interface GigabitEthernet3.100
interface GigabitEthernet3.200
interface GigabitEthernet4
interface GigabitEthernet5

betaという名前のVRF、interface GigabitEthernet3にサブインターフェースが使われていることが分かりました。

上記の情報を用いて、ルータから各C向けに対する状況を確認します。

rt01#ping 192.168.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos 92.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
rt01#ping vrf beta 192.168.10.1
% VRF beta does not have a usable source address

---
rt02#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/6 ms
rt02#ping vrf beta 192.168.11.1
% VRF beta does not have a usable source address

C01、C02には疎通性がありました。 一方で、C03、C04はVRFにソースアドレスが適用されていないようです。 該当のI/Fを確認します。

rt01#show running-config | section GigabitEthernet5
interface GigabitEthernet5
 ip address 192.168.10.254 255.255.255.0
 negotiation auto
 no mop enabled
 no mop sysid
---
rt02#show running-config | section GigabitEthernet5
interface GigabitEthernet5
ip address 192.168.11.254 255.255.255.0
negotiation auto
no mop enabled
no mop sysid

設定にてvrfの適用がされていないようです。 下記を追加します。

(RT01に対して)
interface GigabitEthernet5
   vrf forwarding beta
   ip address 192.168.10.254 255.255.255.0
---
(RT02に対して)
interface GigabitEthernet5
   vrf forwarding beta
   ip address 192.168.11.254 255.255.255.0

C03、C04の疎通性を確認します。

rt01#ping vrf beta 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
---
rt02#ping vrf beta 192.168.11.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.11.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

これでCと各ルータ間において図に書かれた内容とRT内で設定されている情報が一致しました。 次にルータ間の接続を確認します。

rt01#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
rt01#ping vrf beta 172.16.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
---
rt02#ping 172.16.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
rt02#ping vrf beta 172.16.10.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

ルータ間の接続がないようです。 ルータのI/F状態を確認します。

rt01#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet2       10.0.0.15       YES manual up                    up
GigabitEthernet3       unassigned      YES unset  administratively down down
GigabitEthernet3.100   172.16.0.254    YES manual administratively down down
GigabitEthernet3.200   172.16.10.254   YES manual administratively down down
GigabitEthernet4       192.168.0.254   YES manual up                    up
GigabitEthernet5       192.168.10.254  YES manual up                    up
---
rt02#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet2       10.0.0.15       YES manual up                    up
GigabitEthernet3       unassigned      YES unset  administratively down down
GigabitEthernet3.100   172.16.0.1      YES manual administratively down down
GigabitEthernet3.200   172.16.10.1     YES manual administratively down down
GigabitEthernet4       192.168.1.254   YES manual up                    up
GigabitEthernet5       192.168.11.254  YES manual up                    up

ルータ間のI/Fがdown状態になっています。 下記コンフィグを各ルータに入力します。

interface GigabitEthernet3
   no shutdown

状態を確認します。

rt01#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet2       10.0.0.15       YES manual up                    up
GigabitEthernet3       unassigned      YES unset  up                    up
GigabitEthernet3.100   172.16.0.254    YES manual up                    up
GigabitEthernet3.200   172.16.10.254   YES manual up                    up
GigabitEthernet4       192.168.0.254   YES manual up                    up
GigabitEthernet5       192.168.10.254  YES manual up                    up
---
rt02#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet2       10.0.0.15       YES manual up                    up
GigabitEthernet3       unassigned      YES unset  up                    up
GigabitEthernet3.100   172.16.0.1      YES manual up                    up
GigabitEthernet3.200   172.16.10.1     YES manual up                    up
GigabitEthernet4       192.168.1.254   YES manual up                    up
GigabitEthernet5       192.168.11.254  YES manual up                    up

各I/Fのlinkupを確認できました。

ルータ間のping疎通を再度確認します。

rt01#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
rt01#ping vrf beta 172.16.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
---
rt02#ping 172.16.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
rt02#ping vrf beta 172.16.10.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

ルータ間の接続が問題なくできるようになりました。 最後に達成条件の疑似確認をします。

rt01#ping 192.168.1.1 source 192.168.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
rt01#ping vrf beta 192.168.11.1 source 192.168.10.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.11.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
---
rt02#ping 192.168.0.1 source 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
rt02#ping vrf beta 192.168.10.1 source 192.168.11.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.11.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

各C向けのI/Fから対向のCに対して問題なく疎通できそうです。 以上で解決となります。

Level1-3について

問題概要

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

あなたはA社の社員です。
A社ではB社のNWサービスを経由して、A社のC拠点とD拠点をトンネリング接続することになりました。
上記の検証を別社員が行っていたところ、下記が分かりました。
- 拠点Cのc1からD拠点のB向けセグメントに接続できる
- 拠点Cのc1からD拠点の配下セグメントに接続出来ない
2.について、接続できない状態を解消してください。
また、別社員のConfigはレビューをせずにConfigを投入していることが分かりました。
必要に応じて、Configを変更して下さい。
トポロジーは下記の通りです。

達成条件
- c1から172.16.1.254に対し、以下のコマンドで通信が行えること
 - ping 172.16.1.254
- 各ルータのConfigをレビューして、必要があれば変更する。
制約
- ルータ「B社_NWサービス」はアクセスできません


この問題は下記2点の問題によって接続できない状態になっていました。

  • rt03内にて192.168.0.0/27向けのroute情報不足
  • rt03内、ip routing機能の無効化

順を追って解説します。

まず、問題文の別社員の話が本当か確認します。

c1:~# ping -c 5 192.168.0.131
PING 192.168.0.131 (192.168.0.131) 56(84) bytes of data.
64 bytes from 192.168.0.131: icmp_seq=1 ttl=62 time=1.54 ms
64 bytes from 192.168.0.131: icmp_seq=2 ttl=62 time=2.06 ms
64 bytes from 192.168.0.131: icmp_seq=3 ttl=62 time=1.24 ms
64 bytes from 192.168.0.131: icmp_seq=4 ttl=62 time=1.28 ms
64 bytes from 192.168.0.131: icmp_seq=5 ttl=62 time=1.25 ms
 
--- 192.168.0.131 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 1.243/1.475/2.055/0.310 ms
c1:~# ping -c 5 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
 
--- 172.16.1.254 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4092ms

どうやら本当のようです。
rt03のI/F状態を確認します。

rt03#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ---------------------- ------------ -------------- ----------- -------
Ethernet1 192.168.0.131/27 up up 1500
Loopback0 172.16.1.254/24 up up 65535
Management0 172.20.20.5/24 up up 1500
Tunnel1 10.0.0.2/30 down down 1476

Tunnel 1がdownになっており、Tunnelが上手く張れていない点に問題がありそうです。
rt01、rt03のTunnel 1のConfigを確認します。

rt01#show running-config | section Tunnel1
interface Tunnel1
ip address 10.0.0.1/30
tunnel source 192.168.0.2
tunnel destination 192.168.0.131
ip route 172.16.1.0/24 Tunnel1
---
 
rt03#show running-config | section Tunnel1
interface Tunnel1
ip address 10.0.0.2/30
tunnel source 192.168.0.131
tunnel destination 192.168.0.2

各tunnel destinationpingが通る確認します。

rt01#ping 192.168.0.131
PING 192.168.0.131 (192.168.0.131) 72(100) bytes of data.
 
--- 192.168.0.131 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 41ms
---
 
rt03#ping 192.168.0.2
ping: connect: Network is unreachable

rt03がrt01の経路に対して、Network is unreachable です。

rt03に下記コマンドを追加します。
ip route 192.168.0.0/27 192.168.0.130
追加後のping、及びtunnelの状態は下記の通りです。

rt01#ping 192.168.0.131
PING 192.168.0.131 (192.168.0.131) 72(100) bytes of data.
80 bytes from 192.168.0.131: icmp_seq=1 ttl=63 time=0.687 ms
80 bytes from 192.168.0.131: icmp_seq=2 ttl=63 time=0.424 ms
80 bytes from 192.168.0.131: icmp_seq=3 ttl=63 time=0.367 ms
80 bytes from 192.168.0.131: icmp_seq=4 ttl=63 time=0.378 ms
80 bytes from 192.168.0.131: icmp_seq=5 ttl=63 time=0.395 ms
 
--- 192.168.0.131 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.367/0.450/0.687/0.119 ms, ipg/ewma 1.004/0.564 ms
---
 
rt03#ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 72(100) bytes of data.
80 bytes from 192.168.0.2: icmp_seq=1 ttl=63 time=0.701 ms
80 bytes from 192.168.0.2: icmp_seq=2 ttl=63 time=0.449 ms
80 bytes from 192.168.0.2: icmp_seq=3 ttl=63 time=0.386 ms
80 bytes from 192.168.0.2: icmp_seq=4 ttl=63 time=0.383 ms
80 bytes from 192.168.0.2: icmp_seq=5 ttl=63 time=0.373 ms
 
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.373/0.458/0.701/0.124 ms, ipg/ewma 1.081/0.574 ms
---
 
rt01#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- -------------------- ------------ -------------- ---------- -------
Ethernet1 192.168.0.2/27 up up 1500
Ethernet2 192.168.1.1/24 up up 1500
Management0 172.20.20.3/24 up up 1500
Tunnel1 10.0.0.1/30 up up 1476
---
 
rt03#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ---------------------- ------------ -------------- ----------- -------
Ethernet1 192.168.0.131/27 up up 1500
Loopback0 172.16.1.254/24 up up 65535
Management0 172.20.20.5/24 up up 1500
Tunnel1 10.0.0.2/30 down down 1476

pingは双方で通るようになりました。
しかし、rt01のTunnel1はup、rt03のTunnel1はdownという結果になりました。
まだ原因がありそうです。
現状のルート情報を再確認してみます。

rt03#show ip route
 
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - Other BGP Routes,
B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
A O - OSPF Summary, NG - Nexthop Group Static Route,
V - VXLAN Control Service, M - Martian,
DH - DHCP client installed default route,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route,
CL - CBF Leaked Route
 
Gateway of last resort is not set
 
 C        10.0.0.0/30 is directly connected, Tunnel1
 C        172.16.1.0/24 is directly connected, Loopback0
 C        172.20.20.0/24 is directly connected, Management0
 S        192.168.0.0/27 [1/0] via 192.168.0.130, Ethernet1
 C        192.168.0.128/27 is directly connected, Ethernet1
 S        192.168.1.0/24 is directly connected, Tunnel1
 
! IP routing not enabled

ルート情報として特におかしな設定は入っていないようにみえます。
ただ、最後の行に! IP routing not enabledとあります。
これが原因かもしれません。
Configを確認します。

rt03#show running-config | include routing
service routing protocols model multi-agent
no ip routing

ip routing機能が無効になっていました。
rt03に下記コマンドを追加し、有効にします。
ip routing
追加後のtunnelの状態は下記の通りです。

rt03#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ---------------------- ------------ -------------- ----------- -------
Ethernet1 192.168.0.131/27 up up 1500
Loopback0 172.16.1.254/24 up up 65535
Management0 172.20.20.5/24 up up 1500
Tunnel1 10.0.0.2/30 up up 1476

rt03のTunnel1のI/F状態もupになりました。
最後にPC01からpingが通るか、確認します。

c1:~# ping -c 5 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=62 time=2.33 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=62 time=1.29 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=62 time=1.24 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=62 time=1.18 ms
64 bytes from 172.16.1.254: icmp_seq=5 ttl=62 time=1.18 ms
 
--- 172.16.1.254 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.177/1.445/2.334/0.446 ms

c1から172.16.1.254に対し、ping 通信が行えることを確認できましたので、疎通性に関する問題は解決となります。

最後に、問題文にあるConfigのレビューをします。
よく見るとc1向けの経路が下記になっています。
ip route 192.168.1.0/24 192.168.0.130
rt01-03間でTunnelを貼っている環境のため、下記に書き換えます。

no ip route 192.168.1.0/24 192.168.0.130
ip route 192.168.1.0/24 Tunnel1

なお、rt03がrt01の経路に対して、上記変更を加えていない場合は90点としています。

Level1-4について

問題概要

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

Aさんは、とある拠点間を結ぶ検証環境の管理者です。
その検証環境は、同じ部署に所属する人たちも共用で使用しています。
ある日、共用使用者であるBさんから下記の要望がありました。
「追加のセグメントを作って利用できるようにしてほしい」
Aさんが頑張って対応したようですが、BさんがPC04を追加した後、Bさん所有のPC03にて確認したところうまく繋がっておらず、あなたに助けを求めてきました。
状況を確認して、検証環境を正常な状態にしてください。
トポロジー図とBさん所有のPCに関する情報は下記の通りです。

達成条件
PC03からPC04に対して疎通性が確認できること。
制約
PC03、PC04は操作禁止。


この問題はPC04の所属するルート情報がospfで広告されておらず接続できない状態になっていました。

まず達成条件で用いられるPCにはアクセスできないため、直結になっているrt02から情報を入手します。

rt02#ping 192.168.11.1
PING 192.168.11.1 (192.168.11.1) 72(100) bytes of data.
80 bytes from 192.168.11.1: icmp_seq=1 ttl=64 time=0.069 ms
80 bytes from 192.168.11.1: icmp_seq=2 ttl=64 time=0.025 ms
80 bytes from 192.168.11.1: icmp_seq=3 ttl=64 time=0.008 ms
80 bytes from 192.168.11.1: icmp_seq=4 ttl=64 time=0.006 ms
80 bytes from 192.168.11.1: icmp_seq=5 ttl=64 time=0.013 ms
 
--- 192.168.11.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.006/0.024/0.069/0.023 ms, ipg/ewma 0.481/0.045 ms
---

PC04から返事があるため、L2の問題ではないようです。
次に、rt01から同様に確認します。

rt01#ping 192.168.11.1
PING 192.168.11.1 (192.168.11.1) 72(100) bytes of data.
 
--- 192.168.11.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 40ms

rt01からPC04のIPアドレスには疎通できませんでした。
rt01のルート状態を確認します。

rt01#show ip route
 
VRF: default
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B - Other BGP Routes,
       B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
       I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
       A O - OSPF Summary, NG - Nexthop Group Static Route,
       V - VXLAN Control Service, M - Martian,
       DH - DHCP client installed default route,
       DP - Dynamic Policy Route, L - VRF Leaked,
       G  - gRIBI, RC - Route Cache Route,
       CL - CBF Leaked Route
 
Gateway of last resort:
 S        0.0.0.0/0 [1/0] via 172.20.20.1, Management0
 
 C        172.16.0.0/24 is directly connected, Ethernet1
 C        172.20.20.0/24 is directly connected, Management0
 C        192.168.0.0/24 is directly connected, Ethernet2
 O        192.168.1.0/24 [110/20] via 172.16.0.1, Ethernet1
 C        192.168.10.0/24 is directly connected, Ethernet3

PC04の192.168.10.0/24に関するルート情報がありません。
192.168.1.0/24はOSPFによって広告されているため、rt02のospfを確認します。

rt02(config)#show running-config |section ospf
router ospf 1
   passive-interface Ethernet2
   passive-interface Ethernet3
   network 172.16.0.0/24 area 0.0.0.0
   network 192.168.1.0/24 area 0.0.0.0
   max-lsa 12000

passive-interfaceの設定は入っています。 しかし、肝心の192.168.10.0/24に関するルート情報がnetworkの設定がないため追加します。

router ospf 1
network 192.168.11.0/24 area 0
end

設定後、rt01のルーティングテーブルにて192.168.11.0/24の経路が増えていることを確認します。

rt01#show ip route
 
VRF: default
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B - Other BGP Routes,
       B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
       I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
       A O - OSPF Summary, NG - Nexthop Group Static Route,
       V - VXLAN Control Service, M - Martian,
       DH - DHCP client installed default route,
       DP - Dynamic Policy Route, L - VRF Leaked,
       G  - gRIBI, RC - Route Cache Route,
       CL - CBF Leaked Route
 
Gateway of last resort:
 S        0.0.0.0/0 [1/0] via 172.20.20.1, Management0
 
 C        172.16.0.0/24 is directly connected, Ethernet1
 C        172.20.20.0/24 is directly connected, Management0
 C        192.168.0.0/24 is directly connected, Ethernet2
 O        192.168.1.0/24 [110/20] via 172.16.0.1, Ethernet1
 C        192.168.10.0/24 is directly connected, Ethernet3
 O        192.168.11.0/24 [110/20] via 172.16.0.1, Ethernet1

PC03からPC04に疎通できるかどうか、疑似的に確認します。

rt01#ping 192.168.11.1
PING 192.168.11.1 (192.168.11.1) 72(100) bytes of data.
80 bytes from 192.168.11.1: icmp_seq=1 ttl=63 time=0.574 ms
80 bytes from 192.168.11.1: icmp_seq=2 ttl=63 time=0.367 ms
80 bytes from 192.168.11.1: icmp_seq=3 ttl=63 time=0.302 ms
80 bytes from 192.168.11.1: icmp_seq=4 ttl=63 time=0.286 ms
80 bytes from 192.168.11.1: icmp_seq=5 ttl=63 time=0.358 ms
 
--- 192.168.11.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.286/0.377/0.574/0.103 ms, ipg/ewma 0.876/0.472 ms

PC03は利用できないため、通るだろう、という形で作業としては終了です。

さいごに

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

チュートリアル4は、VLAN間ルーティング、及びVRFに関する問題について出題しました。
チュートリアルとしては他の問題と比べて難しかったかもしれません。
ただ、解決方法としてはConfigやinterface周りのshowコマンドを確認していくと自然と解ける問題になっています。
その結果、意外と回答数が多かったな、という印象です。

Level1-3は、ルータ間のルーティングが抜けているため、Tunnel I/FがUpにならない問題を出題しました。
まずお隣のルータ/スイッチの疎通性があるか、確認する癖がついている人には簡単だったかと思います。
また、レビューにてstatic routeの内容について書き換えていただきました。
もし書き換えていない場合は、行きと帰りでパケットのルーティング経路が異なりますので確認してみてください。

Level1-4は、ルータ内のOSPFのnetwork指定が抜けているため追加したPCから特定の場所に疎通性がない問題を出題しました。
実はこの問題が一番簡単だったと思っています。
こちらはroute情報を確認することで自然と解ける問題になります。
個人的にはサービス問題のつもりだったため、もう少し回答数が増えると予想していました。

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していただければ、と思います。

Apache2.4のother_vhosts_access.log出力内容をaccess.logに書く話

はじめに

  • 追加した機材のaccess.logがother_vhosts_access.logに記述されている状態

問題

  • 以下を参考にしました stackoverflow.com
  • 独自のログファイルが定義されていないVirtualHostsのログが書かれるらしい
  • 定義してやれば良さそう

解決

apache2.confに以下の内容を追記しました CustomLog ${APACHE_LOG_DIR}/access.log combined これでログファイルを定義し、無事access.logに出力できました

最後に

  • 余計なlogも一緒に書き込まれるようになった
  • 追加したディレクトリのVirtualHostsを定義し、その中でログファイルを定義した方が良いかな?

Apache2.4で特定のUSER_AGENTを除外する話

はじめに

  • 特定機材を除外する方法を模索した

問題

  • 追加した機材がhttpsを理解できないので、その機材はhttpで通信させたくなった

解決策

  • 以下の内容を記述しました RewriteCond %{HTTP_USER_AGENT} !(hoge) hogeには、その機材のUSER_AGENT名を記述します
  • 指定したUSER_AGENT名の通信はマッチしなくなります

注意点

  • RewriteRule によるRedirect動作の記述の前に書きます
  • ApacheRewriteRuleを認識した後、それ以前に記述されたRewriteCondを見るみたい
  • 以下を参考にしました www.lesstep.jp

最後に

SurfaceにWindows10をクリーンインストールする話

はじめに

問題

  • Windows10 に含まれている回復やUSBに保存したドライブやクリーンインストールをするも、初期化されなかった
  • さらには、以前のWindows10は吹き飛び、BIOSが起動するだけの文鎮と化した

解決

終わりに

Unity2018で音を再生するときの話

はじめに

  • 大学の課題でUnityのゲームを作ってた
  • 特定条件の時に効果音を出したいなぁと思った

問題

  • 以下のサイトを参考に書いていた

increment-log.com

  • しかしうまくいかず

error CS1061: Type `UnityEngine.Component' does not contain a definition for `PlayOneShot' and no extension method `PlayOneShot' of type `UnityEngine.Component' could be found. Are you missing an assembly reference? というエラーがでた

解決

  • とりあえず名前が違うのかなぁと思って調べていた
  • 普通に公式ドキュメントに書いてあった

docs.unity3d.com

  • 違っていた部分を直したらちゃんと動いた。

終わりに

cmder導入する話

はじめに

導入理由

  • ターミナル上に画像を出したい
  • WindowsのWSLは背景を変更できない

方法

ダウンロード

cmder.net

  • cmder起動してSetting(WIN+ALT+P)を開く

Setting

  • 背景
    • General->Background のPathに好きな画像を入れる
  • WSLの起動
    • Startup->Tasksで新しくTaskを作る
    • Commandsの欄に wsl.exe を記述(bash.exeの場合、shellが必ずbashになる)
  • Cmderの割り当てキーを消す
    • Keys & Macro から設定されてると困るものを消す

おわりに

  • 画像が設定できたので満足