Redundant Server-to-Network Connectivity

ipSpace.net » Case Studies » Redundant Server-to-Network Connectivity

A large enterprise (the Customer) is building a private cloud infrastructure using leaf-and-spine fabric for internal network connectivity. The virtualization team hasn’t decided yet whether to use a commercial product (example: VMware vSphere) or an open-source alternative (KVM with OpenStack). It’s also unclear whether VLANs or overlay layer-2 segments will be used to implement virtual networks.

Regardless of the virtualization details, the server team wants to implement redundant server-to-network connectivity: each server will be connected to two ToR switches (see Figure 1).

The networking team has to build the network infrastructure before having all the relevant input data – the infrastructure should thus be as flexible as possible.

Figure 1: Redundant server-to-network connectivity

The document describes a summary of design challenges sent by readers of ipSpace.net blog and discussed in numerous ExpertExpress engagements. It’s based on real-life queries and network designs but does not represent an actual customer network. Complete document is available as downloadable PDF to ipSpace.net subscribers.

Start now

Design Requirements

The virtualization solution deployed in the private cloud may use VLANs as the virtual networking technology Leaf-and-spine fabric deployed by the networking team MUST support layer-2 connectivity between all attached servers.

Overlay virtual networks may be used in the private cloud, in which case a large layer-2 failure domain is not an optimal solution Leaf-and-spine fabric SHOULD also support layer-3 connectivity with a separate subnet assigned to each ToR switch (or a redundant pair of ToR switches).

Conclusions

The most versatile leaf-and-spine fabric design uses dynamic link aggregation between servers and pairs of ToR switches. This design requires MLAG functionality on ToR switches, which does increase the overall network complexity, but the benefits far outweigh the complexity increase – the design works well with layer-2 fabrics (required by VLAN-based virtual networks) or layer-3 fabrics (recommended for transport fabrics for overlay virtual networks) and usually results in optimal traffic flow (the only exception being handling of traffic sent toward orphan ports – this traffic might have to traverse the link between MLAG peers).

Figure 2: LAG between a server and adjacent ToR switches

Get the complete document

Complete case study, including design and deployment guidelines and sample configuration snippets is available to ipSpace.net subscribers. Select the Case studies tab after logging into the webinar management system.

Start now