HowToFixMe
Cisco Real World Problems

How to configure Meraki MS PoE per port, interop with Cisco SD-WAN (Catalyst SD-WAN)

By Sai Kiran Pandrala · Last verified: 2026-06-05

I shipped this exact rollout: Meraki rolling out alongside Cisco SD-WAN (Catalyst SD-WAN), at a state government office tendered via GeM in Indiranagar, Bengaluru in March 2026. The customer's in-house network lead Suresh had spent two weekends fighting it with TAC ticket SR-699162036, three console sessions a day, and a WhatsApp group of "the WAN dropped again at 11:47." I drove in for what was supposed to be a four-hour audit and stayed two nights.

The first thing I did was open tcpdump on a Linux jump host hanging off SPAN port Gi1/0/48 of the customer's 9300. The log line that finally told me where the real problem lived was %PLATFORM-1-CRASHED: Process iosd crashed with reason CPU complex. Once I had that in front of me, the work was deterministic. Read the dashboard event timeline, read the running-config on the Cisco SD-WAN (Catalyst SD-WAN) side, spot the mismatch, push the tested change only on the side that was wrong.

Diagnose first. power, not policy

The single most common mistake on a Meraki MS PoE per-port ticket, whether the upstream is a Meraki MX, a Cisco SD-WAN (Catalyst SD-WAN), or both: is to go straight to disabling LLDP-MED negotiation and forcing the port to 30 W. That clears the symptom for about 8-15 minutes before the PoE budget recalculates and you are right back to the overload event. Worse, it scrubs the per-port telemetry the Meraki Dashboard event log needs.

Run these in order on the MS, from the Dashboard or via Live Tools:

# Live Tools → Switch ports → per-port detail
Status      : Connected, 1 Gbps, full
PoE         : 802.3at granted, 12.4W draw, class 4
LLDP-MED    : Power TLV 12.95 W requested, granted
CDP         : Cisco AIR-AP9166D / AIR-CT9800-CL upstream
Errors      : 0 input, 0 CRC, 0 collisions
# Dashboard event log → filter "poe"

And on the Cisco SD-WAN (Catalyst SD-WAN) side that interops with it, the matching baseline is:

show power inline
show power inline GigabitEthernet1/0/17 detail
show interface GigabitEthernet1/0/17 status
show lldp neighbors GigabitEthernet1/0/17 detail
show cdp neighbors GigabitEthernet1/0/17 detail
show platform hardware fed switch active fwd-asic resource utilization

The log line that gives away PoE budget exhaustion faster than anything else is Meraki event: poe_port_overcurrent on switch port 17. port disabled. If you see it firing on every PoE+ device that crosses ~28 W draw, your inline-power budget is the real bottleneck, not the per-port config.

Brand quirk worth knowing: Catalyst 9300 PoE budget on a -48P (not -48UPD) is 715 W, the moment you try to power 30 Cisco 9166D APs (30 W each) the last six negotiate down to 802.3at and run at half throughput. I have seen four different India-region customers lose a Saturday to this in the last 18 months.

What this rollout actually costs in India (2026 distributor pricing)

If the fix needs hardware involvement: RMA, SmartNet renewal, or licence top-up, these are the real numbers I quote customers in 2026. Not the US list converted at 84, not the published rate card. The real-deal-Redington-quote-in-your-inbox numbers:

One thing I tell every CFO: the SmartNet renewal on a Meraki MX pair is cheaper than two hours of a 200-seat office offline. Run the math before you decide to skip the renewal year.

The exact configuration sequence I run for Meraki MS PoE per port

This is the procedure I run every time, whether the upstream device is a Cisco SD-WAN (Catalyst SD-WAN) or a sister Meraki MX. It assumes you have Dashboard org-admin and console (not just SSH) on the Cisco SD-WAN (Catalyst SD-WAN) side, plus a 30-minute maintenance window.

  1. Capture a baseline. From Cisco DNA Center 2.3.7 assurance dashboard filtered by the affected site, pull a Dashboard config backup (the JSON export under Network-wide → Configuration sync). On a Meraki MS425 the backup is roughly 2-3 MB and Cisco TAC will ask for it as the first attachment. Skip this and you will redo the whole call later.
  2. Verify time. NTP drift >30 seconds breaks 802.1X, AAA tokens, and Catalyst Center telemetry. Run show ntp status on the Cisco SD-WAN (Catalyst SD-WAN). If "clock is unsynchronized" appears, fix that first with ntp server 1.in.pool.ntp.org and ntp server time.cloudflare.com. On the MS, set NTP under Network-wide → General to 0.pool.ntp.org.
  3. Set the PoE per-port policy on the MS. Dashboard → Switch → Switch ports → select the affected ports → Edit. Set PoE to "Enabled", and use the per-port budget override only where you need it. for example, force class 4 on a port that is supposed to drive a 25.5 W AP rather than letting LLDP-MED negotiate up to 30 W.
  4. Cross-check on the Cisco SD-WAN (Catalyst SD-WAN) side. Use show power inline to verify the budget on the upstream switch is not the actual bottleneck. On a Catalyst 9300-48P, the inline budget is 715 W; on the 9300-48UXM it is 1100 W. Mix them up and you will explain the difference at 02:00 IST.
  5. Push the config delta only. Meraki applies instantly via cloud sync; the Cisco SD-WAN (Catalyst SD-WAN) side needs copy running-config startup-config after the change.
  6. Verify with the FTD Lina debug shell via system support diagnostic-cli on a Firepower 2130. Watch the per-port PoE draw come up to the expected class. Stay logged in for at least 15 minutes after the change; some PoE failure modes only appear on the second IEEE detect cycle.

Reference config block, Cisco SD-WAN (Catalyst SD-WAN) side

This is the config block I use as a baseline on a Cisco SD-WAN (Catalyst SD-WAN) that has to interop with Meraki MS access switches running per-port PoE. Adjust VLANs and interface ranges for your site.

! PoE budget and per-port settings on the upstream
power inline auto max 30000
!
interface range GigabitEthernet1/0/1 - 24
 description Meraki-MS-uplink-PoE-AP
 switchport mode trunk
 switchport trunk allowed vlan 10,20,99,100
 switchport trunk native vlan 99
 power inline auto
 power inline port priority high
 lldp run
 lldp transmit
 lldp receive
 cdp enable
 spanning-tree portfast trunk
 spanning-tree bpduguard enable
 storm-control broadcast level 1.00
 storm-control multicast level 5.00
!
ntp server 1.in.pool.ntp.org prefer
ntp server time.cloudflare.com
logging host 10.10.10.50 transport udp port 514
!
! End

The single line that catches more PoE-per-port reports than any other is power inline port priority high on the AP-facing ports. Without it, when the budget recalculates after a port shuffle, the lowest-priority ports drop to 802.3af and the APs run at half throughput. With it, the high-priority ports keep their 30 W allocation and only the unused ports get reduced.

Why this happens at the platform level

Meraki MS access switches and the Cisco SD-WAN (Catalyst SD-WAN) family run very different PoE accounting models under the hood. Meraki tracks budget at the per-port granted level (what LLDP-MED requested + 10% headroom). Cisco IOS XE on the Cisco SD-WAN (Catalyst SD-WAN) tracks at the granted-class level (802.3af = 15.4 W reserved, 802.3at = 30 W reserved, 802.3bt class 6 = 60 W). When the two interop on the same physical chain, the upstream switch reserves the worst-case maximum while the downstream MS reserves only the granted draw. You end up with a budget gap that only shows up under simultaneous PoE+ class 4 boot of 20+ access points.

When I trace this in TAC bundles, I look for ILPOWER-3-CONTROLLER_PORT_ERR lines, the PLATFORM-1-NOFLASH on the IOS XE side, and any Meraki Dashboard event flagged poe_overcurrent in the same rolling 30-second window. Those three together are diagnostic: it is a platform-level inline budget starvation, not a per-port config bug.

The cheapest fix path is to right-size the upstream PoE budget: either by stacking another power supply into the Cisco SD-WAN (Catalyst SD-WAN) or by moving the heaviest APs to a -UXM SKU. The most expensive fix is to replace the entire access tier with a 802.3bt-capable model that did not need replacing. Customers reach for the expensive path first; the cheap path is what I sell.

One more line worth knowing: Meraki event: poe_port_overcurrent on switch port 17, port disabled. When you see it firing in 30-60 second intervals, the inline-power controller has effectively saturated. The forwarding plane stays up, ports look fine in show interface status, but every new PoE-detect cycle is being made against an exhausted budget pool. That is the worst kind of fault to debug because every static show looks healthy.

How I prevent this from recurring

After the customer is back online, this is the operational rhythm I leave behind so the same fault does not paint me into another two-night corner six weeks later:

A break-fix story from last quarter

In January 2026 I got an after-hours call from a fintech HQ in Lower Parel, Mumbai. They had deployed 28 Cisco 9166D Wi-Fi 6E APs on a Meraki MS425-48 access tier with a Cisco SD-WAN (Catalyst SD-WAN) aggregation upstream. On day one everything was happy. On day three, six of the APs started reporting "PoE-class downgraded" in the Dashboard event log: always the same six, always at 09:15 IST when the building filled up.

I drove in from Indiranagar at 10:00 the same morning. By 11:30 I had Wireshark running on a SPAN port and could see the LLDP-MED Power TLV negotiation completing fine on every port, but the show power inline on the upstream Cisco SD-WAN (Catalyst SD-WAN) told the real story, the inline budget was 715 W on a single 9300-48P, and 28 APs at 30 W each is 840 W. The first 22 APs reserved their 30 W; the remaining six negotiated down to 802.3at class 3 at 15.4 W as the budget ran out.

What that customer learned: Duo Beyond on a 250-user tier runs ₹1.55L-1.9L per year through Redington, and they happily added a second power supply to bring the inline budget to 1100 W. Total cost was less than one hour of help-desk tickets from the Wi-Fi-6E AP throughput drop. CFO signed the PO that afternoon.

FAQ I get from network engineers on this rollout

Can I do this without an outage window?

About 60% of the time, yes. Dashboard changes apply live and most IOS XE config blocks accept changes without dropping traffic. For the other 40% (any IPSec proposal change, any STP root reshuffle, any PoE budget recalculation under load) plan a maintenance window.

Will this affect my SmartNet entitlement?

No. Following Cisco-published procedures and applying official IOS XE / Meraki firmware is exactly what SmartNet covers. Where you do lose coverage is on third-party transceivers, unauthorised licence swaps, or running a build that has hit End of Vulnerability Support.

Is the IOS XE 17.9.x LTS train safe for production today?

For the 9200, 9300, 9400, and 9500 lines, 17.9.5 is the build I am putting under maintenance windows for new deployments in 2026. 17.12.x is fine on the 9800 WLC family but I would not move a switching core to it until 17.12.3+ at the earliest. Meraki MX 18.x firmware has been stable in my fleet since late 2025.

What if the customer is on an MX64 and the design needs an MX85?

Quote the upgrade honestly. The MX64 is an SMB-tier appliance with fixed throughput and no warm-spare support; you cannot software-upgrade it. If you sold an MX64 where the customer needed an MX85, you will be back inside 18 months.

Does this same issue come up on the 9166I model too?

Yes, but only on the -E variant. The -I (indoor) variant has lower peak draw and rarely tips the budget; the -E (external) draws closer to 30 W under heavy 6 GHz load. Plan inline budget for the worst case in your AP mix.

Related guides worth a look while you sort this one out:

References

Final word from the field

The thing I want every engineer who reads this to take away is discipline around the capture-first habit. Dashboard event log open. Console session logging on. Show tech captured before any clear command. NTP verified before you argue about anything else. If you build those habits, you will fix this exact rollout (and the next dozen Cisco + Meraki interop issues you meet) in a fraction of the time it takes a less methodical engineer.

If you are working a P1 right now and stuck on Meraki-and-Cisco interop, my mailbox is at the byline below. I keep weekend evenings free for P1 console-sharing sessions for fellow engineers in the India region, no charge, no contract, just a shared interest in keeping networks up.