1/2
Network->static routes-validity

xonivre Lv1  Posted 2026-Sep-24 09:25

Hello Sangfor Support Team,

I have a problem with my Sangfor NSF-1100A-I regarding the Network → Static Routes configuration.

When I check the Validity status of my default routes, both ISP1-ether1 and ISP2-ether2 are showing “Invalid.”

I am concerned because I experience an internet interruption almost every morning at around 8:00 AM. During the incident, all internet users lose internet connectivity for approximately 3 minutes, and then the connection automatically returns to normal.

During the time of the disconnection, I checked Network → Policy Base Routes, and I noticed that the Link State for both ISP1 and ISP2 was showing “Fault.”

My questions are:

Does the “Invalid” status under Network → Static Routes → Validity indicate a problem with my default routes?
Could the Invalid route status be related to the internet disconnection that occurs every morning?
What could cause both ISP1 and ISP2 to show “Fault” under Policy Base Routes → Link State at the same time?
Is there a specific WAN link detection, reliability detection, PBR, or health-check configuration that I should verify?
Could an issue or instability on ISP2 (ether2) cause the Sangfor device to temporarily mark both WAN links as Fault/Invalid?
What logs or diagnostic information should I collect around 8:00 AM to identify the root cause?

As an additional observation, when I physically disconnect ISP2 (ether2), ISP1 is able to become Valid and the network becomes stable. This makes me suspect that there may be an interaction between the ISP2 link status and the Sangfor WAN/PBR detection.

For reference, my current default-route configuration is:

ISP1 / ether1
Destination: 0.0.0.0/0
Gateway: 203.17.xx.xx
Administrative Distance: 1
ISP2 / ether2
Destination: 0.0.0.0/0
Administrative Distance: 2

Even after changing ISP2's Administrative Distance from 1 to 2, its Validity status remains Invalid.

Could you please advise what is causing the routes to show Invalid and whether this is related to the approximately 3-minute internet interruption every morning?

Thank you.

By solving this question, you may help 1022 user(s).

Posting a reply earns you 2 coins. An accepted reply earns you 20 coins and another 10 coins for replying within 10 minutes. (Expired) What is Coin?

Enter your mobile phone number and company name for better service. Go

Muhammad Abid Lv3  Posted 2026-Sep-24 12:07
  
es. Based on your symptoms, I would not assume that “Invalid” simply means the static-route configuration is wrong. The important clue is that both WANs show Fault at the same time, and when you physically disconnect ISP2, ISP1 becomes Valid and stable.

What your symptoms suggest

Your configuration is essentially:

WAN        Default Route        Distance        Status
ISP1 / ether1        0.0.0.0/0 via gateway        1        Invalid during issue
ISP2 / ether2        0.0.0.0/0        2        Invalid
PBR        ISP1 + ISP2        —        Both Fault during issue

Changing ISP2's Administrative Distance from 1 → 2 only changes route preference. It does not fix a WAN link that Sangfor's detection mechanism considers faulty.

Most important thing to check

I would investigate WAN link detection / reliability detection and PBR health checking first, rather than changing Administrative Distance again.

Check:

Network → WAN / Interface configuration
ISP1 and ISP2 physical/link status
Gateway reachability
WAN link detection/reliability detection
Detection method and detection targets
Detection interval/timeout/failure threshold
Network → Policy Base Routes
Open the ISP1 and ISP2 PBR rules.
Check whether Link State Detection / Reliability Detection / Health Check is enabled.
Check what IPs/domains are being used as detection targets.
Check whether both WANs use the same detection target.
Static Routes
Check why Sangfor considers each next-hop route invalid.
For ISP1, verify that 203.17.xx.xx is actually reachable through ether1.
For ISP2, verify its gateway and subnet configuration.
Why both WANs can show Fault

This is particularly important.

If Sangfor's WAN reliability detection is configured to test a common destination—for example, a specific public IP—and that destination becomes unreachable, both WANs can potentially be marked Fault even though the physical ISP links are still up.

Other possibilities include:

ISP2 gateway instability
Incorrect/overlapping WAN subnet or gateway configuration
ARP instability
Duplicate IP/MAC
PBR health-check failure
DNS-based detection failure
Sangfor WAN reliability detection incorrectly configured
Physical switch/VLAN issue affecting the WAN interfaces
ISP2 sending unexpected routing/ARP information
Firmware/software issue
A common upstream failure affecting both ISPs
Incorrect PBR rules causing the health-check traffic to leave through the wrong WAN
Your ISP2 observation is very significant

You said:

When I physically disconnect ISP2 (ether2), ISP1 becomes Valid and the network becomes stable.

I would not conclude yet that ISP2 is definitely defective. But this is strong evidence that you should investigate the interaction between ether2 and Sangfor's WAN/PBR detection.

For example, if ether2 is intermittently generating an ARP/gateway/routing condition that causes Sangfor's detection logic to fail, removing ether2 would eliminate the condition and allow ether1 to become the active valid route.

One test I would perform

During a maintenance window, temporarily configure the system with:

ISP1 only → no ISP2 PBR/default route

Then monitor it through the normal 08:00 AM period.

If the 3-minute interruption disappears, reconnect ISP2 and investigate its:

gateway reachability
ARP
link detection
PBR health check
VLAN/switch port
route validity

Don't repeatedly change Administrative Distance as the primary troubleshooting method.

What to collect exactly at 08:00

Before changing anything, enable/collect logs and capture the status during the incident:

1. Network → Static Routes

Screenshot of both default routes
Validity status
Gateway
Interface
Administrative Distance

2. Network → Policy Base Routes

ISP1 Link State
ISP2 Link State
PBR rules
Reliability/health-check status

3. WAN interfaces

ether1 status
ether2 status
IP/subnet
gateway
negotiated speed/duplex
packet errors/drops if available

4. Ping tests during the failure

From Sangfor itself, test:

ISP1 gateway
ISP2 gateway
8.8.8.8
1.1.1.1

The distinction is important:
WAN gateway = reachable
8.8.8.8 = unreachable

suggests an upstream/ISP problem.

Whereas:
WAN gateway = unreachable
points much more toward a local WAN/VLAN/ARP/interface problem.

One thing I would specifically check Because both links become Fault, check whether both PBR health checks are testing the same destination.

For example:
ISP1 → Health Check → X.X.X.X
ISP2 → Health Check → X.X.X.X

If that common target fails, Sangfor may mark both links faulty.

Also verify that the health-check traffic for ISP1 actually exits ISP1, and ISP2 traffic exits ISP2. A PBR/route interaction can otherwise produce misleading results.

My current assessment
Based on what you've described, I would investigate in this order:
1. ISP2 gateway/ARP stability
2. WAN Reliability Detection / Health Check
3. PBR Link State detection
4. ISP1/ISP2 gateway reachability during 08:00
5. VLAN/switch configuration connected to ether1/ether2
6. Sangfor firmware/software logs

The Invalid route status is a symptom worth investigating, but the more useful clue is both PBR links becoming Fault simultaneously.

If you send me screenshots of Network → Static Routes, Network → Policy Base Routes, and the WAN/ether1 + ether2 configuration pages, I can go through them and tell you exactly which setting is likely causing the 3-minute 08:00 outage.

I Can Help:

Change

Moderator on This Board

1
157
3

Started Topics

Followers

Follow

1139
247
101

Started Topics

Followers

Follow

Board Leaders