================================================================================ ◆Title: パネル形式チュートリアルセッション 「マルチホーム解剖学-実例とその分析-」 ◆時間:10:00-11:30 ◆コーディネーター： 荒野高志(NTTコミュニケーションズ ) ◆発表者(パネリスト): 荒野高志(NTTコミュニケーションズ ) - イントロダクション 前村昌紀(NEC) - マルチホームに関するいくつかの観点 山口二郎(IIJ) - マルチホームの具体例 中川郁夫(INTEC) - JEPG/IPマルチホームワークショップの報告 ◆記録者: 藤原一泰(C&W IDC) / 松川良樹(NEC) ================================================================================ 【 荒野高志(NTTコミュニケーションズ ) - イントロダクション 】 マルチホームの動機 ・ 可用性 いわゆるBACKUP ・ 接続性 学術系から商用に接続したいときとか ・ 宣伝 「うちのNetworkは頑丈です」といったような宣伝 AS取得の数について見てみると、アメリカでは915/年、韓国では10/月、これには企業な ど も含まれている。一方、日本では21個/年と非常に少ない。 急増するAS、さまざまなユーザニーズの発生。 このような条件を抱えながら、マルチホーム手法についてのなんらかの体系化が必要と考 えられる。 前村さんには、IPアドレスやルーティング 山口さんには、マルチホームの実例 中川さんには、IPv6になるとマルチホームはこうなる。。 というような事について語っていただきます。 ----- 【 前村昌紀(NEC) - マルチホームに関するいくつかの観点 】 JANOGメーリングリストでRFC1930問題などについてのドキュメントを、12/8に発行した。 今回はアドレッシングと、PureにLayer3という観点からマルチホーム構成について分析す る。 ● Addressing マルチホームする際、運用するIP Addressによりいくつかのケースが考えられる。 それぞれのケースでメリット・デメリットはある。 ・それぞれのISPからアドレスをもらっている ホストレベルでは "シングルホーム" となる ・1つのISPからのみアドレスをもらっている ISP-AからもらったアドレスブロックをISP-Bからも広報してもらう必要がある。 CIDRによるAggregationの観点から言えば、通常、ISPは他ISPのアドレスブロック は広報しないし、また他のISPのアドレスブロックを広報したがらない。 ・自ら独自で取得したアドレス BGPで運用する（ASを取得する/Private ASを使う） outboundのトラフィックがコントロールしやすい ● マルチホームしようと思う場合には、 - IP Addressをどうするのか - AS番号の取得をどうするのか についての検討がある程度必要である。 ・IP Addressについて 長いプレフィックスを持つものは、今後フィルタされる可能性がある。現状では、 /20 より長いネットワークプレフィックスをアナウンスされた場合にFilterする 　　 Upstreamもある。（Sprint, AGIS） また、192.xxx.xxx.xxxの前半などはAggregateしようがない領域と言われる。 今後、どういう方向となるのかは分からないが、ルータが辛くなると一律で/20より 　　 長いものはFilterしようよという動きになるかも。。 現在では、でかいPIブロックをもらうのは大変。 APNICでは、比較的容易。/20で US$ 8,000 程度。 ARINでは、PAからPI(Provider Indipendent Address)の移行となる。 その際Re-Numberingが必要となる事もある。 JPNICでは、/19をリザーブした上で、/22からの割り当てとなる。 APNICの最近のドキュメントでは、"One year lease"という考え方が記述されてお り、これは、アドレスブロックを1年間リース契約するようなやり方。 歴史的割り当ては許されなくなる可能性がある。 ・ASについて - ASを使わないとすると、 　 基本的にトラフィックコントロールはできない - ASを使うとすると、 　 Full-Routeを自らのPolicyに従いコントロールした運用ができる。ただし、 Upstream向けの複数回線を意図した通りに使用するなどといった事は非常に難しい。 例えば、6Mbpsの2回線を厳密に4.5Mbpsずつバランスして使用するなどのコント ロールは、例えASを使ってBGPでポリシングしようとしても難しい。 ● なぜ、日本ではAS取得が少ないのか？ 日本では「ASをもらうのは難しい」と思われている。 - BGPスキルの欠如？？ … 最近良い本が出ている。 - BGPを使う場合は一つ大きなルータになる。 … 確かに。 - ASが足りない？ … 1年に1600 新規ASが増えている。 リニアに伸びたとして枯渇は40年後か。 ならば、AS枯渇問題は大丈夫なのではないか。 以上でもなぜか「ASをもらうのは難しい」と思われている。 - 日本の回線事情ではなかなかT1レベルなどの太い回線が用意できない。 回線が太くなって、ルータも今より格上の高価なものをどかんと打つようになれば AS取得、MULTIHOMEにも拍車がかかるのかも。 ● 階層的経路制御について CIDRでのAggregationの基本概念自体はマルチホームを想定していない。これは小さいア ドレ スブロック（PI）に対してマルチホームを許していない、といったとり方もできる。 ----- 【 山口二郎(IIJ) - マルチホームの具体例 】 時間的な理由で非常に概要的な説明になるが。。。 ● マルチホーム構成の実例と分類 ・東阪IPルーティング型 東京、大阪でそれぞれISPに接続。 東阪間はプライベートな専用線で接続。 どれがこけてもバックアップがとれる堅固なNETWORKではある。 ・東阪Firewall型 FW自体にDynamic Routingを通してやらねばならない。 FWの機能にもよるところあり。 ・束ね型 ISP、CUSTOMERでルータは1台ずつ、回線部分のみを2重化。 キャリアを分けることに意味がある。外資系企業などが好んで使っている。 #キャリア事情が悪いところには好まれる!? Route-Cache （特定のdestinationに対して一定時間同じ回線を利用する）問題など もあり、必ずしもロードバランスできるという事ではない。 ・アプリ型 Squidと、2つ以上のISPからもらったPAで協調運用。 そのままではBACKUPがとれないので、バックアップ用のエージェントやその他の 工夫が必要。但し、ダイナミックルーティングを使わないのでオペレーションが楽 。 E-Mailは、複数のMXや、Fallback MX等を用いてBACKUPを実現できる。 ・老舗大学型 Addressは歴史的割り当てを受けており、Class BなどのPIを持っている必要がある 。 IPレベル（Layer3）でバックアップできる。Private BGPを用いて学術系と商用系に トラフィックをコントロールできる。 ・文系大学型 PAしか持っていない組織にも適用できる。既存のネットワークを極力 変更せずに、商用ネットワークとのマルチホームを実現する。ルータ を商用ネットワーク側に設置し、NATとPrivate BGPを持ちいてバラン スとバックアップを行なう。外部からアクセスさせるmailやDNSサー バには特殊なdefaultを設定するなど、運用上注意が必要。mail,dns などのバックアップはできない。 ・理系大学型 文系大学型に加えて、mail,dnsなどのサーバのアプリケーション的な バックアップが可能。学術系、商用系にそれぞれのセグメントを設け るため、ルータの台数が多く、複数のルータでPrivate BGP、IBGPな どの運用が必要となる。ネットワーク運用力のある大学がこのような 構成を選択している。 ・その他の型の併用 総合大学型（アプリ型） 学術系、商用系との間にPorxyを設置し、Private BGP、ospfなどを用 いて学術、商用とをバランスする。アプリ型でのSquidでの運用と似 たような形態だが、Squidとは異なって簡単にBACKUPすることができ る。proxyに経路情報を流し込む必要があるため、サーバ屋とルータ 屋がいっしょに作業する必要がある。 銀行型 WWWなどのコンテンツ配信のバックアップを行なう。それぞれのPAセ グメント上にWWWサーバ等が設置されているような環境において、DNS のNSレコードのラウンドロビンを利用する手法。片側の接続に障害が 発生したとしても、DNSのTTLが経過した後は、DNSの実装により必然 的にトラフィックは迂回する事となりBACKUPも実現できる。そこそこ 負荷分散できる。 WindowsなどTTLを考慮していないクライアントの場合はリブート等で 復旧できる。東阪Firewall型、アプリ型、理系大学型の併用も可能。 構成はお金などの事情で変化する。 東阪Firewall型 アプリ、理系大学型の併用になる。。お金次第。 マルチホーム考える際に見積もらねばならないことは、 - NATとアプリケーション - マルチホーム可能なISPの選択 - トラフィックパターンの把握 Outboundが多い…理系 Inboundが多い…銀行 - 目的は「トラフィック分散」なのか「バックアップ+トラフィック分散」なのか？ など、必要なもの、不必要なものをきちんと理解し、最適なソリューションを検討すべき で ある。 ----- 【 中川郁夫(INTEC) - JEPG/IPマルチホームワークショップの報告 】 JEPG/IPワークショップが12/9に開催された。その中から。。 また、IPv6の場合について紹介する。 マルチホームは難しい技術である。 現状、ベストな解というものはなく、それぞれのケースによってベターな解も異なる。 しかし、ここでは「マルチホームする」ことを前提とする。 ● IPv6の世界ではマルチホームはどのように考えられているのか IPv4の場合とそれほど違わない。 ・1つのInterfaceに複数アドレスを割り当てる事が盛り込まれている。 ・PAアドレスしか存在しない。Aggregateは必須となる。 ・その他、自動的にRu-Numberするといった技術なども考えられている。 ・現実的にはTunneling等の手法を用いて、複数のISPから割り当てられたPAアド レスをアナウンスする方法などが考えられる。 ● その他の問題 - お金 - 既存のネットワークをさわりたくない - 信頼性 take overまでの時間、負荷分散のニーズ - 運用するアドレスによって実現方法が異なる - 評価 見積もりは難しい コストの算出、導入後の評価などは難しい。 どれほどのコストメリットがあるのか計れない。 など、次回のワークショップに向けて検討中。 ----- 【 まとめ 】 ● 荒野さん いろいろな課題のうち、ユーザの要求や条件の分類、その解の整理などについては、 だいぶまとまってきた。残されている課題は、２つある。 ・ひとつは評価、コストの問題 ・もうひとつは、BGPマルチホームについてのアドレス割当てとからんだ問題 である。ここでは、後者について議論したい。 歴史的割り当てを受けたアドレスを持っている人はいいでしょう。また、ASも特に問 題なくとれるでしょう。ただ、大きなPIアドレスをとるのは難しいのが現状。 まず、ひとつのネタを提供。 IXやTLDサーバなど誰もが必要とする公共のネットワークには 小さいブロックでも、独立した形としてのアドレスの割り当てを行うという アイデアがある。現在世界中で広く検討中。アジア太平洋地域では 次回3月初めに韓国で開催されるAPRICOTで、議論が行われる予定。 ただ、このアドレスは広く企業に解放されるものではないだろう。 ● 前村さん 現状では、マルチホームをしたいという人に対してアドレス問題などがあって難しいと言 わざるを得ないケースが多い。そういった人たちにはClass Bをあげればいいじゃないかと いう話もあるかもしれないが、、それはやはりアドレスの無駄使いだろう。現実的に小さい ところでは、マルチホームを行わないというのも選択肢の1つ。 ● 山口さん Multihomeを考えるとき、やはりAddressの点などでの既得権問題はある。ただ、いざやる となると勿論、コストもかかるし、運用できるスキルを持った人間が必要になるなど、難し い点も多い。Internet上にはそういった理由できちんと経路制御できていないルータが存在 しているのも事実。BGPとか経路制御に頼るのが問題かも。 ● 中川さん 実際にマルチホームに掛かるコストについて共通認識がなく、便利、便利と言われるが 、リスクなども考えて、きちんと議論すべき。手間とリスクをユーザがきちんと理解した上で 、MultiHomeするというのなら是非やるべきである。 ----- 【 Q&A 】 Q.JPNICでは節約、節約というがそんな事を推奨していると、INTERNET自体の発展もない 　んじゃないのか？　MultiHomeなんかは当たり前になってきており、どこもどんどんや 　っておりRouting Tableも増大し続けている。NATを使用しなければいけないというのは MultiHomeとは言えないでしょう。マルチホームといえない物をマルチホームと言って 議論するのはおかしい。MultiHomeするのならアドレスもASもきっちりもらってやるべ きだろう。なぜ、日本ではそういった流れにはならずに、MultiHomeは難しい、アドレス は節約しろなどと言うのか？ 日本だけ世の中の潮流に逆らって行儀よくしろと言ってい るような気がするのだが。 A.基本的にはAPNICやARINも同じポリシーでやっており、運用に関してはARINなどの方が 実際にはJPNICなどよりはずっときびしい。 　今日のRouting　Tableの増大はINTERNET自体の成長に依るところも大きい。 　Sprint、AGISなどでは爆発的なRouteing　Tableの増大を防ぐために/20等でのFilterも している。 Q.MultiHomeしてどれだけメリットがでたのかという"評価する技術"がまず必要だと思う 。現状、そういった評価できるツールがなにもないと思う。そういったものがあるのなら 　教えてほしい。また、ないのならどなたか頑張って作ってほしい。 A.あるホストへのresponse　timeぐらいなら評価を実施したケースはある。トラフィック 　がきちんとロードバランスしているのかなどといったレベルまでは一般的なユーザはあ 　まり気にしないというのが実情かもしれない。誰がお金を払うのかを考えると、その観 点からの評価が必要である。 T3が2本があったら使い切りたいと考える。コストの問題は大事。また、マルチホーム を受ける立場の議論もある。お客に「グローバルASを使って、マルチホームをやりたい」 と言われたときにどうゆう対応があるか。 ポリシーといっても、BGPはバランスするだけでは使えない。 ユーザはそのような現実を持ち出されてがっかりされるかもしれない。 今後もJANOGのMLで議論を進めたい。