MPLS網でのフローモニタリングの実践小林 淳史
NTT情報流通プラットフォーム研究所
伊藤 知治
株式会社エヌ・ティ・ティ・ドコモ
Oct, 2007

MPLS JAPAN 2007

1

概要
MPLSトラヒック・モニタ機能について（小林）NetFlow, sFlow, IPFIX/PSAMPMPLSフロー監視に必要とされる機能
トラヒック交流の可視化
今後の課題

トラヒック・モニタリングの実践（伊藤）ドコモMPLS網の紹介
トラヒックモニタ機能の必要性
実践状況
Oct, 2007

MPLS JAPAN 2007

フローモニタを身近に感じる.
2

MPLS トラヒック・モニタ機能について

Oct, 2007

MPLS JAPAN 20073

トラヒック・モニタ機能
カウンタの世界
サンプリング・ランダム

IF-MIBカウンタ
LSR-MIBカウンタ
NetFlow（フロー単位のカウンタ）

・フィルタリング

IPFIX
PSAMP

フロー・パ
ケット単位の情報を配信

sFlow

ミラーリング・スイッチによるミラーリング
フルダンプの世界
リモート・ミラーリング
Oct, 2007

MPLS JAPAN 2007

全てのトラフィックもしくは、特定のVPNを指定可能．

終点PoP起点
PoP

VPNレベルのトラヒック交流量
パス交流量が認識可能.
ネットワークの品質が監視可能（将来）
4

フローとは?
共通属性をもつパケットの集合.
NetFlowでは、以下の属性のものをフローとして一般的に認識されている.
Source/Destination IP Address
Source/Destination Port
IPの情報＋ラベ
7-tupleProtocolルもキー情報として含まれる.
Input Interface
TOS
どの粒度でトラヒックMPLSでは?
を監視するか?
MPLS Label 1, 2, 3 …
・7-tuple+MPLSラベル
・MPLSラベル
Input Interface
Oct, 2007

MPLS JAPAN 20075

フロー配信のタイミング
Push型でフロー毎にデータが配信される.
ActiveTime（フロー最大継続時間）
InActiveTime （フロー無通信時間）

監視すべき時間精度に合わせて決める.

フロー最大継続時間（1分〜30分）

フロー無通信時間（15秒）

インターネットの世界:
ActiveTime=1分,InActiveTime=15秒でサンプリングなしで1Gb/sのト
ラヒック量 でおおよそ15kフローレコード/秒が配信.
Prefix”/24 で集約するとおおよそ1kフローレコード/秒となる.

フロー＝MPLSラベルの集合とした場合:
大きい粒度のため、フローの配信量は、極端に抑えられる.
Oct, 2007

MPLS JAPAN 20076

監視する領域
Byte数のカウンタは、どこを示す?
IF-MIBでは、EtherFrame
MPLS NetFlowでは、MPLSラベル＋MPLSデータ長L2VPNとL3VPNの場合で監視する領域が異なることに注意.
IF-MIB

NetFlow

EtherIPFCSLabel Label Ether
Label Label

IP
IP

Labelの領域を含めるか否かは、設定にて変更可能.
Oct, 2007

MPLS JAPAN 2007

ボリュームが微妙に異なることになるので、注意.
7

MPLS運用に関するNetFlowの位置づけ
フローの情報=パケットヘッダに関わる情報
設定（Configuration）に関わる情報は、各種MIBから収集．
足りない情報を補ってトラヒック交流、パス交流を生成.
VPN単位の情報

PW-MIB

Psuedo-Wire単位の設定情報
・設定情報（Pw-id,適用IF）

VPN-MIB

VRF単位の設定・ルーテイング情報
・設定情報（RT,RD,適用IF）
・VRF MP-BGP経路情報

フロー情報
LSR-MIB
ルーティン
・VPNラベル,ルーテイング
MPLS運用の中心的な情報を集約
グラベルに
ラベル値
関わる情報 ・ルーティング情報 In/Outのラベル情報
・ホストIPアドレス
・ラベル毎のカウンタ（byte,packets）
・ポート番号・パケット数・byte数TE-MIB
LDP-MIB
プロトコル
TEトンネルに関わる情報に関わる LDPセッションに関わる情報
・トンネルの宛先、Hop経由の情報
・セッションの隣接関係,Status
情報・トンネルのStatus情報
情報
Oct, 2007

MIBについては、実装（OS）毎に差異があるため、留意が必要．
MPLS JAPAN 2007

8

MPLS/IPフローの悩みごと
NWの大規模化への対応
フロー数増大への対応.
現状の精度を維持してスケーラビリティの向上を図る.
コレクタ側全体のスケーラビリティが必要.

網統合化への対応
網内の様々なトラヒックを用途に応じて収集・分析どう見せるか?
設備設計・需要予測として必要な見え方?
機器障害・トラヒック変動の検知としての必要な見せ方?
Oct, 2007

MPLS JAPAN 2007

9NWの大規模化への対応
フローの大規模化への対応：コレクタの階層化
フローの振り分け：用途に応じたフローの振り分け
フロー変換・集約する際の必要な機能を提案中。
We can select the all trafficor specific VPN (customer).

Destination
PoP

SourcePoP

ネットワークドメイ
ン全体のトラヒッ
ク交流の可視化

全てのトラフィックもしくは、特定のVPNを指定可能．

終点PoP

………

………
………

………

起点
PoP

全てのトラフィックもしくは、特定のVPNを指定可能．

IPv6 Multicast VPN#1
中継#1

PoP#1

中継#2

PoP#2

中継#3

PoP#10

IPv4

フロー集
約・変換

Core Edge
EdgeNetFlow
observation
Point

VPN#1

終点PoP

起点
PoP

中継#1

フローの中継機能に着目

Core Edge
Edge

PoP#1

NetFlow
observation
Point

draft-kobayashi-ipfix-mediator-model-00
Oct, 2007

MPLS JAPAN 200710フロー情報の中継機能
ラベルを意味のある情報に変換
情報を集約する・情報を変換する
NetFlow
10.0.0.2

IPFIX

属性値

IN_BYTESXXINPUT_IFXX

OUTPUT_IF

XX

IN_PKTSXX

MPLS_TOP_LABEL
_TYPE

LDP

MPLS_TOP_LABEL_IP_ADDR

10.0.0.1

MPLS_LABEL_1

548.1.0

MPLS_LABEL_2

32699.1.1

Oct, 2007

全てのトラフィックもしくは、特定のVPNを指定可能．

NetFlow
変換

IF−対地
情報

経路情報
MPLS JAPAN 2007

IPFIX

終点PoP起点
PoP

属性

値

IN_BYTES

XX

IN_対地

XX

OUT_対地XX

IN_PKTSXXEXPORTER_IP

10.0.0.2

MPLS_TOP_LA
BEL_IP_ADDR

10.0.0.1

Cos1

RD65535:10
11

フロー情報の中継機能の実装
一般的なPCを用いても十分な変換を作成可能.
100%
80%
CPU Load

フリーのコレ
クタを活用することも可能.
NetFlow
v.9

ルートリフレクタ+RD

RD,
VPN識別子変換

経路情報

40%

3 kf/s20%

encodeBGP

60%

decode0%1101000

10000

flow rates (f/s)

《環境》-Pentium(R) 4 CPU 3.40GHz-FreeBSD 5.5

・普通のPCにて十分実装可能.
・フローを自由に操れる環境を！

NetFlow
v.9

Oct, 2007

100MPLS JAPAN 200712

トラヒック交流量の見える化
設備設計・需要予測の検討もしくは機器障害・経路変動を検知する上で、トラヒック交流量の変化は、どう見えるとうれしいか?
2次元の世界から3次元の世界へ

東北東京

Oct, 2007

送信元
MPLS JAPAN 2007

北海道
東北関東
東京
…

送信元

北海東北 道
関東
東京
…

北海道
東北関東
東京
…

北海道
東北関東
東京
…

送信先

北海道

関東

送信先
13

トラヒック交流量の見える化
トラヒック変動などに対する対応
影響のあるVPNの把握、VPNの需要予測.
VPN#1

トラヒック
全体トラヒック変動（急激な上昇）Oct, 2007

VPN#2

MPLS JAPAN 2007

14

MPLS/IPフローの更なる悩みごと
トラヒックの大きなVPNが支配的サンプリングにより、小さいトラヒックのVPNは、埋もれる.
VPN毎のサンプリングレートの設定.

ネットワーク品質の監視
現状のLoss,Delayが大まかにどうなっているのかという需要は強いはず.
多様化したサンプリング機能の実装が必要.

RSVPなどへの対応
パスとフローの結び付け方?可視化も含めた検討が必要.

マルチキャストへの対応
マルチキャストのようなトラヒック特性の監視.
Oct, 2007

MPLS JAPAN 200715

トラヒック・モニタリングの実践

Oct, 2007

MPLS JAPAN 200716

ドコモIPルータ網の紹介

Copyright©2007NTTDoCoMo Inc.All rights reserved.

■ドコモIPルータ網の紹介□３G（FOMA）のパケットトラヒックの増大に対応可能な、低コストでより高速・大容量なNWサービスを提供するために2003年度より運用□広域イーサネットとIP-VPNサービスの特徴を併せもつVPNバックボーン□FOMAトラヒックのほかに、オペレーションのトラヒック等、１００を超えるシステムを収容しているドコモの基幹ネットワーク
IPルータ網

VPN#1
Site1

PE

L3VPN
CE

PE
PE

VPN#2
Site1

Oct, 2007

CE

L2VPN
CE

PE

MPLS JAPAN 2007

PECE
CE

VPN#1
Site2

VPN#1
Site3

VPN#2
Site2

17

Copyright©2007NTTDoCoMo Inc.All rights reserved.

トラヒックモニタ機能の必要性１■IPルータ網では見做しギャランティ型のネットワークを構築しており、システム毎に予測された計画帯域での設備設計を実施している。
■ユーザシステム毎のトラヒック予実管理を実施し、余剰な投資が発生しないようにしている。

①申請
帯域③新たな申請帯域

②実績
ﾄﾗﾋｯｸ

設備削減効果しかし・・・

Oct, 2007

MPLS JAPAN 200718

Copyright©2007NTTDoCoMo Inc.All rights reserved.

トラヒックモニタ機能の必要性２■PEのCE向けIFにおいては、IF-MIBよりユーザシステム毎の実績トラヒックが把握できるトラヒック交流が把握できない。

・このリンクのトラヒック交流の内訳は？
・何のシステムのトラヒック？
・主に流れているシステムは？

■トラヒックが多重されている区間では、IF-MIBではユーザシステム毎のトラヒックが把握できない。
MPLS NetFlow で測定できないか？
Oct, 2007

MPLS JAPAN 2007

19

Copyright©2007NTTDoCoMo Inc.All rights reserved.

MPLS NetFlowでのトラヒック測定１■NetFlow機能とFlowコレクトサーバを活用し、Flowデータを収集。
■集計サーバにて、Ｆｌｏｗ情報のＬ１・Ｌ２ラベルから、対地情報及びＶＰＮ情報への対応づけを行うために、集計サーバからルータに接続し、プロバイダールータからL1ラベル情報を、プロバイダーエッジ及びルートリフレクターからL2ラベル情報を収集する。

Flowデータ収集
Flowデータ収集（フロー/トラフィックデータ）（フロー/トラフィックデータ）

Flowコレクトサーバ

OSS
サーバ
集計サーバ

ｵﾍﾟﾚｰｼｮﾝ

サンプリングしたパケッ
サンプリングしたパケッ
トの統計情報を収集
トの統計情報を収集

各情報を集計し対地間VPN
各情報を集計し対地間VPN
トラヒックを算出
トラヒックを算出
P

L2ラベル情報取得
L2ラベル情報取得
PE

L1ラベル情報取得
L1ラベル情報取得

ルータ網
システムA
システムB
システムB

Oct, 2007

MPLS JAPAN 2007

システムA

20

Copyright©2007NTTDoCoMo Inc.All rights reserved.

MPLS NetFlowでのトラヒック測定２■収集したラベル情報及びＦｌｏｗ情報をユーザに表示するサービス名・ノード名と関連付けるため、ＯＳＳサーバよりサービス情報・ノード・リンク情報等を収集する。
■トラヒック表示画面にて、リンクを選択すると、DBに対して収集要求を行い、選択リンクに対する対地間VPNトラヒックが表示される。
Flowコレクトサーバ

集計サーバ

OSS
サーバ
連携

ｵﾍﾟﾚｰｼｮﾝ

Flowデータ収集
Flowデータ収集（フロー/トラフィックデータ）（フロー/トラフィックデータ）

各情報を集計し対地間VPN各情報を集計し対地間VPN
トラヒックを算出
トラヒックを算出

Flow収集Oct, 2007

L1/L2ラベル収集
MPLS JAPAN 200721

Copyright©2007NTTDoCoMo Inc.All rights reserved.

トラヒック表示■ ユーザ単位での地域間集計やIPルータ網全体トラヒックの地域間集計が可能であり、ピーク値のマトリックス表示やトラヒックの異常/増加傾向等を把握するためトラヒックグラフ（実績/使用率）表示が可能となっていグラフ1：ＶＰＮ/対地指定の送受信グラフ
る。
表示期間 ：2006/03/01〜2006/04/01
サービス名 ：＊＊＊＊＊＊
VPN名 ：＊＊＊＊＊＊（またはALL）
対地指定 ：局A〜局B

送信受信

グラフ2：ユーザ指定における全地域間グラフ
表１：システム別対地間交流（別ツールを使用）
outinA

B

CDE

FGA
B
CE

指定期間内の最大通信量（トラヒック量/（トラヒック量/使用率）

F

Ａ〜Ｃ

G

ユーザフィードバックに使用
Oct, 2007

Ａ〜Ｂ・・・

D

表示期間 ：2006/03/01〜2006/04/01
サービス名 ：＊＊＊＊＊＊
VPN名 ：ALL
対地指定 ：ALL〜ALL

MPLS JAPAN 200722

統計情報の精度の分析

Copyright©2007NTTDoCoMo Inc.All rights reserved.

■MPLS NetFlowで測定したデータはどのくらいの精度なの？
□IF-MIBとの差はどのくらい？
MPLSラベルとMPLSデータ長は考慮すべし。
□サンプリングレートの最適値は？

サンプリングレートを高めるとCPU使用率も高くなる。
□測定周期の最適値は？

測定周期を長くすると、ユーザトラヒックの振る舞いにより、精度に大きな差がでる。
測定周期を短くすると、帯域の小さいユーザの精度が悪化する。
Oct, 2007

MPLS JAPAN 200723

Copyright©2007NTTDoCoMo Inc.All rights reserved.

今後の課題■トラヒックモニタ機能の精度向上□サンプリングレート
商用での負荷は設計条件より低いと考えられるため、商用状況を反映したサンプリングレートの検討。
□収集周期
主なユーザシステムの帯域と時間変動を考慮し、最適に測定できる収集周期の検討。
□ピークトラヒックの推定設備設計に反映させるという観点から、ピークトラヒックの推定が必要。そのピーク値の精度を高めたい。
Oct, 2007

MPLS JAPAN 200724

ご清聴ありがとうございました

本発表の一部（4ページから15ページまで）は総務省委託研究課題「次世代バックボーンに関する研究開発」の成果である．
Oct, 2007

MPLS JAPAN 200725