What we do · Network
Datacenter fabric: EVPN/VXLAN on Cisco Nexus
Inside Digital Realty Athens, every server, blade chassis, storage host and customer firewall we run connects to a Cisco Nexus 9000 leaf and spine fabric running BGP EVPN with VXLAN. Every host is dual-homed, any VLAN can live on any leaf, and your gateway is the same address everywhere, so workloads move and fail over without renumbering.
What it is
A Clos fabric: spines on top, leaf pairs underneath, border leaves handing routed traffic to our edge routers. EVPN is the control plane, so the switches learn where every address lives through BGP instead of flooding to find out. VXLAN carries each Layer 2 segment across the fabric, which means your network is not tied to the rack your server happens to sit in.
How we build it
- Spines as pure route reflectors. No tunnel endpoints live on the spines, by design.
- Leaves in vPC pairs. Servers attach with LACP port-channels that are true virtual port-channels across both switches of a pair.
- Deterministic blade cabling. HPE c7000 blade enclosures attach through Cisco Nexus 2000 fabric extenders, one per fabric side.
- Anycast gateways. On every leaf.
- No multicast dependency. Broadcast and unknown traffic is replicated by BGP ingress replication, which keeps the underlay simple and predictable.
- A numbering rule enforced by machine. Every segment's VXLAN identifier is derived from its local VLAN by a fixed rule, with explicit route targets. An automated check reads the full map from every leaf every hour, confirms the leaves are identical and obey the rule, and compares a cryptographic fingerprint of the whole map against a signed baseline in version control. Drift pages an engineer. An intended change has to be re-signed, so every fabric change carries an author and an audit trail.
- Native routing for container platforms. Kubernetes and OpenShift clusters advertise their public service addresses into the fabric over eBGP from each node to both leaves of its pair, with BFD for sub-two-second failure detection and prefix lists tightened to exact host routes.
- Bonds that use both links. Every bonded server we build hashes on layer 3 and layer 4, with the switch side set to match, so parallel flows actually spread across both members.
What it protects you from
- A single switch, link, fabric extender or NIC failure taking your host offline.
- A mistyped VLAN or VXLAN identifier quietly bridging two tenants' networks.
- Slow failover, where a public address takes minutes to move instead of seconds.
- A routine VLAN addition stripping existing VLANs off a live trunk.
- Paying for two links and using one.
In practice
Failover proven by test. In a controlled failure test we rebooted a container cluster node while it was the preferred path for a live public address. The fabric converged onto a healthy node about three seconds later, and the public address never left the fabric routing table.
A blade rack wired before the blades arrived. Ahead of launching new customer platforms, we built the complete port-channel and vPC topology for an entire blade rack in one batch, before most of the blades physically existed. Each database cluster was placed with every replica in a different chassis, so no single chassis can break quorum. Launch day was a power-on, not a cabling job.
Both links of every bond in use. After every bonded build we read the per-port counters to prove both links carry traffic.
Why EuroVPS
- A real EVPN/VXLAN fabric on Cisco Nexus 9000, the same architecture large enterprises and carriers run.
- Dual-homing for every host, not just the expensive ones.
- Tenant isolation checked by machine every hour, against a signed record of what the fabric should be.
- Container ingress routed natively with BFD, not bolted on through a single load balancer.
FAQ
Is my traffic isolated from other customers? Yes. Your segments carry their own identifiers and route targets, and the hourly integrity check exists precisely to make an accidental bridge between tenants impossible to miss.
What happens if a switch fails? Your server is bonded across both switches of a pair and your gateway exists on every leaf. Traffic continues on the surviving switch.
Can I have my own VLANs and subnets? Yes. Dedicated segments and public subnets are built as anycast gateways across the fabric, without touching anyone else's configuration.
Can my Kubernetes cluster announce its own service addresses? Yes. We peer each node with the fabric over eBGP with BFD, so a failed node is routed around in seconds.
If you want your servers on a fabric that is built and checked like this, talk to an engineer.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.