1、交换机网络同传慢怎么处理
一、交换机因素确认
1）、关闭广播、组播、单播风暴尝试
Ruijie(config)#int rang f0/1 - 24
Ruijie(config-if-range)#no storm-control
broadcast
Ruijie(config-if-range)#no storm-control
multicast
Ruijie(config-if-range)#no storm-control
unicast
Ruijie(config-if-range)#end
2）、查看端口双工速率是否一致
Ruijie#show interfaces status
Interface
Status Vlan Duplex Speed Type
------------------------ -------- ---- ------- --------- ------
FastEthernet 0/1
up
full 100 copper
----->双工需要是full的，速率需要保证服务器与pc都是1000M或者100M。
3）、开启，或者关闭流控尝试
Ruijie(config)#int rang f0/1 - 24
Ruijie(config-if-range)#flowcontrol
on
------>开启流控
或者Ruijie(config-if-range)#flowcontrol
off
------->关闭流控
Ruijie(config-if-range)#end
4）、如果是S29G/S3760/S5760系列交换机，可以尝试改为qos模式、关闭流控，并且保存配置重启尝试
Ruijie(config)#int rang g0/1 - 24
Ruijie(config-if-range)#no flowcontrol
Command failed on interface
GigabitEthernet 0/24
Ruijie(config-if-range)#exit
Ruijie(config)#buffer management qos
Ruijie(config)#end
Ruijie#wr
Ruijie#reload
Proceed with reload? [no]y
5）如果网克采用的是组播流方式的话，尝试开启IGMP SNOOPING功能
ip igmp snooping ivgl
ip igmp snooping fast-leave enable
6）S1824GT交换机，需要确认该交换的硬件版本需为2.*以上版本
二、环境因素确认
1）参加网克的主机必须都为千兆网卡（记录网克的型号，核对网克是否有正确的驱动支持），若有部分主机为百兆网卡，会拖慢整体网克速度；
2）没有参加网克的主机不能具有网卡远程唤醒功能，即关机的状态下网卡不能linkup，否则也会拖慢整体的网克速度，不能关闭远程唤醒功能的PC，直接拔掉网线；
三、实验确认
1、PC与服务器直接对连，记录网克速度；
2、将PC与网克服务器接在同一台S18上，测试网克速度，不网克的PC必须拔掉线。
3、将PC与网克服务器接在同一台S27上，测试网克速度，不网克的PC、交换机必须拔掉线，开关流控测试下。
确认上述两个网克速度是否正常，与PC与服务器直接对连的网克速度进行对比，以便确认是交换机设备还是网克工具问题。
2、主流的几款S18系列的交换机网克与无盘启动的推荐模式
说明：由于每个实验室或者网吧的组网方式存在差异，应用的软件也是各式各样，所以上述情况仅是大部分市场使用，测试的经验值，难免存在应用软件与我司交换机兼容性方面的问题，所以如果推荐方式无法解决问题的话，可以尝试其他模式。
3、交换机入口很多no buffer丢包
1）尝试开启本机和对端设备的流控（接口下配置flow-control on）
2）如果是S2924G/S2927XG/S2951XG/S3760/S5760交换机，可尝试将buffer management fc（默认）调整成为qos（全局模式下敲buffer management
qos）
Qos模式和fc模式主要的区别是：qos模式给报文提供更多的缓冲能力，而fc（flowcontrol）模式在有拥塞的情况下，会像对端发pause帧，但由于对端并未开启或本期全局未开启都有可能导致丢包，可查看配置手册了解详细情况。
正常情况下，一般不会造成缓冲区溢出，突发流量较大或多端口向同一端口转发数据的时候（多打一模型）容易发生拥塞。
另外对S29和S5760系列交换机，堆叠情况下流控模式为QoS模式，单机情况和S3760一样，缺省为FC模式。
S29(config)#buffer management ?
fc Configure port
buffer management as flowcontrol mode
qos Configure port buffer
management as qos mode
注意：修改buffer管理方式后，需要保持配置，重启生效
4、S2924G千兆连接服务器，百兆连接pc，网络同传慢
这是因为芯片在处理端口拥塞时的机制造成的，属于硬件实现的限制，当多个端口同时以高速率向一个端口砸包时，会造成该端口拥塞，并且由于FC流控模式的头包阻塞(HOL)原理，造成其他原本没有拥塞的端口无法线速转发，造成29上所有的端口工作在低速下，此时需要更改缓存的管理方式，由FC方式更换为QOS方式就可以解决问题了。
ruijie(config)#buffer management qos
注意：修改buffer管理方式后，需要保持配置，重启生效
5、S21百兆端口是否支持风暴控制功能
1.66以上软件版本开始支持。
并且风暴控制功能默认是开启的，如果要关闭，参考命令
Switch(config)#int f0/2
Switch(config-if)#storm-control ?
broadcast
Broadcast address storm control
multicast
Multicast address storm control
pps
Set storm suppression pps on the interface
unicast
Unicast address storm control
Switch(config-if)#no storm-control
broadcast
Switch#show run
!
interface fastEthernet 0/2
no storm-control broadcast
!
interface fastEthernet 0/3
no storm-control broadcast
6、show interface的接口计数器说明
switch#show interfaces gigabitEthernet 2/1
Index(dec):1 (hex):1
GigabitEthernet 2/1 is UP , line protocol
is UP
Hardware is Broadcom 5464
GigabitEthernet
//phy 型号
Interface address is: no ip address
MTU 1500 bytes, BW 1000000 Kbit //MTU 带宽
Encapsulation protocol is Bridge, loopback
not set
Keepalive interval is 10 sec , //set 链路脉冲
Carrier delay is 2 sec
//载波延时，口链路的载波检测信号DCD 从Down 状态到Up 状态的时间延时
如果DCD
在延时之内发生变化，那么系统将忽略这种的状态的变化而不至于上层的数据链路层重新协商
RXload is 1 ,Txload is 1 //接口负载利用率1/255，每5
分钟统计
Queueing strategy: FIFO //这些都是给路由器用的，交换机不应该show
这些信息，目前在新版本10.4（2b2）中已经不显示了。
Output queue 0/0, 0 drops;
Input queue 0/75, 0 drops
Switchport attributes:
interface's description:""
medium-type is copper
lastchange time:5 Day: 7 Hour:47 Minute:40
Second //接口自系统启动后发生link
变化的相对时间，可以结合show ver 查看系统的启动时间，
判断端口上次发生up/down 的时间
Priority is 0
admin duplex mode is AUTO // 配置的双工为auto, oper
duplex is Full//实际的双工状态
admin speed is AUTO, oper speed is
1000M // 配置与实际的速率
flow control admin status is OFF,flow
control oper status is OFF //流控
broadcast Storm Control is OFF,multicast
Storm Control is OFF,unicast Storm
Control is OFF
5 minutes input rate 0 bits/sec, 0
packets/sec
// 5 分钟平均值
5 minutes output rate 20523 bits/sec, 9
packets/sec //5 分钟平均值
42388309 packets input, 2917143960 bytes, 0
no buffer, 0 dropped //重点关注no buffer 和droped
统计，no buffer 就是由于缓冲区不足
Received 76899 broadcasts, 0 runts, 1
giants
0 input errors, 0 CRC, 0 frame, 0 overrun,
0 abort
69858478 packets output, 6534138835 bytes, 0
underruns , 116 dropped
//重点关注droped 统计
0 output errors, 0 collisions, 0 interface
resets
input，output速率虽然是5分钟的平均值，但实际上是5秒钟更新一次，软件模块会5秒钟读取相关MIB并计算最近5分钟的数据然后进行更新。
7、接口output方向的dropped这个值可以表示任何原因导致的出口丢包统计，种类很多，总结包括如下
1）报文老化（因为出口HOL等原因，导致报文在出口队列中待太久没有被调度到）
2）VLAN出口检查错误，接口不属于要转发报文的vlan（极少见到）
3）还有一些属于应用策略丢弃的，比如需要用出口转换表，结果报文在该表中无法查找到导致报文被丢弃的（如PVLAN的一些应用），还例如STP的端口BLOCK。
4）报文超过MTU长度的，出口MTU检查超出了MTU限制。
5）所以仅从表面无法能够知晓Drop丢包的原因，通常情况下这种丢包也不会对网络正常使用造成影响，
6）从目前已有的故障案例中，排除例如端口阻塞的正常原因，基本都是环境因素导致的MMU资源不足。
8、show interface counters的端口计数器说明
Switch#show int fastEthernet 0/1 counters
Interface : Fa0/1
5 minute input rate : 0 bits/sec, 0 packets/sec //5 分钟的平均速率
5 minute output rate : 0 bits/sec, 0
packets/sec
InOctets : 68023600 进入的包总数
InUcastPkts : 92842 单播包
InMulticastPkts : 36700 组播包
InBroadcastPkts : 75636 广播包
OutOctets : 3630373 出去的总包数
OutUcastPkts : 32053 单播包
OutMulticastPkts : 1059 组播包
OutBroadcastPkts : 13231 广播包
[1] Undersize packets : 0
[2] Oversize packets : 0
[3] collisions : 0
[4] Fragments : 0
[5] Jabbers : 0
[6] CRC alignment errors : 0
[7] AlignmentErrors : 0
[8] FCSErrors : 0
[9] dropped packet events (due to lack of
resources): 0
[10] packets received of length (in
octets):
64:119136
65-127: 75769
128-255: 12663
256-511: 3149
512-1023: 1955
1024-1518: 38849
[1] 长度小于64字节，校验和正确的报文：和Fragment帧对应，区别在于校验和。
[2] 帧超长且校验和正确的报文：和Jabber帧对应，区别在于校验和。
[3] 冲突帧：多站点同时试图发送信息导致冲突，单双工遇到较多。
[4] 长度小于64字节，校验和错误的报文：和Undersize帧对应，区别在于校验和。
[5] 帧超长且校验和错误的报文：和Oversize帧对应，区别在于校验和。
[6] 非超常帧且校验和错误的报文：和FCS相同，CRC是发送方本地进行校验，对端收到后重新进行计算，然后比对FCS字段。
[7] 接收的帧有重组错误：没有通过帧校验且没有边界字节结束（非整字节）的帧，bit丢失。
[8] 帧的内容改变或者丢失：帧校验FCS错误
[9] 丢弃报文统计：总和
[10] 根据长度统计接收的报文
以上原因基本都是由于网卡、端口、线路故障或接触不良导致的。可以先进行链路、端口的替换测试。
9、端口丢包常见原因及信息收集
导致端口丢包的原因总结起来包括如下几种可能性：
1）由于某些接口、链路、双工异常导致的CRC错误、Algiment 帧bit丢失等常见错误，此类报文交换机将予以丢弃
----查看端口计数，是否由较多CRC、冲突帧等。
show interface，show interface counter
2）QOS限速、Rate-limit配置导致的数据包正常丢弃。（不计入端口统计计数）
3）端口BLOCK（STP、RLDP）导致的数据包正常丢弃。（计入端口统计计数）
----查看端口生成树状态。
show spanning-tree summary，show
spanning-tree interface
4）对端设备发送的速率过快导致本端交换机buffer 不足，而又没有流控导致的丢包--尝试两端打开流控，观察。
ruijie(config-if-FastEthernet
0/1)#flowcontrol on
5）多端口向一个端口发送报文，超出这个端口的转发能力，导致的HOL队头阻塞丢包
----尝试调整端口速率和打开流控，观察。
ruijie(config-if-FastEthernet
0/1)#flowcontrol on
6）针对S2900，S3760，S5760可以调整buffer的管理方式，注意需要重启生效
Ruijie(config)#buffer management ?
fc Configure port
buffer management as flowcontrol mode
qos Configure port buffer
management as qos mode
7）针对特殊TCP/UDP运用，最后需要通过在PC端抓包确认故障特点。
参考下面的信息收集方法：
其中最常见的4/5两种类型的溢出，通过查看端口的计数器，定位受影响的端口并打开两端的流控一般都能解决问题。从目前实际遇到的案例来看，也基本都是由于以上两种原因导致的丢包故障。如仍无法解决，请收集上层计数与底层计数信息提供后台分析判断。
注意：收集上下层信息的同时，注意收集信息的充分性，多次收集的上层信息必须有发现drop
计数的递增，这几次收集间隔中底层的信息都必须相应收集到。
上层信息：
show interface （多次获取）
show interface xx counter （多次获取，需要捕捉到drop的计数或其他异常计数的变化）
show interface status
show mac-address-table
底层信息：
sd
su 0 或su xx(对于机箱式产品)
console on
ps （底层查看端口的双工、速率、流控、是否打开自协商，需执行三次）
show
c （执行5次，每次间隔10s）
console off
dexit（退出底层界面）
10、二层转发丢包常见原因及信息收集
二层转发是基于VID+MAC的转发，所以不仅端口存在丢包会导致二层转发丢包，还包括其他较多复杂因素导致的丢包，总结起来有如下几种原因：
1）端口双工、速率、流控等导致的双工不匹配、缓存不足导致的丢包
----通过查看接口的工作状态，查看端口计数来确定是否存在端口丢包。
show int status，show inter，show int counter来确认是否存在half，no
buffer，CRC等统计值，并且持续增长。
2）端口接触不良或频繁震荡导致数据无法被转发导致的丢包
----通过查看日志或更换端口进行对比测试。
show logging
3）链路存在问题导致CRC、Jabber等的丢包
----通过查看端口计数确认并更换链路进行测试。
show inter，show inter counter
4）端口STP逻辑状态的频繁变化，导致的数据转发中断
----通过查看日志和show spanning-tree 查看生成树的统计情况或打开debug开关进行查看。
5）端口限速导致的正常丢包
----查看QOS配置或调整限速大小进行对比测试。
6）MAC表或VLAN表或安全表（FFP）导致的转发不通。
----通过收集上层L2、VLAN、端口、FFP表进行确认对比。也可以调整相关安全功能进行打开或关闭。
show mac-address-table | inc xx（xx代表故障的MAC地址）
二层转发丢包的关键是必须提前确定丢包是在哪里产生的，可以通过分段测试法，充分利用镜像捉包的功能。
二层转发的终极手段是清空设备配置，保留最单纯的环境，进行转发测试，如有仍然有丢包等情况，一般为硬件故障。
11、三层转发丢包常见原因及信息收集
三层转发丢包由于涉及到查找路由和打通路由（ARP）的过程，所以除了上述二层转发丢包的可能性原因以外，还新增了如下几种可能的原因：
1）路由频繁震荡（例如动态路由频繁震荡、路由频繁发生切换或底层路由溢出）
----可以查看相关日志，并收集路由表项，或尝试静态制定相关表项。
show logging，show ip route，show ip ospf
neighbor，show arp，show ip ref adj，show ip ref adj | inc xx（xx代表故障的IP/MAC地址）
2）ARP表频繁发生变化，需要重现打通（例如Tc change导致的三层设备清除ARP地址表）
----可以查看相关STP日志并优化配置或打印相关debug 日志，也可以尝试静态绑定相关表项。
show spanning-tree summary，show log，show arp
| inc xx，show ip ref adj | inc xx（xx代表故障的IP/MAC地址）
3）安全过滤，例如ACL、URPF等某些安全策略将部分报文过滤导致的丢包
----可从配置上、log上进行相关分析及查看。
排查三层转发故障的时候第一要求也是必须确定丢包点在哪个地方，然后根据如上的可能性进行逐一排查。
举个例子：我们通常ping某个目的地址的时候，都会发现ping
5个包，会丢包一个包，原因就是由于第一个包由于目标机器没有源主机的ARP，ARP打通的时间超过ICMP timeout 2s的原因。
三层转发故障定位到单台箱式设备时，当排除了环境因素或功能模块导致的问题后，可能由于内部数据通道之间连接异常导致的丢包，也可以进行槽位更换、线卡替换的排查工作。
12、S5750 内网用户使用飞鸽传书软件，不同VLAN间用户无法互传文件？
故障原因：
部分局域网同传软件（如：飞鸽传书）服务端与客户端交互的报文为255.255.255.255的广播报文，我司交换机不同vlan端口之间是隔离广播报文的，不同广播域间的全网广播会被直接丢弃。
规避方法：
1、方法一：将属于不同VLAN的access接口换成hybrid口，然后通过配置相同的native vlan并且untaged之前的access
vlan实现同一广播域洪泛。
2、方法二：重新规划网络vlan，使要使用飞鸽的端口划入同样的access vlan口。