企業ネットワークにおけるMPLS運用の現状と課題
ソニーグローバルソリューションズ株式会社

平賀 十志男<Toshio.Hiraga@jp.sony.com>

概要• ソニーグループでは日本国内においてMPLS技術を利用したネットワークを構築し、運用しています• このMPLSネットワーク運用の現状と課題および将来展望についてご紹介します2ソニーグループネットワーク• ワールドワイドでのネットワーク接続– 国内約250拠点– 海外拠点• 北米、欧州、アジア、中国• データセンター– 基幹システム• メインフレーム、サーバ– インターネット• ソニーの各Webサイト– 日本、北米、欧州、アジア、中国

3

信頼性に対する要求• 30秒程度の通信断でも工場のラインや物流などの基幹システムに影響– 国内ネットワークと国際ネットワークのシームレスな接続– SCM の整備
– タイムアウトにシビアなアプリケーション– フェールオーバーからの復帰時に手動再接続が必要なシステム– 10秒が許容できないものもある• パケットロスが基幹システムに影響– 性能劣化– Non IP プロトコルの IP カプセル化• 到着順序逆転が基幹システムに影響– 破綻するものもある– 再送がかかるものもある• ネットワーク品質がそのまま VoIP やビデオ会議の品質に– 会議不成立の可能性
4コストに対する要求• 回線コストを最適化したい– 回線利用効率を上げたい– 高価な高品質回線と安価な低品質回線を組み合わせたい– 待機回線も使用したい• 機器コストを最適化したい– 機能追加で実現でしたい• 投資を抑える• お金ではなく技術で埋める– 選択肢が多いほうがいい• 標準化された技術• オペレーションコストを最適化したい– 広く使われている技術を使いたい• 技術資料が豊富• オペレータの確保が容易• マネージメントツールの調達が容易

5

MPLS導入のモチベーション• 信頼性に対する要求に応えたい– 高速障害復旧による可用性の向上– QoS による品質の向上• コストに対する要求に応えたい– トラフィックエンジニアリングによる回線コストの最適化• IGP の最短経路に依存しない明示的なルーティング• 帯域や任意のリンク属性に基づいた最適パスによるリソースの有効活用– 機器、オペレーションコストについては今後に期待• これらを End to End で応えたい

道具の１つとしてのMPLS
6

MPLSネットワークの導入• 2004年からバックボーンの一部として稼動開始– 使用形態• MPLS-TE• EoMPLS– draft-martini– 主なプラットフォーム• GSR• Cisco7200• Catalyst 6500

• 大規模なトラブルもなくそれなりに動いている

7

MPLS-TEネットワークの概要• Ethernet• ISIS-TE• RSVP-TE w/ Fast Hello– 帯域指定などは特にしない• 明示的なパス指定– 固定料金回線をメイン、従量課金回線をバックアップとするとか– 高品質回線をメイン、Not So 高品質回線をバックアップとするなど• 高速回復– Link Protection– Node Protection• ユーザルート用ルーティングプロトコル– TE 上では eBGP, iBGP のみを使用– BGP ルータを Head End/Tail End とする• E-LSP QoS
8

マネージメント• MIBベース– RSVP-MIB、LDP-MIB、LSR-MIB、TE-MIB、FRR-MIBなど– 足りないMIB• PWE3-MIB• ISIS-MIB• コマンドラインによるポーリングを併用

9困った事象 (1/2)• なぜか FRR 事件– 原因不明の PathErr• なぜか RSVP Hello が落ちている– CPU が落としたらしい、がなぜ?
• write memory– write memory をしないというオペレーションは考えられない– とりあえず Hello Interval を400msにしてみることで回避• トータルで write memory 時間より長くする– いまは OS で改善されている

10

困った事象 (2/2)• あれ、それでもFRR?事件– 原因不明の PathErr• なぜか RSVP Hello が落ちている– CPU が落としたらしい、がなぜ?
• CPU 使用率100%?

– OS Architecture 上仕方のないことなのか?
– RSVP Hello や BFD などの高速 Keep-alive 技術はHardware Offload なしで本当に大丈夫なのか?
• 特に Ethernet ではなんらかの Keep-alive に頼らざるを得ない• いずれにせよ、CPU による力技実装ではなくHardware 処理による実装をもっと進めて欲しい11

EthernetでのFRR (1/2)• FRR Trigger となるもの– Link Down Æ Link Protection– Node Down Æ Node Protection• POS に比べてそれほど高速ではない– 現在はかろうじて１秒以内というレベル– Interface Down 検知が思ったほど早くない• デフォルトの Carrier Delay のままでは RSVP Hello による検知が一番早くなる• Carrier Delay = 0 にしても検知は最低数百msのオーダー• プラットフォームによって Interface Down 検知と PathErr の出方が違う– Interface Down のあと PathErr を出すもの– Interface は Up のまま Line Protocol Down のあと PathErr を出すもの– Interface Down と Line Protocol Down の検知の早いほうで PathErr を出すもの• Carrier Delay = 0 でも RSVP Hello による検知のほうが早い場合もある

12

EthernetでのFRR (2/2)• 改善策はあるのか– RSVP Hello の間隔を短くする方法• Line Card で Offload できるようにならないと厳しい• できるなら10msくらいがいいのでは– Ethernet でも LoS 等で FRR が作動するようにする方法• できるようになるとかなり改善が期待できるはず• 実装は…

– Path Protection を使う方法• PLR から Head End までが近い場合(低ホップ数、低 RTT)はプラット
フォームと障害ケースによっては FRR より速い可能性– FRR 終了までのタイムラグ (LFIB UPDATE) の存在– 実装は…
PathErr
10ms

Primary LSPHE
200ms
100ms

backup LSP• いずれにせよ、MPLS + Ethernet の使い勝手をもっと向上させて欲しい
13

そのほかの課題• Catalyst 6500 の実装– 12.0S系と12.2S系のロードマップの違い– InterAS-TE の実装は?

• JUNOS との相互接続– 現在 IOS の仕様依存の TE Tunnel(Numbered) を使用しているため、JUNOS ではMPLS を使用してない– InterAS-TE の実装は?

14

今後の展開(1/2)• MPLS-TE Ready ネットワークの拡大– OSPF Æ ISIS-TE– Backbone Æ End to End• マネージメントツールの導入– いまは MPLS ルータや LSP が少ないこともあり、すべて手作業でのプロビジョニング– いくつかのツールを検討中

15

今後の展開(2/2)•TE 設計の変更– InterAS-TE の導入• IGP ドメインを分けたい– 地理的に離れているネットワーク– サービス対象が異なるネットワーク– オペレーションチームが異なるネットワーク» 企業網とキャリア網» 企業網内であっても分かれている-- 国の違い、担当サービスの違い– Path Protection の導入• FRR との併用
– FRR 失敗時の保険や管理ドメインが異なるときなど• 実装しだいだが場合によっては FRR の代わりに• MIB の実装は?

•Internet VPN TE– End Site 間の Internet VPN を MPLS-TE LSP 用リンクの一部として使用• RSVP Hello や BFD を飛ばしたい• 品質ベースで LSP 最適化ができるといいのでは

16

その他にあるといいもの• Label を処理できる Middle Box– 特に Security 関連• C-Plane の Security も重要だが、D-Plane の Security も重要• IPv4 Unicast 以外の Packet の TE での Carry– Multicast• P2MP-TEは使えるか– IPv6
• Multicast も使いたい• Hierarchical TE– LSP Service への接続用

17まとめ• ソニーグループのMPLSネットワークの概要
および運用の現状と課題、さらに将来展望をご紹介しました• MPLSはまだまだ発展途上の技術であると思いますが、ますます厳しくなるネットワークの各種要求に対応するために必要不可欠な技術であると確信しています18

• ご清聴ありがとうございました• ご意見、ご質問、ご指摘等がありましたらお願いします
mailto: Toshio.Hiraga@jp.sony.com

19