Home / Solutions / Industrial Networking & Datacom / OTT / Cloud Datacenter Network

DOMAIN 02 · INDUSTRIAL NETWORKING

OTT / Cloud Datacenter Network: Capacity That Grows By Policy, Not By Rebuild

Hosting and cloud businesses do not fail because one switch drops — they stall because the network cannot keep up with tenants arriving faster than cabling can, and server NICs moving from 25G to 100G faster than the fabric was sized for. We engineer general-purpose compute networks from your growth curve, with equipment brand chosen openly at design stage: a spine-leaf fabric, VXLAN/EVPN multi-tenant isolation that scales by policy, high-density 25G/100G access, and automated onboarding so racking the next hundred servers is routine work, not a project. Sized honestly for a small-to-mid hosting provider, a regional cloud, or a large OTT operator.

Why Hosting and Cloud Networks Stall Differently

Four patterns behind almost every "we're outgrowing our network" call we get:

Access speed climbs faster than the fabric was sized forServers arrive with 25G NICs, then 100G, while the network was designed around the speed available when the room was first built — every generation of hardware exposes the gap.

Tenant isolation has to expand elasticallyA hosting business adds tenants continuously; isolation, addressing and provisioning that were fine for ten tenants become a manual, error-prone exercise at a hundred.

White-box and self-developed switches coexist, unmanaged as one fleetDifferent hardware generations and vendors accumulate over years of growth, each with its own management tool — until nobody has one view of the whole fabric.

Racking a hundred servers should not be a projectManual port-by-port configuration does not scale with a growing hosting business — every large onboarding becomes an overnight, error-prone exercise instead of routine work.

Architecture: Spine-Leaf + VXLAN/EVPN Multi-Tenant Overlay + High-Density Access

Capacity that grows by adding a leaf and a policy, not by re-cabling a room:

Architecture drawn by AtlasCommTech following carrier-grade data center design practice. Diagram labels are kept in English for engineering clarity.

Why us: our founder spent 13 years inside the Huawei partner ecosystem delivering carrier networks — where a tenant boundary that leaks or an onboarding that takes all night is treated as a design failure, not a fact of life. We bring that standard to hosting rooms scaling from a handful of racks to a full OTT footprint.

Equipment Options

The solution is sized to your requirements and budget first — the same architecture can be delivered on several vendors' product lines. We help you choose by supply availability in your destination country, budget and your team's operating habits.

Huawei — enterprise campus, WAN and security linesMature ecosystem with a global service network.

ZTE & Wantone — comparable datacom linesPrice-performance direction; supply runs smoother in some markets.

H3C — campus and data-center linesWidely deployed campus and data-center portfolio.

White-box switches under an open management standardA cost-driven option many hosting providers already run; we validate each model and firmware version against the automation platform before it goes into production.

What the Design Delivers

Six properties a properly engineered cloud/hosting fabric has that an ad-hoc, grown-by-accretion network never will:

Access speed that scales without a redesignThe fabric is planned so a move from 25G to 100G server access is a leaf and optics upgrade, not a re-cabled room — growth follows your server refresh cycle, not a forced rebuild.

Tenant isolation that scales by policyVXLAN/EVPN adds a new tenant as a configuration change, not a new set of cables — isolation that held for ten tenants holds the same way at a thousand.

Automated onboarding, not manual port workZero-touch provisioning racks, powers on and configures new servers and leaf switches automatically — a hundred-server rollout becomes routine work instead of an overnight project.

Mixed hardware under one management viewWhite-box and branded switches, old generations and new, sit under one automation and monitoring platform — so nobody has to remember which tool manages which rack.

Non-blocking spine-leaf bandwidthEast-west traffic between tenant workloads crosses at most two hops, so noisy-neighbor congestion stays a policy problem you can fix, not a physical bottleneck you cannot.

Out-of-band management planeA separate small network reaches every device's management port — when the production fabric is the thing that broke, you still have a way in.

Three Sizes, One Design Logic

Tell us your tenant count, server access speed and growth curve — the tier tells you the shape of the fabric:

Numbers we design around:

Access speed sized to your current server NIC generation plus a one-to-two-year roadmap — not the highest number available

Tenant isolation tier matched to your compliance requirement before the topology is drawn, not assumed by default

Onboarding automated from server one — zero-touch provisioning is a day-one design choice, not a retrofit once the manual process breaks

Scale tier	Typical site	What the design includes
Small-to-mid hosting provider	A few racks to one room · dozens to low hundreds of tenants	A collapsed or small spine-leaf fabric, 25G server access with 100G spine uplinks, VXLAN/EVPN tenant isolation from day one, zero-touch onboarding, and out-of-band management — sized to prove the automation before it scales to a bigger room.
Regional cloud	Multiple rooms or a full data hall · hundreds of tenants across mixed workloads	A non-blocking spine-leaf fabric, 25G/100G access with a clear path to higher speeds, EVPN multi-tenant overlay at scale, mixed white-box and branded hardware under one automation platform, and structured capacity planning tied to your growth curve.
Large OTT operator	Multiple hall or multi-site footprint · large-scale continuous server onboarding	Multiple non-blocking fabrics tied together, dense 100G access as standard, fully automated zero-touch onboarding at scale, EVPN spanning multiple pods, and a management platform giving one view across every generation of hardware in the fleet.

Equipment Roles (Categories, Not Models)

The solution is built from these equipment categories — the brand is chosen with you at design stage. Exact models depend on your access speed, tenant count and country — so we spec models after your requirements list, not before.

Role	What it does
Leaf / top-of-rack switch (25G/100G)	Connects tenant servers at high density, with the VXLAN/EVPN overlay terminating here; sized by server NIC count and access speed generation.
Spine switch	The non-blocking crossroads every leaf plugs into, deployed in pairs so bandwidth and resilience grow together as leaves are added.
Border leaf / router	Connects the fabric to the internet and peering; carries the routing boundary between tenant overlays and the outside world.
Automation / orchestration platform	Drives zero-touch onboarding, tenant provisioning and configuration templates across every switch generation and vendor in the fleet.
Out-of-band management switch	A small separate switch wired to every device's management port — your way in when the production fabric is what needs diagnosing.
EVPN control-plane node	Distributes tenant reachability information across leaves so a new tenant or a moved workload propagates as a policy update, not a re-cabling job.

Send us your requirements list — tenant count, server access speed, growth projection, compliance regime — and the model list follows. That order keeps the design honest.

Design Notes & Honest Limits

Read this before you commit:

Server access speed should follow your business, not the highest number available. Check your servers' actual NIC generation and your roadmap for the next two years before speccing 100G everywhere — most fleets are still better served by 25G access with a 100G spine that leaves room to grow.
Whether VXLAN/EVPN isolation is enough depends on your tenant count and compliance requirements — some regulated tenants need physical separation regardless of logical isolation quality. We align on the isolation tier your compliance framework actually needs at design stage, before the topology is drawn.
This page is for elastic, multi-tenant general-purpose compute — not for a single company's business systems and not for GPU training. If you need one enterprise surviving a failure, our Resilient Data Center Network solution is the better fit; if your traffic is GPU collective communication, our AI Computing Datacenter Network solution is tuned for that pattern specifically.
The automation platform has to be validated against every white-box model and firmware version you run, not assumed compatible by default — that validation is real engineering time we budget for, and skipping it is how automated onboarding quietly breaks on exactly the hardware generation nobody tested.
A large-scale onboarding automation project takes real integration time before it pays off — it is not a switch you flip on day one. We size that integration effort honestly in the plan rather than folding it into a hardware quote where it disappears.

FAQ

How is this different from your Resilient Data Center Network and AI Computing Datacenter Network pages?

Three different problems. The resilient data center page is about business systems surviving a failure — a general enterprise server room where availability is the goal. The AI computing page is about a lossless fabric for GPU training traffic specifically. This page is about elastic, multi-tenant general-purpose compute at cloud and hosting scale — the network problem of a growing number of tenants and rising server access speeds, not a single company's server room and not GPU collective communication. If you host or resell compute for many customers and your access speeds are moving from 25G toward 100G, this page is yours.

Do we need 100G on day one or can we grow into it?

Almost nobody needs to start at 100G. Access speed should follow your servers' actual NIC generation and your roadmap for the next one to two years, not a number that looks impressive on a proposal. We design the spine and cabling plant so a later move to 100G is a card swap and a fiber check, not a fabric redesign — but we size day-one access to what your current servers actually use.

Is VXLAN/EVPN enough tenant isolation for our compliance requirements?

It depends on your tenant count and what your compliance regime actually requires, and that is a question we answer at design stage, not after the fact. VXLAN/EVPN gives strong logical isolation that scales by policy rather than by physical cabling, which covers most hosting and multi-tenant cloud requirements. Some regulated tenants require physical separation or dedicated hardware regardless of logical isolation quality — we align on the isolation tier your compliance framework needs before the topology is drawn.

Can this manage a mix of white-box and branded switches?

Yes, that mix is normal in this market and the design assumes it from the start. The automation and orchestration platform is chosen for standards-based management across hardware generations and vendors, and we validate each switch model and firmware version against it before it goes into production — that validation step is real engineering time, not a formality.

How is large-scale server onboarding automated?

Through zero-touch provisioning: a new server or leaf switch is racked, cabled and powered on, and the automation platform recognizes it, applies the correct configuration template and reports it into the fabric's inventory without an engineer manually configuring each port. This is what makes racking hundreds of servers a routine operational task instead of a project every time.

Send us your tenant count and access-speed roadmap

An engineer replies with a fabric design and the equipment-category list. Send us your requirements list — the model list follows.

WhatsApp an engineer →