2024年1月に開催されたJANOG53にて、ネットワークのトラブルシューティングコンテスト「NETCON」が開催されました。私もNETCONの問題作成に関わりましたので、自分の作成した問題の解説をしていきたいと思います。
こちらではLevel 2-4について解説していきます。
問題
出題内容は以下のようなものでした。
あなたはAS65053のカスタマーにトランジットを提供するAS65001のオペレータです。 先ほどカスタマーからGoogle Public DNS(8.8.4.4, 8.8.8.8)が利用できなくなったとの申告がありました。CloudFlareの1.1.1.1は利用できるので一旦そちらに設定変更して暫定対処としているとのことですが、早急に対処をしてください。 なお、対処にあたっては以下の条件に従ってください。 ・AS65001のみで対処を行なってください。 ・カスタマーにはpingの依頼のみができます。userルータにoper/userでログインし、Loopback53を送信元としたpingが成功するようにしてください。 ・対処にあたっては暫定対処中の環境に影響がないようにする必要があります。 ・既存の設定は削除しないでください。
トポロジ図
達成条件
・userルータにoper/userでログインし、Loopback53を送信元として以下の宛先へのpingが成功すること ・1.1.1.1 ・8.8.4.4 ・8.8.8.8 ・myasルータの既存のコンフィグ（RPL, prefix-set）が削除されていないこと
制約
・myasルータのみで設定変更を行うこと ・ルーティングプロトコルの追加は許可されない ・1.1.1.1への到達性が消失しないこと
解説
現時点の状況を把握するために、userから指定の宛先にpingを打ってみます。
RP/0/RP0/CPU0:user#ping 1.1.1.1 so lo53
Fri Jan 19 04:51:14.662 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/5 ms
RP/0/RP0/CPU0:user#ping 8.8.4.4 so lo53
Fri Jan 19 04:51:21.227 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4 timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RP/0/RP0/CPU0:user#ping 8.8.8.8 so lo53
Fri Jan 19 04:51:43.521 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8 timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)ご申告のとおり8.8.4.4や8.8.8.8には通らないようです。制約ではmyasしか設定変更できないようなので、ここを重点的にチェックします。
ルーティングテーブル観点
まずは基本のルーティングテーブル確認です。
RP/0/RP0/CPU0:myas#show route ipv4 8.8.4.4
Fri Jan 19 04:56:02.608 UTC
Routing entry for 8.8.0.0/16
Known via "bgp 65001", distance 20, metric 0
Tag 65002, type external
Installed Jan 19 04:46:15.958 for 00:09:46
Routing Descriptor Blocks
198.51.100.2, from 198.51.100.2, BGP external
Route metric is 0
No advertising protos.
RP/0/RP0/CPU0:myas#show route ipv4 8.8.8.8
Fri Jan 19 04:56:06.462 UTC
Routing entry for 8.8.8.8/32
Known via "bgp 65001", distance 20, metric 0
Tag 65002, type external
Installed Jan 19 04:46:15.958 for 00:09:50
Routing Descriptor Blocks
198.51.100.2, from 198.51.100.2, BGP external
Route metric is 0
No advertising protos.どちらの宛先も経路情報はあるようですが、なんか手元の情報とは違いますね。
- 8.8.0.0/16の経路がAS65002をネクストホップとしている
- 8.8.8.8/32の経路が存在しており、AS65002をネクストホップとしている
本来と違う経路情報をAS65002から受け取っている可能性がありそうですね。
BGP観点
ではどこからどのような経路を受信しているのか、BGPテーブルを見てみます。
RP/0/RP0/CPU0:myas#show bgp ipv4 unicast
Fri Jan 19 05:03:09.091 UTC
BGP router identifier 11.11.11.11, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 10
BGP main routing table version 10
BGP NSR Initial initsync version 5 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 198.51.100.2 0 0 65002 13335 i
*> 1.1.1.0/24 198.51.100.2 0 0 65002 13335 i
*> 8.8.0.0/16 198.51.100.2 0 0 65002 i
* 203.0.113.0 0 65008 15169 i
*> 8.8.8.8/32 198.51.100.2 0 0 65002 i
*> 53.53.53.53/32 192.0.2.1 0 0 65053 i
Processed 5 prefixes, 6 pathsトポロジ図の情報通り、8.8.0.0/16をAS65008から受信していますが、それとは別にAS65002から8.8.0.0/16, 8.8.8.8/32をもらっているようです。しかし、AS-Pathを見てみるとAS65002オリジンな経路のようです。これは本来期待される経路ではなさそうなので、これらの経路を使わないようにするのが対処法となりそうです。
方針検討
さて、どう対応するかですが考えられるのはいくつかあります。
- AS65002から広報された8.8.0.0/16, 8.8.8.8/32の経路をフィルタして受け取らなくする
- AS65008から広報された8.8.0.0/16の優先度を何らかの方法で上げることで、こちらを優先して使用するようにする
ですが、実は後者の場合はAS65002から8.8.8.8/32な経路が広報されているので、ロンゲストマッチの法則に従って8.8.8.8/32だけはAS65002へ、それ以外はAS65008→AS15169へと流れる形になるため、達成条件である8.8.8.8へのpingが失敗してしまうのです。と言うことで、結局はAS65002からの意図しない広報経路をフィルタするのがシンプルな対処法と考えられます。
設定変更
ここは慣れている方は簡単かもしれませんね。実施する作業はこれだけです。
- 8.8.0.0/16, 8.8.8.8/32を除外する処理を作成する
- 除外する処理をAS65002のネイバーに適用する
やってみましょう。直接指定でも良いですが、prefix-setというものを作って何を対象としているか分かりやすくしてみます。
まず現状把握です。ネイバへのポリシー（受信/送信する経路に適用する処理）を確認しておきますが特に何も処理はやっていないようです。
RP/0/RP0/CPU0:myas#show bgp neighbor 198.51.100.2 | include Policy
Fri Jan 19 05:55:48.658 UTC
Policy for incoming advertisements is OTHERAS_INBOUND
Policy for outgoing advertisements is OTHERAS_OUTBOUND
RP/0/RP0/CPU0:myas#show rpl route-policy OTHERAS_INBOUND
Fri Jan 19 05:55:57.692 UTC
route-policy OTHERAS_INBOUND
pass
end-policy
!
RP/0/RP0/CPU0:myas#show rpl prefix-set
Fri Jan 19 05:56:10.547 UTC
Listing for all Prefix Set objects
prefix-set TO_USER
8.8.0.0/16,
1.1.1.0/24,
1.0.0.0/24
end-set
!では、やっていきます。8.8.8.8はGoogleDNSですので分かりやすく名前をつけて、その宛先となる経路は受信しても捨てるようにします。
RP/0/RP0/CPU0:myas#configure
Fri Jan 19 05:58:47.333 UTC
RP/0/RP0/CPU0:myas(config)#prefix-set GoogleDNS
RP/0/RP0/CPU0:myas(config-pfx)#8.8.0.0/16, 8.8.8.8/32
RP/0/RP0/CPU0:myas(config-pfx)#exit
RP/0/RP0/CPU0:myas(config)#route-policy OTHERAS_INBOUND
Fri Jan 19 05:59:13.938 UTC
% WARNING: Policy object route-policy OTHERAS_INBOUND' exists! Reconfiguring it via CLI will replace current definition. Use 'abort to cancel.
RP/0/RP0/CPU0:myas(config-rpl)#if destination in GoogleDNS then drop else pass endif
RP/0/RP0/CPU0:myas(config-rpl)#exit
RP/0/RP0/CPU0:myas(config)#show config
Fri Jan 19 05:59:40.259 UTC
Building configuration...
!! IOS XR Configuration 7.8.2
!
prefix-set GoogleDNS
8.8.0.0/16,
8.8.8.8/32
end-set
!
route-policy OTHERAS_INBOUND
if destination in GoogleDNS then
drop
else
pass
endif
end-policy
!
end
RP/0/RP0/CPU0:myas(config)#commit
Fri Jan 19 06:00:18.114 UTC
RP/0/RP0/CPU0:myas(config)#end
RP/0/RP0/CPU0:myas#これで受信する経路情報がフィルタされ、意図しない方向に流れないようになりました。
RP/0/RP0/CPU0:myas#show bgp ipv4 unicast
Fri Jan 19 06:00:54.943 UTC
BGP router identifier 11.11.11.11, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 12
BGP main routing table version 12
BGP NSR Initial initsync version 5 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 198.51.100.2 0 0 65002 13335 i
*> 1.1.1.0/24 198.51.100.2 0 0 65002 13335 i
*> 8.8.0.0/16 203.0.113.0 0 65008 15169 i
*> 53.53.53.53/32 192.0.2.1 0 0 65053 i
Processed 4 prefixes, 4 pathsではuserに依頼してみましょう。
RP/0/RP0/CPU0:user#ping 1.1.1.1 source Loopback53
Fri Jan 19 06:02:51.045 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
RP/0/RP0/CPU0:user#ping 8.8.4.4 source Loopback53
Fri Jan 19 06:02:57.488 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms
RP/0/RP0/CPU0:user#ping 8.8.8.8 source Loopback53
Fri Jan 19 06:03:04.056 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 msバッチリです！
回答
さぁ回答です。
AS65002から意図しない経路 8.8.0.0/16, 8.8.8.8/32 が広報されており、本来の経路であるAS65008へ流れなくなっていたので、以下の通りフィルタを適用して回復いたしました。
prefix-set GoogleDNS
8.8.0.0/16,
8.8.8.8/32
end-set
!
route-policy OTHERAS_INBOUND
if destination in GoogleDNS then
drop
else
pass
endif
end-policy
!講評
BGPでは誤った経路を広報することで意図せず異なるASにトラフィックが流れてしまうことがあり得ます。こういったことを避けるためにRPKIの仕組みがあり、誤った経路広報を信じないということが実現できます。これまでのJANOGでもいくつか発表されているものですので、ぜひそちらもご参照ください。
コメント