Tweet
Khắc phục sự cố hiệu năng trên switch Cisco Catalyst: Bắt đầu từ đâu?
Một trong những tình huống “khó chịu” nhất đối với kỹ sư mạng là nhận được phản ánh kiểu: “Mạng hôm nay chậm quá!”
Nghe thì đơn giản, nhưng đây lại là một trong những dạng sự cố khó xử lý nhất. Vì sao? Bởi chữ “chậm” thường mang tính cảm nhận (subjective). Với người dùng, “chậm” có thể chỉ đơn giản là ứng dụng mở lâu hơn họ mong đợi 2–3 giây. Nhưng cũng có thể đó là dấu hiệu thật sự của một vấn đề nghiêm trọng đang làm giảm hiệu suất toàn hệ thống.
Điều đầu tiên trong troubleshooting không phải là lao ngay vào switch, mà là trả lời câu hỏi:
“Chậm do network, hay do endpoint/application?”
Rất nhiều trường hợp, switch hoàn toàn bình thường, nhưng nguyên nhân thật sự lại nằm ở:
Nói cách khác, network thường bị nghi ngờ đầu tiên, nhưng không phải lúc nào cũng là thủ phạm.
Khi đã xác định switch là nguyên nhân
Nếu quá trình phân tích xác nhận rằng hiệu năng mạng đang thấp hơn mức kỹ thuật kỳ vọng (không chỉ là cảm giác người dùng), và thiết bị gây ra vấn đề là một Cisco Catalyst switch, thì lúc này mới bắt đầu troubleshooting ở cấp độ switch.
Cần lưu ý rằng Cisco có rất nhiều dòng Catalyst khác nhau:
Mỗi platform có:
Vì vậy troubleshooting luôn mang tính platform-dependent.
Tuy nhiên, hầu hết Cisco Catalyst switch đều có cùng các thành phần cốt lõi.
Các thành phần quan trọng trong Cisco Catalyst Switch
1. Ports (Interfaces)
Đây là thành phần dễ hình dung nhất.
Port là nơi switch kết nối vật lý với các thiết bị khác:
Port thực hiện hai chức năng:
Ví dụ:
PC gửi frame vào cổng Gi1/0/10 → đây là ingress port.
Switch quyết định chuyển tiếp frame sang Gi1/0/24 → đây là egress port.
Nếu port gặp lỗi vật lý, hiệu năng sẽ bị ảnh hưởng ngay lập tức.
2. Forwarding Logic
Đây là “bộ não chuyển mạch” ở data plane.
Switch không forward frame ngẫu nhiên. Nó dựa trên các bảng thông tin như:
Ví dụ:
Switch nhận frame có destination MAC:
00:11:22:33:44:55
Nó tra CAM table:
00:11:22:33:44:55 → Gi1/0/24
Sau đó forwarding logic quyết định:
“Gửi frame ra Gi1/0/24.”
Nếu forwarding logic bị quá tải hoặc resource lookup gặp vấn đề, switch performance sẽ giảm.
3. Backplane
Backplane là “xa lộ nội bộ” của switch.
Khi traffic đi qua switch:
Ingress Port → Backplane → Egress Port
Backplane kết nối tất cả các port vật lý bên trong thiết bị.
Ví dụ:
Một switch 48-port Gigabit Ethernet.
Nếu nhiều port cùng truyền traffic đồng thời, tất cả đều chia sẻ switching fabric/backplane bandwidth.
Nếu switch có:
Switching capacity = 176 Gbps
thì tổng traffic vượt mức này sẽ gây congestion.
Kết quả:
4. Control Plane
Đây là nơi chứa:
Control plane chịu trách nhiệm:
Ví dụ:
Switch phải xử lý:
Tất cả đều dùng CPU.
Control Plane có ảnh hưởng hiệu năng không?
Thoạt nhìn thì có vẻ không.
Vì forwarding frame chủ yếu do ASIC ở data plane xử lý.
Nhưng thực tế thì có ảnh hưởng gián tiếp rất lớn.
Lý do:
Forwarding hardware không tự “nghĩ”.
Nó nhận logic từ control plane.
Ví dụ:
Control plane xây:
Data plane chỉ dùng thông tin này để forward.
Nếu control plane bị stress:
thì hậu quả:
=> performance toàn switch giảm.
Khi forwarding hardware bị full
Bình thường:
ASIC handles forwarding
Nhanh, wire-speed.
Nhưng nếu hardware resource đạt cực hạn:
thì một phần traffic có thể bị punt lên CPU.
Lúc này:
Data plane → Control plane
CPU phải tham gia forwarding.
Đây là kịch bản rất nguy hiểm vì CPU forwarding chậm hơn ASIC rất nhiều.
Ví dụ:
ASIC xử lý:
millions of packets per second
CPU xử lý:
ít hơn rất nhiều.
Kết quả:
Hai mục tiêu troubleshooting phổ biến nhất
Theo thực tế vận hành Cisco Catalyst, hai điểm kiểm tra đầu tiên khi nghi ngờ switch performance là: Port Errors
Các lỗi vật lý ở interface thường là nguyên nhân cực phổ biến.
Ví dụ:
show interfaces
Bạn có thể thấy:
Ví dụ CRC tăng:
thường liên quan:
Duplex Mismatch
Một classic issue.
Ví dụ:
Switch:
Full duplex
Thiết bị đối diện:
Half duplex
Kết quả:
Biểu hiện:
Người dùng than:
“Mạng chậm bất thường nhưng không down.”
Kiểm tra:
show interfaces status
show interfaces
Tư duy troubleshooting đúng
Đừng bắt đầu bằng assumption:
“Switch chậm.”
Hãy đi theo flow:
Bước 1
Xác nhận vấn đề thật sự tồn tại:
Bước 2
Xác định domain:
Bước 3
Nếu là switch:
kiểm tra:
Một kỹ sư mạng giỏi không chỉ biết gõ lệnh.
Họ biết xác định đúng nơi cần nhìn trước tiên.
Một trong những tình huống “khó chịu” nhất đối với kỹ sư mạng là nhận được phản ánh kiểu: “Mạng hôm nay chậm quá!”
Nghe thì đơn giản, nhưng đây lại là một trong những dạng sự cố khó xử lý nhất. Vì sao? Bởi chữ “chậm” thường mang tính cảm nhận (subjective). Với người dùng, “chậm” có thể chỉ đơn giản là ứng dụng mở lâu hơn họ mong đợi 2–3 giây. Nhưng cũng có thể đó là dấu hiệu thật sự của một vấn đề nghiêm trọng đang làm giảm hiệu suất toàn hệ thống.
Điều đầu tiên trong troubleshooting không phải là lao ngay vào switch, mà là trả lời câu hỏi:
“Chậm do network, hay do endpoint/application?”
Rất nhiều trường hợp, switch hoàn toàn bình thường, nhưng nguyên nhân thật sự lại nằm ở:
- máy client bị quá tải CPU/RAM
- server phản hồi chậm
- ứng dụng bị bottleneck
- database xử lý kém
- storage latency cao
Nói cách khác, network thường bị nghi ngờ đầu tiên, nhưng không phải lúc nào cũng là thủ phạm.
Khi đã xác định switch là nguyên nhân
Nếu quá trình phân tích xác nhận rằng hiệu năng mạng đang thấp hơn mức kỹ thuật kỳ vọng (không chỉ là cảm giác người dùng), và thiết bị gây ra vấn đề là một Cisco Catalyst switch, thì lúc này mới bắt đầu troubleshooting ở cấp độ switch.
Cần lưu ý rằng Cisco có rất nhiều dòng Catalyst khác nhau:
- Catalyst 2960
- Catalyst 3560
- Catalyst 3850
- Catalyst 9300
- Catalyst 9500
- Catalyst 9600
Mỗi platform có:
- mật độ cổng (port density) khác nhau
- switching capacity khác nhau
- forwarding ASIC khác nhau
- kiến trúc phần cứng khác nhau
Vì vậy troubleshooting luôn mang tính platform-dependent.
Tuy nhiên, hầu hết Cisco Catalyst switch đều có cùng các thành phần cốt lõi.
Các thành phần quan trọng trong Cisco Catalyst Switch
1. Ports (Interfaces)
Đây là thành phần dễ hình dung nhất.
Port là nơi switch kết nối vật lý với các thiết bị khác:
- PC
- server
- router
- firewall
- access point
- switch khác
Port thực hiện hai chức năng:
- nhận traffic vào (ingress)
- gửi traffic ra (egress)
Ví dụ:
PC gửi frame vào cổng Gi1/0/10 → đây là ingress port.
Switch quyết định chuyển tiếp frame sang Gi1/0/24 → đây là egress port.
Nếu port gặp lỗi vật lý, hiệu năng sẽ bị ảnh hưởng ngay lập tức.
2. Forwarding Logic
Đây là “bộ não chuyển mạch” ở data plane.
Switch không forward frame ngẫu nhiên. Nó dựa trên các bảng thông tin như:
- MAC address table
- VLAN information
- CAM table
- TCAM entries
- QoS forwarding policies
- ACL lookup
Ví dụ:
Switch nhận frame có destination MAC:
00:11:22:33:44:55
Nó tra CAM table:
00:11:22:33:44:55 → Gi1/0/24
Sau đó forwarding logic quyết định:
“Gửi frame ra Gi1/0/24.”
Nếu forwarding logic bị quá tải hoặc resource lookup gặp vấn đề, switch performance sẽ giảm.
3. Backplane
Backplane là “xa lộ nội bộ” của switch.
Khi traffic đi qua switch:
Ingress Port → Backplane → Egress Port
Backplane kết nối tất cả các port vật lý bên trong thiết bị.
Ví dụ:
Một switch 48-port Gigabit Ethernet.
Nếu nhiều port cùng truyền traffic đồng thời, tất cả đều chia sẻ switching fabric/backplane bandwidth.
Nếu switch có:
Switching capacity = 176 Gbps
thì tổng traffic vượt mức này sẽ gây congestion.
Kết quả:
- packet drops
- latency tăng
- throughput giảm
4. Control Plane
Đây là nơi chứa:
- CPU
- memory
- operating system
Control plane chịu trách nhiệm:
- chạy Cisco IOS / IOS XE
- xây MAC address table
- xử lý STP
- xử lý routing protocols
- xử lý management traffic
- xử lý ARP
- xử lý control packets
Ví dụ:
Switch phải xử lý:
- STP BPDUs
- CDP
- LLDP
- ARP requests
- routing updates
Tất cả đều dùng CPU.
Control Plane có ảnh hưởng hiệu năng không?
Thoạt nhìn thì có vẻ không.
Vì forwarding frame chủ yếu do ASIC ở data plane xử lý.
Nhưng thực tế thì có ảnh hưởng gián tiếp rất lớn.
Lý do:
Forwarding hardware không tự “nghĩ”.
Nó nhận logic từ control plane.
Ví dụ:
Control plane xây:
- MAC table
- spanning tree topology
- routing information
Data plane chỉ dùng thông tin này để forward.
Nếu control plane bị stress:
- CPU 95–100%
- memory cạn
- process overload
thì hậu quả:
- MAC learning chậm
- topology recalculation chậm
- ARP processing delay
- protocol instability
=> performance toàn switch giảm.
Khi forwarding hardware bị full
Bình thường:
ASIC handles forwarding
Nhanh, wire-speed.
Nhưng nếu hardware resource đạt cực hạn:
- CAM exhausted
- TCAM full
- forwarding engine overloaded
thì một phần traffic có thể bị punt lên CPU.
Lúc này:
Data plane → Control plane
CPU phải tham gia forwarding.
Đây là kịch bản rất nguy hiểm vì CPU forwarding chậm hơn ASIC rất nhiều.
Ví dụ:
ASIC xử lý:
millions of packets per second
CPU xử lý:
ít hơn rất nhiều.
Kết quả:
- latency spike
- packet loss
- switch appears slow
Hai mục tiêu troubleshooting phổ biến nhất
Theo thực tế vận hành Cisco Catalyst, hai điểm kiểm tra đầu tiên khi nghi ngờ switch performance là: Port Errors
Các lỗi vật lý ở interface thường là nguyên nhân cực phổ biến.
Ví dụ:
show interfaces
Bạn có thể thấy:
- input errors
- CRC
- frame errors
- runts
- giants
- overruns
- ignored
- output drops
Ví dụ CRC tăng:
thường liên quan:
- cáp lỗi
- SFP lỗi
- electromagnetic interference
- bad patch panel
Duplex Mismatch
Một classic issue.
Ví dụ:
Switch:
Full duplex
Thiết bị đối diện:
Half duplex
Kết quả:
- collisions
- late collisions
- retransmissions
- throughput cực thấp
Biểu hiện:
Người dùng than:
“Mạng chậm bất thường nhưng không down.”
Kiểm tra:
show interfaces status
show interfaces
Tư duy troubleshooting đúng
Đừng bắt đầu bằng assumption:
“Switch chậm.”
Hãy đi theo flow:
Bước 1
Xác nhận vấn đề thật sự tồn tại:
- latency?
- packet loss?
- throughput drop?
Bước 2
Xác định domain:
- client?
- server?
- application?
- network?
Bước 3
Nếu là switch:
kiểm tra:
- interface health
- duplex/speed
- CPU
- memory
- CAM/TCAM
- STP events
- drops
- ASIC counters
Một kỹ sư mạng giỏi không chỉ biết gõ lệnh.
Họ biết xác định đúng nơi cần nhìn trước tiên.
Attached Files