ISPのトラフィック制御とBGPコミュニティの使い方

Transcription

1 ISP のトラフィック制御と BGP コミュニティの使い方 BIGLOBE Inc. 川村聖一 1

2 はじめに :BIGLOBE のネットワーク 大阪 東京 San Jose Hong Kong Los Angeles Singapore POP vpop 総トラフィック 400Gbps 以上 Inbound Traffic が多い 2

3 はじめに :BIGLOBE のネットワーク JPIX EIE JPNAP JPIX BBIX JPNAP EIE BBIX 10G 10G 20G 10G 20G 20G 20G*2 20G Dojima3 OS1 Note (MF) Kote Dote TY4 TY2 CC1 BIGLOBE 大阪 BIGLOBE 東京 San Jose Los Angeles Hong Kong Singapore Upstream ISP は 3 つ AS2914 AS6453 AS1299 3

4 トラフィック制御の考え方 芯 : 事業に最適なトラフィック設計を行う 具体的に考慮する事 : ISP/MVNO 事業としてのコスト 遅延 ハウジング / ホスティングのコスト 遅延 資本関係やパートナーシップ やらない事 : 事業にそぐわない / 無視した設計 インターネット上の他社に迷惑をかけてしまう設計 4

5 対外接続設計 : 基本要素 IX 接続 プライベートピア (PNI) トランジット キャッシュ 入ってくるトラフィックを制御 出て行くトラフィックを制御 送信経路制御 POP1 POP2 受信経路制御 ISP ユーザ (inbound 多い ) Core DC ユーザ (outbound 多い ) BGP ユーザ 5

6 シンプルな実装 ( 昔の AS2518 の例 ) 難しいトラフィック制御は行わず 接続の種別に応じて送信経路を変更 受信した経路に Community を Tag IX 接続 プライベートピア (PNI) トランジット 受信経路に 2518:3000 を tag 受信経路に 2518:3000 を tag POP1 受信経路に 2518:3000 を tag ISP NW 内部経路に 2518:1000 を tag DC NW 顧客経路に 2518:2000 を tag BGP ユーザ 6

7 シンプルな実装 送信経路は Community 値で制御 Peer とトランジットには Peer から受けた経路を流さない法則を Community で守る IX 接続 IX と同じ プライベートピア (PNI) トランジット 2518: :2000 の経路を送信 POP1 IX と同じ ISP NW BGP ユーザと同じ DC NW 2518: : :3000 の経路を送信 BGP ユーザ 7

8 シンプルな実装 間違い防止のために Peer への経路送信 route policy Transit への送信 route policy をあらかじめ定義しておき それ以外はなるべく使わない IOS-XR の例 route-policy peer-export apply do-not-send-these 基本フィルター if community matches-any internal or community matches-any customer then set med 100 delete community in any done endif drop end-policy Peer の場合 コミュニティをつけて送っても意味が無い場合が多いので消す基本の drop 重要 すごくシンプル! 8

9 シンプルな実装 相手が Community をつけてきても Community で操作する事を許していない相手の送ってくるコミュニティは見なくてもいい AS2518 では Peer 毎にポリシーを作ってる IOS-XR の例 route-policy as65535-import apply do-not-receive-lists if as-path in as65535-aspath1 then set med 0 set local-preference 300 set community peer done endif end-policy 基本フィルター additive が付いて無いので community 値 2518:3000 で上書きする すごくシンプル! 9

10 シンプルな実装 フルルート送る設定も簡単! IOS-XR の例 route-policy full-out apply do-not-send-these if community matches-any internal or community matches-any customer or community matches-any external then set med 0 delete community in any done endif drop end-policy 例では全部 Community を削除しているが BGP Community 機能を提供する場合は 何を送信して良いか は定義した方が良い すごくシンプル! このシンプルな実装を元に Prefix filter でトラフィック制御をしていく 10

11 例えば Transit2 社のトラフィックバランス トランジット 1 は標準設定だけど トランジット 2 は in トラフィックを少し減らしたい場合 トランジット 1 トランジット 2 POP 代表的な手法 : 1) 一部送信経路にprependする (1-3 回程度 ) 2) トランジッターの提供するBGP Communityを使う # より細かい経路をトランジット 1 側に送信する事で減らす事もできますがこの構成ではあまりお勧めしません 11

12 1) の設定例 prefix-set transit2-prepend /24 end-set route-policy transit2-export apply do-not-send-these if community matches-any internal or community matches-any customer then set med 100 pass endif if community matches-any internal if destination in transit2-prepend then prepend as-path 2518 pass endif pass endif if community matches-any internal or community matches-any customer then delete community in as2518-any done endif drop end-policy 12

13 2) の設定例 prefix-set transit2-prepend /24 end-set route-policy transit2-export apply do-not-send-these if community matches-any internal or community matches-any customer then set med 100 pass endif if community matches-any internal if destination in transit2-prepend then set community 1299:5881 additive pass endif pass endif if community matches-any internal or community matches-any customer then delete community in as2518-any done endif drop end-policy ここが前ページと違う特定の ISP 向けは 1 回 prepend してからトランジット 2 は送信 13

14 トランジッターの BGP Community 利用 Tier1 は全事業者 Community 機能を提供している whois で公開している事業者 Web で公開している事業者 pdf などファイルで情報提供する事業者 fm 注意! RTBH 機能を使う場合 (65535:666) IPv4 は /32 単位で受けてもらう事が一般的だが基本フィルターで /24 よりも長い prefix はフィルターする設定になっている場合はコミュニティ値が付いている経路だけは /24 以上で経路広告できる設定にする必要がある Tier2 以下は対応が Tier1 に比べると対応機能が少ない 14

15 なぜ Tier1 は BGP Community が必要かの例 Tier1 は US での相互接続が多い ( 歴史的にも インターネットのトラフィック的にも ) BGP は近いところから出ようとする性質があるが 近いところが必ずしも最適とは限らない 細い! アジア接続 Tier1 US 接続 中国 ISP 輻輳の可能性 潤沢な帯域遠回りでもロスが少ない方を 私 世界規模でバックボーンを展開する Tier1 は様々な国で大規模通信事業者と接続している ベストパスが必ずしも最適な通信品質とは限らないため Community を使って局所的に発生している問題を改善する策を顧客から要求される可能性が高い 15

16 CDN トラフィックの考え方 CDN は バックボーンを持っていない ( 配信サーバ間が内部ネットワークで接続されていない ) 場合が多く 独特な考え方が必要 2 種類のメジャーなコンテンツ配送方式 Anycast 方式 DNS 方式 Anycast の場合 ゾーン間をつなぐネットワークが無く インターネット経由で通信する (2) トラフィック ( コンテンツ ) はここから戻る CDN ゾーン1 CDN ゾーン 2 CDN ゾーン 3 CDN ゾーン 4 (1) こっちにトラフィック ( コンテンツリクエスト ) を出すと ISP トランジット CDN キャッシュ 16

17 CDN トラフィックの考え方 Anycast トラフィックは前ページのとおり送信したところからトラフィックが戻ってくる しかし DNS ベースで CDN マッピングされてしまう場合は送信トラフィックを制御するだけでは効かない (2)CDN の判断で他ゾーンの IP を DNS で返されてしまう しかもゾーン間はつながっていないのでゾーン 1 からトラフィックは来ない DNS の場合 DNS マッピング CDN ゾーン 1 CDN ゾーン 2 CDN ゾーン 3 CDN ゾーン 4 トラフィックはこっちからきたり (1) こっちに来るように一生懸命調整しても (3) 結局こっちにリクエストが飛ぶ ISP トランジット CDN キャッシュ最悪こっちから来るものも 17

18 ISP でできる事 1) トラフィックが多い回線は 深く考えず増強する 難しい操作をせず増速で対応 これがベスト ( プライベートピアの場合 )CDNの多くは輻輳検知できるのであふれても品質劣化にはならない CDNは通信遅延を測定し 最もコストがかからずかつ近いところから出そうとする傾向があるのでそれに任せる ただしコストは重要ファクターなので必ず近いところ というわけではなさそう 2) やりたい事をCDN 会社に説明して協力をお願いする 多くの場合協力的な姿勢 3) トラフィックを減らしたい回線に対してPrependする MEDはほとんど効かない送信経路削減はよく考えて実施しないと通信断リスクがある 参考 : 18

19 こんな事できたら面白そうだけど 実際はできません (IX など共通リンクで Peer している場合 )BGP Community 値で何 Gbps 受けられるか通知できたり 何 Gbps まで流して大丈夫かを BGP Community で通知できたら 100Gbps CDN ISP 10Gbps IX 他 Peer こっちですでにある程度帯域が埋まっている場合突然のバーストで品質低下を防げるかも 19

20 Peer に対して提供する BGP Community BGP Community は今まで Transit が Customer に提供する機能 もしくは内部利用が一般的だった しかし DDoS 対策のために Peer 同士で Community を利用する事も議論は出てきている Peering Policy に記載している会社もある ( 厳密な要求ではない ) トラフィックの流れ方が変わってくると その調整方法や必要な技術も変わってくるため 動向には注視しておく必要がある 20

21 AS2518 の現在 : 内部で使っている BGP Community 海外の POP が増えたので地域識別を追加 どの国で拾った経路か識別したい トランジット顧客への情報共有手段 通信障害対応 ( やったことないけど ) リージョン毎のプリファレンス操作など トランジットサービスを始めたので顧客向け制御機能追加 特定の ISP や Transit へ経路を出さないコミュニティ 今後 prepend も追加予定 Black Hole Routing 機能 ( 内部向け 顧客向け ) は昔から 顧客向けに 2518:666 RFC 値に今後対応予定 21

22 今後検討するトラフィック制御手法 Large Communities (RFC7999) 対応 4byte-AS の Peer やトランジット顧客が増えてきたため急務 BGP Flowspec は実装や仕様で課題が多いが Blackhole でもなく Scrubbing(DDoS のインテリジェントな防御 ) の中間策にもなるため何とか導入したい 22

23 まとめ トラフィック制御の考え方は 事業によって異なる トラフィック制御が必要になった場合 BGP Community を使った制御は有効 Tier1 は多様な BGP Community 機能を提供している 使わないと困るケースもある CDN のトラフィックは通常の Peer と違う考え方が必要 BGP のトラフィック制御は今後も進化しそう 23