Networking
兩個位置的 Cisco 交換機之間的高延遲/丟包。如何排除故障？
我收到了有關大型倉庫設施的兩個部分之間網路應用程序性能不佳的使用者投訴。該軟體是在 Linux 伺服器上執行的基於 curses 的終端應用程序。客戶端是執行 telnet 或 SSH 客戶端的 PC。問題開始於一天前，環境最近（已知）沒有變化。
核心交換機是MDF中的Cisco Catalyst 4507R-E，連接到IDF中 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 差異是否測量錯誤？
- 這可能是流氓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附加輸出：
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/9Cisco 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%
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 或更高版本以解決此問題。