Bachelors Program in IT
Advanced Networking
•
Bachelor
Data Center and Cloud Networking
Introduction
Modern information systems depend on networks that are programmable, highly available, and capable of connecting physical servers, virtual machines, containers, storage systems, users, and cloud services. A traditional three-tier data-center network—access, aggregation, and core—was designed primarily for north–south traffic between clients and servers. Virtualized applications, microservices, distributed databases, and analytics workloads create substantial east–west traffic between servers. This change has encouraged the adoption of spine–leaf fabrics, software-defined overlays, automated control planes, and cloud-native connectivity models.
This chapter examines the architecture and operation of contemporary data-center and cloud networks. It connects protocol theory with practical design decisions, including redundancy, convergence, segmentation, load balancing, storage performance, virtualization, container networking, hybrid connectivity, cloud routing, and security governance.
Learning Objectives
By the end of this chapter, students should be able to:
Explain the structure and design rationale of spine–leaf data-center fabrics.
Distinguish underlay networks from overlay networks and explain VXLAN and EVPN.
Analyze the roles of load balancers, storage networks, hypervisors, and container platforms.
Compare major approaches to hybrid-cloud and multi-cloud connectivity.
Explain cloud routing, security groups, network policies, and shared responsibility.
Evaluate availability, scalability, performance, security, and governance trade-offs.
Propose a defensible architecture for a distributed application.
1. Data-Center Network Requirements
A data-center network must provide connectivity between compute, storage, management, and external networks. Its principal requirements are:
High availability: failure of a link, switch, interface, or device should not unnecessarily interrupt service.
Predictable latency: distributed applications often require consistent rather than merely high bandwidth.
Scalability: the architecture should support additional racks, hosts, tenants, and workloads.
Automation: configuration must be repeatable and compatible with infrastructure-as-code practices.
Observability: operators need topology, flow, performance, and security information.
Security: identity, least privilege, encryption, and policy enforcement must operate at appropriate layers.
Traffic is commonly classified as north–south, between the data center and external users or services, and east–west, between workloads inside the data center. Modern applications generate substantial east–west traffic because a single user request may invoke multiple microservices, databases, caches, and message brokers.
2. Spine–Leaf Fabrics
A spine–leaf fabric is a two-tier topology. Every leaf switch connects to every spine switch, while servers, storage devices, and service appliances attach to leaf switches. Spines generally do not connect directly to one another, and leaves generally do not connect directly to other leaves except where a special design requires it.
A packet traveling between two different leaf switches normally follows the path:
If all links have comparable capacity, the topology provides relatively predictable path length. Equal-cost multipath (ECMP) routing distributes flows across multiple available paths. ECMP usually balances flows, not individual packets, because per-packet balancing could cause reordering. A hash based on fields such as source and destination addresses and transport ports selects a path.
Spine leaf data center fabric
Figure: Spine leaf data center fabric
Figure: A spine–leaf fabric provides multiple equal-cost paths between leaf switches.
A simplified path-count observation is useful. If a fabric has S spine switches and a leaf has one link to every spine, two different leaves have up to S equal-cost spine paths, subject to link, routing, and failure conditions. This is not a bandwidth guarantee: the effective capacity depends on link rates, oversubscription, traffic distribution, and failures.
Oversubscription compares potential downstream host-facing capacity with upstream capacity. If a leaf has H host-facing links of rate r_h and U uplinks of rate r_u, a simple capacity ratio is:
O = (H × rh) ÷ (U × ru)
Here, O is dimensionless. The calculation assumes all links are active and uses nominal line rates; it does not account for protocol overhead, burstiness, or traffic locality. For example, 48 host links at 25 Gb/s and 6 uplinks at 100 Gb/s give O = (48 × 25) ÷ (6 × 100) = 2. Thus, the access-facing capacity is twice the uplink capacity. Whether that is acceptable depends on workload behavior and service-level objectives.
Layer 3 routed underlays are often preferred because they limit broadcast domains and support ECMP. Link-state protocols such as OSPF or IS-IS, or BGP-based designs, can provide reachability among loopbacks and point-to-point links. A design must also address MTU, failure detection, route convergence, telemetry, and automation.
3. Underlays, Overlays, VXLAN, and EVPN
The underlay is the physical or routed IP network that transports packets. The overlay is a logical network built on top of it. Overlays permit logical segments to span multiple physical locations without requiring the physical network to carry every tenant VLAN end to end.
VXLAN, or Virtual Extensible LAN, encapsulates an Ethernet frame inside UDP and IP. A 24-bit VXLAN Network Identifier (VNI) provides a much larger logical segment space than the 12-bit VLAN identifier. A VXLAN tunnel endpoint (VTEP) performs encapsulation and decapsulation, commonly at a leaf switch or virtual switch.
The outer network forwards according to VTEP addresses, while the inner frame preserves the tenant’s logical addressing. VXLAN therefore separates tenant topology from the physical topology, but it introduces overhead. The underlay MTU must be large enough for the original frame plus encapsulation headers; otherwise, fragmentation or packet loss can occur. Operators should calculate and test the required MTU rather than assuming that a nominal setting is sufficient.
A flood-and-learn overlay can discover remote MAC addresses through data-plane flooding. EVPN improves this model by using a control plane, typically BGP, to advertise MAC and IP reachability. EVPN can support:
MAC address advertisement between VTEPs.
Integrated routing and bridging.
Anycast gateways for consistent default-gateway behavior.
Multihoming and all-active redundancy.
More controlled handling of broadcast, unknown-unicast, and multicast traffic.
VXLAN supplies encapsulation; EVPN supplies a control-plane framework. They are related but not interchangeable terms. A correct design specifies the VTEP role, VNI-to-segment mapping, route targets, route distinguishers, gateway placement, failure behavior, and policy boundaries.
4. Virtualization and Network Functions
A hypervisor allows multiple virtual machines (VMs) to share a physical server. Each VM has a virtual network interface connected to a virtual switch. Traffic may be switched locally, sent through a distributed virtual switch, or forwarded to a physical leaf switch through a host uplink.
Virtualization creates several networking concerns:
Live migration: a VM may move while retaining its address, requiring consistent Layer 2 or carefully designed Layer 3 reachability.
Resource contention: CPU, memory, NIC queues, and uplinks can become bottlenecks.
Security boundaries: a virtual switch and hypervisor must enforce isolation between tenants.
Visibility: physical switch telemetry alone may not reveal VM-level behavior.
Network function virtualization: firewalls, routers, and load balancers may run as virtual appliances, but their performance depends on acceleration, packet processing, and placement.
A virtual appliance should not automatically be treated as equivalent to a purpose-built appliance. Evaluation should include throughput, packets per second, latency, state synchronization, failure recovery, licensing, and operational integration.
5. Container Networking
Containers share the host operating system kernel and are generally more lightweight than VMs. A container platform assigns each workload an identity and network interface, often through a Container Network Interface (CNI) plugin. Common models include:
Bridge networking: containers connect to a host bridge and use address translation or routing.
Routed networking: container prefixes are routed through the host or fabric.
Overlay networking: encapsulation connects containers across hosts.
Direct attachment: a workload receives an address from a physical or virtual network, useful for selected high-performance applications.
Kubernetes commonly separates pod networking from service discovery. A pod receives an address, while a Service provides a stable virtual endpoint for a changing set of pods. An ingress or gateway exposes selected services externally. NetworkPolicy can restrict which namespaces, pods, or external endpoints may communicate, but its exact capabilities depend on the CNI implementation.
Containers increase network dynamism. Addresses and endpoints may change frequently, so policy should be based on workload identity, labels, namespaces, and service accounts where possible rather than only on static IP addresses. Observability must include DNS, service discovery, API objects, flow logs, and node-level behavior.
6. Load Balancing
Load balancing distributes client requests across service instances. A layer-4 load balancer uses transport information such as TCP or UDP ports; a layer-7 load balancer can inspect application information such as HTTP paths, headers, cookies, or TLS attributes.
Important mechanisms include:
Health checks: remove failed or unhealthy instances.
Round robin: rotate among servers, appropriate when capacities are similar.
Weighted distribution: send more traffic to stronger or preferred instances.
Least connections: favor the instance with fewer active connections.
Persistence: keep a client associated with an instance when application state requires it.
TLS termination: decrypt at the balancer, which simplifies backend processing but creates a sensitive trust boundary.
A load balancer is not a substitute for application resilience. Connection draining, retry behavior, idempotency, timeouts, circuit breakers, and capacity planning remain necessary. Poorly chosen retries can amplify overload, creating a retry storm.
Availability can be improved through redundant load-balancer nodes and distributed health checking. However, stateful connection tracking and synchronization can make failover more difficult than simple active–standby diagrams suggest.
7. Storage Networking
Data centers use several storage networking models:
Fibre Channel (FC): a specialized, low-loss fabric often used with storage area networks.
iSCSI: SCSI commands carried over IP, benefiting from Ethernet infrastructure.
Network File System (NFS) and SMB: file-level access over IP networks.
NVMe over Fabrics (NVMe-oF): transports NVMe commands over fabrics such as Ethernet or Fibre Channel.
Storage traffic is sensitive to latency, jitter, loss, queueing, and congestion. Bandwidth alone is insufficient. A useful performance relationship is:
IOPS ≈ (transfer rate in bytes/s) ÷ (I/O size in bytes)
This approximation assumes the device and protocol can sustain the rate and that I/O operations are continuously offered. For example, 10 GiB/s with 64 KiB operations gives approximately 10 × 2³⁰ ÷ (64 × 2¹⁰) = 163,840 IOPS. The result is theoretical and does not include protocol overhead, latency limits, queue depth, or device behavior.
Designers may use separate physical fabrics, VLANs, VRFs, or quality-of-service policies for storage. Lossless Ethernet techniques may be considered for selected protocols, but making an entire network lossless is difficult and can cause head-of-line blocking or congestion propagation. Congestion management should therefore be designed and tested for the actual storage protocol.
8. Hybrid-Cloud and Multi-Cloud Connectivity
Hybrid cloud combines private infrastructure with one or more public-cloud environments. Connectivity options include:
Site-to-site IPsec VPN over the Internet.
Dedicated private circuits supplied by a cloud provider or carrier.
SD-WAN overlays.
Cloud exchange or colocation interconnection.
Application-level connectivity through APIs, queues, and identity federation.
VPNs are comparatively quick to deploy and encrypt traffic, but their performance and path stability depend on the Internet and tunnel endpoints. Dedicated connections can offer more predictable performance, yet they require planning, contracts, redundancy, and appropriate provider diversity.
A resilient design should avoid a single circuit, edge router, availability zone, or provider location. It should also define routing ownership. BGP may exchange prefixes between an enterprise and cloud edge, but route filters, maximum-prefix limits, authentication, summarization, and failover testing are essential.
Multi-cloud connectivity should not be pursued merely to create a diagram with several providers. It may be justified by regulatory requirements, resilience, specialized services, bargaining power, or workload placement. Conversely, it introduces inconsistent APIs, identity systems, logging formats, latency paths, and egress costs. Architecture should distinguish genuine portability from duplicated complexity.
9. Cloud Routing and Security Controls
Public-cloud networks commonly provide virtual networks, subnets, route tables, virtual interfaces, gateways, and managed services. A subnet’s route table determines where traffic is sent, while a gateway or attachment connects the virtual network to the Internet, private enterprise network, or another virtual network.
Cloud routing is often distributed rather than controlled by a single traditional router. Providers may implement implicit routes, system routes, peering routes, transit hubs, and user-defined routes. Engineers must understand precedence rules, propagation behavior, asymmetric routing risks, and the difference between control-plane reachability and actual service authorization.
A security group is generally a stateful virtual firewall associated with a workload interface or instance. Inbound rules permit selected traffic; return traffic is usually allowed automatically for an established flow. A network ACL or subnet filter is commonly stateless and therefore requires explicit return-direction rules. Exact semantics vary by provider, so documentation and testing are necessary.
Security groups should follow least privilege:
permit only required protocols and ports;
restrict sources to known groups, prefixes, or identities;
avoid unrestricted administrative access from the Internet;
separate management, application, and data tiers;
log accepted and rejected flows where feasible;
review stale rules continuously.
Encryption in transit, key management, secrets management, vulnerability management, and centralized logging complement network filters. A permitted network flow does not prove that an application request is authorized.
10. Shared Responsibility and Governance
In cloud computing, the provider is responsible for selected components of the cloud infrastructure, while the customer remains responsible for configuration, identities, data, workloads, and often operating systems. The boundary changes by service model:
This division is not a transfer of accountability. Organizations remain responsible for compliance, appropriate access, data classification, incident response, and business continuity. Governance should include asset inventories, policy-as-code, change control, separation of duties, retention rules, audit evidence, and recovery exercises.
Ethical and regulatory concerns include exposure of personal data, cross-border transfer, surveillance, vendor lock-in, opaque automated decisions, and inadequate incident disclosure. Network architecture should support data minimization and purpose limitation rather than treating all traffic and data as equally permissible.
11. Worked Design Example
An online retailer has web, application, and database tiers. It operates two private data centers and uses a public cloud for seasonal capacity. The service requires high availability and must keep customer records in a controlled environment.
A defensible design is as follows:
Build routed spine–leaf underlays in both data centers, using ECMP and redundant uplinks.
Use VXLAN with EVPN for tenant and service segmentation where workloads must span leaf switches.
Place redundant layer-7 load balancers in front of web and application tiers, with health checks and connection draining.
Keep databases on a dedicated storage network using redundant paths, measured latency, and tested failover.
Run stateless application components in containers, with service discovery and deny-by-default network policies.
Connect the data centers and cloud through two diverse private connections, with IPsec as a tested backup.
Exchange only summarized, approved prefixes through controlled BGP sessions.
Permit cloud application tiers to reach on-premises database endpoints only on required ports and through authenticated application identities.
Centralize flow logs, load-balancer logs, identity events, and configuration changes.
Test failure of a spine, leaf, circuit, load balancer, container node, and cloud region.
The design does not assume that every component must be active–active. Stateful databases may use synchronous replication within a latency boundary and asynchronous replication across regions. Recovery objectives should determine placement. Recovery time objective (RTO) is the maximum acceptable restoration time; recovery point objective (RPO) is the maximum acceptable data-loss interval. These are business requirements translated into technical design, not merely network settings.
Case Study: Illustrative Retail Migration
Background. An illustrative retailer operated a three-tier data center with VLAN extension between two sites. Broadcast growth, manual changes, and unpredictable failover caused outages during promotional events.
Problem. The company needed to scale application instances rapidly, connect cloud capacity, and isolate payment workloads. Its existing Layer 2 extension made failure domains large and troubleshooting difficult.
Analysis. Engineers measured east–west traffic, storage latency, failure recovery, and peak connection rates. They discovered that the principal bottleneck was not Internet bandwidth but uneven traffic distribution and overloaded aggregation switches. They also found security rules based on old IP ranges rather than application relationships.
Approach. The company introduced routed spine–leaf fabrics, EVPN-VXLAN for selected logical segments, anycast gateways, redundant load balancers, and container network policies. Payment systems were placed in a separate security zone. Cloud connectivity used two diverse circuits and an encrypted backup tunnel. Infrastructure changes were delivered through reviewed automation, and flow logs were retained for investigation.
Outcome. Failure domains became smaller, new racks could be added without redesigning the core, and cloud expansion no longer required extending every internal VLAN. The retailer still had to address operational complexity, provider-specific services, and the cost of duplicated connectivity.
Learning points. Overlay technology does not remove the need for a reliable underlay. Automation improves consistency but can distribute errors rapidly. Segmentation is strongest when network controls, workload identity, application authorization, and monitoring reinforce one another.
12. Design Challenges and Best Practices
Common challenges include MTU mismatches, asymmetric routing, ECMP hash polarization, noisy neighbors, insufficient observability, untested failover, excessive Layer 2 extension, stale security rules, and dependence on one cloud provider or circuit. Container platforms add rapid endpoint churn and multiple policy layers. Storage networks add sensitivity to congestion and queueing.
Recommended practices are:
prefer simple routed failure domains where application requirements permit;
document underlay, overlay, VNI, VRF, and route-policy relationships;
standardize MTU and validate encapsulated traffic;
use redundant control-plane and data-plane paths;
automate configuration with peer review and rollback;
monitor latency, loss, utilization, queue depth, flows, and control-plane health;
test failure, restoration, and security assumptions regularly;
apply least privilege to routes, security groups, identities, and management access;
measure actual workload behavior before selecting oversubscription or storage designs;
control egress, licensing, and inter-region costs;
maintain provider exit plans for critical services.
Artificial intelligence and machine learning can assist anomaly detection, capacity forecasting, configuration analysis, and root-cause correlation. They should not be treated as infallible. Training data may be incomplete, explanations may be weak, and automated remediation can amplify an incorrect diagnosis. Human approval, bounded actions, audit trails, and safe rollback remain necessary.
Chapter Summary
Contemporary data-center networks use spine–leaf fabrics to provide scalable, predictable paths for east–west traffic. ECMP distributes flows across routed underlays, while overlays such as VXLAN provide logical segmentation independent of physical topology. EVPN supplies a control plane for MAC and IP reachability and supports features such as integrated routing and bridging and multihoming.
Virtual machines and containers increase network dynamism and require visibility beyond physical switch ports. Load balancers improve distribution and availability but must be combined with health checks, graceful draining, resilient applications, and sound retry behavior. Storage networking must account for latency, loss, queueing, IOPS, and protocol-specific requirements rather than bandwidth alone.
Hybrid and multi-cloud architectures use VPNs, dedicated circuits, SD-WAN, exchanges, and application-level integration. Cloud routing and security groups must be understood together with identity, encryption, logging, and provider-specific semantics. Shared responsibility means that cloud providers manage selected infrastructure while customers remain accountable for configuration, data, access, compliance, and recovery. Effective designs therefore combine technical architecture with automation, governance, testing, and ethical handling of data.
Key Terms
Spine–leaf fabric: A two-tier data-center topology in which leaf switches connect to all or many spine switches.
East–west traffic: Traffic exchanged among internal workloads.
North–south traffic: Traffic entering or leaving a data-center environment.
ECMP: Equal-cost multipath routing across multiple routes of equal cost.
Underlay: The physical or routed network carrying overlay packets.
Overlay: A logical network constructed over an underlying network.
VXLAN: UDP-based encapsulation that carries Ethernet frames across an IP network.
VTEP: VXLAN tunnel endpoint that encapsulates or decapsulates VXLAN traffic.
VNI: VXLAN Network Identifier used to identify a logical segment.
EVPN: A BGP-based control-plane technology for Ethernet virtual networks.
Anycast gateway: A gateway address consistently available from multiple network devices.
Virtual machine: A software-defined computer running through a hypervisor.
Container: An isolated application execution environment sharing the host kernel.
CNI: Container Network Interface, a standard integration model for container networking.
Load balancer: A system that distributes connections or requests among service instances.
IOPS: Input/output operations per second.
Security group: A commonly stateful cloud firewall policy associated with a workload interface.
Hybrid cloud: An architecture combining private infrastructure and public-cloud services.
RTO: Maximum acceptable time to restore service.
RPO: Maximum acceptable period of data loss measured in time.
Review Questions
5 Short Answer Questions
What is the principal difference between east–west and north–south traffic?
Why is ECMP commonly used in a spine–leaf fabric?
What roles do VXLAN and EVPN perform?
Why must an overlay design consider MTU?
What does the shared-responsibility model mean in cloud computing?
5 Long Answer Questions
Explain the architecture, advantages, and limitations of a spine–leaf fabric.
Compare flood-and-learn VXLAN operation with EVPN-controlled operation.
Discuss the networking requirements of virtual machines and containers.
Compare VPN, dedicated-circuit, and application-level approaches to hybrid-cloud connectivity.
Explain how cloud routing, security groups, identity, and logging jointly support defense in depth.
3 Analytical / Application Questions
A leaf has 48 host-facing 25 Gb/s links and 6 uplinks of 100 Gb/s. Calculate its nominal oversubscription ratio and evaluate whether the ratio is appropriate for a storage-intensive workload. State additional measurements you would require.
Design a network for a three-tier application spanning two data centers and one public cloud. Specify segmentation, routing, load balancing, storage connectivity, failure handling, and governance controls.
A Kubernetes application experiences intermittent timeouts after a new overlay network is introduced. Develop a structured diagnostic plan addressing MTU, routing, security policy, service discovery, load balancing, and observability.
Multiple Choice Questions with Answers
Question 1
Which topology most directly provides multiple equal-cost paths between data-center leaf switches?
A. Bus topology
B. Spine–leaf fabric
C. Single-tier hub-and-spoke topology
D. Ring topology
Correct Answer: B. Spine–leaf fabric
Question 2
What is the primary purpose of VXLAN?
A. To replace all routing protocols
B. To encrypt every application payload
C. To carry logical Ethernet segments across an IP underlay
D. To provide physical storage media
Correct Answer: C. To carry logical Ethernet segments across an IP underlay
Question 3
What does EVPN commonly provide in a VXLAN design?
A. A BGP-based control plane for MAC and IP reachability
B. A replacement for Ethernet cabling
C. A disk-replication protocol
D. A CPU scheduling algorithm
Correct Answer: A. A BGP-based control plane for MAC and IP reachability
Question 4
Why is per-flow rather than per-packet ECMP commonly used?
A. To increase broadcast traffic
B. To avoid packet reordering
C. To disable redundancy
D. To remove the need for routing tables
Correct Answer: B. To avoid packet reordering
Question 5
A leaf has 48 host links at 25 Gb/s and 6 uplinks at 100 Gb/s. Using O = (H × r_h) ÷ (U × r_u), what is the nominal oversubscription ratio?
A. 0.5
B. 1
C. 2
D. 4
Correct Answer: C. 2
Question 6
Which statement about a layer-7 load balancer is correct?
A. It can use application information such as HTTP paths
B. It operates only on optical signals
C. It cannot perform health checks
D. It eliminates the need for resilient applications
Correct Answer: A. It can use application information such as HTTP paths
Question 7
Which metric is most directly associated with storage I/O operation rate?
A. VNI
B. IOPS
C. BGP local preference
D. RTO only
Correct Answer: B. IOPS
Question 8
Which approach generally offers the most predictable private connectivity between an enterprise and a cloud provider, when correctly provisioned?
A. A dedicated private circuit
B. An uncontrolled public route
C. A broadcast-only VLAN
D. A local container bridge
Correct Answer: A. A dedicated private circuit
Question 9
What is a key characteristic of a typical stateful cloud security group?
A. It automatically authorizes every Internet source
B. It commonly permits return traffic for an established allowed flow
C. It replaces identity management
D. It operates only on storage devices
Correct Answer: B. It commonly permits return traffic for an established allowed flow
Question 10
Which statement best describes cloud shared responsibility?
A. The provider is responsible for every customer configuration
B. The customer has no responsibility after deployment
C. Provider and customer responsibilities vary by service model and remain jointly relevant to security
D. Only the network carrier has security responsibility
Correct Answer: C. Provider and customer responsibilities vary by service model and remain jointly relevant to security