2つの場所にあるCiscoスイッチ間の高遅延/ドロップ。トラブルシューティングする方法？
大規模な倉庫施設の2つの部分間のネットワークアプリケーションのパフォーマンスが低いというユーザーからの苦情を受けています。ソフトウェアは、Linuxサーバー上で実行されるcursesベースの端末アプリケーションです。クライアントは、TelnetまたはSSHクライアントを実行しているPCです。問題は1日前に始まり、最近の（既知の）環境への変更はありません。
コアスイッチは [〜＃〜] mdf [〜＃〜] の Cisco Catalyst 4507R-E であり、Cisco Catalyst 2960スイッチの4メンバースタックにリンクされています [〜＃〜] idf [〜＃〜] ...では、マルチモードファイバーを介して接続されます。サーバーはMDFにあります。影響を受けるクライアントはIDFにあります。
Linuxアプリケーションサーバーから建物全体の2960スタックの管理アドレスにpingすると、変動が大きくなり、遅延がlot長くなります。
--- 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の差異を測定するのは間違っていますか？
- これは不正なPCの結果でしょうか？
- 問題は建物の一部に限定されているので、他に確認すべき点はありますか？ウェアハウスの他のユーザーは問題なく、何の問題もありませんでした。
編集：
バグ 詳細はこちら が原因で、Cisco 2960のCPU使用率が非常に高いことが後でわかりました。
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
追加の出力：
2960のtcam使用率。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%
シスコスイッチは、ICMPを優先順位リストの一番下に配置します。ビジーな3750-Xにpingを実行しても、同じ結果が得られます。
スイッチのシステム使用率を確認する必要があります。スイッチが非常にビジーで、パケットのソフトウェア処理を実行しているようです。これらで何らかのレイヤー3サービスを実行していますか？
IOS 12.2.53：
CSCth24278（Catalyst 2960-Sスイッチ）
スイッチがtelnetまたはコンソールセッションでアクセスされていない場合、スイッチのCPU使用率は高いままです（50〜60％）。スイッチにTelnetまたはコンソール接続すると、CPU使用率が低下します。
回避策はありません。
この状況を修正するには、12.2.58-SE1以降にアップグレードしてください。