------------------------------------------------------------------------------- 内容： MPLSでシヤワセになる方法 時間： 10:20-11:10 発表者：松嶋　聡　（日本テレコム株式会社） 記録者：榎本　武司（PNJコミュニケーションズ） MPLS、で動いてます 　大丈夫です動いてます 　- 2000/04からはじめたVPNバックボーンとして動いてる 　- MPLSに起因する障害は今のところない（正確にはないようにしている） 　- しかし、トラフィックエンジニアリングは運用していないので分からない 実のところは？ 　いまだTagSwitchingを使ってる 　- しかしパケットはMPLS、シグナリングだけTDP 　某社ルータが増えていく 　- 某社ルーターがどんどん増えている 　- さまざまなベンダーがLDPをサポートしてくれるとうれしい 　- RFC2547はいまだに某社しかない JANOG MPLS-WGから 　9月からJANOGにMPLS-WorkingGroupが出来た 　- 色々あったが、とりあえずMailing-Listのみの軽めのWG 　- 参加者は310名（発言者はおよそ10名だが） 　動機は？ 　- JANOGにMPLSをフォーカスして議論できる場がほしかった 　- 英語が苦手な人にも参加できるMPLSの話しがしたかった 　それなりに盛り上がったと思う。 　- マニアック過ぎたかもしれないが、突っ込んだ話しが出来てよかった WGの成果 　MPLS−VPN 　- RFC2547のASをまたぐVPNの実現方法について議論された 多数のプロバイダをまたぐVPNの実現方法について議論された 　トラフィックエンジニアリング 　- TEをうまく実現する為のIGPの拡張について議論された 　　RSVP Extensionなどで設定したTE LSPをIGPで扱う為の拡張 MPLSの課題 　- MPLSが抱える泥臭い課題について議論された 　　どうやら泥臭いところで問題になってる 　- MTUサイズ　ラベルをパケットの前にいくつもつける事ができるので 　　際限なくつけていたらいつかあふれてしまう 　- ICMPの返し方 　　LSPを張ってしまうためラベルだけしか見ていないので 　　間を通過するルータの途中でラベルが落ちてしまったときに 　　ICMPをどこに返すのか分からなくなる 　- TTLの処理 　　IPのTTLとMPLSのラベルの中のTTLとどういう風に同期を取るのかややこしい 　- LSPが切れたとき 　　切れたときってどのように動くのかが疑問 　- Internet Draftがあいまいなので実装に差が出るのでは？ MPLSでシヤワセになる方法 　MPLSのシヤワセって？ 　- トラフィックエンジニアリングをうまく利用してバックボーンのトラフィック 　　 をうまく使うとかVPNをキャリア側でアウトソースしたり、BGPをルータから 　　 開放できる　後はあなたしだい。 　- MPLSでシヤワセになる方法とは？ 　　安心して、仲良く、安く使える方法 　シヤワセのつぼ 　- インターオペラビリティ 　　いろいろあるとはおもうけど、LDP/CR-LDP,RSVPなどはもちろんだけど。 　- オペレータの視点からは 　　やっぱり泥臭いところが気になる 　　実際運用するのは私達だし 　　MTU,ICMP,TTL等 　　地味なので見落としがちなのでやばい 　- こういうところからシヤワセになる方法をかんがえよう MPLSの泥臭いところ 　まずは現状を把握しましょう 　　 　MTU - ラベルがつくためMTUサイズがあふれる 　　ICMP問題につながる 　ICMPの返し方 　- MPLS(LSP)にのってからでもICMPを返したいことがある 　　MTUを超えていたりTTLがなくなったりしているとどうして 　　送れなかったか送信元の人がわからない 　でも 　- MPLSコアルータは必ずしもフルルートを持っているわけではない 　　すべてのパケットを運べるわけではない 　- フルルート持っていないことがメリットでもある 　TTLの処理 　- 基本動作 　　パケットがMPLSドメインを通過しても、TTLはホップ毎にDecrementされる 　　MPLSのTTLをDecrementしている 　- １hopモード 　　LSPでTTLを１つだけ減らすことも認められている 　　LSPをVPNやトンネルとして使うときも便利 　　VPNを使えばお客様がキャリアを意識せず使えるし、TTLも減らない 　　ところが、実現方法は書かれていない 　- 受け側のMPLSルータで理解できる方式でTTLを処理してしまう 　LSPが切れたときの動作 　- LSPが切れてもIP的にリーチャブル、ゆえに経路は消えないまま 　　トラフィックは落ちつづけてしまう 　　非常に困る MPLSの泥臭いところ（２） 　MTUサイズ 　- 現状での解決方法　一応ある 　　BGPとして必要な分だけMTUを大きくしておく 　　Etherでそんなことできるの？ 　　最近は対応したインターフェースとスイッチがある 　- 根本的な解決にはまったくなっていない 　　さっきも言ったとおりラベルをたくさんつけられたらどうしよう 　　いったいMTUのサイズをいくつにしておけばよいのだろう 　　Path MTU Discoveryを利用する？ 　ICMPの返し方 　- Internet Draftには２通りの解決方法が載っている 　　IGPのデフォルトに従う 　　　ICMPを返したい気持ちになって自分のルーティングテーブルをLoockUpして 　　　デフォルトルートがあればそれにしたがってパケットを送れる 　　　しかしVPNのバックボーンでは意味がない 　　LSPに沿って道なりに返す 　　　VPNバックボーンでも一応ICMPを返すことができる 　　　実装がMUSTになっているわけじゃない 　TTLの処理 　- 問題は1hopモード 　　インターネットドラフトにかかれていないモードのときに問題 　- 具体的な実現方法が書かれていない 　　各ベンダー独自の工夫がされている 　　実装されているかどうか聞かないとわからない 　- 基本動作での混在 　　LSP毎にTTLの処理を変えるなんてできない 　　おまけにシグナリング　たとえばLDPやRSVPにTTL処理を扱う 　　パラメータはない 　- どうしても１hopモードが使いたかったら？ 　　現状は１つのベンダーにそろえるぐらいしかない 　LSPが切れたときの動作 　- この問題は以下の条件で起こる 　　LSPでないと運べないトラフィックがある 　　LSPが切れたことをエッジルータが知らない　知ることができない 　- LSPの状態を監視する仕組みが必要 　　たとえばkeepalive、OAMで監視する必要がある 　- LSPの状態をルーティングに反映させる必要がある 　　ただ結局ルーティングに反映させないといけない 　　たとえばBGPを使っている場合はwithdrawnしたりnotificationしないといけない 　- でもそんな実装はない 果たしてシヤワセになれるのか 　結構厳しいかも知れない 　- MTUサイズ問題は 　　BGP対応で何とかやっていきましょう 　　根本的な問題解決ではないけど 　- ICMPの返し方 　　すべてのベンダーで実装されているか調べてみないとわからない 　- TTLの処理 　　1hopモードでは実装に差が出そう 　- LSPが切れた時の動作 　　多分今のところどこにもない 　シヤワセへの道　どうすればシヤワセになれるかステップを考えていく 　- Step.1 　　まずこれらの問題があることを知っておくことは非常に重要である 　　特に今の段階　実装がされていなかったり、仕様があいまいだったり 　- Step.2 　　こういう問題があるが、あなたの欲しいネットワークがこれらの問題に 　　引っかかってしまわなければ問題ないが、引っかかってしまえば問題 　　ならば問題をクリアできるベンダーを選ぶべき 　でも、こんな状況はあまり続いて欲しくないので、いーかげん 　どうにかされてもいい問題ですよね 　- Step.3 　　これらの問題を解決／柔軟に相互運用できる設定が可能になる 　たぶん 　　こういう環境になることを祈るしかない 　　こういうことを満たしていることがMPLSを選ぶ新たな基準になるかも 　シヤワセは歩いてこない　　歌もあるので 　- たとえばさっき言ったようなのだとかなり弱い人任せで 　　誰かちゃんとやってくれるのか？　そんなこと誰もわからない 　　せっかくWGで議論されたのでオペレータからの要求を伝えることができない 　　なんてさみしい 　- ここはいっぱつ 　　Internet Draftにまとめてみようかなと思ってる 　　書けば世界中に伝わるのでオペレータの意見が正確に伝わる 　　書いたことないのでトライすると楽しいかもしれない ということで乞うご期待　楽しみにしていてください 質疑応答 Q： Path MTU Discovery がたとえばあったとして持ってるのはおそらくMPLSを 　　しゃべれるルータだけだと思うが、カスタマーエッジとその間ではMTUの実装段階が 　　どこにあるのかきっとわからない。ドントフラグメントを立てたらどっかで 　　つっかかえてくる恐れが非常に大きい。できればカスタマーエッジ同士でMTUサイズを 　　どっちで出せばいいのか知りたい。あるいは、カスタマーエッジは好きなMTUサイズで 　　カスタマーエッジの背後のネットワークがそのMTUサイズで受けて頂戴と出してきたら 　　MPLSルータがちゃんと聞いてあげて欲しい、そしてそのサイズのMTUで受けたことを 　　言って回って欲しい。MPLSルータが動的にMTUサイズを広報できるとすごくうれしい。 A： MTUサイズを簡単に広報できる実装は今はない。ベンダーによってはFixされていたり 　　設定を変えるリアロケーションが必要になったり、結構ややこしい。 　　ただMTUサイズに関しては、キャリアとかISPがバックボーンをエンドのお客様が 　　意識しない、キャリヤやISPの中でやるべきこと。 　　今はないが実際にそういう仕様ができてきているのでそれに期待してほしい。 　　MTUについてコメント 　　　最近だとMTUを広げてもそんなに問題ないメディアもあると思うけど、 　　　たとえば10MのEtherとかの場合だとMTUサイズは綿密に決まっているので、 　　　広げてしまうと非常に問題が出てくるので、単純に広げるのではなくて 　　　考えてやらないと問題になる。ベンダーにちゃんと聞いて作って欲しい。 　　上記のコメント 　　　100MのEtherで通るなら10MのEtherはレガシーインターフェースと決め付けて 　　　MPLSに10Mはあってはいけないとか言ってもいいかなと思います。 Q： 同一ASの中だと自分の配下なのでどうにでもなるのでVPNを作るときのポリシーは 　　簡単に作れると思うが、技術的にAS間でVPNを張ることは可能かもしれないが、 　　現実的な会社間のいろいろな制約をなんとかする実現方法はないか？ A： 実はAS間でVPNを張れる仕様を実装したものが出てきたのはつい最近で、実際ASを 　　またいでVPNを張ったトラフィックとか経路をどういうポリシーでもって運用すれば 　　よいのかわからない。なぜかというと経路の特性だとか、数だとかはVPNごとに 　　ユニークであり、キャリアのポリシーをそこに当てはめることができないので、 　　相手からくるものを受け入れるしかないと思われる。だからもう少し検討が必要。 Q： 1hopモードについての質問だが、一つ目に1hopモードにしたほうがいいか、それとも 　　普通のモードのほうが良いか。二つ目に1hopモードの各ベンダーの実装状況を教えて 　　ほしい。 A： 1hopモードのほうがいいと思う。ただ、Internet上にMPLSバックボーンがあると 　　基本動作で動いたほうが相手もきちんと見えるのでトラブル解析しやすいと思う。 　　お客様に意識させないという意味で1hopモードのほうが良いと思う。 　　WGで出た話だとC社は最初の入り口で普通にTTLを1つ引く、それをMPLSのTTLに渡す。 　　詳細ではないが、出口でTTLの少ない値をとる。必ずしも1hopモードを意識していない。 　　J社は入り口でTTLを引かずに出口でTTLを引く。 　　だから多分、C社とJ社を入りと出に置くと不幸になる。