Tweet
Khi Router Cisco “thở dốc”: Phân tích và khắc phục các vấn đề hiệu năng trên router
Là quản trị viên mạng, đôi khi bạn sẽ gặp một tình huống khá khó chịu: phiên Telnet hoặc SSH vào router phản hồi rất chậm, thậm chí các gói ping đến router cũng mất thời gian lâu hơn bình thường. Những dấu hiệu này thường là lời cảnh báo rằng router đang gặp vấn đề về hiệu năng.
Trong nhiều trường hợp, nguyên nhân không nằm ở đường truyền WAN hay routing protocol, mà nằm ngay bên trong router: CPU quá tải, bộ nhớ bị cạn kiệt, hoặc cơ chế chuyển tiếp gói không tối ưu. Nếu không xử lý kịp thời, hậu quả không chỉ là độ trễ tăng cao mà còn có thể khiến adjacency của các giao thức định tuyến bị sập, làm một phần hệ thống mạng trở nên unreachable.
Trong bài này, chúng ta sẽ đi sâu vào các nguyên nhân phổ biến gây suy giảm hiệu năng router Cisco và cách troubleshooting theo góc nhìn thực chiến.
Các nguyên nhân phổ biến gây hiệu năng kém trên router
Có ba nhóm nguyên nhân chính cần kiểm tra:
Phần nội dung tài liệu này tập trung trước tiên vào CPU utilization.
CPU utilization quá cao
CPU của router tăng cao trong thời gian ngắn không hẳn là vấn đề. Ví dụ:
Đây có thể là hành vi bình thường.
Nhưng nếu CPU liên tục duy trì ở mức cao trong thời gian dài, hệ thống sẽ bắt đầu phát sinh vấn đề:
Hiểu đơn giản: router vẫn “sống”, nhưng đang quá bận để làm việc đúng cách.
Những process thường gây CPU cao trên router Cisco
1. ARP Input process
Một trong những thủ phạm kinh điển là ARP Input process.
Process này chịu trách nhiệm gửi ARP Request để tìm địa chỉ MAC tương ứng với IP cần liên lạc.
Ví dụ cấu hình sai:
ip route 0.0.0.0 0.0.0.0 fastethernet 0/1
Thoạt nhìn, cấu hình này có vẻ hợp lý:
“Mọi traffic không biết đường đi thì cứ đẩy ra Fa0/1.”
Nhưng đây là một thiết kế không tốt.
Vì sao?
Router hiểu rằng:
"Tất cả các mạng đều reachable trực tiếp qua interface Fa0/1."
Điều này khiến router phải ARP cho từng destination IP.
Ví dụ:
packet đến:
Dst = 8.8.8.8
Router sẽ gửi:
Who has 8.8.8.8?
Packet khác:
Dst = 1.1.1.1
Router lại ARP:
Who has 1.1.1.1?
Cứ như vậy cho từng destination IP.
Vì sao nguy hiểm?
Kết quả:
Đây là lỗi cấu hình rất hay gặp ở người mới học routing.
Cách đúng
Thay vì chỉ định interface trực tiếp:
ip route 0.0.0.0 0.0.0.0 fastethernet 0/1
Hãy chỉ định next-hop:
ip route 0.0.0.0 0.0.0.0 192.168.1.1
Khi đó router chỉ cần ARP cho:
192.168.1.1
thay vì ARP cho toàn bộ Internet.
Khác biệt là rất lớn.
2. Net Background process
Mỗi interface đều có buffer để lưu packet tạm thời.
Bạn có thể hình dung như một hàng chờ (queue).
Nếu interface cần thêm buffer nhưng queue đã đầy, router sẽ mượn buffer từ global memory pool.
Process xử lý việc này là:
Net Background
Nếu Net Background hoạt động quá nhiều, CPU sẽ tăng.
Dấu hiệu
Kiểm tra interface:
show interface g0/0
Nếu thấy các counter tăng:
throttles
ignored
overrun
đó là dấu hiệu cảnh báo.
Ý nghĩa
throttles
Router phải trì hoãn xử lý packet vì thiếu tài nguyên. ignored
Packet đến nhưng không có buffer để chứa. overrun
Packet đến nhanh hơn khả năng xử lý của interface.
Ví dụ thực tế
Một router branch:
Bạn có thể thấy:
ignored: 1542
overrun: 987
Điều này cho thấy router đang nghẽn ở data plane resource.
3. IP Background process
Process này xử lý các thay đổi trạng thái interface.
Ví dụ:
Nếu interface liên tục thay đổi trạng thái, process này sẽ chiếm CPU đáng kể.
Nguyên nhân thường gặp
Cáp lỗi
Loose cable:
UP
DOWN
UP
DOWN
liên tục.
Module lỗi
SFP không ổn định.
Duplex mismatch
Link không ổn định do negotiation lỗi.
Power issue
Thiết bị upstream mất điện chập chờn.
Thực tế
Một cổng uplink flap mỗi vài giây có thể khiến:
IP Background
leo CPU rất nhanh.
4. TCP Timer process
Process này quản lý các TCP connection trên router.
Mỗi phiên TCP đều tiêu tốn tài nguyên.
Ví dụ:
Nếu số lượng connection lớn, CPU tăng.
Established connection
Phiên TCP hoàn tất 3-way handshake:
SYN
SYN-ACK
ACK
Kết nối hợp lệ.
Embryonic connection
Handshake chưa hoàn tất.
Ví dụ:
Client gửi:
SYN
Server phản hồi:
SYN-ACK
Nhưng client không gửi:
ACK
Router phải giữ state chờ timeout.
Vì sao nguy hiểm?
Nếu có hàng ngàn embryonic connections:
Đây là dấu hiệu điển hình của:
Các lệnh troubleshooting CPU trên Cisco IOS
show ip arp
Hiển thị ARP cache:
show ip arp
Nếu thấy nhiều entry:
Incomplete
hãy nghi ngờ:
Ví dụ:
Internet 10.1.1.15 Incomplete
Internet 10.1.1.16 Incomplete
Internet 10.1.1.17 Incomplete
Rất đáng nghi.
show interface
show interface g0/0
Kiểm tra:
Nếu counter tiếp tục tăng, Net Background có thể là nguyên nhân.
show tcp statistics
show tcp statistics
Dùng để xem:
Nếu embryonic connection quá nhiều:
có thể đang bị SYN flood.
show processes cpu
Lệnh quan trọng nhất:
show processes cpu
Cho biết:
Ví dụ:
CPU utilization for five seconds: 92%
CPU utilization for one minute: 89%
CPU utilization for five minutes: 87%
Nếu duy trì như vậy thì chắc chắn có vấn đề.
show processes cpu history
show processes cpu history
Lệnh này cực kỳ hữu ích.
Nó cho bạn biểu đồ CPU theo thời gian:
Điều này giúp phân biệt:
CPU spike tạm thời
hay
CPU cao kéo dài
Ví dụ:
Backup job lúc 1 AM gây spike → bình thường.
CPU 90% suốt nhiều giờ → bất thường.
Troubleshooting mindset
Khi CPU router cao, đừng chỉ nhìn một con số.
Hãy hỏi:
CPU cao vì control plane?
Hay data plane pressure?
Hay security event?
Hay bad design?
Một checklist thực chiến:
show processes cpu
show processes cpu history
show ip arp
show interface
show tcp statistics
Sau đó đối chiếu symptom.
Ví dụ:
Kết luận
Router chậm không phải lúc nào cũng do bandwidth.
Rất nhiều trường hợp, vấn đề nằm ở chính CPU của router.
Chỉ cần một cấu hình default route sai, một interface flap, hoặc một đợt SYN flood nhẹ cũng đủ làm router “thở không ra hơi”.
Hiểu cách đọc process CPU và correlate với các symptom xung quanh là kỹ năng quan trọng của một network engineer chuyên nghiệp.
(Phần tiếp theo: packet switching mode và memory troubleshooting.)
Là quản trị viên mạng, đôi khi bạn sẽ gặp một tình huống khá khó chịu: phiên Telnet hoặc SSH vào router phản hồi rất chậm, thậm chí các gói ping đến router cũng mất thời gian lâu hơn bình thường. Những dấu hiệu này thường là lời cảnh báo rằng router đang gặp vấn đề về hiệu năng.
Trong nhiều trường hợp, nguyên nhân không nằm ở đường truyền WAN hay routing protocol, mà nằm ngay bên trong router: CPU quá tải, bộ nhớ bị cạn kiệt, hoặc cơ chế chuyển tiếp gói không tối ưu. Nếu không xử lý kịp thời, hậu quả không chỉ là độ trễ tăng cao mà còn có thể khiến adjacency của các giao thức định tuyến bị sập, làm một phần hệ thống mạng trở nên unreachable.
Trong bài này, chúng ta sẽ đi sâu vào các nguyên nhân phổ biến gây suy giảm hiệu năng router Cisco và cách troubleshooting theo góc nhìn thực chiến.
Các nguyên nhân phổ biến gây hiệu năng kém trên router
Có ba nhóm nguyên nhân chính cần kiểm tra:
- CPU utilization quá cao
- Packet switching mode không phù hợp
- Memory utilization quá cao
Phần nội dung tài liệu này tập trung trước tiên vào CPU utilization.
CPU utilization quá cao
CPU của router tăng cao trong thời gian ngắn không hẳn là vấn đề. Ví dụ:
- routing table đang reconverge
- interface vừa flap
- cấu hình vừa thay đổi
- router đang xử lý burst traffic
Đây có thể là hành vi bình thường.
Nhưng nếu CPU liên tục duy trì ở mức cao trong thời gian dài, hệ thống sẽ bắt đầu phát sinh vấn đề:
- SSH/Telnet chậm
- ping timeout hoặc latency cao
- routing protocol hello/update gửi chậm
- OSPF/BGP/EIGRP adjacency reset
- packet bị drop
- control plane mất ổn định
Hiểu đơn giản: router vẫn “sống”, nhưng đang quá bận để làm việc đúng cách.
Những process thường gây CPU cao trên router Cisco
1. ARP Input process
Một trong những thủ phạm kinh điển là ARP Input process.
Process này chịu trách nhiệm gửi ARP Request để tìm địa chỉ MAC tương ứng với IP cần liên lạc.
Ví dụ cấu hình sai:
ip route 0.0.0.0 0.0.0.0 fastethernet 0/1
Thoạt nhìn, cấu hình này có vẻ hợp lý:
“Mọi traffic không biết đường đi thì cứ đẩy ra Fa0/1.”
Nhưng đây là một thiết kế không tốt.
Vì sao?
Router hiểu rằng:
"Tất cả các mạng đều reachable trực tiếp qua interface Fa0/1."
Điều này khiến router phải ARP cho từng destination IP.
Ví dụ:
packet đến:
Dst = 8.8.8.8
Router sẽ gửi:
Who has 8.8.8.8?
Packet khác:
Dst = 1.1.1.1
Router lại ARP:
Who has 1.1.1.1?
Cứ như vậy cho từng destination IP.
Vì sao nguy hiểm?
Kết quả:
- số lượng ARP request tăng cực lớn
- CPU phải xử lý liên tục
- nhiều ARP request không bao giờ có phản hồi
- packet bị drop
- hiệu năng router giảm mạnh
Đây là lỗi cấu hình rất hay gặp ở người mới học routing.
Cách đúng
Thay vì chỉ định interface trực tiếp:
ip route 0.0.0.0 0.0.0.0 fastethernet 0/1
Hãy chỉ định next-hop:
ip route 0.0.0.0 0.0.0.0 192.168.1.1
Khi đó router chỉ cần ARP cho:
192.168.1.1
thay vì ARP cho toàn bộ Internet.
Khác biệt là rất lớn.
2. Net Background process
Mỗi interface đều có buffer để lưu packet tạm thời.
Bạn có thể hình dung như một hàng chờ (queue).
Nếu interface cần thêm buffer nhưng queue đã đầy, router sẽ mượn buffer từ global memory pool.
Process xử lý việc này là:
Net Background
Nếu Net Background hoạt động quá nhiều, CPU sẽ tăng.
Dấu hiệu
Kiểm tra interface:
show interface g0/0
Nếu thấy các counter tăng:
throttles
ignored
overrun
đó là dấu hiệu cảnh báo.
Ý nghĩa
throttles
Router phải trì hoãn xử lý packet vì thiếu tài nguyên. ignored
Packet đến nhưng không có buffer để chứa. overrun
Packet đến nhanh hơn khả năng xử lý của interface.
Ví dụ thực tế
Một router branch:
- WAN 100 Mbps
- burst traffic backup
- CPU không theo kịp
Bạn có thể thấy:
ignored: 1542
overrun: 987
Điều này cho thấy router đang nghẽn ở data plane resource.
3. IP Background process
Process này xử lý các thay đổi trạng thái interface.
Ví dụ:
- Up → Down
- Down → Up
- IP address thay đổi
Nếu interface liên tục thay đổi trạng thái, process này sẽ chiếm CPU đáng kể.
Nguyên nhân thường gặp
Cáp lỗi
Loose cable:
UP
DOWN
UP
DOWN
liên tục.
Module lỗi
SFP không ổn định.
Duplex mismatch
Link không ổn định do negotiation lỗi.
Power issue
Thiết bị upstream mất điện chập chờn.
Thực tế
Một cổng uplink flap mỗi vài giây có thể khiến:
IP Background
leo CPU rất nhanh.
4. TCP Timer process
Process này quản lý các TCP connection trên router.
Mỗi phiên TCP đều tiêu tốn tài nguyên.
Ví dụ:
- SSH
- Telnet
- BGP
- API management
- SNMP over TCP
Nếu số lượng connection lớn, CPU tăng.
Established connection
Phiên TCP hoàn tất 3-way handshake:
SYN
SYN-ACK
ACK
Kết nối hợp lệ.
Embryonic connection
Handshake chưa hoàn tất.
Ví dụ:
Client gửi:
SYN
Server phản hồi:
SYN-ACK
Nhưng client không gửi:
ACK
Router phải giữ state chờ timeout.
Vì sao nguy hiểm?
Nếu có hàng ngàn embryonic connections:
- CPU tăng
- memory tăng
- session table đầy
Đây là dấu hiệu điển hình của:
- DoS attack
- SYN flood
- connectivity issue
Các lệnh troubleshooting CPU trên Cisco IOS
show ip arp
Hiển thị ARP cache:
show ip arp
Nếu thấy nhiều entry:
Incomplete
hãy nghi ngờ:
- ping sweep
- host scanning
- reconnaissance traffic
- default route trỏ trực tiếp Ethernet interface
Ví dụ:
Internet 10.1.1.15 Incomplete
Internet 10.1.1.16 Incomplete
Internet 10.1.1.17 Incomplete
Rất đáng nghi.
show interface
show interface g0/0
Kiểm tra:
- throttles
- overruns
- ignored
Nếu counter tiếp tục tăng, Net Background có thể là nguyên nhân.
show tcp statistics
show tcp statistics
Dùng để xem:
- TCP sessions
- initiated
- accepted
- established
- closed
Nếu embryonic connection quá nhiều:
có thể đang bị SYN flood.
show processes cpu
Lệnh quan trọng nhất:
show processes cpu
Cho biết:
- CPU 5 giây
- CPU 1 phút
- CPU 5 phút
- process nào đang ngốn CPU
Ví dụ:
CPU utilization for five seconds: 92%
CPU utilization for one minute: 89%
CPU utilization for five minutes: 87%
Nếu duy trì như vậy thì chắc chắn có vấn đề.
show processes cpu history
show processes cpu history
Lệnh này cực kỳ hữu ích.
Nó cho bạn biểu đồ CPU theo thời gian:
- 60 giây
- 1 giờ
- 3 ngày
Điều này giúp phân biệt:
CPU spike tạm thời
hay
CPU cao kéo dài
Ví dụ:
Backup job lúc 1 AM gây spike → bình thường.
CPU 90% suốt nhiều giờ → bất thường.
Troubleshooting mindset
Khi CPU router cao, đừng chỉ nhìn một con số.
Hãy hỏi:
CPU cao vì control plane?
Hay data plane pressure?
Hay security event?
Hay bad design?
Một checklist thực chiến:
show processes cpu
show processes cpu history
show ip arp
show interface
show tcp statistics
Sau đó đối chiếu symptom.
Ví dụ:
- nhiều Incomplete ARP → routing design
- interface overrun → congestion
- interface flap → physical issue
- embryonic TCP → possible attack
Kết luận
Router chậm không phải lúc nào cũng do bandwidth.
Rất nhiều trường hợp, vấn đề nằm ở chính CPU của router.
Chỉ cần một cấu hình default route sai, một interface flap, hoặc một đợt SYN flood nhẹ cũng đủ làm router “thở không ra hơi”.
Hiểu cách đọc process CPU và correlate với các symptom xung quanh là kỹ năng quan trọng của một network engineer chuyên nghiệp.
(Phần tiếp theo: packet switching mode và memory troubleshooting.)
Attached Files