Data centre networks

A fabric built from what the network carries

We start from what the network must carry: traffic between servers, storage and the outside world, systems that can't stop, and the racks and sites to come. That often means a spine-leaf fabric with EVPN-VXLAN: the physical part grows by adding switches, and the logical networks change on top.

• Spine and leafPhysical structure Spine and leaf Servers in each rack connect to one leaf switch, or two where they need dual paths, and every leaf connects to every spine, so traffic between any two racks takes the same number of hops. We size it from the racks, the traffic between servers and port speeds, from 25G to 800G, for today and the next expansion.
• EVPN-VXLANLogical networks EVPN-VXLAN VXLAN carries the segments across the physical structure, and EVPN tracks where each address lives. A segment can then span several racks and sites, VRFs keep apart what must stay separate, and names and addresses follow one plan.
• Redundancy where it's neededAvailability Redundancy where it's needed Dual paths through the tiers that carry what can't stop, down to the servers' own connections, so a switch or link can fail or be taken out for maintenance while traffic takes the other path.

Automation and monitoring from the start

A network that will grow for years must be safe to change, so automation and monitoring are built into the design.

• Configuration as codeSwitch configuration lives in a repository and rolls out through a pipeline that validates every change. Every change is reviewed first and can be rolled back.
• Monitoring by what the network carriesAlerts show which systems and flows are affected, not just which port went down, for example from telemetry the switches stream over gNMI.
• CapacityLinks and ports are tracked, so the next expansion is planned before it's needed.

How a network project usually runs

The implementation plan is made together with the design, so the business can keep running throughout.

• DiscoveryWhat the network must carry, and what must stay separate The existing network and what's connected The systems that can't stop, and what they need Result The requirements that design and implementation start from
• DesignTopology and redundancy Segments, VRFs and address plan Automation and monitoring Result Target architecture with the reasons behind each decision
• ImplementationIn stages while the business keeps running A plan and a way back for every step Flow checks after each stage Result A deployed network with documented configuration
• ManagementDocumentation and runbooks Changes through automation Ongoing help as the network grows Result A network your team can run and extend

A network your team can run

We write documentation and runbooks for the people who will run the network, and walk through them together before handover. We stay available as the network grows.

• Add a segment through the automation
• Replace a leaf switch by the runbook
• Trace an alert to the systems it affects
• Architecture and decisionsTopology, redundancy and segments, with the reasons behind them.
• Configuration as codeSwitch configuration and templates in your repository.
• Segment and address planWhich segments and VRFs exist, and what they carry.
• RunbooksReplacing a switch, adding a rack and troubleshooting.
• MonitoringAlerts and views tied to what the network carries.

Related services