運用管理からフロープロトコル解説

#運用管理からフロープロトコル解説

###フローマネージメントとは
ソースとデスティネーション間のフレームの流れを
以下のような内容などを認識し分析すること
・Source / Destination Address
・Source / Destination Port 番号
・Protocol
・Interface
・TOS ( IP type of service )　/ Priority ( 802.1p )
・VLAN (802.1Q)
・AS番号
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/d0622482-feb7-73b1-9d0e-acc52cc4c719.png)
次のような分析が可能
ーなぜ、ネットワークが遅いのか？
ー誰がネットワークを使っているか？
ー誰が何をしているか？
－セキュリティ対策は出来ているか？
ーSPAM・DoS攻撃・ウイルス・ワームは？
－ネットワークの使用内容は？
ーマルチキャスト通信は、どの程度？

####運用管理おさらい
運用管理の基本機能
(1) 構成管理
ネットワークを構成している各種構成要素を個々に管理し、 また、その各種構成要素の接続の状態をトポロジーマップとして表示
(2) 障害管理
各種構成要素に対しステータス確認を行い障害を検知する、 あるいは、各種構成要素からのイベントを受信することなどによって 障害を検知
(3) 性能管理
ネットワーク・システムの性能・パフォーマンスを定量的に測定

運用管理おさらい

構成管理
管理内容
・構成機器の種類
・トポロジー・ノード間接続状態の把握
・オート・ディスカバリとダイナミック・マップ
・マップの自動更新（ネットワークの変更も自動的に把握）
・マップのカスタマイズ
・管理・非管理の指定
利点
・管理者の負担を軽減し、構成管理を容易にする
・最新のネットワーク構成の把握
・問題の発生箇所の素早い特定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/409a4957-957c-8a97-1589-1d82418c1a0c.png)

障害管理
管理内容
・ネットワークの状態のモニタリング
・監視対象の障害検知
・イベント通知
・イベントに対する自動アクション
・しきい値のユーザ定義
利点
・中央で全てのイベントを集中的に管理
・問題の発生箇所の素早い特定と自動対応
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/1c314ae2-21c6-ef1f-95b0-beeff68a45a3.png)

性能管理
管理内容
・SNMP-MIB情報の収集、各種レポート化
・測定値（Pingの応答、SNMP-MIB値）の収集
・各種レポート化
・問題箇所の把握
・しきい値による性能変動の把握
・統計値による分析・障害管理
利点
・ネットワーク・システムの性能を定量的に把握
・ネットワーク・システムの性能を一定レベルに維持
・使用動向の把握・予測・計画
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/4fbf2010-39a0-b6be-bddb-753cd7c8f517.png)

####”性能管理”から”トラフィックフロー管理”へ
トラフィック・フロー管理

トラフィック・フロー管理
・誰がネットワークを使っているか？誰が何をしているか？
・誰と誰、何処と何処が、どのような通信（プロトコル）を、
どの程度（バイト数、フレーム数）行なっているか？

フロープロトコルの解説（関連技術）
SNMP
RMON/RMON2
sFlow / sFlow 802.11
Cisco NetFlow
Juniper J-Flow
IPFIX
HP XRMON / RiverStone LFAP
sFlow vs NetFlow

SNMP

SNMP（Simple Network Management Protocol）
・1988年の開発以降、インターネットワーク管理のデファクト・スタンダード
・管理対象となるネットワーク機器に常駐するSNMPエージェントと、
管理する側のSNMPマネージャとのUDP通信により実現
・SNMPエージェントは監視対象機器の情報を、「MIB（Management Information Base）」と
呼ばれる「管理情報ベース」に蓄積
・SNMPマネージャはSNMPエージェントが取得したMIBの内容から、監視対象機器の状態を
統計値として判断
－フレーム数、バイト数、エラーフレーム数、帯域幅使用率 etc

基本はインターフェース/VLAN単位での統計値の収集
➡ MIBⅡ(RFC1213) Interface Group / IF-MIB(RFC2233)のHighCounter（64bit）etc
その他の統計値はRFCにて各種拡張・プライベートMIBにて拡張
－DOT3、DOT5、CPU使用率、温度　など

トラフィック情報は？誰と誰がどのような通信を行なっていたか？
SNMP(MIB2)では、**トラフィックの内容に関する情報・統計値は把握できない**
➡　 **RMON / RMON2 への拡張**

SNMP （MIB OID）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/2fb37ad9-fbc3-a784-5849-606d312862fb.png)

RMON2

RMON (Remote Network Monitoring)
遠隔地(Remote)にあるLANのトラフィックなどの通信状況をモニタリングする機能。
SNMPの拡張機能として提供され、統計値はMIBデータベースに蓄積される。
－RMON（RFC1757）➡ レイヤー２以下（物理層、データリンク層）を管理
－RMON2（RFC2021）➡ レイヤー３以上を管理 (ICMP/IP/UDP/TCPなどが管理可能なので　　　　　　　　　　　　　　　　　　　　　　　　　トラフィック分析が可能）

RMON2の問題点
RMON２プローブが必要
・ハイスピードネットワークでは非常に高価：ギガポートのモニターで一台数百万円
・特定の範囲のみの管理  全社的な管理は不可能
・大量のトラフィックに対しては取りこぼす可能性
ネットワークトラフィックに対して不十分な情報
・特定のプロトコルのみの分析
・リアルタイム性がない
ネットワークパフォーマンスへの影響
・RMON2情報の収集の為に、プローブとマネージャー間で大量のトラフィック
RMON2実装スイッチ
・RMON2を動作させるとスイッチのパフォーマンスに多大な影響
ハイスピード・ネットワークやスイッチング・ネットワークでは適用しづらい

RMON2 (MIB OID)

RMON2
トラフィック情報はMIB値とてカウントされる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/141879c4-b554-398a-39e9-78fa63050267.png)

sFlow

sFlowの誕生

トラフィック・フロー分析のトラディショナルな解決法
SNMPカウンター:
・インターフェース単位のオクテット数・フレーム数などのカウンター情報
・トラフィック情報なし
RMON2:
・RMON２プローブが必要（非常に高価）
・ネットワークトラフィックに対して不十分な情報
・ネットワークパフォーマンスへの影響　など
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/6fbc0074-68e6-22ab-6cc0-582f54904b1c.png)
**トラフィック・フロー分析の次世代の解決法 　➡　sFlow の誕生**
今まで。。。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/e4e7dde6-cbd8-37b6-237d-31a6c9c6a112.png)



sFlowとは

サンプリングベースのテクノロジー
・スイッチやネットワークのパフォーマンスへの影響が少ない
・ハイスピードネットワーク内のトラフィックをモニタリングする事を目的として
新たに考案されたテクノロジー
米国InMon社によって公開 ： Open Standard – IETF RFC3176(sFlow V4)
ネットワーク機器埋め込み型として設計されたモニタリング・テクノロジー
・ルータスイッチ内に実装されスイッチのASICにて処理
・全てのスイッチ・ポートをモニター
スイッチのsFlowエージェントがsFlowを生成し、sFlowマネージャーへ即座に送信
・MIBやキャッシュ上で保持・カウントしない

sFlowの動作
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/d9011c9b-6bec-a28e-6be0-d785f6f309a2.png)

sFlowデータグラム・フォーマット
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/942f990b-3566-df95-0357-dea0753b5a32.png)

トラフィック量の計算

パケットサンプリングとトラフィック量の計算
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/a92289ef-2175-d126-a6d4-5b8b94ff8468.png)

サンプリングの誤差（解析精度）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/8762a638-7186-28da-354f-f5df4d11dc95.png)

誤差とトラフィックはトレードオフの関係

誤差とトラフィックはトレードオフの関係（トラフィック=分析対象トラフィック）
・トラフィックが多い　　➡　誤差は少ない
・トラフィックが少ない　➡　誤差は大きい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/77951efd-7d0d-2539-9ea7-becc82c5e842.png)

誤差を少なくするには？
対象となるフローを増やす
・サンプリングレートを上げる？
➡サンプリングレートはインターフェース単位に可変であるが、
分析の為の頻繁な変更は困難
分析対象期間を延ばす？

誤差を少なくする分析

誤差を少なくする分析
トラフィックが多い場合：通常のサーバーアクセス（HTTP通信など）、DoS攻撃
➡　トラフィックが多いので、リアルタイムでも誤差は少ない
トラフィックが少ない場合：使用頻度・通信量の少ない通信（チャット通信など）
➡　トラフィックが少ないので、リアルタイムでは誤差が大きい
➡　対象期間を延ばす（“分”から”時間“,”日“,”週“,”月“へ）と対象トラフィックが
多くなるので、 誤差が少なくなる

サンプリング分析のコンセプト
・メジャーなトラフィックは、誤差が少なく、リアルタイム性も保たれる
・マイナーなトラフィックは、対象期間を延ばし、誤差を低減
・スイッチ・パフォーマンス、ネットワーク・パフォーマンスの悪化を防ぐ

**サンプリングベースのテクノロジの為、1G/10Gネットワークから更なる広帯域への対応が可能**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/593f799c-1503-5b18-55ac-845600e8ce39.png)
**将来的な100G(ｷﾞｶﾞﾋﾞｯﾄ)、1T（ﾃﾗﾋﾞｯﾄ）、10T、100Tネットワークへの対応**

パケットサンプリングの歴史
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/2a9a4932-a1f6-8257-297a-439183279c92.png)

sFlowエージェント実装ベンダー

現在では、下記の多くのベンダーで実装されている（デファクトスタンダート化へ）

A10 Networks
ADARA Networks
Aerohive
AlaxalA Networks
Alcatel-Lucent Enterprise
Allied Telesis
Arista Networks
AT&T
Aruba
Big Switch Networks
Black Box Network Services
Brocade
Cameo Communications
Cisco
Comtec Systems
Cumulus Networks
Dax Networks
Digital China Networks (DCN)
Dell
D-Link
DrayTek Corp.
Edge-Core Networks
Enterasys
Extreme Networks
F5
Fortinet
Gambit Communications
Hewlett-Packard
Hitachi
Huawei
IBM
IP Infusion
ITS Express
Juniper Networks
LANCOM Systems
LevelOne
LG-ERICSSON
Maipu
Mellanox
MRV
NEC
NETGEAR
Nevion
Open vSwitch
Overture Networks
Pica8
Plexxi
Pluribus Networks
Proxim Wireless
Quanta Computer
Radisys Corporation
Silicom Ltd.
SMC Networks
Themis Computer
Vyatta
Xenya
XRoads Networks
ZTE
ZyXEL
And ….. InMon Corp.

詳しくは、
http://www.sflow.org/products/network.php
を参照いただき。
詳細は、ネットワーク機器ベンダーにご確認ください。

Cisco NetFlow

Cisco NetFlow　➡　Ciscoが開発した技術
・ネットワーク上のIP フローについてネットワーク管理者が情報収集する手段を提供
・エクスポートされたNetFlow データは、ネットワークの管理やプランニング、課金、
攻撃対策、データ マイニングなど、様々な用途に利用可能
・NetFlow が出力する基本データは、「フロー レコード」と呼ばれる
・バージョン1,5,7,8,9が存在
・バージョン９は、RFC3954として公開
・一般的には、全てのポートをモニターするのではなく、特定のポートをモニター

キャッシュ・ベースのテクノロジー（キャッシュ上でフローをカウント）

L3以上のトラフィックの分析が可能（L2の分析（MACアドレスなど）は不可）

NetFlowは、フローとして集計された情報として送られる
➡　マネジャー側でフロー情報化する必要がない

パフォーマンス上に問題がある場合は、サンプリング・テクノロジーを使用した“Sampled NetFlow”も用意されている

Sampled NetFlow 機能を使用すれば、ルータに転送される「x」個の IP パケットごとに 1 個のパケットをサンプリングできます。サンプリング パケットは、ルータの NetFlow フロー キャッシュに取り込まれます。 このサンプリング パケットにより、大多数のパケットに対して NetFlow 用の追加処理が不要となるので、スイッチング処理がより高速に行えるようになり、NetFlow パケットの処理に要する CPU 使用率を大幅に低減できます。 （「Ciscoマニュアルより」抜粋）

フロー

以下の図の内容を、フローとして、統計値（フレーム数・バイト数）を
NetFlowキャッシュ内でカウント

NetFlowキャッシュ内で保持・カウントしている情報を、特定のタイミング（条件）でエクスポート
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/0f0530f2-0695-f416-dcba-c6ea44d46429.png)

フローをエクスポートするタイミング
・インアクティブ・タイマー（デフォルト：１５秒）
－該当のフローセットのセッションが１５秒間インアクティブ（無音）の時、エクスポート
－コマンド ” ip flow-cache timeout inactive 15 “で設定
・アクティブ・タイマー（デフォルト：３０分）
－該当のフローセットのセッションが継続している場合、３０分経過時点で、エクスポート
－コマンド ” ip flow-cache timeout active 30 “で設定
・TCPコネクションのRSTやFINフラグの検出
・NetFlowキャッシュがフル
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/54bb477b-8475-3c92-dce4-16b1a6e263d0.png)

Juniper J-Flow

J-Flow　➡　Cisco NetFlow version 5 と同等

フローサンプリングを推奨
－アカウンティング用のフローモニタリングは、モニタリングエンジンと収集エンジンの双方に
大きな負荷がかかるため

信頼性・誤差
－sFlow同様、信頼区間の考え方を利用

99%信頼区間にて、誤差±3%以内の範囲にて分析することを推奨
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/1fd76bb4-c9ee-0388-7be5-c1a06a098fb2.png)

**J-Flowは、NetFlowの技術を使いながらサンプリング理論については、InMonの理論を推奨している。**
**「Juniper大規模組織のためのトラフィック量追跡管理と使用量割り当て制限」を参照。**

IPFIX

IPFIX
・IETF IPFIXワーキンググループによる標準化
・Cisco NetFlow V9をベースに開発
・RFC5101として仕様化（2008年1月）
・マルチベンダー：Cisco / Nortel Networks/ NEC / HP etc
・フロー送信プロトコル：SCTP（Stream Control Transmission Protocol ）を使用
(UDP/TCP もオプションで使用可能)

プロセスの定義:
・Observation Point ： 観測するネットワーク上のポイント（Interafaceなど）
・Observation Domain ： Observation PointのSet（Router/Switchなど）
・Meter Process ： サンプリング・フィルタリング。フローの解析
・Exporter Process ： テンプレートにあわせてフローレコードとしてエクスポート
・Collector Process ： Exporterから送られた情報をコレクション
・Application Process ： コレクションされた情報を視覚化・分析
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/767e8da9-539e-8cae-9271-dc5f5961d822.png)

IPFIXの今後
2008年1月に正式RFC化  ベンダ実装は今後
・RFC5101：IPFIXプロトコル仕様
－Export Process から Collector Processへの送出方法
・RFC5102：Information Model/Elementの定義(Meter/Export Process)
－自由度が高い
・RFC5103：双方向フローのエクスポート
NetFlowからの移行
留意点
・実装方法　➡　簡略化
・サンプリングへの対応
－誤差の把握：マネジャー(Application Process)側での対応
－IETF PSAMP WGとの連携

**現状（2020年）として、普及しているとは言えない。**
**また、IETF PSAMP WGとの連携ともうまくいっているとは言えない。**
**－＞サンプリングの公式な解がない（策定は困難と思われる）**

Nortel Networks
対応機器
・Ethernet Routing Switch 5500/8600 シリーズ

HP XRMON

HP Extended RMON(XRMON)
1993年 HP社によって策定
HP ProCurveスイッチによって実装

Riverstone LFAP

Riverstone LFAP(Light-weight Flow Accounting Protocol )
2001年 RiverStone社によって策定
2006年 ルーセントが買収（現ルーセント・アルカテル）

#####sFlow vs NetFlow

sFlow
・RFC3176として公開（機器ベンダ非依存のオープンな規格）
・サンプリングベース
・対象レイヤー：L2-L7+Payload
・高速スイッチングネットワークの測定を目的に開発
➡　WANのモニタリング（BGP AS path 分析）
・全インターフェースをモニター
・AS分析(OriginAS/SourcePeerAS/DestPeerAS/DestinationAS Path)

NetFlow
・RFC3954として公開（Cisco色が強い）
・キャッシュベース
・対象レイヤー：L3-L4
・WANリンクの測定が主たる目的としてリリース
➡　LANのモニタリング（CatalystへのNetFlowの実装）
・特定のインターフォース(VLAN等)をモニター
・AS分析（SourcePeerAS/DestPeerAS）

ロケーションの違い：sFlow=全体／NetFlow=Core or WAN
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705452/5160ec1d-573d-023d-84ec-9dcfa7fa2410.png)