ECMP, Link Monitor & Dead Gateway Detection trên FortiGate

1. Liên hệ thực tế

Nối tiếp bài trước, anh Nam đã đặt 2 static route default cùng distance để hai đường FPT và Viettel chia tải với nhau (ECMP). Vài ngày sau, đường FPT bị đứt cáp quang giữa đường — nhưng FortiGate không hề hay biết, route qua FPT vẫn nằm trong routing table, vẫn được chọn cho khoảng một nửa traffic (theo cơ chế chia tải), khiến một nửa người dùng trong văn phòng mất mạng suốt 2 tiếng đồng hồ trước khi có người phát hiện.

Chị Lan chỉ ra vấn đề: "Route tĩnh trên FortiGate không tự biết gateway phía sau có còn sống hay không — chỉ cần cổng vật lý (interface) còn 'up' là route vẫn coi là hợp lệ, dù đường truyền phía sau đã chết. Anh cần thêm Link Monitor để chủ động ping thử một server thật xuyên qua từng đường, phát hiện đường nào chết thì tự động gỡ khỏi routing table."

Bài này giải thích cơ chế ECMP (chia tải khi có nhiều route ngang nhau), và hai công cụ giám sát tình trạng đường truyền: Link Monitor và Dead Gateway Detection (DGD) — nền tảng bắt buộc để failover hoạt động đúng nghĩa.

2. Kiến thức cốt lõi

2.1 ECMP là gì

Equal Cost Multi-Path (ECMP) là cơ chế cho phép FortiGate chia tải traffic trên nhiều gateway/route có cùng "chi phí" (cost) tới cùng một đích. Điều kiện để các route tham gia ECMP:

• Cùng đích (destination) và cùng cost — với static route, cost tính gồm cả distance và priority.
• Route đến từ cùng một nguồn giao thức (cùng là static, hoặc cùng OSPF, hoặc cùng BGP).

⚠️ Lưu ý: ECMP chỉ được xét sau khi Policy Route (router policy) đã kiểm tra và không có entry nào khớp — giống như routing table thông thường, ECMP luôn nằm sau Policy Route trong thứ tự xử lý.

2.2 Ba chế độ load-balance của ECMP

config system settings
    set ecmp-max-paths 2
end

config system global
    set load-balance-mode source-ip-based
end

• source-ip-based (mặc định) — chọn đường theo băm địa chỉ IP nguồn, đảm bảo cùng một client luôn đi qua đúng một đường cố định trong suốt phiên làm việc.
• weight-based — chia tải theo tỉ lệ phần trăm định sẵn giữa các route (ví dụ 80/20).
• source-dest-ip-based — băm theo cặp IP nguồn-đích, phù hợp khi số lượng client ít nhưng số điểm đến đa dạng, giúp phân tải mịn hơn source-ip-based thuần túy.

⚠️ Lưu ý: Vì ECMP có thể khiến traffic của cùng một session đi ra và vào FortiGate qua hai interface khác nhau, cần đặc biệt chú ý cấu hình liên quan tới auxiliary session và bảng session theo interface — nếu không, một số traffic TCP có thể bị chặn nhầm do FortiGate không định danh được traffic trả về thuộc phiên nào.

2.3 Link Monitor — chủ động dò sống một đường truyền

Route tĩnh mặc định chỉ dựa vào trạng thái "up/down" của interface vật lý — nếu cáp quang đứt giữa đường (ISP), interface WAN vẫn "up" bình thường, khiến FortiGate không hề biết đường truyền thực tế đã chết. Link Monitor giải quyết vấn đề này bằng cách chủ động gửi tín hiệu dò (ping, TCP-echo...) qua chính đường truyền đó tới một server thật ở xa.

Cấu hình Link Monitor cơ bản với một server đích:

config system link-monitor
    edit "monitor-fpt"
        set srcintf "wan1"
        set server-config individual
        set gateway-ip 203.0.113.1
        set failtime 3
        config server-list
            edit 1
                set dst "8.8.8.8"
                set weight 50
            next
        end
    next
end

• failtime — số lần dò liên tiếp thất bại trước khi coi link là "dead" (giảm rủi ro báo động giả do mất gói tạm thời).
• Có thể khai báo nhiều server trong server-list, mỗi server một weight — chỉ khi tổng weight của các server đã chết vượt ngưỡng fail-weight thì Link Monitor mới báo toàn bộ link là dead, giúp tránh trường hợp một server đơn lẻ bị lỗi làm ngắt kết nối oan.

Ví dụ minh họa cách fail-weight hoạt động với 3 server giám sát cùng lúc:

config system link-monitor
    edit "monitor-wan1"
        set srcintf "wan1"
        set server-config individual
        set gateway-ip 203.0.113.1
        set failtime 3
        set fail-weight 100
        config server-list
            edit 1
                set dst "8.8.8.8"
                set weight 50
            next
            edit 2
                set dst "1.1.1.1"
                set weight 50
            next
            edit 3
                set dst "9.9.9.9"
                set weight 50
            next
        end
    next
end

Với cấu hình trên, tổng weight của cả 3 server cộng lại là 150, và fail-weight đặt là 100 — nghĩa là:

• Chỉ 1 trong 3 server chết (mất 50/150) → chưa đạt ngưỡng 100 → Link Monitor vẫn coi wan1 còn sống, không gỡ route.
• 2 trong 3 server cùng chết (mất 100/150) → đạt đúng ngưỡng 100 → Link Monitor báo wan1 dead, gỡ route khỏi routing table.

Nhờ vậy, nếu chỉ một server đích (ví dụ 8.8.8.8) tạm thời không phản hồi do sự cố phía server đó — không phải do đường truyền wan1 thực sự chết — hệ thống vẫn không kích hoạt failover nhầm. Chỉ khi đa số server giám sát cùng lúc không phản hồi mới coi là dấu hiệu đáng tin cậy rằng bản thân đường truyền đã có vấn đề.

⚠️ Lưu ý: Nếu không khai báo fail-weight tường minh, giá trị mặc định thường được tính bằng tổng weight của toàn bộ server trong danh sách — tức là mọi server đều phải chết hết thì Link Monitor mới báo dead. Với môi trường cần độ nhạy cao hơn (chỉ cần đa số server chết là đã đáng lo ngại), nên chủ động đặt fail-weight thấp hơn tổng weight tối đa.

2.4 Dead Gateway Detection (DGD) — biến thể áp trực tiếp cho gateway

Dead Gateway Detection hoạt động theo nguyên lý tương tự Link Monitor, nhưng áp dụng trực tiếp cho gateway của một interface cụ thể mà không cần khai báo route riêng — thường dùng khi chỉ cần theo dõi đúng một gateway mặc định thay vì thiết lập cơ chế giám sát phức tạp với nhiều server.

⚠️ Lưu ý: Trên các bản FortiOS gần đây, phần lớn nhu cầu giám sát đường truyền cho kịch bản nhiều-ISP hiện được khuyến khích triển khai qua SD-WAN Performance SLA (health-check trong config system sdwan) thay vì Link Monitor/DGD độc lập — SD-WAN cung cấp thêm khả năng đo latency/jitter/packet loss chi tiết hơn, không chỉ đơn thuần sống/chết. Link Monitor và DGD vẫn hữu ích cho các thiết kế đơn giản không cần đến toàn bộ tính năng SD-WAN.

2.5 Kết hợp Distance + Link Monitor để có failover thực sự

Quay lại tình huống đầu bài — để có failover đúng nghĩa (không phải chia tải ECMP), kết hợp distance khác nhau với Link Monitor giám sát đường chính:

config router static
    edit 1
        set dst 0.0.0.0 0.0.0.0
        set gateway 203.0.113.1
        set device "wan1"
        set distance 10
    next
    edit 2
        set dst 0.0.0.0 0.0.0.0
        set gateway 198.51.100.1
        set device "wan2"
        set distance 20
    next
end

config system link-monitor
    edit "monitor-wan1"
        set srcintf "wan1"
        set server-config individual
        set gateway-ip 203.0.113.1
        set failtime 3
        config server-list
            edit 1
                set dst "8.8.8.8"
                set weight 100
            next
        end
    next
end

Khi Link Monitor phát hiện wan1 chết, route tương ứng bị gỡ khỏi routing table — lúc này route qua wan2 (distance 20) trở thành lựa chọn duy nhất còn lại và được nạp vào forwarding table, traffic tự động chuyển sang đường dự phòng mà không cần can thiệp thủ công.

3. Hỏi & Đáp

ECMP và SD-WAN có phải cùng một thứ không? 

Không hoàn toàn — ECMP là cơ chế chia tải cấp thấp dựa trên routing table khi các route có cùng cost. SD-WAN là lớp tính năng cao hơn, dùng logic riêng (Performance SLA, rule-based) để quyết định traffic đi đường nào dựa trên chất lượng đường truyền thực tế, không chỉ đơn thuần chia đều theo băm IP như ECMP truyền thống.

Tại sao chỉ dựa vào trạng thái "up/down" của interface là không đủ để phát hiện mất kết nối Internet? 

Vì interface WAN có thể vẫn "up" về mặt vật lý (cáp còn cắm, cổng vẫn nhận tín hiệu từ modem/router ISP) trong khi đường truyền phía sau (tới Internet thực sự) đã chết — ví dụ sự cố ở phía nhà mạng. Chỉ có cơ chế chủ động dò như Link Monitor mới phát hiện được tình huống này.

Nếu chỉ có 1 đường Internet duy nhất, có cần cấu hình Link Monitor không? 

Vẫn có giá trị — dù không có đường dự phòng để failover, Link Monitor giúp phát hiện sớm khi đường truyền có vấn đề (kết hợp với SNMP trap hoặc email alert), thay vì đợi người dùng báo mất mạng mới biết.

failtime đặt quá thấp (ví dụ 1) có rủi ro gì? 

Dễ gây báo động giả (false positive) — chỉ cần mất một gói ping do nghẽn mạng tạm thời cũng khiến Link Monitor coi là "dead" và kích hoạt failover không cần thiết, gây gián đoạn không đáng có. Nên đặt failtime đủ lớn (thường 3–5) để lọc bớt nhiễu tạm thời, cân bằng giữa phát hiện nhanh và tránh nhạy cảm quá mức.

4. Quiz

Câu 1: Điều kiện nào KHÔNG cần thiết để hai route tham gia ECMP với nhau?

• A. Cùng đích (destination)
• B. Cùng cost (distance + priority)
• C. Cùng loại giao thức nguồn (cùng static, hoặc cùng OSPF...)
• D. Cùng interface vật lý

Câu 2: Chế độ ECMP nào đảm bảo một client cố định luôn đi qua đúng một đường trong suốt phiên làm việc?

• A. weight-based
• B. source-ip-based
• C. usage-based
• D. random

Câu 3: Vì sao chỉ dựa vào trạng thái "up" của interface WAN là chưa đủ để xác nhận đường Internet còn sống?

• A. Interface WAN luôn báo "down" khi mất Internet
• B. Interface có thể vẫn "up" vật lý dù đường truyền phía sau (ISP) đã chết
• C. FortiOS không hỗ trợ kiểm tra trạng thái interface
• D. Không có sự khác biệt nào giữa hai điều này

Câu 4: Tham số nào trong Link Monitor giúp tránh báo động giả do mất gói tạm thời?

• A. weight
• B. gateway-ip
• C. failtime
• D. srcintf

Câu 5: Khi Link Monitor phát hiện một đường "dead", điều gì xảy ra với route static tương ứng?

• A. Route vẫn giữ nguyên trong routing table, không có gì thay đổi
• B. Route bị gỡ khỏi routing table, cho phép route dự phòng distance cao hơn được nạp vào forwarding table
• C. FortiGate tự động khởi động lại
• D. Toàn bộ Firewall Policy bị vô hiệu hóa

👉 Đáp án

Câu 1: D — ECMP không yêu cầu các route phải cùng interface vật lý; điều kiện là cùng đích, cùng cost, và cùng nguồn giao thức, có thể qua các interface khác nhau. 

Câu 2: B — source-ip-based (mặc định) băm theo IP nguồn, đảm bảo một client luôn đi qua đúng một đường cố định trong suốt phiên. 

Câu 3: B — Interface WAN có thể vẫn "up" về mặt vật lý dù đường truyền thực tế phía sau (tới ISP/Internet) đã gặp sự cố, nên cần cơ chế dò chủ động như Link Monitor. 

Câu 4: C — failtime quy định số lần dò liên tiếp thất bại trước khi coi link là "dead", giúp lọc bớt nhiễu tạm thời và tránh báo động giả. 

Câu 5: B — Khi Link Monitor báo link dead, route static qua interface đó bị gỡ khỏi routing table, cho phép route dự phòng có distance cao hơn được nạp vào forwarding table để tiếp tục định tuyến traffic.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng