data center topology

Merchant Silicon

by Blog

Merchant Silicon

In the ever-evolving landscape of technology, innovation continues to shape how we live, work, and connect. One such groundbreaking development that has caught the attention of experts and enthusiasts alike is merchant silicon. In this blog post, we will explore merchant silicon's remarkable capabilities and its far-reaching impact across various industries.

Merchant silicon refers to off-the-shelf silicon chips designed and manufactured by third-party companies. These versatile chips can be used in various applications and offer cost-effective solutions for businesses.

Flexibility and Customizability: Merchant Silicon provides network equipment manufacturers with the flexibility to choose from a wide range of components and features, tailoring their solutions to meet specific customer needs. This flexibility enables faster time-to-market and promotes innovation in the networking industry.

Cost-Effectiveness: By leveraging off-the-shelf components, Merchant Silicon significantly reduces the cost of developing networking equipment. This cost advantage makes high-performance networking solutions more accessible, driving competition and fostering technological advancements.

Enhanced Network Performance and Scalability: Merchant Silicon is designed to deliver high-performance networking capabilities, offering increased bandwidth and throughput. This enables faster data transfer rates, reduced latency, and improved overall network performance.

Advanced Packet Processing: Merchant Silicon chips incorporate advanced packet processing technologies, such as deep packet inspection and traffic prioritization. These features enhance network efficiency, allowing for more intelligent routing and improved Quality of Service (QoS).

Data Centers: Merchant Silicon has found extensive use in data centers, where scalability, performance, and cost-effectiveness are paramount. By leveraging the power of Merchant Silicon, data centers can handle the ever-increasing demands of modern applications and services, ensuring seamless connectivity and efficient data processing.

Enterprise Networking: In enterprise networking, Merchant Silicon enables organizations to build robust and scalable networks. From small businesses to large enterprises, the flexibility and cost-effectiveness of Merchant Silicon empower organizations to meet their networking requirements without compromising on performance or security.

Merchant Silicon has emerged as a game-changer in the world of network infrastructure. Its flexibility, cost-effectiveness, and enhanced performance make it an attractive choice for network equipment manufacturers and organizations alike. As technology continues to advance, we can expect Merchant Silicon to play an even more significant role in shaping the future of networking.

Matt Conran

Highlights: Merchant Silicon

Understanding Merchant Silicon

– Silicon chips, specifically designed for networking devices, play a pivotal role in functioning routers, switches, and other network equipment. One type of silicon that has gained significant attention and relevance in recent years is Merchant Silicon.

– Merchant Silicon refers to off-the-shelf networking chips produced by third-party vendors. Unlike custom silicon solutions developed in-house by network equipment manufacturers, Merchant Silicon offers a standardized, cost-effective alternative. These chips are designed to meet the requirements of various networking applications and are readily available for integration into networking devices.

– Unlike traditional networking solutions that rely on proprietary chips, merchant silicon allows network equipment manufacturers to leverage readily available chipsets from third-party vendors. This opens up a world of possibilities, empowering companies to design and develop networking solutions that are highly customizable and scalable.

Silicon: Industry Impact

The emergence of merchant silicon has had a profound impact on the networking industry. It has disrupted the traditional model of vertically-integrated networking vendors and opened up opportunities for new players to enter the market. With the ability to leverage merchant silicon, smaller companies can now compete with established networking giants, fostering innovation and driving competition.

## Enhancing Network Infrastructure

One of the most significant applications of merchant silicon is in the enhancement of network infrastructure. With the rise of cloud computing and IoT devices, the demand for high-speed, reliable networks has never been greater. Merchant silicon enables the development of robust routers, switches, and other networking devices that can handle vast amounts of data with minimal latency. This capability is crucial for supporting modern digital ecosystems, where speed and reliability are paramount.

## Driving Innovation in Data Centers

Data centers are the backbone of the digital age, and merchant silicon plays a critical role in their operation. By providing the necessary hardware to manage and route data efficiently, merchant silicon helps data centers achieve higher performance levels while maintaining energy efficiency. This, in turn, supports the seamless operation of services like streaming, online gaming, and real-time data analytics, which require exceptional processing power and speed.

## Boosting Telecommunications

The telecommunications industry is also reaping the benefits of merchant silicon. As the world becomes more connected, telecom providers must ensure their networks can support increased data traffic and provide high-quality service to users. Merchant silicon allows for the development of advanced telecom equipment that can scale with rising demand, ensuring that communication remains fluid and uninterrupted.

Let’s begin by defining our terms:

  • Custom silicon

The term custom silicon describes chips, usually ASICs (Application Specific Integrated Circuits), that are custom designed and typically built by the switch company that sells them. When describing such chips, I might use the term in-house. Cisco Nexus 7000 switches, for instance, use proprietary ASICs designed by Cisco.

  • Merchant silicon

The term merchant silicon describes chips, usually ASICs, designed and made by a company other than the one that sells the switches they are used in. Suppose I could buy these chips from a retail store if such switches use off-the-shelf ASICs. I’ve looked, and Wal-Mart doesn’t carry them. Broadcom’s Trident+ ASIC, for example, is used in Arista’s 7050S-64 switches.

Merchant Silicon and SDN

Another potential benefit of merchant silicon is the future of software-defined networks (SDN). SDN resembles a cluster of switches controlled by a single software brain that runs outside the physical switches. As a result, switches become little more than ASICs that receive instructions from a master controller. A commoditized operating system and hardware would make it easier to add any vendor’s switch to the master controller in such a situation.

A silicon-based switch based on merchant silicon lends itself to this design paradigm. In contrast, a silicon-based switch based on a custom silicon design would likely only support that switch’s vendor’s master controller.

The combination of Merchant Silicon and SDN creates a powerful synergy that enhances the capabilities of modern networks. Merchant Silicon provides the robust, scalable hardware foundation, while SDN adds a layer of intelligence and adaptability.

This partnership allows for the creation of networks that are not only cost-effective but also highly customizable and responsive to business needs. Organizations can now design networks that scale effortlessly, adapt to changing conditions, and optimize performance without the burdensome costs associated with proprietary solutions.

Bare-Metal Switching

Commodity switches are used in both white-box and bare-metal switching. In this way, users can purchase hardware from one vendor, purchase an operating system from another, and then load features and applications from other vendors or open-source communities.

As a result of the OpenFlow hype, white-box switching was a hot topic since it commoditized hardware and centralized the network control in an OpenFlow controller (now known as an SDN controller). Google announced in 2013 that it built and controlled its switches with OpenFlow! It was a topic of much discussion then, but not every user is Google, so not every user will build their hardware and software.

What is OpenFlow

Meanwhile, a few companies emerged solely focused on providing white-box switching solutions. These companies include Big Switch Networks, Cumulus Networks, and Pica8 (now owned by NVIDIA). They also needed hardware for their software to provide an end-to-end solution.

Originally, original design manufacturers (ODMs) supplied white-box hardware platforms like Quanta Networks, Supermicro, Alpha Networks, and Accton Technology Corporation. You probably haven’t heard of those vendors, even if you’ve worked in the network industry.

The industry shifted from calling this trend white-box to bare-metal only after Cumulus and Big Switch announced partnerships with HP and Dell Technologies. Name-brand vendors now support third-party operating systems from Big Switch and Cumulus on their hardware platforms.

You create bare-metal switches by combining switches from ODMs with NOSs from third parties, including the ones mentioned above. Many of the same switches from ODMs are now also available from traditional network vendors, as they use merchant silicon ASICs.

### What is Bare-Metal Switching?

Bare-metal switching refers to the use of network switches that are decoupled from proprietary software, allowing users to install their choice of network operating systems (NOS). This separation of hardware and software provides an unprecedented level of customization and control over network operations, enabling businesses to tailor their network to specific needs and optimize performance. By leveraging open standards and commoditized hardware, bare-metal switches can significantly reduce costs and increase the agility of network infrastructure.

### Benefits of Bare-Metal Switching

One of the primary advantages of bare-metal switching is its cost-effectiveness. By breaking free from vendor lock-in, organizations can select the best hardware and software combination for their needs, often at a fraction of the cost of traditional solutions. Additionally, bare-metal switches offer enhanced flexibility and scalability, allowing networks to adapt quickly to changing demands. This is particularly beneficial for cloud service providers and large data centers that require robust, scalable infrastructure.

### Challenges and Considerations

While bare-metal switching offers numerous benefits, it also presents some challenges that organizations must consider. Implementing a bare-metal switch requires a higher level of technical expertise, as IT teams must manage both hardware and software independently. Furthermore, ensuring compatibility between different NOS and hardware can be complex. Organizations need to carefully evaluate their technical capabilities and resources before transitioning to a bare-metal architecture.

Landscape Changes

Some data center vendors offer a “Debian” based operating system for network equipment. Their philosophy is that engineers should manage switches just like they manage servers with the ability to use existing server administration tools. They want networking to work as a server application. For example, Cumulus has created the first full-featured Linux distribution for network hardware. It allows designers to break free from proprietary networking equipment and utilize the advantages of the SDN Data Center.

**Issues with Traditional Networking**

Cloud computing, distributed storage, and virtualization technologies are changing the operational landscape. Traditional networking concepts do not align with new requirements and continually act as blockers to business enablers. Decoupling hardware/software is required to keep pace with the innovation needed to meet the speeds and agility of cloud deployments and emerging technologies.

Merchant silicon is a term used to describe chips. Usually, ASICs (Application-Specific Integrated Circuits) are developed by an entity, not the company selling the switches. Then, we have custom silicon, which is the opposite of Merchant Silicon. Custom silicon is a term used to describe chips, usually ASICs, that are custom-designed and traditionally built by the company selling the switches in which they are used.

Before you proceed, you may find the following helpful:

  1. LISP Hybrid Cloud
  2. Modular Building Blocks
  3. Virtual Switch
  4. Overlay Virtual Networks
  5. Virtual Data Center Design

Merchant Silicon

Disaggregation Model

Disaggregation is the next logical evolution in data center topologies. Cumulus does not reinvent all the wheels; they believe that routing and bridging work well, with no reason to change them. Instead, they use existing protocols to build on the original networking concept base. The technologies they offer are based on well-designed current feature sets. Their O/S enables dis-aggregation of switching design to the server hardware/software disaggregation model.

Disaggregation decouples hardware/software on individual network elements. Modern networking equipment is proprietary today, making it expensive and complicated to manage. Disaggregation allows designers to break free from vertically integrated networking gear. It also allows you to separate the procurement decisions around hardware and software.

Data Center Topology Types
Diagram: Data Center Topology Types.

Data center topology types and merchant silicon

Previously, we needed proprietary hardware to provide networking functionality. Now, the hardware allows many of those functions in “merchant silicon.” In the last ten years, we have seen a massive increase in the production of merchant silicon. Merchant silicon is a term used to describe the use of “off-the-shelf” chip components to create a network product enabling open networking. Currently, three major players for 10GbE and 40GbE switch ASIC are Broadcom, Fulcrum, and Fujitsu.

In addition, cumulus supports the Broadcom Trident II ASIC switch silicon, also used in the Cisco Nexus 9000 series. Merchant silicon’s price/performance ratio is far better than proprietary ASIC. 

Routing isn’t broken – Simple building blocks.

To disaggregate networking, we must first simplify it. Networking is complicated. Sometimes, less is more. Building robust ecosystems using simple building blocks with existing layer 2 and layer 3 protocols is possible. Internet Protocol (IP) is the underlying base technology and the basis for every large data center. MPLS is an attractive, helpful alternative, but IP is a mature building block today. IP is based on a standard technique, unlike Multichassis Link Aggregation (MLAG), which is vendor-specific.

Multichassis Link Aggregation (MLAG) implementation

Each vendor has various MLAG variations; some operate with unified and separate control planes. MLAG offers suitable control planes: Juniper with Virtual Chassis, HP with Intelligent Resilient Framework (IRF), Cisco Virtual Switching System, and cross-stack EtherChannel. MLAG, with separate control planes, includes Cisco Virtual Port-Channel (vPC) and Arista MLAG.

With all the vendors out there, we have no standard for MLAG. Where specific VLANs can be isolated to particular ToRs, Layer 3 is a preferred alternative. Cumulus Multichassis Link Aggregation (MLAG) implementation is an MLAG daemon written in python.

The specific implementation of how the MLAG gets translated to the hardware is ASIC independent, so in theory, you could run MLAG between two boxes that are not running the same chipset. Similar to other vendor MLAG implementations, it is limited to two spine switches. If you require anything to scale, move to IP. The beauty of IP is that you can do much stuff without relying on proprietary technologies.

Data center topology types: A design for simple failures

Everyone building networks at scale is building them as a loosely coupled system. People are not trying to over-engineer and build exact systems. High-performance clusters are excellent applications and must be made a certain way. A general-purpose cloud is not built that way. Operators build “generic” applications over “generic” infrastructure. Designing and engineering networks with simple building blocks leads to simpler designs with simple failures. Over-engineering networks experience complex failures that are time-consuming to troubleshoot. When things fail, they should fail.

Building blocks should be constructed with straightforward rules. Designers understand you can build extensive networks with simple rules and building blocks. For example, analyzing Spine Leaf architecture looks complicated. But in terms of the networking fabric, the Cumulus ecosystem is made of a straightforward building block – fixed form-factor switches. It makes failures very simple.

On the other hand, if the chassis base switch fails, you need to troubleshoot many aspects. Did the line card not connect to the backplane? Is the backplane failing? All these troubleshooting steps add complexity. With the disaggregated model, when networks fail, they fail in simple ways. Nobody wants to troubleshoot a network when it is down. Cumulus tries to keep the base infrastructure simple and not complement every tool and technology.

For example, if you use Layer 2, MLAG is your only topology. STP is simply a fail-stop mechanism and is not used as a high convergence mechanism. Rapid Spanning Tree Protocol (RSTP) and Bridge Protocol Data Units (BPDU) are all you need; you can build straightforward networks with these.

Virtual router redundancy

First Hop Redundancy Protocol (FHRP) now becomes trivial. Cumulus uses Anycast Virtual IP/MAC, eliminating complex FHRP protocols. You do not need a protocol in your MLAG topology to keep your network running. They support a variation of the Virtual Router Redundancy Protocol (VRRP) known as Virtual Router Redundancy (VRR). It’s like VRRP without the protocol and supports an active-active setup. It allows hosts to communicate with redundant routers without dynamic or router protocols.

A Final Point: Merchant Silicon

For years, networking giants relied on proprietary chips to power their devices. However, with the advent of merchant silicon, the landscape has dramatically shifted. Companies like Broadcom, Intel, and Marvell have pioneered the development of these versatile chips, making them accessible to a broader range of manufacturers. This democratization of technology has led to increased competition and innovation in the networking sector, benefiting both businesses and consumers.

One of the primary advantages of merchant silicon is its cost efficiency. By leveraging standardized chips, manufacturers can reduce research and development expenses, leading to more affordable networking solutions. Furthermore, merchant silicon offers enhanced flexibility, enabling companies to adapt their products quickly to meet changing market demands. The interoperable nature of these chips also facilitates seamless integration across different networking devices, ensuring compatibility and ease of deployment.

The rise of software-defined networking (SDN) and network functions virtualization (NFV) has further amplified the role of merchant silicon. These technologies decouple network functions from hardware, allowing them to run on standardized servers powered by merchant silicon. This shift not only reduces costs but also accelerates service deployment, enhances network agility, and simplifies management. As a result, businesses can optimize their network infrastructure to support modern applications and services more efficiently.

While merchant silicon offers numerous benefits, it is not without its challenges. One concern is the potential for reduced differentiation, as multiple manufacturers use the same underlying technology. To mitigate this, companies must focus on developing unique software and features that set them apart from competitors. Additionally, as with any technology, ensuring robust security measures is crucial to protect networks from potential threats and vulnerabilities.

Summary: Merchant Silicon

Merchant Silicon has emerged as a game-changer in the world of network infrastructure. This revolutionary technology is transforming the way data centers and networking systems operate, offering unprecedented flexibility, scalability, and cost-efficiency. In this blog post, we will dive deep into the concept of Merchant Silicon, exploring its origins, benefits, and impact on modern networks.

Understanding Merchant Silicon

Merchant Silicon refers to using off-the-shelf, commercially available silicon chips in networking devices instead of proprietary, custom-built chips. These off-the-shelf chips are developed and manufactured by third-party vendors, providing network equipment manufacturers (NEMs) with a cost-effective and highly versatile alternative to in-house chip development. By leveraging Merchant Silicon, NEMs can focus on software innovation and system integration, streamlining product development cycles and reducing time-to-market.

Key Benefits of Merchant Silicon

Enhanced Flexibility: Merchant Silicon allows network equipment manufacturers to choose from a wide range of silicon chip options, providing the flexibility to select the most suitable chips for their specific requirements. This flexibility enables rapid customization and optimization of networking devices, catering to diverse customer needs and market demands.

Scalability and Performance: Merchant Silicon offers scalability that was previously unimaginable. By incorporating the latest advancements in chip technology from multiple vendors, networking devices can deliver superior performance, higher bandwidth, and lower latency. This scalability ensures that networks can adapt to evolving demands and handle increasing data traffic effectively.

Cost Efficiency: Using off-the-shelf chips, NEMs can significantly reduce manufacturing costs as the chip design and fabrication burden is shifted to specialized vendors. This cost advantage also extends to customers, making network infrastructure more affordable and accessible. The competitive market for Merchant Silicon also drives innovation and price competition among chip vendors, resulting in further cost savings.

Applications and Industry Impact

Data Centers: Merchant Silicon has revolutionized data center networks by enabling the development of high-performance, software-defined networking (SDN) solutions. These solutions offer unparalleled agility, scalability, and programmability, allowing data centers to manage the increasing complexity of modern workloads and applications efficiently.

Telecommunications: The telecommunications industry has embraced Merchant Silicon to accelerate the deployment of next-generation networks such as 5G. By leveraging the power of off-the-shelf chips, telecommunication companies can rapidly upgrade their infrastructure, deliver faster and more reliable connectivity, and support emerging technologies like edge computing and the Internet of Things (IoT).

Challenges and Future Outlook

Integration and Compatibility: While Merchant Silicon offers numerous benefits, integrating third-party chips into existing network architectures can present compatibility challenges. Close collaboration between chip vendors, NEMs, and software developers ensures seamless integration and optimal performance.

Continuous Innovation: As technology advances, chip vendors must keep pace with the networking industry’s evolving needs. Merchant Silicon’s future lies in the continuous development of cutting-edge chip designs that push the boundaries of performance, power efficiency, and integration capabilities.

Conclusion

In conclusion, Merchant Silicon has ushered in a new era of network infrastructure, empowering NEMs to build highly flexible, scalable, and cost-effective solutions. By leveraging off-the-shelf chips, businesses can unleash their networks’ true potential, adapting to changing demands and embracing future technologies. As chip technology continues to evolve, Merchant Silicon is poised to play a pivotal role in shaping the future of networking.

multipath tcp

Data Center Topologies

by Blog
Network Architecture / Data Center Design

Data Center Topology: From Three-Tier Networks to Leaf-Spine Fabrics

Data center topology defines how switches, servers, storage systems and external networks connect—and ultimately how application traffic moves through the infrastructure. The architecture you choose influences latency, available bandwidth, resilience, operational complexity and the ability to scale as workloads grow.

Traditional hierarchical networks remain relevant in many environments, but modern cloud platforms and distributed applications increasingly rely on scalable Layer 3 fabrics, leaf-spine architectures and equal-cost multipath routing. Understanding these designs means looking beyond the network diagram to examine routing behaviour, traffic patterns, failure domains and the control plane that keeps the fabric connected.

Design principle: build around application requirements

A good topology is not simply the one with the most links or the most switches. It is the one that delivers the required capacity, predictable forwarding, appropriate redundancy and manageable failure behaviour at an acceptable cost.

01 / STRUCTURE

Topology and Fabric Design

Compare three-tier, centralized, top-of-rack, end-of-row and leaf-spine architectures.

02 / ROUTING

BGP and ECMP

Explore routing adjacencies, route selection, multipath forwarding and convergence during failures.

03 / OVERLAYS

VXLAN and EVPN

Understand how Layer 3 underlays support virtual networks and distributed endpoint reachability.

04 / OPERATIONS

Capacity and Resilience

Evaluate oversubscription, traffic distribution, observability and failure-domain behaviour.

In this guide: Work from fundamental topology choices to modern data center fabrics, BGP-based routing, traffic engineering considerations and practical troubleshooting.

NETWORK INSIGHT · FIELD GUIDE

Explore Data Center Topology

Navigate the architecture, routing, traffic flows and resilience principles behind modern data center networks.

06 sections
Follow the guide from architecture fundamentals through routing, observability and resilient operations.
01 / ARCHITECTURE FUNDAMENTALS

Understanding Data Center Architectures

Data center topology defines how servers, storage systems, switches and external networks connect. The architecture determines how traffic moves through the infrastructure and influences available bandwidth, latency, redundancy, scalability and operational complexity.

This section introduces traditional three-tier networks, centralized switching, top-of-rack (ToR), end-of-row (EoR) and leaf-spine architectures. Compare their connectivity models and trade-offs to understand which designs best match different workload and infrastructure requirements.

Engineering focus Choose topology according to traffic patterns, growth expectations, capacity, failure domains and the cost of operating the network.
Section 01 / Architecture Fundamentals

The Main Data Center Architectures

Data center networks can be built using hierarchical switching layers, centralized switching platforms, distributed access switches or fabric-based designs. Each approach creates a different balance between cabling, port utilization, bandwidth, failure isolation and operational complexity.

The right starting point is the workload. A smaller environment with limited server-to-server traffic may not need the same architecture as a cloud platform supporting thousands of virtual machines, containers or data-intensive applications. Topology selection should reflect traffic patterns, growth expectations, availability targets and the cost of operating the network over time.

Common architectural approaches
01
Hierarchical

Traditional Three-Tier Architecture

A traditional enterprise design separates access, aggregation or distribution, and core functions. Access switches connect servers, the aggregation layer concentrates traffic and may enforce policy, and the core provides high-speed connectivity between network blocks.

This model remains useful where existing infrastructure, established operational practices or clear policy boundaries make a hierarchical design appropriate. However, multiple switching tiers can increase path length and create bottlenecks when east-west traffic grows.

02
Centralized

Centralized Switching

In a centralized design, servers or server racks connect back to a central switching location. Concentrating switching resources can simplify management and make port allocation efficient in smaller environments.

As the facility grows, cable lengths, pathway congestion, centralized capacity limits and the consequences of equipment failure must be evaluated carefully.

03
Distributed Access

Top-of-Rack and End-of-Row

Top-of-rack (ToR) places access switches in individual server racks. End-of-row (EoR) places switching equipment in a dedicated rack serving a row of servers. Both approaches can provide redundant connectivity when designed with suitable independent paths and devices.

ToR generally shortens server cabling and can isolate access failures to a rack. EoR can consolidate switching resources, but may require more structured cabling. Neither approach automatically determines whether the wider network uses a three-tier or leaf-spine architecture.

04
Fabric-Based

Leaf-Spine Architecture

A leaf-spine fabric connects each leaf switch to multiple spine switches. Servers and other endpoints connect to the leaf layer, while the spine layer provides paths between different leaves. A Layer 3 underlay commonly uses equal-cost multipath routing to distribute eligible traffic across available paths.

This architecture provides predictable path structure and supports incremental expansion. Its capacity and resilience depend on link speeds, the number of spine switches, oversubscription, routing design and failure behaviour.

Important distinction: ToR and EoR describe where access switching is placed. Three-tier and leaf-spine describe broader network architectures. A data center can use ToR switches as its leaf layer in a leaf-spine fabric.

Compare the design trade-offs
Design consideration Three-tier / centralized Leaf-spine fabric
Traffic paths May traverse several hierarchical layers. Typically uses a consistent leaf-to-spine-to-leaf path.
Scaling Expansion depends on available tier capacity and design. Can expand by adding leafs and, when needed, spine capacity.
Multipath routing Depends on the routing and switching design. Layer 3 ECMP is commonly used between leafs and spines.
Operational considerations May suit established environments and existing investments. Requires deliberate underlay, routing, capacity and failure planning.
Before selecting a topology
Traffic patterns

Determine whether workloads primarily communicate with external networks or generate substantial east-west traffic between servers.

Capacity and growth

Estimate endpoint growth, uplink bandwidth, oversubscription limits and the cost of adding future capacity.

Failure domains

Identify the impact of losing a switch, link, rack or entire network block, including the capacity that remains.

Operations and cost

Balance equipment and cabling costs against monitoring, troubleshooting, automation and lifecycle requirements.

Engineering takeaway: Choosing a topology is a decision about traffic paths, capacity, failure behaviour and operational trade-offs—not simply the arrangement of switches. The next step is to examine how leaf-spine and Clos fabrics address the scaling and path-predictability requirements of modern data centers.

NETWORK INSIGHT · INTERACTIVE ARCHITECTURE LAB

Explore Data Center Architectures

Compare four common ways to connect compute, access and switching. Select an architecture, then click a device in the topology to inspect its role in the network.

Three-tier architecture Illustrative topology
Selectable device Network connection Highlighted path
Selected device

Core switch

The core provides high-speed connectivity between distribution blocks and upstream networks in a traditional three-tier design.

Architecture insight

Separate layers make roles easy to understand, but traffic may traverse multiple tiers and scaling can increase operational complexity.

Layered Design structure
Multi-hop Typical path shape
Layer by layer Common scaling approach
Design strengths
  • Clear separation of network roles
  • Familiar operational model
  • Can suit hierarchical traffic patterns
Design considerations
  • Potentially longer paths between servers
  • Capacity planning across tiers
  • Additional layers to operate and troubleshoot

These diagrams illustrate common design patterns, not vendor-specific configurations. Actual forwarding paths, redundancy and oversubscription depend on the implementation. ToR means Top of Rack; EoR means End of Row; Clos describes a multistage network fabric.

02 / FABRIC ARCHITECTURE

Leaf-Spine and Clos Fabrics

Leaf-spine architecture connects each leaf switch to multiple spine switches, creating a consistent path structure between different server racks. It is widely used in modern data centers where distributed applications, virtualization and cloud workloads generate substantial east-west traffic.

Explore how leaf and spine layers work together, how two-tier fabrics relate to Clos network designs, and how adding switches can expand connectivity. The section also examines oversubscription, available path diversity and the limits of relying on topology alone to guarantee performance.

Engineering focus Understand fabric stages, leaf-to-spine connectivity, expansion options and the capacity that remains when a device or link fails.
Section 02 / Fabric Architecture

Leaf-Spine and Clos Fabrics

Leaf-spine architecture is a common foundation for modern data center networks. Instead of sending traffic through a succession of hierarchical switching layers, it connects access-layer leaf switches to a set of spine switches. This creates a fabric with consistent paths between leaf switches and provides a repeatable way to expand connectivity as workloads grow.

The architecture is particularly useful for environments with substantial east-west traffic, including virtualized platforms, container infrastructure, distributed storage and cloud-native applications. Its performance depends on the actual link speeds, number of paths, traffic distribution and capacity provisioned throughout the fabric.

The physical fabric
Spine layer
Spine 1
Spine 2
Spine 3
Every leaf connects to every spine
Leaf layer
Leaf 1
Leaf 2
Leaf 3
Leaf 4
Server and workload connectivity
Servers
Storage
Compute
Services

Conceptual topology, not a physical cabling diagram. Each leaf has links to each spine; server-facing connections are shown separately. The simplified graphic illustrates connectivity rather than every individual link.

1. The role of leaf switches

Leaf switches provide connectivity for servers, storage, firewalls, load balancers and other data center endpoints. They may also perform Layer 3 routing, enforce network policy and act as VXLAN tunnel endpoints when an overlay is deployed.

In a Layer 3 fabric, endpoints in different subnets can communicate through routed paths. When VXLAN EVPN is used, the leaf layer can additionally provide overlay connectivity and distribute endpoint reachability through the EVPN control plane.

2. The role of spine switches

Spine switches interconnect the leaf layer and provide transit paths between leaf switches. In a conventional two-tier leaf-spine fabric, spine switches do not connect directly to servers, and leaf switches do not connect directly to other leaf switches.

Adding spine capacity can increase the number of available paths and aggregate fabric bandwidth, provided the leaf uplinks, interfaces, routing configuration and downstream capacity are designed to use it. A spine failure can reduce available capacity even when connectivity survives.

Why path predictability matters: Traffic between endpoints attached to different leaf switches normally traverses one spine switch. This creates a consistent switching-hop structure, although actual latency still depends on link speeds, device processing, congestion and the forwarding path.

How the architecture scales
01 / ADD LEAF CAPACITY

Expand endpoint connectivity

Add leaf switches with uplinks to the fabric's spine layer. Confirm that the existing spine and uplink capacity can support the additional traffic.

02 / ADD SPINE CAPACITY

Increase fabric bandwidth

Additional spine switches can create more equal-cost paths. Validate routing limits, optics, cabling, interface capacity and platform support before expanding.

03 / MANAGE OVERSUBSCRIPTION

Plan for real traffic demand

Compare aggregate server-facing bandwidth with available uplink bandwidth. Size the fabric according to workload behaviour and acceptable contention.

04 / CONTROL FAILURE IMPACT

Test the remaining capacity

Evaluate whether surviving spines and links can carry traffic after a failure, not simply whether alternate paths exist.

Two-tier and multi-tier Clos designs

Leaf-spine is a practical implementation of a two-tier Clos-style fabric. Larger environments may introduce a super-spine or additional fabric stages to interconnect multiple pods, rooms or data halls. These designs extend the architecture while requiring careful consideration of path diversity, capacity and failure boundaries.

Design Typical purpose Key consideration
Two-tier leaf-spine Connect endpoints across a single fabric. Spine capacity, leaf uplinks and ECMP behaviour.
Multi-pod fabric Connect modular groups of racks or infrastructure. Inter-pod connectivity and failure isolation.
Super-spine / multi-stage Clos Scale connectivity across larger fabrics or multiple data halls. Additional stages, path design and end-to-end capacity.

Engineering takeaway: Leaf-spine provides a scalable connectivity structure, but the topology alone does not guarantee non-blocking performance or equal traffic distribution. Routing, ECMP, link capacity, oversubscription and failure handling determine how the fabric behaves under real workloads. The next section examines east-west and north-south traffic patterns that influence these design decisions.

NETWORK INSIGHT · FABRIC EXPLORER

Explore Leaf-Spine and Clos Fabrics

Investigate how leaf and spine switches connect, trace an illustrative server-to-server path, simulate a spine-link failure, and see why uplink capacity and oversubscription matter.

Explore:
Two-tier leaf-spine fabric All illustrated links up
Network device Available link Illustrative selected path Failed link
Topology focus

Leaf switches

Leaf switches connect servers and provide uplinks into the spine layer. In a conventional two-tier fabric, each leaf connects to every spine.

Fabric principle

A full-mesh leaf-to-spine design provides multiple potential paths between different leaves. Routing and ECMP determine which next hops are installed and used.

Trace a flow
2 Illustrated spine paths between selected leaves
8 Leaf-to-spine links currently available
Healthy Illustrative fabric state
Explore leaf uplink oversubscription 3:1 example
1:1 · equal nominal capacity 5:1 · more aggregate server capacity

A 3:1 illustrative oversubscription ratio means aggregate nominal server-facing bandwidth is three times the uplink bandwidth. Actual throughput depends on traffic patterns, link rates and congestion.

Why use a Clos-style fabric?

A multistage design can provide scalable connectivity and multiple paths without requiring every leaf to connect directly to every other leaf.

What should engineers verify?

Check spine and leaf capacity, uplink speed, ECMP behavior, failure convergence and the bandwidth remaining after a link or device failure.

This is an educational model, not a live network or packet-level simulator. The four-leaf, two-spine diagram is illustrative. ECMP distributes eligible flows across available next hops; it does not guarantee that each physical link carries exactly the same load.

03 / TRAFFIC ENGINEERING

Data Center Traffic Patterns

A data center network must accommodate the traffic generated by applications, storage systems, virtual machines and distributed services. Understanding where traffic originates and where it travels is essential for designing a fabric with sufficient capacity and predictable performance.

This section distinguishes east-west traffic between internal workloads from north-south traffic entering or leaving the data center. It explores how flow size, concurrent demand, ECMP hashing, uplink capacity and congestion influence the actual behaviour of a leaf-spine network.

Engineering focus Size the fabric around real workload demand, identify potential bottlenecks and validate performance during normal operation and failure conditions.
Section 03 / Traffic Engineering

Data Center Traffic Patterns

A data center topology must be designed around the traffic it carries, not simply the number of switches and links it contains. Application placement, storage access, replication, service dependencies and external connectivity all influence where traffic flows and where congestion can occur.

Leaf-spine fabrics are particularly suited to distributed east-west communication, but north-south traffic, large data transfers and uneven workload demand can still create bottlenecks. Understanding these patterns helps engineers size uplinks, evaluate redundancy and choose appropriate routing and forwarding designs.

Two fundamental traffic directions
01 / EAST-WEST

Workload-to-workload traffic

Traffic between servers, virtual machines, containers, storage systems and distributed application components. In modern environments, this can represent a substantial share of total network demand.

02 / NORTH-SOUTH

Traffic entering or leaving the fabric

Traffic between internal workloads and external networks, users, WANs, internet services or other data centers. Its path may include border leaf switches, firewalls, routers and load balancers.

Example / east-west traffic path
Communication between two server racks
Server A
Rack 1
Leaf 1
Spine
Leaf 2
Server B
Rack 2

Simplified logical path. In a conventional two-tier leaf-spine fabric, inter-leaf traffic normally traverses a spine. The forwarding plane selects an available path according to the installed routes and forwarding configuration.

Why east-west traffic affects fabric design

Distributed applications frequently exchange data across multiple servers. Examples include database replication, distributed storage, service-to-service requests, cluster coordination and virtual machine communication. If these flows cross leaf switches, the spine layer and leaf uplinks must provide enough capacity for their combined demand.

Traffic demand is rarely perfectly uniform. Some flows are short and latency-sensitive, while others transfer large volumes of data. Multiple simultaneous flows may also compete for the same links. Consequently, aggregate bandwidth alone does not reveal every congestion risk.

Important distinction: A fabric can have several equal-cost paths and still experience congestion. ECMP provides a mechanism for distributing eligible flows across paths; it does not guarantee that every flow uses a different link or that traffic is perfectly balanced.

North-south traffic and border connectivity

External traffic commonly enters or leaves through designated border leaf switches or dedicated edge devices. These connect the fabric to WAN routers, internet edge infrastructure, firewalls, load balancers and other networks.

The design must consider both bandwidth and resilience. Concentrating external connectivity on a small number of devices may simplify policy enforcement, but it can also create capacity constraints or larger failure domains. Distributing border functions can improve scale, provided routing policy and security controls remain consistent.

Traffic patterns and engineering decisions
Traffic pattern Potential pressure point Design response
Server-to-server Leaf uplinks and spine capacity. Assess aggregate demand, path diversity and ECMP.
Storage replication Sustained high-throughput flows. Measure peak demand and validate link utilization.
Internet or WAN access Border links, security appliances and external routing. Plan edge capacity, policy and redundant paths.
Large data transfers Flow imbalance and transient congestion. Evaluate hashing behaviour, flow sizes and telemetry.
Failure or maintenance Reduced capacity on surviving paths. Validate traffic behaviour after losing a link or device.

Measure the traffic, not just the topology

Traffic engineering should use interface counters, utilization trends, flow telemetry, packet drops, latency measurements and application performance data. These observations help distinguish a routing issue from a capacity problem or an application-generated traffic burst.

Engineers should also examine behaviour during failure conditions. A fabric that operates comfortably during normal traffic may become congested when a spine or uplink is unavailable and flows are redistributed across fewer remaining paths.

Engineering takeaway: Traffic patterns determine how much capacity the fabric needs, where redundancy matters and which paths must be observed. The next section moves from physical connectivity to the control plane: BGP in data center fabrics, including route exchange, best-path selection, ECMP, convergence and troubleshooting.

NETWORK INSIGHT · TRAFFIC EXPLORER

Explore Data Center Traffic Patterns

Follow traffic between servers, across the fabric and toward external networks. Adjust the illustrative load to understand why workload patterns, path capacity and congestion matter when designing a data center.

East-west: server to server Illustrative traffic flow
Network link East-west flow North-south flow Potential congestion
Traffic focus

East-west traffic

Traffic between workloads inside the data center. In a leaf-spine fabric, communication between servers on different leaves normally traverses a spine.

Engineering insight

Distributed applications, storage replication and service-to-service calls can generate substantial east-west traffic. Design for workload demand rather than assuming all traffic exits the data center.

Example flow
East-West Selected traffic direction
Leaf → Spine → Leaf Illustrative forwarding path
Moderate Illustrative link demand
Simulate traffic demand 45% illustrative load
Low demand High demand

At this illustrative load, the selected links have moderate demand. Real congestion depends on offered traffic, available link capacity, buffering, queueing and the distribution of flows.

Why traffic direction matters

East-west traffic can stay inside the fabric and use leaf uplinks and spine capacity. North-south traffic crosses the boundary toward external networks or services.

What engineers should measure

Compare interface utilization, drops, queue depth, flow records and application latency. A high average utilization can hide short bursts that cause packet loss or delay.

This widget is a conceptual teaching model, not a live traffic generator or telemetry system. The load slider represents illustrative demand, not measured utilization. Actual paths and capacity depend on topology, routing, link rates, hashing and workload behavior.

04 / ROUTING CONTROL PLANE

BGP in Data Center Fabrics

Border Gateway Protocol (BGP) provides a scalable way to distribute network reachability information across modern data center fabrics. In a routed leaf-spine design, BGP can establish the routes that allow traffic to move between endpoints while supporting controlled route propagation and multipath forwarding.

Explore eBGP and iBGP design approaches, route advertisements, best-path selection, ECMP and convergence. The section also introduces the relationship between a routed underlay and a VXLAN EVPN overlay, showing why control-plane state must be checked alongside the actual forwarding table.

Engineering focus Trace route propagation, validate next-hop reachability, understand multipath installation and troubleshoot routing changes without confusing BGP state with end-to-end connectivity.
Section 04 / Routing Control Plane

BGP in Data Center Fabrics

Border Gateway Protocol (BGP) is widely used to exchange reachability information in modern data center networks. In a routed leaf-spine fabric, it can provide scalable route distribution, controlled reachability, multipath forwarding and predictable responses to topology changes.

BGP does not replace the physical fabric. It supplies control-plane information that routers use to decide which network destinations are reachable and which paths can be installed for forwarding. The resulting behaviour depends on the routing design, policy, platform capabilities and operational configuration.

Keep the layers distinct: the physical topology defines available links; the routing control plane distributes reachability; the forwarding plane moves packets using installed forwarding entries. A healthy BGP session alone does not prove that the intended traffic path is working.

01 / Choosing a BGP fabric design
DESIGN A

eBGP leaf-spine

Leaf and spine switches use different autonomous system numbers (ASNs), and BGP sessions between them operate as external BGP. This is a common design for routed Clos fabrics because it can keep routing relationships explicit and support repeatable deployment patterns.

DESIGN B

iBGP-based fabric

Routers exchange BGP routes within the same autonomous system. Larger designs may use route reflectors to distribute routes without requiring a full mesh of iBGP sessions between every participating router.

DESIGN C

Hybrid routing

A fabric may combine an IGP or static routing for underlay reachability with BGP for other routing functions. The exact division depends on the design; there is no requirement that every data center use one universal routing model.

DESIGN D

Border and external routing

Border leaf switches or edge routers exchange routes with external networks. Import and export policies determine which prefixes can enter or leave the fabric and how they are represented to other routing domains.

Example: eBGP in a leaf-spine fabric

In this simplified example, each leaf has an eBGP session to each spine. Leaf-to-spine routing sessions exchange the reachability needed to forward traffic across the fabric. The example illustrates the relationship rather than prescribing a specific ASN plan or configuration.

Illustrative two-tier routed fabric
SPINE LAYER
Spine 1 AS 65101
Spine 2 AS 65102
eBGP sessions between each leaf and both spines
LEAF LAYER
Leaf 1 AS 65001
Leaf 2 AS 65002

Conceptual relationship only; individual physical links and separate BGP sessions are not drawn. ASNs are illustrative. This design assumes the chosen BGP configuration permits the required route exchange between the relevant devices.

Design caveat: eBGP does not automatically guarantee a working fabric or multipath forwarding. ASN allocation, next-hop reachability, route policy, prefix limits, supported BGP features and ECMP configuration must all be validated.

02 / Underlay and overlay routing

The BGP underlay

The underlay is the routed IP infrastructure that connects the switches and provides IP reachability across the fabric. In a BGP-routed underlay, BGP can advertise the infrastructure prefixes needed to reach loopbacks and other routed destinations. These routes provide the foundation for control-plane sessions and overlay tunnel endpoints where applicable.

The VXLAN EVPN overlay

In a VXLAN EVPN design, VXLAN encapsulates tenant traffic across the IP fabric, while EVPN uses BGP to distribute overlay reachability information. This can include information about MAC addresses, IP addresses and tenant segments, depending on the EVPN route type and deployment.

Component Primary responsibility Example question
Underlay routing IP reachability between routed fabric endpoints. Can this VTEP reach the remote VTEP address?
BGP EVPN control plane Advertises overlay reachability and related information. Has the expected MAC/IP or prefix route been learned?
VXLAN data plane Encapsulates tenant packets across the IP underlay. Can the encapsulated packet traverse the fabric?
Forwarding and policy Applies installed forwarding entries and applicable policies. Does traffic reach the correct destination and tenant?

These functions are related but not interchangeable. A healthy underlay does not prove that EVPN routes are correct, and receiving an EVPN route does not by itself prove that end-to-end forwarding succeeds.

03 / How BGP selects routes

From route advertisement to forwarding

1

Receive: a BGP neighbor advertises a prefix and its associated path attributes. The receiving router evaluates the update against session state, import policy and protocol rules.

2

Validate: the route must be acceptable under policy and protocol requirements. Its next hop must also be resolvable for the route to be usable for forwarding.

3

Select: the router evaluates eligible paths using its BGP decision process and implementation-specific policy. Attributes such as local preference, AS path, origin and MED can influence the outcome; their exact effect depends on the decision context and configuration.

4

Install: the selected route or eligible set of multipaths may be installed into the routing table and forwarding hardware, subject to platform limits, configuration and interactions with other routing sources.

5

Forward: packets are sent using the installed forwarding entries. The actual path depends on the forwarding implementation, ECMP eligibility, hashing and current topology.

Best path is not the same as every installed path. BGP implementations can select a best path while also installing multiple eligible paths for multipath forwarding. Multipath rules and supported attributes vary by platform and configuration.

Why BGP policy matters

BGP exchanges reachability, but policy determines which routes are accepted, preferred, modified or advertised onward. In a data center, an incorrect policy can suppress a required prefix, permit an unintended route or cause traffic to prefer an unexpected exit.

Engineers should explicitly document intended import and export behaviour, allowed prefixes, ASN expectations, next-hop handling and any route attributes used to influence path selection. Reusable policy templates can reduce configuration drift across large fabrics.

04 / ECMP and BGP multipath

How equal-cost paths support fabric capacity

Equal-Cost Multipath (ECMP) allows a router to forward traffic across multiple eligible next hops for a destination. BGP can supply candidate paths, but the routing implementation and configuration determine whether multiple paths are considered equivalent and installed.

Once multiple next hops are installed, forwarding hardware commonly uses a hash of packet or flow fields to select a path. This helps distribute traffic while typically preserving packet ordering within a flow. It does not mean every individual packet is sent down a different path, nor does it guarantee perfectly even utilization.

Mechanism Role Common misconception
BGP best-path selection Chooses a preferred route according to policy and decision rules. It does not necessarily install every received path.
BGP multipath Allows multiple eligible BGP paths to be installed. It is not automatic on every platform or configuration.
ECMP forwarding Distributes eligible flows across equal-cost next hops. It does not guarantee perfect load balance.
LACP Negotiates and manages a Layer 2 link aggregation group. It is not the same mechanism as Layer 3 ECMP.

ECMP and LACP can both use hashing in forwarding or distribution decisions, but they operate at different levels. ECMP selects among Layer 3 next hops; LACP negotiates membership in a Layer 2 aggregated link. A design may use one or both, depending on its physical and logical architecture.

05 / Convergence and failure handling

What happens when a path fails?

When a link or device fails, the fabric must detect the event, update the relevant routing state and adjust forwarding. BGP may withdraw affected routes or advertise revised reachability. The forwarding plane then changes its installed entries as the control plane and hardware respond.

Convergence time depends on failure detection, session behaviour, routing policy, protocol timers, implementation, hardware programming and the scope of the change. BFD may help detect some failures faster when supported and correctly configured, but it is not a universal guarantee of a particular recovery time.

FAILURE 01

Single link loss

If alternate paths remain available and the routing design recognizes the failure, traffic may be redirected through surviving paths. Check both route changes and actual forwarding.

FAILURE 02

Spine or peer loss

Routes or next hops associated with the failed device may be removed. Surviving paths carry the remaining demand, potentially increasing utilization and exposing oversubscription.

FAILURE 03

Policy or route withdrawal

A prefix may disappear even though physical links and BGP sessions remain up. Investigate advertisements, filters, next-hop resolution and the routing table.

FAILURE 04

Session instability

Repeated BGP resets can cause route churn and traffic disruption. Check interface errors, reachability, timers, logs and control-plane resource conditions.

Resilience must be tested under load. Redundant links are useful only if surviving paths have sufficient capacity and forwarding converges as intended. Test representative link and device failures, and measure packet loss, recovery time and post-failure utilization.

06 / Practical BGP troubleshooting

Work from session state to packet forwarding

When a prefix is missing or traffic takes an unexpected path, avoid starting with a broad configuration change. Follow the route through the control plane and forwarding plane, checking each stage before moving to the next.

1

Verify the session. Confirm the intended BGP neighbor is Established, and inspect logs, reset reasons, interface status and reachability between peer addresses.

2

Check received routes. Confirm the expected prefix is being advertised by the peer and received locally. Use the platform's received-route or neighbor-route commands where supported.

3

Inspect policy. Review prefix lists, route maps, import/export policies, community handling, maximum-prefix controls and any policy that could reject or modify the route.

4

Inspect best path and next hop. Identify why a candidate route was selected or rejected. Confirm that the selected next hop is resolvable and reachable.

5

Verify multipath installation. If several paths are expected, check the routing table for multiple installed next hops and confirm that multipath settings and platform capabilities permit them.

6

Validate forwarding. Inspect the forwarding table, interface counters, flow telemetry and packet path. For VXLAN EVPN, also verify underlay reachability, relevant EVPN routes, VTEP reachability and tenant forwarding state.

Example diagnostic commands

These are illustrative Cisco IOS/IOS XE-style commands. Exact syntax and available detail vary by operating system and platform; use the equivalent commands for your switches. 

show ip bgp summary
show ip bgp
show ip route
show ip cef
show running-config | section router bgp

Start with the neighbor summary, then inspect the target prefix and its candidate paths. Check the routing table to determine which route was selected, and inspect the forwarding table to verify the next hop used for packet forwarding. Review the BGP configuration and policies when the observed result differs from the intended design.

  • The relevant BGP neighbor is Established.
  • The expected prefix is received and passes import policy.
  • The selected route has a valid, reachable next hop.
  • Expected ECMP next hops are installed when multipath is intended.
  • Export policy allows the required route to reach downstream peers.
  • Forwarding state and traffic telemetry agree with the expected path.
  • Failure tests confirm acceptable convergence and surviving capacity.

Continue with the BGP Learning Centre

Explore route propagation, best-path selection and fault investigation through the Network Insight BGP Learning Centre. It complements this architecture section with a practical, interactive way to examine BGP behaviour.

Open the BGP Learning Centre: Explore. Trace. Diagnose. →

Engineering takeaway: BGP is not simply a way to establish routing sessions. Its value comes from controlled route distribution, predictable policy, appropriate path selection and verified forwarding behaviour. A reliable fabric requires the control plane, forwarding plane, physical capacity and failure handling to work together.

NETWORK INSIGHT · BGP FABRIC EXPLORER

Explore BGP in a Leaf-Spine Fabric

Select a router, inspect the illustrative BGP sessions, trace how a prefix is learned, and simulate a path failure. See how routing information and forwarding paths work together in a data center network.

Illustrative BGP fabric Sessions established
iBGP eBGP Failed path
Selected element

Spine 1

A spine switch provides fabric transit. Depending on the design, it may establish eBGP sessions with leaf switches and exchange underlay reachability.

Engineering insight

BGP distributes reachability information. The forwarding plane uses the installed routes to move packets; a BGP session being established does not alone prove that an application path is working.

Interactive controls
6Illustrative BGP sessions
2Illustrative available paths
EstablishedSelected scenario state
Follow a route advertisement 10.10.10.0/24
1Prefix learnedA peer advertises reachability to the prefix.
2BGP evaluatesAttributes and policy influence route selection.
3Route installedAn eligible route is installed for forwarding.
4Packet forwardedThe forwarding table directs traffic to a next hop.
Underlay reachability

The underlay provides IP reachability between fabric devices and their loopbacks or next hops. eBGP is often used between leaf and spine switches in routed fabrics, though designs vary.

Route selection and forwarding

BGP applies policy and path-selection rules to choose eligible routes. ECMP may install multiple equal-cost next hops when supported by the routing design and platform.

Educational model only. This topology and its route progression are illustrative, not a live BGP implementation. Real session counts, ASNs, route attributes, ECMP eligibility, convergence and forwarding behavior depend on the configured network and platform.

05 / Observe

Network Visibility, Traffic Intelligence and BGP

You cannot reliably protect a network if you cannot establish what is happening within it. Flow records, packet captures, encrypted-traffic metadata and security logs reveal different aspects of network behaviour and provide evidence for troubleshooting and threat detection.

This section connects traffic analysis with BGP route visibility, helping engineers investigate unexpected communication patterns, routing changes and reachability problems using evidence from multiple layers.

05 / Observe

Network Visibility: From Traffic Flows to BGP Intelligence

Security controls determine what should be allowed. Observability helps engineers establish what is actually happening. By correlating flow records, packet-level evidence, encrypted traffic metadata and routing information, network teams can identify suspicious behaviour, investigate connectivity failures and understand how an incident moves across the network.

A firewall log may show that a connection was permitted, but it rarely explains the entire conversation. A packet capture may reveal a protocol exchange, yet only represent a short interval or one observation point. Flow telemetry can expose communication patterns across a longer period, while routing telemetry can explain which paths were available and why traffic may have taken an unexpected route.

Engineering principle: No single telemetry source provides the complete picture. Strong network investigations correlate evidence from multiple layers rather than treating an alert, a flow record or a routing change as conclusive proof on its own.

5.1 — Choose the right observation method

Flow telemetry

NetFlow and IPFIX

Summarise conversations using fields such as source and destination addresses, ports, protocol, packet counts, byte counts and timestamps. IPFIX provides an extensible framework for exporting structured flow information.

Sampling

sFlow

Uses statistical sampling of packets and interface counters to provide scalable visibility into traffic patterns, particularly in large switched and routed networks. Sampling can miss individual events.

Packet evidence

SPAN and packet capture

SPAN mirrors selected switch traffic to an observation port. Packet captures can reveal protocol headers, retransmissions, handshakes and other details that summaries cannot show. Mirror oversubscription can cause packet loss.

Encrypted traffic

Metadata and behaviour

Connection timing, volume, direction, destination reputation, DNS context where available, TLS handshake metadata and endpoint telemetry can help detect anomalies without assuming that encrypted payloads are readable.

Method Best used for Important limitation
NetFlow / IPFIX Traffic accounting, unusual communication patterns and historical investigation Typically lacks full packet payload and detailed packet-by-packet sequence
sFlow High-volume traffic trends and scalable network sampling Sampling may omit short-lived or low-volume activity
SPAN / packet capture Protocol troubleshooting and detailed session analysis Limited observation point, capture duration and possible mirror-port loss
Endpoint and security logs Process attribution, identity, host events and security outcomes Coverage and reliability depend on instrumentation and log integrity
BGP and routing telemetry Route changes, path selection, reachability and control-plane anomalies A valid route does not prove that the application or forwarding path works

5.2 — Build an evidence chain

Consider a server that suddenly transfers much more data than usual. A single bandwidth graph might identify the spike, but it cannot establish whether the cause is a legitimate backup, a compromised service or an unexpected change in traffic routing. A structured investigation combines several sources.

DetectBaseline deviation
→
CorrelateFlows and identities
→
InspectPackets and logs
→
ValidateRoutes and forwarding

First, establish when the anomaly began. Next, identify the communicating endpoints, destination ports, volume and duration. Compare the behaviour against the normal baseline. Then inspect available DNS, endpoint, firewall and packet evidence. Finally, check whether a route change, next-hop failure or policy update coincided with the event.

Interactive investigation explorer

Select an observation to see what it can establish and what should be checked next.

INVESTIGATION VIEW Flow records: establish who communicated

Compare source and destination addresses, ports, protocol, bytes, packets and timestamps. Identify unusual destinations, repeated connections or a sudden change in traffic volume. Then correlate the flow with endpoint and security logs.

5.3 — Encrypted traffic: visibility without payload inspection

Encryption protects confidentiality, but it does not make every aspect of a connection invisible. Depending on the protocol, configuration and observation point, engineers may still have access to connection duration, byte counts, packet sizes, timing, DNS information, destination addresses and some handshake metadata.

Behavioural baselines

Detect changes in connection frequency, data volume, session duration and communication direction compared with a service's established pattern.

Identity correlation

Combine network observations with endpoint, workload and authentication records to associate a connection with a device, user or application where the evidence supports it.

Protocol-aware analysis

Use available TLS, DNS and transport metadata carefully. Encrypted Client Hello and encrypted DNS can limit visibility into some fields, while QUIC changes what traditional passive inspection can observe.

Important distinction: A large encrypted transfer to an unfamiliar destination is an investigation lead, not proof of data exfiltration. Validate the destination, expected application behaviour, endpoint context and any applicable organisational policy before drawing conclusions.

5.4 — BGP visibility: understand the route behind the traffic

Border Gateway Protocol (BGP) exchanges reachability information between autonomous systems and distributes routes within an autonomous system through iBGP. Its control plane influences the paths that IP packets may follow. For network security and troubleshooting, this means traffic anomalies should sometimes be investigated alongside BGP updates, routing-table changes, next-hop resolution and forwarding state.

Routing intelligence

Three autonomous systems, one destination prefix

Illustrative topology for correlating route propagation with observed traffic.

AS65002 External BGP peer
AS65001 Internal BGP and routing policy
AS65003 External BGP peer

Example destination: 10.10.10.0/24

# Illustrative route observation Prefix: 10.10.10.0/24 Protocol: BGP AS_PATH: 65002 64496 NEXT_HOP: 192.0.2.2 Observation: Route present in BGP table Validation: Confirm best path, next-hop reachability and FIB

The values above are illustrative. They do not describe a live network or establish that this route is selected, reachable or safe.

What should engineers observe?

  • UPDATE activity: identify announcements and withdrawals, including the prefix affected and the time of the change.
  • AS_PATH changes: investigate unexpected path changes, unusual origins and route attributes that may affect selection.
  • Best-path selection: compare competing routes, local preference, AS_PATH length and other attributes in the context of the vendor's decision process and policy.
  • Next-hop resolution: verify that the selected next hop is reachable through the relevant routing information.
  • Forwarding state: confirm that the selected route is programmed into the forwarding information base (FIB) and that traffic can actually traverse the path.
  • Session health: correlate BGP neighbour state transitions, resets, timers and logs with the time the traffic anomaly occurred.
Security note: BGP route leaks and route hijacks can affect reachability or redirect traffic. Monitoring is only one defence. Apply appropriate prefix filtering, route-policy controls, peer validation and, where supported and operationally suitable, RPKI-based Route Origin Validation. ROV validates route-origin authorisation; it does not by itself validate the entire AS_PATH or prevent every routing attack.

5.5 — BGP and traffic telemetry must be correlated

A route appearing in the BGP table is not the same as a successful application connection. BGP provides control-plane reachability information, while the forwarding plane handles packets. An investigation must distinguish a route that has been received from one that has been selected, installed and successfully used.

Observation Possible interpretation Next validation step
Traffic volume drops suddenly Application failure, link problem, filtering or a route change Correlate interface counters, flow records, route events and endpoint health
AS_PATH changes unexpectedly Legitimate policy change, upstream change or suspicious announcement Check the source peer, prefix origin, route policy and trusted routing evidence
BGP route exists, but traffic fails Unresolved next hop, FIB inconsistency, ACL, MTU issue or downstream failure Check route selection, next-hop recursion, FIB, interface state and packet path
Repeated BGP session resets Transport instability, peer configuration, resource pressure or timer expiry Inspect neighbour logs, TCP connectivity, interface errors and control-plane load
Unexpected outbound traffic New workload behaviour, misconfiguration or potentially malicious activity Correlate destination, workload identity, DNS, security events and route history

5.6 — Operational requirements for reliable visibility

Observability systems are only as useful as the quality and consistency of their data. Time synchronisation is essential when correlating events across routers, firewalls, switches, hosts and collectors. Retention policies should preserve enough history to establish a baseline and investigate delayed reports. Telemetry collectors should be monitored for gaps, overload and export failures.

  • Synchronise timestamps across network devices, endpoints and telemetry platforms.
  • Document flow sampling rates, SPAN limitations and which interfaces are actually observed.
  • Monitor telemetry loss, collector health, storage capacity and data-retention windows.
  • Restrict access to sensitive flow records, packet captures and routing logs.
  • Protect management and telemetry channels against unauthorised access or tampering.
  • Establish normal traffic and routing baselines before treating deviations as incidents.
Section takeaway: Effective visibility connects traffic behaviour, security events and routing decisions. Flow records show communication patterns; packet captures provide deeper protocol evidence; encrypted-traffic metadata supports behavioural analysis; and BGP telemetry helps explain changes in network reachability. Correlation turns those separate signals into a defensible engineering investigation.
Network Security Engineering · OBSERVE · Flow telemetry, packet analysis, encrypted traffic metadata and BGP route visibility
NETWORK INSIGHT · VISIBILITY WORKBENCH

Investigate the Data Center with Network Telemetry

Explore how flow records, interface counters, packet captures and BGP telemetry reveal different parts of a network problem. Select a diagnostic view to correlate traffic behavior with routing and forwarding state.

Traffic and telemetry sources Illustrative telemetry
Network connection Selected diagnostic path Warning signal Potential fault
Selected source

Flow telemetry

Flow records summarize conversations between endpoints. They help identify major talkers, traffic direction and volume, but do not normally contain every packet's full contents.

Engineering insight

No single telemetry source explains every fault. Correlating traffic records, interface counters, packet evidence and routing state can narrow the cause much faster.

Diagnostic actions
Flow recordsSelected evidence source
Traffic patternWhat it can reveal
PartialEvidence coverage
Illustrative diagnostic evidence
SignalExample observationInterpretationStatus
Flow recordsLarge app-to-database flowIdentify traffic source and volumeUseful
Interface countersOutput drops increasingInvestigate congestion or queue pressureCheck
Packet captureRetransmissions observedCorrelate loss, delay and endpoint behaviorCheck
BGP telemetryNext-hop route changedVerify route selection and forwarding stateUseful
What the data tells you

Flow telemetry helps locate large or unexpected conversations. It is valuable for traffic engineering and capacity planning, but its detail depends on the exporter, sampling and collection interval.

Correlate before concluding

Compare timestamps and affected paths across telemetry sources. A counter increase, a packet symptom and a routing change are stronger evidence when they align in time and relate to the same flow.

Educational demonstration only. The evidence values are illustrative examples, not live measurements. Available telemetry, sampling, counter definitions, packet visibility and BGP monitoring capabilities vary by platform and deployment.

06 / Respond

Incident Response, Threat Detection and Network Forensics

When suspicious activity is detected, the priority shifts from observation to controlled investigation and response. Engineers must validate the evidence, determine the scope of the incident, preserve relevant records and contain the threat without creating unnecessary operational disruption.

Explore the incident response lifecycle, practical forensic techniques, containment decisions and BGP incident investigation, from the first alert through recovery and lessons learned.

06 / Respond

Incident Response, Threat Detection and Network Forensics

Detecting suspicious activity is only the beginning. Effective incident response requires engineers to validate the alert, establish the scope of the incident, preserve evidence, contain the threat and restore services safely. Network telemetry, endpoint records, security controls and routing information provide complementary evidence that helps teams understand what happened and determine the appropriate response.

A security alert does not automatically establish that a system has been compromised. A sudden increase in outbound traffic, an unfamiliar destination, repeated authentication failures or an unexpected BGP route change may indicate a security incident, a configuration error or legitimate operational activity. The objective is to investigate systematically rather than act on an assumption.

Core principle: Incident response must balance containment, evidence preservation, service availability and business risk. Every action should have a clear purpose, an authorised scope and a way to verify its outcome.

6.1 — The incident response lifecycle

A practical response process moves from preparation through detection, analysis, containment, eradication and recovery. Lessons learned then feed back into monitoring, configuration standards and security controls. In a serious incident, these activities may overlap, and responders may need to revisit earlier stages as new evidence emerges.

PrepareTools, roles and playbooks
→
DetectAlert and validate
→
ContainLimit further impact
→
EradicateRemove root cause
→
RecoverRestore and monitor
Phase 1

Preparation

Define incident ownership, escalation paths, approved containment actions, logging requirements, backup procedures and communication channels before an incident occurs.

Phase 2

Detection and analysis

Validate the alert, establish a timeline, identify affected assets and correlate evidence from network, endpoint, identity and security systems.

Phase 3

Containment

Reduce the opportunity for further harm using proportionate, authorised controls. Consider dependencies and the operational consequences of isolating a device or blocking a communication path.

Phase 4

Eradication and recovery

Remove the confirmed cause, remediate affected systems, restore trusted configurations and verify that services are operating correctly before returning to normal operations.

6.2 — Detect and validate suspicious network activity

Detection systems compare observed activity against rules, threat intelligence, behavioural baselines and known indicators. The resulting alerts must be evaluated in context. An IP address associated with a threat feed, for example, is a useful investigation lead but may be outdated, shared by multiple services or unrelated to the activity under examination.

Signal Potential concern Validation approach
Unusual outbound data volume Possible data transfer or unexpected application behaviour Check flow records, destination, workload identity, scheduled jobs and endpoint events.
Repeated authentication failures Possible credential guessing or account misuse Correlate identity logs, source addresses, successful logins and account activity.
Repeated DNS queries Possible misconfiguration, automated activity or suspicious domain generation Inspect query patterns, resolver logs, domain context and the originating endpoint.
Unexpected east-west traffic Possible lateral movement or a newly introduced dependency Compare with workload communication baselines, segmentation policy and process telemetry.
Unexpected BGP announcement Possible route leak, misconfiguration or unauthorised route propagation Verify the peer, prefix, origin, policy, route history and expected maintenance activity.
Repeated connection resets Possible service instability, filtering or hostile connection activity Correlate packet captures, firewall decisions, server logs and interface counters.

6.3 — Interactive incident investigation

Select a scenario to explore the evidence an engineer should collect before choosing a response. These are illustrative investigation paths, not automated diagnoses.

Investigation workbench

Select a scenario to reveal its evidence requirements and recommended next steps.

INVESTIGATION SCENARIO Unusual outbound data transfer

Establish which host initiated the transfer, the destination, data volume, timing and expected application behaviour. Correlate flow records with endpoint activity, DNS context and available security logs before deciding whether containment is necessary.

6.4 — Network forensics and evidence preservation

Network forensics reconstructs relevant events from available evidence. Depending on the environment, that evidence may include packet captures, NetFlow or IPFIX records, DNS logs, firewall events, authentication records, endpoint telemetry, configuration changes and BGP update history.

Packet captures

Preserve the relevant capture interval and observation point. Record any capture filters, truncation settings, packet loss indicators and limitations affecting interpretation.

Centralised logs

Preserve original records where possible, document collection methods and correlate events using consistent timestamps and asset identifiers.

Configuration history

Compare approved and current firewall rules, ACLs, routing policies, interface configuration and relevant changes made before or during the incident.

Evidence handling: Follow organisational policy and applicable legal requirements. Restrict access to sensitive records, preserve provenance, document collection and handling, and use cryptographic hashes where appropriate to help demonstrate that collected files have not changed.
# Example: calculate a SHA-256 hash of a collected evidence file # Run on an authorised system with access to the evidence file. shasum -a 256 incident-capture.pcap # Record the hash, filename, collection time, collector and storage location. # A hash supports integrity verification; it does not prove the original # capture was complete or that its contents are accurate.

6.5 — Containment: reduce risk without creating another outage

Containment aims to limit the impact of an incident while preserving enough operational capability to investigate and recover. The right action depends on confidence in the evidence, the criticality of the affected service, the likely threat and the available alternatives.

Containment option Potential benefit Risk to consider
Isolate an endpoint Limits some network communications from a suspected host May interrupt critical services or remove access needed for investigation.
Apply a targeted firewall rule Restricts a verified malicious flow or exposure An overly broad rule may block legitimate dependencies.
Disable compromised credentials Reduces the opportunity for further unauthorised access Can interrupt automated workloads or legitimate administrative activity.
Change routing policy May mitigate an established routing threat or isolate an affected path Incorrect changes can cause route withdrawal, traffic blackholing or wider reachability loss.
Increase targeted monitoring Improves evidence collection when immediate isolation is not justified Monitoring alone may be insufficient when active harm is continuing.
Operational safeguard: High-impact containment actions should follow the incident response plan and appropriate authorisation. In a critical network, coordinate changes with service owners, assess failover behaviour and maintain a documented rollback plan wherever feasible.

6.6 — BGP incidents: distinguish control-plane anomalies from forwarding failures

BGP-related incidents require particular care because an incorrect response can affect reachability well beyond a single router. Unexpected route advertisements, route leaks, session instability and policy errors may alter the paths available to traffic. However, a route change alone does not establish malicious intent.

# Illustrative BGP incident triage checklist 1. Identify the affected prefix and first observed change. 2. Determine which peer advertised or withdrew the route. 3. Compare AS_PATH, origin and relevant route attributes. 4. Verify import/export policy and expected maintenance changes. 5. Check the selected route and next-hop resolution. 6. Confirm the FIB and test the affected forwarding path. 7. Apply an authorised mitigation and verify the result.

In an interdomain routing incident, useful safeguards may include carefully maintained prefix filters, explicit import and export policies, maximum-prefix controls, appropriate peer authentication and RPKI Route Origin Validation where supported. ROV helps validate whether an origin AS is authorised to originate a prefix; it does not validate every aspect of the route or prevent every possible BGP attack.

Within an autonomous system, engineers should also check iBGP propagation, route-reflector behaviour, next-hop reachability, IGP dependencies and forwarding state. A route may be visible in one routing table but absent from another, or selected by BGP without being usable for forwarding.

6.7 — Recovery, verification and lessons learned

Recovery is more than removing a block or restarting a service. Before returning affected systems to normal operation, teams should verify that the original cause has been addressed, required security controls are working and relevant traffic is following expected paths.

  • Confirm the affected systems, accounts, prefixes or services have been identified.
  • Remove the confirmed cause and remediate the relevant configuration or vulnerability.
  • Restore systems from trusted sources where required and verify their security posture.
  • Validate routing, next-hop reachability, forwarding state and application connectivity.
  • Maintain heightened monitoring for recurrence and unexpected changes.
  • Document the timeline, decisions, evidence, impact, recovery steps and outstanding risks.
  • Update detection rules, runbooks, access controls and training based on lessons learned.

6.8 — Measure incident response effectiveness

Response metrics help organisations identify gaps and improve operational readiness. They should be interpreted alongside incident severity, service impact and investigation quality rather than treated as isolated performance targets.

Detection

Mean time to detect

Measures the elapsed time between a defined incident starting point and detection. The starting point must be consistently defined for comparisons to be meaningful.

Response

Mean time to contain

Measures how long it takes to implement an effective containment measure after the relevant response clock starts.

Quality

Recurrence and false positives

Review recurring incident causes, unnecessary escalations, detection coverage and whether mitigations actually reduce risk without unacceptable disruption.

Section takeaway: Effective incident response joins detection, evidence preservation, containment, remediation and recovery into a controlled engineering process. Network telemetry and BGP visibility provide important context, but reliable decisions depend on corroborating evidence, understanding operational dependencies and verifying that corrective actions work.
Network Security Engineering · RESPOND · Threat detection, incident handling, network forensics and routing incident investigation
NETWORK INSIGHT · RESILIENCE LAB

What Happens When a Data Center Fabric Fails?

Simulate illustrative link and spine failures in a leaf-spine fabric. Follow the surviving paths, inspect the remaining connectivity and identify what engineers should verify before declaring the fabric resilient.

Leaf-spine fabric connectivity Normal operation
Available connection Traffic path Failed component or link Illustrative alternate path
Scenario analysis

Normal operation

Both spine switches are available. Each leaf has two uplinks, allowing traffic to use multiple fabric paths when routing and forwarding are configured accordingly.

Engineering lesson

Redundancy is only useful when alternate paths are operational, routing converges correctly and the remaining links can carry the offered load.

Test controls
8 / 8Available leaf-to-spine links
2 / 2Available spine switches
2Illustrative paths between selected leaves
Failure investigation checklist
CheckQuestionWhy it mattersStatus
Physical stateAre the links and devices operational?Confirms the failure boundaryBaseline
RoutingHave paths been withdrawn or recalculated?Control-plane state influences path selectionBaseline
ForwardingAre alternate next hops installed?Confirms traffic has a usable pathBaseline
CapacityCan surviving links carry the load?Prevents congestion after failoverBaseline
Resilience is more than redundancy

Multiple links and switches create alternate paths, but they do not guarantee uninterrupted service. Detection time, routing convergence, forwarding updates, hashing and remaining capacity all affect the outcome.

Validate the recovery

After a failure, verify reachability and application behavior, inspect routing and forwarding state, compare interface counters and confirm that the surviving fabric is not overloaded.

Educational model only. This is a simplified two-spine, four-leaf fabric. The diagram illustrates connectivity and possible alternate paths; it does not calculate live routing convergence, ECMP hashing, throughput, packet loss or application availability. Actual behavior depends on topology, routing policy, hardware and configuration.

Network Insight · Architecture Briefing

Designing Data Center Networks for Scale, Visibility and Resilience

Data center topology is more than a diagram of switches and links. It determines how workloads communicate, how capacity scales, how routing adapts to change and how engineers isolate faults when the network behaves unexpectedly.

Six ideas to take away

From architectural foundations to operational troubleshooting, each design decision affects the next.

01
Choose the right architecture

Three-tier designs separate access, aggregation and core functions. Leaf-spine fabrics provide a more consistent path structure for many modern, east-west-heavy workloads.

02
Understand the fabric

Leaf switches connect endpoints; spine switches interconnect the leaves. Clos-style designs can scale horizontally, subject to port count, link speed and oversubscription choices.

03
Design for real traffic

North-south and east-west flows create different demands. Capacity planning must consider traffic concentration, ECMP distribution, burstiness and workload communication patterns.

04
Make routing part of the design

BGP can provide scalable underlay routing in a leaf-spine fabric. Route policy, next-hop reachability, ECMP and convergence behavior all influence the forwarding outcome.

05
Make the network observable

Flow telemetry, interface counters, packet captures and routing telemetry reveal different parts of the story. Correlating them helps connect symptoms to causes.

06
Prove resilience under failure

Redundant links are only the beginning. Test failover, verify routing and forwarding state, check surviving capacity and confirm that affected applications recover.

A simplified fabric mental model

SPINE LAYER Path diversity
Leaf 1Leaf 2Leaf 3Leaf 4
ComputeStorageApplications

Think in layers, paths and failure domains.

A useful fabric design connects physical topology, routing behavior and application requirements. Each layer answers a different engineering question: what is connected, where can traffic travel and what happens when a component is lost?

✓Topology: Are there enough paths between the required endpoints?
✓Routing: Are the intended next hops available and installed?
✓Capacity: Can the remaining fabric carry the expected load?
✓Operations: Can telemetry identify the fault and verify recovery?

The engineering takeaway

A resilient data center is not simply one with redundant links. It is one whose behavior can be understood, measured and tested.

Build around the workload, understand the trade-offs in the chosen topology, validate routing and forwarding, and exercise failure scenarios before they occur in production. The goal is not just connectivity—it is predictable performance and recoverable service.

Continue exploring network architecture through practical diagrams, routing examples and interactive troubleshooting exercises.

Network Insight
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```

Data Center Network Design

by Blog

Data Center Network Design

Data centers are crucial in today’s digital landscape, serving as the backbone of numerous businesses and organizations. A well-designed data center network ensures optimal performance, scalability, and reliability. This blog post will explore the critical aspects of data center network design and its significance in modern IT infrastructure.

Data center network design involves the architectural planning and implementation of networking infrastructure within a data center environment. It encompasses various components such as switches, routers, cables, and protocols. A well-designed network ensures seamless communication, high availability, and efficient data flow.

The traditional three-tier network architecture is being replaced by more streamlined and flexible designs. Two popular approaches gaining traction are the spine-leaf architecture and the fabric-based architecture. The spine-leaf design offers low latency, high bandwidth, and improved scalability, making it ideal for large-scale data centers. On the other hand, fabric-based architectures provide a unified and simplified network fabric, enabling efficient management and enhanced performance.

Network virtualization, powered by technologies like SDN, is transforming data center network design. By decoupling the network control plane from the underlying hardware, SDN enables centralized network management, automation, and programmability. This results in improved agility, better resource allocation, and faster deployment of applications and services.

With the rising number of cyber threats, ensuring robust security and resilience has become paramount. Data center network design should incorporate advanced security measures such as firewalls, intrusion detection systems, and encryption protocols. Additionally, implementing redundant links, load balancing, and disaster recovery mechanisms enhances network resilience and minimizes downtime.

Matt Conran

Highlights: Data Center Network Design

Data Center Network Design

To embark on a successful network design journey, it is essential first to understand the data center’s specific requirements. Factors such as scalability, bandwidth, latency, and reliability need to be carefully assessed. By comprehending the data center’s unique needs, network architects can lay a solid foundation for an optimized design.

Efficiency and resilience are at the core of any well-designed data center network. Building on the requirements identified in the previous section, architects must consider redundancy, load balancing, and fault tolerance principles. The design should minimize single points of failure while maximizing resource utilization and network performance.

Various network topologies and architectures can be employed in data center network design. Each option offers unique advantages and trade-offs, from traditional hierarchical designs to modern approaches like leaf-spine architectures. This section will explore different topologies, highlighting their strengths and considerations.

Virtualization and SDN have revolutionized data center network design, offering increased flexibility and agility. By abstracting network functions from physical infrastructure, virtualization allows for dynamic resource allocation and improved scalability. SDN further enhances network programmability, enabling centralized management and automation. This section will delve into the benefits and implementation considerations of these technologies.

Network, security, and computing

– A data center architecture consists of three main components: the data center network, the data center security, and the data center computing architecture. In addition to these three types of architecture, there are also data center physical architectures and data center information architectures. The following are three typical compositions.

– Network architecture for data centers: Data center networks (DCNs) are arrangements of network devices interconnecting data center resources. They are a crucial research area for Internet companies and large cloud computing firms. The design of a data center depends on its network architecture.

– It is common for routers and switches to be arranged in hierarchies of two or three levels. There are three-tier DCNs: fat tree DCNs, DCells, and others. There has always been a focus on scalability, robustness, and reliability regarding data center network architectures.

– Data center security refers to physical practices and virtual technologies for protecting data centers from threats, attacks, and unauthorized access. It can be divided into two components: physical security and software security. A firewall between a data center’s external and internal networks can protect it from attack.

Data Center Network Design Considerations

a. Understanding the Requirements

Before embarking on the design process, it’s crucial to understand the data center’s unique requirements. Factors such as power and cooling, network connectivity, scalability, and security are vital in determining the design approach. By thoroughly assessing these requirements, architects can create a blueprint that aligns with the organization’s current and future needs.

b. Optimizing Physical Layout

The physical layout of a data center significantly impacts its efficiency and performance. This section will delve into rack placement, aisle design, cable management, and airflow optimization. By adopting best practices in physical layout design, data center operators can minimize energy consumption, reduce maintenance costs, and enhance overall operational efficiency.

c. Redundancy and Resilience

Data centers demand high levels of redundancy and resilience to ensure uninterrupted operations. This section will explore the concept of redundancy in power and cooling systems, backup generators, redundant network connectivity, and failover mechanisms. Implementing robust redundancy measures helps mitigate the risk of downtime and ensures continuous availability of critical services.

4. Security and Compliance

Data centers store sensitive and valuable information, making security a top priority. This section will discuss the importance of physical security measures, access controls, surveillance systems, and fire suppression mechanisms. Additionally, we will explore compliance standards and regulations that govern data center operations, such as SOC 2, ISO 27001, and GDPR.

5. Embracing Green Initiatives

As environmental sustainability gains importance, data centers seek ways to minimize their carbon footprint. This section will focus on energy-efficient design practices, including using renewable energy sources, efficient cooling techniques, and server virtualization. Data centers can contribute to a more sustainable future by adopting green initiatives.

Data Center Network Security 

### What is Cloud Armor?

Cloud Armor is a security service offered by Google Cloud that provides protection against distributed denial-of-service (DDoS) attacks and other web-based threats. It leverages Google’s global infrastructure to offer scalable and reliable protection, ensuring that your applications and services remain available and secure even in the face of large-scale attacks.

### Key Features of Cloud Armor

Cloud Armor comes packed with several features that make it an indispensable tool for modern enterprises. Some of its key features include:

– **DDoS Protection:** Automatically detects and mitigates DDoS attacks, ensuring minimal disruption to your services.

– **Web Application Firewall (WAF):** Provides customizable rules to block malicious traffic and protect against common web vulnerabilities.

– **Edge Security Policies:** Allows you to define security policies at the edge of your network, ensuring threats are mitigated before they reach your core infrastructure.

– **Adaptive Protection:** Uses machine learning to identify and respond to evolving threats in real-time.

### Understanding Edge Security Policies

One of the standout features of Cloud Armor is its ability to implement edge security policies. These policies enable organizations to enforce security measures at the periphery of their network, providing an additional layer of defense. By stopping threats at the edge, you can prevent them from penetrating deeper into your network, thereby reducing the risk of data breaches and other security incidents.

Edge security policies can be tailored to your specific needs, allowing you to block traffic based on various criteria such as IP address, geographic location, and request patterns. This granular control helps you enforce stringent security measures while maintaining the performance and availability of your services.

### Benefits of Using Cloud Armor

Deploying Cloud Armor offers several benefits that can significantly enhance your security posture. These include:

– **Scalability:** Designed to handle traffic spikes and large-scale attacks, ensuring your services remain available even under heavy load.

– **Customization:** Flexible rules and policies allow you to tailor security measures to your unique requirements.

– **Proactive Defense:** Real-time threat detection and mitigation keep your applications protected against the latest cyber threats.

– **Cost-Effective:** By leveraging Google’s global infrastructure, you can achieve enterprise-level security without the need for significant upfront investment.

### What is Google Network Connectivity Center?

Google Network Connectivity Center is a unified platform designed to manage and monitor network connections across a variety of environments. Whether you’re dealing with on-premises data centers, cloud environments, or hybrid setups, NCC provides a centralized control point. It simplifies the complexities involved in network management, allowing IT teams to focus on optimizing performance rather than troubleshooting issues.

### Key Features of Google NCC

#### Unified Management

NCC offers a single pane of glass for managing network connections, making it easier to oversee and control your entire network infrastructure. This unified management approach reduces the need for multiple tools and interfaces, streamlining operations and increasing efficiency.

#### Flexible Connectivity Options

Google NCC supports a range of connectivity options, including VPNs, interconnects, and peering. This flexibility ensures that you can choose the best connectivity method for your specific needs, whether it’s connecting remote offices or integrating with third-party cloud services.

#### Real-Time Monitoring and Analytics

One of the standout features of NCC is its real-time monitoring and analytics capabilities. With detailed insights into network performance and traffic patterns, you can quickly identify and resolve issues, optimize resource allocation, and ensure consistent network performance.

Understanding Network Tiers

Network tiers are a concept that categorizes network traffic based on its importance and priority. By classifying traffic into different tiers, businesses can allocate resources accordingly and optimize their network usage. In the case of Google Cloud, there are two main network tiers: Premium Tier and Standard Tier.

The Premium Tier is designed to deliver exceptional performance and reliability. It leverages Google’s global network infrastructure, ensuring low latency and high throughput for critical applications. By utilizing the Premium Tier, businesses can enhance user experience, reduce latency-related issues, and improve overall network performance.

While the Premium Tier offers top-tier performance, the Standard Tier provides a cost-effective solution for non-critical workloads. It offers reliable network connectivity at a lower price point, making it an excellent choice for applications that do not require ultra-low latency or high bandwidth. By strategically utilizing the Standard Tier, businesses can optimize their network spend without compromising on reliability.

Understanding VPC Networking

VPC, or Virtual Private Cloud, is a virtual network dedicated to a specific Google Cloud project. It allows users to define and manage their network resources, including subnets, IP addresses, and firewall rules. With VPC networking, businesses can create isolated environments and control the flow of traffic within their cloud infrastructure.

Google Cloud’s VPC networking offers a range of powerful features. Firstly, it provides global connectivity, allowing businesses to connect resources across regions seamlessly. Additionally, VPC peering enables secure communication between different VPC networks, facilitating collaboration and data sharing. Moreover, VPC networking offers granular control through firewall rules, ensuring robust security for applications and services.

What is Google Cloud CDN?

Google Cloud CDN, short for Content Delivery Network, is a globally distributed network of servers designed to deliver content to users at blazing-fast speed. Cloud CDN minimizes latency and ensures a seamless user experience by caching your content in strategic locations worldwide. Whether it’s static assets, dynamic content, or even streaming media, Cloud CDN optimizes the delivery process, reducing the load on your origin servers and improving overall performance.

Cloud CDN operates by leveraging Google’s extensive network infrastructure. When a user requests content from your website or application, Cloud CDN intelligently routes the request to the nearest edge location. If the content is already cached at that edge location, it is immediately delivered to the user, eliminating the need for a round trip to the origin server. This not only reduces latency but also saves bandwidth and server resources.

Understanding VPC Network Peering

VPC network peering connects VPC networks from different projects or within the same project within Google Cloud. It enables direct communication between these networks, eliminating the need for complex VPN setups or public IP addresses. This seamless connectivity can significantly enhance collaboration, data sharing, and network management.

Enhanced Security: VPC network peering ensures that communication between peered networks remains isolated from the public internet. This adds an extra layer of security by reducing the exposure to potential cyber threats.

Improved Performance: By leveraging VPC network peering, data can be transferred at incredibly high speeds between peered networks. This enables faster resource access, reduces latency, and enhances overall application performance.

Simplified Network Architecture: VPC network peering allows for a more streamlined and simplified network architecture. Instead of relying on complex gateways or routers, communication between VPCs can be established directly, making network management and troubleshooting more straightforward.

Data Center Network Types

a. The Three-Tier Data Center Network

The three-tier DCN architecture has been a traditional approach in data center networking. It consists of three layers: the access layer, the aggregation layer, and the core layer. Each layer serves a specific purpose, from connecting end devices to aggregating traffic and providing high-speed connectivity. This hierarchical design allows for scalability and redundancy, making it a popular choice for many data centers.

b. Unleashing the Power of Fat Tree Data Center Networks

The fat tree DCN, also known as the Clos network, has gained prominence recently due to its ability to handle large-scale data center deployments. Unlike the three-tier DCN, a fat tree network provides multiple paths between devices, enabling better load balancing and higher bandwidth capacity. Fat tree networks offer low-latency communication and enhanced fault tolerance by utilizing a non-blocking switching fabric, making them ideal for mission-critical applications.

c. Exploring the Revolutionary DCell Approach

The DCell architecture takes a novel approach to data center networking and offers a unique perspective on scalability and fault tolerance. DCell networks are based on a hierarchical structure of cells, where each cell consists of a group of servers connected together. This decentralized design eliminates the need for traditional core switches and enables direct server-to-server communication. With its self-organizing capabilities, DCell networks provide excellent scalability, fault tolerance, and efficient resource utilization.

Composition of Data Center Architecture

Routing and Switching:

Routing is the backbone of a data center network, guiding data packets through the labyrinthine pathways. It involves determining the optimal path for data to travel from source to destination, considering network congestion, latency, and cost factors. Advanced routing protocols like Border Gateway Protocol (BGP) enable dynamic route selection, ensuring efficient and fault-tolerant data delivery.

Switching complements routing by facilitating efficient data transmission within a local network. At the heart of a data center, switches act as intelligent traffic controllers, directing data packets to their intended destinations. With features like VLANs (Virtual Local Area Networks) and Quality of Service (QoS), switches prioritize and prioritize traffic, optimizing network performance and ensuring seamless communication.

stp port states

Example: Spanning Tree Uplink Fast

Spanning Tree Protocol (STP) prevents loops in Ethernet networks by creating a loop-free logical topology and blocking redundant paths. While STP ensures network stability, it can also introduce delays in network convergence. Network downtime caused by STP convergence can be a primary concern for businesses. Even a few seconds of downtime can result in significant losses in critical environments. This is where Spanning Tree Uplink Fast comes into play. Uplink Fast is an enhancement to STP that provides faster convergence times, reducing network downtime and improving overall network efficiency.

How Uplink Fast Works

Uplink Fast allows a switch to detect a link failure on its designated root port and immediately activate an alternate port. This process eliminates the need for the traditional STP convergence process, resulting in faster network recovery times. Uplink Fast is instrumental when network redundancy is crucial, such as in data centers or enterprise networks.

Introducing Spanning Tree MST

Spanning Tree MST enhances the traditional STP, providing a more efficient and flexible solution. MST allows network administrators to divide the network into multiple regions, each with its own Spanning Tree instance. By doing so, MST optimizes network resources and enables load balancing across multiple paths, leading to increased performance and redundancy.

To implement Spanning Tree MST, network switches need to be properly configured. This involves defining regions, assigning VLANs to instances, and configuring parameters such as root bridges and priorities. MST configuration can be complex, but with careful planning and understanding, it offers significant benefits.

Spanning Tree MST offers several key advantages. First, it enables efficient utilization of network resources by load-balancing traffic across multiple paths. Second, it provides enhanced redundancy, ensuring that if one path fails, traffic can automatically reroute through an alternate path. Third, MST simplifies network management by allowing administrators to control traffic flow and prioritize specific VLANs within each instance.

Data Center Security Technologies

Understanding the MAC Move Policy

The MAC Move Policy is a crucial feature in Cisco NX-OS devices that governs the movement of MAC addresses within a network. By defining specific rules and criteria, administrators can control how MAC addresses are learned, aged, and moved across different interfaces and VLANs.

Configuring the MAC Move Policy

Proper configuration is essential to effectively utilizing the MAC Move Policy. This section will guide you through the step-by-step process of configuring the policy on Cisco NX-OS devices. From defining the MAC move parameters to implementing the policy on specific interfaces or VLANs, we will cover all the necessary commands and considerations to ensure a seamless configuration experience.

Understanding MAC ACLs

MAC ACLs, also known as Ethernet ACLs or Layer 2 ACLs, operate at the data link layer of the OSI model. Unlike traditional IP-based ACLs, which focus on network layer addresses, MAC ACLs allow administrators to filter traffic based on MAC addresses. This enables granular control over network access, providing an additional layer of defense against unauthorized devices.

By implementing MAC ACLs on the Nexus 9000 series, network administrators can exercise enhanced control over their network environment. MAC ACLs prevent MAC address spoofing, mitigating the risk of unauthorized devices gaining access. Furthermore, they enable the isolation of specific devices or groups of devices, ensuring that only designated entities can communicate within a given VLAN or network segment.

Understanding VLANs and ACLs

Before we embark on our journey to explore VLAN ACLs’ potential, let’s establish a solid foundation by understanding VLANs and ACLs individually. VLANs (Virtual Local Area Networks) allow us to logically segment networks, improving performance, scalability, and network management. On the other hand, ACLs (Access Control Lists) act as gatekeepers, controlling traffic flow and enforcing security policies.

VLAN ACLs serve as a crucial layer of defense in protecting our networks from unauthorized access, malicious activities, and potential breaches. By implementing VLAN ACLs, we can define granular rules that filter and restrict traffic between VLANs, ensuring that only desired communication occurs. This level of control empowers network administrators to mitigate risks, maintain data integrity, and enforce compliance.

Understanding Nexus Switch Profiles

Nexus switch profiles are a feature of Cisco’s Nexus series switches that allow administrators to define and manage a group of switches as a single entity. By creating a profile, administrators can easily configure and monitor all switches within the group, eliminating the need for repetitive manual configurations. This centralization of management simplifies network administration and saves valuable time and resources.

One of the primary advantages of using Nexus switch profiles is the ability to streamline network operations. With a profile in place, administrators can make changes or updates to configurations across multiple switches simultaneously. This significantly reduces the risk of configuration errors and ensures consistent settings throughout the network. Furthermore, the centralized management approach simplifies troubleshooting and enables faster resolution of network issues.

Data Center Technologies

Understanding Layer 3 Etherchannel

Layer 3 Etherchannel is a link aggregation technique that combines multiple physical links between switches into a single logical channel. By bundling these links together, traffic can be distributed across them, increasing overall bandwidth capacity and providing load-balancing capabilities. Unlike Layer 2 Etherchannel, Layer 3 Etherchannel operates at the network layer, allowing traffic to be routed.

To configure Layer 3 Etherchannel, several steps need to be followed. First, the physical interfaces on the switches need to be identified and grouped into the Etherchannel bundle. Then, a logical interface, the Port-Channel interface, is created and assigned an IP address. Subsequently, routing protocols or static routes can be configured on the Port-Channel interface to enable communication between different networks.

Layer 3 Etherchannel supports various load-balancing algorithms, determining how traffic is distributed across the bundled links. Standard algorithms include source IP, destination IP, and round-robin. Each algorithm has advantages and considerations depending on the network requirements and traffic patterns.

Cisco Nexus 9000 Port Channel

Implementing Port Channels on Cisco Nexus 9000 switches offers several advantages. Firstly, it provides increased link bandwidth, allowing for efficient data transfer and reducing bottlenecks. Secondly, Port Channels enhance network resilience by providing link redundancy. In a link failure, traffic seamlessly switches to the remaining active links. Lastly, Port Channels enable load balancing, distributing network traffic evenly across the aggregated links for optimal utilization.

Setting up a Port Channel on Cisco Nexus 9000 switches is straightforward. Administrators can configure Port Channels using the Link Aggregation Control Protocol (LACP) or the Port Aggregation Protocol (PAgP). Administrators can maximize the benefits of this feature by adequately configuring interfaces and assigning them to the Port Channel.

Understanding Unidirectional Link Detection (UDLD)

UDLD is a layer 2 protocol that helps identify and mitigate the presence of unidirectional links in a network. It works by exchanging periodic messages between neighboring switches to verify bidirectional connectivity. By detecting unidirectional links, UDLD helps prevent potential network issues such as black holes, spanning-tree loops, and data loss.

Cisco Nexus 9000 switches offer seamless integration and support for UDLD. To enable UDLD on a Nexus 9000 switch, administrators can utilize simple commands within the switch configuration. By configuring UDLD timers, administrators can customize the frequency of UDLD messages exchanged between switches. Additionally, UDLD can be configured to operate in either standard or aggressive mode, depending on the specific needs of the network environment.

Understanding VRRP

VRRP, an essential networking protocol, provides automatic failover and load-balancing capabilities. It allows multiple routers to work as a virtual group, presenting a single IP address. By intelligently distributing network traffic, VRRP ensures seamless connectivity even in the face of router failures.

The Nexus 9000 Series, Cisco’s flagship product line, offers a range of cutting-edge features, including VRRP. Designed to meet the demands of modern networks, these switches deliver exceptional performance, scalability, and flexibility. With the Nexus 9000 Series, network administrators can harness the power of VRRP to build a robust and highly available network infrastructure.

Example: Data Center WAN Protocol

BGP, also known as the routing protocol of the Internet, is responsible for exchanging routing and reachability information among autonomous systems (AS). It enables routers to make intelligent decisions about the most optimal paths for data transmission. Unlike interior gateway protocols, BGP focuses on routing between different networks rather than within a single network.

BGP operates on a trust-based model, where routers form peer relationships to exchange routing information. These peers establish connections and exchange routing updates, allowing them to build a complete picture of network reachability. BGP uses a sophisticated algorithm that considers multiple factors, such as path length, quality of service, and policy-based decisions, to determine the best route for traffic.

Understanding BGP AS Prepend

AS Prepend involves adding additional Autonomous System (AS) numbers to the AS path attribute of BGP advertisements. By manipulating the AS path, network operators can influence inbound traffic routing decisions by neighboring autonomous systems. This technique makes a specific path appear less desirable, diverting traffic to alternative paths.

AS Prepend holds excellent potential for optimizing network routing in various scenarios. It can achieve load balancing across multiple links, redirect traffic to less congested paths, or prefer specific transit providers. By carefully implementing AS Prepend, network administrators can improve network performance, reduce latency, and enhance overall service quality.

BGP AS Prepend

Recap: Border Gateway Protocol (BGP) is data centers’ most commonly used routing protocol. It has been used to connect Internet systems worldwide for decades and can also be used outside a data center. The BGP protocol is a standard-based open-source software package. It’s more common to find BGP peering between data centers over the WAN. However, we see BGP often used purely inside the data center.

 Understanding Leaf and Spine Networks

Leaf and spine networks, also known as Clos networks, are a modern approach to data center architecture. The design revolves around a hierarchical structure consisting of two key components: leaf switches and spine switches. Leaf switches connect directly to endpoints, while spine switches interconnect the leaf switches, forming a non-blocking fabric. This architecture eliminates bottlenecks and enables seamless scalability.

BGP (Border Gateway Protocol) is a crucial routing protocol in leaf and spine networks. It ensures efficient data forwarding between leaf switches using a set of rules known as BGP route advertisements. By default, BGP requires every router to have a full mesh of connections with all other routers in the network, which can be resource-intensive. This is where BGP route reflection comes into play.

Understanding BGP Route Reflection

BGP route reflection, at its core, is a method that allows a BGP speaker to reflect routing information to its peers, alleviating the need for full-mesh connectivity. Designating specific BGP routers as route reflectors streamlines and manages the network structure.

The utilization of BGP route reflection offers several advantages. First, it reduces the number of required BGP peering sessions, resulting in a simplified and less resource-intensive network. Second, route reflection enhances scalability by eliminating the need for full-mesh connectivity, particularly in large-scale networks. Third, it improves convergence time and reduces BGP update processing overhead, enhancing overall network performance.

**The third wave of application architectures**

Google and Amazon, two of the world’s leading web-scale pioneers, developed a modern data center. The third wave of application architectures represents these organizations’ search and cloud applications. Towards the end of the 20th century, client-server architectures and monolithic single-machine applications dominated the landscape. This third wave of applications has three primary characteristics:

Unlike client-server architectures, modern data center applications involve a lot of communication between servers. In client-server architectures, clients communicate with monolithic servers, which either handle the request entirely themselves or communicate with fewer than a handful of other servers, such as database servers. Search (or Hadoop, its more popular variant) employs many mappers and reducers instead of search. In the cloud, virtual machines can reside on different nodes but must communicate seamlessly. In some cases, VMs are deployed on servers with the least load, scaled out, or balanced loads.

A microservices architecture also increases server-to-server communication. This architecture is based on separating a single function into smaller building blocks and interacting with them. Each block can be used in several applications and enhanced, modified, and fixed independently in such an architecture. Since diagrams usually show servers next to each other, East-West traffic is often called server communication. Traffic flows north-south between local networks and external networks.

**Scale and resilience**

The sheer size of modern data centers is characterized by rows and rows of dark, humming, blinking machines. As opposed to the few hundred or so servers of the past, a modern data center contains between a few hundred and a hundred thousand servers. To address the connectivity requirements at such scales, as well as the need for increased server-to-server connectivity, network design must be rethought. Unlike older architectures, modern data center applications assume failures as a given. Failures should be limited to the smallest possible footprint. Failures must have a limited “blast radius.” By minimizing the impact of network or server failures on the end-user experience, we aim to provide a stable and reliable experience.

**Data Center Goal: Interconnect networks**

The goal of data center design and interconnection network is to transport end-user traffic from A to B without any packet drops, yet the metrics we use to achieve this goal can be very different. The data center is evolving and progressing through various topology and technology changes, resulting in multiple network designs.  The new data center control planes we see today, such as Fabric Path, LISP, THRILL, and VXLAN, are driven by a change in the end user’s requirements; the application has changed. These new technologies may address new challenges, yet the fundamental question of where to create the Layer 2/Layer three boundaries and the need for Layer 2 in the access layer remains the same. The question stays the same, yet the technologies available to address this challenge have evolved.

Example Protocol: Understanding VXLAN

VXLAN, an encapsulation protocol, enables the creation of virtualized Layer 2 networks over an existing Layer 3 infrastructure. By extending the Layer 2 domain, VXLAN allows the seamless transfer of network traffic between geographically dispersed data centers. It achieves this by encapsulating Ethernet frames within IP packets, providing flexibility and scalability to network virtualization.

Scalability and Flexibility: VXLAN addresses the limitations of traditional VLANs by allowing for a significantly more significant number of virtual networks—up to 16 million—compared to the 4,096 limit of VLANs. This scalability enables organizations to allocate virtual networks more efficiently while accommodating the growing demands of cloud-based applications and services.

Enhanced Network Segmentation and Isolation: VXLAN provides improved network segmentation by creating logical networks that are isolated from one another, even if they share the same physical infrastructure. This isolation enhances security and enables more granular control over network traffic, facilitating efficient multi-tenancy in cloud environments.

VXLAN unicast mode

Modern Data Centers

There is a vast difference between modern data centers and what they used to be just a few years ago. Physical servers have evolved into virtual networks that support applications and workloads across pools of physical infrastructure and into a multi-cloud environment. There are multiple data centers, the edge, and public and private clouds where data exists and is connected. Both on-premises and cloud-based data centers must be able to communicate. Data centers are even part of the public cloud. Cloud-hosted applications use the cloud provider’s data center resources.

Unified Fabric

Through Cisco’s fabric-based data center infrastructure, tiered silos and inefficiencies of multiple network domains are eliminated, and a unified, flat fabric is provided instead, which allows local area networks (LANs), storage area networks (SANs), and network-attached storage (NASs) to be consolidated into one high-performance, fault-tolerant network. Creating large pools of virtualized network resources that can be easily moved and rapidly reconfigured with Cisco Unified Fabric provides massive scalability and resiliency to the data center.

This approach automatically deploys virtual machines and applications, thereby reducing complexity. Thanks to deep integration between server and network architecture, secure IT services can be delivered from any device within the data center, between data centers, or beyond. In addition to Cisco Nexus switches, Cisco Unified Fabric uses Cisco NX-OS as its operating system.

The use of Open Networking

We also have the Open Networking Foundation ( ONF ), which provides open networking. Open networking describes a network that uses open standards and commodity hardware. So, consider open networking in terms of hardware and software. Unlike a vendor approach like Cisco, this gives you much more choice with what hardware and software you use to make up and design your network.

Data Center Performance Parameters

TCP Performance Parameters

TCP (Transmission Control Protocol) is the backbone of modern Internet communication, ensuring reliable data transmission across networks. However, various parameters that determine TCP’s behavior can influence its performance. 

Understanding TCP Window Size: One crucial parameter that affects TCP performance is the window size. The TCP window size refers to the amount of data sent before an acknowledgment is required. A larger window size allows more data to be transmitted without waiting for acknowledgments, thus optimizing throughput. However, substantial window sizes can result in congestion and increased retransmissions.

Congestion Control Mechanisms: Congestion control mechanisms are vital in maintaining network stability and preventing congestion collapse. TCP utilizes algorithms such as Slow Start, Congestion Avoidance, and Fast Recovery to regulate data flow based on network conditions. These mechanisms ensure fairness and efficiency, improving TCP performance and avoiding network congestion.

Timeouts and Retransmission: TCP implements a reliable data transfer mechanism using acknowledgments and timeouts. When a packet is not acknowledged within a specific timeframe, it is considered lost, and TCP initiates retransmission. The selection of appropriate timeout values is crucial to balance reliability and responsiveness. Setting shorter timeouts may lead to unnecessary retransmissions, whereas longer ones can increase latency.

 Selective Acknowledgments and SACK Options: Selective acknowledgments (SACK) enhance TCP performance and recovery from packet loss. SACK lets the receiver inform the sender about specific out-of-order packets received successfully. This enables the sender to retransmit only the necessary packets, reducing unnecessary retransmissions and improving overall efficiency.

Maximum Segment Size (MSS): The Maximum Segment Size (MSS) is another crucial TCP performance parameter defining the maximum amount of data encapsulated within a single TCP segment. Optimizing the MSS can significantly impact performance, especially when network links have different MTU (Maximum Transmission Unit) sizes.

Understanding TCP MSS

TCP MSS refers to the maximum amount of data encapsulated within a single TCP segment. It represents the size of the payload, excluding headers and other overhead. The MSS value is negotiated during the TCP handshake process and remains constant throughout the connection.

The TCP MSS value has a direct impact on network performance and efficiency. Setting an appropriate MSS value ensures optimal network resource utilization and avoids unnecessary data packet fragmentation. Properly configuring TCP MSS becomes crucial when networks have different MTU (Maximum Transmission Unit) sizes.

Fragmentation occurs when the MSS value exceeds the MTU of a network path. This fragmentation can lead to performance degradation, increased latency, and potential packet loss. By carefully managing the TCP MSS value, network administrators can prevent or minimize fragmentation issues and enhance overall network performance.

Configuring TCP MSS requires a thorough understanding of the network infrastructure and the devices involved. It involves adjusting the MSS value at various points within the network, such as routers, firewalls, and load balancers. Aligning the TCP MSS value with the MTU of the underlying network ensures efficient data transmission and avoids unnecessary fragmentation.

Advanced Topics

VXLAN Flood and Learn Mechanism

The flood-and-learn mechanism in VXLAN plays a crucial role in facilitating communication between virtual machines within the overlay network. When a virtual machine sends a broadcast or unknown unicast frame, the frame is encapsulated in a VXLAN packet and flooded throughout the network. Each VXLAN tunnel endpoint (VTEP) learns the source MAC address and VTEP association, enabling subsequent unicast traffic to be directly delivered.

Multicast is a fundamental component of VXLAN flood and learn, offering several benefits. First, using multicast VXLAN reduces bandwidth consumption compared to traditional flooding techniques. Second, multicast enables efficient replicating broadcast, multicast, and unknown unicast traffic across the overlay network. Third, it enhances network scalability by eliminating the need to maintain a multicast group per tenant.

BGP Multipath

Understanding BGP Multipath

BGP multipath is a feature that enables the installation and usage of multiple paths for a single prefix in the routing table. Traditionally, BGP selects a single best path based on factors such as AS path length, origin type, and path attributes. However, with multipath enabled, BGP can utilize multiple paths simultaneously, distributing traffic across them for load balancing and redundancy purposes.

The utilization of BGP multipath brings several advantages to network operators. First, it enhances network resilience by providing redundant paths. In the event of a link failure or congestion, traffic can be automatically rerouted through available alternate paths, ensuring continuous connectivity. Additionally, BGP multipath facilitates load balancing, enabling more efficient utilization of network resources and better traffic distribution across multiple links.

Understanding BGP Next Hop Tracking

BGP next-hop tracking monitors the reachability of the next-hop IP address associated with a particular route. It allows routers to dynamically adjust their routing tables based on changes in the network topology. Routers can make informed decisions about forwarding traffic by continuously tracking the next hop, ensuring optimal path selection.

Enhanced Network Resiliency: BGP next-hop tracking enables routers to detect and respond to network changes quickly. If a next hop becomes unreachable, routers can automatically reroute traffic to an alternative path, minimizing downtime and improving network resiliency.

Load Balancing and Traffic Engineering: Network administrators gain granular control over traffic distribution with BGP next-hop tracking. By monitoring the reachability of multiple next hops, routers can intelligently distribute traffic across different paths, optimizing resource utilization and improving overall network performance.

Improved Network Convergence: Rapid convergence is crucial in dynamic networks. BGP next hop tracking facilitates faster convergence by promptly updating routing tables when next hops become unreachable. This ensures routing decisions are based on current information, reducing packet loss and minimizing network disruptions.

next hop tracking

Related: Before you proceed, you may find the following useful:

  1. ACI Networks
  2. IPv6 Attacks
  3. SDN Data Center
  4. Active Active Data Center Design
  5. Virtual Switch

Data Center Network Design

The Rise of Overlay Networking

What has the industry introduced to overcome these limitations and address the new challenges? – Network virtualization and overlay networking. In its simplest form, an overlay is a dynamic tunnel between two endpoints that enables Layer 2 frames to be transported between them. In addition, these overlay-based technologies provide a level of indirection that allows switching table sizes to not increase in the order of the number of supported end hosts.

Today’s overlays are Cisco FabricPath, THRILL, LISP, VXLAN, NVGRE, OTV, PBB, and Shorted Path Bridging. They are essentially virtual networks that sit on top of a physical network, and often, the physical network is unaware of the virtual layer above it.

Traditional Data Center Network Design

How do routers create a broadcast domain boundary? Firstly, using the traditional core, distribution, and access model, the access layer is layer 2, and servers served to each other in the access layer are in the same IP subnet and VLAN. The same access VLAN will span the access layer switches for east-to-west traffic, and any outbound traffic is via a First Hop Redundancy Protocol ( FHRP ) like Hot Standby Router Protocol ( HSRP ).

Servers in different VLANs are isolated from each other and cannot communicate directly; inter-VLAN communications require a Layer 3 device. Virtualization’s humble beginnings started with VLANs, which were used to segment traffic at Layer 2. It was expected to find single VLANs spanning an entire data center fabric.

VLAN and Virtualization

The virtualization side of VLANs comes from two servers physically connected to different switches. Assuming the VLAN spans both switches, the same VLAN can communicate with each server. Each VLAN can be defined as a broadcast domain in a single Ethernet switch or shared among connected switches.

Whenever a switch interface belonging to a VLAN receives a broadcast frame (the destination MAC is ffff.ffff.ffff), the device must forward it to all other ports defined in the same VLAN.

This approach is straightforward in design and is almost like a plug-and-play network. The first question is, why not connect everything in the data center into one large Layer 2 broadcast domain? Layer 2 is a plug-and-play network, so why not? STP also blocks links to prevent loops.

The issues of Layer 2

The reason is that there are many scaling issues in large layer 2 networks. Layer 2 networks don’t have controlled / efficient network discovery protocols. Address Resolution Protocol ( ARP ) is used to locate end hosts and uses Broadcasts and Unicast replies. A single host might not generate much traffic, but imagine what would happen if 10,000 hosts were connected to the same broadcast domain. VLANs span an entire data center fabric, which can bring a lot of instability due to loops and broadcast storms.

**No hierarchy in MAC addresses**

MAC addressing also lacks hierarchy. Unlike Layer 3 networks, which allow summarization and hierarchy addressing, MAC addresses are flat. Adding several thousand hosts to a single broadcast domain will create large forwarding information tables.

Because end hosts are potentially not static, they are likely to be attached and removed from the network at regular intervals, creating a high rate of change in the control plane. Of course, you can have a large Layer 2 data center with multiple tenants if they don’t need to communicate with each other.

The shared services requirements, such as WAAS or load balancing, can be solved by spinning up the service VM in the tenant’s Layer 2 broadcast domain. This design will hit scaling and management issues. There is a consensus to move from a Layer 2 design to a more robust and scalable Layer 3 design.

But why is Layer 2 still needed in data center topologies? One solution is Layer 2 VPN with EVPN. But first, let us look at Cisco DFA.

The Requirement for Layer 2 in Data Center Network Design

  • Servers that perform the same function might need to communicate with each other due to a clustering protocol or simply as part of the application’s inner functions. If the communication is clustering protocol heartbeats or some server-to-server application packets that are not routable, then you need this communication layer to be on the same VLAN, i.e., Layer 2 domain, as these types of packets are not routable and don’t understand the IP layer.

  • Stateful devices such as firewalls and load balancers need Layer 2 adjacency as they constantly exchange connection and session state information.

  • Dual-homed servers: Single server with two server NICs and one NIC to each switch will require a layer 2 adjacency if the adapter has a standby interface that uses the same MAC and IP addresses after a failure. In this situation, the active and standby interfaces must be on the same VLAN and use the same default gateway.

  • Suppose your virtualization solutions cannot handle Layer 3 VM mobility. In that case, you may need to stretch VLANs between PODS / Virtual Resource Pools or even data centers so you can move VMs around the data center at Layer 2 ( without changing their IP address ).

Data Center Design and Cisco DFA

Cisco took a giant step and recently introduced a data center fabric with Dynamic Fabric Automaton ( DFA ), similar to Juniper QFabric. This fabric offers Layer 2 switching and Layer 3 routing at the access layer / ToR. Firstly, it has a Fabric Path ( IS-IS for Layer 2 connectivity ) in the core, which gives optimal Layer 2 forwarding between all the edges.

Then they configure the same Layer 3 address on all the edges, which gives you optimal Layer 3 forwarding across the whole Fabric.

On the edge, you can have Layer 3 Leaf switches, such as the Nexus 6000 series, or integrate with Layer 2-only devices, like the Nexus 5500 series or the Nexus 1000v. You can connect external routers, USC, or FEX to the Fabric. In addition to running IS-IS as the data center control plane, DFA uses MP-iBGP, with some Spine nodes being the Route Reflector to exchange IP forwarding information.

Cisco FabricPath

DFA also employs a Cisco FabricPath technique called “Conversational Learning.” The first packet triggers a full RIB lookup, and the subsequent packets are switched in the hardware-implemented switching cache.

This technology provides Layer 2 mobility throughout the data center while providing optimal traffic flow using Layer 3 routing. Cisco commented, “DFA provides a scale-out architecture without congestion points in the network while providing optimized forwarding for all applications.”

Terminating Layer 3 at the access / ToR has clear advantages and disadvantages. Other benefits include reducing the size of the broadcast domain, which comes at the cost of reducing the mobility domain across which VMs can be moved.

Terminating Layer 3 at the accesses can also result in sub-optimal routing because there will be hair pinning or traffic tromboning of across-subnet traffic, taking multiple and unnecessary hops across the data center fabric.

The role of the Cisco Fabricpath

Cisco FabricPath is a Layer 2 technology that provides Layer 3 benefits, such as multipathing the classical Layer 2 networks using IS-IS at Layer 2. This eliminates the need for spanning tree protocol, avoiding the pitfalls of having large Layer 2 networks. As a result, Fabric Path enables a massive Layer 2 network that supports multipath ( ECMP ). THRILL is an IEEE standard that, like Fabric Path, is a Layer 2 technology that provides the same Layer 3 benefits as Cisco FabricPath to the Layer 2 networks using IS-IS.

LISP is popular in Active data centers for DCI route optimization/mobility. It separates the host’s location from the identifier ( EID ), allowing VMs to move across subnet boundaries while keeping the endpoint identification. LISP is often referred to as an Internet locator. 

That can enable some triangular routing designs. Popular encapsulation formats include VXLAN ( proposed by Cisco and VMware ) and STT (created by Nicira but will be deprecated over time as VXLAN comes to dominate ).

The role of OTV

OTV is a data center interconnect ( DCI ) technology enabling Layer 2 extension across data center sites. While Fabric Path can be a DCI technology with dark fiber over short distances, OTV has been explicitly designed for DCI. In contrast, the Fabric Path data center control plane is primarily used for intra-DC communications.

Failure boundary and site independence are preserved in OTV networks because OTV uses a data center control plane protocol to sync MAC addresses between sites and prevent unknown unicast floods. In addition, recent IOS versions can allow unknown unicast floods for certain VLANs, which are unavailable if you use Fabric Path as the DCI technology.

The Role of Software-defined Networking (SDN)

Another potential trade-off between data center control plane scaling, Layer 2 VM mobility, and optimal ingress/egress traffic flow would be software-defined networking ( SDN ). At a basic level, SDN can create direct paths through the network fabric to isolate private networks effectively.

An SDN network allows you to choose the correct forwarding information on a per-flow basis. This per-flow optimization eliminates VLAN separation in the data center fabric. Instead of using VLANs to enforce traffic separation, the SDN controller has a set of policies allowing traffic to be forwarded from a particular source to a destination.

The ACI Cisco borrows concepts of SDN to the data center. It operates over a leaf and spine design and traditional routing protocols such as BGP and IS-IS. However, it brings a new way to manage the data center with new constructs such as Endpoint Groups (EPGs). In addition, no more VLANs are needed in the data center as everything is routed over a Layer 3 core, with VXLAN as the overlay protocol.

**Closing Points: Data Center Design**

Data centers are the backbone of modern technology infrastructure, providing the foundation for storing, processing, and transmitting vast amounts of data. A critical aspect of data center design is the network architecture, which ensures efficient and reliable data transmission within and outside the facility.  1. Scalability and Flexibility

One of the primary goals of data center network design is to accommodate the ever-increasing demand for data processing and storage. Scalability ensures the network can grow seamlessly as the data center expands. This involves designing a network that supports many devices, servers, and users without compromising performance or reliability. Additionally, flexibility is essential to adapt to changing business requirements and technological advancements.

Redundancy and High Availability

Data centers must ensure uninterrupted access to data and services, making redundancy and high availability critical for network design. Redundancy involves duplicating essential components, such as switches, routers, and links, to eliminate single points of failure. This ensures that if one component fails, there are alternative paths for data transmission, minimizing downtime and maintaining uninterrupted operations. High availability further enhances reliability by providing automatic failover mechanisms and real-time monitoring to promptly detect and address network issues.

Traffic Optimization and Load Balancing

Efficient data flow within a data center is vital to prevent network congestion and bottlenecks. Traffic optimization techniques, such as Quality of Service (QoS) and traffic prioritization, can be implemented to ensure that critical applications and services receive the necessary bandwidth and resources. Load balancing is crucial in evenly distributing network traffic across multiple servers or paths, preventing overutilizing specific resources, and optimizing performance.

Security and Data Protection

Data centers house sensitive information and mission-critical applications, making security a top priority. The network design should incorporate robust security measures, including firewalls, intrusion detection systems, and encryption protocols, to safeguard data from unauthorized access and cyber threats. Data protection mechanisms, such as backups, replication, and disaster recovery plans, should also be integrated into the network design to ensure data integrity and availability.

Monitoring and Management

Proactive monitoring and effective management are essential for maintaining optimal network performance and addressing potential issues promptly. The network design should include comprehensive monitoring tools and centralized management systems that provide real-time visibility into network traffic, performance metrics, and security events. This enables administrators to promptly identify and resolve network bottlenecks, security breaches, and performance degradation.

Data center network design is critical in ensuring efficient, reliable, and secure data transmission within and outside the facility. Scalability, redundancy, traffic optimization, security, and monitoring are essential considerations for designing a robust, high-performance network. By implementing best practices and staying abreast of emerging technologies, data centers can build networks that meet the growing demands of the digital age while maintaining the highest levels of performance, availability, and security.

Example Product: Data Center Monitoring

#### Understanding Cisco ThousandEyes

Cisco ThousandEyes is a comprehensive network intelligence platform that offers deep insights into the performance and health of your data center. By leveraging cloud-based agents and on-premises appliances, ThousandEyes provides end-to-end visibility across your entire network, from your data center to the cloud and beyond. This holistic approach allows IT teams to quickly identify and resolve issues, ensuring that your data center operates at peak efficiency.

#### Key Features of Cisco ThousandEyes

One of the standout features of Cisco ThousandEyes is its ability to deliver real-time insights into network performance. With its advanced monitoring capabilities, ThousandEyes can detect anomalies, pinpoint bottlenecks, and provide actionable data to help you optimize your data center operations. Here are some of the key features that make ThousandEyes a valuable asset:

– **End-to-End Visibility:** Monitor the entire network path, from the user to the application, ensuring no blind spots.

– **Cloud and On-Premises Integration:** Seamlessly integrate with both cloud-based and on-premises infrastructure for comprehensive coverage.

– **Real-Time Alerts:** Receive instant notifications of any performance issues, allowing for swift resolution.

– **Detailed Reporting:** Generate in-depth reports that provide insights into network performance trends and potential areas for improvement.

#### Benefits of Using Cisco ThousandEyes for Data Center Performance

Implementing Cisco ThousandEyes in your data center can deliver a range of benefits that contribute to enhanced performance and reliability. Some of the key advantages include:

– **Proactive Issue Resolution:** By identifying potential problems before they escalate, ThousandEyes helps prevent downtime and ensures continuous service delivery.

– **Improved User Experience:** With optimized network performance, users enjoy faster, more reliable access to applications and services.

– **Cost Efficiency:** By reducing downtime and improving operational efficiency, ThousandEyes can help lower overall IT costs.

– **Scalability:** As your business grows, ThousandEyes can scale with you, providing consistent performance monitoring across expanding networks.

#### Real-World Applications

Many organizations have successfully leveraged Cisco ThousandEyes to boost their data center performance. For example, a global financial services company used ThousandEyes to monitor their network and quickly identify a latency issue affecting their trading platform. By resolving the issue promptly, they were able to maintain their competitive edge and deliver a seamless experience to their clients. Similarly, an e-commerce giant utilized ThousandEyes to ensure their website remained responsive during peak shopping seasons, resulting in increased customer satisfaction and sales.

 

Summary: Data Center Network Design

In today’s digital age, data centers are the backbone of countless industries, powering the storage, processing, and transmitting massive amounts of information. However, the efficiency and scalability of data center network design have become paramount concerns. In this blog post, we explored the challenges traditional data center network architectures face and delved into innovative solutions that are revolutionizing the field.

The Limitations of Traditional Designs

Traditional data center network designs, such as three-tier architectures, have long been the industry standard. However, these designs come with inherent limitations that hinder performance and flexibility. The oversubscription of network links, the complexity of managing multiple layers, and the lack of agility in scaling are just a few of the challenges that plague traditional designs.

Enter the Spine-and-Leaf Architecture

The spine-and-leaf architecture has emerged as a game-changer in data center network design. This approach replaces the hierarchical three-tier model with a more scalable and efficient structure. The spine-and-leaf design comprises spine switches, acting as the core, and leaf switches, connecting directly to the servers. This non-blocking, high-bandwidth architecture eliminates oversubscription and provides improved performance and scalability.

Embracing Software-Defined Networking (SDN)

Software-defined networking (SDN) is another revolutionary concept transforming data center network design. SDN abstracts the network control plane from the underlying infrastructure, allowing centralized network management and programmability. With SDN, data center administrators can dynamically allocate resources, optimize traffic flows, and respond rapidly to changing demands.

The Rise of Network Function Virtualization (NFV)

Network Function Virtualization (NFV) complements SDN by virtualizing network services traditionally implemented using dedicated hardware appliances. By decoupling network functions, such as firewalls, load balancers, and intrusion detection systems, from specialized hardware, NFV enables greater flexibility, scalability, and cost savings in data center network design.

Conclusion:

The landscape of data center network design is undergoing a significant transformation. Traditional architectures are being replaced by more scalable and efficient models like the spine-and-leaf architecture. Moreover, concepts like SDN and NFV empower administrators with unprecedented control and flexibility. As technology evolves, data center professionals must embrace these innovations and stay at the forefront of this paradigm shift.