admin 08/01/2026

SD-WAN nâng cao trên FortiGate - App rules, ưu tiên traffic và load-balance

Fortigate NAMHI | Giai đoạn 3 | Bài 15

⚙️ SD-WAN nâng cao trên FortiGate – App rules, ưu tiên traffic và load-balance

Bài 14 đã giúp dựng SD-WAN cơ bản (members + SLA + rules). Sang Bài 15, sẽ giúp doanh nghiệp “cảm nhận được”: Teams/VoIP mượt hơn, ERP ổn định hơn, và traffic “nặng” không làm nghẹt đường của dịch vụ quan trọng. Điểm mấu chốt: viết rule theo nhóm dịch vụ + đặt SLA theo mục tiêu + thêm QoS/traffic shaping tối thiểu để giữ trải nghiệm.

⏱️ 60–90 phút🎯 Level: Nâng cao (vận hành thực tế)🧰 Dành cho: IT triển khai / IT vận hành

⬅️ Bài 14: SD-WAN cơ bản ➡️ Đi tới Bài 16 (Publish dịch vụ đa WAN)

🧭 Tư duy khi làm SD-WAN nâng cao

SD-WAN nâng cao không phải “càng nhiều rule càng tốt”. Cần ưu tiên: ít rule nhưng trúng mục tiêu, chia theo nhóm dịch vụ mà khách hiểu được và IT dễ vận hành.

✅ 3 nhóm rule tiêu chuẩn

🎙️ Meeting/VoIP (nhạy jitter)
🏢 ERP/SaaS (cần ổn định, ít “nhảy”)
🌍 Default Internet (web, browsing, update)

✅ 3 thành phần bắt buộc

Health-check/SLA đúng mục tiêu
Rule đúng thứ tự + match đúng traffic
QoS tối thiểu để traffic nặng không “đè” traffic quan trọng

⚠️ Nếu chỉ bật SD-WAN mà không có SLA/targets chuẩn + không có QoS, bạn sẽ gặp case “link xanh mà vẫn lag” hoặc “download làm nghẹt Teams”.

📋 Chuẩn bị trước khi triển khai

✅ App inventory

Danh sách dịch vụ thật

Teams/Zoom/VoIP, ERP, CRM, email cloud, camera cloud… ghi rõ “dịch vụ nào quan trọng”.

Không có inventory → rule sẽ “đoán mò”.

✅ Link characteristics

Hiểu tính chất WAN

WAN nào ổn định, WAN nào nhanh nhưng chập chờn, WAN nào CGNAT… để chọn strategy đúng.

WAN tốt cho VoIP ≠ WAN tốt cho download.

✅ Test plan

Kịch bản test

Test theo giờ cao điểm: call Teams + mở ERP + chạy download để thấy QoS/SD-WAN hoạt động.

Test đúng tình huống khách dùng.

1️⃣ Tạo nhiều Performance SLA profiles (VoIP khác Web)

Lỗi phổ biến: dùng 1 SLA cho mọi thứ. Thực tế, VoIP/Meeting nhạy với jitter và loss, còn web browsing lại “chịu được” hơn. Vì vậy nên có ít nhất 2 SLA profiles.

🎙️ SLA-VOICE (khuyến nghị)

Ưu tiên jitter/loss thấp
Targets: 2–3 điểm ổn định
Ngưỡng chặt hơn default

💡 Đặt tiêu chí “fail” sớm để Teams/VoIP chuyển link kịp thời.

🌍 SLA-WEB (mặc định)

Ưu tiên latency ổn
Targets: DNS public/cloud
Ngưỡng “dễ chịu” hơn VOICE

💡 Web chịu jitter tốt hơn VoIP, nên không cần ngưỡng quá khắt khe.

⚠️ Targets phải “phản ánh internet thật”. Tránh targets dễ chập chờn khiến SLA báo xấu giả.

2️⃣ Dùng đúng strategy: Priority, Best Quality, Load Balance

🎯 Priority

Khi cần ổn định & predictable

ERP/SaaS thường phù hợp: ưu tiên WAN1, nếu WAN1 fail SLA thì mới qua WAN2.

Ưu tiên trải nghiệm ổn định hơn “nhanh nhất”.

⚡ Best Quality

Khi cần “mượt” theo SLA

Teams/VoIP/Meeting nên dùng best quality theo SLA-VOICE, giảm jitter/loss.

Thường giúp “cảm nhận” cải thiện rõ nhất.

⚖️ Load Balance

Khi muốn tận dụng cả 2 WAN

Dùng cho web browsing/download/update… nhưng phải có QoS để không phá Meeting/ERP.

Không bật load-balance “bừa” cho ERP/VoIP.

💡 NAMHI gợi ý triển khai: VoIP/Meeting = Best Quality, ERP/SaaS = Priority, Default = Load Balance (có QoS).

3️⃣ SD-WAN Rules nâng cao – mẫu cấu trúc NAMHI (dễ vận hành)

💡 Rule càng “cụ thể” phải nằm càng “trên”. Rule default luôn nằm cuối.

Rule A

🎙️ Meeting/VoIP – Best Quality theo SLA-VOICE

Match: Application category (Collaboration/VoIP) hoặc services cụ thể
Strategy: Best Quality
Health-check: SLA-VOICE
Members: WAN1 + WAN2 (cho SD-WAN chọn link tốt)

⚠️ Nếu match application, cần bật nhận diện app đúng cách (để rule hit chính xác).

Rule B

🏢 ERP/SaaS – Priority, ít “nhảy”

Match: Destination/FQDN/IP ranges của ERP/SaaS hoặc ISDB
Strategy: Priority (WAN1 → WAN2)
Health-check: SLA-WEB hoặc SLA riêng cho ERP

💡 ERP thường không thích “đổi IP” liên tục, nên Priority ổn hơn Best Quality.

Rule C

🌍 Default Internet – Load Balance có kiểm soát

Match: all remaining traffic
Strategy: Load Balance (theo session/weight)
Health-check: SLA-WEB
Members: WAN1 + WAN2 (cân bằng tải)

⚠️ Nếu không có QoS, download có thể “đè” Meeting. Phần dưới sẽ xử lý.

4️⃣ Policy ra Internet khi dùng SD-WAN (giữ đơn giản, dễ debug)

➡️ LAN/VLAN → SD-WAN zone

Outgoing interface: SD-WAN zone
NAT: Enable
Log Allowed Traffic: (khuyến nghị) All Sessions

🔍 Debug dễ theo trình tự

Policy có hit không?
SD-WAN rule nào match?
SLA của WAN member đang xanh hay đỏ?

💡 Nếu bạn đang có nhiều policy WAN1/WAN2 từ Bài 13, hãy chuẩn hoá lại để giảm trùng lặp.

5️⃣ QoS/Traffic shaping “đủ dùng” để giữ chất lượng (phần khách cảm nhận rõ nhất)

SD-WAN chọn đường tốt là 1 chuyện. Nhưng nếu đường bị “nghẹt” vì download/update thì Teams/VoIP vẫn lag. Vì vậy NAMHI luôn đề xuất: tối thiểu phải có traffic shaping hoặc cơ chế ưu tiên cho app quan trọng.

Bước 1

Tạo traffic shaping profile (đơn giản)

Profile “MEETING-PRIORITY”: ưu tiên cao, giới hạn hợp lý
Profile “DEFAULT-LIMIT”: giới hạn download/update theo giờ làm việc (nếu cần)

💡 Không nhất thiết “siết” mạnh, chỉ cần đủ để tránh nghẽn đột biến.

Bước 2

Gắn shaping vào policy / rule phù hợp

Gắn ưu tiên cho nhóm Meeting/VoIP; gắn giới hạn nhẹ cho nhóm default/download. Nhớ: SD-WAN quyết định đường, shaping giữ trải nghiệm khi đường bị tải nặng.

Bước 3

Test thực tế: call Teams + chạy download

Đây là test “đúng đời”: nếu call vẫn ổn trong khi có tải, cấu hình đã “đạt chuẩn vận hành”.

⚠️ QoS mạnh quá sẽ làm user than “mạng chậm”. Làm theo nguyên tắc: “bảo vệ app quan trọng” chứ không “bóp” toàn bộ.

❌ Lỗi thường gặp & cách xử lý nhanh (accordion)

❌ Rule Meeting/VoIP không hit (vẫn đi default)

Match application chưa đúng (app signature/nhận diện)
Rule đặt dưới rule default
Traffic thực tế không thuộc nhóm app bạn chọn (cần refine match)

❌ SLA báo xấu “giả” khiến SD-WAN đổi link liên tục

Targets chập chờn
Threshold quá nhạy
Interval/Fail-Pass count chưa hợp lý

❌ Load balance làm một số dịch vụ bị logout

Một số dịch vụ nhạy với thay đổi IP public. Với nhóm này, chuyển sang rule Priority hoặc “pin” vào 1 WAN. Đừng cố load balance mọi thứ.

❌ Teams/VoIP vẫn lag dù đã Best Quality

Link bị nghẽn do traffic nặng: cần QoS/shaping
SLA targets không phản ánh đúng jitter/loss thực tế
WAN member “xanh” nhưng chất lượng thực tế theo giờ cao điểm xấu

💡 Luôn test giờ cao điểm: SD-WAN đẹp trên lab chưa chắc đẹp ngoài đời.

✅ Checklist bàn giao

✅ SD-WAN members: WAN1/WAN2 đúng, trạng thái ổn
✅ SLA-VOICE & SLA-WEB: targets ổn định, ngưỡng hợp lý, monitor rõ
✅ Rule thứ tự đúng: Meeting → ERP → Default
✅ Policy ra Internet dùng SD-WAN zone + bật log để debug
✅ QoS/shaping tối thiểu cho Meeting/VoIP
✅ Test 3 kịch bản: SLA xấu, đứt WAN, quay về WAN1

🧩 Kết luận

SD-WAN nâng cao giúp hệ thống “thông minh đúng chỗ”: app quan trọng đi đường tốt, app nhạy không bị traffic nặng đè. Làm đúng: SLA tách profile + rule theo nhóm dịch vụ + QoS đủ dùng → khách sẽ “cảm nhận” rõ sự khác biệt.

➡️ Bài tiếp theo