---------------------------------------------------- ■Interdomain Routing Security Workshop 12 ■日時:2007/3/9 15:00 - 18:00 ■会場:Cisco Systems 赤坂オフィス ---------------------------------------------------- <Agenda> 1. JANOG19 review and recent BFD standardization/implementaion NTTcom, 鈴木さん 2. From the IX point of view インターネットマルチフィード, 三宅さん 3. BFD deplyment around the world cisco, 河野さん 4. Y.1731 vs 802.1ag JPIX, 石田さん 5. Discussion and Next-step NTTcom 吉田さん ---------------------------------------------------------- 1.JANOG19 review and recent BFD standardization/implementaion NTTcom, 鈴木さん <プレゼンテーション> ・BGPで何十秒も障害が検知できないことを良しとするかを議論したい。 ・Skypeの実験、BGPが切り替わる前に上位レイヤで代替経路へ切り替える  機能あり。 ・VoDはバッファリングされるため、映像には問題ない。 ・リンクダウンが検知されない箇所   スイッチ経由でポートを稼いでいるポイント、IX経由のBGP ・BGPで障害検知を高速化するための解決策  @ 極力スイッチを挟まない。    (メリット) ほぼ必ずリンクダウンを検出可能。          OSPFの場合、DR、BDRのエレクションを考慮不要    (デメリット) ポート単価、トラフィック負荷(←たいしたことない)  A Keep Alive/Helloを高頻度に    (メリット) 実装済み、すぐできる、運用ノウハウがある。    (デメリット) ハードウェア負荷(←経路計算と重なると辛い)    (そのほか) 装置によってMinimam値が異なる。  B BFDを使う    (メリット)・Keep/Helloよりも高速検知(40秒を5秒とか)         ・多くの実装はラインカードモジュールにハード実装          だがC-Planeから分離しているので負荷分散         ・SWを挟むと、Keep−Aliveに数秒かかるのでBFDの方が高速   (デメリット)・C/D分離で負荷分散しても、ASIC化されないとセッション数増          加が辛い                  ・Internet上のBGPなのに認証を未実装。    (その他) ・uRPFとの親和性考慮  CEther-OAM    (メリット)・高頻度にcc(Helloなど)をやりとりしなくても、          Ether-AIS/RDIが         ・障害発生時に飛ぶため、負荷の心配が少ない。        (デメリット)・実装している装置が少ない。       ・MEGレベル0〜7に注意 0〜2網内 3〜4網を跨ぐ 5〜7          ユーザ宅内                   ・通信はレイヤの低い方から切り替わるのがセオリーだが、   SkypeがBGPの切替前にL7の切替があったけど、上位レイヤの切替って   どうなの? <質疑応答>    Q.Skypeが切り替わったのはSIPのような呼制御、またはRTPで切り     変わったのか? A.SkypeはRTPを直接ユニキャストで張っている状態で切り替わった。         Q.BFDのセキュリティについて、DOSなどの攻撃を受けてしまう     可能性は?    A.e-BGPでシングルホップでも攻撃を受ける可能性あり。     (BFDに限ったことではない。)      Q.Juniperのルータは、keep-aliveが20S以下にならない?    A.20s以下になるversionもある。隠しコマンド投入によ6sになる。    Q.Keep-Aliveを短くして何か問題があったか?    A.特に短くしても問題ない     「BGPがフラップするかもしれません」という警告メッセージが     出るだけ       Q.BFDを実網で試験したのか?    A.実網ではないが、それに近い状態で試験を実施。     (ユーザトラフィックが流れていない)    Q.DR・BDRのエレクションが不要、とあるが、設定が必要では?     (複数台の場合は自然と決まるが、2台では設定が必要だったはず)    A.3〜5台で環境を構築している。    Q.BGPのデフォルトタイムを替えている方いる?    A.フルルートしゃべるルートで3秒、15秒という設定をしている。     Keep-Aliveで2年間問題がおきていない。IXでも、問題ない区間は     それで動かしているが、実際にはPeer張れなくなったところもあり。    A.5S,15Sに全部変更したが、Juniperだと20s以下だと受付けない。     相手と自分のタイマー値の見え方が変わることもあった。。     短いHoldtime値を設定すると、拒否するルータもある。     BGPは自分の希望のホールドタイムを投げて、相手がAcceptする値が     帰ってくる仕様。短いのに合わせる仕様もあり。実装によりけり。    Q.システム全体で、何秒で収束させているものなのか?    A.一つのASの中では、そんなに時間はかからない。5秒程度     Rが落ちて、上がったときの伝播時間は10sとかかからないのでは     ないか。   ・インターネット屋として、切替のパフォーマンスをどうしていくかを    考えていく必要があると思う。短くできないなら短くできないで    認識を合わせていけばいい。 ------------------------------------------------------------ 2. From the IX point of view インターネットマルチフィード, 三宅さん <プレゼンテーション>  ・iDC業務で金融系ユーザも抱えている。リアルタイム性の高い通信を行う   ユーザも。装置が故障して3分くらいで切り替わったのだが、バレて   しまった。  ・Skypeにようにインテリジェントなアプリケーションを考えてほしいと   思った。  ・JPNAP IXでの規定によると、BGPの保持時間は180s、keep-alive 90sを   推奨する、   というのはあるが、オペレーションで規制しているわけではない。  ・ユーザ会で振ってみたら、ネガティブな意見が多い。   IX利用時の値は一律には収束時間は個々の問題なので決められないよね。  ・昔から3分て決まっているんだよ、て人もいる。  ・BGPのKeep-Aliveは短いものに引っ張られる。ISPの網に影響するので   あれば考え物、という意見ももらった。  ・Hold-timeは180sが大半、次が90s(Juniperのおそらくデフォルト)、   20s、40sは少数  ・基本的には事業者間の取り決め。相手に連絡して話し合うものかなと。  ・レイヤ2でも冗長化しているので、考えた方がいいというのは同感。  ・冗長化ありだと、光スイッチを使ったもの           高度な冗長プロトコル(RSTP、VSRP、MRP)           伝統的冗長プロトコル(STP)  ・IXはConjectionがあるとか言われるけど、そんなことはない。  ・ループするような故障も最近はそんなにみない。  ・光スイッチを使ったものというのはいくつか例あり(アムステルダムの   お客様など)。  ・双方向で流れていれば、一定時間後には戻る。  ・RSTPでは、そんなにIXで複雑なプロトコルにならないので高速。  ・iDCの立場では、3分より短くしてほしいなという気持ち。   IXの立場では、ISPさん同士で仲良く話し合ってほしい名という気持ち。 <質疑応答>  Q.JPIXの立場として、短くすることについてどうか?  A.Peer to Peerの場合はバイラテラルに。  Q.短くしない最低のところまで短くしない理由は?  A.相手に同意を得るための手間がかかるため。   短くすると問題がないかの確証がない。それを検証するのは後回しに・・   技術的理由は特にない。  Q.グロッサリースタートを使っている人は? A.(いない。)不具合の報告はない(使っている人がいないから)    ・実験NWでは、他のプロトコルと連鎖して時系列で起きたときに怖い。  ・ハードウェア障害で時系列的に起こるケースが怖い。  ・Peerに負荷がかかって落ちると、OSPFに生成エラーが起き、BGPに影響   した例あり。   短い値だとクリティカルになったこともあった。  ・RFCにPeerが落ちて上がるまでに何秒以上必要というタイマがあった   気がする。  ・Trap Dumplingみたいなものを合わせて使う。  ・検出は早く、上がるのは一定以上、という実装があればいい。 <質疑応答> Q.Keep Alive/Holdtime値を決める条件は?  A.レイヤ2の値よりは大きくしなければならない。    この値より小さいと、L2で頑張ってる最中にパタパタしてしまう。   TCPのリトランスタイマより大きくしなければならない。  Q.広域イーサでも、何らかの手段を講じているか。   1s程度の高速冗長プロトコルだとL3はどれくらい?  A.マージン見て5s程度。 ------------------------------------------------------------ 3. BFD deplyment around the world cisco, 河野さん <プレゼンテーション>  ・Worldwideには、BFDの事例はない。  ・VPNでは使われている事例ありだが、Internetでは事例が少ない。   (理由) 相手がサポートしていない、安定性重視、   ロスを検知したとしてもkeep-alive/Hold-downが起こるまで待て、    keep-aliveすら短縮していないのに何でBFDなの?など意見あり。    ・BGPのConvergenceについて、BFDを使う上での考慮点   ・LOCAL    ・L1 下位レイヤの組合せ      下位アーキテクチャのRegilency(光伝送装置、Ether SW etc)      →その収束時間よりも長くすること。      警報転送(Auto Nego、LPS)    ・L2 Link Aggrigationとの組合せ (1:22:10)       バンドルされたリンクで動作するため、コンポーネントリンクに      適用できない。    ・L3 uRPF      echo Packetを廃棄してしまうので注意。    ・L4 IPv6      IPv6用のv6セッションは未サポート       v4のネクストホップをBFDで検出することをWorkAroundとして      検討中。      →v4/v6DUALスタックで同じ動作という前提で。      ・L5 Graceful Start     ・BGPのPeerを切らずにVer.Upできるため、今後必要な機能となる      と思う。共通のCPUですべてのコントロールプレーン処理を実行      する。      Contralized: 共通のCPUですべてのコントロールプレーン処理を      実行する。負荷が高くなることは避けられない。      Distributed:ラインカードで実行できるので、RP処理に影響      されない。Control Plane とFowarding Planeを分離。      Semidedicated:BFDセッションを専用ハード処理する。      (これが理想的)     ・Global Matter(1:30:00)    G1 Route Osallation ・Fast Detection ConvergenceとStability/Scalabilityは拮抗する。      ・Carrier Delayというタイマーを設定する。       ・Exponential BackOff IGPのSPF Delay。      ・BGP Flap Dampling Minimam Advertise interface       Globalにダンプリングをしたとしても、かえって害があるので       やらないほうがいいという方向になっている。      ・山ほど論文はたくさんあるが、確定的なことは言えてない。      ・1990年代から論文があるが、当時とはだいぶ事情が変わっている。       それぞれ比較しても意味がない。     ・BGP PIC(Prefix Independent Convergence)       ・障害が発生して25万ものフルルート書き換えるのは時間が        かかるため、FIGを階層化して、手順を簡略化して高速化         すべてのルータがPICの機能をカバーしている必要がある。        同一機種/OS     <おまけ>      ・BFD for MPLS-FRR trigger        BFDをホップバイホップで走らせるべき。MPLSトンネルを落        とさずに      ・BFD for MPLS-LSP Liveness         BFDをLSPのLiveness検知に使うというベンダもあり。         どっちが良いかは一概に言えない。 <質疑応答>    ・BFDについては、Worldwideでは使われてませんという状況。    ・あまり短い事業者は少ないと思われる。    ・機器のパフォーマンス上、Holdtimeを長くしてくれという要望を     受ける。     Q.論文について、前提条件がどう変わったのか?     A.・CPUの処理能力向上      ・ルートフラップダンプリング やるべき→やらないべきに変わった。      ・シングルベンダ → マルチベンダへ、実装もパラメータもまちち。      ・トリガードカリキュレーション(2002,2003〜)    Q.シングルホップでBFD、Flap-Damplingみたいな仕様が必要では     ないか?    A.マルチホップで使うことになるなら機能的に必要。     1hopならばインタフェースダンプリングでやればよいが、     マルチホップはいろいろ難しいこともあって目途立たず。    Q.Graceful-restartについて、その間はBFD with BGPを止める     というのは?    A.その期間は回復しなくなるのでは?     Graceful-restartする前に出すパケットで開始するのがわかる。    Q.安全のため、Graceful-restartをやるときはBFDを両側で止める     というのはどうか?    A.BFDはユニバーサルで他のプロトコルとも関係しているため、     BGPのための動作、OSPFのための動作というわけではない(ので     止めれない)。  Q.以下、どちらの構成が多いか?  A. |Router| ----- |Router| IXでPeerを2本張るケース |____ |Router|   |Router| ----- |Router|  東阪で分けるケース |Router| ----- |Router| ------------------------------------------------------------------ 4. Y.1731 vs 802.1ag JPIX, 石田さん <プレゼンテーション> ITU-T キャリア中心,ヨーロッパ系 IEEE メーカ系,US系 MEF キャリア,メーカ系,US系 新たな標準 OAM、MAC in MAC イーサのサービスタイプ    E-LAN MP-MP、E-LINE P-P、E-Tree p-mp(ホットスポットなど)    IEEE802.1ag・・コネクティビティチェック、ループバック、トレースルートをL2で   実現。パフォーマンス測定、リンクトレース、障害検知が可能。 ・TTLはOAMだけ。MAC in MACではリジェクトされる。 ・MAC in MACは網内ではループしない。 ・注意点として、IPトレースルートとは異なりCPUがやること。  Fowarding-Planeでの作業ではない。 ・これが実際使えるのか実験した例  |お客様SW|--- 2%フレームロス、8.9,sec delay ---- |SW| |イーサOAM装置|---|NWシュミレータ| <RPM>|NWシュミレータ|  --|イーサOAM装置| <質疑応答>  Q.MEGレベルを指定するのは?  A.リンクトレースはどのドメインを使うかを指定する必要がある。   たとえばCPEのところで投げるとMEGレベルで7だけど、2,3,4は応答しない。   同じMEGレベルのノードだけが反応する。(後で確認する)  ・実装状況について、各ベンダとも実装は出始めている。  ・安価なCPEだと実装はないが、ハイエンドのSWだと可能性あり。    Q.キャリアのための技術だが、エンドユーザが使うことは考えられる?  A.あんまり考えずらい。  Q.キャリア向けの機能だが、全部100M指定にしているのに、ある個所だけ   Auto-Negoだったりする。これを見つけることができるか?  A.途中のSWが対応していれば、切り分け可能。(借用は必要だが)    Q.プロビ、トラブル対応で使いたいが、結果をどう表示するのか?  A.それはAgentの問題。L2においてもSNMPを使うことになる。    ・今年、来年で標準化、実装が進むこととなる。  ・SONETで備わっていた機能が少しは復活してもいいかなと思う。  ・ヨーロッパもトラフィック多いので、日本から積極的に提言していく   くらいの気持ちで進めていく。  ・次回、継続的な検討としたい。 -------------------------------------------------------- 5. Discussion and Next-step NTTcom 吉田さん ・アプリのシビアなNW切替高速化要求に対してどうするか? ・IX事業者の立場からは、ISP事業者さん協議。 ・L2としても考えるところがある。 ・(BFDは)WorldWideではほとんど使われてない。 ・EtherOAMのような切断検知プロトコルもある。 <Next Step> ・誰かbfdでやってみない?  OCNとXXXでやってみるかも・・   (→ 何名か賛同。)   ・Interdomainでどこまで頑張れるか?   インタロップの夜中はどうか?   相手もいる話なのですが、調整してみる。     <次回 Agenda>  ・Fast Convergence  ・4バイトASの相互接続実験の結果を報告できるかも。 <次回日程> 6/29(Fri) --------------------------------------------------------