演示:使用NBAR统计与分析流量

演示:使用NBAR统计与分析流量


   NBARNetwork-Based Application Recognition,基于网络的应用识别)的作用主要是对动态分配TCP/UDP端口号的应用程序和HTTP流量等进行分类,在分类的同时,还可以对该分类数据流量进行统计。NBAR对网络数据的匹配之一就是通过自身的一个匹配协议列表,如图6.19所示,它对网络所使用的大多数协议都能进行识别。如果NBAR匹配协议列表中不能对新的协议进行匹配分类,此时Cisco提出了PDLM(数据包描述语言模块)和自定义的匹配方式。因为NBAR还可以报告包括输入/输出数据包总数和字节数,以及输入/输出比特率等在内的流量统计信息,所以当网络发生拥塞时,NBAR是常见的流量分类统计分析工具。

012359753.jpg

  数据包描述语言模块(PDLM)从路由器的闪存(Flash)中加载,用于不是最新的Cisco IOS软件。实际上就是升级NBAR的协议识别能力,以便对新的协议或应用程序进行识别。所谓新协议,实际上就是原Cisco路由器的NBAR匹配协议列表中,还没有被完成定义的协议。使用新的PDLM可以很大程度地提高NBAR的识别能力,加载新的PDLM配置指令如下所示。


加载一个名叫“citrix.pdlm”的模块到路由器闪存中。

Router(config)#ip nbar pdlm pdlm-name

其中,pdlm-name必须使用URL名称形式。PDLM文件可以被存放到路由器的Flash中,也可以被存放到TFTP服务器上。配置实例如下所示:


Router(config)#ip nbar pdlm flash://citrix.pdlm

上述代码表示路由器使用缓存中的PDLM文件。


Router(config)#ip nbar pdlm tftp://192.168.2.100/citrix.pdlm

上述代码表示路由器使用TFTP服务器192.168.2.100上存放的PDLM文件。

自定义的匹配协议方式特别适合于那些不是众所周知的端口或对众所周知的端口做了修改,比如,企业有一个运行在UDP端口号300上的自定义协议服务,或者企业将HTTP众所周知的端口80改为了8080。此时NBAR将无法识别这两个协议,可以通过自定义的匹配协议方式来完成修改,让NBAR重新识别该协议。


router(config)#ip nbar custom myservice udp 300

上述代码表示将企业运行在UDP端口号300上的自定义协议编入PDLM文件中。


router(config)#ip nbarport-map http tcp 8080

上述代码表示企业将HTTP众所周知的端口80改为了8080


演示:利用NBAR统计和分析流量


演示目标:

nCisco路由器上NBAR协议发现的基本配置。

n识别网络流量,对各类网络协议分类。

n统计网络数据包每秒发送的速度及对分类流量的统计。

n如果遇到不能匹配协议列表,路由器默认的处理方式。

n“新协议”的分类和流量统计。

演示环境:如图6.20所示。

012807876.jpg


演示步骤:

第一步:为统计环境做基础配置,包括为每台路由器写入IP地址、启动RIP路由协议,保证192.168.1.2可以访问192.168.3.100。路由器R1与路由器R2RIP V2配置如下:

r1(config)# router rip

r1(config-router)# version 2

r1(config-router)# network 192.168.1.0

r1(config-router)# network 192.168.2.0

r1(config-router)# no auto-summary


r2(config)# router rip

r2(config-router)# version 2

r2(config-router)# network 192.168.2.0

r2(config-router)# network 192.168.3.0

r2(config-router)# no auto-summary

完成上述配置后,如果没有配置错误,192.168.1.2应该能够和192.168.3.100通信。在192.168.1.2上的测试如图6.21所示。

013012959.jpg

第二步:Cisco的路由器上启动NBAR配置,如果要启动NBAR配置,必须先启动路由器的cef功能。配置指令如下所示


r2(config)#ip cef  在路由器R2上启动cef功能。

r2(config)#interface ethernet 1/1

r2(config-if)#ip nbar protocol-discovery

在路由器R2E1/1接口下打开NBAR协议发现功能与统计功能。


注意:使用NBAR的发现与统计功能时,建议将ip nbarprotocol-discovery配置在流量较为集中的路由器上。例如,企业级网络一般将该功能用到企业级网络的边界路由器上。在该演示环境中,将其用到路由器R2上,建议让NBAR做更长时间的统计,然后再查看统计结果。


     第三步:在主机192.168.1.2上发起如下会话,完成统计流量的模拟。

n192.168.1.2的主机上发起对192.168.3.100Web访问。

n192.168.1.2的主机上ping 192.168.3.100 �Ct �Cl 500,提示192.168.1.2连续的ping     192.168.3.100,并携带500个包的大小。

n192.168.1.2的主机上访问192.168.3.100FTP服务器。

n192.168.1.2的主机上访问192.168.3.100的共享文件夹“NBAR”。


第四步:让第三步中的流量持续几分钟后,在路由器R2上使用show ipnbar protocol-discovery命令查看NBAR统计协议和流量分布,NBAR统计流量报表界面如图6.22所示。


013323177.jpg

其参数含义如下。

nProtocol”:NBAR实时发现的具体协议,如图6.22所示的协议是HTTP

nInput”:指流入路由器R2接口E1/1的流量,包含具体参数如下。

lPacket Count”:统计该接口接收数据包的数量,例如,Packet Count对应113

lByte Count”:统计该接口接收数据包的大小,例如,Byte Count对应23354

l5min Bit Rateb/s)”;统计该接口以5分钟作为一个时间间隔单位,表示数据接收速度,如5min Bit Rateb/s)对应0

l5min Max Bit Rateb/s)”:统计该接口以5分钟作为一个时间间隔单位,表示数据最大接收速度,如5min Max Bit Rateb/s)对应6000

nOutput:指流出路由器R2接口E1/1的流量,包含具体参数如下。

lPacket Count”:统计该接口发送数据包的数量,例如,Packet Count对应58

lByte Count”:统计该接口发送数据包的大小,例如,Byte Count对应14152

l5min Bit Rateb/s)”:统计该接口以5分钟作为一个时间间隔单位,表示数据发送速度,如5min Bit Rateb/s)对应0

l5min Max Bit Rateb/s)”:统计该接口以5分钟作为一个时间间隔单位,表示数据最大发送速度,例如5min MaxBit Rateb/s)对应4000


如图6.23所示,NBAR清晰地统计了网络协议的使用情况,其协议包

FTPICMPRIPNETBIOSHTTPNBAR将流量统计进行了排位,排位靠前表示基于该协议的网络流量越大。其中,FTP的流量最大,其次是ICMP。并且还在分类协议的后面部分,分别对流量的情况进行了相应的统计,包括数据包的个数、数据包的大小、数据包5分钟的速度及最大速度。


013519709.jpg

注意:在企业级网络的应用流量相当庞大而且相当复杂的情况下,建议利用NBAR执行流量统计的维持时间更长一些,只有这样才能看出企业网络在一个持续的时间周期的变化与规律。


第五步:NBAR对未知流量的统计及对整个网络流量的统计。NBAR拥有强大的协议识别能力,但是这并不表示NBAR能执行所有网络协议的统计与识别,在如图6.24所示的内容中,就有“unknown(未知)”的流量没有被NBAR所识别。

013621834.jpg

针对这种情况有两种方案可以进行解决。第一种方案是通过为路由器加载最新的数据包描述语言模块(PDLM)来扩展NBAR的协议识别能力。对于如何加载语言模块(PDLM)前面已讲述,这里不再多述。第二种方案是网络管理员手工添加映射记录,比如,在192.168.3.100的服务器上主持NetMeeting会议,并在主机192.168.1.2上呼叫192.168.3.100,建立NetMeeting会议状态。可以发现路由器R2上利用NBAR协议发现功能并没有发现NetMeeting的流量,如图6.25所示。对于这种情况,首先应确定NetMeeting的端口。


013735509.jpg


NetMeeting常使用到的端口是基于TCP389522150317201731。端口389用于LDAP 服务器支持分布式文件系统,端口522用于用户定位服务器(User Location Service ),端口1503T.120 标准由一组通信和应用程序协议组成。T.120 协议被设计来用于多点数据会议和实时通信,包括多层协议,该协议很大程度上提高了多媒体和多媒体数字信号编解码器的控制能力。端口1720用于H.323协议,它是ITU-TIP网络上传输音频、视频和数据的规范,当符合H.323标准时,各个厂商的产品可以兼容。它主要针对呼叫信令和控制,多媒体传输和控制,以及点对点或点对多的流量流控。端口1731用于语音呼叫控制。


在这些端口中,NBAR能识别LDAP389端口和H.3231720端口,而其他端口都没有被NBAR识别。最终由自定义匹配协议列表来对NetMeeting的流量进行统计和分类,指令如下:


r2(config)#ip nbar custom NetMeeting tcp  522 1503 1731

指令分析:ip nbarcustomNetMeeting 是自定义一个NBAR可识别的一个协议,该协议的名称叫做“NetMeeting”tcp522 1503 1731是将NetMeeting所使用的端口号映射到该协议。由于NBAR能识别LDAP389端口,所以H.3231720端口在定义该协议时没有输入这两个端口号。

当完成自定义NetMeeting后,可以通过指令show ip nbar port-map ?查看nbar的发现能力,是否加入了对NetMeeting的发现功能,其中“?”表示列出所有nbar可以统计与分析的流量及协议类型,如图6.26所示为NBAR协议发现能力。可看出在输出的显示中已经出现自定义的NetMeeting

013905521.jpg

   此时再使用show ipnbar protocol-discovery指令可查看NBAR现在的统计结果,如图6.27所示,成功地统计了NetMeeting的流量。

014003941.jpg


本文出自 “无名的基督” 博客,谢绝转载!

你可能感兴趣的:(qos,流量统计,NBAR)