Friday, 4:47 p.m.
My phone rang while I was on a ladder, halfway through mounting an Extreme Networks WS-AP3825i access point. The voice on the other end was one of our field techs. “Scanners are connecting to the SSID, but they aren’t getting IP addresses.”
I looked at the AP. Power LED on. Status LED blinking in a pattern that wasn’t obviously bad—but wasn’t obviously good, either. The quick-start card had a legend with tiny diagrams that made about as much sense to me as blood pressure monitor symbols. I remember looking at my watch. It was 4:47 p.m. on a Friday, and the site was due to go live Monday at 8:00 a.m.
Background: a rollout I thought I had handled
Seven years into doing this kind of work, I have a checklist partly because past me made avoidable mistakes. This one nearly became the cover story.
We were replacing an older wireless network at a distribution center. The plan called for 32 Extreme Networks WS-AP3825i access points across two buildings. The switches and wireless controller were also Extreme Networks. I know the product line well enough to be dangerous—which, as it turned out, was exactly the right way to describe me that day.
I had done a similar deployment a few months earlier. My notes included the Extreme Networks switch commands I used for the AP uplinks: create the VLANs, tag the client VLANs on the AP port, put the AP in the right management VLAN. I typed those commands again. The switch accepted every one. No errors. I checked the VLAN membership and saw the port in all the right places.
Then I mounted the AP, watched it join the controller, and marked it complete. From a switch config perspective, it looked perfect. From a wireless perspective, it looked perfect. The problem was that I hadn’t looked at what happens after a client actually connects.
Saturday: the AP was never the problem
The next morning, the field tech confirmed the symptom: devices associated to the SSID but got no IP address. Not “slow.” Not “intermittent.” They connected, waited, and ended up with 169.254.x.x addresses. That’s the networking equivalent of a dead end.
I started with the easy things. Power? I used a Klein multimeter to check the PoE voltage at the end of the cable. It read 53 volts, so the switch port was delivering power. This isn’t a no-name vs. Klein multimeter debate; I just needed one number I could trust. Power was fine.
The AP? It was still connected to the controller. Channel, SNR, association count—all looked normal. The switch port? It was in the right VLANs. The DHCP server? I could ping it from the switch management VLAN. So why were wireless clients not getting leases?
I spent another hour trying things. I rebooted the AP. I disabled and re-enabled the SSID. I tried different Extreme Networks switch commands I half-remembered from forums. At one point I was two commands away from rebooting the production switch on a Saturday—not because I thought it would help, but because I was running out of reasonable moves. That’s when I stopped.
The ticket that cost $295 and saved the weekend
At 11:20 a.m., I opened a support ticket with Extreme Networks. The case number was SR-3310. I remember it because it was the moment I stopped treating the problem as a test of my pride.
Our standard support agreement didn’t include the urgent queue on a weekend. The buy-up was $295. I didn’t ask twice. I’ve never seen a $295 support fee destroy a project budget. I have seen a missed go-live destroy trust, and no one remembers whether the problem was hardware, software, or something in between.
People like to say the extra fee buys speed. It doesn’t. Speed alone isn’t useful if the answer is wrong. What it buys is certainty: someone who has read the command reference for this exact firmware, who has seen this exact setup, and who will keep going until the problem is solved.
What the engineer found
The engineer asked for the switch config and looked at the VLAN setup. Then they said the sentence that made the whole weekend click: “Your wireless clients are on VLAN 200, but your DHCP server is on VLAN 10. VLAN 200 has no DHCP relay. The DHCP broadcasts die at the VLAN boundary.”
In other words, the WS-AP3825i access point was doing its job. The switch port was set up correctly for the wireless network. What I had missed was the Layer 3 part. In my earlier deployment, the DHCP server had been on the same VLAN as the wireless clients, so no relay was needed. This one used a central DHCP server, and I never added the relay rule on the VLAN interface.
The fix took about two minutes. The engineer gave me the commands, I applied them, and within 90 seconds a scanner on the loading dock pulled a valid IP address. I sat on the floor of the wiring closet and laughed. The whole problem was one missing Layer 3 command in my checklist.
I don’t have hard data on how many deployment delays come from DHCP relay configs instead of bad APs. Anecdotally, in my world, the access point is rarely the problem. The problem is usually the switching config around it—or something even dumber, like the one command I didn’t save.
The checklist I use now
That mistake is the reason every rollout checklist now starts with these three things:
- For every client VLAN, confirm DHCP relay or IP helper is configured on the switch, not just the port membership.
- Test with a real client device from the start, not just from the AP or controller dashboard.
- If a support fee costs less than a missed deadline, pay it before hour three of guessing—not after.
A support ticket isn’t a delivery service. It’s closer to insurance: you pay for the certainty that someone will take the problem seriously and keep answering until it’s fixed. Now I budget for that fee in every project with a hard deadline. It’s not because I expect the network to fail. It’s because I want certainty priced into the plan, not bolted on after I’ve already wasted a weekend.