SIGCOMM 2026: Google GGN Rebuilds Its Global WAN

SIGCOMM 2026: Google GGN Rebuilds Its Global WAN

GGN: Experiences in Designing and Deploying the Next-Generation Google Global Network

Google’s global wide-area network has evolved through several architectural generations. The B2 network was optimized for highly available Internet-facing traffic, while B4 was purpose-built as a software-defined WAN for high-capacity inter-datacenter traffic.

That separation made sense when the workloads and operational requirements were more distinct. The rapid growth of cloud services, distributed applications, and large-scale AI training has changed the equation.

At hyperscale, maintaining two independent WAN architectures creates duplicated control planes, operational complexity, isolated capacity pools, and different failure modes. Meanwhile, cloud customers increasingly expect predictable bandwidth, latency, availability, and service-level objectives (SLOs) across regions.

The architecture described in the SIGCOMM 2026 paper introduces GGN (Global Backbone Network) as Google’s next-generation global backbone. Rather than continuing to optimize B2 and B4 independently, GGN unifies their capabilities around three architectural principles:

• Core Sharding — split the global backbone into independently operated network planes.
• Regionalization — establish hard control-plane boundaries around geographic regions.
• Vendor-Agnostic Hardware — standardize the WAN hardware interface so multiple commercial platforms can be deployed interchangeably.

The result is a WAN designed around failure containment, horizontal scalability, rapid hardware adoption, and enforceable SLOs.

🏗️ Why Google Needed a New Global Network

#

Google’s original B2/B4 split provided useful specialization:

• B2: A carrier-style IP/MPLS network primarily serving consumer-facing Internet traffic.
• B4: A software-defined WAN optimized for high-capacity, high-utilization inter-datacenter traffic.

However, the two-network model introduced several structural limitations as Google’s infrastructure scaled.

Duplicated control planes and operational systems

#

B2 and B4 historically maintained independent control planes, management systems, and operational workflows.

Introducing a capability such as IPv6 support or a new QoS class could therefore require separate engineering and deployment processes. The result was duplicated development effort and slower feature rollout.

Different scaling bottlenecks

#

B2’s distributed MPLS-TE architecture accumulated increasing amounts of protocol state as the network grew. Large numbers of Label Switched Paths (LSPs) placed additional pressure on control-plane processing and operational state.

B4 took the opposite approach, relying heavily on centralized SDN control to achieve sophisticated traffic engineering. This enabled high network utilization, but it also introduced a different class of failure risk: a control-plane defect could potentially affect a large portion of the global network.

At the hardware layer, B4 also faced increasingly constrained forwarding-table resources as tunnel and traffic-engineering requirements expanded.

Isolated capacity pools

#

B2 and B4 capacity could not simply be treated as one common resource.

A major physical failure, such as a submarine cable outage, could leave one network congested while capacity remained available on the other. Because the underlying architectures were different, moving traffic between the two was not straightforward.

For cloud customers, this becomes particularly important. Internal Google applications can often rely on application-level load balancing and redundancy, but customers running distributed services across regions require the underlying network to provide predictable availability and performance.

GGN addresses these limitations by treating the global WAN as a collection of independent but coordinated domains rather than one monolithic system.

🎯 Four Core Objectives

#

The GGN design is centered around four objectives:

1. Contain global failures so a control-plane or infrastructure problem does not automatically become a worldwide outage.
2. Scale horizontally by adding independent network capacity instead of continuously expanding a single global control domain.
3. Accelerate network evolution by allowing hardware and software components to evolve independently.
4. Make SLOs enforceable through explicit bandwidth, latency, availability, and packet-loss policies.

These requirements lead directly to GGN’s three major architectural pillars.

🧩 GGN Architecture: Edge, Core, and Narrow APIs

#

GGN avoids building one globally omniscient control system.

Instead, the architecture divides the WAN into multiple functional domains that interact through narrowly defined interfaces.

At the highest level, there are two major domains:

Core Domain

#

The Core provides transit connectivity between edges and is divided into:

• Global Core — connects geographic regions.
• Regional Core — provides connectivity within an individual region.

Edge Domain

#

The Edge provides the ingress and egress points for traffic:

• Compute Edge — connects to Google’s compute infrastructure.
• Customer Service Edge — connects to Google Cloud customers through direct-interconnect services.
• Internet Edge — connects Google’s network to external Internet peers and transit providers.

The boundary between Edge and Core is defined by the Edge-Core API.

Rather than exposing the complete internal implementation of one domain to another, the API provides a limited set of required information.

Two particularly important interfaces are:

• Routing API: Uses eBGP to exchange the minimum reachability information required by the adjacent domains.
• Bandwidth API: Uses Google’s BwE4 bandwidth-enforcement system to communicate capacity allocations from the Core to the Edge.

This narrow interface is an important reliability mechanism.

The Edge does not need to understand the Core’s internal control logic, while the Core cannot arbitrarily manipulate the internal behavior of the Edge. Each domain can therefore evolve independently while limiting the blast radius of software failures.

🧱 Pillar 1: Core Sharding

#

The most fundamental architectural change in GGN is Core Sharding.

Instead of operating one globally interconnected core, GGN divides the backbone into multiple physically isolated global networks called shards.

The existing B4 infrastructure becomes Shard 1, followed by additional shards such as Shards 2, 3, and 4.

Each shard maintains its own:

• Data-forwarding plane
• SDN control plane
• Physical network resources
• Failure domain

There is no direct internal interconnection between shards within the Core. Instead, edge routers connect to multiple shards and distribute traffic across them.

Why sharding improves resilience

#

Core Sharding changes the failure model from:

One global control plane → potentially global failure

to:

Multiple independent planes → localized failure domain

This provides several advantages.

Failure isolation: A software defect in one shard does not directly disable the forwarding plane of every other shard.

Horizontal scaling: Capacity can be increased by adding additional network planes rather than continually enlarging one global topology.

N+1 resilience: The network can be provisioned so that the remaining shards have enough capacity to preserve high-priority traffic when one shard is unavailable.

The architecture therefore treats redundancy as a property of the network’s structure rather than simply adding more backup paths inside one topology.

🧠 Shard Enforcer: Policy-Driven Traffic Placement

#

A critical component of GGN is the Shard Enforcer (SE).

The SE resides within the BwE control plane of each Edge domain and acts as a policy engine for shard selection.

It continuously tracks:

• Shard bandwidth availability
• Reachability state
• Network policy
• Traffic priority
• SLO requirements

The SE can then push shard-selection policies toward edge routers using BGP and coordinate with host-side BwE mechanisms to adjust application traffic quotas.

This is different from relying exclusively on conventional routing convergence.

Traditional routing primarily reacts after a failure. The SE can make proactive decisions based on capacity, policy, and SLO requirements.

⚡ Multi-Tier Failure Response

#

GGN uses multiple layers of protection rather than waiting for a single controller to recover the network.

1. Sub-second data-plane protection

#

PRR (Packet-level Protection Reroute) provides rapid protection at the packet/data-plane level.

Host networking can immediately re-hash traffic toward healthy shards, reducing the duration of black-hole conditions before higher-level control systems react.

2. Second-level edge routing

#

BGP detects route withdrawals and allows edge routers to stop directing traffic toward an unavailable shard.

3. Minute-level SDN optimization

#

The Shard Enforcer and associated controllers can then recalculate broader bandwidth allocations.

This slower layer is particularly useful for failures that do not completely black-hole traffic, such as partial capacity degradation or persistent congestion.

The important design principle is that fast protection and slower optimization operate together.

🚦 Traffic Classes and SLO Protection

#

GGN divides workloads into four traffic tiers:

The highest-priority traffic is protected first when a shard becomes unavailable.

Lower-priority traffic can be throttled or degraded to preserve customer-facing commitments.

The architecture uses N-1 capacity planning. With four shards, for example, the remaining three are provisioned with enough aggregate capacity to support the required high-priority workload after losing one complete shard.

The exact behavior depends on traffic class and available capacity rather than treating every packet equally during a failure.

⚖️ The ECMP Constraint

#

Current switch-table limitations introduce another engineering trade-off.

Cross-shard traffic distribution relies on ECMP (Equal-Cost Multi-Path). If different shards have asymmetric physical capacity, ECMP’s equal-cost assumptions can result in temporary load imbalance.

This limitation motivates further work toward WCMP (Weighted Cost Multi-Path), which can better account for differences in available capacity.

🌎 Pillar 2: Regionalization

#

Core Sharding protects against failures that could otherwise propagate through the global control plane.

Regionalization addresses another problem: preventing failures inside one geographic region from escaping into the rest of the network.

GGN deploys independent Traffic Engineering (TE) and BwE controller clusters within geographic regions.

A regional controller primarily understands and manages its own local topology rather than maintaining complete visibility into Google’s global WAN.

Local and Global Control

#

Traffic is divided into two broad categories:

• Intra-region traffic: Managed autonomously by the regional control plane.
• Inter-region traffic: Coordinated between regional and global controllers.

This creates a hierarchy of responsibility without requiring a single controller to maintain global visibility of every network detail.

🛡️ Border Nodes Create Hard Boundaries

#

Regional and global domains meet at Border Nodes.

Although physical infrastructure may be shared at these boundaries, the control domains remain logically isolated.

One particularly important rule is that regional controller policies take precedence over global policies when conflicts occur.

This prevents a misconfigured global policy from automatically overriding regional protection mechanisms.

The physical links attached to Border Nodes can also be logically partitioned.

One portion of the available bandwidth can be reserved for regional traffic, while the remainder serves inter-region transit. These allocations can be adjusted through software without physically replacing the links.

This creates a useful property: regional protection can be enforced without requiring completely independent physical infrastructure for every control domain.

🧰 Pillar 3: WBB and Vendor-Agnostic WAN Hardware

#

B4 relied heavily on Google’s custom networking hardware.

GGN moves toward a more standardized hardware model through the WAN Building Block (WBB).

Instead of treating a specific router model as part of the architecture, WBB defines the functional requirements and software interfaces that compatible devices must provide.

This changes the hardware strategy in three ways.

Reducing vendor concentration

#

Using multiple vendors reduces dependence on a single hardware supplier and limits the potential impact of vendor-specific firmware defects.

Faster hardware adoption

#

Commercial networking hardware can evolve independently from Google’s control-plane software.

Google can therefore adopt new forwarding ASICs and hardware platforms without redesigning the entire WAN control architecture around each device generation.

Focusing engineering effort on software

#

With hardware behavior abstracted behind standardized interfaces, engineering resources can focus more heavily on:

• Traffic engineering
• Bandwidth scheduling
• Failure recovery
• Control-plane reliability
• Network automation

🔌 Open Interfaces

#

WBB relies heavily on open and standardized interfaces, including the OpenConfig ecosystem:

• gNMI — configuration and telemetry
• gNOI — operational and device-management functions
• gRIBI — programmed forwarding-table injection
• gRPC — service communication and device management

The objective is to make the control plane independent of any particular vendor’s hardware implementation.

📦 Abstract Hardware SKUs

#

WBB also avoids defining the WAN in terms of specific vendor models.

Instead, a hardware SKU is described through functional properties such as:

• Forwarding capacity
• Throughput
• Power consumption
• Required interfaces
• Hardware capabilities

Different vendors can therefore supply devices that satisfy the same functional specification.

Google can also deliberately distribute vendors across different shards. A vendor-specific software or firmware defect is then less likely to affect every shard simultaneously.

💰 TCO Trade-Off

#

According to the paper’s evaluation, the WBB approach is approximately cost-neutral over a five-year total-cost-of-ownership period compared with Google’s custom hardware approach, with the cited analysis showing roughly a 2% difference.

The architectural overhead is similarly limited:

• Core sharding: approximately 2–5% additional network cost.
• Regionalization: approximately 1% additional operational overhead.

The key argument is that these relatively small costs buy substantially stronger isolation and greater hardware deployment flexibility.

🚚 Migrating Tens of Terabits Without a Hard Cutover

#

Replacing a production WAN carrying enormous amounts of traffic cannot be accomplished through a single migration event.

GGN instead uses a gradual migration strategy.

1. Build physical interconnects

#

The first step is establishing physical links between legacy B2 edge infrastructure and the new GGN core.

2. Move Tier-0 traffic first

#

User-facing, high-priority traffic is migrated to Shard 1, which is based on the existing B4 infrastructure.

This provides an important validation stage for the new architecture while keeping the migration scope controlled.

3. Let new traffic populate the new shards

#

Rather than forcing every existing application to migrate simultaneously, newly generated traffic can be directed toward Shards 2–4.

This allows GGN capacity to grow organically.

4. Use host-level steering

#

Hosts can mark packets to identify whether traffic should use the sharded architecture.

This provides fine-grained control at the level of:

• Applications
• Destination clusters
• Traffic flows
• Workloads

Such steering is considerably more granular than moving an entire network prefix at once.

5. Automate migration safety checks

#

Before traffic is shifted, automated systems evaluate factors including:

• Available shard bandwidth
• Layer-3 and Layer-7 SLOs
• Source-to-destination latency
• Current network capacity
• Failure headroom

The result is a migration process that treats every traffic shift as a controlled experiment rather than a one-time global cutover.

📈 Reported Deployment Scale

#

According to the paper’s reported deployment status, by July 2026, Shards 2–4 represented approximately 35% of total GGN capacity.

In some large AI-cluster regions, sharded traffic accounted for as much as 40%.

The paper also reports that overall GGN capacity had reached approximately 45× the capacity of B4 in 2019, with deployment velocity equivalent to adding a complete 2019-era B4 network roughly every two months.

These figures illustrate the central motivation for horizontal scaling: GGN is designed to expand by adding independent capacity rather than repeatedly enlarging one monolithic global network.

🧪 What Google Learned From Operating GGN

#

The architecture is not simply a collection of theoretical mechanisms. The paper also reports lessons from applying the design to real WAN failures.

📊 Historical Failure Analysis

#

Google’s analysis of WAN incidents from 2021 through 2025 reportedly found that:

• 56% of historical outages would have been completely mitigated by GGN’s deployed architecture.
• A further 37% fell within capabilities that were actively being rolled out.
• Approximately 5.3% remained outside the architecture’s intrinsic prevention capabilities.

The numbers illustrate an important distinction: high availability does not come from one mechanism.

It emerges from combining physical isolation, independent control planes, rapid packet-level protection, traffic prioritization, and regional boundaries.

🛡️ Active Path Diversity

#

High-priority traffic does not necessarily depend on a single active path with another path waiting in standby.

Instead, traffic can use multiple physically separated paths simultaneously.

PRR then provides rapid protection when one path becomes unavailable.

This reduces dependence on controller reaction time during the most critical portion of a failure.

🔄 TE Auto-Fallback

#

GGN also implements fallback behavior for Traffic Engineering controller failures.

If the higher-level TE control system becomes unavailable, the network can fall back toward underlying routing mechanisms such as BGP or IS-IS.

This creates a hierarchy of control:

Advanced optimization → basic routing → continued forwarding

The objective is graceful degradation rather than total loss of connectivity when an advanced controller fails.

🌳 Tree Tunnels

#

Another optimization addresses tunnel-state explosion.

Traditional mesh-style tunneling can require O(N²) relationships as the number of endpoints grows.

GGN introduces merged tree-structured tunnels, allowing multiple flows or destinations to share forwarding structures.

According to the reported results, this can reduce hardware forwarding-table entries by as much as 90%.

That is particularly important when switch hardware has fixed table capacity.

☁️ NCS-Free Architecture

#

GGN also moves control software away from dedicated network servers and into Google’s general-purpose Borg container infrastructure.

This allows control-plane resources to scale dynamically with demand and reduces the operational burden of maintaining dedicated server infrastructure.

The broader architectural principle is consistent with GGN’s hardware strategy: network intelligence should be software-defined and independently scalable.

🔬 Multi-Vendor Testing at Hyperscale

#

A vendor-agnostic hardware strategy only works if different platforms can be validated consistently.

Google therefore developed and open-sourced several networking tools.

ONDATRA

#

ONDATRA provides automated testing for network devices.

It helps validate device behavior against standardized requirements rather than relying on manual testing.

Feature Profiles

#

Feature Profiles define standardized test suites that vendors can execute within their own laboratories.

This allows hardware suppliers to perform compatibility validation before equipment reaches Google’s production test environments.

KNE

#

KNE (Kubernetes Network Emulation) provides containerized network-device emulation.

Instead of requiring a large physical testbed for every development iteration, engineers can reproduce significant portions of network behavior in software.

Together, these tools create a testing pipeline that matches the philosophy of WBB:

Standardize the interface, automate validation, and keep hardware implementations interchangeable.

☁️ GGN Compared With Other Hyperscale WAN Architectures

#

Google is not alone in redesigning WAN architecture around cloud and AI workloads.

The major hyperscalers have taken different approaches to similar problems.

The architectures differ in implementation, but several common trends emerge:

• Smaller failure domains
• Multiple independent network planes
• Greater separation between regional and global control
• Software-defined traffic engineering
• Increasing hardware abstraction
• More sophisticated host-to-network coordination

The interesting difference is how each hyperscaler balances isolation, hardware customization, controller centralization, and host-level traffic control.

GGN’s defining characteristic is the combination of these mechanisms into one architecture: sharded global planes, hard regional boundaries, and standardized commercial hardware.

🧭 What GGN Changes About Hyperscale WAN Design

#

GGN represents a significant shift in how a global WAN can be structured.

The traditional model tends toward a highly interconnected global system where routing, traffic engineering, and hardware state must scale with the entire network.

GGN instead introduces explicit boundaries at multiple levels:

                         GGN Global Backbone
                                │
                ┌───────────────┴───────────────┐
                │                               │
          Global Control                 Regional Control
                │                               │
        ┌───────┼───────┐                ┌──────┴──────┐
        │       │       │                │             │
     Shard 1 Shard 2 Shard 3...       Region A      Region B
        │       │       │                │             │
        └───────┼───────┘                └──────┬──────┘
                │                               │
             Edge-Core API                 Border Nodes
                │                               │
        ┌───────┼────────┐              Regional Services
        │       │        │
     Compute Customer Internet
      Edge     Edge      Edge

Each boundary serves a specific purpose:

• Shards contain global core failures.
• Regions contain geographic and controller failures.
• APIs isolate software domains.
• WBB isolates control software from hardware vendors.
• Traffic tiers isolate critical workloads from congestion.
• Host-level steering provides fine-grained migration and recovery control.

This is essentially a defense-in-depth strategy for network architecture.

🔮 What’s Next for GGN?

#

The reported roadmap focuses on extending the architecture rather than replacing its fundamental principles.

Key areas include:

1. Global Core Sharding rollout — extending sharded and regionalized architecture across the remaining global footprint.
2. WCMP adoption — moving beyond ECMP to better distribute traffic across asymmetric shard capacities.
3. Broader PRR and FRR coverage — extending rapid protection mechanisms across additional traffic classes.
4. Continued hardware abstraction — expanding the pool of interchangeable commercial networking platforms.
5. Further automation — increasing the amount of migration, validation, and failure response that can be performed automatically.

The broader direction is clear: the network itself becomes a distributed software system with explicit fault boundaries, independently scalable components, and programmable traffic policies.

🏁 Conclusion

#

Google’s transition from B2 and B4 toward GGN is more than a capacity upgrade. It represents a change in the fundamental failure model of a hyperscale WAN.

Instead of relying on one globally coordinated network, GGN divides the system into independent shards, regional control domains, and hardware-agnostic building blocks.

The three architectural pillars work together:

• Core Sharding limits the blast radius of global control-plane and infrastructure failures.
• Regionalization prevents local failures and policies from unnecessarily propagating across the world.
• WAN Building Blocks allow Google to adopt commercial hardware without tightly coupling the control plane to specific vendors.

Above them, mechanisms such as PRR, traffic-tier prioritization, BwE, host-level steering, and automated validation provide the operational layer required to run the architecture at hyperscale.

The resulting design reflects the changing requirements of cloud and AI infrastructure. At tens or hundreds of terabits per second, reliability is no longer achieved simply by adding more links or bigger routers. It requires architectural isolation, rapid software-driven recovery, horizontal scalability, and precise control over how every class of traffic uses the available network.

GGN’s most important idea is therefore not any individual protocol or hardware platform. It is the decision to make failure containment a first-class architectural property of the global WAN.