---
title: "SD-WAN and WAN testing: failover, steering, tunnels | TEST4NET"
description: "We test branch CPEs, hubs and vCPEs on impaired links: steering and failover on brownouts, QoS, IPsec throughput, tunnel scale, RFC 6349 and Y.1564 on the underlay"
image: https://test4net.com/hubfs/og/solutions-sd-wan.png
---

[Skip to content](https://test4net.com/solutions/sd-wan#main-content)

[![TEST4NET](https://test4net.com/hubfs/test4net-logo-fixed-2.svg)](https://test4net.com/?hsLang=en)

- Services
- Products
- Resources
- Company

[News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en)

What we test

By technology

Industries

[Load & Performance Testing Throughput, sessions and latency up to and past the rated limit](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing Features against the spec, RFC compliance with evidence](https://test4net.com/services/functional-conformance-testing?hsLang=en) [Interoperability Testing Multi-vendor behaviour, before it reaches production](https://test4net.com/services#interop) [Security & Resilience Testing NGFW, IPS and VPN efficacy and performance with threats on the wire](https://test4net.com/services/security-resilience-testing?hsLang=en) [Test Plan & Methodology Design What to test, how, and what counts as a pass](https://test4net.com/services/test-plan-design?hsLang=en) [Test Automation & CI/CD Regression suites wired into your release pipeline](https://test4net.com/services#automation) [Training Programs Hands-on courses for your test engineers](https://test4net.com/services#training) [Equipment Repair Diagnostics and repair of test equipment](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en)

[Routing & Switching RFC 2544 and RFC 2889 on real ports, 1G to 100G](https://test4net.com/solutions/routing-switching?hsLang=en) [Firewalls & NGFW RFC 9411 throughput with inspection switched on](https://test4net.com/solutions/firewalls-ngfw?hsLang=en) [SD-WAN & WAN Path selection and QoS under emulated WAN conditions](https://test4net.com/solutions/sd-wan?hsLang=en) [Cloud & NFV Virtual appliances and cloud services under load](https://test4net.com/solutions/cloud-nfv?hsLang=en) [5G & Mobile Core Transport and core functions under subscriber traffic](https://test4net.com/solutions/5g-mobile-core?hsLang=en) [Wi-Fi Wi-Fi 6 clients and access points, Wi-Fi 7 in progress](https://test4net.com/solutions/wi-fi?hsLang=en) [Storage & Infrastructure Storage networks and servers under realistic I/O](https://test4net.com/solutions/storage?hsLang=en) [AI / Switching Fabric (RoCEv2) Lossless Ethernet for GPU clusters: PFC, ECN, fabric load](https://test4net.com/solutions/ai-fabric-rocev2?hsLang=en) [All technologies](https://test4net.com/services#coverage)

[Telecom Operators Pre-deployment acceptance and vendor comparison](https://test4net.com/solutions/industries#telecom) [Network & Security Vendors Independent validation of your product claims](https://test4net.com/solutions/industries#vendors) [System Integrators Proof for the customer before the rollout](https://test4net.com/solutions/industries#integrators) [Enterprise & Banks Upgrades and new platforms checked before production](https://test4net.com/solutions/industries#enterprise) [All industries](https://test4net.com/solutions/industries?hsLang=en)

Not sure where to start?

Test plan and quote in 1–3 business days

Tell us what you run and what worries you. We propose the tests, tools and timeline.

[Request a test plan](https://test4net.com/contacts?hsLang=en)

CloudLAB

[How It Works Pick a scenario, run it in the live lab, get the report](https://test4net.com/cloudlab#how) [Equipment & Capabilities L2-3 to 100G, L4-7 past 200G, Wi-Fi, WAN emulation](https://test4net.com/cloudlab#equipment) [Access Plans Hourly sessions, subscriptions, dedicated racks](https://test4net.com/cloudlab/plans?hsLang=en) [Hosted DUT Testing Ship the box or upload the VM, we run the tests](https://test4net.com/cloudlab/hosted-dut?hsLang=en) [Open the CloudLAB portal](https://lab.test4net.com)

Our tools

[Traffic Generator L4-7 and security traffic past 200 Gbit/s, app mix library](https://test4net.com/products/traffic-generator?hsLang=en) [WANemu Delay, jitter, loss and bandwidth shaping per link](https://test4net.com/products/wanemu?hsLang=en) [Book a demo](https://test4net.com/contacts?hsLang=en)

New: our own test tools

Our own tools, in beta this autumn

Built in our lab, priced per gigabit. Join the beta list and see them first.

[Join the beta list](https://test4net.com/products#lead-form)

Read

Technologies / Protocols

Methodologies

[Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) [FAQ How the lab, sessions and reports work](https://test4net.com/faq?hsLang=en) [All resources](https://test4net.com/resources?hsLang=en)

[BGP Route exchange, policy and convergence](https://test4net.com/blog/how-we-test-bgp?hsLang=en) [OSPF & IS-IS IGP adjacency, flooding and SPF timing](https://test4net.com/blog/how-we-test-ospf-is-is?hsLang=en) [MPLS & SR LDP, RSVP‑TE and SR‑MPLS label paths](https://test4net.com/blog/how-we-test-mpls-and-segment-routing?hsLang=en) [EVPN / VXLAN Overlay fabrics, MAC/IP routes, multi-homing](https://test4net.com/blog/how-we-test-evpn-vxlan?hsLang=en) [IPsec & IKEv2 Tunnel setup, rekeying and throughput](https://test4net.com/blog/how-we-test-ipsec-and-ikev2?hsLang=en) [TLS / HTTPS Handshakes, cipher suites and inspection](https://test4net.com/blog/how-we-test-tls-and-https?hsLang=en) [RoCEv2 Lossless Ethernet, PFC and ECN for AI fabrics](https://test4net.com/blog/how-we-test-rocev2?hsLang=en) [Wi-Fi 6 / 6E / 7 802.11ax/be, OFDMA, MLO and roaming](https://test4net.com/blog/how-we-test-wi-fi-6-6e-7?hsLang=en) [All protocols](https://test4net.com/blog/tag/protocols?hsLang=en)

[RFC 2544 Throughput, latency, frame loss and back-to-back](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889 LAN switch benchmarking: forwarding, MAC learning, congestion](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511 Firewall and NGFW performance benchmarking](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) [RFC 6349 TCP throughput and buffer delay testing](https://test4net.com/methodologies/rfc-6349?hsLang=en) [RFC 5180 IPv6 benchmarking methodology](https://test4net.com/methodologies/rfc-5180?hsLang=en) [ITU-T Y.1564 Ethernet service activation: CIR, EIR, KPIs per service](https://test4net.com/methodologies/y-1564?hsLang=en) [ITU-T Y.1731 Ethernet OAM: delay, jitter, loss and SLA monitoring](https://test4net.com/methodologies/y-1731?hsLang=en) [TR-398 Wi-Fi in-premises performance test plan](https://test4net.com/methodologies/tr-398?hsLang=en) [All methodologies](https://test4net.com/methodologies?hsLang=en)

Read

[Case studies, test insights and lab notes Blog](https://test4net.com/blog?hsLang=en) [What is changing in network testing and infrastructure Industry News](https://test4net.com/news?hsLang=en) [How the lab, sessions and reports work FAQ](https://test4net.com/faq?hsLang=en)

[About Us Independent lab in Armenia, team and history](https://test4net.com/about?hsLang=en) [Why TEST4NET What you get that vendor slides never show](https://test4net.com/why-test4net?hsLang=en) [Lab & Certifications Bench capacity, methods and the standards we test against](https://test4net.com/lab?hsLang=en) [Partners Test tool vendors and IT partners we work with](https://test4net.com/partners?hsLang=en) [Contacts Talk to an engineer, not a sales bot](https://test4net.com/contacts?hsLang=en)

[Support portal](https://test4net.com/support?hsLang=en)

- Services
  
  What we test
  
  [Load & Performance Testing](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing](https://test4net.com/services/functional-conformance-testing?hsLang=en) [Interoperability Testing](https://test4net.com/services#interop) [Security & Resilience Testing](https://test4net.com/services/security-resilience-testing?hsLang=en) [Test Plan & Methodology Design](https://test4net.com/services/test-plan-design?hsLang=en) [Test Automation & CI/CD](https://test4net.com/services#automation) [Training Programs](https://test4net.com/services#training) [Equipment Repair](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en)
  
  By technology
  
  [Routing & Switching](https://test4net.com/solutions/routing-switching?hsLang=en) [Firewalls & NGFW](https://test4net.com/solutions/firewalls-ngfw?hsLang=en) [SD-WAN & WAN](https://test4net.com/solutions/sd-wan?hsLang=en) [Cloud & NFV](https://test4net.com/solutions/cloud-nfv?hsLang=en) [5G & Mobile Core](https://test4net.com/solutions/5g-mobile-core?hsLang=en) [Wi-Fi](https://test4net.com/solutions/wi-fi?hsLang=en) [Storage & Infrastructure](https://test4net.com/solutions/storage?hsLang=en) [AI / Switching Fabric (RoCEv2)](https://test4net.com/solutions/ai-fabric-rocev2?hsLang=en) [All technologies](https://test4net.com/services#coverage)
  
  Industries
  
  [Telecom Operators](https://test4net.com/solutions/industries#telecom) [Network & Security Vendors](https://test4net.com/solutions/industries#vendors) [System Integrators](https://test4net.com/solutions/industries#integrators) [Enterprise & Banks](https://test4net.com/solutions/industries#enterprise) [All industries](https://test4net.com/solutions/industries?hsLang=en)
  
  [Not sure where to start? Test plan and quote in 1–3 business days](https://test4net.com/contacts?hsLang=en)
- Products
  
  CloudLAB
  
  [How It Works](https://test4net.com/cloudlab#how) [Equipment & Capabilities](https://test4net.com/cloudlab#equipment) [Access Plans](https://test4net.com/cloudlab/plans?hsLang=en) [Hosted DUT Testing](https://test4net.com/cloudlab/hosted-dut?hsLang=en) [Open the CloudLAB portal](https://lab.test4net.com)
  
  Our tools
  
  [Traffic Generator](https://test4net.com/products/traffic-generator?hsLang=en) [WANemu](https://test4net.com/products/wanemu?hsLang=en) [Book a demo](https://test4net.com/contacts?hsLang=en)
  
  [New: our own test tools Our own tools, in beta this autumn](https://test4net.com/products#lead-form)
- Resources
  
  Read
  
  [Blog](https://test4net.com/blog?hsLang=en) [Industry News](https://test4net.com/news?hsLang=en) [FAQ](https://test4net.com/faq?hsLang=en) [All resources](https://test4net.com/resources?hsLang=en)
  
  Technologies / Protocols
  
  [BGP](https://test4net.com/blog/how-we-test-bgp?hsLang=en) [OSPF & IS-IS](https://test4net.com/blog/how-we-test-ospf-is-is?hsLang=en) [MPLS & SR](https://test4net.com/blog/how-we-test-mpls-and-segment-routing?hsLang=en) [EVPN / VXLAN](https://test4net.com/blog/how-we-test-evpn-vxlan?hsLang=en) [IPsec & IKEv2](https://test4net.com/blog/how-we-test-ipsec-and-ikev2?hsLang=en) [TLS / HTTPS](https://test4net.com/blog/how-we-test-tls-and-https?hsLang=en) [RoCEv2](https://test4net.com/blog/how-we-test-rocev2?hsLang=en) [Wi-Fi 6 / 6E / 7](https://test4net.com/blog/how-we-test-wi-fi-6-6e-7?hsLang=en) [All protocols](https://test4net.com/blog/tag/protocols?hsLang=en)
  
  Methodologies
  
  [RFC 2544](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) [RFC 6349](https://test4net.com/methodologies/rfc-6349?hsLang=en) [RFC 5180](https://test4net.com/methodologies/rfc-5180?hsLang=en) [ITU-T Y.1564](https://test4net.com/methodologies/y-1564?hsLang=en) [ITU-T Y.1731](https://test4net.com/methodologies/y-1731?hsLang=en) [TR-398](https://test4net.com/methodologies/tr-398?hsLang=en) [All methodologies](https://test4net.com/methodologies?hsLang=en)
  
  Read
  
  [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) [FAQ How the lab, sessions and reports work](https://test4net.com/faq?hsLang=en)
- Company
  
  [About Us](https://test4net.com/about?hsLang=en) [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en) [Lab & Certifications](https://test4net.com/lab?hsLang=en) [Partners](https://test4net.com/partners?hsLang=en) [Contacts](https://test4net.com/contacts?hsLang=en)

[News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en)

[Services](https://test4net.com/services?hsLang=en) / SD-WAN and WAN

# SD-WAN and WAN: path selection, failover and tunnel scale measured on impaired links

We test branch CPEs, hubs, cloud gateways and the underlay services behind them on the CloudLAB bench: two or three underlays per site through WAN emulators that add delay, jitter, loss and shaping per link, IPsec tunnels and application traffic from emulated branches, and the brownouts a datasheet never mentions. The report shows how fast the policy moves an application off a bad path, how many tunnels and sessions a hub holds, and what TCP really gets over the overlay.

[Request a test plan](https://test4net.com/solutions/sd-wan#lead-form) [See the device classes](https://test4net.com/solutions/sd-wan#classes)

**Voice loss on an MPLS brownout** 2 % loss and 40 ms jitter injected on the MPLS path, Internet path clean. Same policy before and after tuning 

050100 VOICE DELIVERED, % 0306090120 TIME AFTER THE BROWNOUT, S design 5 s Delivered policy · 90 s Tuned probes, day 4 · 3 s Delivered policy Tuned probes, day 4

- **1G–100G**WAN emulators per link: delay, jitter, loss, shaping
- **2–3**underlays per site, each with its own impairments
- **From 2 weeks**for a run
- **1–3 days**test plan and quote

When the number is needed

## Three moments in an SD-WAN rollout when the vendor slide stops being an answer

A slide shows a failover in one second on two clean links. Each moment below asks what the CPE does with your applications, your underlays and the half-broken path, and ends in a number the project can sign.

1. 1
   
   ### Shortlist
   
   Tender, 2–3 platforms
   
   Every candidate runs the same steering, failover, QoS and tunnel-scale cases on the same impaired links with the same emulated branches. Vendors see the plan before the first packet and get the same report.
   
   Ranked table per KPI, scale ceiling per platform, 3–4 weeks for 3 platforms
2. 2
   
   ### Acceptance
   
   Before the branches migrate
   
   The delivered CPEs and hubs with the production policy: application classes, SLA probes, thresholds, QoS, breakout rules and tunnel settings from your export. Measured against your design on the underlays you will actually buy.
   
   Signed report with pass and fail per case, policy export, from 2 weeks
3. 3
   
   ### Change
   
   Software release or policy change
   
   The acceptance cases run again on the new release, the new underlay or the new application policy. What moved, by how much, and whether the branch still clears the design. Repeatable from the same bench profile.
   
   Diff per KPI against the last run, 3 business days

What we test

## Five device classes, and the numbers each one has to show

The bench is the same, the traffic and the pass criteria are not. The table is the starting point of the plan; your application list and your underlay contracts set the thresholds.

| Device class | Numbers in the report | Traffic and config on the bench | Typical size |
| --- | --- | --- | --- |
| 01Branch CPE | IPsec throughput per packet size, steering time on loss, jitter and link down, QoS under congestion | Two or three underlays via WAN emulators, voice, video and SaaS-like flows, your policy and probes | 100 Mbps to 1 Gbps per branch, 2–3 underlays |
| 02Hub and data-center gateway | Tunnels held, new connections per second, throughput with all active, convergence on hub loss | Emulated branches with IPsec and overlay routes, traffic on every tunnel, one hub taken down live | 1–10 Gbps per hub, tunnel count from your design |
| 03Cloud gateway, vCPE | The same KPIs per instance size, throughput per core, behaviour when the host is loaded | Image on the bench hypervisor or in your tenant, the same branches and impairments as hardware | 200 Mbps to 5 Gbps per instance |
| 04Controller and orchestrator | Policy push time to all sites, re-admission after controller loss, data plane while it is down | Controller on the bench or in your tenant, emulated sites joining, policy pushes under traffic | Hundreds to thousands of sites |
| 05Underlay Ethernet or Internet service | Y.1564 per service: CIR, EIR, delay, jitter, loss; RFC 6349 TCP throughput over the path | Generator and a loopback or second unit at the far end, 15 min to 24 h runs, TCP per window size | 10 Mbps to 10 Gbps per service |

Any SD-WAN vendor, physical or virtual, including a vendor you are leaving. Named test tools are picked for the setup and listed in the report.

The bench around one branch CPE

Users voice, video, SaaS flows Generator ports RFC 2544 frames, IPsec CPE Branch CPE under test your policy, probes, QoS IPsec · 3 underlays MPLSInternetLTE WAN emulator per link delay · jitter · loss Hub, branches a tunnel per branch Controller policy push, admission BROWNOUT OR CUT ON ONE PATH steering time · app score tunnel throughput · sessions

Around the box

## What sits on each side of the CPE while it is measured

A failover number only means something with the right things around the device: the applications it will steer, the underlays it will see with their real delay and loss, and the half-broken path that production will hand it on a Tuesday afternoon

1. ### Underlays with their real behaviour
   
   Each link goes through a WAN emulator with the delay, jitter, loss and shaping of the contract or the measured path. A brownout is a change in those numbers, not a cable pulled.
2. ### Your policy, line by line
   
   Application classes, SLA probe intervals and thresholds, QoS queues, breakout and tunnel settings from your export. The report shows which line each slow move or dropped class traces back to.
3. ### Branches and failures with traffic running
   
   Emulated users behind the CPE and emulated branches behind the hub, voice and video flows scored per second, the brownout and the cut timed from the last good second to the first good second after the move

Typical scenario

## A platform rated for sub-second failover, a brownout on MPLS, and 90 seconds of broken voice

An enterprise hands over its branch platform for acceptance before 300 sites migrate. The vendor slide shows failover in under a second. With the production policy and a clean cable pull it does. With 2 % loss and 40 ms jitter on the MPLS path, the probes keep reporting the link as up and voice stays on it for 90 seconds. Tuning probe interval, loss threshold and the jitter rule brings the move to 3 seconds on day 4; the hub tunnel ceiling and the DIA breakout rules are measured on the same bench days.

90 s → 3 s

voice steering time on an MPLS brownout

91 %

of line rate for TCP over the overlay, RFC 6349

11 days

from the first packet to the signed report

Composite scenario from projects of this type. Numbers are realistic and not from one client.

Voice steering time on a brownout, s

Delivered policy Tuned probes, day 4 90 3 Design 5 0255075100 beyond the design clears the design

What you take away

## Four numbers that end the argument, and the table they live in

The report is built for the meeting after the test: the vendor, the carrier and your network team read the same table, with the pass band from the design next to the measured value per path and per application

Each number comes with its evidence: per-second application scores, tunnel and session counters from the box, emulator settings per link, captures and the policy export of the run

Steering

Time to move each application class off a path on loss, jitter and link down, and back when the path recovers, with the probe settings that produced it

Scale

Tunnels, sessions, routes and sites where the hub or the controller stops or slows, so the design has a ceiling with a margin, not a slide maximum

Throughput

IPsec throughput per direction and packet size per branch class, QoS behaviour under congestion, and RFC 6349 TCP over the overlay against the line rate

Underlay

Y.1564 per underlay service against the carrier contract, so a slow failover is traced to the policy or to the link, not argued about

ACC-SDW-02 Acceptance, branch platform Rerun, day 4

### Result table, 6 of 18 cases

| KPI | Pass band | Measured | Result |
| --- | --- | --- | --- |
| Voice steering on MPLS brownout | ≤ 5 s | 3 s | Pass |
| Voice steering on link down | ≤ 1 s | 0.6 s | Pass |
| IPsec throughput, 1 Gbps branch, 1400 B | ≥ 900 Mbps | 940 Mbps | Pass |
| Tunnels held per hub, traffic on all | ≥ design count | design + 20 % | Pass |
| TCP throughput over the overlay, RFC 6349 | ≥ 85 % of line | 91 % | Pass |
| Voice MOS under 3:1 congestion | ≥ 4.0 | 3.9 | Pass with a note |

Where it runs

## The CloudLAB WAN bench, and the pages behind this one

CPEs and hubs ship to the CloudLAB rack in Armenia or we connect the bench to your lab; virtual gateways run on the bench hypervisor or in your tenant, and you watch the run through the portal with an engineer on every session. The links are 1G to 100G with a WAN emulator on each, so a brownout is a setting, not a search for a bad cable.

[How a load run goes, step by step](https://test4net.com/services/load-performance-testing?hsLang=en) [Routing and switching: the boxes behind the WAN](https://test4net.com/solutions/routing-switching?hsLang=en) [RFC 6349: TCP throughput over a real path](https://test4net.com/methodologies/rfc-6349?hsLang=en) [Y.1564: Ethernet service activation](https://test4net.com/methodologies/y-1564?hsLang=en)

### Related reading

- [BlogSASE: why vendor benchmarks miss your real deployment](https://test4net.com/blog/sase-benchmark-evaluation-methodology?hsLang=en)
- [Blog387 network outages in a week: cloud incidents up 81%](https://test4net.com/blog/network-outage-report-october-2026-387-incidents-a-week?hsLang=en)
- [BlogWhy vendor benchmarks are not enough for infrastructure decisions](https://test4net.com/blog/datasheet?hsLang=en)
- [BlogVIAVI State of the Network 2027: 58% test before deployment](https://test4net.com/blog/viavi-state-of-the-network-2027-58-percent-test-before-deployment?hsLang=en)

Before the brief

## What WAN teams ask first

Which SD-WAN platforms can you test?

Any vendor and any form factor: branch appliances, hub and data-center gateways, virtual CPEs on the bench hypervisor or in your cloud tenant, and the controller that drives them. Classic WAN routers with IPsec and policy routing run the same cases. The plan names the test tool behind each number; there is no single default vendor.

How do you make a link go bad on purpose?

Every underlay on the bench passes through a WAN emulator that sets delay, jitter, loss, reordering and bandwidth per direction. A brownout is a scripted change of those numbers at a known second, so the steering time is measured from the first bad second to the first good second after the move, and the same brownout repeats for every platform and every rerun.

Is it tested with our policy and our applications?

Yes. Application classes, SLA probes, thresholds, QoS and breakout rules come from an anonymised export; the traffic is built from your application list, with voice and video scored per second and SaaS-like flows over TLS. A vendor-default run can sit next to it, so the gap between the slide and your policy is a number.

How many branches does a run emulate?

As many as the design needs, on 1G to 100G ports: emulated branches with IPsec tunnels and overlay routes toward the hub, with traffic on every tunnel. The site count and a multi-hub design are agreed per setup and written into the plan before the quote.

What about the underlay itself, is the carrier at fault?

The underlay is measured on its own: ITU-T Y.1564 per service against the contract, RFC 6349 for TCP throughput and buffer delay over the path. With those numbers next to the steering times the report says whether a slow failover is the policy, the box or the link.

How long does it take and what do we get?

Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one branch class and a hub, 3–4 weeks for a shortlist of 3 platforms. The report holds every case with its pass band, the measured value, the emulator settings and the policy export, plus a one-page summary per platform.

## Send the platforms, the underlay list and the policy export. The plan comes back in 1–3 business days.

No prices on the site: scope first, then the quote. The vendor and the carrier can sit in on the brief.

[Request a test plan](https://test4net.com/solutions/sd-wan#lead-form) [How the load run goes](https://test4net.com/services/load-performance-testing?hsLang=en)

Send the shortlist

## You have the method. Now get the numbers.

Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.

Prefer to chat? [Message an engineer on WhatsApp](https://wa.me/37491612709)

We use what you send only to answer you. See our [Privacy Policy](https://test4net.com/privacy-policy?hsLang=en).

[Send the shortlist](https://test4net.com/solutions/sd-wan#lead-form)

[![TEST4NET LLC](https://test4net.com/hubfs/test4net-logo-fixed.svg)](https://test4net.com?hsLang=en)

Independent testing and validation for telecom, information security and cloud infrastructure – real insights, not assumptions

<https://www.linkedin.com/company/test4net> <https://wa.me/37491612709> <https://t.me/TEST4NET> [mailto:sales@test4net.com](mailto:sales@test4net.com) <https://www.facebook.com/people/Test4net-LLC/61591470856077/> <https://www.youtube.com/@TEST4NET>

#### Navigate

- [Home](https://test4net.com/?hsLang=en)
- [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en)
- [About us](https://test4net.com/about?hsLang=en)
- [Contact](https://test4net.com/contacts?hsLang=en)
- [Blog](https://test4net.com/blog?hsLang=en)
- [Industry News](https://test4net.com/news?hsLang=en)

#### Get in touch

Sales

[sales@test4net.com](mailto:sales@test4net.com)

Support

[support.test4net.com](https://support.test4net.com)

© 2026 TEST4NET LLC. All rights reserved.

[Privacy Policy](https://test4net.com/privacy-policy?hsLang=en) [Legal](https://test4net.com/legal?hsLang=en)

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://test4net.com/#organization",
  "@type" : "Organization",
  "address" : {
    "@type" : "PostalAddress",
    "addressCountry" : "AM",
    "addressLocality" : "Yerevan",
    "postalCode" : "0033",
    "streetAddress" : "3 Hakob Hakobyan Street (Mergelyan Hub)"
  },
  "alternateName" : "TEST4NET",
  "contactPoint" : {
    "@type" : "ContactPoint",
    "availableLanguage" : [ "en", "ru", "hy" ],
    "contactType" : "sales",
    "email" : "sales@test4net.com",
    "telephone" : "+374-60-88-88-99"
  },
  "description" : "Independent, vendor-neutral lab for testing network and cybersecurity products — NGFW, WAF, IPS, DLP and SASE — and an authorized distributor of test, measurement and network infrastructure solutions.",
  "email" : "sales@test4net.com",
  "foundingDate" : "2024",
  "image" : "https://test4net.com/hubfs/og-t4n.png",
  "logo" : "https://test4net.com/hubfs/test4net-logo-fixed-2.svg",
  "name" : "TEST4NET LLC",
  "sameAs" : [ "https://www.linkedin.com/company/test4net/", "https://t.me/TEST4NET", "https://www.facebook.com/people/Test4net-LLC/61591470856077/" ],
  "telephone" : "+374-60-88-88-99",
  "url" : "https://test4net.com/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://test4net.com/#website",
  "@type" : "WebSite",
  "inLanguage" : "en",
  "name" : "TEST4NET",
  "potentialAction" : {
    "@type" : "SearchAction",
    "query-input" : "required name=search_term_string",
    "target" : {
      "@type" : "EntryPoint",
      "urlTemplate" : "https://test4net.com/hs-search-results?term={search_term_string}"
    }
  },
  "publisher" : {
    "@id" : "https://test4net.com/#organization"
  },
  "url" : "https://test4net.com/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "Service",
  "areaServed" : "Worldwide",
  "description" : "We test branch CPEs, hubs, cloud gateways and the underlay services behind them on the CloudLAB bench: two or three underlays per site through WAN emulators that add delay, jitter, loss and shaping per link, IPsec tunnels and application traffic from emulated branches, and the brownouts a datasheet never mentions. The report shows how fast the policy moves an application off a bad path, how many tunnels and sessions a hub holds, and what TCP really gets over the overlay.",
  "isPartOf" : {
    "@type" : "WebPage",
    "url" : "https://test4net.com/services"
  },
  "name" : "SD-WAN and WAN",
  "provider" : {
    "@type" : "Organization",
    "name" : "TEST4NET",
    "url" : "https://test4net.com/"
  },
  "serviceType" : "SD-WAN and WAN testing: path selection and failover on impaired links, application steering, QoS, IPsec throughput and tunnel scale, RFC 6349 and Y.1564 on the underlay",
  "url" : "https://test4net.com/solutions/sd-wan"
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "BreadcrumbList",
  "itemListElement" : [ {
    "@type" : "ListItem",
    "item" : "https://test4net.com/services",
    "name" : "Services",
    "position" : 1
  }, {
    "@type" : "ListItem",
    "item" : "https://test4net.com/solutions/sd-wan",
    "name" : "SD-WAN and WAN",
    "position" : 2
  } ]
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "FAQPage",
  "mainEntity" : [ {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Any vendor and any form factor: branch appliances, hub and data-center gateways, virtual CPEs on the bench hypervisor or in your cloud tenant, and the controller that drives them. Classic WAN routers with IPsec and policy routing run the same cases. The plan names the test tool behind each number; there is no single default vendor."
    },
    "name" : "Which SD-WAN platforms can you test?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Every underlay on the bench passes through a WAN emulator that sets delay, jitter, loss, reordering and bandwidth per direction. A brownout is a scripted change of those numbers at a known second, so the steering time is measured from the first bad second to the first good second after the move, and the same brownout repeats for every platform and every rerun."
    },
    "name" : "How do you make a link go bad on purpose?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Yes. Application classes, SLA probes, thresholds, QoS and breakout rules come from an anonymised export; the traffic is built from your application list, with voice and video scored per second and SaaS-like flows over TLS. A vendor-default run can sit next to it, so the gap between the slide and your policy is a number."
    },
    "name" : "Is it tested with our policy and our applications?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "As many as the design needs, on 1G to 100G ports: emulated branches with IPsec tunnels and overlay routes toward the hub, with traffic on every tunnel. The site count and a multi-hub design are agreed per setup and written into the plan before the quote."
    },
    "name" : "How many branches does a run emulate?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "The underlay is measured on its own: ITU-T Y.1564 per service against the contract, RFC 6349 for TCP throughput and buffer delay over the path. With those numbers next to the steering times the report says whether a slow failover is the policy, the box or the link."
    },
    "name" : "What about the underlay itself, is the carrier at fault?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one branch class and a hub, 3–4 weeks for a shortlist of 3 platforms. The report holds every case with its pass band, the measured value, the emulator settings and the policy export, plus a one-page summary per platform."
    },
    "name" : "How long does it take and what do we get?"
  } ]
}
```