3 SD-WAN Mistakes I Made in My First Year (and the Checklist That Fixed It)

Who needs this checklist (and why I wrote it)

I've been handling network infrastructure orders for enterprise clients for about 6 years now. I'm the guy who' s supposed to know the difference between a good SD-WAN deployment and a costly nightmare. But I wasn't always that guy.

My first year managing SD-WAN rollouts—specifically with Extreme Networks gear—was a masterclass in what not to do. I personally made (and documented) 3 significant mistakes, totaling roughly $12,000 in wasted budget across two projects. Now, I maintain my team' s deployment checklist to prevent others from repeating my errors.

This checklist is for you if:

• You're evaluating or deploying Extreme Networks SD-WAN (sometimes spelled 'sdwan') for the first time.
• You're moving away from a traditional MPLS setup and need a practical, step-by-step plan.
• You' ve heard the marketing claims and want to know where the real pitfalls are hidden.

There are 3 main steps here. Each one addresses a mistake I made, in the order I made them. Trust me—skip one, and you' re looking at a headache that could easily cost you a week of troubleshooting.

Step 1: Validate your underlay network before touching the SD-WAN config

The mistake: In September 2022, I was in a hurry. The CIO wanted SD-WAN live at our main distribution center in two weeks. I jumped straight into configuring the ExtremeCloud SD-WAN orchestration—policies, traffic steering, the whole nine yards. The problem? Our MPLS circuit at that site had a persistent 2% packet loss that wasn't showing up in our basic monitoring.

The result: The SD-WAN controller kept trying to steer traffic away from a link that looked 'up.' But the underlying issue was intermittent jitter. Applications that relied on VoIP and real-time inventory sync kept failing. I spent three days chasing the wrong configuration before someone on the carrier side finally admitted the circuit was flaky. That error cost $890 in redo plus a 1-week delay.

The lesson (and the check):

• Don't trust simple ping tests. Run a 24-hour RFC 2544 test on all WAN links before you start your SD-WAN config.
• Check for micro-bursts. Look at interface utilization in 10-second intervals, not 5-minute averages. I' ve seen links that look 40% utilized but spike to 95% for 3 seconds at a time—enough to drop packets.
• Validate latency and jitter. If your latency is over 100ms, or your jitter exceeds 10ms, you need to fix the transport first. SD-WAN doesn' t magically fix a bad circuit.

Quote from my notes back then: 'The circuit looked fine on the dashboard. The dashboard was lying. Not maliciously, but it was averaging out the problems.'

Step 2: Map your application flows before writing one policy rule

The mistake: In Q1 2024, I was tasked with setting up a new SD-WAN site for a 200-user office. They had a mix of SaaS apps (Office 365, Salesforce), some legacy ERP, and a video conferencing suite. I created a single, aggressive rule: 'Prioritize all real-time apps.'

Sounds sensible, right? Except I didn't realize their 'ERP' system—which I thought was just a database query tool—actually used a proprietary protocol that looked like bulk data transfer to the SD-WAN classifier. The SD-WAN kept pushing that traffic to the backup link (cheaper, lower priority), and the ERP kept timing out. The finance team was not happy.

The lesson (and the check):

• Get a list of every business-critical application. Not just the names—the ports, the protocols, the vendor names.
• Check your SD-WAN' s application signatures. Extreme Networks maintains a database of signatures, but your custom or legacy app might need a custom signature or a manual policy. I missed this step entirely.
• Don' t over-prioritize. If you mark everything as 'high priority,' nothing is high priority. Pick 3-5 apps max and let everything else use best-effort.

A senior colleague later told me: 'The goal isn't to give every app a gold ticket. It' s to stop the one app that' s causing the fire from burning down the house.'

Step 3: Test your failover scenarios (and your user experience) in production, not just the lab

The mistake: I had a nice, clean lab setup. Two circuits, SD-WAN controller, traffic policies. In the lab, failover was flawless—sub-second convergence. I was proud. Deployed it to a 50-user remote branch. First time the primary link went down (about 2 weeks in), the network failed over. Technically.

But here's what the lab didn' t show: the users' VPN clients had to re-establish their secure tunnels. That took 30-60 seconds. Every single user experienced a 'connection lost' popup. Help desk calls flooded in. I had configured the SD-WAN for automatic path steering, but I hadn' t told the VPN infrastructure to expect a failover.

My lab test was a test of the network, not of the user experience. That mistake cost us a 3-day production delay and a lot of angry emails.

The lesson (and the check):

• Test the full user experience. Don' t just verify the SD-WAN switched paths. Open an RDP session, a web call, a database query. Watch what the user sees.
• Check your VPN/DIA integration. If your SD-WAN is handling failover but your Direct Internet Access (DIA) or VPN client doesn' t know about the change, users feel the pain.
• Schedule a 'fire drill' week. For the first month, schedule one unannounced circuit failure per week (during business hours, but with a plan). Train your help desk on the script: 'This is a scheduled failover test. It will take 1-2 minutes. Thank you for your patience.'

Common pitfalls and final reminders

I've seen colleagues make similar mistakes, so here are a few more to keep in mind:

• Over-segmentation. It' s tempting to create 20 different VNs (Virtual Networks) for every department. Keep it to 3-4. IoT, guest, corporate, and maybe a DMZ. More than that, and your policy management becomes a nightmare faster than you can say 'network segmentation.'
• Ignoring the cloud control plane. ExtremeCloud IQ is a solid controller, but it' s internet-dependent. If your management network goes down, can you troubleshoot? Have a local admin account and a backup process for offline configs.
• Copying the Cisco config. Extreme' s CLI and policy model is different. Don' t assume 'router-on-a-stick' logic works the same way. It sorta does, but the syntax is different enough to bite you.

My experience is based on about 15 SD-WAN deployments, mostly in mid-market (200-1000 seat) environments. If you' re deploying in a data center core or a massive campus (5000+ users), some of these steps might need scaling. I can' t speak to that directly, but the principle holds: validate the underlay, map the apps, test the user experience.

The checklist I now use takes about 4 hours to run through, start to finish. It' s saved me from at least two major disasters that I can think of. If this saves you even one 3-day debugging session, it was worth writing down.