Comments
Description
Transcript
シスコの CRS-1 が試験に合格 40 ギガルータの試験結果
NETWORKING THE TELECOM INDUSTRY www.lightreading.com November 30, 2004 シスコの CRS-1 が試験に合格 40 ギガルータの試験結果 はじめに 「シスコシステムズ社が 5 億ドルの費用、4 年間の研究開発、そして 500 名の人員を投じて開発した CRS-1 ルータを試験するには、どれほどの努力が必要となるだろうか？」 今年初め、シスコ初（また世界初）の 40 ギガ対応コアルータの試験を Light Reading から最初に依頼さ れたとき、私たち European Advanced Networking Test Center AG（EANTC）のスタッフは頭を抱えま した。 私たちが不安を覚えたのも当然のことでしょう。40 ギガビット／秒の IP トラフィックの試験は、控え めに言っても簡単な作業ではありません。プロジェクトメンバーの 1 人はその作業を「空中で雷を測定 するようなもの」と言っていましたが、これは今回評価対象となった装置のスピードとパワーを見事に 言い当てています。次の事実は私たちが直面した困難を裏書きするものです。 • 試験方法の考案だけで 2 ヶ月以上かかりました。 • 共同で試験を行ったパートナーの Agilent Technologies 社は、試験計画の要件を満たす試験手順を作 成するため、オーストラリアとカナダの同社の研究所で 5 人月相当の労力を投入しました。 • 試験自体は 2 週間で 140 時間をかけて行われ、計 11 名のエンジニアが参加しました。 • 50 以上の Agilent OC-192（10 ギガビット／秒）ポートに加えて、大変希少な OC-768（40 ギガビッ ト／秒）のテストポートを 2 つ用意して試験を行いました。OC-768 のポートは現在 Agilent 社がそ れを製造している唯一のアナライザベンダーであり、 このモジュールが世界で 10 体もないことから、 それを確保すること自体容易なことではありませんでした。 • EANTC の試験文書はエクセルのシートで合計 70 万行以上になりました。 シスコのまったく新しい CRS-1 コアルータの単独検証試験に投じた努力は、結果的には十分報われる ものとなりました。この試験は、40 ギガビット／秒の SONET/SDH インターフェイスを初めて試験し たこと、エミュレーションによるインターネットパケットのスループットとして 1.2 テラビット／秒以 上を初めて実現したこと、Cisco CRS-1 の独自の試験結果を初めて公表したことなど、いくつかの点で 業界初となりました。 シスコルータの試験結果を簡単に述べると次のようになります。「CRS-1 の性能はきわめて高く、将来 にわたってサービスプロバイダーの要求に対応できるスケーラビリティを備えていることが実証された。 テラビット／秒の帯域幅、何百万ものルート、何千万もの IPv4 および IPv6 フローに対応できた。シス テムが高負荷で稼動中であっても、ソフトウェア更新時のトラフィック瞬断はわずか数ナノ秒にとどま った。その高いアベイラビリティには脱帽せざるを得ない。また、そのスループット能力をマルチシャ ーシ構成によって拡張できることも確認できた。」 EANTC は、CRS-1 が今後のルータの性能やスケーラビリティが目指すべき次のマイルストーンである ことが今回の試験で証明されたと考えています。 1 40 ギガ試験の必要性 IT 業界の成長にはかつてほどの勢いはないにしても、インターネットの成長はとどまるところを知りま せん。多くの大手サービスプロバイダーはこのところ新たなコアネットワークインフラストラクチャへ の投資を控えていますが、インターネットブーム時に設置した装置の多くが償却され、またキャパシテ ィに対する要求が高まるにつれ、次世代バックボーンルータの配備を検討しないわけにはいかなくなっ ています。 このため新たなレベルの転送速度とインターフェイスを実現する新しいモンスターボックスへの需要が 生まれています。超広帯域 40 ギガ Packet-Over-Sonet（POS）を駆動するハードウェア製品は、複数 の 10 ギガビット／秒インターフェイスを実装する製品に比べて、管理性を高め、光ファイバインフラ をより効率的に利用するという、サービスプロバイダーの現在のニーズに対するソリューションを提供 できるポテンシャルを持っています。しかも 40 ギガには、今後のキャリアネットワークで確実に活用 できるという利点があります。通信ネットワークの成長の歴史を見れば、こうした技術に対する市場は 現在は小さくても、やがてその規模と重要性が増すのは確実です。 この市場に向けたシスコのソリューションである CRS-1 は並列パケット処理技術を用いており、その 一部は高度に特殊化した Application-Specific Integrated Circuit（ASIC：特定用途向け IC）内に実装さ れています。結果として、各ラインカードおよびファブリック全体を通して、ノンブロッキングかつ信 頼性の高い並列パケット処理を保証するアーキテクチャを実現しています。 シスコの主張の検証 Light Reading の当初の目的は、CRS-1 を特に試験対象とするものではなく、あらゆるベンダーの 40 ギ ガ対応ルーティングプラットフォームを試験することでした。 しかし入手可能な 40 ギガ対応製品を分析した結果、シスコの CRS-1 キャリアルーティングシステムだ けが残ったのです（シスコの主要なライバルである Avici と Juniper の両社は 40 ギガ対応製品を「準備 中」とコメント）。 同様に CRS-1 の試験に使う装置の選択も単純でした。40 ギガの分析が可能なテスターは、Agilent の N2X マルチサービス試験ソリューションしかありませんでした。 試験する製品と使用するテスターを決定するのは簡単でしたが、シスコシステムズの最高峰ともいうべ き製品を Light Reading が中立な立場から評価することを認めるよう同社を説得するのは困難をきわめ ました。 この試験には多くのことがかかっているため、こうした困難は予想されていました。CRS-1 はシスコと そのカスタマーにとって大変重要な製品です。初めての 40 ギガビット／秒ルータであり、まったく新 しい「キャリアクラス」の IOS ルータコード（最終的にはシスコの他のルータプラットフォームへの移 植を予定）を使った初めてのシスコルータでもあります。また試験は、シスコが通信事業者のニーズを 真に理解し、次世代の音声、映像、データサービストラフィックを扱う高度な通信ネットワークの基幹 技術を提供できることを通信事業者側に理解させるための重要な試みとして、きわめて大きな意味を持 っています。 シスコと Light Reading の間で国連審議なみの長々とした交渉が数ヶ月間行われました。声を荒げた感 情的なぶつかりあいもありましたが、アメリカ式交渉のすばらしい伝統に従い、ついにはいくつかの基 本原則について合意に達しました。重要な合意点には以下のものがあります。 • ベルリンの EANTC ではなく、カルフォルニア州サンホセのシスコの施設で試験を行う（CRS-1 の移 動には多大な装備と多数の技術者が必要という論理的な理由から Light Reading 側が譲歩）。 • Light Reading のあらゆる試験にならい、中立性を確保するため、シスコは試験プロジェクトに一切 資金を提供しない。 • シスコは結果の公表前に試験の生データを確認して不備を指摘できるが、製品性能に関する EANTC の分析結果を読むことは禁じられ、また結果の公表に関していかなる「拒否権」も持たない。 2 最も重要な点は、試験とその結果が実際のネットワーク条件や事業者要件を反映した現実的なものとな るよう、主要サービスプロバイダーが試験方法のピアレビューを行うことに関係者全員が合意したこと です。 試験方法全体は Light Reading のウェブサイトからダウンロード可能で、サービスプロバイダーのフィ ードバックは 20 ページに記載されています。結果的に試験方法は Cisco CRS-1 に特化またはカスタマ イズされたものではなく、基本的な物理レイヤ条件が一致する装置であれば適用可能なものとなりまし た。 Light Reading はサービスプロバイダーのフィードバックに基づき、IP コアバックボーンに対するサー ビスプロバイダーの現在と将来の要件を中心に試験すべき 8 つの重要分野を特定しました。 • 実際のトラフィックパターンを使い 1500 万ユーザをエミュレートした場合の IPv4（現在のインター ネットプロトコル）の転送性能 • IPv4 と IPv6（今後のインターネットプロトコル）混在時の転送性能を検証し、ルータが次世代イン ターネットプロトコルへの移行に対応できるかを確認 • アクセスコントロールリストや未承認トラフィックのロギングなどのセキュリティサービスや、QOS 分類を追加した場合の転送速度への影響 • eBGP（exterior Border Gateway Protocol）で他のバックボーンルータに接続して 150 万以上の個別 ルートを交換する場合のルーティング情報アップデート性能 • 300 マルチキャストグループでマルチキャスト 70%ユニキャスト 30%のパケット混合負荷を与え、 TV 放送やポイントツーマルチポイント企業アプリケー ションなどのマルチキャストアプリケーションに対す るスケーラビリティを検証 • 数百万ユーザに対するサービスをエミュレートして COS 実装を評価 • 今日のコアルータに欠かせない無中断によるソフトウ ェアおよびハードウェア交換の検証 • MPLS（Multiprotocol Label Switching）コアネットワ ーク内で動作するラベルスイッチルータとしてのシス テム機能を評価するための MPLS トンネルのスケーラ ビリティ試験 Cisco CRS-1 には他にもやりたくとも現実には不可能な 試験もたくさんありました。特に複数の Cisco CRS-1 で ネットワークを組んで試験を行えば、現実的な条件下で の CRS-1 の性能について貴重な知見が得られたはずです が、利用できる Cisco CRS-1、試験装置、時間と資金と いったリソースの都合上かないませんでした。前述のよ うに 1 台の CRS-1 の試験でも精一杯だったのです。 Cisco CRS-1 の試験結果ですが、率直に言ってその速度、 スケーラビリティ、柔軟性、システム全体の堅牢性には 驚かされました。Light Reading の試験結果は、CRS-1 が真に 100%キャリアクラスのルータであることを示す ものです。 Cisco CRS-1 （中央のラック）は一見大きく見えるが、 Agilent N2X（左右のラック）のスタックと見比べてほしい。 3 主な結果 • 1500 万ユーザ（フロー）のエミュレート時、OC-192 および OC768 インターフェイス上で、シング ルシャーシ構成の場合、合計 9 億 2900 万パケット／秒（640 ギガビット／秒）、マルチシャーシ構成 の場合 18 億 3800 万パケット／秒（1.28 テラビット／秒）のワイヤスピードの IPv4 転送性能（試験 事例 1 を参照） • IPv4 が 85%、IPv6 が 15%の混合トラフィックでワイヤスピードの転送性能（試験事例 2 を参照） • 各ポートへの 5,000 のアクセスリスト、アクセスリストのロギング、QoS 分類の追加も転送性能に影 響なし（試験事例 3 を参照） • 合計 150 万の IPv4 および IPv6 ルートから 50 万のルートを別のポートに迂回後わずか 18 秒で再収 束（試験事例 4 を参照） • 合計 400 ギガビット／秒のマルチキャストスループットで損失ゼロのマルチキャスト転送性能（試験 事例 5 を参照） • ワイヤスピードでの COS 試験ではプレミアムクラス（絶対優先）と均等化キューイング（weighted fair queuing）が帯域幅固定時およびトラフィックバースト時どちらでも仕様最大値まで可能（試験事例 6 を参照） • ソフトウェアパッケージアップグレード時のサービス断はわずか 120 ナノ秒。ファブリックカード交 換以外のすべてのハードウェア交換が無中断で可能。8 つのバックプレーンファブリック中の 1 つに 重大なエラー発生後の復旧時間は 0.19 秒（試験事例 7 を参照） • 優先フォワーディング（EF：Explicit Forward）とベストエフォートによる DiffServ 時の正確なトラ フィックエンジニアリングを含む合計 87,000 MPLS トンネル（1 ポートにつき 1,500）上でのワイヤ スピード転送（試験事例 8 を参照） ところで CRS-1 が問題なく動作したかといえば、必ずしもそうだったわけではありません。試験中 IPv6 パケットの損失があった際にマイクロコードの修正で直す必要がありましたが、技術的に見てこれは無 視できません。また CRS-1 のシャーシは、1 つ 2 つのラインカードしか必要としないような場合には形 状的に大きすぎます。業界内ではシスコが問題を解決するために、この製品のサイズを半分にしたバー ジョンを開発中とのうわさが流れています。 この試験は技術的にいくつもの「初めて」を達成した点で意義がありますが、別の意味でも「初めて」 を成し遂げました。実はシスコが Light Reading にその製品の試験を許可したのは、2001 年に同社が実 施して物議をかもしたルータ試験以来のことだったのです。試験の結果はシスコ側のこの大胆な決断が 賢明であったことを示しています。また他のルータベンダーがこの決断に触発されて 1 月発表予定の Light Reading の 2005 年度試験プログラムに進んで参加してくれることを願っています。 各試験とその結果は以下にくわしく説明します。 試験構成 試験には、合計 56 の packet-over-Sonet OC-192（10 ギガビット／秒）インターフェイスと、2 つの packet-over-Sonet OC-768（40 ギガビット／秒）インターフェイスを使用しました。シスコルータの各 モジュールは OC-192 ポートを 4 つ、または OC-768 ポートを 1 つ装備します。（図 1） 試験では真の Sonet OC-768（SDH STM-256）インターフェイスモジュールだけを使用しました。4x OC-192 WDM ポートは真の OC-768 インターフェイスとはみなしません。 すべての CRS-1 シャーシと OC-192 ならびに OC-768 のインターフェイスモジュールでは、シスコ IOS-XR ソフトウェアのバージョン 2.0.2 を用いました。IOS-XR は、IOS オペレーティングシステムのまったく 新たなバージョンです。IOS-XR の詳細については試験事例 7 を参照してください。 シスコは、すべての試験に対して 1 つのソフトウェアリリースを選ぶ必要がありました。試験中は、ソ フトウェアアップグレード試験やマルチシャーシ試験、試験事例 2 で必要だったパッチを除いてソフト の交換はしていません。使用を認めたのは製品リリース版のみです。試験開始時に EANTC がシスコの 公開ウェブサイトからソフトウェアをダウンロードしました。 4 試験は 40 の OC-192 インターフェイスを持つ Agilent N2X システム（旧 RouterTester、ソフトウェアリ リース 6.3）のクラスタと、16 の OC-192 インターフェイスおよび 2 つの OC-768 インターフェイスを 持つ Agilent Router Tester システム（ソフトウェアリリース 5.1.1）のクラスタを使って行いました。異 なるクラスタを使ったのは、Agilent の 40 ギガポートが古いソフトウェアのみをサポートしていたため です。 完全に再現可能な環境で試験を行うため、シスコの構成に対する変更と CRS-1 コンソールのメッセー ジをすべて EANTC で自動的にログしました。 各試験は、エミュレータを同じ物理ポートに接続したまま行いました。アナライザポートとトラフィッ クストリームは、CRS-1 のバックプレーンとモジュールの内部処理装置に負荷がかかるようインターリ ーブしました。シスコはモジュールに残っているトラフィックとバックプレーンを通過するトラフィッ クの間に性能の違いはないと主張しましたが、EANTC の試験はこれを検証できるよう構成しました。 すべての試験事例では標準的な IPv4 および IPv6 アドレス体系を用いました。各インターフェイスには、 すべてのルートとフローに適合するよう、クラス A のネットワークアドレス空間を与えました。 Cisco CRS-1 は以下の構成で試験しました。 41 42 1 2 3 56 57 39 40 58 Agilent N2X クラスタ 6.3 Agilent N2X クラスタ 5.1 試験対象のシステム OC-192 OC-768 図 1 試験事例 1：IPv4 IMIX ベース転送 試験の目的 現実的な条件下において試験対象システムの最大 IPv4 転送性能を測定すること 試験構成 最大帯域幅の確認は、通常は誰もが最初に行う最も単純な試験です。しかし今回は、対象帯域幅とルー タを流れるユーザフロー数の計算を同時に扱う必要がありました。理論上の最大帯域幅は 1 モジュール あたり 40 ギガビット／秒（完全 2 重）、1 シャーシあたり 640 ギガビット／秒、CRS-1 の最大マルチシ ャーシ構成時に 92 テラビット／秒です。モジュールを満載した 1 つのシャーシに対して、利用可能な 限りの Agilent インターフェイス（56×10 ギガ＋2×40 ギガ＝640 ギガビット／秒）で負荷を与えるこ とができました。これはエミュレートされた IP トラフィックの量としてはおそらく今までで最大でし ょう。 スケーラビィリティ試験をさらに拡張するため、以前と同じインターフェイスカードを使って 88 の OC-192 （10 ギガビット／秒）インターフェイスと 10 の OC-768（40 ギガビット／秒）インターフェイスを加 えて CRS-1 のマルチシャーシ構成を構築し、エミュレートされたトラフィックをシャーシ中で複数回 ループさせるスネーク試験を行いました。この 3 台のラックを使ったルータの実装には、2 つのライン 5 カードシャーシとそれらを相互接続する 1 つのファブリックカードシャーシを含みます。 エミュレートするユーザ数は第二の挑戦でした。多くの試験では、それぞれが大きな 1 つの帯域幅を持 つ「フロー」 （エンドツーエンドの IP アドレス関係）をいくつか用いるだけです。こうした試験ではフ ローテーブルのサイズが（その状態が保持される場合）小さく、テーブルエントリへのアクセスが早い ため、ルータのアーキテクチャによっては扱いが簡単です。しかし Light Reading は現実的なシナリオ として、各ユーザが必要とする帯域幅をわずか 42 キロビット／秒と仮定しました（それより多く、ま たは少なくなる場合もあります）。640 ギガビット／秒を満たすためには、そうしたフローが 1500 万も 必要となります。この試験ではエミュレートされたユーザを持つ宛先 IP ネットワークに対してスタテ ィックな IP ルートを設定しました（後の試験では BGP を使用）。 このフロー数は現在の要件をはるかに越えており、通信事業者によるフィードバックでも適切な値とさ れています。 すべての負荷試験では、Internet Mix Traffic（IMIX：インターネットミックストラフィック）に合わせ、 複数のパケットサイズを混合して使いました。これは実際のフレームサイズの使用に沿って現実のネッ トワークトラフィックをシミュレートする確実な方法です。複数の研究は、インターネットのトラフィ ックは異なるサイズのフレームで構成されており、その比率が固定していることを示しています。IMIX トラフィックは、複数サイズのフレームを実際のインターネットトラフィックに見られるフレームサイ ズの構成と似た比率で混合したものを含んでいます。IMIX トラフィックを使うことで、1 つのパケット サイズを順番に試験するのに比べて現実的な条件下で SUT を試験することができます（図 2 と図 3）。 packet-over-Sonet リンク上では、物理層（HDCL）でのバイトスタッフィングが実現可能な最大帯域幅 に影響します。ルータが IP ヘッダー（TTL）とチェックサムを変更するため、受信したデータに加えて バイトスタッフィングが発生し、ルータが受信したより多くのデータを送らなければならない場合があ ります。 20% 23% 38% 57% 16% 40 バイト 64 バイト 552 バイト 174 バイト 576 バイト 1500 バイト 750 バイト 16% 7% 図 2 IPv4 パケットストリームの分布（帯域幅%) 1500 バイト 23% 図 3 IPv6 パケットストリームの分布（帯域幅%) 結果 試験は異なるハードウェア構成を使って 2 回実施しました。シングルシャーシ版では、ルータは、合計 9 億 2900 万パケット／秒、つまり 640 ギガビット／秒でワイヤスピードの IMIX 転送を実現しました。 どのフロー中にもシーケンスを外れたパケット（エンドユーザから見た TCP スループットに悪影響を 与える）がないことを確認しました。 マルチシャーシ構成では（物理的構成の詳細は 5 ページ目の試験構成を参照）、システムは 18 億 3800 万パケット／秒というほとんど信じられない数値を達成しました。合計の帯域幅は 1.28 テラビット／ 秒でした（図 4 と図 5）。 標準的な packet-over-Sonet バイトスタッフィング（上記参照）により、98%負荷で遅延試験を行いま した。シングルシャーシおよびマルチシャーシともに平均 80 マイクロ秒（µs）というのは、シスコの 予想値とも一致しています。 CRS-1 は 3 ステージの Benes スイッチトポロジを採用していますが、これが多くのインターフェイス 拡張に非常によく対応できることは明らかです。すべてのシャーシサイズで 3 ステージの数は同じです。 マルチシャーシ版では異なる種類のファブリックカードにより第 2 ステージを外部化する必要がありま 6 すが、これはアーキテクチャ上の違いとはなりません。3 つのステージがあることで他のアーキテクチ ャに比べて著しく遅延が増大するわけではありません。80 µs の遅延は無視できるもので、voice-over-IP 呼では 20 以上の CRS-1 が接続経路上に存在しても気付かれることはないでしょう。シングルシャーシ とマルチシャーシソリューションの唯一の違いは最大遅延で、±80 µs となっています。いずれにして もこの値は非常に小さいものです（図 6）。 100 万パケット／秒 18 億 3800 万 パケット／秒 1500 1.28 テラビット／秒 1000 9 億 2900 万 パケット／秒 1000 640 ギガビット／秒 500 500 0 シングルシャーシ 図 4 0 マルチシャーシ シングルシャーシ IPv4 パケットレート 図 5 マルチシャーシ IPv4 スループット マルチシャーシ 最大遅延 平均遅延 最小遅延 シングルシャーシ 0 100 200 300 400 マイクロ秒 図 6 IPv4 遅延 試験事例 2：IPv4/IPv6 混合転送 試験の目的 IPv4/IPv6 混合トラフィックの最大転送性能の測定 試験構成 2004 年、日本のインターネットバックボーン中の IPv6 トラフィックの割合は、全トラフィックの 1% に達しました。IPv6 トラフィックは最悪の場合 2010 年までに全インターネットトラフィックの 15%未 満にとどまることが予想されており、今回の試験でもこの数字を使いました。IPv6 は徐々に研究ネット ワーク専用のイメージから脱却しつつあります。今日の通信事業者は新規のバックボーン設備について は IPv6 を要求しています。 今回の試験での CRS-1 の課題は、IPv6 の転送処理を純粋にハードウェア上で行えること、また特にヘ ッダー分析によるオーバーヘッドの増大が実際の IPv4/IPv6 環境下で性能問題につながらないことを証 明することでした。最初の試験事例と同様に Agilent のエミュレータを準備し、全トラフィックの 15% を IPv6 にしました。インターネット上の IPv6 混合トラフィックを再現するために異なるパケットサイ ズも使用しました。 7 結果 CRS-1 が IPv6 を完全にハードウェア上で処理できることがはっきり証明されました。今回の混合トラ フィックシナリオでは、シングルシャーシシステムはラインレートで 8 億 2 千万 pps のパケットレート を達成しました。パケットレートは全 IPv4 トラフィックシナリオよりわずかに小さくなっていますが、 これは IPv6 パケットの方が長いためです。 驚いたことに、1 回目の試験でシステムは 1.83%のパケット損失を出しました。シスコの説明によれば、 モジュラーサービスカードで受信されるパケットフローは、それぞれが一度に 1 つのパケットを処理す る 188 のパラレルチャネルをもつチップセットにより処理されます。他の試験で見てきた通り、通常の 条件下では、ワイヤスピードのスループットとしてはこれで十分以上です。IPv6 パケットの転送判断に は、IPv4 パケットの場合より 20%多く時間がかかりましたが、今回の遅延試験でもこの値が確認され ています（下記参照）。パケットを 188 のチャネルそれぞれに割り当てるスケジューラは、ほとんどの IPv6 と IPv4 の組み合わせをワイヤスピードで動作するよう最適化されていました。今回の 85/15%のケ ースは図らずもシステムの不具合を見つけることとなりました。 シスコはマイクロコードを最適化し、試験対象システムにパッチをインストールしました。試験事例を 再び実施したところ、今回は CRS-1 がパケット損失なしで 100%のスループットを達成することを確認 しました。他の性能へ悪影響が出ないように、その後の試験でもこのパッチをインストールしたままに しました（図 7 と表 1）。 遅延試験を 98%負荷で行った結果、平均遅延は全 IPv4 環境より約 20%高く、マルチシャーシ環境での 最大遅延はシングルシャーシシステムより 25%高いことが示されました。ただし重要なのはすべての IPv4 および IPv6 パケットが最大でも 0.34 ミリ秒以内で転送されていることです。これが絶対最大遅延値で あり、IPv6 としては素晴らしい結果です（図 8）。 モジュラーサービスカード内のパケット並行処理のため、シーケンス外れのパケットが生じる可能性が あることが理論上わかっていました。そこで EANTC では別途試験を行い、各フローの全パケットが正 しいシーケンスで送信されるか確認しました。この試験事例では（また他の試験でも）、シスコのルー タはあらゆる条件下で各フローのシーケンスを維持しました。また誤ってルーティングされた迷子フレ ームその他の予想外の問題は生じませんでした。この実装は超高速並列コンピューティング環境で並外 れて正確なスケジューリングを実行できると言い切ってもよいでしょう。 表 1 IPv4/IPv6 混合時のパケットレート 送信レート 受信レート IPv6 送信レート IPv6 受信レート 1 秒ごとの （パケット／秒 （パケット／秒 （パケット／秒） （パケット／秒） パケット損失 合計） 合計） 受信 帯域幅 L2 819,904,533 802,170,750 130,840,624 115,837,061 15,003,563 （1.83％） 98.17% マイクロコー ド変更後の 2 回目の試験 819,927,902 819,927,902 130,840,608 130,840,608 0 100% 100 万パケット／秒 1 回目の試験 2000 1500 パケット損失(pps) IPv6 受信レート(pps) IPv4 受信レート(pps) 1000 500 0 1 回目の 試験 図 7 8 マイクロ コード変 更後の 2 回 目の試験 マルチ シャーシ 試験 IPv4/IPv6 混合時のスループット マルチ シャーシ 最大遅延 平均遅延 最小遅延 シングル シャーシ 0 100 200 300 400 マイクロ秒 図 8 IPv4/IPv6 混合時の遅延 試験事例 3：セキュリティおよび QoS 実装時の IMIX ベースの IPv4/IPv6 転送 試験の目的 現実的な条件下での試験対象システムの最大 IPv4 転送性能の測定 試験構成 IP ルータを単なるパケット転送装置として使おうとする通信事業者はほとんどいません。ほとんどの場 合、DiffServ 分類、セキュリティ（アクセスコントロールフィルタ）、未承認サービスへアクセスしよう とするユーザのログ（アクセスコントロールリストのロギング）などの追加的なパケット処理機能を設 定する必要があります。こうしたサービスをすべて起動しても動作できることがキャリアクラスのルー タの標準的な要件となっています。 結果 5,001 エントリを持つアクセスコントロールリスト（ACL）を IPv4 用に設定し、そのうち 5,000 エント リを DENY 文、最後のエントリを PERMIT-ALL 文としました。DENY 基準はシーケンシャルではなく 擬似ランダムで選び、シーケンシャルレンジが 1 つの ACL エントリに変換されるのを防止しました。 また DENY エントリの 50%を、処理対象データストリームの IP アドレスに一致し、データトラフィッ クの UDP ポートには一致しないよう設定しました。このためルータはすべてのステートメントを処理 し、パケット宛先を判断する際にパケットの内部深くまで確認しなくてはなりません。さらに ACL を 入力フィルタおよび出力フィルタの両方として各ポートに適用したので、各パケットについて ACL を 2 回処理することになりました。 次に 5,000 番目の ACL エントリ（IPv4 と IPv6）に ACL ロギングを設定し、ルータがこのエントリに一 致するパケットのログを取ってセキュリティルールの侵犯を管理者に通知するようにしました。 最後に各インターフェイス上に IPv4 と IPv6 用の 500 エントリの QoS 分類フィルタを設定し、ユーザ からのトラフィックを異なるサービスクラスに割り当てる典型的なエッジシナリオをエミュレートしま した。 比較を容易にするため、IPv4 と IPv6 のトラフィックストリームを前の試験事例と同じアナライザに設 定しました。唯一の違いは、今回は UDP パケット（最小パケットサイズは 48 バイト）を送信し、アク セスコントロールリスト処理時にルータに UDP ヘッダーを確認させた点です。得られたパケットレー トはパケットサイズが大きくなった分、少々遅くなりました。 シスコはこれまでの結果に劣らないワイヤスピードを達成できることに自信を持っていました。今回の 結果はシスコの期待を裏付けるものでした（図 9 と表 2）。 表 2 アクセスコントロールリスト、ロギング、QoS 起動時のスループット 送信レート （pps 合計） 受信レート （pps 合計） 送信レート （IPv6 pps） 受信レート （IPv6 pps） 1 秒ごとの パケット損失 受信 帯域幅 L2 684,912,460 684,912,460 130,839,710 130,839,710 0 100% 9 100 万パケット／秒 800 600 パケット損失(なし) IPv6 受信レート IPv4 受信レート 400 200 0 ACL 起動時 ACL とロギ ング起動時 ACL、ロギン グ、QoS 分 類起動時 図 9 サービス起動時の IPv4/IPv6 転送性能 結果の詳細を以下に示します。 • 5,000 エントリが DENY で最後のエントリが PERMIT-ALL である 5,001 エントリの ACL を IPv4 用 と IPv6 用に 2 つ用意し、それらの ACL を使って試験した結果、ワイヤスピードの IMIX 負荷で IPv4/IPv6 のパケット損失は観測されませんでした。 • 2 回目の試験ではアナライザ上の 1 つのストリームを ACL のエントリに一致するよう設定し、ACL が実際にネットワークを保護していることを確認しました。全ポートが IPv4 および IPv6 パケットを 適切に廃棄しました（Agilent の統計はどのストリームが廃棄されたのか示しませんでした）。 • CRS-1 から EANTC が管理する syslog サーバにアクセスコントロールログ情報を転送しました。ロ グの形式は以下のとおりです。 Oct 27 14:33:29.242 : ipv4_acl_mgr[210]: %IPV4_ACL-6-IPACCESSLOGP : access-list IPV4_Test (50400) deny udp 169.0.0.3(0) -> 168.0.0.3(5086), 1 packet • QoS トラフィック分類リストをセキュリティ ACL と同時に起動しました。シスコは、500 行の ACL を使った入力サービスポリシーを設定しました。DiffServ による入力または出力パケットのリマーキ ングが行われることを確認するため、 「show policy-map interfaxe…」コマンドを実行しました。分類 リストは全トラフィックに一致して優先度を書き換えるよう設定しました。 • シーケンス外れのパケットは確認されませんでした。試験対象システムは 300 秒の試験時間中、堅牢 なキューイングおよび転送性能を示しました。 同様の試験をマルチシャーシシステムについても実施しました。予想通り、マルチシャーシ環境でも前 の試験事例と同じ性能が達成されました。 実際、アクセスコントロールリスト、ロギング、QoS 分類の追加がルータの性能に影響を及ぼすことは ありませんでした。前の試験事例と同様、ワイヤスピードの転送を全リンクで達成できました。 10 試験事例 4：BGP ピアリング 試験の目的 IPv4 と IPv6 のルートを使った eBGP 実装の性能およびルート収束時間の測定 試験構成 IP ルーティングはよく理解されてはいますが、通信するピアの数が増えるにつれてルータ数が着実に増 大していくため、コアルータにとっては依然として課題となっています。IP ルーティングの実行では、 特にルーティング情報を可能な限り早くアップデートして、トポロジ変更時にブラックホール化したト ラフィック（誤った宛先に送られるパケット）やパケットの損失を防ぐ必要があるため、多大な処理能 力が必要となります。 たとえば Light Reading が 2 年前に実施した試験を含め、インターネットバックボーンのルーティング テーブルのサイズの見積もりはしばしば行われています。それ以来ルーティングテーブルは年に 20%ず つ増え、現在では 16 万エントリ以上となっています。5 年後のルーティングテーブルのサイズは、40 万エントリほどになる可能性があります。さらに通信事業者は、インターネットにアクセスするサブネ ットワークやインターネットからは見えない VPN などに多くの内部ユーザを抱えています。また IPv6 ルーティングテーブルも増大することでしょう。こうした理由から、今回の試験では余裕を見て 150 万 の個別エントリを持つ BGP ルーティングテーブルを採用しました。 各ポート上にエミュレートしたリモートルータに対して 1 ポートにつき 1 つの eBGP セッションを確立 するよう eBGP 試験を論理的に構成しました（図 10）。 この試験では多数のルータが存在する現実的な環境がエミュレートできます。検索処理を厳しくするた め、異なる長さのプレフィックスを用いました（表 3）。 当然ながら、今後のキャリアネットワークで一般化するであろう IPv4 と IPv6 の混在ルートを使用しま した。コントロールプレーンで許可されたルートと、転送ハードウェア内に実際にインストールされア ップデートされているルートとを区別するため、これまでと同じ混合 IMIX パケットを使って全ルート 上にトラフィックを送信しました。 eBGP セッション eBGP セッション リモートネット ワークへの eBGP ルート 試験対象システム （すべてのポート／クラスタは示していない） 図 10 11 表 3 BGP プレフィックス定義 アドレス種別 プレフィックス長 ポートごとの 固定ルート ポートごとの 変更ルート ポートごとの 総ルート数 IPv4 /19 536 1000 1536 IPv4 /24 8544 4000 12,544 IPv4 /29 5952 2000 7952 IPv6 /45 500 500 1000 IPv6 /60 1250 750 2000 5000 5000 5000 5000 5000 結果 エミュレートしたルータをすべて起動し、CRS-1 がセッションを確立して 150 万のルート上でワイヤ スピードのトラフィック転送ができるか観測しました。実際そのとおりになり、ほとんどの市販ルータ にはほぼ不可能であろう膨大な数の BGP ルート検索を行ったにもかかわらず、1 つのパケット損失も 観測されませんでした。 次に多数の IPv4 と IPv6 のルート（この場合 50 万ルート）を新たな宛先に切り替えた後の収束時間を 確認しました。これは隣接する主要なインターネットコアルータの障害をエミュレートしたワーストケ ースのシナリオです。既存の 50 万のルートに対して、宛先までの距離が劣る「ASpath」を持つ迂回ル ートを異なるインターフェイスを介して実装しました。次にこれらのルートの元の宛先を一度に削除し、 ルータに 50 万のルートの最適ネクストホップを一度に再計算させました。 結果は素晴らしいものでした。CRS-1 は全ルートを把握し、12 秒以内に新しい宛先へと切り替えまし た。元のネクストホップ宛先へルートを再アドバタイズした時の収束時間は 18 秒でした（図 11）。 この図は、2 つの異なるポートグループを介したパケット転送を示しています。最初に、同じ数のパケ ットを受信するよう、同じ数のルートに 2 つのポートグループを設定しました。最初の切り替えでポー トグループ B からポートグループ A にいくつかのルートが移されたので、ポートグループ A 上ではポ ートグループ B 上より多くのパケットが転送されるようになりました。ルータは 12 秒後にすべての BGP のアップデート処理を完了し、転送レートは新しい値で安定しました。1 分後、アナライザがルートを 元の状態に戻しました。今度はパケットレートが再び均等に分配されルートが収束するまでに 18 秒か かりました。 100 万パケット／秒 ポートグループ A 上のルート 375 ポートグループ B 上のルート 350 325 300 275 250 1 21 41 61 81 秒 図 11 eBGP4 再収束 解釈 試験対象システムはすべての BGP ルートの処理とアップデートに成功し、正常動作中に全ルートでゼ ロ損失スループットを達成しました。ルートの変更後もシステムは 18 秒以内に収束し、その後ゼロ損 失スループットを達成しました。 12 試験事例 5：IPv4 ユニキャスト／マルチキャスト混合転送 試験の目的 マルチキャスト／ユニキャスト混合環境でのルータのマルチキャスト転送能力の評価 試験構成 マルチキャスト転送は、企業および家庭用アプリケーションにとってますます重要なものとなっていま す。たとえば銀行はビジネスクリティカルなマルチキャストトレーディング情報システムを使用してい ますし、ファイバツーザホームプロジェクトでは IP ベースのネットワークを介して大規模 TV 放送サー ビスを展開しています。両方のアプリケーションに対応するためには、マルチキャスト転送は高品質、 高アバイラビリティでなくてはならず、また多数のグループや大きな帯域幅に合わせて拡張できなくて はなりません。 マルチキャストルーティングには、現在のキャリアネットワークで主流のプロトコルである PIM-SM を 用いました。 試験は 2 つの部分にわけて行いました。最初に通常のマルチキャストルータとしての CRS-1 の動作を評価し、次に CRS-1 がマルチキャストグループの送信元と宛先を調整する論理ノードである マルチキャストランデブーポイント（Rendezvous Point：RP）として動作した場合に性能の違いが出 るかを確認しました。 本構成では、1 ポートにつき 20 のセンダ、1 マルチキャストグループにつき 2 つの送信元、合計 1,160 の送信元をエミュレートしました。各ポートは、同じポートで送信されるもの以外のすべての送信元、 つまり 1140（S, G）ルートに加入するよう設定しました。各マルチキャスト送信元は、1 ポートにつき 570 万 pps（5.7 ギガビット／秒）マルチキャスト受信トラフィックに加え、5000 pps のレートで 125 バイトの固定サイズのデータを送信しました。さらにフルメッシュのユニキャストストリームを各クラ スタに設定し、3 ギガビット／秒（40 ギガポート上では 12 ギガビット／秒）を送受信しました。リン ク層オーバーヘッドを加えると、得られた帯域幅は全インターフェイスでワイヤスピードに近いものと なりました（図 12）。 これまでの試験同様、マルチキャストでもユニキャストでもパケットの損失は生じませんでした。また、 58 の PIM リンクを制御し、それぞれ 2 つの送信元と 57 の加入者を持つ 580 のマルチキャストグルー プの配信ツリーを構築し、3 億 3000 万 pps のダウンストリームマルチキャストデータを送信しました。 またこれとは別に 1 億 9200 万のユニキャストパケットを平行して交換しました（図 13 と図 14）。 試験の後半では、試験前半の機能に加えて CRS-1 を RP として動かしました。結果は試験前半で得られ たものと同様でした。 結論から述べると、マルチキャストトラフィックでもマルチキャストルーティングでも、ルータに過負 荷をかけることはできませんでした。この試験により、CRS-1 のマルチキャスト性能はユニキャスト転 送速度を補い、容易に 1 シャーシにつき 3 億 pps 以上を達成できることが示されました。 13 送信元 グループ 1～20 送信元 1 グループ 1～20 送信元 2 1140 レシーバ 1140 レシーバ 加入者 加入者 送信元 送信元 グループ 571～580 送信元 2 グループ 571～580 送信元 1 送信元 加入者 加入者 1140 レシーバ 1140 レシーバ 試験対象システム （ランデブーポイント） （すべてのポート／クラスタを示していない） 図 12 600 ギガビット／秒 100 万パケット／秒 400 300 200 100 500 400 マルチキャスト 受信帯域幅 ユニキャスト 受信帯域幅 300 200 100 0 マルチキャス マルチキャス ユニキャスト ユニキャスト ト送信レート ト受信レート 送信レート 受信レート 図 13 マルチキャスト性能 0 図 14 マルチキャスト帯域幅 試験事例 6：サービスクラス 試験の目的 IPv4 Differentiated Service（DiffServ）が正しく実装できているかを確認 試験構成 試験は二つの部分に分けて行いました。 • 固定データレートのトラフィックフローを使ってリンクを加入過多状態にしました。これに伴い CRS-1 はキュー管理機能により生じた輻輳を処理するために、ストリームを優先付けしました。 • バースト状態でのキュー管理機能を評価するため、EF クラスのトラフィックにバースト性のトラフ ィックが影響を与えるかどうか調べました。 この試験では、パケットサイズがそれぞれ異なる 5 つのトラフィッククラスを用いました（表 4）。 今回は 58 ポートのうち 6 ポートを送信専用ポートとして使って他の全ポートにデータを送信し、加入 過多状態を生じさせました。ルータは輻輳時には、優先度の低いフレームのみ破棄しなければなりませ ん。 14 IPv6 での DiffServ の用法はこれと同じではないので、この試験では IPv4 のみを扱いました（表 5）。 1 つの DiffServ クラスのトラフィックが制限を越えた場合、ルータはそれをリマーク（通常のエッジル ータの機能）せず、キュー設定にしたがって転送します。この試験の目的はリマーキングではなく、輻 輳処理とキューイングの確認です。 表 4 DiffServ クラスごとのパケットサイズ定義 DiffServ クラス DiffServ 名 クラス名 パケットサイズ EF Expedited Forwarding Premium 60 バイト AF11 Assured Forwarding Class 1 Gold 40 バイト AF21 Assured Forwarding Class 2 Silver 552 バイト AF31 Assured Forwarding Class 3 Bronze 576 バイト BE Best-Effort Best-Effort 1500 バイト 表 5 リニア DiffServ ストリームのトラフィック負荷定義 クラス名 ルータの帯域幅制限 トラフィック発生器から送信される トラフィック発生器から送信される 帯域幅（OC-192 用）ステップ A 帯域幅（OC-192 用）ステップ B Premium 0.5 ギガビット／秒 0.5 ギガビット／秒 0.5 ギガビット／秒 Gold EF なしで回線速度の 35% 3 ギガビット／秒 3 ギガビット／秒 Silver EF なしで回線速度の 25% 2 ギガビット／秒 2 ギガビット／秒 Bronze EF なしで回線速度の 25% 2 ギガビット／秒 3 ギガビット／秒 Best-Effort （残り＝15%） 3.5 ギガビット／秒 2.5 ギガビット／秒 （1 ギガビット／秒は予備ポートより）（1 ギガビット／秒は予備ポートより） 1 回目の試験：（図 15 と図 16） • Best Effort を除いた全クラスが設定した制限値内で送信できました。 • パケット損失の可能性があるクラスは Best Effort クラスのみでした。 • EF、AF1、AF2、AF3 クラスではルータはパケットを 1 つも失いませんでした。 • EF および AF クラスではシーケンスエラーもありませんでした。 • いずれ帯域保証クラスでも最大遅延は 0.23 ミリ秒でした。 次のステップとして AF31 ストリームの帯域幅を 1 ギガビット／秒増やし、このクラスに設定された制 限値を超えるようにしました。同時に、Best Effort ストリームの帯域幅を 1 ギガビット／秒減らしまし た。合計の加入過多レートは変えないようにしました。私たちは、スイッチが設定された比率を常に把 握し、AF31 クラスで制限値を超えたパケットを Best Effort クラスよりもより多く破棄するだろうと予 想しました（図 17 と図 18）。 15 7% 6% BE AF31 5% 4% 3% AF21 最大遅延 平均遅延 最小遅延 AF11 2% EF 1% 0 0% EF AF11 AF21 AF31 BE 図 15 QoS クラスのパケット損失 （Best Effort クラスのみ制限値を超過） 7.00% 6.00% 5.00% 4.00% 3.00% 2.00% 1.00% 0.00% 1000 2000 3000 マイクロ秒 図 16 QoS クラスの遅延 （Best Effort クラスのみ設定制限値を超過） BE AF31 AF21 最大遅延 平均遅延 最小遅延 AF11 EF 0 EF AF11 AF21 AF31 BE 図 17 QoS クラスのパケット損失 （Best Effort および AF31 クラスが制限値を超過） 500 1000 1500 2000 2500 3000 マイクロ秒 図 18 QoS クラスの遅延 （Best Effort および AF31 クラスが制限値を超過） パート B：バーストトラフィック このパートでは、他のトラフィッククラスでバーストトラフィックを送信し、プレミアム（EF）トラフ ィックのパケット損失と遅延を観察しました（表 6）。 ルータは、あらゆる条件下で EF トラフィックの優先する必要があります。EF トラフィッククラスでパ ケット損失が起きてはならず、リンク加入過多時でも遅延が増大してはいけません。その他の全クラス のトラフィックは、規定通り送信されるか、または必要に応じて廃棄される必要があります。 ルータの動作は予期どおりでした。プレミアムの AF11 および AF21 トラフィッククラスではパケット 損失は見られませんでした。また、リンク加入過多時でも優先クラスの遅延時間は影響を受けませんで した。すべての試験で Best Effort と AF31 クラスのトラフィックは必要時に限り廃棄されました。 （図 19） 次のステップ（AF31 加入過多時のスタティックリニアフロー）では、AF31 ストリームは、ルータが「帯 域幅の割合」にしたがって設定されていたため、Best Effort ストリームよりずっと多くのトラフィック を失いました。AF31 ストリームはその割合を大きく超過していましたが、Best Effort ストリームが超 過していたのはわずかな量だったのです。 システムはトラフィックバーストプロファイルにも対応しました。スタティックなトラフィックプロフ ァイルに比べて EF および AF クラスの最大遅延値が 10%増大しました。 AF11 クラスはすべての試験で他の AF クラスに比べてやや高い最大遅延値（+20 µs）を示しました。こ れについてシスコは、AF11 クラスが他の AF クラスより早いレートでより小さなパケットを処理してい るためとコメントしています。パケットはそれぞれのキューから出た後、回線インターフェイスモジュ ール（PLIM）の FIFO に入ります。たまたま AF11 が制限を超過した時に他の 2 つの AF クラスがパケ ットを FIFO に入れると、それ以降の AF11 パケットの遅延が少し大きくなります。これが最大遅延値 が大きくなる原因です。 16 表 6 DiffServ バースト性トラフィックのトラフィック負荷定義 DiffServ クラス 平均帯域幅 バースト負荷 バースト長 （連続パケット） EF 0.5 ギガビット／秒 ― ― AF11 1 ギガビット／秒 1.5 ギガビット／秒 5 AF21 1.5 ギガビット／秒 2.0 ギガビット／秒 10 AF31 2 ギガビット／秒 4 ギガビット／秒 25 BE 3 ギガビット／秒 6 ギガビット／秒 50 BE AF31 AF21 最大遅延 AF11 平均遅延 EF 最小遅延 0 500 1000 1500 2000 2500 3000 マイクロ秒 図 19 QoS クラスの遅延 （Best Effort クラスが制限値を超過、バーストトラフィック時） 試験事例 7：ソフトウェアの保守 試験の目的 ソフトウェアアップグレード時およびハードウェアモジュール交換時のサービス中断の評価 試験構成 通信事業者は、CRS-1 のような大規模コアルータに対して保守のために自主的にサービスを一切中断す る必要がないことを期待しています。また、1 つのコンポーネントの障害がシステム停止を引き起こす ことがあってはいけません。ルータがこの 2 つの期待に応えられるかどうか、以下の検証を行いました。 • 重要なソフトウェアパッケージのアップグレードおよびダウングレード • プライマリルートプロセッサの抜き差し • セカンダリルートプロセッサの抜き差し • ソフトウェア停止なしのファブリックカードの抜き差し • ソフトウェアを停止してのファブリックカードの交換 • ラインカードの抜き差し これらすべてのステップで、システムには大きな BGP ルーティングおよび IPv4/IPv6 転送負荷を与え、 150 万ルート上にラインスピードでトラフィックを送信して eBGP ピアリング試験を再び行いました。 これにより、CRS-1 のルーティングおよび転送性能に対するサービスの実際の影響を確認することがで きました。 17 ソフトウェアアップグレード シスコの IOS-XR はモジュラー性の高いソフトウェアです。アップグレードおよびダウングレード試験 では、IETF の指針や要件の変更に応じて変更される典型的なモジュールであり、利用できないとシス テムにとって致命的であるという理由から、ルーティング（BGP、OSPF など）用のソフトウェアパッ ケージを選びました。ベースソフトウェア（基本のオペレーティングシステム基幹ソフトウェア）のア ップグレード／ダウングレードについては試験していません。 ソフトウェアパッケージのバージョンを 2.0.0 から 2.0.2 へアップグレードし、その後 2.0.0 へとダウン グレードしました。この試験は非常に過酷なもので、システムはパケットストリームの転送を継続し、 かつ隣接 BGP との関係を維持しながらプライマリルートプロセッサの BGP コードを交換し、すべての BGP セッションを再起動しなければなりません。 結果は驚くべきものでした。ルータはアップグレード時に 5 億 6000 万 pps のレートで転送を行いなが ら、すべてのインターフェイスでわずか 24 の IP パケットしか失いませんでした。これはサービス中断 時間にすると 120 ナノ秒または 0.00000012 秒に相当します。ダウングレード試験ではシステムの損失 パケットは、45 ns にあたるわずか 9 パケットでした。こうした損失パケットは Agilent スタック（18 のインターフェイスを持つ）の 1 つにだけ見られ、しかも 1 回の試験でだけ生じたので少し奇妙でした。 もう一度手順を繰り返したところ、パケット損失は生じませんでした。 シーケンス外れのパケットはどの試験でも検出されず、転送遅延の増加はありませんでした。プライマ リおよびセカンダリルートプロセッサのアップグレードまたはダウングレード処理全体にかかった時間 は 90 秒前後でした。 ハードウェアモジュール交換手順 これまでと同じ試験構成で、重要な冗長化ハードウェアコンポーネントをいったん抜き取り、再び挿入 しました。（表 7） 結果をまとめると、各ルートプロセッサおよびファブリックカードはルーティングや転送に影響を与え ることなく稼動状態のまま交換が可能です。当然ながら、前もってソフトウェアを停止せずにファブリ ックカードを抜いた場合、システムの復旧にわずかですが時間（190 ms）がかかりました。 表 7 ハードウェア交換によるサービス中断 試験 パケット損失 相当（時間） 最大遅延 （µs） シーケンス 外れパケット 0 104 0 190 ms 112.1 0 ソフトウェアを停止してのファブリックカードの抜き差し 0 110.2 0 無トラフィックでのラインカードの抜き差し 0 109.9 0 プライマリルートプロセッサの抜き差し 0 114.4 0 セカンダリルートプロセッサ抜き差し ソフトウェア停止なしのファブリックカードの抜き差し 18 試験事例 8：MPLS スケーラビリティ 試験の目的 MPLS ラベルスイッチルータ（LSR）としての試験対象ルータの機能とスケーラビリティを RSVP-TE を使って検証 試験構成 試験対象システムはエッジではなくコアバックボーンで使用されます。MPLS しては LSR（Label Switch Router：ラベルスイッチルータ）として機能し、少なくとも現在のハードおよびソフト構成では VPN サービスには関与しません。CRS の主な機能は、MPLS ラベル転送をネゴシエートし、トラフィックエ ンジニアリングトンネルを維持することです。そのためこれらについて試験しました。 • 本試験では、合計 57,000 の RSVP-TE トンネルを確立してコントロールプレーンに負荷を与えまし た。 • 全トンネルにワイヤスピードでトラフィックを送信し、MLPS による転送能力をチェックしました。 • さらにトンネルを介してプレミアムおよびベストエフォートのトラフィックを送信し（MPLS ラベル ヘッダーの EXP ビットを使用）、宛先ポートを加入過多状態にすることにより、優先処理とキューイ ングの性能を検証しました。 この試験事例では、一方のクラスタに異なる Agilent N2X ソフトウェアリリース（6.4 ベータリリース） を用いましたが、それはこのリリースが RSVP-TE トラフィックメッシュ作成を容易にする新たな MPLS 機能拡張を提供するためです。他方のクラスタでは標準の 5.1.1 のソフトウェアを使いました。5.1.1 の ソフトウェアを使った RSVP-TE LSP の作成には数時間を要したのに対し、6.4 ベータリリースでは 1,500 の LSP を作成するのに要した時間は 1 ポートにつき数分でした。 結果（表 8） すべての LSP を問題なく確立できました。試験開始後 30 秒にいくつかの LSP がダウンしましたが、こ れは Agilent N2X RSVP-TE 実装の不安定性によるものでした。 試験対象のルータはすべての RSVP-TE トンネルを確立しました。また全 RSVP-TE トンネルについて ワイヤスピードのスループットを達成しました。優先付けされた（トラフィックエンジニアリング）ト ンネルは損失を生ずることなくパケットを転送し、遅延は最小でした。加入過多試験時にパケット損失 を観測したのは、予想したとおりベストエフォートのストリームのみでした。 表 8 プレミアム トラフィック ベストエフォート トラフィック MPLS トラフィックエンジニアリング試験結果 パケット損失／秒 最小遅延 平均遅延 最大遅延 シーケンスエラー 0 20.8 µs 97.6 µs 137.0 µs 0 30,544,669 29.5 µs N/A N/A あり 19 サービスプロバイダーからのフィードバック 2004 年 9 月に EANTC が最初の試験方法を開発した後、Light Reading が主要サービスプロバイダーの 専門家をパネリストとして招き、試験計画への提言を要請しました。すべての試験事例が通信事業者に よる現在の実際の試験方法を反映し、サービスプロバイダーの将来のコアバックボーン要件を満たすこ とを確認することがきわめて重要でした。各試験事例が現実に即しており、また有効であることを確か めたかったのです。 FiberNet Telecom Group 社の Engineering 部門の Vice President である Ernest Hoffmann 氏、Network Architecture and Advanced Technology の Vice President である Jack Wimmer 氏、MCI 社の Network Technology Development 部門の Director である Glenn Wellbrock 氏を含む大手通信事業者 5 社の代表か ら大変詳細な回答をいただきました。SBC Communications 社も回答を寄せてくれました。私たちはこ れらの人々と 2 週間にわたり E メールや電話会議を通じて活発な議論を交わし、そのおかげで多くのサ ービスプロバイダー環境に適合するよう試験計画を強化することができたのです。 転送のスケーラビリティ サービスプロバイダーのパネリストからは以下のような発言がありました。 • 「1500 万フローは現在の要件を超えており、適切な数字だと思う」 • 「60 秒の試験時間は適切ではない。使用が長引いた場合、メモリリークなどのソフトウェアエラー にならないか、もっと長時間にわたって試験をした方がよい。」 • 「40 ギガルータを試験するのに 1500 万フローで十分とは思えない。」 • 「各フローの最初のパケットの遅延とフローの 2 番目以降のパケットを区別するのか（ルート検索の コストの観点から）。」 • 「POS リンク上のワイヤスピードの定義について、OC-192 と OC-768 の場合「ワイヤスピード」の 値はどれほどになるのか。」 • 「POS バイトスタッフィングについて、1 つのポートにつき 22k の IP アドレスが存在すること、ま たパケット、ヘッダーまたはチェックサムでバイトスタッフィングが起きないようにする必要がある ことを考えると、これを行うのはきわめて困難であろう。これを自動化する処理があるのか。」 • 「56 本の OC-192 と 2 本の OC-768 について、スイッチファブリック全体に負荷を分散させるため、 各試験クラスタに対応するインターフェイスをインターリーブすることを提案する。」 以下の対策を実施しました。 • 1500 万フローは十分な負荷を与えたシステムでの 5 キロバイト／ユーザ／秒に相当し、適切だと思 われるので、試験計画はそのままとしました。 • 試験時間を 300 秒に延長しました。 • 1 つのパケットが過剰に時間をとらないよう気をつけながら、各フローの最大遅延を計測しました。 • HDLC ライン符号化のため、packet-over-Sonet のワイヤスピードレートの定義は本当に困難です。 ルータが各 IP パケットを変更する（Time to Live 値を下げ、チェックサムをアップデートする）ため、 試験対象システムで予測できないバイトスタッフィングが起こる可能性があり、また HDLC 関連のビ ットパターンも現れるので、パケットがルータを通過する間にビットレートが実際に上がり、ビット ストリームが出力回線のビットレートを超過してしまう場合があるからです。HDLC バイトスタッフ ィング効果を計算したり予測したりする方法は見つからなかったので、スループットを 98%に落とし たレートで遅延試験を行う必要がありました。 • ポートとアナライザ間のリンクをインターリーブさせ、試験対象システムのシャーシ全体にフローが 分散するようにしました。 20 ルーティングのスケーラビリティ サービスプロバイダーから以下のような発言がありました。 • 「実際の環境をよりよくシミュレートするため、1 ルートにつき 1 つ以上の送信元 IP アドレスを使え ないのか。たとえば最初の試験と同じ方法（フロー数やパケットサイズを変えて）を使えばよい。」 • 「この次世代ルータが 100 万以上の BGP ルートを処理し、それらすべてにトラフィックを転送でき るかどうかを検証するのは非常に興味深い。」 • 「ルーティングの再収束試験は非常に重要である。」 • 「試験に使えるルータが物理的に 1 つしかなくても、論理的に分割されたルータ構成での再収束を確 認できるのか。」 以下の対応をしました。 • 他の試験事例と同じインターネット混合パケットストリームを使うよう BGP 試験を変更しました。 • 統計の把握があまりにも困難になるため、1 対 1 の IP アドレス／ルータ関係は変更しませんでした。 • 個別ルートの数を合計 1700 万に増やし（1 ポートにつき 23,000 の IPv4 ルートと 7,000 の IPv6 ルー ト）、各ルートにトラフィックを送信しました。 • 残念ながら試験に使えるシステムは 1 つしかありませんでした。現在のソフトウェアリリースでは仮 想ルータはまだサポートされていません。そのため実際のシステムを 2 つ使ったルーティングの再収 束試験はできませんでした。ただし Agilent エミュレータを使い、BGP 収束に対応できるよう試験計 画を拡張しました。 アベイラビリティ 通信事業者は高アベイラビリティ試験に特に関心を示しました。 • 「インターフェイスモジュールだけでなく、冗長化されたアクティブなコントロールモジュールも抜 いてみるべきだ。」 • 「ハードウェアモジュール交換手順で、装置にリムーバブルな回線カードと回線カード内モジュール がある場合、両方抜いてみるのも面白いのではないか。」 • 「ソフトウェアの保守試験については「ソフトウェアのアップグレード／ダウングレードが転送およ びルーティングに与える影響は、試験に先立ちベンダーが主張した範囲内と予想する」と明記すべき だ。」 • 「言うまでもないが、本当にベンダーの言う通りになるのか明確にしてほしい。ヒットレスは、まさ にヒットレスという意味でなければならない。 」 以下の対策を実施しました。 • ハードウェアの冗長試験を、すべてのリムーバブルな冗長ユニットをカバーするよう拡張しました。 • ヒットレスとされているすべてのソフトウェアアップグレードおよびハードウェア交換の正確な結果 を計測し、また試験開始前にベンダーの主張するところを問い合わせました。 IPv6 IPv6 試験については特に言及されませんでした。しかし直接問い合わせると、今後何年にもわたって存 続するよう設計された IPv6 はコアルータにとって「非常に重要な」実装機能であるという点でサービ スプロバイダー側と意見が一致しました。 21 マルチキャスト これに関しては以下のような提言がありました。 • 「たとえばマルチキャストグループを増やしたり、異なるマルチキャストトラフィック負荷を使用す るなど、マルチキャスト転送容量／性能の制限についてより深く考察するために、あといくつか試験 事例を追加してほしかった。」 • 「当方にはマルチキャストグループの数についてきちんとした概算がない。この試験事例で 580 を最 大数とした根拠は何か。RFC2547 (BGP/MPLS VPN)でマルチキャストをサポートする場合、もっと 数が多くなると思うのだが。」 試験時間がないため、マルチキャスト試験は拡張しませんでした。カスタマー個別のマルチキャストを MPLS VPN で転送する場合にマルチキャストグループの数が増える点については同意見です。しかしこ の試験事例はネイティブ IP に関係するものなので、グループ数はそのままとしました。 MPLS 回答には以下のようなものがありました。 • 「MPLS スケーラビリティ試験について、解放と再確立を評価するためのチャーン試験を追加したら どうか。」 • 「MPLS 高速迂回の試験はしないのか。」 • 「ケーブルまたはモジュールを抜いた場合の LSP 再収束を確認する試験はしないのか。」 • 「provider edge（PE：プロバイダーエッジ）VPN 機能の試験は可能か。 」 こうしたもっともな要求に対して、以下の対応を取りました。 • 残念ながら、トンネルの解放と再確立時間について試験装置に制限要素がありました。事前ステージ ングの段階で無効な結果が検出されたため、試験を中止しました。 • MPLS 再収束については試験を行いたかったのですが、LSP 収束の試験には少なくとも 2 つのルータ が、また高速迂回の試験には 3 つのルータが必要となるため、追加しないことにしました。 セキュリティと QoS 以下の質問が寄せられました。 • 「Access Control List（ACL：アクセスコントロールリスト）はどれだけ深くパケットの中を見るの か。送信元と宛先アドレスをチェックするだけか、あるいはプロトコル種別あるいはポート情報まで 確認するのか。」 • 「標準的な ACL エントリはどのような形か。プロトコルやポートの情報を含むのか。送信元／宛先 アドレスとプロトコル／ポートの ACL を混在させれば試験事例がより現実的なものになると思う。」 以下の回答をしました。 • 2 名のコメンテーターからまったく同じ要求が出されました。TCP と UDP ポートを ACL 試験に含め ました。 本稿は、Light Reading 社の Web サイト www.lightreading.com で 公開されているテストレポートを同社の許可を得て翻訳したものです。 22