Architecture Decision Record for Campus IT Teams

SONiCopen networkingAI fabricEthernetautomation

In brief

Engineering guidance on Architecture Decision Record for Campus IT Teams for Australian campus teams, covering PoE budgets, access-layer resilience, migration risk.

Key takeaways

Engineering guidance on Architecture Decision Record for Campus IT Teams for Australian campus teams, covering PoE budgets, access-layer resilience, migration risk.

Why Australian Campus IT Teams Need an Architecture Decision Record for Open Networking

Enterprise networking is at a decision point. For decades, campus IT teams in Australia have relied on proprietary switching stacks from a small number of incumbent vendors. That model delivered predictable support contracts and familiar CLI workflows, but it also locked organisations into multi-year licensing, closed firmware ecosystems, and limited hardware sourcing options.

Enterprise SONiC — the community-hardened, Linux-based network operating system originally developed for hyperscale data centres — is now mature enough for campus and enterprise edge roles. SONiC runs on switches from multiple hardware vendors and supports a full suite of protocol functionality including BGP, RDMA, LLDP, VLAN, ACL, and PoE management, all within a container-based architecture that decouples software from hardware (sonicfoundation.dev; github.com/sonic-net/SONiC).

For Australian organisations, the migration question is not just technical. Regulatory frameworks such as the Australian Government Information Security Manual (ISM), the Privacy Act 1988, and state-level data sovereignty requirements shape how networking infrastructure must be selected, deployed, and audited. AI infrastructure buildout — including sovereign data centre expansions like Macquarie Data Centres’ IC3 Super West — is also driving campus networks to support higher throughput, lower latency, and more flexible traffic engineering than legacy proprietary stacks typically allow.

This playbook uses the Architecture Decision Record (ADR) framework to give campus IT teams a structured, reviewable, and defensible method for evaluating whether to migrate from proprietary networking to Enterprise SONiC. An ADR is a lightweight document that captures the context, options considered, decision rationale, and consequences of a significant architectural choice. It is not a procurement proposal or a vendor RFP. It is an internal engineering record that any stakeholder — network architect, security officer, procurement lead, or CIO — can review and challenge before the organisation commits resources.

The goal of this guide is to help you build that ADR with source-backed decision criteria, phased deployment checklists, and clear review blockers so your team can make an informed, auditable decision.

Understanding Enterprise SONiC: Architecture for Campus Roles

SONiC (Software for Open Networking in the Cloud) is an open-source network operating system built on Linux and developed under the Linux Foundation. Its core architecture uses Docker containers to isolate individual network functions — such as BGP, LLDP, VLAN management, and telemetry — into independently updatable modules. This modular design provides fault isolation, simplified troubleshooting, and the ability to upgrade individual services without full switch reboots.

Key architectural properties relevant to campus deployments:

Switch Abstraction Interface (SAI): SONiC communicates with switch ASICs through a hardware abstraction layer called SAI. This means the same SONiC software image can run on switches built with Broadcom, Marvell, or other silicon, as long as the hardware vendor provides a compliant SAI implementation. For campus teams, this breaks the coupling between NOS and hardware procurement.

Container-Based Modularity: Each network function runs in its own Docker container. Campus-relevant containers include: teamd (link aggregation and MC-LAG), lldp (neighbour discovery), snmp (monitoring), dhcp_relay (DHCP forwarding), pmon (platform monitoring including PoE and fan control), and bgp/routing containers. Teams can debug, restart, or update individual services without affecting the entire switch.

Configuration Model: SONiC uses a centralised JSON configuration file (config_db.json) and supports both CLI (via sonic-utilities) and programmatic configuration through REST APIs and gNMI/gRPC telemetry. For campus teams accustomed to proprietary CLIs, this is a significant workflow change that requires training investment.

Protocol Support: SONiC supports BGP, OSPF, VLAN, LACP, MC-LAG, STP/RSTP/MSTP, ACLs, DHCP relay, LLDP, sFlow, ERSPAN, VXLAN, and EVPN. For campus roles, the critical question is whether the specific feature combination your environment requires — such as 802.1X NAC integration, PoE scheduling, captive portal, or wireless controller coordination — is available in the SONiC distribution you plan to deploy.

Multi-Vendor Hardware Ecosystem: The Open Compute Project (OCP) Networking project — under which SONiC is a sub-project — has driven the development of open, disaggregated switching hardware. OCP’s scope explicitly includes ‘fully disaggregated and open networking HW and SW’ with Linux-based operating systems and automated bare-metal provisioning (opencompute.org/projects/networking). Multiple hardware vendors now ship OCP-qualified or SONiC-compatible campus and aggregation switches.

NVIDIA Pure SONiC: Major infrastructure vendors including NVIDIA offer ‘Pure SONiC’ as a community-developed, production-supported distribution alongside their own commercial NOS options like Cumulus Linux (nvidia.com/en-us/networking/ethernet-switching). This means campus teams can access enterprise support channels while still running open-source NOS.

The practical implication for Australian campus IT teams: Enterprise SONiC gives you a credible alternative NOS that separates hardware buying decisions from software feature decisions. But the migration is not a drop-in replacement. It requires careful feature mapping, integration testing, and operational workflow changes that the ADR process documented in this guide is designed to capture.

The Architecture Decision Record Framework for Network Migration

An Architecture Decision Record (ADR) is a structured document that captures a significant technical decision, the alternatives considered, the rationale, and the expected consequences. For a campus networking migration, the ADR serves three purposes:

Defensibility: It provides a written rationale that procurement, security, and executive stakeholders can review. If a migration is questioned after the fact, the ADR shows what was considered and why.
Traceability: It creates an audit trail for compliance frameworks that require documented change management processes (relevant under the Australian Government ISM and ASD Essential Eight maturity model).
Knowledge Transfer: It preserves institutional knowledge about why the network was designed a certain way, which is critical for teams with staff turnover.

ADR Template for Campus SONiC Migration:

ADR Field	Description	Example
Title	Unique identifier and descriptive name	ADR-2025-NET-001: Migrate Campus Access Layer from [Vendor] to Enterprise SONiC
Status	Proposed, Accepted, Deprecated, Superseded	Proposed
Context	Business and technical drivers for the decision	Vendor lock-in risk, EOL hardware refresh cycle, AI workload campus backbone requirements
Decision	The specific architectural choice made	Adopt Enterprise SONiC on OCP-qualified bare-metal switches for campus access and aggregation layers
Alternatives Considered	List of options evaluated with pros and cons	Option A: Renew proprietary vendor contract. Option B: Migrate to SONiC. Option C: Hybrid approach.
Consequences	Expected positive and negative outcomes	Positive: hardware flexibility, cost avoidance on licensing. Negative: training investment, reduced vendor TAC support scope.
Review Date	When the ADR should be reassessed	12 months after deployment or at next major refresh cycle
Compliance Mapping	Which regulatory or policy requirements the decision addresses	ISM Control 1463 (Network Segregation), PSPF Governance 9 (Recordkeeping)
Approval Signatures	Technical and business stakeholders	Network Architect, CISO, Procurement Lead

This template is deliberately generic. Your organisation should adapt it to match internal governance frameworks. The key principle is that no significant network architecture change should proceed without a written, reviewed, and approved decision record.

Decision Criteria: Proprietary Networking vs Enterprise SONiC for Campus

The following decision criteria table provides a structured comparison framework for campus IT teams. It is not a vendor recommendation. Each criterion should be evaluated against your specific environment, skillset, and regulatory context.

Decision Criterion	Proprietary Networking Stack	Enterprise SONiC on Open Hardware	What to Evaluate
Hardware Sourcing	Single-vendor or limited approved vendor list	Multi-vendor via SAI; OCP-qualified switches from multiple OEMs	Can you source campus switches from 2+ vendors with SONiC support?
Software Licensing	Per-device or per-feature licensing; recurring OpEx	Open-source (Apache 2.0 for community SONiC); commercial support optional	What is your 5-year TCO comparison including support contracts?
Campus Feature Parity	Mature campus features: 802.1X, PoE management, NAC integration, wireless controller, captive portal	Evolving: VLAN, LACP, PoE (platform-dependent), LLDP, sFlow; 802.1X and advanced campus features vary by distribution	Map your required feature set against the specific SONiC distribution and hardware platform
Operational Tooling	Vendor-specific NMS, SNMP MIBs, proprietary telemetry	Industry-standard: gNMI, gRPC, SNMP, sFlow, REST API, SONiC CLI	Does your NMS/Ops team have experience with standard Linux tooling and API-driven automation?
Support Model	Vendor TAC with SLAs, firmware updates, hardware replacement	Community support or commercial support from distribution vendor (e.g., NVIDIA Pure SONiC, other Enterprise SONiC distributors)	What is your minimum acceptable support SLA for campus access switches?
Security and Compliance	Vendor security advisories, CVE patching cadence tied to vendor	Open-source CVE tracking via GitHub; community and commercial patch pathways; auditability of source code	Does your compliance framework require source code auditability or specific patch SLAs?
Upgrade Path	Vendor-managed firmware bundles	Container-based independent service upgrades; community release cycles	Do you have the operational maturity to manage rolling upgrades on container-based NOS?
Campus-Specific Integration	Tight integration with vendor wireless, NAC, SD-WAN	Integration via standard protocols (802.1X, RADIUS, LLDP); wireless controller independence may be required	Map your wireless, NAC, and SD-WAN integration points
Staff Skills	Existing CLI familiarity; vendor certification pathways	Linux skills, Ansible/Python automation, YAML/JSON config, container management	Assess current team skills and identify training gaps
Vendor Lock-In Risk	High: proprietary CLI, config format, hardware-NOS coupling	Low: open config format, multi-vendor hardware, standard protocols	Quantify your current switching contract exit costs and timelines

Australian-Specific Considerations:

Data sovereignty: Australian Government entities must comply with the Hosting Certification Framework and data sovereignty requirements. SONiC’s open-source nature allows full inspection of the NOS codebase, which can support compliance evidence gathering.
Supply chain resilience: The Australian Signals Directorate’s Essential Eight and supply chain risk management guidance encourage diversity in critical infrastructure components. Multi-vendor SONiC hardware sourcing directly supports this objective.
AI campus backbone: As Australian enterprises deploy AI infrastructure — including GPU inference clusters connected to campus networks — SONiC’s proven RDMA and RoCE capabilities (originally hardened in hyperscale data centres) provide a credible path for campus-to-data-centre traffic engineering.

Engineering Evidence Floor

For campus and access switching topics, acceptance should be based on endpoint behaviour under real operating constraints. The evidence package should include endpoint classes, PoE budget, NAC/802.1X, LLDP-MED, voice VLANs, multicast, STP or MC-LAG behaviour, uplink capacity, monitoring, rollback, and help-desk workflow. A representative pilot should run at least 48 ports for 30 days, include one planned rollback inside 24 hours, and document support ownership before scale-out.

Evidence area	What to validate	Acceptance gate	Rework trigger
Endpoint mix	APs, phones, cameras, laptops, IoT, and printers	48 ports run mixed load for 24 hours	Only laptop traffic is tested
Power and uplinks	PoE budget, 1G/2.5G/5G/10G access, and 100G uplinks	No power or uplink bottleneck in pilot	Refresh ignores closet constraints
Resilience	STP, MC-LAG, link loss, member loss, and rollback	3 failure cases captured	Campus works only in steady state
Operations	Monitoring, logs, backup, restore, and help-desk runbook	Incident evidence ready within 2 hours	Support depends on informal notes
Rollout	Site selection, training, spares, and change windows	30 days pilot approved before estate rollout	Procurement scales before validation

Engineering FAQ

What should be tested before moving campus switching to SONiC or open networking? Test PoE behaviour, NAC integration, VLAN and policy design, STP or MC-LAG interaction, multicast, monitoring, upgrade rollback, and help-desk workflows. Campus readiness is an operations test, not only a forwarding test.

Where do campus refresh projects usually carry hidden risk? The risk often sits in closets: power budget, old cabling, undocumented uplinks, mixed endpoint types, voice devices, cameras, badge systems, and change windows. Those details should be inventoried before selecting switch models.

How should Australian campus teams structure a pilot? Choose one representative site or building, document endpoint classes, run PoE and failover tests, verify monitoring, train operations staff, and define rollback steps before expanding to the broader estate.

Sources Reviewed

Product fit

Where xSONiC fits

xSONiC can help validate the switch, optics, software image, telemetry, and support assumptions against the actual deployment before a production order is released.