Advanced Network Services: NCC, CDN, IPv6 & BYOIP

Once you have mastered the core VPC, the VPN, the load balancers, and the firewalls, there is a layer of advanced services that the PCNE exam tests at the edges. These are the services that most engineers never touch in their day-to-day work, but they appear in exam scenarios designed to separate the “Professional” from the “Associate.” Each of these services solves a specific, often niche problem—and knowing when to reach for them is the key.

Network Connectivity Center (NCC)

Historically, if you wanted to connect your New York office to your London office using Google’s backbone as a transit network, you had to chain together VPNs and custom routes in creative ways. NCC changes Google Cloud into a global SD-WAN hub.

The Hub & Spoke Model
  1. Hub: A global resource container that acts as the central routing point.
  2. Spokes: VPN tunnels, Interconnect VLANs, or Router Appliances (SD-WAN VMs like Cisco or Fortinet).
Site-to-Site Data Transfer

By default, spokes cannot talk to each other through the hub. But if you enable Site-to-Site Data Transfer (which incurs additional cost), Google acts as your global transit provider. Your NY office connects to Google’s NY PoP, traffic rides the backbone to London, and exits to your London office—all without ever touching the public internet.

Router Appliance

This feature allows you to run a third-party Network Virtual Appliance (NVA) and peer BGP directly with Google’s Cloud Router. This is the integration point for enterprises using Cisco SD-WAN, Fortinet, or Palo Alto in their branch offices.

Cloud CDN: Content at the Edge

Latency kills user experience. If your user is in Sydney and your backend is in Iowa, the speed of light adds roughly 150ms of round-trip time. Cloud CDN caches content at Google’s Points of Presence (PoPs), shortcutting the round-trip entirely.

Cache Modes
  1. USE_ORIGIN_HEADERS: Respects Cache-Control: max-age=3600 from your backend. The CDN caches exactly as the backend instructs.
  2. FORCE_CACHE_ALL: Ignores the backend’s cache headers and caches everything. Dangerous for dynamic content, powerful for static assets.
  3. CACHE_ALL_STATIC: Caches only content types that are typically static (images, CSS, JS).
Cache Keys & Signed URLs

By default, example.com/image.jpg?user=123 is a different cache entry than ?user=456. You can strip query parameters to increase cache hit ratios. For paid or restricted content, Signed URLs add a cryptographic signature that the CDN validates at the edge—blocking unauthorized access without any backend computation.

IPv6: The Dual-Stack Future

The world has run out of IPv4 addresses. Google Cloud supports Dual Stack networking, where subnets can carry both IPv4 and IPv6 traffic simultaneously.

Key Points
  1. Internal IPv6: Assign ULA (Unique Local Address) ranges (fd20::/20) to subnets for private internal communication.
  2. External IPv6: Assign globally routable IPv6 addresses to VMs and load balancers.
  3. Subnet Configuration: You must set the subnet stack type to IPV4_IPV6 at creation time.
  4. The exam trap: You generally cannot have an “IPv6-only” VM in Google Cloud. It is almost always Dual Stack (IPv4 + IPv6).
BYOIP: Bring Your Own IP

Enterprises often depend on specific public IP addresses for whitelisting with partners, DNS reputation, or regulatory compliance. When migrating to the cloud, changing their IP addresses is not an option.

BYOIP allows you to bring your own publicly routable IPv4 blocks to Google Cloud:

  1. ROA (Route Origin Authorization): You cryptographically sign a message with your Regional Internet Registry (ARIN, RIPE) proving you own the CIDR.
  2. Validation: Google verifies the signature.
  3. Announcement: Google advertises your prefix from their edge to the internet.
  4. Usage: You can assign these IPs to Forwarding Rules, NAT Gateways, or VM instances—just like native Google IPs.
Putting it Together: A Pro-Engineer View

Imagine you are the network architect for a media company expanding globally. You deploy NCC as a hub, connecting your studio in Los Angeles, your editing facility in London, and your distribution center in Tokyo—all as spokes using existing VPN tunnels, with site-to-site transfer enabled. Your video platform uses Cloud CDN with FORCE_CACHE_ALL for movie trailers, dramatically reducing origin load. Your new mobile app supports IPv6 natively, so you enable Dual Stack on all frontend subnets. And because your CDN domain has years of DNS reputation built on a specific IP block, you use BYOIP to bring those addresses into Google Cloud. Four advanced services. Four different problems. One cohesive architecture.

Related Posts