janog41-bgp-operation-pub

Size: px

Start display at page:

Download "janog41-bgp-operation-pub"

としみつつの
4 years ago
Views:

1 BGP と障害と運と Matsuzaki maz Yoshinobu 2018/1/26 1

2 2017/08/ /1/26 2

3 観測されている概要 2017/08/25 12:22JST 頃 AS15169 が他 AS の IPv4 経路をトランジット開始頃流通しない細かい経路が量に広報これによりトラヒックの吸い込みが発国内の各 AS で通信障害を検知 2017/08/25 12:33JST 頃 AS15169 がトランジットしていた経路を削除 2018/1/26 3

4 観測された問題の BGP 経路概要経路数全体で約 11 万経路 ( 本分が約経路 ) /10 から /24 まで幅広い経路 ( 半数程度が /24) 通常流れていない細かい経路が多かった AS PATH は概ね < 本来の AS PATH> 広報元 AS 番号は正しそう各 AS が直接 AS15169 と張っている BGP 接続では今回の経路広報は観測されていない対象 AS 全体で約 7000 AS 程度 ( 本分が約 89 AS) BGP は観測点によってえる情報が異なるのでご注意 2018/1/26 maz@iij.ad.jp 4

5 トランジットされちゃった AS 世界でおよそ 7000 AS 程度内本 (JPNIC 管轄 ) のものが 89 AS 広報された prefix 数の AS 別順位 OCN/AS4713 がきな影響を受けている AS prefix 4713/OCN /WINDSTREAM /UNINET /Turk Telecom /TANet /CTTNET /1/26 maz@iij.ad.jp 5

6 概要図 1: 平常時 Verizon AS701 該当経路を受信した AS 平常時の通信経路意図せずトランジットされた AS Google AS /1/26 6

7 概要図 1: 平常時 Verizon AS701 該当経路を受信した AS BGP 経路の伝搬意図せずトランジットされた AS Google AS /1/26 7

8 概要図 1: 平常時 Verizon AS701 該当経路を受信した AS 選択された通信経路意図せずトランジットされた AS Google AS /1/26 8

9 推定される障害や影響広報された宛先向けの通信で遅延が発した通信が国経由になったため経路上に分な帯域がない場合は輻輳の発量の経路広報で機器が不安定になった負荷上昇でルータが不安定になった RIB/FIB 溢れでルータが不安定になった何らか機器の bug を踏んだ IXP 越しの通信が迂回したかも発条件が特殊なので恐らく今回は発していないのではと考えている 2018/1/26 9

10 概要図 1: 平常時この経路上のどこかで輻輳が発すると更なる遅延やパケットロスが発 Verizon AS701 該当経路を受信した AS 遅延の発意図せずトランジットされた AS Google AS /1/26 10

11 量の経路追加通常 65 万経路 +10 万経路上流通常 65 万経路 +10 万経路 2 1 IBGP 現状ざっくり約 65 万経路何もしていないと内部の RT3 は 65 万 x2 で 130 万経路 3 IBGP +20 万経路 = 150 万経路今回 10 万 x2 追加で 150 万経路受信していたかも構成によっては更に多い場合も 2018/1/26 maz@iij.ad.jp 11

12 経路削減を適しててもなルータで運するため国内経路のみを内部ルータに渡している場合 AS PATH(_4713_ 等 ) で国内経路を識別していた場合追加で約経路構成によってはもっと多い通常時の 5 倍から 10 倍の経路数が追加された可能性があるこれらなルータが過負荷になるなどの障害が発した可能性がある通常 65 万経路 +10 万経路 IBGP: 国内経路のみ通常数千経路経路 2018/1/26 maz@iij.ad.jp 12

13 IXP でトラヒック減を観測 /1/26 13

14 RIPE Atlas Probe で通信影響測定 RIPE NCC のプロジェクト世界に Probe を配っていてエンドユーザ視点での計測が可能 AS4713 の probe を抽出し宛先別に影響を推定 OCN 内で通信が完結する宛先 : k.root-servers.net 国内で今回の影響を受けた宛先 : m.root-servers.net 海外で今回の影響を受けた宛先 : ctr-ams02.atlas.ripe.net 2018/1/26 maz@iij.ad.jp 14

15 RIPE Atlas でる : OCN 内 IPv4 Probe26837 IPv4 Probe28818 IPv6 IPv6 2018/1/26 maz@iij.ad.jp 15

16 RIPE Atlas でる : OCN と国内 IPv4 Probe26837 IPv4 Probe28818 IPv6 IPv6 2018/1/26 maz@iij.ad.jp 16

17 RIPE Atlas でる : OCN と海外 IPv4 Probe26837 IPv4 Probe28818 IPv6 IPv6 2018/1/26 maz@iij.ad.jp 17

18 RIPE Atlas からえること該当 Probe では国内海外の IPv4 通信に遅延の増加やパケットロスを観測 IPv6 へ直接の影響はほとんどなかった模様 IPv4 の BGP 経路が対象であったため probe26837 では IPv4/IPv6 で宛先に寄らずパケットロスが観測されているため Probe 近傍のどこかで輻輳が発していたかもしれない 2018/1/26 18

19 影響時間の推定迂回による遅延や輻輳の影響今回広報された経路に関わる通信経路や RIPE Atlas などの記録からすると 20 分以内には収束したはず量の経路広報で不安定になった機器の影響影響した機器があった場合そこを通過する通信収束時間はその運組織の対応に依存 2018/1/26 19

20 僕がやってたこと 08/25( ) 14 時台 ENOG46 会場に向かい中某社 SOC より連絡調査開始して関係各所に情報共有 15 時台 JANOG ML に投稿 [janog:14007] ENOG46 で発表 17 時台 AS15169 NOC に情報共有 Twitter に投稿 18 時台 ENOG46 懇親会 2018/1/26 maz@iij.ad.jp 20

僕がやってたこと 08/28( ) そのの IA 研 @IIJ で事象を概説することになり慌てて資料作成何とかできたので公開

21 僕がやってたこと 08/28( ) そのの IA で事象を概説することになり慌てて資料作成何とかできたので公開 /1/26 maz@iij.ad.jp 21

22 2018/1/26 22

23 電気通信事故検証会議の報告為的ミスの未然防誤送信された経路情報の受信防及び不要な経路情報の送信防障害に関する情報の電気通信事業者間での共有利者周知 # 16 ベストエフォートサービスにおいては停が # ない限りは品質の低下と判断していないことから # 総務省は本事案については電気通信事業法上の # 事故には該当しないと判断している /1/26 maz@iij.ad.jp 23

24 円滑なインターネット利環境の確保に関する検討会検討会 ( 第 2 回 ) 配布資料 : 対応の向性 ( 案 ) 誤送信された経路情報の受信防及び不要な経路情報の送信防を図るためのフィルターやリミッターの設定といった仕組み体は既に存在しているが広く電気通信事業者にそれぞれのネットワーク構成や運の考えに合わせて柔軟かつ適切に対応することを求めるためには例えば情報通信ネットワーク安全信頼性基準にルータのフィルター設定について規定する等適切な制度的対応を検討する必要があるまた総務省が本障害のような事象を迅速かつ的確に把握し情報共有の結節点となるためにはこれまで総務省への報告対象ではなかったインターネットの障害についてもサイバー攻撃に起因するものも含めて報告対象とする等総務省への報告の在りを含め障害に関する情報共有体制の整備を検討する必要がある /1/26 maz@iij.ad.jp 24

25 情報集約と展開? 本経済新聞 1 23 紙サービスで障害が発した場合第報を接続事業者から総務省に報告同省が関係する業者に必要な情報を送る対象となる障害の度合いやどこまで報告するかは業者の意を踏まえて今後詰める 2018/1/26 maz@iij.ad.jp 25

26 情報共有周知への課題会社事情会社ポリシー NDA 公式解による硬直化利者対応即時性と不確かな障害情報報道対応報道は犯探しになりがちどうすればうまくやれるだろうか? 2018/1/26 26

27 経路制御でやりたいこと付随して確保したいことは他にもあるけど冗性拡張性運容易性 2018/1/26 27

28 が広報する BGP 経路には届けたい範囲 ( スコープ ) がある到達性を担保する経路 ( トランジット向け広報 ) グローバルに届いて欲しい到達性を確保する経路 ( ピア向け広報 ) 隣接 AS とその配下のみに伝搬して欲しいトラヒックを制御する経路隣接 AS とその配下のみに伝搬して欲しい場合によっては隣接 AS だけでも良いでもこれらは分では制御できない旦広報した経路は受信側のポリシで制御される 2018/1/26 maz@iij.ad.jp 28

29 2018/1/26 29

30 情報の集取と展開みんな何から情報集めてますか? どこで情報提供するのが嬉しいですか? それっぽい情報を出す元はどこが良い? 個 JANOG WG ICT-ISAC JPNIC お役所 2018/1/26 30

31 BGP 運どうします? フィルターやリミッターの設定? リミッターはかなり覚悟が必要な設定今回の件は防げない相互接続を推進もしくは縮退? 接続先を増やして AS_PATH で勝てる状態を作る接続先を減らして漏洩の可能性を減らす leak community? /1/26 31

32 局に応じた情報共有発直後事象把握のために事業者間で情報交換 JANOG 等で信頼関係を構築しておきましょう硬直化前にできるだけ早く利者周知障害認知の公表状況の適宜更新権威ある周知情報があると参照しやすい報道対応僕たちが伝えたいことと報道価値は別モノかも 2018/1/26 32

33 送出経路ポリシは基本 2 つピア / 上流に広報する経路と配下の経路顧客 AS に広報する経路フルルート / デフォルトルート BGP でトラヒック制御しようとすると複雑になっていく例えば特定ピアのみ細かな経路の広報などなど 2018/1/26 maz@iij.ad.jp 33

34 BGP でトラヒック制御しない到達性の維持に努める必要なところに必要な帯域を意する必要な AS と適宜ピアを拡充するピア上流に常に同の経路広報をう誰かが経路流出させても周辺 AS と多拠点でピアできていれば流出経路は AS PATH で採されない可能性がまり影響範囲が極となる 2018/1/26 34

35 複雑化する BGP 経路に局所性が出てきているトラヒック制御のため隠すため BGP はているポイントで経路が異なる漏れ出した経路は特定のネットワークだけに届くかも 2018/1/26 35

36 経路削減は延命策 not 解決策経路フィルタで削減された経路数は現状のもの将来やトラブル発時の経路数は未知 max-prefix などで受信経路数を制限できるけど BGP ピアが切断しても丈夫? alert 受信して機器が不安定になる前に対処可能? 分余裕を持った運をがけるしかないあるいは複数の安全策の併 2018/1/26 36

37 BGP 運でできること統した広報ポリシ AS 間のトラヒック制御に細かい経路を利しない受信ポリシの検討受信経路で酷い影響が出ないようにする余裕を持った機材での運事象を第三者が検証できるように経路アーカイブ等へ経路情報を提供しておく 2018/1/26 37

38 peerlocking の適 Peerlocking yday_practical_bgp.pdf ある AS と堅牢に相互接続できてるならその AS 関連の経路を他から受信しない他 AS が経路を漏洩しても影響を受けない迂回路が直接接続のどれかに限られるため事故が起こった際の影響はより酷いことになるかも運は結構変 2018/1/26 38

39 peerlocking 模式図 AS_PATH に AS-YYY が含まれている経路を他の AS から切受信しない上流ピア顧客 AS-ZZZ AS-XXX 分 AS AS-YYY 2018/1/26 39

IIJ Technical WEEK2017 経路制御の課題と対策

IIJ Technical WEEK2017 経路制御の課題と対策経路制御の課題と対策 Matsuzaki maz Yoshinobu 2017/11/09 maz@iij.ad.jp 1 今のトピック BGP には scope が無い期待される制御を経路フィルタ等で実装契約慣習経費 2017/11/09 maz@iij.ad.jp 2 経路制御でやりたいこと付随して確保したいことは他にもあるけど冗性拡張性運容易性