Advanced BGP, SSL Policies & Network Benchmarking

This article addresses the advanced specifics that experienced network engineers expect to see in a comprehensive study guide. These are the topics that bridge the gap between “I know what BGP is” and “I can configure BGP route advertisements with custom filtering on Cloud Router.” If you come from a traditional networking background with Cisco or Juniper experience, this is where Google Cloud’s abstractions will feel most different from what you are used to.

Advanced BGP: Custom Route Advertisements

By default, Cloud Router advertises all subnets in its VPC to BGP peers. This is convenient but dangerous—you may not want your on-premises network to know about every subnet, especially development or testing ranges.

Custom Route Advertisements

You can switch a Cloud Router’s BGP session from “Advertise all subnets” to “Advertise custom routes”:

  1. Edit the BGP session configuration.
  2. Select “Create custom routes.”
  3. Manually list only the subnets or IP ranges you want to share with your peer.
Route Filtering on Import

When your on-premises router advertises hundreds of routes to Cloud Router, you may want to accept only specific prefixes. Cloud Router supports route filtering on import:

  1. Define a list of allowed IP prefixes.
  2. Routes that do not match the filter are dropped before being installed in the VPC route table.
  3. This prevents accidental route injection from a misconfigured on-prem router.
BGP Communities

Cloud Router has limited support for BGP communities compared to traditional routers. It primarily sets MED values to influence the peer’s routing decisions. Inbound community matching is not broadly supported except in specific NCC scenarios. If the exam asks about influencing the peer’s routing preference, the answer is MED, not communities.

SSL Policies: Hardening TLS

When you attach an SSL certificate to a Target HTTPS Proxy, Google allows a wide range of TLS cipher suites by default. This maximizes compatibility but may violate strict compliance standards like PCI-DSS or FIPS 140-2.

SSL Policies let you control exactly which TLS versions and cipher suites are allowed:

  1. Compatible: Allows TLS 1.0, 1.1, and 1.2. Broadest client support, lowest security baseline.
  2. Modern: Allows only TLS 1.3 and strong TLS 1.2 ciphers. Best security, may break very old clients (Android 4.x, IE 11).
  3. Restricted: Meets FIPS/NIST standards. Most restrictive.
  4. Custom: You hand-pick the exact cipher suites.

You attach the SSL Policy to the Target HTTPS Proxy. To enforce a minimum standard across the organization, use the Organization Policy constraint constraints/compute.sslPolicy.

Network Performance Benchmarking with iperf3

When someone says “the network is slow,” you need data, not opinions. ping measures latency. iperf3 measures throughput (bandwidth).

The Common Mistake

Running iperf3 -c 10.0.0.5 and seeing 2 Gbps on what should be a 10 Gbps link. The conclusion: “Google’s network is broken.”

The reality: a single TCP stream is limited by the guest OS’s receive window and CPU. You are measuring single-stream performance, not link capacity.

The Fix: Parallel Streams
iperf3 -c 10.0.0.5 -P 8

The -P 8 flag runs 8 parallel TCP streams simultaneously. This saturates the NIC and shows the true link capacity. With 8 streams on an n2-standard-8, you will typically see close to the machine type’s egress cap.

Context for Benchmarking
  1. VPN tunnels: Each tunnel is capped at ~3 Gbps. The encryption CPU overhead is the bottleneck, not the network.
  2. Interconnect VLAN attachments: Throughput is capped by the attachment bandwidth (e.g., 1 Gbps, 10 Gbps).
  3. Inter-region: Throughput is high but latency increases with distance. Use iperf3 to validate throughput and ping to validate latency independently.
Multi-Cloud Connectivity: GCP to AWS
Option 1: HA VPN to AWS Site-to-Site VPN
  1. Create an HA VPN gateway on GCP (two external IPs).
  2. Create a Site-to-Site VPN in AWS (two tunnel endpoints).
  3. Configure BGP between Cloud Router and AWS’s VPN gateway. AWS uses APIPA addresses (169.254.x.x) inside the tunnel. Cloud Router supports this.
  4. Result: Encrypted connectivity between GCP VPC and AWS VPC, with dynamic routing.
Option 2: Cross-Cloud Interconnect

A managed service where Google provisions a physical link inside an Equinix facility directly to an AWS Direct Connect port.

  1. Bandwidth: 10 Gbps or 100 Gbps.
  2. Use case: High-throughput, low-latency multi-cloud architectures.
Putting it Together: A Pro-Engineer View

Imagine you are the network architect for a company running workloads on both GCP and AWS. You configure HA VPN between the two clouds with BGP using APIPA addresses in the tunnel. On the GCP side, Cloud Router advertises only your production subnets using custom route advertisements—dev and staging ranges are hidden. Your Global HTTPS LB uses an SSL Policy set to “Modern” because your mobile app supports TLS 1.3. Before launch, you run iperf3 -P 16 between your GCP compute instances and AWS EC2 instances through the VPN to validate throughput. The benchmark confirms 2.8 Gbps per tunnel—acceptable for your workload. Every configuration is evidence-based, not assumed.

Related Posts