PicOS Data Center Switches: EVPN & Upgrade Guide

Most data center switch decisions still start with a datasheet: port count, speeds, and price. PicOS data center switches ask a different question first. Because the operating system, hardware, and management layers are decoupled, choosing PicOS is less a hardware purchase and more an operating-model decision - how your team will provision, automate, and run the fabric over its lifetime.

This guide explains what PicOS data center switches actually are, how the switch, the network operating system, and the AmpCon-DC controller fit together, where they are a strong fit, and exactly what to validate before a production rollout. The goal is to help a network team evaluate PicOS on engineering criteria, not marketing language.

PicOS Switch vs PicOS NOS vs AmpCon-DC: What You Are Actually Choosing

The term "PicOS data center switch" is often used loosely, which creates confusion during evaluation. It refers to three distinct layers that are bought and operated separately:

• The switch hardware - open networking ("white box" or "brite box") platforms, typically built on Broadcom silicon. A common data center example is a 1U leaf or spine switch such as the N8550-32C, with 32 x 100G QSFP28 ports on a Broadcom Trident 3 ASIC. The ASIC, port speeds, and buffer determine the hard limits of what the box can do.
• The PicOS network operating system - the PicOS NOS from Pica8, built on an unmodified Debian Linux kernel. It supplies the Layer 2/Layer 3 stack, EVPN-VXLAN, MLAG, security, and open telemetry (SNMP, sFlow, and gNMI). The NOS, plus its version and license tier, determines which features are actually available.
• AmpCon-DC - the management and automation controller. It handles zero-touch provisioning (ZTP), template-driven configuration, topology discovery, telemetry, upgrades, and validation across the full lifecycle, from Day 0 design to Day 2+ operations.

Keeping these layers separate matters during evaluation: a switch model can be perfectly capable hardware while a specific PicOS version or license does not yet enable the feature you need. Always evaluate the combination, not one layer in isolation.

Why Enterprises Evaluate PicOS for Data Centers

Enterprises usually look at PicOS when an existing design starts limiting performance, scale, or operations - for example, moving from 10G to 25G or 100G, standing up a new leaf-spine fabric, or trying to reduce manual, switch-by-switch configuration.

Handling East-West Traffic With Leaf-Spine

Legacy architectures were tuned for predictable north-south traffic. Virtualization, distributed storage, container platforms, and AI workloads generate far more east-west traffic between racks. A leaf-spine fabric flattens the topology and makes latency and bandwidth more predictable. PicOS-based switches can take leaf, spine, top-of-rack, border, or interconnect roles, provided the port speeds, switching capacity, and routing features match the design.

Reducing Vendor Lock-In - and How That Actually Works

"Reducing lock-in" is easy to claim, so it is worth stating the mechanism. In a traditional stack, hardware, NOS, licensing, management, and support are bundled into one vendor relationship. PicOS follows a disaggregated, open-networking model: the same NOS runs on validated white-box hardware from multiple suppliers, with full support for speeds from multi-gig up to 400-gig and beyond and for EVPN-VXLAN. In practice, that means the operating model and automation become the durable part of your design, while the underlying hardware vendor can change over time. The trade-off is real, though - you take on more responsibility for design, validation, and operational ownership.

Automating Day 0 to Day 2+ With AmpCon-DC

Manual CLI is tolerable for a handful of switches and risky across dozens or hundreds. AmpCon-DC is where PicOS earns much of its operational value: ZTP onboarding, Jinja-based configuration templates, Ansible playbooks, and REST APIs reduce repetitive work and configuration drift. The objective is not automation for its own sake - it is repeatable onboarding, auditable change, and faster recovery.

Key Capabilities to Evaluate

EVPN-VXLAN and IP Fabric Readiness

Modern fabrics typically extend Layer 2 over a routed Layer 3 underlay using two standards together: VXLAN, the overlay encapsulation defined in RFC 7348, and EVPN, the BGP-based control plane standardized in RFC 7432. When the switch model and PicOS version support it, PicOS can be evaluated for scalable leaf-spine fabrics serving virtualized and cloud-style, multi-rack environments. Treat EVPN-VXLAN support as version- and model-specific, and confirm it against the exact platform you intend to buy.

MLAG and High Availability

MLAG lets two physical switches present a single logical aggregation point to downstream devices, keeping all links active and removing the dependence on spanning-tree-heavy designs. For top-of-rack and aggregation roles, this provides redundant uplinks for servers and storage without the failover gaps common to traditional stacking. Validate peer-link, keepalive, failover timing, and orphan-port behavior before relying on it.

Programmability and Telemetry

A data center switch should be automation-friendly by default. PicOS exposes Ansible, Python, and standards-based interfaces, and provides visibility through SNMP, sFlow, and gNMI streaming telemetry. The practical payoff is consistency: templated configs, baselined monitoring, and drift detection across the whole fabric.

Lifecycle Management and Visibility

Switching capacity is only part of operations. Teams also need topology, interface state, device health, and configuration-drift visibility. With AmpCon-DC, PicOS environments can be provisioned, monitored, changed, and validated from one console - which, for teams with limited engineering headcount, can matter as much as raw throughput.

PicOS vs Closed NOS vs Community NOS

The meaningful difference between these options is the operating model, not headline hardware specs. The table below compares a traditional closed stack, a community-driven open NOS, and PicOS with AmpCon-DC.

Best-Fit and Poor-Fit Scenarios

PicOS is a strong choice in some environments and a poor one in others. Being honest about both protects the deployment.

Strong fit when:

• You are building leaf-spine or EVPN-VXLAN fabrics and want open hardware sourcing.
• The team is automation-ready (or willing to become so) and values templated, repeatable operations.
• You want to standardize one NOS and one management model across many switches.
• The target hardware is on the validated compatibility list and the PicOS version supports the required features.

Less suitable when:

• The team has no automation capability and no plan to build it.
• You depend heavily on a single vendor's TAC for day-to-day operations.
• There is no ability to lab-validate the fabric before production.
• Your preferred hardware or required feature set is not on the supported matrix.

Common Use Cases

10G/25G to 100G Upgrades

A frequent path is raising server access to 25G and building 100G leaf-to-spine uplinks. Beyond the switch itself, the upgrade depends on the physical layer: for multimode runs, the fiber grade you deploy determines reach, so confirm supported distances early - the differences between OM1 through OM5 multimode fiber and their distance limits directly affect whether a 100G link will work in your cabling plant.

Leaf-Spine Data Center Fabrics

Leaf switches connect servers and storage; spine switches provide the high-speed fabric between leaves. PicOS fits these roles when speeds, port counts, and routing features match the design. Structured cabling makes this far cleaner - planning MPO/MTP trunk and breakout cabling up front keeps high-density leaf-to-spine connections manageable as the fabric grows.

Data Center Gateway and Interconnect

Some designs extend switching between sites, zones, or domains, where scalable Layer 3 routing and centralized lifecycle visibility matter most. These longer runs usually call for single-mode optics, so match the transceiver reach to the link - reviewing the differences between OS1 and OS2 single-mode fiber helps confirm a given interconnect distance is supported.

AI, HPC, and Lossless Ethernet

AI and HPC fabrics are not just about raw bandwidth. RDMA traffic (RoCEv2) needs a lossless or near-lossless Ethernet fabric, which depends on flow control such as PFC and congestion signaling such as ECN, plus adequate switch buffers and clean telemetry. PicOS data center switches support PFC/ECN-based lossless transport on compatible platforms, and high-bandwidth designs increasingly use 400G interfaces - when planning spine or GPU-fabric uplinks, confirm the optics and form factor, including 400G QSFP-DD. Validate congestion behavior, buffer sizing, and NIC compatibility against your specific workload before committing.

How to Plan a PicOS Deployment

A successful deployment starts from design requirements, not a product list. The checklist below maps each requirement to what to verify, why it matters, and what goes wrong if it is skipped.

Two items on this list cause the most avoidable delays. First, decide the server access medium early: whether to standardize on 10GBASE-T or SFP+ optics changes cabling, power, and reach assumptions across every rack. Second, plan breakout cabling deliberately - for example, breaking a single 100G port into 4 x 25G server links - using the right MPO breakout cabling so the port map and fiber assignments line up before installation day.

Before production, validate the design in a lab or pilot: routing convergence, EVPN route behavior, MLAG failover, automation templates, monitoring, and rollback. Then roll out in phases rather than cutting over the whole network at once, unless it is a controlled greenfield build. You can review Pica8's data center switch portfolio and validated platforms to confirm which hardware and feature combinations are supported for your target design.

Common Mistakes to Avoid

Choosing by port speed alone. Speed matters, but routing features, automation support, buffer sizing, optics compatibility, license tier, support model, and upgrade path all belong in the decision.

Ignoring NOS feature and license requirements. The operating system, its version, and its license determine what the network can actually do. Confirm L2/L3, EVPN-VXLAN, MLAG, telemetry, and security coverage against the exact platform before buying.

Underestimating operational change. An automation-ready network needs new processes: who owns templates, who approves changes, how configs are backed up, and how rollback is handled.

Skipping lab validation. For important data center changes, a lab test is not optional. At minimum, validate core fabric functions, redundancy, monitoring, and failure recovery before any traffic depends on them.

Is PicOS Right for Your Data Center?

PicOS data center switches fit enterprises that want a scalable fabric, automation-ready operations, open hardware sourcing, and a structured lifecycle - especially teams planning leaf-spine designs, 10G/25G to 100G upgrades, EVPN-VXLAN fabrics, or environments where manual switch-by-switch configuration is no longer sustainable. They are a weaker fit where there is no automation capability, a hard dependency on single-vendor support, no lab to validate against, or hardware outside the supported matrix.

A practical next step: document your current design and operational pain points, define the target architecture and required feature set, confirm hardware and PicOS version compatibility, and test the fabric in a controlled environment before committing to production.