交换机涉及丢包问题进行流量统计

交换机涉及丢包问题 进行流量统计 配置参考

解决方案

关键配置如下:

#
acl number 3000
rule 0 permit icmp source 192.168.1.2 0 destination192.168.1.3 0  
rule 1 permit icmp source 192.168.1.3 0 destination 192.168.1.2 0    //需要统计的流量,源做目的,目的做源.需要正反写两条rule条目
#
traffic classifier 3000 operator and
if-match acl 3000
#
traffic behavior 3000
permit
statistic enable

// 在流行为中 开启流量统计功能 statistic enable
#
traffic policy 3000
classifier 3000 behavior 3000
#
interface gigabitEthernet0/0/1

// 在流量的进入交换机的接口和出交换机的接口上都要双方向调用流策略
traffic-policy 3000 inbound
traffic-policy 3000 outbound
#
interface gigabitEthernet0/0/2

//在流量的进入交换机的接口和出交换机的接口上都要双方向调用流策略
traffic-policy 3000 inbound
traffic-policy 3000 outbound
#

PC1>ping 192.168.1.3    // PC1 ping PC2测试流量统计效果

Ping 192.168.1.3: 32 data bytes, Press Ctrl_C to break
From 192.168.1.3: bytes=32 seq=1 ttl=128 time=31 ms
From 192.168.1.3: bytes=32 seq=2 ttl=128 time=15 ms
From 192.168.1.3: bytes=32 seq=3 ttl=128 time=15 ms
From 192.168.1.3: bytes=32 seq=4 ttl=128 time<1 ms
From 192.168.1.3: bytes=32 seq=5 ttl=128 time=31 ms

--- 192.168.1.3 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 0/18/31 ms

[SW1]display traffic policy statistics interface GigabitEthernet 0/0/1 inbound

Interface: GigabitEthernet0/0/1
Traffic policy inbound: 3000
Rule number: 2
Current status: OK!
---------------------------------------------------------------------
Board : 0
Item                             Packets                      Bytes
---------------------------------------------------------------------
Matched                               10                        740
  +--Passed                           10                        740
 +--Dropped                           0                          0
   +--Filter                          0                          0
    +--URPF                            -                          -
   +--CAR                             0                          0
[SW1]display traffic policy statistics interface GigabitEthernet 0/0/1 outbound

Interface: GigabitEthernet0/0/1
Traffic policy outbound: 3000
Rule number: 2
Current status: OK!
---------------------------------------------------------------------
Board : 0
Item                             Packets                      Bytes
---------------------------------------------------------------------
Matched                               10                        740
  +--Passed                           10                        740
 +--Dropped                           0                          0
   +--Filter                          0                          0
   +--URPF                            -                          -
   +--CAR                             0                          0
[SW1]display traffic policy statistics interface GigabitEthernet 0/0/2 inbound

Interface: GigabitEthernet0/0/2
Traffic policy inbound: 3000
Rule number: 2
Current status: OK!
---------------------------------------------------------------------
Board : 0
Item                             Packets                      Bytes
---------------------------------------------------------------------
Matched                               10                        740
  +--Passed                           10                        740
  +--Dropped                           0                          0
   +--Filter                          0                          0
   +--URPF                            -                          -
   +--CAR                             0                          0
[SW1]display traffic policy statistics interface GigabitEthernet 0/0/2 outbound

Interface: GigabitEthernet0/0/2
Traffic policy outbound: 3000
Rule number: 2
Current status: OK!
---------------------------------------------------------------------
Board : 0
Item                             Packets                      Bytes
---------------------------------------------------------------------
Matched                               10                        740
  +--Passed                           10                        740
 +--Dropped                           0                          0
   +--Filter                          0                          0
   +--URPF                            -                          -
   +--CAR                             0                          0

入接口GigabitEthernet 0/0/1 inbound 方向通过的数据包个数 等于出接口GigabitEthernet 0/0/2 outbound方向通过的数据包个数,表明ping的请求包交换机没有丢包

入接口GigabitEthernet 0/0/1 outbound 方向通过的数据包个数 等于出接口GigabitEthernet 0/0/2 inbound方向通过的数据包个数,表明ping的回包交换机没有丢包

清空接口统计计数:

reset traffic policy statistics interface GigabitEthernet 0/0/2 outbound

时间: 2024-10-10 05:53:50

交换机涉及丢包问题进行流量统计的相关文章

交换机端口丢包问题

H3C S5500 是核心,与邻栋建筑的S3100链接.用户反映3100下的客户端网络不稳定. 链接方式  (5500)网线(百兆光电转换)光纤到邻栋(百兆光电转换)网线(3100) 首先ping ,偶尔丢包 3%-5%,偶尔又好了..奇怪 然后查看3100和5500所在端口配置都正常 查看端口input和output 都没有errors 但是端口利用率比较高 Last 300 seconds input:  5910 packets/sec 6288557 bytes/sec 51% 然后查看

一次由于网卡流量跑满引起的服务器丢包总结

最近收到线上一台DB服务器ping丢包,丢包率一直在30%左右.通过Zabbix监控查看了服务器CPU,内存都很正常,网卡流量也不高,基本在100M左右. 首先确认一下服务器硬件是否正常,由于没有收到硬件报警.登录服务器通过HP管理工具在此确认了硬件信息都正常(硬盘,缓存卡,内存等).  第二步在排查一下系统问题,通过top,ps等命令也没有发现什么异常,基本上排除系统问题.  第三步查看了一下该服务器上联监控机端口流量,也都很正常,由于收到只有这一台服务器报警,也排除了上联交换机故障问题. 

万兆光模流量大于4G后有drop丢包现象

故障现象: 一批设备使用的是万兆光模块,当单台流量达到4G以上时量就会上不去且有dorp丢包现象. 同一批设备相同业务,量在4G以下的一切正常 设备故障信息如下: 处理过程: 1.  调整buffer_size缓冲大小(未解决该问题) 注:ethtool -G是暂时生效的,永久生效的话需要将ethtool设置写入/etc/rc.d/rc.local之中 2.  联系厂家更新驱动(未解决该问题) 3.  设置中断绑定在不同的cpu核心上(解决了该问题) 设置之前:cat /proc/interru

网络抓包,协议分析,流量统计程序

// YQPackageCaptureDlg.cpp : 实现文件 // #include "stdafx.h" #include "YQPackageCapture.h" #include "YQPackageCaptureDlg.h" #include "afxdialogex.h" #include <pcap.h> #include <vector> #include <afxwin.h&

openStack 云平台管理节点管理网口流量非常大 出现丢包严重 终端总是时常中断问题调试及当前测试较有效方案

tuning for Data Transfer hosts connected at speeds of 1Gbps or higher <一.本次OpenStack系统调试简单过程简单记录> 1,dmesg 日志,丢包问题关键原因定位; [101231.909932] net_ratelimit: 85 callbacks suppressed 2,ethstatus -i p5p1 实时追踪网口TX/RX状态; 3,具体内核等相关参数调整 # recommended default co

ping丢包故障处理方法

1. Ping丢包故障定位思路故障分析Ping丢包是指Ping报文在网络中传输,由于各种原因(如线路过长.网络拥塞等)而产生部分Ping报文丢弃的现象.在使用Ping命令,出现Ping丢包的现象时,第一步需要确定Ping丢包的网络位置,其次是确定Ping丢包的故障原因,然后依据定位的故障原因再进行解决.确认Ping丢包的网络位置时一般采用逐段Ping的方法,可以将Ping丢包故障最终确定在直连网段之间. 确认Ping丢包的故障原因一般采用流量统计的方法,通过流量统计可以知道丢弃报文的具体位置.判

IP通信中音频编解码技术与抗丢包技术概要

此文较长,建议收藏起来看. 一.一个典型的IP通信模型 二.Server2Server技术分类 Server2Server这块也是一个专门的领域,这里只简单分个类. 1.同一国家相同运营商之间: 同一运营商之间也有丢包,在铁通,鹏博士等运营商中尤甚.并且在晚高峰的时候表现更加突出. 2.同一国家不同运营商之间: 在很多时候,由于运营商之间的结算和有限带宽的问题.运营商之间的网络不稳定. 3.不同国家之间: 同一个国家都这么多问题,不同国家的问题回更复杂,在不同的国家要选择好的机房,实时选择实时监

华为9312 ping本地互联丢包 tcpping不丢包,但转发正常

1.华为9312 设备cpu正常 .但是从这台交换机ping其它互联设备丢包 从其它设备ping进来也有丢包 ,但二层经过这台交换机的业务不影响流量正常, 2.检查设备cpu正常 ,log无异常, 3.os的版本比较老, 解决方法,关闭华为设备默认的icmp限制 und icmp rate-limit enable

Google&#39;s BBR拥塞控制算法如何对抗丢包

我不知道该怎么说.总之,便舍船,从口入,我看不到黄发垂髫并怡然自乐!我不会说什么,除了咒骂!        在BBR之前,存在着两种拥塞控制算法,基于丢包的和基于时延的,不管哪一种都是基于探测的,换句话说,基于丢包的算法将丢包作为一种发现拥塞的手段,而基于时延的算法则是将时延增加作为发现拥塞的手段,它们之所以错误是因为它们的初衷就是错的: 丢包算法: 为了发现拥塞就不得不制造拥塞,这TMD的太JIBA讽刺了,为了戒毒,就必须先TMD的染上毒瘾!然而根本没毒瘾的话何谈戒毒!TCP之所以这么玩我觉得