• 文章搜索:
  • 灵犀一指

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    H3C S12500-X SFlow采集流量翻倍问题追根溯源

    作者:  |  上传时间:2014-11-26  |  关键字:H3C S12500-X SFlow采集流量翻倍问题追根溯源

    一、 问题描述:

    客户采用SNMP网管和自己研发的SFlow软件分别对S12500-X的端口流量进行监控,结果发现SFlow监控到的流量不准确,从监控图上看到SNMP监控到的流量和端口实际流量是匹配的,但是SFlow监控到的流量与实际流量不符,显示为实际流量的两倍。而同网当中采用同样的SFlow软件采集S12500的设备流量则是准确的,因此怀疑S12500-X与SFlow软件配合有问题。

    二、 过程分析:

    客户在S12500-X上所有的端口都配置了SFlow的两种功能,一种是sampling-rate,一种是counter。根据协议的定义,sampling-rate是用来跟踪流量细节,counter用来监控端口的流速,也即是SNMP获取的端口速率一致。但是客户自己开发的软件,计算端口流速时,不是根据标准的counter而是根据sampling-rate自己软件模拟计算的,并非按照counter来统计实现。

    其端口配置如下:

    interface Ten-GigabitEthernet0/0/23

    port link-mode route

    flow-interval 30

    ip address 10.1.1.1 255.255.255.252

    sflow flow collector 1

    sflow sampling-rate 30000

    sflow counter collector 1

    sflow counter interval 30

    interface Ten-GigabitEthernet0/0/47

    port link-mode route

    flow-interval 30

    ip address 20.1.1.1 255.255.255.252

    sflow flow collector 1

    sflow sampling-rate 30000

    sflow counter collector 1

    sflow counter interval 30

    流量计算过程简单的描述如下:

    如上示意图,S12500-X上,报文从23端口入,47端口出来。客户在这两个端口都配置了sampling-rate。由于SFlow是双向统计,因此S12500-X在23端口入的时候发送一份SFlow报文给服务器,47端口出的时候也发送一份给服务器。

    SFlow报文部分关键字段截图如下:

    在入端口23的SFlow统计的报文是:

    source id index 23表示该SFlow报文统计的是23端口的报文,

    input interface value 23表示这个报文从23端口进入交换机,由于这个是入端口的报文,还没找到出端口,所以output interface value 为0.

    在出端口47上,发送给服务器的SFlow关键字段截图如下:

    source id index 47表示该SFlow报文统计的是47端口的报文,

    input interface value 23表示这个报文从23端口进入交换机,

    output interface value 为47.表示这个是47端口出方向的报文。

    按照正常的实现逻辑,SFlow采样哪个端口,应该按照source id index 47 来计算。但是客户的软件是根据input interface value 来计算。这样就出问题:一个报文从23进入,由于有input interface value =23的数值,这样被服务器计算一次,而在47端口出时,由于有input interface value =23信息,又被统计一次,所以一个报文被统计两次,这样统计出来的流量就多一倍了。

    接着解释现场为何12500没有问题?

    根据12500的抓报文,我们发现由于12500的芯片在出方向,没有带上入端口信息,其SFlow报文的关键字段如下图所示:

    可以看到出方向的input interface value为0,这样客户的软件就无法统计上,也就是恰好不能重复统计了。

    所以问题的本质上是S12500-X在出端口能带入报文的端口信息,而客户的软件没有区分端口的出入方向就出现双重统计。S12500由于芯片在出方向不能带入端口信息而恰好没有问题。

    根据协议的要求,定义了报文的input interface value 字段,就要求能携带该信息,而且在电信运营商的骨干网络上,往往只在上行链路上配置SFlow,S12500-X能逆向查源端口的能力就能满足客户的监控要求。

    实际上SFlow软件的计算方法不妥,应该根据source id index 来确定报文的源端口,再根据input interface value或者output interface vlan来确认报文的出入方向,就能准确地计算出报文在端口的出入情况。

    三、 解决方法:

    根据分析结果,针对此类问题解决方法有两个:

    1、 修改SFlow软件的计算方法,按照标准来统计流量信息。

    2、 S12500-X设备适应SFlow软件的计算方法,在出端口不再携带源端口的信息。