JANOG55 NETCON問題解説 Level2-8 Level2-11 Level3-9

• Level2-8
• Level2-11
• Level3-9

Level2-8

問題文

あなたはVPSを提供しているN社で勤務しています。
昨今IPv4アドレスの枯渇が深刻であり、N社も例外ではありません。
もう在庫がなく追加での取得はできないのです。
そこで、バックボーンで利用していたアドレスをサービス用として転用することを思いつきました。
早速、会社の検証環境で動作検証をしています。
BGP Unnumberedを構成する技術であるRFC8950を活用し、iBGP内ではIPv4アドレスを使わないようにしました。
しかし、SV-01からRT-03へPingが通らないようです。
SV-01からRT-03のルータのアドレスである10.0.0.1にPingが通るように修正を行ってください。
各RTはFRRを利用しており、vtyshでCLIに入ることができます。

達成条件

• sv01から10.0.0.1にアクセスすることができる
  • ping 10.0.0.1
• bgpを使用して経路広報されていること
  • RT-03の広報したPrefixをRT-01が保持していること
  • RT-01の広報したPrefixをRT-03が保持していること

制約

Interface情報は変更してはいけない

config

RT-01

!
frr version 8.4.1_git
frr defaults traditional
hostname RT-01
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 4210000000
 bgp router-id 192.168.192.1
 neighbor 2a06:a005:1f51::2 remote-as 4210000000
 !
 address-family ipv4 unicast
  network 192.168.192.0/24
  neighbor 2a06:a005:1f51::2 soft-reconfiguration inbound
  neighbor 2a06:a005:1f51::2 prefix-list client out
  neighbor 2a06:a005:1f51::2 route-map permit-all in
  neighbor 2a06:a005:1f51::2 route-map permit-all out
 exit-address-family
exit
!
ip prefix-list client seq 10 permit 192.168.192.0/24
!
route-map permit-all permit 100
exit
!
end

RT-02

frr version 8.4.1_git
frr defaults traditional
hostname RT-02
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 4210000000
 bgp router-id 172.16.0.2
 neighbor 172.16.0.1 remote-as external
 neighbor 172.16.0.1 update-source 172.16.0.2
 neighbor 2a06:a005:1f51::1 remote-as 4210000000
 !
 address-family ipv4 unicast
  neighbor 172.16.0.1 soft-reconfiguration inbound
  neighbor 172.16.0.1 prefix-list AllPrefix_v4 in
  neighbor 172.16.0.1 prefix-list cr01_prefix out
  neighbor 172.16.0.1 route-map permitAll_v4 in
  neighbor 172.16.0.1 route-map permitAll_v4 out
  neighbor 2a06:a005:1f51::1 soft-reconfiguration inbound
  neighbor 2a06:a005:1f51::1 route-map permitAll_v4 in
  neighbor 2a06:a005:1f51::1 route-map permitAll_v4 out
 exit-address-family
exit
!
ip prefix-list AllPrefix_v4 seq 10 permit 0.0.0.0/0 le 24
ip prefix-list cr01_prefix seq 10 permit 192.168.192.0/24
!
route-map permitAll_v4 permit 10
exit
!
end

RT-03

frr version 8.4.1_git
frr defaults traditional
hostname RT-03
no ipv6 forwarding
service integrated-vtysh-config
!
ip route 10.0.0.0/24 blackhole 254
!
router bgp 4200000000
 bgp router-id 172.16.0.1
 neighbor 172.16.0.2 remote-as 4210000000
 neighbor 172.16.0.2 update-source 172.16.0.1
 !
 address-family ipv4 unicast
  network 10.0.0.0/24
  neighbor 172.16.0.2 soft-reconfiguration inbound
  neighbor 172.16.0.2 prefix-list AllPrefix_v4 in
  neighbor 172.16.0.2 prefix-list AdvertisePrefix_v4 out
  neighbor 172.16.0.2 route-map permitAll_v4 in
  neighbor 172.16.0.2 route-map permitAdvertise_v4 out
 exit-address-family
exit
!
ip prefix-list AllPrefix_v4 seq 10 permit 0.0.0.0/0 le 24
ip prefix-list AdvertisePrefix_v4 seq 10 permit 10.0.0.0/24
!
route-map permitAll_v4 permit 10
exit
!
route-map permitAdvertise_v4 permit 10
exit
!
end

問題解説

こちらの問題はFRRoutingを利用しています

まず達成条件がクリアできていないことを確認します。

まず、SV-01から10.0.0.1に対しpingしても100%ロスしてしまいます。

つづいてvtyshに入り確認を行います。
RT-01の保有する経路を確認します。

K>* 0.0.0.0/0 [0/0] via 172.20.20.1, eth0, 00:05:48
C>* 172.20.20.0/24 is directly connected, eth0, 00:05:48  
C>* 192.168.192.0/24 is directly connected, eth3, 00:05:47

RT-03の広報する10.0.0.0/24は持っていないようです。

そしてRT-03の保有する経路を確認します。

K>* 0.0.0.0/0 [0/0] via 172.20.20.1, eth0, 00:09:31
S>* 10.0.0.0/24 [254/0] unreachable (blackhole), weight 1, 00:09:30
C>* 10.0.0.1/32 is directly connected, dummy0, 00:09:30
C>* 172.16.0.0/24 is directly connected, eth1, 00:09:30
C>* 172.20.20.0/24 is directly connected, eth0, 00:09:31

RT-01の広報する192.168.192.0/24は持っていないようです。

達成条件はクリアできていませんでしたので、どこかで起きている問題を解決する必要があります。

問題の特定

まずそれぞれのルータ間のPeerが上がっているか確認します。
RT-01

RT-02

RT-03

Peerはすべて上がっているようです。
しかしRT-02でRT-03に対し送信しているしているPrefixが0となっています(PfxSnt 0)
では、なぜ送信できていないのかを探っていきます。

RT-02の保有する経路を確認します。

K>* 0.0.0.0/0 [0/0] via 172.20.20.1, eth0, 00:19:57
B>* 10.0.0.0/24 [20/0] via 172.16.0.1, eth1, weight 1, 00:19:51
C>* 172.16.0.0/24 is directly connected, eth1, 00:19:56
C>* 172.20.20.0/24 is directly connected, eth0, 00:19:57

RT-01の広報する192.168.192.0/24を持っていないことがわかります。
つまり、RT-01とRT-02間で正常に経路を交換できていないようです。

RT-02でRT-01から受け取った経路を確認します。
show ip bgp neighbors 2a06:a005:1f51::1 received-routes

Next Hopが172.16.0.1となっていますが、RT-01とRT-02の間にはIPv4アドレスは存在していないため通信できません。

RT-02のConfigを確認してみると、address-family ipv4 unicastにneighbor 2a06:a005:1f51::1と入っていますので、IPv4のNext HopをIPv6にしたいのだなと分かります。

問題の解決

Extended Nexthop CapabilityをRT-01とRT-02の間で使ってあげることとします。

これでPeerが上がるはずですが、Activeとなり上がりません。

エラーを見てあげるとdoes not have a v6 LL address associated with it, waiting until one is created for itといったエラーが上がっていることがわかります。
確かにv6 LLアドレスは持っていますので、そんなことはないはずです。
調べてみると前から観測されているようで、FRRのバグだと思っています。まだ調べきれていません。
InterfaceをShutdownさせ再度upさせると、エラーなくPeerが上がります。

最後に採点条件を満たしていることを確認します。
RT-01が10.0.0.0/24を持っていること
B>* 10.0.0.0/24 [200/0] via 2a06:a005:1f51::2, eth2, weight 1, 00:00:24

RT-03が192.168.192.0/24を持っていること
B>* 192.168.192.0/24 [20/0] via 172.16.0.2, eth1, weight 1, 00:00:17

SV-01から10.0.0.1にpingが通ること

満たしていますのでこれにて終了です。

問題作成にあたって

こちらの問題はICTSCの問題を参考にさせていただいたものです。
上記問題の状況を再現しようとしましたが、特に何もせずにIPv4 NLRI with IPv6 Nexthopできていました。
そこでIPv4と同じ様にPublicなIPv6アドレスで構成しようとしたところ、Extended Nexthop Capabilityが必要でしたので出題することとしました。

多くの事業者にとってIPv4枯渇は問題となっていると思います。
IPv6 Onlyなバックボーンは最近実運用でも採用例をよく目にすることから、それの導入となればと今回の問題文としました。
IP Closの場でもBGP Unnumberedがよく使われていますし、IXPにおいても可能性を秘めていると思っております。
IPv6への完全移行は相当な難しさがありますが、組織内においては削減できると思いますので、小中規模のネットワークにおいてもBGP Unnumberedが普及すると良いと思っております。

Level2-11

問題文

あなたはホスティングプロバイダであるN社(AS65000、AS65200)に勤務しています。
顧客のサーバ(SV-01: 172.17.0.10)に対し、繰り返しDoS攻撃が行われているため、度々サービスがダウンしていました。

自分たちでDoS攻撃を処理することも考えましたが、攻撃の規模が大きいため現実的ではありませんでした。
攻撃元を確認したところ、AS65500のIP(SV-02: 172.16.0.10)より行われていることがわかりました。

AS65000とAS65200は、A社 AS65100からIPトランジットを購入しています。
AS65200は攻撃を処理するのに十分な量の帯域を確保していますが、AS65000とAS65100の接続は十分ではありません。

AS65200はBGP Communityへの対応をしており、AS65000よりAS65200に対してBGP Communityを付与した広報をすることでBlackholeにルーティングする(RTBH)ことができるはずです。
早速設定してみましたが、うまく動作していないようです。

あなたはRT-01・SV-01・RT-02を触ることができます。

RT-01よりRT-02に対して行ったRTBHが正しく行われ、172.17.0.10への通信がRT-01に到達しないよう修正を行ってください。

攻撃対象とされているIP(RTBHの対象): 172.17.0.10
AS65200によりAS65000に提供されているblackhole用のBGPコミュニティ 65200:666
A社はプレフィックス長が/24より長いルートを受け取りません。
AS65200はプレフィックス長が/32のルートも受け取るはずです。
N社はプレフィックス長が/24より長いルートは組織外のASに送信してはいけません。
攻撃元のSV-02からは172.17.0.10、172.18.0.10に対して継続してpingが送信されているため、確認に使用することもできます。

達成条件

• SV-01にて以下の条件を満たせていること
  • SV-02から送出される、172.17.0.10宛のpingが到達しないこと
  • SV-02から送出される、RTBH対象以外のIP(172.18.0.10, 172.17.0.1)宛のPingが通ること
• RT-02にて正常にブラックホールにルーティングできていること
• RT-02においてRT-01から広報された172.17.0.10/32が存在し、Nexthop-discardされていること
• RT-02において172.17.0.10/32にbgpコミュニティ 65200:666が付与されていること

制約

Static Routeを設定するのは禁止です。
Firewallの追加は禁止です。

config

RT-01 (問題に関連するところのみ抜粋)

interface GigabitEthernet0/0/0/0
 description to-RT-02
 ipv4 address 10.10.0.51 255.255.255.254
!
interface GigabitEthernet0/0/0/1
 description to-RT-03
 ipv4 address 10.10.0.61 255.255.255.254
!
interface GigabitEthernet0/0/0/2
 description to-SV-01
 ipv4 address 172.17.0.1 255.255.255.0
!
prefix-set MY_PREFIXES
  172.17.0.0/24,
  172.18.0.0/24
end-set
!
prefix-set BLACKHOLE_PREFIXES
  172.17.0.10/32
end-set
!
community-set AS65200_BLACKHOLE
  65200:666
end-set
!
route-policy PASS_ALL
  pass
end-policy
!
route-policy EXPORT_TO_AS65100
  if destination in MY_PREFIXES then
    pass
  else
    drop
  endif
end-policy
!
route-policy EXPORT_TO_AS65200
  if destination in BLACKHOLE_PREFIXES then
    set community AS65200_BLACKHOLE additive
    pass
  endif
  if destination in (172.17.0.0/24) or destination in (172.18.0.0/24) then
    pass
  else
    drop
  endif
end-policy
!
router static
 address-family ipv4 unicast
  172.17.0.0/24 Null0
  172.17.0.10/32 GigabitEthernet0/0/0/2
  172.18.0.0/24 Null0
  172.18.0.10/32 GigabitEthernet0/0/0/2
 !
!
router bgp 65000
 bgp router-id 172.17.0.1
 address-family ipv4 unicast
  network 172.17.0.0/24
  network 172.17.0.10/32
  network 172.18.0.0/24
 !
 neighbor 10.10.0.50
  remote-as 65200
  address-family ipv4 unicast
   route-policy PASS_ALL in
   route-policy EXPORT_TO_AS65200 out
  !
 !
 neighbor 10.10.0.60
  remote-as 65100
  address-family ipv4 unicast
   route-policy PASS_ALL in
   route-policy EXPORT_TO_AS65100 out
  !
 !

RT-02 (問題に関連するところのみ抜粋)

interface GigabitEthernet0/0/0/0
 description to-RT-01
 ipv4 address 10.10.0.50 255.255.255.254
!
interface GigabitEthernet0/0/0/1
 description to-RT-04
 ipv4 address 10.10.0.30 255.255.255.254
!
interface GigabitEthernet0/0/0/2
 description to-RT-03
 ipv4 address 10.10.0.70 255.255.255.254
!
prefix-set CUSTOMER_AS65000_PREFIXES
  172.17.0.0/24,
  172.18.0.0/24
end-set
!
prefix-set CUSTOMER_AS65500_PREFIXES
  172.16.0.0/24
end-set
!
community-set BLACKHOLE
  65200:666
end-set
!
route-policy PASS_ALL
  if destination in (0.0.0.0/0 ge 8 le 24) then
    pass
  else
    drop
  endif   
end-policy
!
route-policy FROM_CUSTOMER_AS65000
  if destination in (172.17.0.0/24 ge 24 le 32) or destination in (172.18.0.0/24 ge 24 le 32) then
    if community matches-any BLACKHOLE then
      set next-hop discard
    else
      pass
    endif
  endif
end-policy
!
route-policy FROM_CUSTOMER_AS65500
  if destination in (172.16.0.0/24) then
    pass
  endif
end-policy
!
router bgp 65200
 bgp router-id 10.10.0.50
 address-family ipv4 unicast
 !
 neighbor 10.10.0.31
  remote-as 65500
  address-family ipv4 unicast
   route-policy FROM_CUSTOMER_AS65500 in
   route-policy PASS_ALL out
  !
 !        
 neighbor 10.10.0.51
  remote-as 65000
  address-family ipv4 unicast
   route-policy FROM_CUSTOMER_AS65000 in
   route-policy PASS_ALL out
  !
 !
 neighbor 10.10.0.71
  remote-as 65100
  address-family ipv4 unicast
   route-policy PASS_ALL in
   route-policy PASS_ALL out
  !
 !

問題解説

こちらの問題はCisco XRを利用しています。

まずは達成条件をクリアできていないことを確認します。

SV-01にてtcpdumpしてみると、SV-02から送出されているpingが確認できます。

SV-02(172.16.0.10)から172.17.0.10に宛てたpingも届いていますので、RTBHできていません。

そしてRT-02を見ても、172.17.0.10/32自体が学習されていないことが分かります。

問題の特定と解決

RT-01でRT-02に対し広報しているルートを見てみます。

ちゃんと172.17.0.10/32も広報しているようです。

RT-02でshow bgp ipv4 unicast summaryにより確認するとRT-01(10.10.0.51)から受け取ったPrefixは2つとなっています。

何らかの設定で弾かれてしまっているようです。

設定を確認します。
neighbor 10.10.0.51(RT-01)の設定は以下のとおりです

 neighbor 10.10.0.51
  remote-as 65000
  address-family ipv4 unicast
   route-policy FROM_CUSTOMER_AS65000 in
   route-policy PASS_ALL out

route policy FROM_CUSTOMER_AS65000が適応されているので中身を見ます

route-policy FROM_CUSTOMER_AS65000
  if destination in (172.17.0.0/24) or destination in (172.18.0.0/24) then
    if community matches-any BLACKHOLE then
      set next-hop discard
    else
      pass
    endif
  endif
end-policy

/24と固定で入っています。
よって、こちらのRoute Policyで弾かれていることがわかります。
問題文によるとAS65200はプレフィックス長が/32のルートも受け取るはずです。となっていますので、/24から/32まで受け取るよう変更します。

route-policy FROM_CUSTOMER_AS65000
  if destination in (172.17.0.0/24 ge 24 le 32) or destination in (172.18.0.0/24 ge 24 le 32) then
    if community matches-any BLACKHOLE then
      set next-hop discard
    else
      pass
    endif
  endif
end-policy

RT-02で172.17.0.10/32も受け取るようになったことを確認します。
B 172.17.0.10/32 [20/0] via 10.10.0.51, 00:00:33

しかし、まだSV-02(172.16.0.10)から172.17.0.10に宛てたpingは届き続けています。

引き続きRT-02の設定を確認します。
Route Policyには

    if community matches-any BLACKHOLE then
      set next-hop discard

と書かれています。こちらのCommunity Setを確認します。

community-set BLACKHOLE
  65200:666
end-set

よって、BGP Community 65200:666が付与されて来た場合、next-hopがdiscardされると分かります。
172.17.0.10/32にBGP Community 65200:666が付与されているか確認します

BGP Community 65200:666は付与されていないようです。

RT-01側の設定を確認します。
router bgp 65000の設定は以下のようになっています。

router bgp 65000
 bgp router-id 172.17.0.1
 address-family ipv4 unicast
  network 172.17.0.0/24
  network 172.17.0.10/32
  network 172.18.0.0/24
 !
 neighbor 10.10.0.50
  remote-as 65200
  address-family ipv4 unicast
   route-policy PASS_ALL in
   route-policy EXPORT_TO_AS65200 out
  !
 !
 neighbor 10.10.0.60
  remote-as 65100
  address-family ipv4 unicast
   route-policy PASS_ALL in
   route-policy EXPORT_TO_AS65100 out

RT-01からみてRT-02は異なるASであるため、BGP Communityを渡すにはsend-community-ebgpが必要です。
以下のように変更します。

 neighbor 10.10.0.50
  remote-as 65200
  address-family ipv4 unicast
   send-community-ebgp
   route-policy PASS_ALL in
   route-policy EXPORT_TO_AS65200 out

RT-02側を確認します。

意図したようにコミュニティが付与されていることが確認できました。

routeを見てもNullに向いていることを確認できます。
B 172.17.0.10/32 [20/0] via 0.0.0.0, 00:02:11, Null0

RT-02でBlackholeすることはできましたが、RT-03もRT-01のUpstreamとして存在しています。
RT-04→RT-03→RT-01といった経路で到達してしまう可能性があります。
様々な方法がありますが、今回は172.17.0.0/24のRT-03への広報を止めることとします。
RT-01のRT-03に対する設定を確認すると以下のRoute Policyが適応されていることがわかります。

route-policy EXPORT_TO_AS65100
  if destination in MY_PREFIXES then
    pass
  else
    drop
  endif
end-policy

指定されているPrefix Setは以下です。

prefix-set MY_PREFIXES
  172.17.0.0/24,
  172.18.0.0/24
end-set

今回は新たなPrefix Setを作成し、指定します。

prefix-set EXPORT_TO_AS65100_PREFIXES
  172.18.0.0/24
end-set

route-policy EXPORT_TO_AS65100
  if destination in EXPORT_TO_AS65100_PREFIXES then
    pass
  else
    drop
  endif
end-policy

これにて、SV-02(172.16.0.10)から172.17.0.10に宛てたPingがRT-02でBlackholeされ、届かなくなりました。

問題作成にあたって

日本語の読解問題のようになってしまいました。
もっと分かりやすい直感的な出題を心がけたいです。

多くの場合、RTBHは完全にパケットをDropしてしまうためDDoSの解決策にはならないはずです。
(サービスへのアクセスが完全にできなくなる)
ただ、中小ホスティングプロバイダではDDoSを処理するのに十分な帯域を普段から持つのは現実的ではありませんので、まだまだ使われています。
（私の使っているホスティングプロバイダのサーバもUpstreamでDropされたことがあります)
その動作原理を知りたいという気持ちもあり出題に至りました。

Level3-9

問題文

あなたはある動画配信サービスを提供するAS65000を運用しています。

サービスの拡大に伴い帯域の不足が懸念されています。
そこでこれまで購入していたAS65100のトランジットに加え、AS65200からもトランジットを購入し、ECMPをしたいです。

設定を行いましたが、うまくバランスされていないようです。
修正を行ってください。

顧客のPrefixは172.16.0.0/24とします。
172.16.0.10は顧客側に設置されたサーバの1つで、確認に使用できます。
SV-01にて「mtr 172.16.0.10 --udp」を実行し、2ホップ目に複数のアドレスが表示されることを確認してください

達成条件

• RT-01にて、172.16.0.0/24がmultipathとなっていること。
• SV-01にて「mtr 172.16.0.10 --udp」を実行し、2ホップ目に複数のアドレスが表示されること。

制約

Static Routeを設定するのは禁止です。

config

RT-01

!
frr version 8.4.1_git
frr defaults traditional
hostname RT-01
no ipv6 forwarding
service integrated-vtysh-config
!
ip route 172.17.0.0/24 blackhole 254
!
router bgp 65000
 bgp router-id 172.17.0.1
 neighbor 10.10.0.50 remote-as 65200
 neighbor 10.10.0.50 update-source 10.10.0.51
 neighbor 10.10.0.60 remote-as 65100
 neighbor 10.10.0.60 update-source 10.10.0.61
 !
 address-family ipv4 unicast
  network 172.17.0.0/24
  neighbor 10.10.0.50 soft-reconfiguration inbound
  neighbor 10.10.0.50 prefix-list AllPrefix_v4 in
  neighbor 10.10.0.50 prefix-list AdvertisePrefix_v4 out
  neighbor 10.10.0.50 route-map permit-all in
  neighbor 10.10.0.50 route-map permit-all out
  neighbor 10.10.0.60 soft-reconfiguration inbound
  neighbor 10.10.0.60 prefix-list AllPrefix_v4 in
  neighbor 10.10.0.60 prefix-list AdvertisePrefix_v4 out
  neighbor 10.10.0.60 route-map permit-all in
  neighbor 10.10.0.60 route-map permit-all out
 exit-address-family
exit
!
ip prefix-list AllPrefix_v4 seq 10 permit 0.0.0.0/0 le 24
ip prefix-list AdvertisePrefix_v4 seq 10 permit 172.17.0.0/24
!
route-map permit-all permit 100
exit
!
end

問題解説

こちらの問題はFRRoutingを利用しています。
触れることのできるマシンはRT-01とSV-01です。

まずは達成条件をクリアできていないことを確認します。

SV-01でmtr 172.16.0.10 --udpしてみます。

2ホップ目に複数のアドレスが表示されていません。

RT-01でshow ip bgpしてみます。

Prefix 172.16.0.0/24を見ると、next hop 10.10.0.50がBestPathとなっていることがわかります。

問題の特定と解決

複数のASNから学習した経路でECMPするときにはbgp bestpath as-path multipath-relaxが必要です。
RT-01にbgp bestpath as-path multipath-relaxを投入します。

router bgp 65000
 bgp router-id 172.17.0.1
 bgp bestpath as-path multipath-relax
 neighbor 10.10.0.50 remote-as 65200
 neighbor 10.10.0.50 update-source 10.10.0.51
 neighbor 10.10.0.60 remote-as 65100
 neighbor 10.10.0.60 update-source 10.10.0.61

show ip bgpで確認してみます。

Prefix 172.16.0.0/24を見ると、next hop 10.10.0.60に=がつき、Multipathとなっていることがわかります。

SV-01でmtr 172.16.0.10 --udpしてみますが、まだ2ホップ目に複数のアドレスが表示されません。

今回はPingの発信元と発信先が同一です。
FRRoutingはLinux上で動いておりデフォルトでL3 hashのみを確認するため、L4に変更する必要があります。
以下のいずれかの方法で確認します。
sysctl net.ipv4.fib_multipath_hash_policy
cat /proc/sys/net/ipv4/fib_multipath_hash_policy
0となっていることが分かります。

こちらを1に変更し、per-flow ecmpを有効にします。

echo "net.ipv4.fib_multipath_hash_policy=1" >> /etc/sysctl.conf
sysctl -p

または

sysctl -w net.ipv4.fib_multipath_hash_policy=1

SV-01にてmtr 172.16.0.10 --udpをして確認してみましょう。

2ホップ目に複数のアドレスが表示されました。

問題作成にあたって

なかなか外部の複数のASに対してECMPするということは少ないのではないかと思います。
ただ、多くのアクセスを捌く必要のあるサービスの内部などではよく使われるのではないかと思います。
そのようなときの導入となれば良いなと出題しました。

Linux側でL3からL4のECMPに変える必要があることで、満点を取りづらい面もあったかと思います。

雑記

全体を通して、実際の場面にも繋がることを意識しました。
しかし、あまりエンタープライズなネットワークや機器を触ったことがないことから、かなり作問に悩みました。

普段から問題に当たり解決したら記録しておくことの重要性にも気づきました。

すべてのJANOG・NETCON関係者、解いてくださった皆様、ありがとうございました。