2.1 Flow基本概念
在网络中，流flow代表通信的对等端的一条连接。有多种方式来进行标识，在不同的应用中各不相同，通常我们关心的流记录分类依据由一个五元组（即源地址、目的地址、源端口、目的端口和协议类型）所组成。流的生命周期图如下：
其中有几个是关键帧(包)：
l 产生：当一个四元组sip sport dip dport第一次出现
l 应用识别：明确标识流承载的应用protocol
l 状态：根据所承载的应用协议更新状态机的状态
l 结束：可以是显式(如tcp fin)或者隐式(超时)
一个比较有意思的问题是，通过这些关键帧是否可以足够精确的还原一个流，这有点类似视频处理中的关键帧技术。
流对象还需要封装下面一些属性：
l 流的方向问题：单向流 vs 双向流(NetFlow是单向流)
l 流量统计
l 时间标记
l 当前状态
l …..
2.2 流量测量与分析系统的几个关键因素
Flow级的处理是流量监测的主流，前面讨论的流是一个比较粗的概念，实际上对流可有更细致的分类：
n 应用未识别的流：没有对流中承载的应用进行应用识别
n 无状态协议已识别流：已对流中承载的协议进行识别，但不维护状态
n 有状态协议已识别流：已对流中承载的协议进行识别，并维护状态，每个流是一状态机
下面这些是区别与现有网络管理系统的关键因素：
1. 在线计算
在线计算才能真正精确的实时响应，控制能力比基于统计的响应要强大。
一般的IDS因为是passby旁路监听方式运行，控制能力比较有限(主要是利用TCP会话终结与ICMP不可达)，因此一种思路是和防火墙等pass-through设备联动来增强控制能力，这就需要使用防火墙等设备的专有协议(F5流量控制器提供I-Control接口，思路也和这个类似)。
2. 采样技术
当前骨干网数据流量的巨大，包采样技术应用比较重要，如sFlow就是基于包采样原理，因此才能对设备的影响降到最低，在NetFlow中也引入包采样，实际系统中经常采样1:100或1:500等。
但问题是采样的包流量能够准确反应全流量的特性吗？这方面的研究还比较多，结果表明对于大多数流量分析而言，采样是能够真实反应全流量的特性，这是有统计理论支持的，并且给出了各种采样方式和采样比例的误差分析，以及实践认可的采样方法[7]。
3. 应用层识别
当前已有的各类工具的弱点就是没有适应当今IP环境中应用的复杂性，占主导地位的流量往往是非固定端口号，甚至采样常用端口号如80等。这就需要对网络流量进行应用层识别，例如DPI(深度包检测技术)等。
4. 状态机制
一般网管工具的flow技术大多是采用设备提供的静态flow(到网管工具处只是一个结果，不具备状态)。flow还具有动态属性，是一种内存数据结构，作为一种状态机使用－实时、动态flow。状态机制蕴涵巨大的潜力和机会！尤其实时处理的时候，可以主动被动同时突破，收到某种包－>发相关探测包－>收到结果－>更新状态……
在Cisco设备的内部运行中，NetFlow组件会建立一个NetFlow Cache(缺省尺寸是4MB，64K条 * 64Bytes/CacheEntry，show ip cache flow命令可查看这个Cache的大小)，路由设备每秒钟检查一次缓冲区，下列情况下替换一些Cache Entry[29]：
1) 会话结束(TCP FIN 或者TCP RST)
2) Cache满
3) 一条flow变成非活动状态，(缺省15秒钟)一定时间内没有变化的流
4) 一条活动flow持续长时间(缺省30分钟)
n Cisco：The value of information in the cache was a secondary discovery Initially designed as a switching path???!! 直接就是交换路由的内部数据结构[16]。
n now Works with Cisco Express Forwarding (CEF) or fast switching Not a switching path，netflow Answers questions regarding IP traffic: who, what, where, when, and how
n 防火墙中状态监测作用要明显一些，也可借鉴。
5. 平台支持
更灵活的系统架构，应用可扩展性，系统可伸缩性，快速满足用户需求变化。
2.3 NetFlow
1. 基本概念
Netflow提供网络流量的会话级视图，记录下每个TCP事务的信息。也许它不能象tcpdump那样提供网络流量的完整记录，但是当汇集起来是，它更加易于管理和易读。回答关于网络流量的 who, what, where, when, and how！
• NetFlow中的Flow是由7个关键字段标识单方向的连接
– [IPsrc, IPdst, srcPort, dstPort, protocol, TOS, Ifindex]
• 每当路由器端口上收到一个数据包，都会扫描这7个字段来判断此数据包是否属于一个已经存在的flow
– 是>相应的flow纪录内的数据包数，整个flow过程的字节大小就会相应增加；
– 否>一条新的描述这个session的flow在cache中生成；
• 在新的flow不断生成的同时,cache内过期的flow记录以UDP方式导出
• NetFlow还有个作用就在设备内部根据NetFlow流做交换（路由）处理
– 流生命周期中的状态机制（状态不断更新）
– 网管软件一般无法得到这些实时状态信息，只得到静态的flows封装输出；
Sampled Netflow
• 采样
– NetFlow对设备的资料消耗比较大，如果全流量采集会影响正常功能，因此设备中生成流的过程中应用包采样，按照1:n生成Flow；//向sFlow学习的？
• 采样模式：
– Deterministic sampling: select every Nth packets, with N specified by the user.
– Random sampling: randomly select one out of N packets with N specified by the user.
– Time based sampling: select a sampled packet every N milliseconds.
随机采样被认为是最佳的包采样方式。(误差最小、与真实情况最吻合，有统计理论依据[7])。
2. NetFlow版本
flow技术版本，V1、V5、V7、V8、V9以及相关的cflowd、SFLOW、NetStream如下表：
版本 描述
V1 相对原始，实际上已经基本抛弃不用
V5 最基本、最常用的版本。
V7 Cisco Catalyst 6500 and 7600 Series Switches
缺乏AS、interface、TCP Flag 、TOS information
V8 为聚合输出格式，不适用于数据挖掘 Reduces resource usage
V9 基于模板的；长期来看NetFlow会转向V9格式。IETF Packet Sampling 工作组和IP Information Export工作组相关标准的基础。RFC 3954 IPFIX
Cflowd juniper路由器的格式，从个人经验来看，和V5一致，现在已改作jflow。
Sflow Rfc3176 2到7层，性能好，cpu,内存等资源占用少，协议支持更广泛。
Foundry、hp、Inmon等支持
NetStream 华为公司的技术，据说内容和CISCO的V5一致
3. NetFlow V5格式
一系列的流记录可合并成一个流量包，这个流量包是可被发送到远程收集器的IP数据包。切记，现在互联网传输的一个流的平均长度约为11个数据包，因此高速中继线可生成大量的流记录和流量包！ 目前普遍使用的输出报文格式有两种－第5版和第8版的流记录。第5版为每个流生成的单一记录里都包含了源和目的IP地址，因此是大家最感兴趣的方法。
图2-1 NetFlow第5版输出报文格式
NetFlow输出报文中包含许多有价值的流量统计数据，这些流信息充分揭示了有关网络使用的“4W”问题：
Who：哪一个用户（IP）使用了网络？
What：网络流量的类型是什么？
When：在什么时间使用网络，使用了多长时间？
Where：网络流量流向何处？
利用NetFlow数据分析器对这些数据进行统计分析，就能从中提取出网络流量特征，从而为网络管理员提供一张丰富而详尽的网络利用视图。
图2-2 每条Flow记录提供的信息(V5)
4. NetFlow网络监测系统的基本架构
用FLOW技术构建一个流量监测分析系统，从功能上分，需要几个关键部件，如下：
[1] 是flow exporter,即能够吐出flow record的设备或者吐出flow信息的源，最基本的是Cisco路由器。或者是通过采packet生成流的probe(也叫路由器仿真器)，例如NetFlow exporter。
[2] 是flow collector，即能够接受这些吐出来的flow record信息(例如netflow-tool)，压缩归档保存为流文件。
[3] 是flow analysis,即能够分析这些数据源，得出相关的重要信息，例如netflow-scan，并保存(如flow-scan输出分析结果到RRD数据库)。
[4] 是reporter(web portal),即能够对分析后的数据，进行图表展示，例如rrd-tool。
图2.3 NetFlow网络监测框架
5. NetFlow性能问题
详细信息可见参考资料[2][4]，这里摘录部分：
• 性能
– CPU
• With ~10,000 active flows: 7.14 percentage points of additional CPU utilization
• With ~45,000 active flows: 19.16 percentage points of additional CPU utilization
• With ~65,000 active flows: 22.98 percentage points of additional CPU utilization
– 带宽
• NetFlow is very efficient, the amount of export data being about 1.5% of the switched traffic in the router
Netflow 性能实例
• CISCO 实测
– 某省骨干端口GE 口GSR12416
– CPU前后没有变化2%
– 平均入流量在650M， 采样率为500的时候
– 15分钟平均flow条数为110000万条
– 每秒122条flow
– 122*1.4k=171k/sec
– 预期： 650M的百分之一6.5兆＝6500K
• Juniper 实测
– 某省骨干端口GE JUNIPER M160
– CPU前后没有变化3.76%
– 平均入出流量在380M， 采样率为100的时候
– 15分钟平均flow条数为700000万条
– 每秒778条flow
– 778*1.3k=1011k/sec
– 预期： 380M的百分之一3.8兆＝3800K
6. NetFlow方向问题
一般情况下，一次网络通信是双向的，有发起方和应答方。但是由于NetFlow仅统计通过某个接口进入设备的数据，所以说它是单向的通信流。
cisco高版本的ios开始在部分板卡上支持出方向的netflow了。记得是12.0-24以后的ios才支持，同时要求硬件是gsr的pos和ge板卡.
2.4 sFlow
网络设备必须做到能够在不影响网络性能的前提下对网络流量进行计量，而这一点正是困扰现有网络设备厂商的一个难题。新IETF草案标准RFC 3176利用网络数据包采样技术，突破了所有这些制约传统传输流监测和网络分析的限制。行业组织sflow.org还用“sFlow”的名称来推广这项RFC。RFC 3176使管理人员可以可靠地、以统计学方法测量所有联网的应用、用户、服务器、路由器以及存储交换机对网络性能和流量的影响。
SFlow可以统计到VLAN信息，对bgp支持的比较好，源目的地as，as路径等，这一点NetFlow或者做不到或者做的不标准（要看实现它的那些公司是怎么做的了）。NetFlow要消耗设备宝贵的处理器和存储资源；SFlow理论上没有这个问题，sflow宣称使用简单的流程采样数据，不像netflow有缓存那么复杂，可以做到非常高的速率。//电信运营商核心路由器现在一般使用高采样比率NetFlow，1:100，1:500，性能问题也不大。
与RMON等数据包采样技术不同，sFlow是一种导出格式，它增加了关于被监视数据包的更多信息，并使用嵌入到网络设备中的sFlow代理转发被采样数据包。sFlow代理只是简单地选择、封装和转发数据包，以保证对网络设备的处理和CPU的要求最小化，并不是每一个数据包都发送到采集器, 这些叫做sFlow数据报的样本被转发给网络上的一台sFlow采集服务器。在这台服务器上，样本数据报利用一种算法进行处理，算法根据采样的数据建立网络传输流的完整模型。
图2.4 sFlow Datagram
sFlow使用两种独立的采样方法来获取数据：针对交换数据流的基于数据包的统计采样方法和基于时间的针对网络接口统计数据（类似RMON的轮询）采样sFlow还能使用不同的采样率对整个交换机或仅对其中一些端口实施监视，这就保证了在设计管理方案时的灵活性。
总的来说sFlow并没有取得预期的市场。但它提供一种与NetFlow不同的思路(个人认为技术并不比NetFlow优秀)，在某些特定领域有自己的优势，在技术上也比较开放，有一些借鉴的价值。
sFlow Datagram 格式
*Interface statistics samples
*Flow sample
-Packet header (MAC,IP,IPX,HTTP,FTP,DNS…)
-Sample process parameters (rate, pool etc.)
-Switch
.Input/output ports
.Priority
.VLAN
-Router
.Source/destination prefix
.Next hop address
-Gateway
.Source AS, Source Peer AS
.Destination AS Path
.Communities, local preference
-User
.User IDs (RADIUS等) for source/dest
-URL
.URL associated with source/destination
-NAT
.Network address translation mapping
-MPLS
.Label stack information
-Vendor Specific • Raw data export
– Decode at collector
• Rich detail
– Traffic
– Forwarding
– I/F counters
• Extensible (sFlow v5)
– Vendor-specific records
阅读(11684) | 评论(0) | 转发(0) |
