我收到用户投诉，称大型仓库设施的两个部分之间的网络应用程序性能不佳。该软件是一个基于 curses 的终端应用程序，运行在 Linux 服务器上。客户端是运行 telnet 或 SSH 客户端的 PC。问题始于一天前，环境最近没有发生（已知）变化。
核心交换机是思科 Catalyst 4507R-E在里面中密度纤维板，链接到 Cisco Catalyst 2960 交换机的 4 成员堆栈以色列国防军... 它们通过多模光纤连接。服务器位于 MDF 中。受影响的客户端位于 IDF 中。
从 Linux 应用服务器 ping 到整个大楼的 2960 堆栈管理地址，结果显示差异很大，并且很多延迟：
--- shipping-2960.mdmarra.local ping statistics ---
864 packets transmitted, 864 received, 0% packet loss, time 863312ms
rtt min/avg/max/mdev = 0.521/5.317/127.037/8.698 ms
但是，从应用程序服务器到客户端计算机的 ping 操作更加一致：
--- charles-pc.mdmarra.local ping statistics ---
76 packets transmitted, 76 received, 0% packet loss, time 75001ms
rtt min/avg/max/mdev = 0.328/0.481/1.355/0.210 ms
相关 Linux 接口或交换机端口均未显示错误（参见问题底部）。
我该如何解决这个问题？
- 有没有简单的方法来确定端口活动？
- 交换机管理 IP 上的 ping 变化是不是错误的测量对象？
- 这可能是流氓电脑造成的吗？
- 由于问题只发生在建筑物的某个部分，我还应该检查其他什么吗？仓库中的其他用户都很好，没有遇到任何问题。
编辑：
后来我发现，Cisco 2960 CPU 利用率极高，是因为这个 bug详细内容在这里。
来自 2960 堆栈...
shipping-2960#sh int GigabitEthernet1/0/52
GigabitEthernet1/0/52 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is b414.894a.09b4 (bia b414.894a.09b4)
Description: TO_MDF_4507
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 13/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 441
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 3053000 bits/sec, 613 packets/sec
5 minute output rate 51117000 bits/sec, 4815 packets/sec
981767797 packets input, 615324451566 bytes, 0 no buffer
Received 295141786 broadcasts (286005510 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 286005510 multicast, 0 pause input
0 input packets with dribble condition detected
6372280523 packets output, 8375642643516 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
附加输出：
tcam 利用率为 2960。4507 上不可用。
shipping-2960# show platform tcam utilization
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 8412/8412 335/335
IPv4 IGMP groups + multicast routes: 384/384 1/1
IPv4 unicast directly-connected routes: 320/320 28/28
IPv4 unicast indirectly-connected routes: 0/0 28/28
IPv6 Multicast groups: 320/320 11/11
IPv6 unicast directly-connected routes: 256/256 1/1
IPv6 unicast indirectly-connected routes: 0/0 1/1
IPv4 policy based routing aces: 32/32 12/12
IPv4 qos aces: 384/384 42/42
IPv4 security aces: 384/384 33/33
IPv6 policy based routing aces: 16/16 8/8
IPv6 qos aces: 60/60 31/31
IPv6 security aces: 128/128 9/9
Cisco 2960 CPU 利用率历史记录...
shipping-2960#show processes cpu history
3333333444443333344444444443333333333444443333344444444443
9977777111119999966666222229999977777555559999911111000008
100
90
80
70
60
50 ***** *****
40 **********************************************************
30 **********************************************************
20 **********************************************************
10 **********************************************************
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per second (last 60 seconds)
4488887787444454444787888444444454677774444444447888544444
6401207808656506776708000447546664789977697589953201636647
100
90
80 *###*##* *#*##* *#** ###
70 #######* *##### *###* *###
60 #######* *##### * *#### *###*
50 * ########*********###### ** *** *####*********####* ** *
40 ##########################################################
30 ##########################################################
20 ##########################################################
10 ##########################################################
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per minute (last 60 minutes)
* = maximum CPU% # = average CPU%
8889888888888888988888889888888888888888888888888888888888888888898889
2322334378633453364454472653323431254225563228261399243233354222402310
100
90 * *** * ** * **** * *** * * ** * * *
80 *#############################*********************************#******
70 *#####################################################################
60 *#####################################################################
50 ######################################################################
40 ######################################################################
30 ######################################################################
20 ######################################################################
10 ######################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%
答案1
Cisco 交换机将 ICMP 置于优先级列表的底部。如果我们 ping 繁忙的 3750-X，我们会得到相同的结果。
您需要查看交换机上的系统利用率，因为我怀疑它们太忙了，以至于它们正在对数据包进行软件处理。您在这些交换机上运行任何类型的第 3 层服务吗？
iOS 12.2.53中有一个相当严重的bug：
CSCth24278（Catalyst 2960-S 交换机）
当交换机没有被 telnet 或控制台会话访问时，交换机上的 CPU 利用率仍然很高（50% 到 60%）。当您通过 telnet 或控制台访问交换机时，CPU 利用率会下降。
没有解决方法。
升级到 12.2.58-SE1 或更高版本可以解决此情况。