2017/8/25のルーティング障害

多分巷に出ている情報が正しそうだけど、気になったので調べてみました。

最初はインターネットに関わってない部署だからその術もないとか思ったけど、その気になれば公開されている情報で辿れそうですね。
(消したほうが良ければお知らせください。消すので)

調べようとしたきっかけは小島さんの何気ないツイートでした。

さっきの経路問題「記録してないわー」という人でもhttps://t.co/c9uCj7i8Sl あたりからupdate dump のファイルサイズでかいやつ取ってきて眺めてみると面白いかもしれません。JP / US / EU で見比べるのもおすすめ

— Shintaro Kojima (@codeout) 2017年8月25日

言われてみればそうだよなと思い、ちょっと調べてみることに。
(Routeviewsがあることに気づかせてくださったことに感謝です)

早速Routeviewsを拝見。とりあえずDIX-IEにしてみました。
http://archive.routeviews.org/route-views.wide/bgpdata/2017.08/UPDATES/
この辺り？

	updates.20170825.024..>	2017-08-25 02:59	23K
	updates.20170825.030..>	2017-08-25 03:14	25K
	updates.20170825.031..>	2017-08-25 03:29	839K
	updates.20170825.033..>	2017-08-25 03:44	1.0M
	updates.20170825.034..>	2017-08-25 03:59	39K
	updates.20170825.040..>	2017-08-25 04:14	61K

03:29(UTC)ということは日本時間だとだいたい昼かと
明らかにデータサイズが違うのが2つあります。

とりあえず手前の updates.20170825.0315.bz2 をwget

中身を見る前にbgpdump用意しないと。。。

以下URLからダウンロード
https://bitbucket.org/ripencc/bgpdump/wiki/Home

centosに何も入れてなかったので

 # yum -y install gcc make bzip2-devel zlib-devel

してconfigure / make

bgpdumpコマンドは動きそうなのでとりあえず

$ bgpdump -M updates.20170825.0315.bz2 > bgpdump.txt

単純にupdateの数を時間でwcしてみる

$ cat bgpdump.txt | awk -F\| '{print $2,$5}' | awk '{print substr($2,0,5)}' | uniq -c

    628 03:15

   1034 03:16

    578 03:17

    404 03:18

    611 03:19

    637 03:20

   1139 03:21

   1849 03:22

  93577 03:23  < ---この辺が怪しい？

  85166 03:24  < ---この辺が怪しい？

  74246 03:25

   6516 03:26

   7859 03:27

   4523 03:28

   2187 03:29

もうちょっと細かく

$ cat bgpdump.txt | awk -F\| '{print $2,$5}' | awk '{print substr($2,0,7)}' | grep '03:2[345]' |  uniq -c
  17563 03:23:1
  20197 03:23:2
     16 03:23:4
  55801 03:23:5 <-- この辺？(12:23:50 JST あたり?)
     44 03:24:1
  45316 03:24:2 <-- この辺？
     14 03:24:4
  39792 03:24:5 <-- この辺？
  23999 03:25:0
  41383 03:25:2
   7782 03:25:3
   1082 03:25:5

多分最初の方なので

$ cat bgpdump.txt | grep '03:23:5' | more

(中略)

BGP4MP|08/25/17 03:23:50|W|202.249.2.169|2497|82.148.101.0/24
BGP4MP|08/25/17 03:23:50|W|202.249.2.169|2497|67.201.109.0/24
BGP4MP|08/25/17 03:23:50|A|202.249.2.169|2497|162.247.80.0/24|2497 701 15169 26744|IGP
BGP4MP|08/25/17 03:23:50|A|202.249.2.169|2497|68.170.240.0/24|2497 701 15169 26744|IGP
BGP4MP|08/25/17 03:23:50|A|202.249.2.169|2497|63.116.253.0/24|2497 2914 174 7843 11351 12120|IGP
BGP4MP|08/25/17 03:23:50|A|202.249.2.169|2497|103.55.110.0/24|2497 701 15169 24186 134023|IGP
BGP4MP|08/25/17 03:23:50|A|202.249.2.169|2497|103.55.111.0/24|2497 701 15169 24186 134023|IGP

(たくさんあるので略)

15169がたくさん並んでる模様

$ cat bgpdump.txt | grep '03:23:5' | grep 15169 | wc -l
55329

たくさんアップデートしてる。advatiseかwithdrawかは詳しくみてないけど。

$ whois AS15169
(中略)
ASNumber:       15169
ASName:         GOOGLE
ASHandle:       AS15169
RegDate:        2000-03-30
Updated:        2012-02-24
Ref:            https://whois.arin.net/rest/asn/AS15169

ということで、予備情報がなくともその気になれば辿り着けそうです。
けど、originは正しそうですよね、よくみてないけど。これじゃ経路奉行も反応しないかも。岡田さんが書かれているとおり、BGPSEC PATH Validationがあると幸せになれるのかな？と思いました。

今回の経路トラブルは、単純なMis-Origination/Hijackingじゃなくて、BGPSEC/Path Validationが必要だった場面ってことになるかな。
ﾁｮｰ久々にTweet

— okada masayuki (@smadako) 2017年8月25日

例えば、こういった情報をElasticsearchとかで可視化すると何か見えたりするのかもしれませんね。