Google Cloud BGP route policies: 3 use cases worth stealing

Key Takeaways

• Policy named sets now let you group IPv4/IPv6 prefixes or BGP communities into reusable entities, cutting configuration sprawl across multiple Cloud Routers
• The most common use case is 'fail closed' route filtering, where a drop-all policy at the end of evaluation prevents hijacks and routing loops
• Enterprises with stateful firewalls are solving asymmetric routing by tagging routes with BGP communities and adjusting MED values in Cloud Router

Google Cloud has published a breakdown of the three most requested BGP route policy patterns its customers built over the past year. The company also announced policy named sets for Cloud Router, a feature that groups IPv4/IPv6 prefixes or BGP communities into single, reusable entities. For network teams managing complex hybrid environments, these patterns solve real problems: blocking unwanted routes, steering traffic across active/standby links, and forcing symmetric paths through stateful firewalls.

What changed with policy named sets?

When Google made BGP route policies generally available over a year ago, the pitch was programmable control over route evaluation and propagation without third-party virtual appliances. The reality, according to Google's own observation, is that configurations got messy as environments scaled. Managing individual prefixes or communities across multiple Cloud Routers became cumbersome.

Policy named sets fix this by letting you define a list once and reference it everywhere. You create a named set containing, say, all your internal subnet prefixes. Then every Cloud Router that needs to act on those prefixes references the same set. Update it in one place; the change propagates. The feature runs on the Common Expression Language (CEL), which means the same fine-grained, ordered rule syntax applies.

Pattern 1: Route filtering with a fail-closed default

The most common pattern Google observed is strict route filtering. Network teams use BGP route policies to block unwanted learned routes from peers and prevent specific subnets from being advertised out of their VPC.

By default, Cloud Router operates on a fail-open model. Security-conscious organizations flip this by appending a 'drop all' policy as the final term in their evaluation list. This creates a fail-closed environment where only explicitly permitted routes pass through.

The benefit is certainty. You know exactly which routes your network accepts. No routing loops from rogue advertisements. No accidental blackholes. No BGP hijacks slipping through because a filter rule was incomplete.

Pattern 2: MED and AS-PATH prepending for active/standby

The second pattern targets traffic steering without touching on-premises hardware. Customers running active/standby interconnects use BGP route policies to influence which path traffic takes.

Two mechanisms do the work. First, modifying the BGP multi-exit discriminator (MED) attribute makes a specific peer preferred for incoming traffic. Lower MED wins, so bumping the MED on your backup link deprioritizes it. Second, AS-PATH prepending artificially lengthens a route's AS-PATH, making it less attractive across the broader network. Add three AS hops to your backup link's advertisements and traffic avoids it unless the primary fails.

Neither technique requires reconfiguring on-premises routers. The policy lives in Cloud Router. This matters when you cannot easily push changes to legacy network gear or when different teams own the on-prem and cloud environments.

Pattern 3: Solving asymmetric routing with BGP communities

This is the advanced case. Enterprises running stateful firewalls or specific network appliances on-premises need return traffic to flow through the exact same device it originated from. If it doesn't, the firewall drops the packet because it has no state for that connection.

The solution uses BGP community tags. On-premises routers tag routes with specific standard BGP communities. Cloud Router reads those tags via inbound policies and adjusts route preference by manipulating the MED. The result is that Google Cloud understands the stateful topology of the on-premises network and routes return traffic symmetrically.

Before BGP route policies, achieving this required third-party virtual appliances or complex workarounds. Now it's configuration.

How to test before production

Google's recommendation is straightforward: test your BGP route policies in a staging environment. Verify your CEL expressions and routing logic before rolling them out. A misconfigured route policy can blackhole traffic or create loops, and BGP changes propagate fast.

The documentation includes a deep-dive guide on CEL expressions for route filtering, configuration steps for MED and AS-PATH prepending, and an architecture guide for traffic symmetry using BGP community tags.

Frequently asked questions

Frequently Asked Questions

What is a BGP route policy in Google Cloud?

A BGP route policy is a set of ordered rules that filter BGP routes and modify route attributes directly within Cloud Router. Policies use the Common Expression Language (CEL) to define conditions and actions.

How do policy named sets simplify BGP configuration?

Policy named sets let you group lists of IPv4/IPv6 prefixes or BGP communities into a single reusable entity. You define the set once and reference it across multiple Cloud Routers, reducing duplication and simplifying updates.

Can BGP route policies prevent BGP hijacking?

Yes. By implementing a fail-closed model with a drop-all policy as the final evaluation term, you ensure only explicitly permitted routes are accepted, blocking hijacked or rogue route advertisements.

How do I force traffic through a specific interconnect link?

Use BGP route policies to modify the MED attribute or apply AS-PATH prepending. Lower MED values make a path preferred; longer AS-PATHs make a path less attractive.

What is asymmetric routing and why does it matter?

Asymmetric routing occurs when traffic takes a different path on the return trip than it did outbound. Stateful firewalls drop asymmetric traffic because they have no session state for it. BGP community tags and MED manipulation can force symmetric paths.

Source: Cloud Blog