ISP バックボーンネットワークにおける経路制御設計 ~ 実践編 ~ NTTコミュニケーションズ ( 株 ) 吉田友哉 Copyright 2003 Tomoya Yoshida

ネットワークの経路制御設計! ネットワークを流れるトラフィックをどうさばくか! 必要な帯域をどうやって確保するのか! 各 POP のトラフィック地方の POP からのトラフィックは, 一番近い東京大阪のメイン POP にもってくる. 障害時は, あらかじめ設定してある迂回路にて救済そもそもどこが POP になるの? トラフィックの多い地域を POP として立ち上げていく! 国内 ISP とのトラフィック交換大きな ISP とは PrivatePeer を基本. 落ちたら IX を利用, もしくは Private 内で救済. 他の ISP は IX をメイン. 最後は海外トランジット! 海外トランジット均等に 2 つの上流をうまく使い分けるあるいは, コストの安い上流をメインとし, 切れた場合には他に回す! 2 重故障もある程度考慮にいれて設計する冗長をとっている 2 回線とも, という場合にはどうしようもないが, 例えば迂回したその先での故障などの場合 2003/12/2 Copyright 2003 Tomoya Yoshida 5

ネットワーク設計 ( 基本 )! 信頼性 ( 冗長性の確保 )! 装置, ノード, リンクレベルの冗長化, 負荷分散! ビルレベルでの分散! 光ファイバーの異経路分散! 同一サービスの搭載架の分散, 電源系統の分散! 品質! 必要な帯域をきちんと確保する! 装置単体, 装置間における品質の確保! 運用性! 容易にトラブル対応が可能な, 物理的, 論理的にシンプルな構成! 多段構成,HOP 数の削減 " 今はルータの性能も上がってきたので, HOP 数はそれほど影響しない. ナノミリ sec オーダ?! 将来性拡張性! 新サービス, 新たな POP に対応可能なネットワーク 2003/12/2 Copyright 2003 Tomoya Yoshida 7

ネットワークの規模階層的構造! 中規模大規模な ISP ネットワーク! 物理ネットワーク外部から複数の上流経路を受信し, 国内のピアも十数以上 GW は複数台, それぞれ ebgp 接続を複数本主要な地域は POP になっている CORE ルータや境界ルータは基本は 2 重化構成! 論理ネットワーク IGP は OSPF メイン,EGP は BGP 内部の Topology 管理は OSPF, 経路情報の管理は BGP(OSPF)! 階層的構造に沿ったルーティングの設計! AS 間 [ebgp] inter-as! AS 内 [OSPF/iBGP] 外部接続部 (GW) バックボーン intra-as 中継アクセス部! エンドユーザ [static/rip/ebgp] End-user 2003/12/2 Copyright 2003 Tomoya Yoshida 8

トポロジー情報経路情報! トポロジー情報 ( ネットワークの地図 )! バックボーン全体のリンクのつながりを表す情報! OSPF のリンクステートデータベース ( トポロジカルデータベース ) に格納 OSPF では隣接と LSA を交換し, それに基づいてトポロジカルデータベースを作成する! 経路情報! ユーザの経路情報 PA アドレス, 上流 ISP からの経路情報 ( フルルート / トランジット経路 )! 基本は BGP により交換! 以下の場合には OSPF が有効ユーザ経路を簡単にロードバランスさせたい場合実際に BGP を動かしていないルータから上位に経路情報を渡したい場合 2003/12/2 Copyright 2003 Tomoya Yoshida 10

アドレス設計! IP アドレスの設計は! ネットワークの規模が増せば, よりルーティングネットワークに影響を与える! なるべく経路は集成可能なように設計する各 POPやABRで集成 ( 例 :area-range, summary-address) ユーザブロックの割り当てプールは連続した割り当てに! とはいっても, 豊富に最初からブロックを確保できないのも事実. 現実はけっこう厳しいかも (JPNIC おかわり問題?) ちぎって割り当てをせざるをえない! できる範囲内でうまく " 最近はそれほど経路が細かくなっても, ルータ自体の負荷はあまりきにしなくてもよいだろうネットワークの規模が大きくなれば, ルーティングに影響を与えるが, そもそもそのぐらいの大きなネットワークであれば, アドレスもあらかじめある程度豊富に確保可能なはず " 規模相応にうまく割り当てが可能となるだろう逆に規模が小さければ, それほど経路も爆発的に増えることもないので, 気にしないでも大丈夫 2003/12/2 Copyright 2003 Tomoya Yoshida 11

アドレス設計! 例えば以下ように分類し, それぞれある程度まとめてアドレスブロックを確保しておく (1) バックボーンアドレス LB アドレス P2P アドレス,POP 間アドレスバックボーン SW セグメントブロック (2) ユーザアドレスユーザが実際に利用するブロック (3) 外部アドレス GW などで外部と接続する部分のアドレス ( 実際には (2) に含める )! セキュリティーの観点! Telnet などのリモートアクセス範囲の明確化! 経路広告の範囲の明確化 (DOS など ) 2003/12/2 Copyright 2003 Tomoya Yoshida 12

アドレス設計分類用途割り当て外部への広告 Telnet アクセス (1) バックボーンアドレスループバックアドレス /32 スイッチセグメント /27/26 等 point-to-point /30 POP 間 /POP 内セグメント /30 等不要広告許可 (2) ユーザアドレスダイヤルアッププール /24 等 DSL 用プール /24 等常時接続 / ハウジング /29/28 /24 等必要拒否 (3) 外部アドレスプライベートピア IX 接続上流 ISP 接続 ( 自ネットワークから相手に /30 払い出す場合には, ユーザアドレスに含める ) 不要広告拒否ルーティングに必要無いが, 外部からの疎通確認などで実際には広報する, またちゃんとアドレスブロックがまとまっていない場合には, 経路広報が細切れになってしまうので, 実際にはそこまで細かく分けずに広告するのが一般的. 範囲の明確化自体は必要 2003/12/2 Copyright 2003 Tomoya Yoshida 13

N+1 設計! 実際に流れている帯域に,+1 の回線本数を用意する! N=1 の場合には,1+1 = 2 本で冗長化! N=2 の場合には,2+1 = 3 本で冗長化!... ISP-A ISP-A 600M 600M 600M 700M N=2 N=4 1 8G 3 5G ISP-B ISP-B 100% 救済を考えると,2GE のトラフィックに対して,3GE(1.5 倍 ) の容量を確保する必要がある 100% 救済を考えると,4GE のトラフィックに対して,5GE(1.25 倍 ) の容量を確保する必要があるトラフィック量が増加するにつれて, 回線の有効利用が見込める 2003/12/2 Copyright 2003 Tomoya Yoshida 14

N+1 設計 GE 増設による 100% 救済設計例必要帯域 (G) 10 9 8 7 6 5 4 3 2 1 メリット : 実トラフィック量が増えるほど, 効率的に回線が利用できるデメリット : 増設ポイントが多いため, その都度増設設計が必要 0 1 2 3 4 5 6 7 8 9 10 実トラフィック量 (G) 2003/12/2 Copyright 2003 Tomoya Yoshida 15

N+1 設計! 需要予測! 過去から現在までのトラフィック量の伸びのデータをもとに, 将来の需要を予測し, プロットした結果を線で結んでみる! その上で, どの時期までにどのぐらいの帯域を必要とするかを判断! 実際に回線やファイバーを調達する時間を見込んで, 最終的にいつまでに増設の判断をして行動に移さなければならないのか, あるいはメディアの変更を考えるべきなのか (GE " 10GE) の決断をする GE を 6 本束ねるようになったら,Operation やルータの収容分散自体も厳しい " 10GE にすべき? でも, 用意するなら 10GE x 2 これは厳しい OC48 x 4 なら 7.2G まで OK か 2003/12/2 Copyright 2003 Tomoya Yoshida 19

N+N+1 設計! N+1 に加えて, 他の接続形態 (M) を含めた冗長性の確保! N=1,M=1 N+M =1+1+1=3! N=2,M=1 N+M =2+1+1=4! 例えばPrivateピア (N) のバックアップにIX(M) を利用 " バックアップ (M) を他のISPと共用させることが可能 " N+1で100% 救済が確保できない場合などに利用できる " とはいっても, 現実的には IX の回線って浮かしておく余裕はないかも ISP-A ISP-A N+1 M ISP-B N+1 M ISP-C それぞれ +1 本用意する必要がないので, 合計 7 本で済む 2003/12/2 Copyright 2003 Tomoya Yoshida 20

CPU メモリ! あればあるに越したことはない! 256M と 512M ではだいぶ異なる! どのぐらい必要なのかは, 自分のネットワーク環境に近い検証環境をつくってテストする! ルーティングエンジンの性能アップで, より効率化されるかも! OSPFやBGPの経路数を実網と同じ値, あるいは数年先の状態まで考慮してテストする 2003/12/2 Copyright 2003 Tomoya Yoshida 21

OSPF BGP メモリ消費量 ( 例 ) 経路数別メモリ消費量 80,000,000 メモリ消費量 ( 単位 : バイト ) 70,000,000 60,000,000 50,000,000 40,000,000 30,000,000 20,000,000 10,000,000 0 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 経路数 18,000 20,000 22,000 24,000 26,000 28,000 30,000 OS や機種によっても, 消費量は異なるので, それぞれの組み合わせで自分にあった環境で検証する必要がある OSPF BGP 2003/12/2 Copyright 2003 Tomoya Yoshida 22

Loopback! 装置自体が落ちない限りは生きている仮想インターフェース! 通常は /32! 全ルータに付与するのが望ましい! OSPF や BGP では特に重要になってくる! OSPF のルータ ID ID が変わってしまうと,LSA の交換を再度やり直し " これは非常にまずい! BGP のピアは loopback ではるのが基本インターフェースでピアをはると, たとえ回線を冗長していても, そのインターフェースが落ちると即 BGP ピアも断になってしまう! ebgp から受信した経路の next-hop にも利用! ルータへの各種アクセス制御で利用するのが一般的! telnet access! snmp access (MIB,Trap) 2003/12/2 Copyright 2003 Tomoya Yoshida 23

論理網と物理網! ルーティングトポロジーと論理トポロジーの構造は一緒にしておくのが望ましいだろう! トラブル時における対応が容易になるこのルータが落ちれば, 論理的にも落ちる! 極端に異なっていると, 運用自体が複雑に BGP ピアルータ E 行きは問題ないこの場合には, どういう風に経路が流れるんだっけなどルータ A ルータ C BGP ピアルータ F ルータ B ルータ D 帰りがピンポンルータ G ルータ E から下部の経路を BGP ピアにより受信しているルータ C は,OSPF の Default に従ってルーティングしているため, 上位に投げ返してしまう " ピンポン発生ルータ E は, ルータ A とルータ B に BGP で経路配信をしている. 上位向けは OSPF のデフォルト 2003/12/2 Copyright 2003 Tomoya Yoshida 24

OSPF の動き ( おさらい )! OSPF の動き ( 流れ )! リンクステートパケットを隣接ルータ間で交換! それをもとに,LDSB( トポロジカルデータベース ) を各ルータが作成! そのデータベースから, ダイクストラの SPF アルゴリズム ( ダイクストラ法 ) を用いて, 自分を頂点とした最短パスツリーを作成! そのツリーをもとに, ルーティングテーブルを作成! 自分を頂点としたリンクステート ( トポロジカル ) データベースを, それぞれのルータがもっているので, ある個所で障害が発生しても, あらかじめ保持してる LSDB からすぐにそれぞれのルータが再計算可能. 収束も非常にはやい! RIP などは, ルーティングテーブルのアップデートを,30 秒ごとに隣接へ伝達しているので, その点 OSPF は非常に高速化されている 2003/12/2 Copyright 2003 Tomoya Yoshida 26

エリア設計! まずは, エリア 0( バックボーンエリア ) を中心に考える! どこをエリア 0 にすればよいのか? 鉄道を例に考えると, 新幹線の走っている主要な駅をエリア0 それ以外の, ローカルな路線エリア ( 京葉線や中央本線など ) は, エリア 0にぶらさがる各エリアとするエリア0 以外のエリアは, 全てエリア0を介して接続するこになるエリア0に各エリアがぶら下がるようなスター型の構成になるネットワークのコアとなる部分がエリア0となる! むやみにエリアは増やさない! エリア 0 はどんどん肥大化していくので注意が必要! 1 エリアには ABR( エリア境界ルータ ) は 2 台 ( 以上 )! ABR が落ちると, そのエリアが全滅 2003/12/2 Copyright 2003 Tomoya Yoshida 27

エリア設計広島エリア大阪エリア仙台エリア北海道エリアエリア 70 エリア 20 エリア 30 エリア 40 ABR ABR ABR ABR ABR ABR ABR ABR CORE CORE CORE CORE CORE CORE CORE バックボーンエリア ( エリア 0) CORE ABR ABR ABR ABR ABR ABR ABR ABR エリア 80 エリア 50 エリア 11 エリア 10 福岡エリア名古屋エリア東京 2 エリア東京 1 エリア 2003/12/2 Copyright 2003 Tomoya Yoshida 28

エリア設計西国際 1 東国内 2 東国際 2 Area 40 Area 70 広島福岡 Area 80 ABR ABR ABR ABR 西国内 1 CORE CORE 大阪 2 大阪 1 CORE CORE Area 0 ABR ABR 名古屋 CORE CORE Area 50 東京 2 CORE 東京 1 CORE ABR 北海道 ABR ABR ABR 仙台東国内 1 東国際 1 Area 30 エリア 0 の中さらに細かいエリアはここでは省略 2003/12/2 Copyright 2003 Tomoya Yoshida 29

1 つのエリアに置けるルータの台数! 一概には言えません ( ほとんど決まり文句 )! ネットワークの Topology やリンクの数などにかなり左右される! 数十台程度なら, 大抵 1 エリアでおさまるだろう ( 経験上 ) ただ, これもあくまで一般論で, それぞれ事情は違う! OSPF の収束時間が以前に比べて長いなぁそろそろエリアを分割, あるいはエリア 0 の台数を減らすか! ルータの性能は侮れない処理能力の高いルータと, そうではない非力なルータとでは, 随分と差がある! 参考書や文献 ( でもあくまで指標にすぎない, 実は結構古い ) Halabi:50 台までだろう.60 台や 70 台は避けるべき Moy:1991 年に多くて 200 台といったが, ベンダによっては,350 台というところもあるし,50 台やそれ以下というところもある! 実際には, 色々動かしながら試行錯誤! エリア 0 は肥大するので注意 2003/12/2 Copyright 2003 Tomoya Yoshida 30

リンクの数! point-to-point と SW セグメントをバランスよく! むやみに point-to-point のフルメッシュなどを増やすと,LSDB が増大してしまう可能性があるそのルータにはどのようなリンクがつながっているのか 1つのルータに属する同一エリアのリンク数が多いと,1つのRouter- LSAパケットに含まれるリンクの数が多くなり, 肥大化! SW セグメントについては,DR が Network-LSA 生成ネットワークには, どのルータがつながっているかパケットフォーマットが単純で,DRがそのネットワーク内でneighborとなる各ルータをattachしていくだけ 2003/12/2 Copyright 2003 Tomoya Yoshida 31

OSPF パケットの種類にどのようなリンクが接続されているかにどのようなルータが接続されているか Link Type1 P2P OSPF TYPE1 Hello パケット LS TYPE1 Router-LSA Link Type2 Transit Network OSPF TYPE2 DD パケット LS TYPE2 Network-LSA Link Type3 Stub Network OSPF TYPE3 LSR パケット LS TYPE3 Summary-LSA IP Network Link Type4 Virtual Link OSPF TYPE4 LSU パケット LS TYPE5 AS-external-LSA LS TYPE3 Summary-LSA ASBR OSPF TYPE5 LSA パケット LS TYPE7 NSSA 2003/12/2 Copyright 2003 Tomoya Yoshida 32

DR/BDR の設計! DR/BDR は, 処理能力の高いルータ, もしくはそれほど仕事をしていないルータにやらせる! 絶対に DR/BDR にしたくないルータは,Priority をはじめから 0 にセットしておく DR/BDR がない場合 DR/BDR がある場合 DR(Priority:5) BDR(Priority:4) ルータ A ルータ B ルータ A ルータ B ルータ C ルータ D ルータ E ルータ C ルータ D ルータ E (DROTHER) (DROTHER) (DROTHER) Cisco の場合には,priority = 1 がデフォルト Priority が低くても, 最初に立ち上がったものが DR になってしまうので注意 2003/12/2 Copyright 2003 Tomoya Yoshida 33

DR/BDR の設計 SW1とSW2で,2 重化の冗長構成をとっている場合 " DRやBDRをそれぞれのセグメントで分けて付与したい " SW1のセグメントでは, ルータAをDR " SW2のセグメントでは, ルータBをDR DR( 実線 ) DR( 点線 ) ルータ A ルータ B SW1 SW2 ルータ C ルータ D ルータ E 2003/12/2 Copyright 2003 Tomoya Yoshida 34

ルータの故障で DR は重なる矢印は削りました DR(Priority:5) BDR(Priority:4) BDR(Priority:4) DR(Priority:5) ルータA ルータB ルータC ルータD ルータE 設計上は,Priority をセグメント毎に分けてあるので,DR は分散されているルータA ルータB ルータC ルータD ルータE (Priority:3) (Priority:2) (Priority:1) (Priority:1) (Priority:2) (Priority:3) DR(Priority:5) BDR(Priority:4) ルータ A ルータ B BDR(Priority:4) ルータ A DR(Priority:5) ルータ B ルータ C ルータ D ルータ E ルータ C ルータ D ルータ E (Priority:3) (Priority:2) (Priority:1) (Priority:1) (Priority:2) (Priority:3) (Priority:5) DR(Priority:4) 同一ルータが DR になっている! (Priority:4) DR(Priority:5) ルータ A ルータ B ルータ A ルータ B ルータ C ルータ D ルータ E BDR(Priority:3)(Priority:2) (Priority:1) DR ルータが故障すると対象セグメントの通信が一定時間断になってしまう! ルータ C (Priority:1) ルータ D ルータ E (Priority:2) BDR(Priority:3) 2003/12/2 Copyright 2003 Tomoya Yoshida 35

コスト設計! ネットワークの設計ポリシーが前提 ( 物理トポロジーを含めた )! どのリンクを普段メインで使うのか! イコールコストマルチパスにするのか,1/0 にするのか! あるリンクが落ちた場合には, どこで救済させるのか POPが全断することを想定して, 違うPOPで救済させる? あらゆるパターンを想定して考えなければならない! メイン回線を小さく, バックアップをそれよりも大きな値で! あまりにも値かけ離れていると, ぐるっと回ってしまう! 値は多少余裕のある設計にしておく緊急避難で, 一時的に迂回させるどうしようもない場合に, 微妙に調整した場合! ネットワークのトポロジーが複雑だと, 非常に難しくなるので, シンプルな構成で, シンプルなコスト設計が望ましい! ある程度体系的なポリシーを決めておく! 当てはまらない場合には微調整渡り接続回線 : 5 メインの回線 : 10 バックアップの回線 : 20 2003/12/2 Copyright 2003 Tomoya Yoshida 36

コスト設計渡りが 5, メインが 10, バックアップが 20 西国際 1 東国内 2 東国際 2 メイン 20 20 広島福岡 10 10 バックアップ 10 10 大阪 2 大阪 1 10 10 10 10 名古屋東京 2 5 5 渡り 5 5 東京 1 10 10 10 10 10 10 10 10 北海道 20 20 仙台東国内 1 東国際 1 西国内 1 2003/12/2 Copyright 2003 Tomoya Yoshida 37

コスト設計北海道から福岡への通信 " 東京大阪のスクエア部分は異経路分散, 大阪 1から福岡へ東国内 2 西国際 1 東国際 2 20 20 広島福岡 10 10 10 10 大阪 2 5 5 大阪 1 10 10 10 10 名古屋東京 2 5 5 東京 1 10 10 10 10 10 10 10 10 北海道 20 20 仙台東国内 1 東国際 1 西国内 1 2003/12/2 Copyright 2003 Tomoya Yoshida 38

コスト設計東京 1 と東京 2 のリンクがきれた場合 " 全て大阪 2 経由西国際 1 東国内 2 東国際 2 20 20 広島福岡 10 10 10 10 大阪 2 5 5 大阪 1 10 10 10 10 10 10 名古屋東京 2 5 5 東京 1 10 10 10 10 10 10 北海道 20 20 仙台東国内 1 東国際 1 西国内 1 2003/12/2 Copyright 2003 Tomoya Yoshida 39

コスト設計このとき, 北海道と仙台のリンクが細い場合などは, 名古屋や西国内へは大阪 1 経由, 東京 1 や東の国内, 国際は仙台経由 20 20 広島福岡 10 10 10 10 西国内 1 西国際 1 大阪 2 5 5 大阪 1 10 10 10 10 10 10 名古屋東国内 2 東国際 2 東京 2 東京 1 北海道仙台 2003/12/2 Copyright 2003 Tomoya Yoshida 40 5 5 10 10 10 10 10 10 20 20 東国内 1 東国際 1 これを 8 などにすると, 名古屋行きのトラフィックも東京 1 経由 8

コスト設計大阪 1 が崩壊 " 大阪 2 から広島経由で福岡へ西国際 1 東国内 2 東国際 2 20 20 広島福岡 10 10 10 10 大阪 2 5 5 大阪 1 10 10 10 10 名古屋東京 2 5 5 東京 1 10 10 10 10 10 10 10 10 北海道 20 20 仙台東国内 1 東国際 1 西国内 1 2003/12/2 Copyright 2003 Tomoya Yoshida 41

コスト設計 ( まとめ )! ポリシー決め! 物理構成とトラフィックに基づいて, どこがきれたらどう迂回させるのか! 用意できる回線や帯域に依存してしまう場合もあるが! あまり複雑な設計はしない! オペレーションしやすい設計は大切! ある場所が故障した際に, あまりに複雑な救済経路にしない! 行きと帰りは基本は一緒にする ( 運用性 ) わざと行きと帰りの経路をわける場合もあるが! 思わぬ事態が! 設計どおりに実際いかない場合がある故障時に, 想定していたパスとは違うパスに流れ込んでしまったその都度見直し 2003/12/2 Copyright 2003 Tomoya Yoshida 42

OSPF の内部経路外部経路! 内部経路 (Internal 経路 )! OSPF のトポロジーデータベースを構築し, それをもとに経路計算を実施する! 全てがネットワークの地図 ( トポロジー情報 ) 把握することになる為, 多くなればなるほど再計算をする際にルータの収束に影響を与える! 外部経路 (External 経路 )! Internal 経路のように, 複雑な経路計算は出来ない! ただし, 経路に変化があった際にも,OSPFデータベースの再計算を行わないため, 負荷は軽い 2003/12/2 Copyright 2003 Tomoya Yoshida 43

OSPF 内部経路 ASBR から上位は, トポロジーの冗長構成をとるため Internal 経路である事が必須 ABR ABR Cisco の場合 router ospf 2003 area 0 authentication area 101 authentication network 172.16.32.10 0.0.0.3 area 0 network 172.16.32.14 0.0.0.3 area 0 network 10.0.255.129 0.0.0.0 area 101 network 10.101.1.64 0.0.0.15 area 101 network 10.101.1.80 0.0.0.15 area 101 内部経路 RT RT エリア 101 Juniper の場合 protocols { ospf { area 0.0.0.0 { interface so-0/1/0.0; interface so-1/1/0.0; } area 0.0.0.101 { interface lo0.0; interface so-2/1/0.0; interface so-2/2/0.0; } } } ASBR ASBR ASBR ユーザルータユーザルータ加入者収容ルータユーザルータ 2003/12/2 Copyright 2003 Tomoya Yoshida 44

OSPF 外部経路 Cisco の場合 router ospf 2003 redistribute connected subnets route-map c-to-ospf redistribute static subnets route-map s-to-ospf ip route a.a.a.a b.b.b.b c.c.c.c access-list 80 permit 10.0.0.32 0.0.0.3 ABR ABR route-map s-to-ospf permit 10 set metric 1 set metric-type type-1 RT RT エリア 101 route-map c-to-ospf permit 10 match ip address 80 set metric-type type-1 ASBR ASBR ASBR ASBR 下部 (1 重化, で /30) は,connected 経路を上位に再配信すれば OK Network コマンド + passive " Internal 外部経路ユーザルータユーザルータ加入者収容ルータユーザルータ下部 ( ユーザアドレス ) は static 経路を生成し, それを OSPF External にて配信 2003/12/2 Copyright 2003 Tomoya Yoshida 45 ユーザルータ

OSPF のデフォルトルートの広告デフォルトルートの広告とはフルルートを保有していないルータが, フルルートを保有しているルータにルーティングできるように設定するものパケット破棄能力にすぐれた CORE ルータ等から配信するのが望ましい " 宛先のない経路に対してのパケットは全てデフォルトに向かってくる! BGP のフルルートなどが必要ない部分は, デフォルトルートを活用すべし Cisco の場合 router ospf 2003 default information originate always metric-type 1 metric 5 エリア0 CORE CORE 0.0.0.0/0 AS2003 2003/12/2 Copyright 2003 Tomoya Yoshida 46

OSPF のデフォルトルートの広告 Juniper の場合 protocols { ospf { export DEFAULT-ORIGINATE; } } policy-options { policy-statement DEFAULT-ORIGINATE { term 1 { from { protocol static; route-filter 0.0.0.0/0 exact; } then { metric 5; external { type 1; } accept; } } term 999 { then reject; } } } routing-options { static { route 0.0.0.0/0 discard; } } Protocol,OSPF の部分で, 何を export するのかを定義する. ここでは, DEFAULT- ORIGINATE DEFAULT-ORIGINATE の中身を定義 protocol が static で 0.0.0.0/0 に exact match した場合のみ metric 5,external type-1 で広告それ以外は,reject Static route の生成 " discard = null0 2003/12/2 Copyright 2003 Tomoya Yoshida 47

OSPF の安定性! どの程度の規模まで現状のまま耐えられるか?! ルータの機器, メモリ量,CPU, ネットワークのトポロジーなど, 色々な要素があるので, ケースバイケースというのが正直なところ! 検証をするにしても, 何十台もルータをかき集めて同じ環境を作ってやるのは不可能! ある程度経験則を頼りに設計し, 実網を監視していくしかない! 参考ドキュメント OSPF Anatom of an Internet Routing Protocol J. Moy (January 1998) RFC 著者 OSPF DESIGN GUIDE Bassam Halabi (April 1996) インターネットルーティングアーキテクチャーの著者 2003/12/2 Copyright 2003 Tomoya Yoshida 48

OSPF の安定性! LinkState パケット交換で負荷がけっこうかかる! neighbor が確立されるのに時間がかかる! show ip ospf neighbor で見ても,DR と BDR に対して,Status がしばらく full にならない! 何故か不安定な事象がおこっている! Dead timer 値が 30 秒をかなり下回っていることが多い 10 秒ごとに HELLO をなげているので, 落ちているということになる ( 別の原因かもしれない )! バグっていう事もよくある! 疑問に思ったら, ベンダやメーカに問い合わせをしましょう! 普段からの確認! MIB による,OSPF の再計算の回数測定! MRTG へのグラフ化 2003/12/2 Copyright 2003 Tomoya Yoshida 49

危ないと感じたら! 機器の性能をUpgradeしてみる! バージョンアップやメモリ増設で, 劇的に改善される場合もある! なるべく, メモリをつんでおくのは悪いことではない! 1エリアの台数を削減したり, リンクを減らす " LSDBの縮小化! 一定の性能のルータを並べている場合には,1 台の大容量なルータに集約してしまう and 帯域を太くしてまとめて行く ( 序所に )! 他の方式を検討! むやみにOSPFにのっけている人は,BGP 化する " static-to-bgp! その他 Confederation IS-IS 化 OSPFのプロセスを分ける 2003/12/2 Copyright 2003 Tomoya Yoshida 50

その他! エリアの表記! エリア 0 に関しては,0 と表記すれば, 自動的に 0.0.0.0 と解釈されるが, エリア 1 と書くと, ベンダによっては, Area 0.0.0.1( ベンダA) Area 1.0.0.0( ベンダB) の 2 通りの解釈があるので, ちゃんとエリア 0.0.0.1 と書くのがよい! ABR で,loopback はどっちのエリアに属したらよいの?! エリアの中にいれておくのがいいでしょうエリア 0 の孤立時に, 通信断になってしまう 2003/12/2 Copyright 2003 Tomoya Yoshida 51

OSPF 設計まとめ! エリア設計! Area0 を中心に設計し, 序所に拡大していく! 1 エリアに配置する ABR( エリア境界ルータ ) は,2 台がよいでしょう! 1エリアに何台置けるかは, 一概には言えないルータの性能やそれぞれのネットワークにおける挙動は異なる CPUが落ち着くまでの時間が肥大していくようなら, 台数を減らしたほうがよいだろう! リンク数! メモリ! あまりむやみに増やすような設計はさけたい! point-to-point と SW セグメントをバランスよく! BGP の経路数の約 2 倍は消費するので, 普段から注意が必要! DR/BDR! DR ルータは, かなりの負荷がかかるので, そのセグメントにおいて処理の少ないルータや, 処理能力の高いルータにやらせるのが基本! SWセグメントでは, 同一ルータが, 同じ冗長構成をとっている別 SWセグメントのDRを兼任してしまわないように設計する Priority 設計運用での修正 (DRがかさなった場合には,interfaceの開閉で対応可能) 2003/12/2 Copyright 2003 Tomoya Yoshida 52

OSPF 設計まとめ! コスト設計! 迂回路も含め, どのようにトラフィックをさばくのか, まずはポリシーをしっかりと決めることが大前提! あまり複雑な値や経路にはしない! 基本は, 行きと帰りの経路を一緒にして, 運用やトラブル時の対応をなるべく簡易にするのが望ましい! 経路 / 経路数! なるべくエリアごとに経路が集成できるようなアドレス設計! External 経路でも, それなりに数が多くなってくると不安定要因となるので注意! デフォルトルート! デフォルトルートで用が足りる部分は, うまく活用しましょう! パケット破棄に強いルータを選定しましょう! 何かおかしいと思ったら! 機器の Upgrade を検討! メーカやベンダへ問い合わせる! 他の方式を検討するのも価値がある! 運用! 日頃から,MIB などを用いて観測しておく ( 経路数なども ) 2003/12/2 Copyright 2003 Tomoya Yoshida 53

BGP 設計! AS 内,AS 間において, どのようなポリシーで, いかに最適に, スケーラブルに BGP 経路を配信させるか! 外部 AS から何の経路を受信するのか. どのような優先性を与えるのか受信ポリシー! どのピア先に対して, 何の経路を, どのように広告するのか広告ポリシー! 自 AS 内経路は, どうやって配信するのか! 外部から受信した経路は AS 内部にどのように伝播させるのか ibgp をフルメッシュにはるのか? リフレクタの階層構造を用いるのか?! AS 内全体に一律配るのではないとすると, じゃぁどこに対して何を配信したらいいのか? COREやGWの必要保有経路は?ABRはフルルート必要? BGPユーザの階層では? 非 BGPユーザの階層では? 2003/12/2 Copyright 2003 Tomoya Yoshida 55

BGP ポリシー設計! 受信ポリシー! 相手から経路を受信する際に, 何の経路をどのように受信するのか複数の上流をどう使い分けるか国内のピアはどういったポリシーで制御させるのかプライベートを優先?IXと同じ位置付けにする? 複数回線で接続されていた場合には? 切れた場合にはどこで救済? 東西の制御方法は? どういったパスアトリビュートを付与して経路制御をするか! 不必要な経路を広告されてきた場合にはどうする?( 全体のポリシー ) GWでFilterをかける? Filterするにはちょっと負荷が気になるので, 受信したとしても, 該当経路を優先させないように内部で制御をかける?! 広告ポリシー! 自分の経路や BGP 顧客などの経路を配信する際に, 何の経路をどういう重み付けで, どういうパスアトリビュートを用いて広告するのかあまり常時使用したくないリンクに対しては,Prependをかませる? Prefixを分けて, 回線ごとにトラフィックをさばく? 2003/12/2 Copyright 2003 Tomoya Yoshida 56

BGP ポリシー設計 ( 受信 ) 以下の接続形態を考える BGP 顧客経路自 AS 内広報経路プライベートピア経路商用 IXピア経路学術 IXピア経路上流フルルート1 上流フルルート2 基本は, 接続形態に対して, LOCAL_PREF 属性を適用し, それでは強すぎる場合には,MED 属性を用い, この2つを組み合わせて制御する値づけはバッファをもって設計する必要あり ( ルートマップのinstance 番号や OSPFのコスト値などと同じ ) " 新しい接続形態が増えた場合 " 値を整理したい場合 route-map ebgp-out permit 10 match as-path 3 set metric 100 route-map ebgp-out permit 11 match as-path 4 set metric 200... 途中にdenyのroute-mapを挿入したい場合に, 数字を書き直さないと駄目 2003/12/2 Copyright 2003 Tomoya Yoshida 59

BGP ポリシー設計 ( 受信 ) 接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 110 120 3 商用 IXピア経路 300 200 210 220 4 学術 IXピア経路 300 300 310 320 5 上流フルルート1 200 6 上流フルルート2 200 6 " 数字には余裕をもって設計 " ここでの優先順位とは, 単純に LOCAL_PREF の値を元とした順位 2003/12/2 Copyright 2003 Tomoya Yoshida 60

BGP ポリシー設計 ( 受信 ) ポイント 1: BGP 顧客経路は, まず最優先に設定する接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 110 120 3 商用 IXピア経路 300 200 210 220 4 学術 IXピア経路 300 300 310 320 5 上流フルルート1 200 6 上流フルルート2 200 6 " 顧客経路は他の ISP などにちゃんと広報する必要がある " もしその顧客が他の ISP とマルチホーム接続をしていれば, ピア経路としても聞こえてくる場合がある " その際, 仮にピア経由を優先してしまうと, 自 AS 内でベストパスではなくなるため, 経路がアナウンスされなくなってしまう! ピア先自 AS 2003/12/2 Copyright 2003 Tomoya Yoshida 61 優先ピア先顧客出ない非優先

BGP ポリシー設計 ( 受信 ) ポイント 2: BGP 顧客の次に, 自 AS 内広報経路は優先させる接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 110 120 3 商用 IX ピア経路 300 200 210 220 4 学術 IX ピア経路 300 300 310 320 5 上流フルルート 1 200 6 上流フルルート 2 200 6 " 自 AS 内経路が, 仮に他から流れてきた場合を想定して, ちゃんと優先させておく必要がある ( エッジで Filter する手法も勿論ある ) " BGP 顧客よりも優先度が低いので, 顧客から自 AS の経路が流れてきた場合を想定する必要がある. これは, 顧客のエッジでフィルタをかけるなどの対応をして防ぐ必要がある ( 顧客経路しか受け取らない ) " もしも 500 にした場合には, 制御方法によっては不具合が生じる 2003/12/2 Copyright 2003 Tomoya Yoshida 62

BGP ポリシー設計 ( 受信 ) 経路広告インターネット Prefix AS_PATH 172.16.0.0/16 i 不具合 Prefix LOPRE AS_PATH 172.16.0.0/16 500 i 172.16.0.0/16 500 65000 i AS_PATH の短い, 自 AS から広報した経路がベストパス! ベスト自 AS 500 BGP-to-OSPF が停止 500 自 AS から配信する IGP 経路がなくなる解決顧客 (AS65000) Prefix AS_PATH 172.16.0.0/16 65000 i 顧客経路が常にベストとなる " 安定 Prefix LOPRE AS_PATH 172.16.0.0/16 400 i 172.16.0.0/16 500 65000 i ベスト自 AS からの配信が停止顧客経路が復活し, ベストに選択 BGP-to-OSPF が再開,IGP 経路が生成その IGP 経路をもとに自 AS 経路が復活 2003/12/2 Copyright 2003 Tomoya Yoshida 63

BGP ポリシー設計 ( 受信 ) ポイント 3-1: ピア経路は,LOPRE を統一し,MED で勝負させる接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 110 120 3 商用 IX ピア経路 300 200 210 220 4 学術 IX ピア経路 300 300 310 320 5 上流フルルート 1 200 6 上流フルルート 2 200 6 " ピア経由の経路は, 基本は AS_PATH による制御 " 異なる AS 間では MED 比較の対象ではないので,ID 勝負などになる場合もある " プライベートピアを優先されるように,LOPRE を高く設定する場合もある ( 例 )LOPRE350 2003/12/2 Copyright 2003 Tomoya Yoshida 64

BGP ポリシー設計 ( 受信 ) Prefix AS_PATH 172.16.0.0/16 2 1 i 自 AS Prefix AS_PATH 172.16.0.0/16 3 1 i どっちに流れるんだ? IX Peer (LP300,MED200) AS2? 172.16.0.0/16 AS1 Private Peer (LP300,MED100) AS3 それぞれのASを収容するルータもしくは上位とのIBGP 部分で,Router-ID 勝負に? なったり, あるいは, 先に受信したASの経路が優先されるなど, まちまちになる Prefix AS_PATH 172.16.0.0/16 2 1 i 自 AS Prefix AS_PATH 172.16.0.0/16 3 1 i ベスト IX Peer (LP300,MED200) AS2 AS3 AS1 172.16.0.0/16 Private Peer (LP350,MED100) LOPRE が 350 の Private が常にベスト LOPRE は,AS_PATH よりも強いので注意! 2003/12/2 Copyright 2003 Tomoya Yoshida 65

直接ピアをしているのにトラフィックが流れない例 AS2001 200.100.0.0/16 transit AS2002 は顧客である AS2001 の経路も AS2003 に広報する Public Peer 直接ピアをしているにも関わらず, 全くトラフィックが流れない IX AS2002 Private Peer AS2003 Local Preferenceを 150 に設定 AS2003での経路の見え方 Prefix AS Path LP 200.100.0.0/16 2001 150 > 200.100.0.0/16 2002 2001 200 ベストパス Local Preference を 200 に設定 BGP を使った経路情報の流れ実際の IP トラヒックの流れ 2003/12/2 Copyright 2003 Tomoya Yoshida 66

IX などで Policy をまとめた Config 例 Cisco の例 router bgp 2003 neighbor IX1-Main peer-group neighbor IX1-Main next-hop-self neighbor IX1-Main route-map ix1-main-out neighbor IX1-Backup peer-group neighbor IX1-Backup next-hop-self neighbor IX1-Backup route-map ix1-backup-out neighbor 192.168.1.10 peer-group IX1-Main neighbor 192.168.1.11 peer-group IX1-Backup neighbor 192.168.1.12 peer-group IX1-Backup neighbor 192.168.1.13 peer-group IX1-Main neighbor 192.168.1.14 peer-group IX1-Main ip as-path access-list 10 permit ^$ ip as-path access-list 10 permit ^2008$ ip as-path access-list 10 permit ^2008 2009$ route-map ix1-main-out permit 10 match as-path 10 set metric 300 route-map ix1-backup-out permit 10 match as-path 10 set metric 310 ポイント 1 通常どこの ISP に対しても自分から広報する経路は一緒なので, メインとバックアップの 2 つに分けてグループを作っておくポイント 2 作成したグループを用いて, 実際の相手のアドレスに対してポリシーを適応させていく. そのピアをメイン回線として適応するなら,IX1-Main ポイント 3 もらう経路はそれぞれ違うので, それは直接相手のネイバーアドレスに対して route-map を定義する ( 例 ) neighbor192.168.1.10 route-map as-4713-in in 2003/12/2 Copyright 2003 Tomoya Yoshida 67

BGP ポリシー設計 ( 受信 ) ポイント 3-2: Closet Exit で, 近いところからルーティング接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 100 100 3 商用 IXピア経路 300 100 100 100 3 学術 IXピア経路 300 100 100 100 3 上流フルルート1 200 6 上流フルルート2 200 6 " プライベートや IX などは区別しない " IGP のもっとも近いところからルーティングさせる (IGP の設計が重要になってくる ) 2003/12/2 Copyright 2003 Tomoya Yoshida 68

BGP ポリシー設計 ( 受信 ) Closet Exit の場合には, どこに何を収容するのかが非常にきいてくる西上流フルルート 1 東国内学術 IX2 東上流フルルート 2 20 20 広島福岡 10 10 10 10 大阪 2 5 5 大阪 1 西国内商用 IX1 10 10 10 10 名古屋東京 2 東京 1 北海道仙台 2003/12/2 Copyright 2003 Tomoya Yoshida 69 5 5 10 10 10 10 10 10 10 10 20 20 東国内プライベート 1 東上流フルルート 1

BGP ポリシー設計 ( 受信 ) ポイント 4: 上流フルルートは, うまく使い分ける接続形態 LOCAL_PREF MED1 MED2 MED3 優先順位 BGP 顧客経路 500 1 自 AS 内広報経路 400 2 プライベートピア経路 300 100 110 120 3 商用 IX ピア経路 300 200 210 220 4 学術 IX ピア経路 300 300 310 320 5 上流フルルート 1 200 6 上流フルルート 2 200 6 " もっとも優先度が低いので, 何でも良さそうだが, 多くの実装で,LOPRE のデフォルト値が 100 になっているため, その値よりも大きくしておくのが望ましいだろう理由 : 仮に LOPRE50 などで設定していた場合, うっかりミスで, フルルートを他の BGP 接続からデフォルトで受信してしまうと, 全てがそちらにひっぱりこまれてしまう " 使い分けに関しては,AS_PATH にまかせるのが基本.AS-PATH Prepend や, コミュニティを用いて制御する場合も多くある ( 顧客経路はそれぞれ優先させるなど ) ( 例 ) 上流 1 が安い場合には, 上流 2 から受信するときに,Prepend を 1 つかませる 2003/12/2 Copyright 2003 Tomoya Yoshida 70

BGP ポリシー設計 ( 受信 )! Closet Exit の注意点! IGPメトリックがきいてくるので,OSPFのコスト設計が重要! Externalの回線をうまく分散収容する必要があるおなじような位置付けのところに収容すると, ある部分ばかりに引き込まれて偏ってしまう! 上流の制御! 上流が2つ以上ある場合, それぞれのCustomer 経路は優先顧客コミュニティーにマッチしたら, 優先度を高くして受信など大抵上流 ISP(Transit ISP) ではコミュニティーがインプリされている! それ以外のTransit 経路は, コストの安いほうをとことん使う完全 1:0 形態にするなら,LOPREで制御したほうが確実ある程度 Topologyに依存させるには,AS_PATH Prependで制御 MEDは異なるASでは比較できないので使えない! 自 ASの経路! BGPのサービスを顧客に対してしないのであれば, 受信ポリシーとして優先順位をつける必要はない. 但し, 外部から自分に対して広告されても, Filterではじくなどの仕組みは必要 2003/12/2 Copyright 2003 Tomoya Yoshida 71

BGP 受信ポリシー確認 3 国内ピアが落ちた場合には,( 海外 )Transit で救済したい Transit1 Transit2 Transit3 Peer2 Peer1 ベストパス LP= 300 MED=100 IX LP= 300 ベストパス MED=200 自 AS LP= 200 non-prepend LP= 200 Prepend 1 顧客 2003/12/2 Copyright 2003 Tomoya Yoshida 75

Hot-Potato と Cold-Potato! Hot-Potato! 最も近いところから相手にパケットを出してしまおう AS1 西 # AS2 西 AS1 東 # AS2 東! Closest Exit( とにかく近いところからパケットを出してしまう. 通常 IGP コストの最も近いところからルーティングさせる手法 )! Cold-Potato! Hot-Potato のように近いところから, というポリシーではなく, 例え遠くなったとしても, ポリシーに従ってルーティングさせる方法 AS1 西 # AS1 東 # AS2 東 # AS2 西 AS1 東 # AS2 東 2003/12/2 Copyright 2003 Tomoya Yoshida 78

Hot-Potato による経路制御 BGP での経路情報トラフィック大阪 200.100.0.0/16 AS2001 東京 R3 R2 R1 大阪では商用 IX が優先商 MED 200 BGP での経路情報学 MED 300 P MED 100 東京では Private ピアが優先 R6 R5 R4 MED 1000 大阪 RR AS2003 の大阪 RR での経路の見え方 Prefix MED > 200.100.0.0/16 200 ベストパス 200.100.0.0/16 1000 AS2003 相手に経路を互いに渡す際,MED を 1000 にして渡す東京 RR AS2003 の東京 RR での経路の見え方 Prefix MED > 200.100.0.0/16 100 ベストパス 200.100.0.0/16 300 200.100.0.0/16 1000 2003/12/2 Copyright 2003 Tomoya Yoshida 79

Hot-Potato による経路制御 (Juniper の設定例 ) protocols { bgp { group to-rr { type internal; local-address X.X.X.X; peer-as 2003; neighbor Y,Y,Y,Y { Neighborである大阪 RRのアドレス import HOT_POTATO-IN; Hot Potato 用 Policy } } policy-statement HOT_POTATO-IN { term AS2003 { 対象 ISP 名 from as-path AS2003; 対象 ISPのAS-Pathの指定 then { metric 1000; MEDを 1000" に設定 local-preference 150; ピアのLocal Preferenceとして設定 accept; 書かなければeBGPから受けた時に付加 } されたものがそのまま渡される } 東京 RR のコンフィグ例 term AS-ALL { from as-path AS-ALL; then accept; } term Other { then reject; Hot Potato 以外の ISP 経路の受信を許可それ以外の経路受信を削除 as-path AS2003 (2003.*) ; 対象 ISPのAS Numberで始まるAS-Path as-path AS-ALL (.*) ; を指定 2003/12/2 Copyright 2003 Tomoya Yoshida 80

Closet Exit( とにかく近いところから ) BGP での経路情報トラフィック大阪 200.100.0.0/16 AS2001 東京 R3 R2 R1 大阪方面は全て大阪の商用 IX 経由商 MED 100 R6 BGP での経路情報何もしない学 MED 100 R5 R4 P MED 100 R4 に近いところは R4 のプライベートピア経由,R5 に近いところは R5 の学術 IX 経由大阪 RR AS2003 の大阪 RR での経路の見え方 AS2003 東京 RR AS2003 の東京 RR での経路の見え方 Prefix MED > 200.100.0.0/16 100 ベストパス 200.100.0.0/16 100 RR 同士では特になにもしない Prefix MED > 200.100.0.0/16 100 ベストパス 200.100.0.0/16 100 200.100.0.0/16 100 2003/12/2 Copyright 2003 Tomoya Yoshida 81

BGP ポリシー設計 ( 広告 )! 以下の 3 つのパスアトリビュート手法を使って制御するのが基本! MED 基本は異なる AS 間で比較されないので, 隣接 AS 同士が複数回線で結ばれている場合に有効! AS-PATH Prepend 自分の AS-PATH を相手に遠くみせる手法! Community の set 相手と自分の間で, この Community はどうゆう制御をする, ということを事前に取り決めがされている, あるいは公開されているので, 自分主体で相手の Lopre を制御したり, 経路を調節したりといった柔軟な制御が可能! 広告経路! 上流やピア先には, 自分のアドレスと BGP 顧客経路を広告! BGP 顧客には, フルルートを場合によっては, デフォルトルートのみを配信 " お客さん側の BGP ルータがメモリ的に厳しいような状況など ( 約 3 万経路で 25M 前後は消費する ) 2003/12/2 Copyright 2003 Tomoya Yoshida 83

MED を用いた制御 AS2003 の出口で AS2001 向けに経路をアナウンスするときに MED を設定 R1 200.100.0.0/16 AS2003 router bgp 2003 neighbor Z.Z.Z.Z remote-as 2001 neighbor Z.Z.Z.Z route-map SET-MED out route-map SET-MED permit 10 set metric 110 R2 BGP での経路情報 MED 100 R3 200.100.0.0/16へのトラヒックは R3を経由 Z.Z.Z.Z AS2001 R4 BGP での経路情報 MED 110 AS2001 での経路の見え方 Prefix AS Path MED 200.100.0.0/16 2003 110 > 200.100.0.0/16 2003 100 ベストパス BGP を使った経路情報の流れ AS2003 向けの実際のトラフィック相手から自分に帰ってくるトラフィックを制御することができる 2003/12/2 Copyright 2003 Tomoya Yoshida 84

AS_PATH を用いた制御ベスト 100.50.0.0/16 2002 2003 2003 2003 100.50.0.0/16 2004 2005 2003 BGP を使った経路情報の流れ AS20000 向けの実際のトラフィック 100.50.0.0/16 2004 2005 2003 AS2001 AS_PATH の短い左回りを選択する AS2004 100.50.0.0/16 2002 2003 2003 2003 100.50.0.0/16 2005 2003 AS2005 Y.Y.Y.Y AS2002 AS_PATH に 2003 を 2 つ多く付加して, 遠いようにみせる 100.50.0.0/16 2003 AS2003 100.50.0.0/16 100.50.0.0/16 2003 2003 2003 Cisco の場合 router bgp 2003 neighbor Y.Y.Y.Y remote-as 2002 neighbor Y.Y.Y.Y route-map ASPATH-PREPEND out route-map ASPATH-PREPEND permit 10 set as-path prepend 2003 2003 2003/12/2 Copyright 2003 Tomoya Yoshida 85

Community による戻りのトラフィック制御 2001:110 をつければ Local Preference が 110 になるのは知ってるから, こっちからトラフィック流してね ( という気持ち ) R1 200.100.0.0/16 AS2003 R2 相手にルールを公開 ( 等 ) 2001:100 " LOPRE 100 2001:110 " LOPRE 110 2001:120 " LOPRE 120 200.100.0.0/16 COMMUNITY 2001:110 R3 200.100.0.0/16 へのトラフィックは R1 を経由 R4 200.100.0.0/16 COMMUNITY 2001:100 COMMUNITY 2001:110 検知 COMMUNITY 2001:100 検知 2001:110 がついているから, こちらの回線の Local Preference は 110 に設定するよ LOCAL_PREF=110 付与 LOCAL_PREF=100 付与優先 AS2001 BGP を使った経路情報の流れ AS2003 向けのトラフィック COMMUNITY 自体は単なるタグ経路アナウンス先 (AS2001) が COMMUNITYをこのように解釈してくれる場合に有効となる 2003/12/2 Copyright 2003 Tomoya Yoshida 86

海外上流のトラフィック制御の難しさ! 上流のその先の Topology や Peer の関係などをきちんど日々把握している必要がある! 上流の Topology はけっこう変わる突然急激にトラフィックが変動している. 何故? よくよく見るとAS-PATHが変わっている! でも,Lopre だと強すぎるから, やっぱり AS-PATH 制御?! いくら Prepend しても, トラフィックがやってくる上の Transit Peer の関係上無理な場合がある 2003/12/2 Copyright 2003 Tomoya Yoshida 88

BGP ポリシー設計 ( 広告 ) どう Prepend しても, ひっぱりこんでしまう場合 Transit1 Peer AS2 AS1 にて,Transit1 経由の自 AS 経路よりも,Peer 経由が優先されてしまう Transit Transit Transit AS1 Peer Prepend Transit2 Transit いくら Prepend しても無理か自 AS Transit を買っている上流 ISP 2003/12/2 Copyright 2003 Tomoya Yoshida 89

ibgp 設計! 全 BGP ルータが正しく BGP 経路情報を保有し, それぞれのルータが正しく経路選択出来るようにする! 同じ情報を保持する必要があるのとは違う! BGP の経路は配送すべきところに適切に配送する! OSPF のデフォルトルートなどで十分なところはデフォルトでルーティングさせる! 内部の細かい経路は必要ないところには配送しない BGPユーザ向けの階層にはフルルートのみをそれ以外の収容ルータ向けには経路を配送しない! リフレクタ階層構造を利用! それほど数が多くなければ, フルメッシュのほうが適当な場合もある 2003/12/2 Copyright 2003 Tomoya Yoshida 91

BGP 経路情報の不一致 ibgp で受信した経路は, 他の ibgp ピアには渡さない. 例えば R5 は R4 から受信した 200.101.0.0/16 を R6 には広報しない AS2003 の R5 での経路の見え方 Prefix AS Path > 200.101.0.0/16 2001 > 200.102.0.0/16 2002 > 200.104.0.0/16 2004 200.101.0.0/16 AS2001 200.102.0.0/16 AS2002 R2 BGPでの経路情報 200.104.0.0/16 AS2004 R3 R1 BGPでの経路情報 ibgp R5 AS2003 ibgp BGP での経路情報 R4 ibgp R6 AS2003 の R4 での経路の見え方 Prefix AS Path > 200.101.0.0/16 2001 > 200.102.0.0/16 2002 ibgp をはらなかったために, 互いの経路情報を交換しない AS2003 の R6 での経路の見え方 Prefix AS Path > 200.102.0.0/16 2002 > 200.104.0.0/16 2004 2003/12/2 Copyright 2003 Tomoya Yoshida 92

ルートリフレクタ (RR) 一般的な ibgp Peer R R R ibgp Peer R R ibgp はフルメッシュでなくてはならないルートリフレクタ (RR) を使用した ibgp Peer RRクライアント R RRクライアント R ルートリフレクタ ibgp Peer R RR クライアント R RR クライアント R RRクライアント ibgp フルメッシュをルートリフレクタを用いた Peer により代用 2003/12/2 Copyright 2003 Tomoya Yoshida 93

リフレクタ階層構造東京 1 地域を例とするルートリフレクタによる ibgp 階層構造ネットワークの規模により階層は異なる東京 1 RR 冗長化 RR CORE GW GW ルータコアルータリフレクタを専用でやる or 境界ルータなどが兼任 N 層 RR RR RR RR 境界基幹境界ルータ地方基幹ルータリフレクタと境界集約を兼任 N+1 層 RR RR RR RR RR RR 集約集約ルータ N+2 層 ADSL 収容ルータ c c c c... c c c c... BGP 収容ルータ 2003/12/2 Copyright 2003 Tomoya Yoshida 94

リフレクタ階層構造イメージ図広島福岡 ABR ABR ABR ABR 西国内 1 西国際 1 CORE 大阪 2 RR RR CORE 大阪 1 RR RR CORE CORE N 層 ABR RR ABR 名古屋東国内 2 東国際 2 CORE CORE 東京 2 RR RR CORE 東京 1 RR RR CORE RR RR N-1 層 N-2 層 ABR 北海道 ABR ABR ABR 仙台東国内 1 東国際 1 RR RR RR RR N 層から経路をもらい N-1 層を形成している c c c 東京 1 や大阪 1 などでも, さらに階層化されるが, ここでは省略 2003/12/2 Copyright 2003 Tomoya Yoshida 95

行きのルーティングフフルートエリアインターネット GW ルータから ebgp 経由でインターネットへと接続 ebgp GW GW GW 外部接続部 (GW) 必ず特定の CORE を通って外部に抜けるような構成では, デフォルトに従ってルーティングすれば特に問題はないデフォルト配信 CORE CORE バックボーン ibgp OSPF ABR ABR ABR OSPF のデフォルトルートで十分. ただし上位には Static 経路を BGP に再配信する ASBR R Static を BGP へ再配信エンドユーザ ASBR 中継アクセス部 AS 2003/12/2 Copyright 2003 Tomoya Yoshida 96 R ebgp 配下にBGPユーザをかかえている場合にはフルルートを保持

ユーザ Static 経路を BGP に再配信 ABR ABR 中継アクセス部 RT RT エリア 101 Cisco の例 router bgp 2003 redistribute static route-map s-to-bgp neighbor X.X.X.X remote-as 2003 neighbor X.X.X.X send-community neighbor X.X.X.X next-hop-self neighbor X.X.X.X update-source loopback 0 ip route a.a.a.a b.b.b.b c.c.c.c ASBR ASBR ASBR ユーザルータユーザルータ加入者収容ルータユーザルータ static route-map s-to-bgp permit 10 set community no-export ASBR でユーザアドレスを static で記述. それを上位に BGP で再配信.BGP の場合には,no-export をつけて,GW ルータから外にでていかないようにしている. 内部の ibgp では send-community を動作させ,no-export の Community 情報がついたは内部でのみ伝播する 2003/12/2 Copyright 2003 Tomoya Yoshida 97

帰りのルーティング細かい ibgp 経路エリアコアルータに到達した段階では, 全ての細かい下部の経路を知っている必要があるので, 全 BGP 情報を保有する ABR では, 自分の配下の BGP 経路を保有していれば OK GW ABR GW デフォルト配信 CORE ABR インターネット GW CORE ABR デフォルトルートに従ってコアルータへルーティングすれば OK 外部接続部 (GW) バックボーン ibgp ebgp OSPF 中継アクセス部自身の Static ルートに従ってルーティングされる ASBR R Static を BGP へ再配信 ASBR R ebgp AS エンドユーザ 2003/12/2 Copyright 2003 Tomoya Yoshida 98

リフレクタ階層構造の経路配信イメージ同じ階層にいるからといって, 同じ BGP 経路を保有するとは限らない東京 1 F RR C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 RR F CORE F GW GW ルータコアルータ F F: フルルート C:: クライアント経路 N 層 C9 C10 C11 C12 RR RR RR RR F C1 C2 C3 C4 C5 C6 C7 C8 境界基幹境界ルータ F ABR 地方基幹ルータ N+1 層集約ルータ C9 C10 C11 C12 C5 C6 C7 C8 C1 C2 C3 C4 RR RR RR RR RR RR F 集約 F N+2 層 c c c c... C9 C10 C11 C12 c c c c... c c c c... C5 C6 C7 C8 C1 C2 C3 C4 F ASBR AS 境界ルータ Static ユーザ ADSL 収容ルータ BGP 収容ルータ User 2003/12/2 Copyright 2003 Tomoya Yoshida 99

リフレクタ階層構造 ( 東京 1 の例 ) 東京 1 ID:1 RR ID:1 RR Top 階層 N 層 ID:11 ID:11 ID:15 RR RR RR RR ID:15 N+1 層 ID:117 ID:117 ID:151 ID:151 ID:153 RR RR RR RR RR RR ID:153 N+2 層 c c c c... c c c c... 東京 1 地域を例とするルートリフレクタによる ibgp 階層構造 1 つ前の層から ID が辿れるような付与規則にするとわかりやすいかもしれない 2003/12/2 Copyright 2003 Tomoya Yoshida 100

他のクラスターから経路が伝播される ID:1 RR ID:1 RR X.X.X.X/24 Client から上がって来た経路は他のクラスターへと伝播される ID:11 ID:11 X.X.X.X/24 ID:15 RR RR RR RR ID:15 c X.X.X.X/24 c c X.X.X.X/24 Cluster list: 0.0.0.11, 0.0.0.1, 0.0.0.15 リフレクタルータが, また別のリフレクタルータへと経路を配送している.Cluster list は, 辿ってきたクラスターが順に並んでいる. リフレクタが他のリフレクタに配送する場合に, 自分の ID を左につけて配送していく (AS_PATH 同じようなイメージで, 左がもっとも直近 ) AS_PATH : 4713 2914 701 2003/12/2 Copyright 2003 Tomoya Yoshida 101

クラスター ID の設定ミス ID:1 RR ID:1 RR X.X.X.X/24 Client から上がって来た経路は他のクラスターへと伝播される ID:11 ID:15 X.X.X.X/24 ID:15 RR RR RR RR ID:15 破棄 c 来た経路が自分と同じクラスター ID であったため, その経路情報を破棄する c c X.X.X.X/24 通信断クラスター ID が重複してしまったために, 自分と同じクラスター ID の経路を他から受信すると, ループを防ぐために破棄してしまう (AS_PATH のループディテクションと原理は一緒 ) 2003/12/2 Copyright 2003 Tomoya Yoshida 102

クライアントとのピアが切れた場合 ( 同一 ID) ID:1 RR-A ID:1 RR-B ID:15 RR 破棄 RR ID:15 c クライアントの片方のピアがきれた場合には, もう一方のリフレクタから上位に配信された経路は, 同一 ID のため破棄される. ただし, 通常各クライアントは, 各々両方のリフレクタにピアをはっているので, どちらか一方から経路を受信できる 2003/12/2 Copyright 2003 Tomoya Yoshida 103

別の ID を付与した場合 ID:1 ID:1 RR-A RR-B ID:100.0.0.11 RR RR ID:100.0.0.12 c 別 ID の場合には, クライアントの片方のピアがきれても, 上位リフレクタから経路が配信される.( 通常状態においても配信される ) RR がパケットフォワーディングもやっている場合には, この方法がいいだろうツリーが増えるので, 適応個所には注意したいが, 大きな問題はないだろう BGP 経路の伝播が, 同一 ID とは異なる点にも注意したい 2003/12/2 Copyright 2003 Tomoya Yoshida 104

経路の見え方 ( 同一 ID の場合 ) クラスター ID が同一のため, 上位リフレクタから反射した経路は同一 ID の下位リフレクタにはわたらない ID:1 RR-A ID:1 RR-B ID:15 RR 破棄 RR ID:15 1 経路 1 経路 1. Client からの経路 c 1. Client からの経路 2003/12/2 Copyright 2003 Tomoya Yoshida 105

経路の見え方 ( 別 ID の場合 ) IGP コストが同等の場合には, ルータ ID( リフレクタからの経路受信の場合には Originator ID, それでも一緒の場合には Router-ID) が小さいほうをベストに選択. この場合,RR-A,RR-B 共に 100.0.0.11 からの経路をベストに選ぶ ID:1 RR-A ID:1 RR-B 100.0.0.11 には反射しないベストなので 1 経路しかない ID:100.0.0.11 RR > Router-ID RR ID:100.0.0.12 1 経路 3 経路 1. Client からの経路 c 1. 直接 Client から受信する経路 2. リフレクタ A 経由の 0.0.0.1, 100.0.0.11 の経路 3. リフレクタ B 経由の 0.0.0.1, 100.0.0.11 の経路 Originator ID : その経路の生成元 (GW ルータの LB など ) 2003/12/2 Copyright 2003 Tomoya Yoshida 106

ibgp 設計のポイント! リフレクタの階層化! CORE を中心とした物理的な階層と同等な階層化が理想的経路配送自体も,GW から入ってきたフルルートは CORE を中心にリフレクタがフォワーディングも兼任する場合には注意! ID を付与する場合に, わかりやすい数字かループバックアドレスに設計する! 何がどのように配信されるのかは, それぞれのネットワークによって異なるので, ちゃんと押さえておく必要がある! サービスごとにクラスター化をし, 各クラスターごとに配信経路やルーティング方式を検討する ( フォワーディングトポロジーに追従 )! BGP ユーザのクラスタ当然 BGP で経路を配信他のクラスタの細かい経路まではいらない! ADSL 専用クラスタ上位には,BGP でクライアント経路を配信. ルーティングはデフォルトルートに従えばよいので. フルルートを保有する必要はないなど 2003/12/2 Copyright 2003 Tomoya Yoshida 107

BGP の next-hop の解決方法! BGP では, 相手から受信した経路の next-hop に到達性がなければ, その経路は無効とする (NEXT_HOP 属性 )! ebgp の場合には, 受信時に破棄! 外部経路の NEXT_HOP の解決方法には,2 つの方法がある! ebgp から受信する際に, 自身のループバックを next-hop とする ibgp に対して, next-hop-self を設定 (Cisco の場合 ) そのループバックは OSPF などの IGP でルーティング! ebgp ピアで使用している /30 などの connected アドレスを,IGP に流す redistribute connected Netwrok コマンド + passive better 2003/12/2 Copyright 2003 Tomoya Yoshida 109

next-hop-self を設定した場合これが意味 ebgp で経路を受信してそれを ibgp に流す際に, 自分が宛先だよということをして内部にその経路を伝播させるしくみ R3 10.0.0.253 R3 からみた BGP 経路情報 ibgp ピア AS2001 ebgp ピア Prefix Nexthop AS Path 172.16.0.0/16 10.0.0.254 AS2001 R1 192.168.10.1 AS2003 172.16.0.0/16 192.168.10.0/30 192.168.10.2 R2 10.0.0.254 IGP 経路情報 :10.0.0.254 R2 からみた BGP 経路情報 Prefix Nexthop AS Path 172.16.0.0/16 192.168.10.1 AS2001 next-hop-self を設定し NEXT_HOP 属性を 192.168.10.1(AS2001 が持つアドレス ) から 10.0.0.254(AS2003 が自分で持っている R2 のループバックアドレス ) に置き換える Cisco の場合 router bgp 2003 neighbor 192.168.10.1 remote-as 2001 略 neighbor 10.0.0.253 remote-as 2003 neighbor 10.0.0.253 next-hop-self ebgp 経由で受けた経路を ibgp ピアに流す際に設定する AS2001の172.16.0.0/16のNEXT_HOP 属性の値は,AS2003から見たときの該当アドレスへのボーダールータのアドレス.Next-hop-selfを行うと10.0.0.254と見える 2003/12/2 Copyright 2003 Tomoya Yoshida 110

ebgp 経路をそのまま ibgp に流した場合 ebgp で接続している /30 のインターフェースの経路情報は内部では知らないので, 何らかの方法で IGP に流す必要がある ebgp ピア 172.16.0.0/16 AS2001 R1 192.168.10.1 192.168.10.0/30 192.168.10.2 R2 ibgpピア AS2003 R2 からみた BGP 経路情報 Prefix Nexthop AS Path 172.16.0.0/16 192.168.10.1 AS2001 R3 R3からみたBGP 経路情報 Prefix Nexthop AS Path 172.16.0.0/16 192.168.10.1 AS2001 IGP 経路情報 :192.168.10.0/30 192.168.10.1 に到達するためのルーティング情報が IGP で流れていなくてはならない AS2001 の 172.16.0.0/16 の NEXT_HOP 属性の値は AS2003 から見たときの該当アドレスへのボーダールータのアドレス. この図では,192.168.10.1 が出口のアドレス 2003/12/2 Copyright 2003 Tomoya Yoshida 111

リカーシブルックアップ AS2003 AS2001 172.16.8.1 宛てのパケット到着 ibgp ebgp 172.16.0.0/16 data Dst. 172.16.8.1 Ether0 192.168.10.0/30 R3 R2 R1 10.0.0.1 192.168.10.1 1 回目の Lookup(BGP 経路検索 ) R3 ルーティングテーブル Prefix Next-hop B 172.16.0.0/16 192.168.10.1 O 192.168.10.0/30 10.0.0.1 Ether0 OSPF へ再配信 R2 の Config(Cisco の場合 ) router ospf 2003 redistribute connected subnets route-map c-to-ospf router bgp 2003 neighbor 192.168.10.1 remote-as 2001 neighbor 192.168.10.1 route-map peer-out out neighbor 192.168.10.1 route-map peer-in in 最終的なパケットフォワーディング先 2 回目の Lookup(BGPNext-hop を IGP 経路で検索 ) access-list 11 permit 192.168.10.0 0.0.0.3 route-map c-to-ospf permit 10 match ip address 11 set metric-type type-1 2003/12/2 Copyright 2003 Tomoya Yoshida 112

ebgp マルチホップによるロードバランス同一ルータで外部と複数本で ebgp ピアをはる場合,eBGP マルチホップによりロードバランスが可能 Cisco の場合 (R2) router bgp 2003 neighbor z.z.z.z remote-as 2004 neighbor z.z.z.z ebgp-multihop 2 ip route z.z.z.z 255.255.255.255 x.x.x.x ip route z.z.z.z 255.255.255.255 y.y.y.y R1 R3 AS2003 AS2004 y.y.y.y R2 R4 z.z.z.z x.x.x.x Juniper の場合 (R2) protocols { bgp { group ebgp { type external; multihop { ttl 2; } peer-as 2004; neighbor z.z.z.z; } } } } routing-options { static { route z.z.z.z/32 next-hop [ x.x.x.x y.y.y.y ]; } } ループバックアドレスで互いにピアをはる相手のループバックに対するルーティングは,Static Route を物理インターフェースに対して設定することにより解決 z.z.z.z " ループバックアドレス 2003/12/2 Copyright 2003 Tomoya Yoshida 113

ibgp multipath によるロードバランス複数の ebgp ピアから受信した経路に対して, 内部でバランスさせる BGP マルチパスの条件 BGP のマルチパス機能が有効になっていること経路選択プロセスで,IGP メトリックによる選択をしても決着がつかない場合ベンダによって, 仕様が異なるので注意 R1 AS2003 R2 Cisco の場合 (R5) router bgp 2003 maxiumu-path ibgp 2 R3 Cost:10 AS2004 R5 R4 Cost:10 Juniper の場合 (R5) protocols { bgp { group ibgp { neighbor x.x.x.x { multipath; R5 にて, マルチパス機能を有効にする.eBGP に対しても可能 2003/12/2 Copyright 2003 Tomoya Yoshida 114

PA アドレス (CIDR 経路 ) の広告 CIDR 経路は安定してインターネットに広報されていなくてはならない BGP で経路広告する際の IGP は, static null0 にて行う! AS2002 インターネットネットワークコマンドだけでは BGP の経路広告はできない Cisco の場合 (RR) router bgp 2003 network 200.100.0.0 mask 255.255.0.0 BGP の経路情報 ip route 200.100.0.0 255.255.0.0 null 0 254 経路を管理する親玉であるルートリフレクタにて生成する RR RR AS2003 200.100.0.0/16 Protocol Distance ルータが生きている限りは up しているインターフェース 2003/12/2 Copyright 2003 Tomoya Yoshida 115

next-hop-self つづき 172.16.1.0/16 Transit 提供 172.16.2.0/16 AS1 Peer AS3 Peer IX AS2.1.2.3 172.16.3.0/16 192.168.0/24 AS1 から AS3 へ広告される経路 Prefix Nexthop AS Path 172.16.1.0/16 192.168.0.1 AS1 172.16.2.0/16 192.168.0.2 AS1 AS2 本当は, マルチアクセスメディアネットワークにおける最適な next-hop とするための BGP の実装 " 直接トラフィックを引き込んでしまうだけど next-hop-self の設定は, 相手に経路広告する際にも設定しましょう AS1 が next-hop-self の設定をしていなかったのが原因 2003/12/2 Copyright 2003 Tomoya Yoshida 117

フラップダンプニング ( ルートダンプニング ) 回線の up/down などにより,BGP の経路がフラップしている場合には, その Update パケットが頻繁に発生し, ルータの CPU を無駄に消費してしまう. それを回避するために, ある閾値を境に, その経路を抑制するしくみ Penalty のカウント方法 <Cisco> Penalty 1000/1Flap <Juniper> * Route is withdrawn 1000 * Route is readvertised 1000 * Route's path attributes change 500 デフォルトの penalty 値 <Cisco> half-life: 15 minutes reuse: 750 suppress: 2000 max-suppress-time: 60 minutes <Juniper> half-life: 15 minutes reuse: 750 suppress: 3000 max-suppress-time: 60 minutes 1, half-life: 加算されたペナルティー値が半分になるまでの時間 2. reuse: この値までペナルティー値が減れば, 再度その経路を広告するという設定値 3. suppress: ペナルティー値の合計がこの値を超えた時点で, 制限をかけはじめる 4. max-suppress-time: 制限をかける時間として設定する最大の時間 2003/12/2 Copyright 2003 Tomoya Yoshida 118

BGP フラップの例 Cisco Juniper 1 回落ちてあがる 15 分弱 1000 2000 1 回のフラップに対して与えられるそれぞれのペナルティー値 1 回落ちてあがる 505 1505 1010 3010 この瞬間に suppress 15 分この間 Juniper 経由は無効安定 753 1505 Half-time15 分経過 15 分強 375 750 Half-time15 分強で Reuse の 750 に到達 2003/12/2 Copyright 2003 Tomoya Yoshida 119

マルチベンダ環境! ベンダの仕様によって, 挙動が異なる場合がけっこうある! BGP のベストパスセレクションの動作が違うチューニングが必要なときもある場合によっては, 経路選択時に障害も起こりうる! 経路表の持ち方が異なる! など! ある程度は検証を行って確認しましょう! 実網でわかった場合には, その都度検討 2003/12/2 Copyright 2003 Tomoya Yoshida 121

BGP Hold-time! 実装が若干異なる! Juniper " Keepalive:30 秒,Holdtime:90 秒! それ以外 " Keepalive:60 秒,Holdtime:180 秒! Hold-time は,2 つの BGP ピアの間で異なっていたら, 値の小さいほうにあわされるので注意! Open メッセージの中にふくまれていて, 最初に BGP ピアを確立する際のネゴシエーションで決定される Juniper --- Cisco の場合には, keep-alive 30 秒 / Hole-time90 秒になる BGP のバージョンは, 最初の OPNE メッセージのやり取りの段階で, 不一致の場合にはピア自体が張れない ( 例えば, バージョン 1 とバージョン 4) 2003/12/2 Copyright 2003 Tomoya Yoshida 122

next-hop-self の実装! Cisco! 記述しないと有効にならない ebgp から受信した経路を ibgp に流す場合に, next-hop-self を記述すると有効! ただし,iBGP ピア同士で書いても, 有効にならない! Juniper! 記述しないと有効にならない ebgp から受信した経路を ibgp に流す場合に, next-hop-self を記述すると有効 (Cisco と同様 )! ibgp 同士においても, 記述すると有効になってしまうので注意ルーティングループを引き起こす可能性がある 2003/12/2 Copyright 2003 Tomoya Yoshida 123

send-community の実装! Cisco! 対向のピアに対して, send-community と記述しないと, ちゃんとコミュニティを伝播してくれない! Juniper 例えば,no-export などの経路を内部で利用していると, 上流向けに対して send-community がはずれてしまった場合には, 外部にもれてしまう! デフォルトでコミュニティー情報をわたす! 特に設定は必要ない 2003/12/2 Copyright 2003 Tomoya Yoshida 124

Route-Refresh メッセージ! BGP のメッセージ Type5 = ROUTE_REFLESH! RFC2918 で規定. 相手から全 BGP 経路情報の再送を要求! BGP の OPNE メッセージのやり取り時に, 各々自分がどのタイプが受け入れ可能かを通知する! 実際には, BGP TYPE1 OPEN メッセージの中の, Optional Parameters フィールドの値の中の, Capability Code に記述 Capability Code = 2 : rfc Capability Code = 128 : cisco (128 以上はベンダ独自使用領域 )! 最近は, この 2 種類両方とも実装している, あるいは実装中というベンダが多い! Juniper,Riverstone はデフォルトでキャッシュ方式を採用している! 各ピアから受信した経路をキャッシュしている " メモリを消費する! Cisco の場合など, soft-reconfiguration inbound でキャッシュ 2003/12/2 Copyright 2003 Tomoya Yoshida 125

BGP の passive モードの実装通常はどちらか一方からの TCP179 ポートに対する OPEN メッセージによって, コネクションが開設される R1 OPEN R2 Passive と設定してあると, 自分からコネクションを OPNE しようとせず, 相手からのコネクション開設を待っている R1 passive 179 OPEN R2 Passive 設定は,Juniper や Riverstone が対応注意両方 passive だと, 永久に BGP ピアが確立しない 2003/12/2 Copyright 2003 Tomoya Yoshida 126

経路管理のされ方 (1)! ルーティングテーブルのみ :Juniper,RS! OSPF も BGP も全て 1 つのルーティングテーブルで管理されている! ルーティングテーブル上でベストではないと,BGP にて配信されない例えば Juniper では, advertise-inactive というコマンドで,OSPF など BGP 以外のプロトコルがベストとなっていても,BGP 上で最もベストな経路が配信可能となる! BGP 以外の経路が配信されてしまう可能性があるので注意 Out の policy 変更は,IP ルーティングテーブル全体に適応される match protocol ospf などでマッチしてしまうと, その経路が BGP で配信されてしまう逆に In の policy は,BGP ピアに対しては,BGP 経路しか受信しないので, BGP の経路に対してのみ適応される " 他のプロトコルの経路を受け取る心配はない 2003/12/2 Copyright 2003 Tomoya Yoshida 127

経路管理のされ方 (2)! ルーティングテーブルと BGP テーブルがある :Cisco,Foundry! BGP 経路の制御は,BGP テーブルで行われる! BGP テーブル上のベスト経路が, ピア先に経路配信される! ルーティングテーブルと BGP テーブルの関係 BGP 経路をピアから受信し, ベストパスを選択する同時に, そのBGPテーブルでベストとなっている経路を, 自身のルーティングテーブルに渡す渡されたあと. プロトコルディスタンスで, もっとも優先される経路がルーティングテーブルに正式にエントリーされる (OSPFで同じ経路が存在する場合には,BGP テーブルのみでベストパスとしてエントリーされ, ルーティングテーブルにはのらない $ プロトコルディスタンスの差 )! BGP ピアに配信される経路は,BGP テーブルを参照する通常のルーティングテーブルでベストになっていなくても OK 2003/12/2 Copyright 2003 Tomoya Yoshida 128

BGP の RIB 管理と各テーブルの関係 RIB(Routing Information Base) BGP テーブルピア先からの経路入力 Adj-RIBs-In Loc-RIB Adj-RIBs-Out ピア先からの経路がいったんこのテーブルにそのまま蓄積される経路フィルタとパス属性による処理が行われた結果がここに蓄積され, これがルーティングに反映されるピア先への広告のために選択された情報が蓄積され, UPDATE メッセージにてピア先に広告されるピア先への経路出力ルーティングテーブル 0.0.0.0/0 *[OSPF] 00:00:51, metric 110, tag 0 4.0.0.0/8 *[BGP] MED 100, localpref 200, AS path: 2914 3356 I 6.1.0.0/16 *[BGP] MED 100, localpref 90, AS path: 2914 668 7170 1455 I 150.22.0.0/16 *[OSPF] metric 36, tag 0 フォワーディングテーブル Destination Interface 0.0.0.0/0 so-0/1/0.0 4.0.0.0/8 so-0/0/0.0 6.1.0.0/16 so-0/0/0.0 150.22.0.0/16 so-0/1/0.0 2003/12/2 Copyright 2003 Tomoya Yoshida 129

MED について! MED(MULTI_EXIT_DISC) のおさらい! 1 つの隣接 AS との間に複数回線がある場合,MED の値を互いに交換することによって, 優先順位をつけることができる! 異なる AS 間では通常比較の対象にはならない always-compare-med で, 異なる AS 間でも比較することが可能! 値の小さいほうを優先する! 2 つ以上の AS をまたがっては広告されない ebgp ピアに対して Update を送信する場合には,MED 属性は削除される! MED 値がついていない場合には, ベンダーによって解釈が異なる! MED = 0 or NULL ( もっとも優先される )! MED = MAX 値 ( もっとも値が大きいということは, 使われないということ )! ベンダによっては, 何も値がついていない経路に付与する MED 値を変更することが可能 2003/12/2 Copyright 2003 Tomoya Yoshida 130

BGP 経路比較 (MED 編 )[3] 同一 AS の経路なので,MED の小さいほうを R5 ではベストパスに選択ベスト MED 200 MED 210 AS2003 Route-Reflector R3 経由 R4 経由 R5 ibgp ibgp ベスト R3 R4 ベスト ebgp R1 AS2001 ebgp IX 2003/12/2 Copyright 2003 Tomoya Yoshida 133

BGP 経路比較 (MED 編 )[5] 最終的には,R3 経由の経路が伝播して落ち着くベスト MED 200 ibgp AS2003 R5 Route-Reflector ibgp MED 200 i e ベスト MED 200 R3 e MED 210 R4 ベスト ebgp R1 AS2001 ebgp IX 2003/12/2 Copyright 2003 Tomoya Yoshida 135

BGP 経路比較 (MED 編 )[6] 同様に AS2002 の例 : この場合は,R4 経由の経路がベストになって落ち着く i MED 200 ベスト MED 200 ibgp AS2003 R5 Route-Reflector ibgp ベスト R3 MED 210 e R4 ベスト MED 200 e R2 AS2002 ebgp IX 2003/12/2 Copyright 2003 Tomoya Yoshida 136

BGP 経路比較 (MED 編 )[7] それぞれ MED200 の経路がベストとなっている (AS2001,AS2002 を合体 ) MED 200 MED 200 ibgp AS2003 R5 Route-Reflector ibgp ベスト MED 200 R3 MED 210 MED 210 R4 ベスト MED 200 ebgp R1 ebgp R2 ebgp IX AS2001 AS2002 2003/12/2 Copyright 2003 Tomoya Yoshida 137

BGP 経路比較 (MED 編 )[9] まず先に AS2001 経由で AS100 の経路を受信 ( 先に開通したなど ) AS2003 MED 200 ibgp R5 Route-Reflector ibgp MED 200 ベスト i e ベスト MED 200 R3 e MED 210 R4 ebgp R1 ebgp R2 ebgp IX AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 139

BGP 経路比較 (MED 編 )[10] その後,AS2002 経由でも AS100 の経路を受信 AS2003 MED 200 ibgp R5 Route-Reflector ibgp MED 200 i ベスト e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 140

BGP 経路比較 (MED 編 )[11] まず R4 では,eBGP 経由の AS2002 の経路がベストに AS2003 MED 200 ibgp R5 Route-Reflector ibgp MED 200 i e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 141

BGP 経路比較 (MED 編 )[12] AS2002 経由のベスト経路を R5 に伝播 MED 200 ibgp AS2003 R5 Route-Reflector ibgp e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 142

BGP 経路比較 (MED 編 )[13] R5 では,Router-ID の小さい R4 経由をベストに選択 MED 200 ibgp ベスト MED 200 AS2003 R5 Route-Reflector ibgp Router-ID:R3>R4 ベスト e MED 200 ebgp R3 MED 210 e ebgp MED 210 e R4 MED 200 ベスト e IX R1 R2 AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 143

BGP 経路比較 (MED 編 )[14] i e R3 では,Peer タイプで直接 AS2001 経由の ebgp 経路をベストに選択 MED 200 ベスト MED 200 MED 200 ebgp R3 R1 AS2001 ibgp ベスト MED 200 MED 210 e AS2003 R5 ebgp Route-Reflector MED 210 e ibgp R4 R2 AS2002 MED 200 e IX ベスト AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 144

BGP 経路比較 (MED 編 )[15] R3 では AS2001,R4 では AS2002 の経路がそれぞれベストに MED 200 ibgp ベスト MED 200 AS2003 R5 Route-Reflector ibgp e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 145

実装の違い! Cisco! ebgp に対して,Router-ID の比較をしない! ルートフラップを考慮した実装らしい 2 つの ebgp ピアから経路を受信している場合, 同一 AS_PATH だし, 安定して常に広告されている方 ( 先に広告してきた方 ) を優先的に常に選択していたほうが望ましい! Juniper! ebgp に対して,Router-ID の比較をする 2003/12/2 Copyright 2003 Tomoya Yoshida 146

BGP 経路比較 (MED 編 ):R3/R4 = C の場合 [16] R3/R4 共に ebgp がベストになっているので, このままの状態で落ち着く MED 200 ibgp ベスト MED 200 AS2003 R5 Route-Reflector ibgp e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 147

BGP 経路比較 (MED 編 ):R3/R4 = J の場合 [17] 再度 R4 で比較をし,Router-ID の小さい R1 経由をベストに選択 MED 200 ibgp ベスト MED 200 AS2003 R5 Route-Reflector ibgp Router-ID:R2>R1 e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp ベスト MED 210 e R4 R2 MED 200 e IX AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 148

BGP 経路比較 (MED 編 ):R3/R4 = J の場合 [18] 同一 AS なので,MED の小さい R3 経由をベストにベスト MED 200 MED 210 ibgp AS2003 R5 Route-Reflector ibgp e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp ベスト MED 210 e R4 R2 MED 200 e IX AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 149

BGP 経路比較 (MED 編 ):R3/R4 = J の場合 [19] ベスト経路を R4 に配信.R4 では Peer タイプで AS2002 の経路が再びベストにベスト MED 200 MED 210 ibgp AS2003 R5 Route-Reflector ibgp MED 200 e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 150

BGP 経路比較 (MED 編 ):R3/R4 = J の場合 [20] また元に戻った " 経路情報のフラップが発生している!! MED 200 ibgp MED 200 AS2003 R5 Route-Reflector ibgp Router-ID:R3>R4 MED 200 e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 151

回避策 1 明示的に優先ピアの LOCAL_PREF をあげてしまう (300"310) ベスト AS2003 LOPRE 310 MED 200 LOPRE 310 MED 200 ibgp R5 Route-Reflector ibgp Lopre で差をつけるのは実はあまりよくない e ベスト LOPRE 310 MED 200 Peer タイプで ebgp の経路が優先される ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 LOPRE 310 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 152

回避策 2 always-compare-med を使って, 異なる AS 間で MED 比較をさせるベスト AS2003 MED 200 MED 200 ibgp R5 Route-Reflector ibgp e ベスト MED 200 ebgp R3 R1 MED 210 e ebgp MED 210 e R4 R2 MED 200 e IX ベスト AS2001 AS2002 AS100 2003/12/2 Copyright 2003 Tomoya Yoshida 153

BGP 経路周りのトレースの方法! トレースのポイント! 何が起きているのかを把握する traceroute をして, どういうルーティングをしているか! その後順にログインして, ルーティングテーブル等を追っていくどこをネクストホップにルーティングしようとしているのか何故下部から経路が配信されてこないのかあるいは, 何故違うほうをベストに選択しているか, など論理トポロジーや物理トポロジーをちゃんと把握した上で調査すること! ピンポンしている場合には, 大抵片方はデフォルトに従って, もう片方は経路を知っているなどの場合が多い ( 経験則 )! GW のベストパスは, 単に GW 自身のベストパスに過ぎない! 基本はリフレクタのベスト経路が伝達されているはずなので, パケットの通り道でどのように見えているかを確認しましょう! こんなことも! ちゃんとルーティングテーブルは正しいのに, 明後日の方向にパケットをだしている (forwarding-table を clear すると直ったとか )! BGP 経路がちゃんとピアから流れてこない ( ハングっている場合もある ) 2003/12/2 Copyright 2003 Tomoya Yoshida 154

bgp deterministic-med! BGP ピア先から受信した経路のうち, 先に同一 AS の経路をまず比較して, そのあとに異なる AS 間の経路を比較する! Cisco は, デフォルトでは有効になっていない! Juniper は,cisco non-deterministic-med を入れると,Cisco と同様に受信した順に比較するようになる 172.16.0.0/16 先にここを比較する R2 R3 R4 R1 2003/12/2 Copyright 2003 Tomoya Yoshida 155

OSPF のループバックのコスト! ループバックアドレスの見え方が異なる! Cisco: R1 が Cisco の場合,R2 から見た R1 の Loopback のコストは 10+1=11 に見える! Juniper: R1 が Juniper の場合,R2 から見た R1 の Loopback のコストは 10 のまま! IGP コストで経路選択をしている場合などは注意が必要 R1(J) R1(C) +1 Cost:10 Cost:10 R2 R2 2003/12/2 Copyright 2003 Tomoya Yoshida 156

トラフィックの設計! In/out でなるべく相殺ができるような収容設計! トラフィックの方向をちゃんと把握する In が多いのか,out が多いのか! その上で, 同一ルータにどのピア先を一緒に収容すれば効率がよいのかを考えて収容分散設計するなど GW からバックボーン向けの回線の効率化! 上流やピア先のトラフィックを分析! Netflow/cflowd を用いて測定! ピア先のさらにその先の AS とのトラフィックが多い " 直接ピア! 明らかにおかしなトラフィックが発生しているっぽい mac-accounting などをやると,static でむけられているっぽい 2003/12/2 Copyright 2003 Tomoya Yoshida 158

フィルタリング! 2 種類, それぞれ 2 方向 (in/out) のフィルタ! 経路フィルタ外部から自 AS 内に対して広報されてくる経路をフィルタ (in) 自 ASから外部 ASに対して広報する際に適応するフィルタ (out)! パケットフィルタ外部から自 AS 内に対して通過しようとするパケットをフィルタ (in) 自 ASから外部 ASに対して通過しようとするパケットをフィルタ (out) 2003/12/2 Copyright 2003 Tomoya Yoshida 159

経路フィルタ! In 方向 ( 外部 AS" 自 AS)! 共通自 AS 経路,Private アドレス, マルチキャスト, リンクローカルなどを遮断! 上流ピア細かい経路は受け取らない (/24 よりも細かいものなど ) ピアに対しては, 基本は AS_PATH フィルタでブロック異常な経路数に対しては, 上限を設けておく (max-prefix など )! 顧客申告ベースの Prefix のみ (exact-much or 該当 Prefix 内 ) を受け取る! Out 方向 ( 自 AS" 外部 AS)! 共通内部で利用している細かい経路などは, ちゃんとはじくような設定 Private などの経路を利用している際には, それをはじくフィルタを設定 remove-private-as! 上流ピア自分と顧客経路のみを配信するような AS_PATH フィルタ AS_PATH と Prefix-length を組み合わせて, 自 AS の場合には, 細かい経路が出ないように,Prefix-length でも制限し, 顧客は AS_PATH で制御 2003/12/2 Copyright 2003 Tomoya Yoshida 160

パケットフィルタ! パケットフィルタを考える前に! まず, 自分が経路を広報していなければ, パケットはやってこない! やってきたパケットに対して, どういう Policy を適応するのかを考えるソースアドレスを偽っている場合 ( スプーフィング ) に対して (in) ソースが Private アドレスの経路に対して (in)! 自分が相手に出すパケットは, 迷惑のかからない程度にフィルタ! 基本は, 自分の身は自分で守る! In 方向 ( 外部 AS" 自 AS)! 共通ソースが自 AS アドレス,Private アドレス. マルチキャストアドレスなどのパケットはフィルタ (urpf チェック )! Out 方向 ( 自 AS" 外部 AS)! 自 AS 内でちゃんと経路を管理していれば, 特段必要ないはず顧客との接続部分ではじいてしまうなど 2003/12/2 Copyright 2003 Tomoya Yoshida 161

Black Hole Routing GW 遮断 GW 遮断 GW 遮断 GW 全 GW の Config(Cisco の場合 ) ip route 192.0.2.1 255.255.255.255 null 0 遮断 GW 遮断あらかじめ仕組みを作っておく必要がある CORE R1 CORE R1 の Config(Cisco の場合 ) router bgp 2003 redistribute static route-map static-to-bgp 1. DOS 攻撃の対象を特定 (171.68.1.4/30) 2. R1にstaticを1 行きる ip route 171.68.1.4 255.255.255.252 null 0 tag 66 3. 2. できったstaticは,BGP 経路として配信. (next-hopが192.0.2.1) 4. GWにあらかじめ設定してある,null 0 により遮断される route-map static-to-bgp permit 10 match tag 66 set ip next-hop 192.0.2.1 set local-preference 50 set community no-export set origin igp route-map static-to-bgp permit 20 2003/12/2 Copyright 2003 Tomoya Yoshida 162

参考資料ー 1 BGPのベストパス選択一覧表上から順に経路比較を実施し, ベスト経路が選択優先度属性内容 1 NEXT_HOP ネクストホップへの到達性があること 2 WEIGHT Cisco 固有のパラメータで, 値の大きな経路を優先 3 LOCAL_PREF Local_Pref 値の大きな経路を優先 4 LOCAL Localで生成された経路を優先 5 AS_PATH AS-PATH 長の短い経路を優先 6 ORIGIN Origin 属性が,igp>egp>incompleteの順に優先 7 MED MED 値が小さい経路を優先 8 PEER_TYPE ibgpよりもebgp 経由で受信した経路を優先 9 IGP METRIC IGPのMetric 値が小さい ( 近い ) パスの経路を優先 10 ROUTER_ID Router-IDが最も小さい経路を優先 2003/12/2 Copyright 2003 Tomoya Yoshida 165

参考資料ー 2 Cisco と Juniper における, プロトコルディスタンス ( ルートプリファレンス ) 値の違い Cisco プロトコル Preference 値 Connected 0 Static 1 EBGP 20 EIGRP( 内部 ) 90 IGRP 100 OSPF 110 ISIS 115 RIP 120 EIGRP( 外部 ) 170 IBGP 200 Juniper プロトコル Preference 値 Connected 0 Static 5 MPLS 7 OSPF internal 10 ISIS level-1 internal 15 ISIS level-2 internal 18 RIP 100 P-to-P 110 OSPF external 150 ISIS level-1 external 160 ISIS level-2 external 165 BGP 170 2003/12/2 Copyright 2003 Tomoya Yoshida 166