Capability

WAN/LAN Dual-Path DC Monitoring

Each DC's external and internal network paths monitored independently — partial reachability is a recognized state, not a binary.

Classic GSLB asks: "Is the data center reachable?" One answer. TR7 GTM asks two: "Is it reachable from the WAN?" and "Is it reachable from the LAN?" — and lets failover policy use both answers independently. Production networks make this matter constantly. A DC's external internet link goes down but its private MPLS link to other DCs stays up: external users should fail over, but internal cross-DC services should continue. A DC's LAN/private network is down but its WAN is up: external traffic should keep flowing while internal failover triggers. A DC's WAN link is up but only reaches partial peering: the DC is reachable, but not from every direction. TR7 GTM data-center definitions carry two independent access lists: `wanAccess[]` for external network paths and `lanAccess[]` for internal/private network paths. Each list holds multiple endpoints (IP, port, V-Device, route table) so a DC has multiple WAN entry points and multiple LAN entry points. Each endpoint is monitored independently. Failover scenarios consume the resulting reachability flags as separate signals. The result: failover policy reflects the actual topology. WAN-only failure, LAN-only failure, partial reachability and full outage are four distinct states with four distinct policy responses — not collapsed into a single binary.

2 paths

WAN and LAN access lists per DC, monitored independently

N endpoints

Each path holds multiple endpoints — redundant transit captured natively

4 states

Full-up, WAN-only, LAN-only, full-down — each a distinct policy input

Per-DC

Health thresholds tuned independently per data center

Single-link reachability hides asymmetric failures that real networks produce.

The classic GSLB model treats each data center as a single entity with a single reachability state. Either the DC is up, or it is down. Most enterprise networks are built differently: external internet links, private MPLS or VPN links, dedicated cross-DC peering, partner network connections — each carries its own outage patterns and its own routing policy.

When an external transit provider fails but the private MPLS stays up, the binary view says "DC is down" — but cross-DC internal traffic should still flow. When the private link is congested but the public link is healthy, the binary view says "DC is up" — but internal latency-sensitive services are degrading. Single-link health checks cannot distinguish these states, and operators are forced to choose between false positives and false negatives.

The right answer is multi-path reachability: monitor each network's entry points independently and let policy consume the separate signals. TR7 GTM data-center definitions are dual-path natively: WAN access points and LAN access points are independent lists, each monitored separately, each contributing distinct flags to failover decisions.

Our approach

Each TR7 GTM data center is defined with two independent access lists — one for WAN endpoints, one for LAN endpoints. Each list holds multiple addresses with full network context.

wanAccess list — external network reachability

Each WAN access entry carries IP, port, V-Device assignment and route table. Multiple WAN entries per DC capture redundant external paths (primary transit, secondary transit, partner peering).

lanAccess list — internal/private network reachability

Each LAN access entry mirrors the WAN structure with private network context. Multiple LAN entries capture MPLS links, VPN tunnels, dedicated cross-DC fiber and other private paths.

Partial reachability as a recognized state

When some WAN entries are unreachable but LAN entries are healthy (or vice versa), the DC is in a partial state. Operator-defined scenarios consume the partial state as a distinct signal — failover policy is not forced into binary up/down.

Per-entry V-Device and route table context

Each access entry is bound to a specific V-Device and route table. This lets a single TR7 deployment monitor DCs across multiple network segments — internal-only DCs, DMZ DCs, partner-connected DCs — without collapsing them into one routing context.

Capabilities

Dual-path monitoring is built into the data-center model and consumed throughout the scenario, trigger and DNS-record decision logic.

Multiple WAN access endpoints per DC

wanAccess is an array — each entry is a full network address (IP, port, V-Device, route table). A DC with two external transit providers has two WAN entries; if one fails, the DC is partially WAN-reachable but not completely WAN-down.

Multiple LAN access endpoints per DC

lanAccess mirrors the WAN list with private-network entries. A DC with MPLS plus a dedicated peering link has two LAN entries. Internal cross-DC traffic uses the LAN path; LAN reachability is monitored independently of WAN.

Per-endpoint health probing

Each WAN and LAN endpoint is monitored independently. The DC's status is the composite of all per-endpoint health states, exposed as separate signals (any-WAN-up, all-WAN-up, any-LAN-up, all-LAN-up, internet-reachable).

Auto-generated DC pair scenarios use both paths

When TR7 GTM auto-generates failover scenarios for a DC pair, the generated condition expressions combine WAN-reachability, LAN-reachability and internet-reachability signals. Operators do not write the logic; the platform composes it from the dual-path inputs.

Manual scenarios can reference WAN/LAN flags directly

Custom scenarios reference the per-DC reachability flags by ID. An expression like "DC-B WAN is down AND DC-B LAN is up" picks out the exact partial state the operator wants to act on.

Access period, required-success and required-failure thresholds

Each DC carries operator-tunable health-check parameters: how often to probe each access point, how many successive successes are required to mark up, and how many failures to mark down. The same threshold values apply to WAN and LAN; per-endpoint customization happens via the V-Device and route table assignments.

V-Device segmentation enforces separation

WAN and LAN endpoints can sit in different V-Devices and different route tables. This prevents accidental cross-network probe leakage — internal-only monitoring never traverses external transit, and external monitoring never traverses internal MPLS.

Dashboard surfaces partial states explicitly

Operators see each DC's WAN endpoints and LAN endpoints separately on the dashboard. Partial reachability appears as "3 of 4 WAN endpoints healthy" — not as a single up/down flag.

Scenario triggers receive dual-path payload

When a scenario fires triggers, the trigger payload includes the current reachability state of each WAN and LAN endpoint. Downstream systems (SIEM, incident management) receive structured topology context for the failover event.

Independent failover thresholds for WAN-only vs LAN-only outages

Operators define separate scenarios for WAN-only outages and LAN-only outages. A WAN failure may trigger DNS-level external failover; a LAN failure may trigger internal route-table changes via the trigger system. Two distinct response paths from two distinct signal classes.

Operational depth

Dual-path monitoring works with V-Devices, route tables, scenario condition expressions, and trigger payload composition.

Endpoint health composition

Each access endpoint's health is determined by a configurable probe (TCP, HTTP, HTTPS, ICMP, DNS, etc.). The composite WAN-reachable flag for the DC is true if any (or all, per operator policy) WAN endpoints are healthy. The same composition applies to LAN.

Internet reachability signal

A separate internet-reachability flag is computed from external probe results. This flag is independent of any specific WAN endpoint and is used in auto-generated scenarios to detect total external isolation.

V-Device and route table binding

Each access entry's V-Device + route table assignment determines which network context the probe runs in. Probes for LAN endpoints traverse internal infrastructure; probes for WAN endpoints traverse external infrastructure. The platform enforces this separation.

Threshold tuning per DC

accessPeriod, requiredSuccess, requiredFailure are defined per DC. A high-stakes DC may use a 30-second probe with 2-success/1-failure thresholds for fast failover; a less critical DC may use 5-minute probes with 3-success/3-failure for stability.

Composite condition syntax in scenarios

Conditions reference reachability signals by ID: `|wanAccess`, `|lanAccess`, `|access`, `|internet`. The `!` suffix negates. Combined-condition groups join with AND/OR for expressive multi-path logic.

Trigger payload structure

When a scenario fires triggers, the payload carries each DC's current reachability state: WAN endpoint count, LAN endpoint count, healthy endpoint counts, last probe times. Incident management systems receive structured context for the failover event.

When to use it

External transit outage with internal MPLS intact

External transit provider fails. WAN-reachable flag for the affected DC drops; LAN-reachable stays up. External users fail over via DNS; cross-DC internal traffic continues over MPLS without disruption.

Internal/private network outage with external link healthy

MPLS link to the DC fails. LAN-reachable drops; WAN-reachable stays up. External users continue to reach the DC; internal services route around the DC via alternative paths triggered by the LAN-failure scenario.

Government / regulated networks with strict path separation

Regulated environments (government, defense, finance) often mandate strict separation between public and private network paths. TR7's dual-path monitoring expresses this separation natively — each path has its own probes, its own thresholds and its own policy response.

Multi-transit redundancy with per-link visibility

DCs with two or three transit providers see each provider's reachability separately. A single transit going down does not flag the DC as WAN-down — only its specific endpoint becomes unreachable, and operators see exactly which transit failed.

Frequently asked questions

Why is this different from running two separate health checks?

Two separate health checks give you two separate signals, but they are not coupled to a DC identity. Dual-path monitoring binds both signals to the same DC entity, so failover scenarios reference "DC-A's WAN is down" rather than "check-37 is down." The semantic mapping to the data center, the V-Device, and the route table is preserved, and the dashboard shows the DC's full path picture in one view.

Can a DC have only WAN access or only LAN access?

Yes. An internet-facing DC with no internal MPLS would have an empty lanAccess list; an internal-only DC with no external transit would have an empty wanAccess list. The dual-path model accommodates DCs with asymmetric connectivity without forcing operators to invent synthetic endpoints.

How does this interact with split-horizon DNS?

Dual-path monitoring is independent of split-horizon DNS but composes well with it. Split-horizon serves different DNS answers to internal versus external clients; dual-path monitoring decides whether the DC is reachable from each side. Together, internal clients can be told to go to LAN-reachable DCs while external clients are told to go to WAN-reachable DCs.

What if the WAN and LAN have different latencies?

Latency is captured by the client-source signals in multi-source DC selection. WAN/LAN reachability is a separate dimension: it tells you which paths are available, not which is fastest. Combine WAN/LAN reachability (eligibility) with client-source latency (preference) for full path-aware selection.

Are the WAN and LAN probe schedules the same?

By default, yes — both inherit the DC's accessPeriod, requiredSuccess and requiredFailure thresholds. Operators can override per V-Device and route table if the WAN path requires faster probing than the LAN path (or vice versa).

Stop collapsing real-network topology into a single up/down flag.

Walk through dual-path DC monitoring on your own topology: WAN transit outages, MPLS-only DCs, partial reachability — all as recognized states, not edge cases.