The PoE Campus Refresh Question No One Is Asking Openly
Enterprise campus networks across Australia are entering a significant refresh cycle. Aging Cat5e and Cat6a cabling plants, the rise of Wi-Fi 6E and Wi-Fi 7 access points demanding higher Power over Ethernet budgets, and the post-pandemic reconfiguration of office spaces are all converging to force network teams to revisit their campus switching strategy.
Yet most refresh conversations still default to the same three or four proprietary vendors. The question this analysis raises is straightforward: with SONiC (Software for Open Networking in the Cloud) now a mature, production-hardened open-source network operating system backed by a broad ecosystem, why are campus buyers not evaluating open switching as part of their PoE refresh planning?
SONiC, hosted under the Linux Foundation, is described as “a free and open-source network operating system based on Linux that runs on switches from multiple vendors and ASICs” offering “a full-suite of network functionality” that “has been production-hardened in the data centers of some of the largest cloud-service providers” [sonicfoundation.dev, sonic-net/SONiC GitHub]. Its container-based modular architecture provides “better fault isolation, easier debugging and troubleshooting, simplified upgrades and maintenance, and enhanced scalability” [sonic-net/SONiC GitHub]. These are qualities that campus network operators arguably need just as much as hyperscalers.
The editorial proposition is not that SONiC campus switching is a finished story today. It is that the buying criteria for a campus PoE refresh - port density, per-port power budget, multi-vendor hardware flexibility, automation readiness, and total cost of ownership - are exactly the criteria where open networking should be evaluated alongside proprietary incumbents.
What SONiC’s Ecosystem Signals for Campus PoE Deployments
The SONiC Foundation’s membership and architecture provide relevant signals for campus buyers evaluating open networking. SONiC is built on the Switch Abstraction Interface (SAI), which “helps in accelerating hardware innovation” by decoupling the network operating system from the underlying ASIC [sonicfoundation.dev]. For campus environments, this decoupling means that PoE-capable switching hardware from multiple vendors can potentially run the same NOS, giving network teams procurement flexibility that proprietary stacks do not offer.
NVIDIA’s networking portfolio explicitly lists “Pure SONiC” as one of the NOS choices available for their Ethernet switches, describing it as “a community-developed, open source network operating system based on Linux that runs on switches from multiple vendors and powers some of the largest data centers in the world” [nvidia.com/en-us/networking/ethernet-switching]. While NVIDIA’s current Ethernet switch portfolio targets data center and AI workloads rather than campus PoE edge, the NOS support pattern demonstrates that the SONiC ecosystem is expanding beyond its original hyperscaler scope.
The key gap - and the reason campus buyers should be watching closely - is whether Enterprise SONiC distributions and the broader hardware ecosystem have matured campus-specific features: PoE management and budgeting, LLDP-MED for endpoint discovery, 802.1X port authentication, and simplified day-2 operations for branch and campus topologies.
Australian Campus Refresh Drivers: Why Timing Matters Now
Several factors make the Australian enterprise campus market a relevant test case for open networking evaluation in PoE refresh cycles:
First, Australia’s commercial real estate sector is undergoing significant retrofit activity. Office fitouts increasingly require high-density PoE deployments for Wi-Fi 6E and Wi-Fi 7 access points, IP security cameras, IoT sensors, and digital signage. Wi-Fi 7 access points in particular are expected to require 802.3bt (PoE++) power budgets of up to 90W per port, substantially more than the 802.3at (PoE+) 30W budgets that many existing campus switches were designed around.
Second, Australian enterprise IT teams face a well-documented skills shortage in networking. Proprietary campus management platforms lock teams into vendor-specific training and tooling. An open-source campus NOS based on standard Linux tooling and industry-standard APIs could reduce this dependency, though the operational maturity of SONiC for campus workflows would need to be demonstrated.
Third, the Australian government’s emphasis on supply chain diversity in critical infrastructure creates a procurement environment where multi-vendor, standards-based networking solutions carry strategic value. Open networking hardware that runs SONiC provides exactly this kind of supply chain flexibility.
PoE Planning Checklist for SONiC-Based Campus Switches
For network teams evaluating SONiC-based access switches in a campus PoE refresh, the following planning criteria deserve close attention. Each criterion maps to a specific technical requirement that determines whether a SONiC campus deployment is viable today or remains a near-term roadmap item:
Per-port PoE budget: The switch must support IEEE 802.3bt (PoE++) at 60W or 90W per port to accommodate Wi-Fi 7 access points and high-power IoT endpoints. Legacy 802.3at (30W) is insufficient for next-generation campus edge devices.
Total PoE power budget: A 48-port PoE++ switch needs a system power budget of 1,500W to 2,000W or more to deliver full PoE on all ports simultaneously. Power supply redundancy (1+1) is expected in enterprise campus deployments.
LLDP-MED and PoE negotiation: Endpoint power discovery and dynamic power allocation require robust LLDP-MED support in the NOS. This is a campus-specific feature that may not be fully mature in all SONiC distributions.
802.1X and NAC integration: Campus access ports typically require IEEE 802.1X port-based authentication with RADIUS integration. Verify that the SONiC distribution supports 802.1X supplicant and authenticator modes.
MC-LAG and STP: Campus aggregation layers often use MC-LAG for active-active uplinks and STP or MSTP for loop prevention. These are critical for campus resilience.
PoE scheduling and port management: Campus operators need the ability to schedule PoE on/off per port (e.g., powering down conference room APs after hours) for energy management.
Management and automation: NETCONF/YANG, gNMI, or Ansible-based automation for campus switch provisioning at scale. This is where SONiC’s Linux-native automation story becomes a differentiator.
Power supply and form factor: Australian data centre and comms room standards typically require front-to-back airflow and specific rack-mount form factors. Confirm hardware availability in the Australian market.
The Incumbent Gap: Where Proprietary Campus Stacks Create Buyer Lock-In
The dominant campus switching vendors in Australia - including Cisco (Catalyst), HPE Aruba (CX), and Juniper (EX) - offer mature PoE campus solutions with deep integration into their own wireless, security, and management ecosystems. This maturity is a genuine strength.
However, this maturity comes with structural costs that open networking can address:
Hardware-software coupling: Proprietary NOS stacks tie the buyer to a single hardware vendor’s switch ASICs, form factors, and pricing. A SONiC-based campus switch allows the buyer to select hardware from multiple vendors running the same NOS, creating procurement leverage.
Management platform lock-in: Proprietary campus management platforms (Cisco DNA Center, Aruba Central, Juniper Mist) bundle wireless LAN controller, network management, and analytics into a single-vendor subscription. SONiC-based campus deployments can integrate with open-source or multi-vendor management tools.
Upgrade cadence control: With proprietary stacks, the buyer is subject to the vendor’s end-of-life and end-of-support timelines. Open-source NOS provides more control over when and how to upgrade.
Licensing complexity: Campus switching licensing has become increasingly complex, with per-port, per-feature, and subscription-based models that obscure true total cost of ownership. Open networking simplifies this equation.
This is not an argument that SONiC campus switching is ready to replace Cisco Catalyst in every Australian enterprise today. It is an argument that the buying criteria are shifting, and network teams running campus refresh evaluations should include open networking in their assessment.
What xSONIC Brings to the Campus Refresh Conversation
xSONIC’s access-aggregate, access-point, and bare-metal product families position the brand to participate in the campus refresh market with an open networking value proposition. The relevant product and solution connections include:
Access and Aggregation Switches: PoE-capable campus access and aggregation switches running SONiC-based NOS, targeting the edge and distribution layers of enterprise campus networks.
Enterprise Access Points: Wi-Fi 6, Wi-Fi 6E, and Wi-Fi 7 access points aligned with OpenWiFi standards, complementing the open networking switching story.
Bare Metal Switches: Open switching hardware for campus environments where the buyer wants full NOS flexibility, including custom or community SONiC builds.
Optical Transceivers: SFP/SFP+/SFP28 transceivers for campus uplinks and inter-building fiber connections.
The PoE Campus solution pillar (/solutions/enterprise-campus/poe-campus-guide/) and Campus Refresh solution pillar (/solutions/enterprise-campus/campus-refresh/) provide the technical depth for buyers evaluating these products.
For Australian enterprises, the xSONIC campus value proposition centers on: multi-vendor hardware choice, SONiC-based NOS with campus feature support, OpenWiFi-aligned wireless, and simplified licensing without proprietary subscription lock-in.
Related xSONiC Resources
Sources Reviewed
- Submit a copyright removal request - YouTube Help: https://support.google.com/youtube/answer/2807622?hl=en
- Supports: input source for finding, recommendation, claim, and evidence review.
- SONiC Foundation: https://sonicfoundation.dev/
- Supports: input source for finding, recommendation, claim, and evidence review.
- SONiC GitHub: https://github.com/sonic-net/SONiC
- Supports: input source for finding, recommendation, claim, and evidence review.
- Azure SONiC Documentation: https://azure.github.io/SONiC
- Supports: input source for finding, recommendation, claim, and evidence review.
- Open Compute Networking: https://www.opencompute.org/projects/networking
- Supports: input source for finding, recommendation, claim, and evidence review.
- Broadcom Ethernet Switching: https://www.broadcom.com/products/ethernet-connectivity/switching
- Supports: input source for finding, recommendation, claim, and evidence review.
- Marvell Switching: https://www.marvell.com/products/switching.html
- Supports: input source for finding, recommendation, claim, and evidence review.
- NVIDIA Ethernet Switching: https://www.nvidia.com/en-us/networking/ethernet-switching
- Supports: input source for finding, recommendation, claim, and evidence review.