JANOG55 NETCON問題解説 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関係者、解いてくださった皆様、ありがとうございました。
Discussion