Skip to main content

SecuraWall.com

Email security and continuity

Explore
Technical Guide · Network & Infrastructure

What Is SD-WAN? Multi-Site Networking Guide

SD-WAN manages multiple WAN links using centralized policy, application awareness and dynamic path selection.

LAST TECHNICAL REVIEW:
Network & Infrastructure

Why This Topic Matters

SD-WAN manages multiple WAN links using centralized policy, application awareness and dynamic path selection.

Key Decision Points

Define SLAs using latency, loss and jitter.

Plan Internet breakout security separately.

Separate underlay and overlay responsibilities.

Test failover with real link outages.

Architecture and operating model

SD-WAN applies application and path policies over underlay links. Link-up status does not prove quality; loss, jitter and latency can influence selection. Assess overlay reachability, NAT, tunnel MTU and controller dependencies. Shared carriers or physical routes may retain common failures.

  1. 1Underlay links
  2. 2Quality measurement
  3. 3Application/path policy
  4. 4Overlay and destination service
Test degraded quality and restoration stability as well as outright link failure.

Design parameters

Path quality
Tie latency, loss and jitter to application targets; an established tunnel does not imply a good path.
Underlay independence
Two carriers may share a route or termination point; verify failure independence.
Addressing and routing
Show subnet, gateway, routes and NAT scope separately. Validate DNS results alongside the actual path to the target IP.
Redundant path
Check that alternate paths do not share device, power or carrier failures. Measure transition time through the application.
Transport capacity
Evaluate port speed, uplink utilization, packet loss and queues together. One test flow may not represent total capacity.
Operational visibility
Monitor interface counters, adjacencies, error records and time synchronization. Maintain a normal-operation baseline.

Worked example

Test complete failure and degraded quality separately at a two-link branch. Evaluate voice moving to a better path while backup follows its intended policy. Measure existing-session effects from IP/NAT changes and oscillation during restoration.

Troubleshooting

ObservationLikely cause / distinctionVerification
Failover occurs but sessions dropNAT, source address or application state may change.Measure active-session behavior and new transaction results during link loss.
Local VLAN works, remote network failsGateway, routing, ACL or return-path issues may be involved.Compare addressing, routes and policy records at both ends.
Small requests work, large transfers stallMTU, packet loss and destination storage waits are possible distinctions.Measure packet sizes and retransmissions; distinguish networking from storage waits.
Backup path exists but interruption is longDetection, convergence, DNS or session renewal can extend interruption.Record failure time and the first successful application operation using synchronized clocks.

Acceptance checks

  1. Test degraded quality and restoration stability as well as outright link failure.
  2. Test an access matrix covering allowed and denied network pairs.
  3. Exercise individual link and device failures separately.
  4. Record loss, latency and queue counters under peak load.
  5. Retain pre-change configuration and rollback steps.
  6. Verify appropriate separation of management access from user networks.

Related concepts

Layer 2 and Layer 3 boundaries

A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.

MTU along the path

MTU concerns packet size on a link; tunnelling and encapsulation headers can reduce space available for useful payload. Small requests working while large transfers stall may suggest an MTU issue, but this is not proof. TCP MSS and interface MTU are distinct. Compare both endpoints and tunnel interfaces. Identify the affected segment with controlled tests instead of changing every device, and remember that blocked ICMP error messages can complicate path-MTU discovery.

DNS caching and dependencies

DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.

Latency distribution

Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.

Bandwidth and useful throughput

Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.

Telemetry and time correlation

Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.

Primary documentation

Who · How · Why

How This Content Was Prepared

WHO?

Doz Teknoloji Technical Team

This content is based on the technical evaluation approach used across Doz Teknoloji's enterprise IT practice areas.

HOW?

Technical criteria + primary sources

The topic was cross-checked against vendor documentation, publications from standards bodies and other relevant official technical sources.

WHY?

Improve decision quality

This guide explains the technical term and the criteria to consider when making purchasing, architecture or operational decisions.

LAST TECHNICAL REVIEW

PRIMARY / OFFICIAL SOURCES

Related Enterprise Solutions

Explore the related service and solution pages to plan implementation.

Let's Evaluate Your Technical Requirement

Share your current infrastructure, user count or technical objective and we can help clarify product, licensing or project scope.

Send a Technical Request
Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!