Enterprise Campus Guideline

[dangquangminh]

Trong thời đại VoIP, Webex, Zoom và các ứng dụng cộng tác real-time, chỉ một cú giật hay mất gói trên mạng campus cũng đủ làm khách hàng hoặc sếp của bạn kêu trời. Vì vậy, triển khai QoS end-to-end từ access → distribution → core → WAN là nguyên tắc sống còn để bảo vệ trải nghiệm người dùng.

Dưới đây là các guidelines quan trọng khi triển khai QoS trong Campus Enterprise mà anh em CCNA, CCNP, CCIE cần nắm:

---

1. Classify & Mark càng gần nguồn càng tốt

• Nguyên tắc vàng: phân loại (classification) và đánh dấu (marking) traffic tại access edge, ngay khi nó vừa đi vào mạng.
• Lý do: Nếu để người dùng tự đánh DSCP/CoS thì cực kỳ nguy hiểm – ai cũng có thể gán EF (Expedited Forwarding) cho traffic không quan trọng → chiếm dụng hàng ưu tiên của VoIP/video.
• Ví dụ: Một nhân viên gán DSCP EF cho traffic tải phim → làm call center VoIP delay, jitter → QoS cả hệ thống coi như “vỡ trận”.

---

2. Police unwanted traffic ngay tại nguồn

• Không có lý do gì để cho phép traffic rác (malware, DDoS flood, scan) đi sâu vào mạng rồi mới drop.
• Hãy chặn hoặc giới hạn (police) ngay tại chỗ nó phát sinh.
• Ví dụ: Một user trong LAN chạy DoS bằng ICMP flood → nếu không police tại access switch, CPU firewall và core switch có thể bị nghẽn.

---

3. Ưu tiên QoS trong hardware, không phải software

• Router IOS thường xử lý QoS bằng CPU, dễ quá tải khi policy phức tạp.
• Switch Catalyst sử dụng ASIC chuyên dụng, xử lý QoS ở tốc độ 1G/10G/25G/40G line rate.
• Điều này cho phép triển khai QoS phức tạp mà không lo hiệu năng.

---

4. Queuing ở mọi điểm có nguy cơ nghẽn

• Campus thường underutilized (95% link access chạy <5%), nhưng vẫn có oversubscription:
  • Access → Distribution: 20:1
  • Distribution → Core: 4:1
• Khi nghẽn xảy ra (momentary burst), buffer có thể đầy → packet loss ngay lập tức.
• Vì vậy, queuing phải bật ở uplink hoặc bất kỳ điểm mismatch (VD: GE → FE).

---

5. QoS để bảo vệ khi bất thường xảy ra

• Bình thường campus ít nghẽn, nhưng khi có sự cố (DDoS, loop, broadcast storm), traffic tăng đột biến.
• Nếu không có QoS, traffic rác sẽ nuốt sạch băng thông, VoIP, video và cả traffic best-effort đều chết.
• QoS chính là “lá chắn” giữ cho ứng dụng quan trọng còn sống sót.

---

6. Đừng quên bảo vệ Control Plane & Data Plane

• Ngoài user traffic, control traffic (OSPF, EIGRP, BGP, HSRP) cũng cần bảo vệ.
• Nếu control plane nghẽn, mạng sập toàn diện.
• Cisco IOS cung cấp Control Plane Policing (CoPP) để bảo vệ control plane.

---

💡 Ví dụ thực tế:
Một doanh nghiệp triển khai Webex Meeting trên toàn công ty. Trong lúc họp, một user vô tình chạy download tool P2P saturate uplink access → distribution. Nếu có QoS:

• Webex (DSCP AF41/EF) vẫn được ưu tiên.
• P2P traffic bị police/shape hoặc đẩy vào hàng best-effort.
• Cuộc họp vẫn mượt, không ai biết là uplink đã nghẽn.

---

✅ Content Review Question:
Câu nào là guideline chung khi triển khai campus QoS?

• ❌ Police unwanted traffic flows as close to their destinations as possible.
• ❌ Classification/marking nên làm ở core layer.
• ❌ Luôn dùng NBAR vì tất cả Catalyst đều hỗ trợ (sai).
• ✅ Classify and mark applications as close to their sources as technically and administratively feasible.