前言：丟包是症狀，非病因

路由器收到封包 → 查路由表 → 轉發/丟棄。**丟包發生點**通常在：**輸入佇列溢位、輸出佇列溢位、CPU 處理不過來、記憶體無法分配緩衝區**。最核心兩大根因：**記憶體碎片化** 與 **CPU 過載**。

一、記憶體碎片化：隱形殺手

什麼是記憶體碎片？

路由器記憶體被分配/釋放後，形成大量**不連續的小塊**。總可用記憶體看似充足，但**最大連續可用塊**極小，導致大封包 (如 1500B、Jumbo Frame) 無法分配緩衝區 → **強制丟包**。

診斷命令：`show memory` (Cisco/H3C/Huawei 通用)

Router# show memory
Head    Total(b)     Used(b)     Free(b)     Lowest(b)    Largest(b)
Processor  0x...   20971520    8388608    12582912    10485760     8388608
I/O        0x...    4194304    1048576    3145728     2097152     2097152

• Free：總可用位元組
• Largest：最大連續可用塊位元組

判斷準則：Free vs Largest 比值

經驗閾值

**建議維持 Largest ≥ Free 的 1/3 ~ 1/2**。若低於 1/10，必須干預。

形象比喻：櫃子抽屜理論

櫃子總容量大 (Free 大)，但被切成 1000 個小格子 (碎片)，大物件 (大封包) 放不進去 → **雖有空間卻無法存放** = 丟包。

緩解措施

• **定時重啟**：排程凌晨重啟，釋放碎片 (治標)
• **升級記憶體**：物理擴容 (治本，受限於硬體插槽/最大支援)
• **優化配置**：減少不必要的路由表項、ACL 條目、NetFlow 採樣率、日誌級別
• **軟體升級**：新版固件常包含記憶體管理優化 (Slab Allocator、Pool Tuning)

二、CPU 過載：顯性瓶頸

診斷命令：`show processes cpu` (或 `display cpu-usage`)

CPU utilization for five seconds: 85%/12%; one minute: 78%; five minutes: 72%
 PID Runtime(ms)   Invoked  uSecs   5Sec  1Min  5Min  TTY Process
   12   12345678    123456    100   45%   42%   40%   0  IP Input
   34    2345678    234567     10   20%   18%   17%   0  ARP Process
   56    3456789    345678     10   15%   14%   13%   0  SNMP Engine

判斷準則

• **5 分鐘平均 CPU < 60%** → 健康
• **5 分鐘平均 CPU 60%~70%** → 警戒，排查高佔用進程
• **5 分鐘平均 CPU > 70%** → **過載**，必須干預，極大概率導致丟包

定位「元兇」進程

1. `show processes cpu` 找出 **5Min 佔用最高** 的 PID
2. `show processes memory` 對照該 PID 記憶體佔用
3. **雙高 (CPU+MEM) 進程 = 核心嫌疑犯**

常見高 CPU 進程與對策

Free	Largest	Largest/Free	碎片嚴重度	風險
20 MB	15 MB	75%	輕微	正常運行無影響
20 MB	8 MB	40%	中等	大封包偶發丟包，需關注
20 MB	0.8 MB	4%	**嚴重**	**頻繁丟包、介面間歇性失效、BGP/OSPF 鄰居震盪**

進程名	典型原因	對策
IP Input / IP Background	大量封包需 CPU 處理 (ACL/NAT/Qos/隧道/選項)	啟用硬體轉發 (CEF/Fast Switching)、優化 ACL 順序、關閉不必要服務
ARP / ARP Input	ARP 風暴/掃描/環路	啟用 DAI、Port Security、Storm Control、檢查環路
BGP / OSPF / ISIS	路由震盪、全表重算、鄰居抖動	Route Dampening、BFD 快速檢測、優化區域劃分、摘要路由
SNMP Engine	監控系統採集頻率過高/MIB 遍歷	降低採集頻率、限制 MIB 視圖、使用 Telemetry 替代
HTTP/HTTPS/SSH/TELNET	暴力破解/掃描/大量並發管理連線	ACL 限制管理平面存取、啟用 SSH Key、Fail2ban、Control Plane Policing
SRB Background	橋接風暴 (SRB = Source Route Bridging)	關閉無用橋接功能、啟用生成樹

緊急止血：強制關閉可疑進程/服務驗證

# Cisco 範例：關閉 HTTP Server (若為嫌疑)
no ip http server
# 或關閉 SNMP
no snmp-server
# 驗證丟包是否改善 → 是 → 根因確認 → 修復配置/升級固件 → 重啟服務

三、綜合診斷決策樹

發現丟包
    │
    ├─ show memory → Largest/Free < 0.3？ → 是 → 記憶體碎片化 → 重啟/優化/擴容/升級
    │
    └─ 否 → show processes cpu → 5Min CPU > 70%？ → 是 → CPU 過載 → 定位高佔用進程 → 針對性優化/關閉/升級
    │
    └─ 否 → 檢查介面計數器 (CRC/Input Error/Output Error/Overrun/Underrun)
            → 物理層故障 (光模塊/纖維/網線/埠速率雙工不匹配)
    │
    └─ 檢查 ACL/QoS/策略路由/NAT 配置錯誤導致黑洞/迴路
    │
    └─ 檢查對端設備/鏈路/運營商端

四、防禦性設計：從源頭減少丟包

• **硬體轉發優先**：核心路由器必須支援 CEF/dCEF/NPU/ASIC 線速轉發，CPU 僅處理控制平面
• **控制平面保護 (CoPP/CPPr)**：限制送達 CPU 的報文速率 (ICMP、ARP、路由協議、管理流量)
• **佇列管理**：WFQ/CBWFQ/LLQ 保障關鍵業務、限制 Best-effort 佇列深度
• **主動監控**：NQA/SLA Probe 持續測試關鍵路徑丟包/延遲/抖動，異常即告警

**記住**：路由器再貴、交換技術再先進 (過程/快速/自治/矽交換)，**沒有封包輸入，一切歸零**。守住記憶體與 CPU，就是守住網絡生命線。