Network Connectivity Center — Hub-and-Spoke Network Topology

Tại Sao Quan Trọng Trong Production

GKE clusters ở multiple regions cần kết nối với nhau, kết nối đến on-premises, kết nối đến other clouds. Trước NCC, bạn phải manually configure:

• VPC Peering giữa từng cặp VPCs (O(n²) complexity)
• Cloud VPN tunnels từ on-premises đến từng region
• Custom routing: advertise routes từ on-prem đến tất cả regions

Kết quả: mạng lưới rất phức tạp, khó scale, dễ tạo ra routing loops, đặc biệt khi on-premises sử dụng multiple connections (primary + backup).

Network Connectivity Center (NCC) là orchestration framework — tạo hub tập trung, sau đó connect spokes (VPCs, VPNs, Interconnects) vào hub. NCC handle routing, re-advertisement, failover.

Hub-and-Spoke Model

Hub Concept

Hub là central routing point — không phải router vật lý (NCC không host router), mà là logical orchestration entity:

GCP Network Connectivity Hub (logical routing orchestrator)
├── Spoke 1: VPC us-east (connect N subnets)
├── Spoke 2: VPC eu-west (connect N subnets)
├── Spoke 3: VPN tunnel to on-prem datacenter
├── Spoke 4: Interconnect VLAN attachment (backup)
└── Spoke 5: Router Appliance VM (custom routing logic)

Hub không hold state, không store traffic — chỉ coordinate route advertisement giữa spokes.

Hub Configuration

# Create hub
gcloud network-connectivity hubs create fleet-hub \
    --project=FLEET_PROJECT \
    --region=global

Hub được created ở global scope — không regional.

Spoke Attachment

Spokes = resources được connect vào hub. Spoke types:

1. VPC Spokes — attach VPC network:

gcloud network-connectivity spokes vpc create us-east-vpc-spoke \
    --vpc-network=us-east-vpc \
    --hub=fleet-hub \
    --location=global

Hub advertise subnets từ us-east-vpc đến other spokes.

2. Hybrid Spokes — attach external connectivity:

gcloud network-connectivity spokes hybrid create on-prem-spoke \
    --hub=fleet-hub \
    --location=us-central1
    # Attach VPN tunnel or Router Appliance

3. Router Appliance Spoke — custom routing VM:

gcloud network-connectivity spokes router-appliance create \
    --hub=fleet-hub \
    --instance=router-appliance-vm  # Custom VM with Quagga/BIRD
    --interface=eth0
    --location=us-central1

Router Appliance dùng dynamic routing (BGP) để advertise routes, NCC coordin­ate.

Data Transfer Between Spokes — Dynamic Route Re-advertisement

Khi site-to-site data transfer enabled, NCC re-advertise routes học được từ một spoke đến other spokes:

On-Premises (10.0.0.0/16)
    ↓ BGP
Router Appliance (hybrid spoke) learn route 10.0.0.0/16
    ↓ NCC advertise
Spoke 1 (us-east-vpc) receive advertisement: 10.0.0.0/16 available via router appliance
Spoke 2 (eu-west-vpc) receive advertisement: 10.0.0.0/16 available via router appliance
    ↓
Pod trong us-east-vpc call on-prem IP 10.0.0.50
    → Destination 10.0.0.0/16 routed via router appliance
    → Traffic flow to on-prem

Pod trong eu-west-vpc call on-prem IP 10.0.0.50
    → Destination 10.0.0.0/16 routed via router appliance (via NCC)
    → Traffic flow to on-prem

Khi many spokes connected, NCC coordinate full-mesh route re-advertisement:

Spoke A learn route from external source
    ↓
NCC advertise đến Spoke B, C, D, ...
    ↓
Spoke B, C, D now can reach route từ Spoke A
    ↓
Full mesh connectivity enabled

NCC Với GKE — Multi-Region Topology

Typical fleet deployment:

us-east-vpc (prod-us-east cluster)
├── Subnets: 10.1.0.0/16
├── Pod CIDR: 10.128.0.0/14
└── Spoke: attach vào hub

eu-west-vpc (prod-eu-west cluster)
├── Subnets: 10.2.0.0/16
├── Pod CIDR: 10.132.0.0/14
└── Spoke: attach vào hub

On-Premises Datacenter
├── Subnets: 10.0.0.0/16
├── BGP advertise: 10.0.0.0/16
└── Hybrid Spoke (via VPN tunnel)

Traffic flow pod-to-pod xuyên GCP regions:

Pod us-east (10.128.x.x) → Call Pod eu-west (10.132.x.x)
    → Pod ở us-east-vpc, destination 10.132.0.0/14
    → Routing table: 10.132.0.0/14 routed via VPC peering/NCC
    → Traffic cross-region Google backbone
    → Pod eu-west received request

Traffic pod-to-on-prem:

Pod us-east (10.128.x.x) → Call On-Prem Service (10.0.50.10)
    → Destination 10.0.0.0/16 (learned from router appliance via NCC)
    → Traffic routed to router appliance VM
    → Router appliance forward via VPN tunnel
    → On-premises receive request

Constraints Cho GKE

Constraint 1: Pod CIDR không overlap

• NCC re-advertise all routes — nếu two clusters use 10.128.0.0/14 pod CIDR, routes conflict
• Must assign unique pod CIDR per cluster:
  • us-east: 10.128.0.0/14
  • eu-west: 10.132.0.0/14
  • asia-east: 10.136.0.0/14

Constraint 2: Subnet CIDR không overlap

• Cùng vpc scope: tự động enforce (GCP prevent)
• Across vpcs: NCC có thể handle overlap nhưng routing sẽ ambiguous
• Best practice: carefully plan CIDR allocation across all regions

Constraint 3: Hybrid spokes require consistent ASN

• Nếu multiple router appliance VMs, chúng phải use cùng ASN
• All non-Google spokes trong NCC must use matching ASN để BGP peers recognize hệ nhau
• Google spokes (VPC) không need ASN

BGP Communities và Route Filtering

NCC support BGP communities — tagging routes để selective filtering:

# Route advertisement với community
# On-Prem router advertise: 10.0.0.0/16 community 65001:100 (production)
# On-Prem router advertise: 10.0.100.0/24 community 65001:200 (development)

Router appliance spoke có thể filter:

Import policy: accept routes with community 65001:100 only
    → Only production routes advertised to other spokes
    → Dev routes không propagate

Điều này cho phép selective route distribution — có những subnets nhất định không cần broadcast đến tất cả locations.

Failover Và High Availability

Active-Backup Hybrid Spokes

Hub
├── Hybrid Spoke "primary" (VPN tunnel to primary on-prem router)
└── Hybrid Spoke "backup" (VPN tunnel to backup on-prem router)

Cả hai VPN tunnels up. On-prem routers advertise subnets via BGP:

• Primary router advertise 10.0.0.0/16 AS Path length 1
• Backup router advertise 10.0.0.0/16 AS Path length 2 (prepend AS)

NCC prefer shorter AS Path — traffic prefer primary tunnel. Nếu primary down:

• BGP session primary → router appliance drop
• Backup spoke learn 10.0.0.0/16 từ backup router (shorter AS path)
• NCC re-advertise đến other spokes via backup spoke
• Traffic failover automatic

Failover latency: thường < 30 seconds (BGP hold timer + convergence).

Multi-Path Routing

Nếu có multiple paths available (primary + backup both up), NCC enable equal-cost multi-path (ECMP) — traffic distribute xuyên both paths:

Traffic to on-prem 10.0.0.0/16:
├── 50% via primary tunnel (primary spoke)
└── 50% via backup tunnel (backup spoke)

Load balancing per-flow — flows don't move, session affinity maintained.

Constraints Và Limitations

IPv4 only cho hybrid spokes: NCC support IPv6 cho VPC spokes, nhưng hybrid spokes (VPN, Interconnect) chỉ IPv4. Nếu cần IPv6 to on-prem, phải setup dual-stack và manage separately.

No built-in traffic shaping: NCC không rate-limit traffic giữa spokes. Nếu hybrid spoke saturated, traffic sẽ congest — cần QoS tại spoke level hoặc on-prem router.

Hub-and-spoke limitation: NCC không support full mesh topology. Nếu need all-to-all connectivity (mỗi spoke directly connect tất cả other spokes), phải use VPC peering + manual routing management.

Route propagation latency: Route advertise từ one spoke đến others mất vài giây. Nếu pod cập nhật route (ví dụ thêm service), other clusters cần tờ giây để learn và route traffic.

BGP graceful shutdown: Khi disconnect spoke, BGP graceful shutdown không guaranteed — routes có thể linger tại other spokes. May take tới 180 giây (BGP hold timer default) để fully remove.

Best Practice: NCC + Fleet Pattern

Recommended architecture:

Fleet Host Project:
├── NCC Hub
├── VPC Spokes:
│   ├── Shared VPC (platform infrastructure, databases)
│   ├── Prod VPC us-east (prod cluster)
│   ├── Prod VPC eu-west (prod cluster)
│   ├── Staging VPC (staging cluster)
│   └── Dev VPC (dev cluster)
└── Hybrid Spoke:
    └── VPN to on-premises (primary + backup tunnels)

Traffic patterns:

• Pod-to-pod: xuyên GKE clusters via NCC VPC spokes + VPC peering
• Pod-to-database: on-prem database ở shared VPC, pods route via NCC
• Pod-to-on-prem: via hybrid spoke VPN

Naming convention: match NCC spoke names với VPC names + cluster names:

us-east-vpc-spoke → us-east-vpc → prod-us-east cluster
eu-west-vpc-spoke → eu-west-vpc → prod-eu-west cluster

Clarity helps troubleshooting.

Operational Checklist

When deploying NCC:

• [ ] Create hub
• [ ] Define CIDR allocation — ensure no overlaps across regions + on-prem
• [ ] Attach VPC spokes per region
• [ ] Configure hybrid spokes (VPN tunnels) to on-prem
• [ ] Setup BGP sessions (ASN matching)
• [ ] Enable site-to-site data transfer nếu cần
• [ ] Test connectivity: ping pod ở cluster A từ cluster B, ping on-prem service từ pod
• [ ] Monitor NCC metrics (spoke status, routes advertised)
• [ ] Setup alerting nếu spokes down hoặc routes missing

Troubleshooting checklist:

• [ ] Verify spoke status: gcloud network-connectivity spokes list
• [ ] Check routes learned: gcloud network-connectivity routes list
• [ ] Verify BGP sessions từ router appliance: show ip bgp summary
• [ ] Test reachability: gcloud network-connectivity connectivity-tests
• [ ] Check firewall rules không block traffic

References

• Network Connectivity Center Overview
• Hub and Spokes Architecture
• Dynamic Routing with NCC
• Troubleshooting NCC
• GKE Multi-Region Networking