The same way as the servers around it - and getting this wrong is one of the few hardware choices that cannot be corrected afterwards.

Data centre equipment is cooled front to back so that cold air is drawn from the cold aisle and hot air is expelled into the hot aisle. Switches are sold in both directions, usually described as port-side intake or port-side exhaust, and both are legitimate depending on which way the switch is mounted.

The question to answer is where the ports face. A switch mounted with its ports towards the cold aisle needs port-side intake; one with its ports facing the hot aisle needs port-side exhaust.

Get it backwards and the switch inhales the exhaust of the servers below it. It will run hot, throttle its fans to maximum, and have a materially shorter life.

Airflow direction is fixed at manufacture on most models - some allow reversible fan trays and power supplies, but they must be ordered that way. Confirm it on the purchase order, not on delivery.

The ratio of access bandwidth to uplink bandwidth - and the acceptable figure depends on how much traffic actually leaves the rack.

A switch with 48 server ports at 25 Gb has 1.2 Tb of access capacity. With four 100 Gb uplinks it has 400 Gb out, so it is oversubscribed 3:1. If every server transmitted at line rate simultaneously to somewhere outside the rack, two thirds of that traffic would queue.

In practice servers rarely do. Traditional application workloads with most traffic staying inside the rack tolerate 3:1 or more comfortably. Storage traffic, distributed databases and anything with heavy east-west communication need much closer to 1:1.

The honest approach is to measure existing uplink utilisation at peak, including short bursts rather than five-minute averages, since microbursts cause drops that averages hide.

Adding uplinks later is usually possible, but only if the ports and the optics budget were allowed for.

Every leaf connects to every spine, all links are active, and capacity grows by adding spines - rather than one blocked path per loop and a core that must be replaced when outgrown.

In a traditional design, access switches uplink to a pair of aggregation switches and spanning tree blocks redundant paths, so half the links carry no traffic. Growth means a bigger core.

In a leaf and spine fabric every leaf switch connects to every spine switch. Routing spreads traffic across all paths equally, so nothing is blocked, and any server is exactly the same distance from any other - two hops - which makes latency predictable.

Capacity is added by adding another spine, which increases the bandwidth available to every leaf at once.

The cost is address and configuration complexity: a routed fabric with an overlay is more to design and automate than a pair of trunked switches. Below a certain size it is not worth it, and a simple pair of aggregation switches remains the right answer.

Carrying Layer 2 networks across a routed fabric - so servers can share a subnet without the fabric having to be Layer 2.

A leaf and spine fabric routes between switches, which is what makes it fast and loop-free. But many workloads still expect Layer 2 adjacency: virtual machine mobility, clustering, and applications that were never designed for anything else.

VXLAN resolves that by encapsulating Ethernet frames inside UDP packets, which the fabric routes normally. Two servers on different leaves appear to be on the same segment while the traffic between them is routed.

EVPN is the control plane that makes it manageable, distributing MAC and IP reachability between switches rather than relying on flooding.

The practical considerations are that it needs hardware support - encapsulation in silicon, not software - the additional header slightly reduces usable frame size so the fabric needs jumbo frames configured, and troubleshooting requires tools that understand the overlay. It is also frequently a separate licence tier.

Because data centre traffic arrives in bursts far shorter than any monitoring interval, and a switch with insufficient buffer drops packets that averages will never show.

Many-to-one patterns are the problem case: dozens of servers responding to one request at once, or a storage array serving a rebuild. For a few milliseconds the traffic destined for one port exceeds its capacity many times over. Buffering absorbs the burst; insufficient buffering drops it.

The consequence for TCP is disproportionate - a dropped packet triggers retransmission and congestion control, so throughput collapses far more than the drop count suggests. Storage protocols are worse, since some do not tolerate loss at all.

The architecture matters as much as the total: shared buffer pools allow one congested port to draw on the whole pool, while fixed per-port allocation cannot.

Watch for switches quoting a large total buffer that is statically divided. Look for drop counters and microburst telemetry in the monitoring, because five-minute averages will report the link as half idle.

Two of each, hot-swappable, fed from separate paths - on anything that a rack of servers depends on.

A top-of-rack switch is a single point of failure for everything in its rack unless the servers are dual-homed to two switches. Where they are not, the switch itself must be as resilient as possible: dual power supplies on independent feeds, redundant fans, and both replaceable without powering the switch down.

The common error is dual supplies plugged into the same power strip, which protects against a failed supply and nothing else. Separate feeds are the point.

Where servers are dual-homed to a pair of switches, the calculation changes and single-supply switches can be acceptable - the redundancy is at the rack level rather than the device level.

Check fan replaceability regardless. Fans are the wearing part in a data centre switch, and a model that requires the switch to be removed from the rack to change one turns routine maintenance into an outage.

Forwarding a frame as soon as the destination address has been read, rather than waiting for the whole frame - which reduces latency and is standard in data centre silicon.

A store-and-forward switch receives the entire frame, checks it, and then forwards it. That adds a delay proportional to frame size at every hop.

Cut-through reads only the header, looks up the destination and begins transmitting immediately. Latency becomes almost independent of frame size and can be well under a microsecond.

The trade is that corrupted frames are forwarded, because the check sequence at the end has not been read yet - so a bad cable propagates errors rather than containing them. Good implementations count these and can revert to store-and-forward on a port with high error rates.

Whether it matters depends entirely on the workload. High-frequency trading, HPC and some storage fabrics care about microseconds; a general virtualisation estate will not notice. Do not pay a premium for it without a workload that benefits.