Cloud, Data-Center and Edge Networking

Introduction

Modern applications rarely execute within a single server or network. A user request may traverse a content-delivery network (CDN), cloud load balancer, container ingress gateway, service mesh, distributed database and edge service. The network must therefore provide scalable connectivity, predictable performance, rapid failure recovery, workload mobility, security segmentation and operational visibility.

Traditional three-tier data-center networks were optimized primarily for north–south traffic between clients and servers. Cloud-native applications generate substantial east–west traffic among services, storage systems and compute clusters. Leaf–spine fabrics, equal-cost multipath routing (ECMP), overlays and Ethernet VPN (EVPN) evolved to support this traffic efficiently. At wider scope, cloud interconnects, multi-cloud architectures, CDNs and edge platforms connect distributed application components across administrative and geographic boundaries.

The central engineering challenge is not merely achieving high link rates. It is matching capacity, topology, routing, queueing, convergence and failure isolation to application requirements such as tail latency, availability, throughput, consistency and regulatory compliance.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Analyze leaf–spine fabrics using capacity, oversubscription and failure-domain models.

2. Explain underlay, overlay, VXLAN and BGP EVPN operation.

3. Evaluate ECMP, flow-aware load balancing and application delivery mechanisms.

4. Apply serialization, queueing and latency models to network design.

5. Compare CDN, cloud-connectivity and multi-cloud networking alternatives.

6. Explain container networking and service-mesh data and control planes.

7. Analyze convergence behavior and resilience under link, device and domain failures.

8. Relate edge-network design to distributed application requirements.

9. Assess operational, security, governance and sustainability implications.

1. Data-Center Traffic and Design Requirements

Data-center traffic is commonly classified as:

• North–south traffic: communication entering or leaving a data center or cloud region.
• East–west traffic: communication among workloads, services or storage systems inside the environment.

Cloud applications frequently combine short latency-sensitive flows, sometimes called mice flows, with long high-volume elephant flows. Short flows are sensitive to queueing and connection-establishment delay, whereas elephant flows can create persistent congestion and affect many other flows.

A network design should be evaluated against explicit service objectives:

• throughput and admissible traffic matrices;
• median and tail latency, such as the 99th percentile;
• availability and recovery time;
• tenant isolation and security policy;
• scalability of forwarding and control-plane state;
• observability and operational complexity;
• cost, energy use and portability.

Average utilization alone is insufficient. A fabric operating at moderate average load may still experience microbursts, incast or hash collisions that overflow buffers and increase tail latency.

2. Leaf–Spine Fabrics

2.1 Topology and forwarding

A leaf–spine fabric is a folded Clos topology. End systems connect to leaf switches, while each leaf connects to every spine. Spines normally do not connect directly to one another, and leaves do not rely on lateral links for ordinary forwarding.

A packet between endpoints on different leaves follows a leaf–spine–leaf path. With equal-rate links and symmetric wiring, multiple shortest paths exist. Layer 3 routing in the underlay and ECMP distribute flows over these paths.

The regular topology offers several advantages:

• predictable hop count;
• horizontal expansion by adding leaves or spines, subject to port limits;
• multiple equal-cost paths;
• bounded failure domains;
• simpler automation than irregular topologies.

2.2 Capacity and oversubscription

Suppose a leaf has:

• H host-facing ports, each of rate r_h;
• S spine-facing uplinks, each of rate r_u.

Its downlink capacity is

C_down = H r_h,

and its fabric-facing capacity is

C_up = S r_u.

The leaf oversubscription ratio is

O = C_down / C_up.

An O value of 1 represents a locally non-oversubscribed leaf. A value of 3 means the attached endpoints could collectively offer three times the leaf's uplink capacity. This ratio is a capacity indicator, not a guarantee of application performance. Actual feasibility depends on the traffic matrix, endpoint limits, destination concentration and failures.

Worked Example 1: Leaf capacity

A leaf has 48 ports at 25 Gb/s and four uplinks at 100 Gb/s.

C_down = 48 × 25 = 1,200 Gb/s.

C_up = 4 × 100 = 400 Gb/s.

Therefore,

O = 1,200/400 = 3.

The nominal oversubscription is 3:1. If one 100 Gb/s uplink fails, available uplink capacity becomes 300 Gb/s and the failure-state ratio becomes 1,200/300 = 4:1.

If there are L identical leaves, aggregate leaf-to-spine capacity is L S r_u. However, not all of this is simultaneously available to an arbitrary traffic matrix. For any chosen network cut, traffic crossing that cut cannot exceed the sum of capacities of links crossing it. Cut analysis is therefore more rigorous than relying only on port-count ratios.

A fabric described as non-blocking must also specify its traffic model. Under a hose model, each endpoint or leaf has bounded ingress and egress demand, but traffic destinations may vary. Under a fixed traffic matrix, admissibility can be tested against link and cut constraints. No topology can deliver a demand matrix that concentrates more traffic on a destination leaf than that leaf's available downlink or uplink capacity.

2.3 ECMP and load distribution

ECMP normally hashes selected packet-header fields, such as source and destination addresses, transport ports and protocol, to choose one next hop. Flow-consistent hashing avoids packet reordering within a flow, but it does not guarantee equal byte distribution. A small number of elephant flows may collide on one uplink while other links remain underutilized.

Alternative mechanisms include:

• resilient hashing, which minimizes flow remapping after a next-hop change;
• weighted ECMP for unequal-capacity paths;
• flowlet switching, which changes paths only across sufficiently large inter-packet gaps;
• adaptive routing based on congestion information;
• centralized traffic engineering for selected large flows.

Adaptive methods can improve utilization but may cause instability or packet reordering if measurements are delayed or decisions are too aggressive.

2.4 Failure domains and degraded capacity

A failure domain is the set of services or components affected by a common fault. Relevant domains include a link, line card, leaf, spine, rack, power feed, availability zone, metro region and provider backbone.

If a leaf has S equal-capacity uplinks and f independent uplinks become unavailable, its residual uplink capacity is

C_residual = (S − f)r_u,

for 0 ≤ f < S. Relative capacity is (S − f)/S. This expression assumes that the remaining spine paths and downstream links are operational and equally usable.

Losing a leaf generally isolates its single-homed endpoints. Dual-homing servers or appliances to two leaves reduces this risk, but creates a shared dual-homing control domain that must be designed carefully. Losing one spine reduces fabric path diversity and capacity but should not disconnect a correctly constructed fabric.

Reliability calculations require independence assumptions. If two links share a conduit, power supply or line card, treating their failures as independent overestimates availability. Diversity must be physical and administrative, not merely logical.

3. Underlays, Overlays, VXLAN and EVPN

3.1 Underlay and overlay separation

The underlay provides IP reachability among network tunnel endpoints. It usually uses an interior gateway protocol or external BGP, ECMP and point-to-point routed links. Its goals are simplicity, fast convergence and stable reachability.

The overlay creates tenant or service connectivity over the underlay. Decoupling the two permits workload addressing and segmentation to evolve without requiring the physical topology to emulate every logical network.

3.2 VXLAN encapsulation

Virtual Extensible LAN (VXLAN) transports Ethernet frames over an IP network, commonly using UDP destination port 4789. A VXLAN network identifier (VNI) is 24 bits, permitting approximately 16.7 million identifier values and substantially greater segmentation scale than the 12-bit VLAN identifier space.

A VXLAN tunnel endpoint (VTEP) encapsulates and decapsulates traffic. VTEPs may reside in top-of-rack switches, hypervisors or software gateways.

Encapsulation consumes MTU. With an outer Ethernet header, IPv4 header, UDP header and VXLAN header, a common overhead is 50 bytes before considering optional VLAN tags, IPv6, security encapsulation or physical-layer fields. Designers should either increase the underlay MTU or reduce endpoint MTU to prevent fragmentation and silent drops. Exact overhead must be calculated from the headers actually deployed.

3.3 BGP EVPN control plane

Flood-and-learn VXLAN can discover remote addresses through data-plane flooding, but this scales poorly. BGP EVPN distributes endpoint reachability and multihoming information through a control plane.

Important EVPN route types include:

• Type 1: Ethernet auto-discovery route, used in multihoming procedures.
• Type 2: MAC/IP advertisement route, carrying endpoint MAC and optionally IP bindings.
• Type 3: inclusive multicast Ethernet tag route, supporting broadcast, unknown-unicast and multicast replication.
• Type 5: IP prefix route, used for routed prefix advertisement.

Route distinguishers make routes unique, while route targets control import and export between virtual routing and forwarding instances. These mechanisms perform different functions and should not be conflated.

An anycast gateway gives the same default-gateway address and often the same virtual MAC address on multiple leaves. A workload can retain its gateway identity after mobility, and inter-subnet traffic can be routed at the ingress leaf. This distributed routing avoids unnecessary traversal through a centralized gateway.

EVPN suppresses some broadcast traffic by distributing IP-to-MAC bindings. Nevertheless, duplicate addressing, stale advertisements, endpoint mobility and inconsistent policy can still produce failures. Sequence mechanisms and control-plane validation are essential.

3.4 Convergence analysis

Recovery time can be decomposed approximately as

T_recovery = T_detect + T_control + T_install + T_drain,

where:

• T_detect is failure-detection time;
• T_control is route recomputation and propagation time;
• T_install is forwarding-table programming time;
• T_drain represents residual effects such as queued packets, stale state or transport recovery.

These components may overlap, so the expression is an engineering decomposition rather than a universal additive law. Bidirectional Forwarding Detection can reduce detection time, while precomputed fast reroute can protect traffic before global convergence completes. Extremely aggressive timers may cause false failure declarations under congestion or control-plane stress.

A convergence objective must specify both duration and loss. A network that restores reachability in 200 ms may still violate an application objective if a large burst is lost and transport recovery takes seconds.

4. Latency, Queueing and Congestion

End-to-end latency may be expressed as

D_total = Σ(D_prop + D_ser + D_queue + D_proc) + D_app,

where propagation delay depends on distance and medium, serialization delay is the time to place bits on a link, queueing delay depends on contention, processing delay is incurred by forwarding and security functions, and D_app includes application processing.

For a packet of L bits transmitted on a link of rate R bits/s,

D_ser = L/R.

Worked Example 2: Serialization delay

For a 12,000-bit packet on a 1 Gb/s link:

D_ser = 12,000/(1 × 10^9) s = 12 × 10^−6 s = 12 microseconds.

This calculation excludes propagation, queueing and processing.

4.1 Queueing model

For an M/M/1 queue with Poisson arrivals of rate λ, exponentially distributed service times of mean 1/μ, one server and an infinite buffer, stability requires λ < μ. Define utilization ρ = λ/μ. The mean time in the system is

W = 1/(μ − λ),

and mean queueing time, excluding service, is

W_q = ρ/(μ − λ).

By Little's law, the mean number in the system is N = λW.

Worked Example 3: Idealized packet queue

A 100 Gb/s output link carries packets with a fixed illustrative mean size of 1,000 bytes, or 8,000 bits. If service is approximated as exponential, the mean service rate is

μ = 100 × 10^9 / 8,000 = 12.5 × 10^6 packets/s.

For λ = 10 × 10^6 packets/s, ρ = 0.8. Therefore,

W = 1/(12.5 × 10^6 − 10 × 10^6) = 0.4 microseconds,

and

W_q = 0.8/(2.5 × 10^6) = 0.32 microseconds.

The model is useful for showing the nonlinear increase in delay as utilization approaches one. It is not a precise model of a real switch because packet arrivals are often bursty, packet sizes are not exponential, multiple queues share buffers, and scheduling policies differ. Tail latency must be measured or modeled using realistic traces and queue disciplines.

4.2 Congestion control and buffering

Large buffers absorb bursts but can create bufferbloat. Small buffers reduce standing delay but may drop packets during incast. Explicit Congestion Notification marks packets before overflow when supported. Data-center transports may use ECN, precise telemetry or receiver-driven mechanisms to react rapidly.

Priority flow control can prevent loss for selected traffic classes, but poor configuration may propagate congestion and create deadlock risks. Lossless behavior should therefore be restricted to justified traffic classes and accompanied by admission and congestion controls.

5. Load Balancing and Application Delivery

A Layer 4 load balancer distributes connections using network and transport information. A Layer 7 load balancer can inspect HTTP hostnames, paths, headers or application metadata. Layer 7 provides richer policy but introduces greater processing cost and often terminates encrypted sessions.

Common selection algorithms include round robin, weighted round robin, least connections, consistent hashing and rendezvous hashing. Consistent hashing reduces remapping when back-end membership changes, which is useful for caches. Health checks must detect genuine service readiness rather than mere process reachability.

Load balancing occurs at multiple layers:

1. global DNS or anycast directs clients to a region;

2. a regional load balancer selects a cluster;

3. an ingress gateway selects a service;

4. a service proxy selects a workload instance.

Uncoordinated balancing layers can create hotspots. Capacity-aware policies should account for heterogeneous back ends, retries and slow instances. Retries require bounded budgets and backoff; otherwise they amplify overload into a retry storm.

6. Content-Delivery Networks

A CDN places content or application functions near users. A request is directed to a point of presence using DNS, anycast or both. The edge may serve a cached object, terminate transport security, filter attacks or forward the request to an origin.

For cache hit ratio h, edge-served mean response time D_e and origin-served mean response time D_o, a simple mean-delay model is

E[D] = hD_e + (1 − h)D_o.

This weighted mean assumes those conditional means adequately represent each class. It does not capture tail behavior, object popularity variation or congestion correlation.

For h = 0.9, D_e = 20 ms and D_o = 180 ms:

E[D] = 0.9(20) + 0.1(180) = 36 ms.

CDN design must consider cache keys, expiration, invalidation, stale serving, origin shielding and data residency. Personalized or rapidly changing content may have low cacheability. Edge execution can improve performance but expands the trusted computing base.

7. Cloud and Multi-Cloud Connectivity

Cloud connectivity options include encrypted Internet VPNs, provider-managed private circuits, carrier Ethernet and colocation-based cross-connects. Selection depends on throughput, predictability, encryption, lead time, redundancy and cost.

BGP commonly exchanges routes between enterprises and cloud providers. Sound design includes explicit prefix filters, maximum-prefix limits, authentication where supported, route-preference policy and independent physical paths. Redundant logical tunnels over one carrier or conduit do not provide full failure independence.

Multi-cloud networking can reduce provider concentration risk and place services near users, but it also introduces:

• inconsistent routing and security abstractions;
• overlapping private address space;
• inter-cloud data-transfer charges;
• variable latency and egress capacity;
• fragmented observability;
• identity and certificate-management complexity.

Architectures include hub-and-spoke transit, provider-native transit services, software-defined cloud routers and direct inter-cloud circuits. A common abstraction layer improves consistency but may conceal provider-specific behavior or create another control-plane dependency.

Address planning should avoid overlap where possible. Network address translation can resolve collisions, but complicates telemetry, policy, troubleshooting and end-to-end identity. Application-layer identity is therefore increasingly important in distributed systems.

8. Container Networking and Service Meshes

Containers are ephemeral and may be rescheduled frequently. In Kubernetes-style systems, a container network interface (CNI) implementation assigns addresses and establishes connectivity. Designs may use routed pod addresses, overlays or combinations of both.

Service discovery maps stable service names to changing workload endpoints. Forwarding may be implemented with packet-filter rules, IP virtual servers, eBPF programs or proxies. The design affects latency, observability, policy granularity and operational complexity.

A service mesh adds service-to-service capabilities such as mutual TLS, workload identity, authorization, traffic splitting, retries and telemetry. Its control plane distributes policy and configuration; its data plane enforces them through sidecar proxies, node-level proxies or newer sidecar-reduced models.

A mesh does not remove the need for a reliable network. It adds processing, connection state and certificate dependencies. Excessive telemetry cardinality can overwhelm observability systems, while poorly bounded retries can worsen congestion. Mesh adoption is most defensible when identity, encryption and traffic policy benefits exceed these costs.

9. Edge Computing and Distributed Applications

Edge computing places compute and storage closer to users, sensors or physical processes. Candidate applications include industrial control, connected vehicles, augmented reality, video analytics and privacy-sensitive processing.

An application's latency budget should be allocated across access, transport, queueing, compute and response stages. Moving computation closer reduces propagation distance but does not guarantee lower delay if edge resources are overloaded or intermittently connected.

Distributed application design must address:

• placement: where state and computation execute;
• consistency: how replicas reconcile concurrent updates;
• partition behavior: whether operations continue during disconnection;
• state transfer: how much data must cross constrained links;
• mobility: how sessions migrate as users change locations;
• availability: whether local operation is possible without the cloud.

The CAP result states that when a network partition occurs, a distributed system cannot guarantee both linearizable consistency and availability for every request. It does not imply that designers choose only two properties during normal operation. Practical systems select consistency models and partition responses according to application risk.

Edge nodes generally have less capacity and weaker physical protection than centralized data centers. Remote attestation, secure boot, encrypted storage, signed software, least-privilege management and tamper-aware operations are therefore important.

10. Illustrative Case: Designing a Distributed Telemedicine Platform

Background

This fictional case concerns a healthcare provider deploying video consultation and diagnostic-assistance services across two cloud regions and six hospital edge sites. Patient records must remain within the national jurisdiction, video requires low latency, and diagnostic inference should continue during temporary cloud disconnection.

Problem

The existing network uses a single cloud VPN and a hierarchical data-center topology. Peak east–west traffic causes congestion, VPN failure interrupts every hospital, and container services lack uniform identity controls. The target requires 99.99% service availability, regional recovery, auditable encryption and sub-100-ms interactive network round-trip time for most domestic users.

Analysis

Each leaf supports 1.2 Tb/s of server-facing capacity and 400 Gb/s of uplink capacity, giving 3:1 nominal oversubscription. Measured peak uplink demand is 280 Gb/s per busy leaf. Under normal conditions, utilization is 280/400 = 0.70. After one uplink fails, utilization becomes 280/300 ≈ 0.933, leaving little burst tolerance. The design is connected after the failure but does not meet a prudent performance margin.

Flow records reveal several long replication flows that collide under ECMP. Failure analysis also shows that two nominally separate VPNs share one carrier access circuit, creating a common failure domain.

Approach and Solution

The provider adopts the following design:

1. A routed leaf–spine underlay with BGP and four 100 Gb/s uplinks per leaf.

2. VXLAN/EVPN overlays for clinical, management and research segments, with distributed anycast gateways.

3. A fifth 100 Gb/s uplink per critical leaf, reducing nominal oversubscription to 1,200/500 = 2.4:1. After one uplink failure, 400 Gb/s remains and peak utilization is 280/400 = 0.70.

4. Resilient ECMP hashing plus monitoring of elephant flows and per-link utilization.

5. Two physically diverse cloud connections using different carriers and entry facilities, with encrypted backup over the Internet.

6. CDN delivery for public educational content, but no caching of protected patient records at unapproved locations.

7. Edge inference at hospitals, with asynchronous transfer of approved diagnostic metadata and explicit conflict handling.

8. A service mesh for workload identity, mutual TLS and authorization, with bounded retries and telemetry sampling.

9. Failure drills covering spine loss, carrier failure, route withdrawal, certificate expiration and regional cloud outage.

Outcome

Testing confirms continued operation after any single spine-facing link failure without exceeding 70% of remaining critical-leaf uplink capacity at the measured peak. Local inference remains available during cloud disconnection, while queued results synchronize after connectivity returns. Physical-path diversity removes the original carrier-access single point of failure.

Learning Points

• Connectivity after failure does not prove adequate failure-state capacity.
• Failure domains must be verified physically and organizationally.
• Overlay segmentation should complement, not replace, identity-based controls.
• Edge autonomy requires deliberate state and reconciliation design.
• Performance objectives should be tested using failure scenarios and tail metrics.

11. Operations, Governance and Emerging Developments

Operational visibility should combine flow records, streaming telemetry, routing state, packet sampling, synthetic transactions and distributed application traces. Time synchronization and consistent identifiers are necessary to correlate network and application events.

Intent-based automation can validate topology, policy and capacity before deployment. Safe automation requires schema validation, staged rollout, rollback, change authorization and independent observation of outcomes. AI-assisted operations can identify anomalies or correlate alarms, but opaque recommendations should not automatically alter critical routing without constraints and auditability.

Contemporary developments include programmable data planes, eBPF-based networking, smart network interface cards, data-processing units, in-network telemetry, segment routing and sidecar-reduced service meshes. These technologies can shift processing away from host CPUs and improve visibility, but may increase vendor dependence and debugging complexity.

Governance concerns include lawful interception, data residency, cross-border routing, encryption-key control, tenant isolation and retention of telemetry containing personal information. Organizations should collect only necessary data, restrict access, define retention periods and document automated decisions.

Sustainability also matters. Replicating data across many regions improves resilience but consumes network and storage energy. Capacity planning should balance availability, latency and carbon impact rather than maximizing replication indiscriminately.

12. Engineering Best Practices

1. Define traffic matrices, tail-latency targets and failure-state capacity requirements before selecting technology.

2. Keep the underlay simple and verify MTU consistently across every encapsulated path.

3. Design for physical as well as logical path diversity.

4. Analyze cut capacity and destination bottlenecks, not only aggregate bandwidth.

5. Use resilient load distribution and monitor byte balance, not merely flow counts.

6. Bound retries and validate health checks to avoid overload amplification.

7. Separate tenant segmentation, workload identity and authorization as distinct controls.

8. Test convergence, packet loss and transport recovery under realistic failures.

9. Automate configuration with validation, staged deployment and rollback.

10. Include regulatory, privacy, cost and energy constraints in architecture decisions.

Chapter Summary

Cloud, data-center and edge networks support distributed applications whose performance depends on capacity, latency, resilience and policy across multiple layers. Leaf–spine fabrics provide predictable paths and ECMP scale, but oversubscription and cut constraints determine admissible traffic. Failure-state analysis is essential because a connected topology may still lack adequate residual capacity.

VXLAN creates scalable overlays, while BGP EVPN distributes endpoint, prefix and multihoming information. Convergence depends on detection, control-plane processing, forwarding installation and application recovery. Queueing delay grows nonlinearly near saturation, making tail measurements and burst analysis necessary.

Load balancers, CDNs, cloud interconnects, container networks and service meshes each introduce benefits and dependencies. Multi-cloud and edge systems extend failure domains and require explicit identity, state, consistency and regulatory strategies. Effective engineering combines quantitative modeling, physical diversity, automation, observability and disciplined failure testing.

Key Terms

Anycast Gateway: A common gateway identity implemented at multiple network locations.

BGP EVPN: A BGP-based control plane for distributing Ethernet and IP reachability information.

Bisection/Cut Capacity: The total capacity of links crossing a selected partition of a network.

CNI: A specification and implementation framework for container network connectivity.

Content-Delivery Network: A distributed platform that serves content or functions near users.

ECMP: Forwarding over multiple equal-cost paths, commonly using flow hashing.

Edge Computing: Placement of compute or storage near data sources and users.

Elephant Flow: A long-lived or high-volume flow capable of materially affecting utilization.

Failure Domain: Components affected by a shared fault or dependency.

Leaf–Spine Fabric: A folded Clos topology in which leaves connect endpoints and every spine.

Microburst: A short traffic burst that can overflow a queue despite moderate average utilization.

Multi-Cloud Networking: Connectivity and policy spanning more than one cloud provider.

Oversubscription: The ratio of potential offered access capacity to available upstream capacity.

Service Mesh: Infrastructure providing service identity, security, traffic control and telemetry.

Tail Latency: Delay observed at a high percentile of a latency distribution.

Underlay: The physical or routed network providing reachability between tunnel endpoints.

VNI: A 24-bit VXLAN identifier representing a logical network segment.

VTEP: A device or software function that encapsulates and decapsulates VXLAN traffic.

VXLAN: An encapsulation that transports Ethernet frames over UDP/IP networks.

Review Questions

Short Answer Questions

1. Distinguish north–south traffic from east–west traffic.

2. What information does an oversubscription ratio provide, and what does it omit?

3. Explain the different purposes of an EVPN route distinguisher and route target.

4. Why can ECMP produce unequal byte utilization even when flow counts are balanced?

5. What operational risk arises from unbounded service-mesh retries?

Long Answer Questions

1. Explain leaf–spine architecture and evaluate its scalability, capacity and failure behavior.

2. Describe VXLAN/EVPN operation, including VTEPs, VNIs, route types and anycast gateways.

3. Compare Layer 4 load balancing, Layer 7 load balancing and CDN request distribution.

4. Critically assess multi-cloud networking with respect to resilience, cost, security and operations.

5. Explain how container networking and service meshes change connectivity, identity and observability.

Analytical / Application Questions

1. A leaf has 64 host ports at 25 Gb/s and eight uplinks at 100 Gb/s. Calculate normal and single-uplink-failure oversubscription ratios. Evaluate whether a measured peak uplink demand of 650 Gb/s remains supportable after the failure.

2. Develop a latency budget for an edge application requiring a 40-ms round-trip response. Include access, transport, queueing, processing and application components, and identify the most likely sources of tail latency.

3. Design a failure-testing plan for a two-region cloud application using EVPN data centers, private cloud circuits, Kubernetes and a service mesh. Include measurable recovery and capacity criteria.

Multiple Choice Questions with Answers

Question 1

A leaf has 48 host-facing ports at 25 Gb/s and four fabric uplinks at 100 Gb/s. What is its nominal oversubscription ratio?

A. 1:1

B. 2:1

C. 3:1

D. 4:1

Correct Answer: C. 3:1

Question 2

Which EVPN route type commonly advertises endpoint MAC and optional IP information?

A. Type 1

B. Type 2

C. Type 3

D. Type 5

Correct Answer: B. Type 2

Question 3

What is the serialization delay of a 12,000-bit packet on a 1 Gb/s link?

A. 1.2 microseconds

B. 120 microseconds

C. 12 microseconds

D. 1.2 milliseconds

Correct Answer: C. 12 microseconds

Question 4

An M/M/1 queue has an arrival rate of 8,000 packets/s and a service rate of 10,000 packets/s. What is the mean time in the system?

A. 0.125 milliseconds

B. 0.5 milliseconds

C. 1.25 milliseconds

D. 5 milliseconds

Correct Answer: B. 0.5 milliseconds

Question 5

Which mechanism minimizes flow remapping when an ECMP next hop fails?

A. Resilient hashing

B. Packet flooding

C. Static VLAN pruning

D. Transport fragmentation

Correct Answer: A. Resilient hashing

Question 6

A leaf has four equal 100 Gb/s uplinks. If one uplink fails, what proportion of its original uplink capacity remains?

A. 25%

B. 50%

C. 75%

D. 80%

Correct Answer: C. 75%

Question 7

Which statement about an anycast gateway in an EVPN fabric is correct?

A. It requires all inter-subnet traffic to pass through one centralized router.

B. It provides a common gateway identity at multiple leaves.

C. It eliminates the need for an IP underlay.

D. It converts every unicast packet into multicast traffic.

Correct Answer: B. It provides a common gateway identity at multiple leaves.

Question 8

A CDN has a cache hit ratio of 0.9, an edge response time of 20 ms and an origin response time of 180 ms. Under the weighted-mean model, what is the expected response time?

A. 20 ms

B. 36 ms

C. 90 ms

D. 162 ms

Correct Answer: B. 36 ms

Question 9

Why is logical path redundancy insufficient when both paths use the same conduit?

A. The paths necessarily use different routing protocols.

B. A shared physical failure can disable both paths.

C. ECMP cannot operate over logical links.

D. VXLAN prohibits shared infrastructure.

Correct Answer: B. A shared physical failure can disable both paths.

Question 10

During a network partition, what trade-off is identified by the CAP result?

A. A system cannot guarantee both linearizable consistency and availability for every request.

B. A system must disable both replication and caching.

C. A system cannot use encryption and compression simultaneously.

D. A system must choose between routing and switching.

Correct Answer: A. A system cannot guarantee both linearizable consistency and availability for every request.