Aruba Campus Access Architect (HPE7-A11) study materials
Aruba Campus Access Architect (HPE7-A11) study resources

Right-Sizing an Over-Built Distribution Layer

Aruba Campus Access Architect (HPE7-A11) · Put your knowledge to work in context.

All case studies

Right-Sizing an Over-Built Distribution Layer

A hospital is designing a new 1,400-user campus across three buildings. The incumbent design proposes a fully routed access layer with 14 distribution switches, dual 100G uplinks per access closet, and every access switch running OSPF. The customer's actual traffic profile: 80% of flows stay within a building, peak inter-building traffic is 6 Gbps aggregate, and the only latency-sensitive application is a nurse-call system confined to a single building. The customer has a 3-person network team, no automation pipeline, and a hard budget cap. They ask you to validate the proposed design before signing.

1. The customer asks whether the 14-switch routed distribution design is appropriate. What is your recommendation and what design principle drives it?

Read the worked answer

The design is over-engineered for the stated requirements and should be simplified.

Reasoning:

  • 80% of flows are intra-building, so inter-building capacity is the binding constraint, and 6 Gbps aggregate peak is far below the proposed uplink capacity. Dual 100G per closet is not justified by the traffic profile.
  • A routed-everywhere design pushes OSPF (or similar) onto every access closet. That is a defensible modern pattern, but it multiplies the operational surface: 14 distribution nodes plus per-closet routing adjacencies, all maintained by a 3-person team with no automation. Complexity the team cannot operate is a reliability liability, not an asset.
  • The latency-sensitive app is confined to one building, so end-to-end latency across the distribution layer is not a design driver.

Recommendation: Collapse to a two-tier design with a redundant distribution pair per building (or a shared core/distribution pair), keep Layer 2 at the access edge with a single spanning-tree domain per building, and reserve routing for the distribution/core boundary. Size uplinks to observed peak plus headroom (e.g., 2x10G or 2x25G per closet), not to theoretical maxima.

Principle: Design to measured requirements and to the operating team's capability. Redundancy should be targeted at real failure domains, not applied uniformly to every link and every protocol layer.

2. The customer pushes back: "Won't collapsing the design reduce resilience?" How do you answer, and what resilience properties do you preserve?

Read the worked answer

Resilience comes from eliminating single points of failure in the paths that matter, not from maximizing the number of routing nodes.

What you preserve:

  • Redundant distribution switches per building with diverse power and physical paths.
  • Dual-homed access closets (each closet uplinked to both distribution switches) so a single switch or link failure does not isolate a closet.
  • Fast convergence at the Layer 2/Layer 3 boundary, with a clear, documented primary/backup path.

What you actually improve:

  • Fewer routing adjacencies and fewer protocol interactions mean fewer places for a misconfiguration to cause a campus-wide outage. A 3-person team can reason about a two-tier design under pressure.
  • A smaller, well-understood topology is easier to test and to recover.

What you give up and accept:

  • Some path diversity at the access edge. Document the accepted risk and the compensating controls (redundant uplinks, monitored link health).

Framing: Resilience is measured by mean time to recover and by blast radius, not by node count. Validate with a failure test: pull one distribution switch and confirm no closet loses connectivity.

3. What evidence would you collect before finalizing uplink sizing, and how would you present the trade-off to the customer?

Read the worked answer

Evidence to collect:

  • Interface utilization and flow data (NetFlow/IPFIX or sFlow) over at least a representative week, including peak hours.
  • Application flow locality: confirm the 80/20 intra/inter-building split with actual flow records rather than assumption.
  • Growth forecast tied to a business input (bed count, clinic expansion), not a generic percentage.
  • Failure-mode traffic: what happens to inter-building load when one distribution node is down.

Presentation:

  • Show measured peak versus proposed capacity as a ratio, so the customer sees the headroom explicitly.
  • Quantify the cost delta between the proposed and right-sized uplinks, and state what that budget buys instead (spares, monitoring, redundancy in the areas that matter).
  • State the growth assumption and the trigger for revisiting: e.g., "if inter-building peak exceeds 60% of uplink capacity for two consecutive months, add a link."
  • Record the accepted risks and the review date in the design document so the decision is auditable.