About PSO Technologies

Provisioning circuits without the dread of change nights.

You run a network. You need the boring parts to be right the first time, every time — and proof of what happened when they aren't. We build the portal, templates and telemetry that make that possible, across any vendor, without lock-in.

4+
Vendor adapters · Cisco · Juniper · Nokia · Arista · and many more
100%
Deploy templates with rollback
'00
Founded · Auckland, NZ
The pattern that broke us

Network provisioning has two failure modes, and both are exhausting.

The first is the handbuilt stack. Engineers copy config out of a spreadsheet into routers at 11pm, one typo from a truck roll, one departure from the whole runbook walking out the door. It scales by hiring.

The second is the vendor slide that promises a self-healing network and can't tell you why it grouped two alerts together. We watched customers pay for both patterns and still not sleep on change nights. Nothing on the market answered what will this actually do to my routers, and how do I put it back if it's wrong? — so we built the answer.

The decisions we made in order

We wrote the rollback template before the deploy template.

Every vendor adapter was drafted with its undo first — Cisco IOS-XR and IOS-XE, Juniper Junos, Nokia SR OS, Arista EOS. No adapter passes code review without its rollback in the same commit. Nothing ships in one direction only, and that single rule became the operating principle for the whole company.

We put a pseudowire-ID registry in front of the render step. Two orders can't race for the same circuit, because the registry hands out the ID before Jinja touches a template. Small decision — it removed the class of bug most home-grown provisioning tools quietly ship.

We wrote to inventory before we wrote to routers. PSO reads NetBox (or your CMDB, or a CSV) on a schedule and matches every planned change against what's actually there — device, port, VLAN, service assignment. A change that references a device the inventory doesn't know about is refused at design time, not at deploy time. The router is the last thing PSO touches, not the first.

Why multi-vendor is hard

A pseudowire is not a pseudowire.

Four vendors, one service, four genuinely different objects. Any tool that treats multi-vendor support as swapping a template will produce configuration that is syntactically valid and functionally wrong.

Cisco IOS-XR Ships today l2vpn xconnect · p2p · pw-id Pseudowire signalled by targeted LDP. A neighbour address and a circuit identifier.
Juniper Junos Templated protocols l2circuit · virtual-circuit-id The same idea with a different name, and a physical MTU that must exceed the service MTU by the encapsulation overhead.
Nokia SR OS Templated service epipe · sap · spoke-sdp The service never references the far end. It binds to a transport tunnel provisioned separately and shared by many services.
Arista EOS Templated router bgp · vpws · patch panel No traditional pseudowire exists. Point-to-point is EVPN, stitched through a patch panel construct, with mirrored virtual circuit identifiers at each end.

PSO models each platform as an adapter that owns its own variable mapping, its own commit semantics and its own verification command. A Nokia deployment checks that the transport tunnel exists before building the service. An Arista deployment reverses the local and remote identifiers between ends. Neither behaviour belongs in a shared template.

What ships today: IOS-XR and IOS-XE, running production circuits. The Junos, SR OS and EOS adapters are templated to the same rule — deploy-with-rollback — and are waiting on device time before they touch a customer.

Next in the queue

Cisco NX-OS. A datacenter-fabric adapter for the spine-and-leaf edge, where enterprises hand off to a carrier through their own DC fabric. Same deploy-with-rollback rule, same audit trail, currently in templating.

How it works · the changes PSO handles

Each change type fails differently. That's the whole point of the checks.

Below are the four Metro Ethernet services PSO provisions today, plus software upgrades and policy-map updates — all handled with the same discipline. Preflight, deploy, verify, rollback. Different shapes on the picture; same rule underneath. If a request doesn't match, it's refused before it touches a router.

EPLShips todayOne port, one circuit

The simplest shape, and the one every other service is measured against. All traffic on the port maps to a single circuit — no VLANs, no multiplexing, no ambiguity.

EVPLShips todayMultiple circuits over one port

Three EVCs multiplexed on one handover, each carrying a distinct VLAN and its own pseudowire ID. In the shape below the third request is refused before it reaches a router — the PWID registry has already handed 2102 to EVC 2. This is the check working.

EP-LANShips todayEvery site to every other

Not a set of pairs — a domain. Sites join a shared any-to-any LAN with MAC learning and policed broadcast. The checks aren't about two ports; they're about the whole domain, which is a different bug surface entirely.

ENNIShips todaySomeone else's network on one end

An external carrier hands traffic to PSO's edge, which lands on an access-node bundle already carrying other customers. The bundle exists before the request arrives. PSO adds one subinterface, nothing else — the restraint is the feature.

UpgradeShips todayIOS-XR software upgrade automation

A single upgrade is a click. Twenty-six of them across four time zones is a career. PSO orchestrates the fleet as a wave — same preflight on each, rollback image staged before install, verify before it moves to the next — so an ops lead runs a maintenance window instead of a script.

QoSShips todayPolicy-map updates

A production QoS change is never a single policy — it's a core policy-map that references a handful of children (voice, business, internet, management) and has to move as one bundle. PSO stages the whole hierarchy per device, snapshots old counters before the new parent loads, and stops the wave on any drop-rate anomaly.

Capacity planningShips todayOne capacity book — trunks, ports, ENNIs

PSO ingests interface counters over gNMI and tracks every asset that has a ceiling: core trunks against bit rate, PE customer-facing ports against sub-interface count and S-VLAN space, shared ENNIs against the slice PSO owns. A new EVC order is refused at design time when it would push any of those past threshold — with the offending asset named, not a generic "capacity exceeded".

What we stand for

Five operating principles. Each one forbids something specific.

  1. 01 · Deploy Rollback comes first. Every deploy template ships with the undo that reverses it. We write the undo first — deploy without a matching rollback is refused at code review.
  2. 02 · Gates Preflight or don't ship. Every change class — provisioning, software upgrades, policy-maps — has its own preflight that must pass before anything touches a router. If the environment can't let the check run (missing credentials, unreachable device, inventory mismatch), the change doesn't ship. The gate is not optional, even for the engineer who wrote it.
  3. 03 · Audit Every change is audited. Every provisioning step writes to an append-only log with the actor, the timestamp, and the diff. If a circuit acts strange next Tuesday, we can tell you what touched it.
  4. 04 · Proof Numbers, not adjectives. Every claim on this page has a demo behind it. The 26-device upgrade wave, the pm-core policy hierarchy, the refused EVC — all real code running against a real test lab. If we can't show you the mechanism, we don't put the claim on the page.
  5. 05 · Demo The demo is the pitch. You see a real router provision a real circuit — render, preflight, deploy, verify, reverse. Nothing is prerecorded, nothing is mocked. If a feature can't survive a live demo, it doesn't ship.

See it provision one circuit.

Book 30 minutes. We'll order an EPL through the portal on a real router — render, preflight, deploy, verify, and reverse it. The demo is the pitch.

Book a call