Static Routes và Next Hops — Kiểm Soát Đường Đi Của Traffic

Internal Model: Route Table Phân Tán Của GCP

Không có router vật lý nào trong GCP VPC. Route table là một logical construct được lưu trong GCP control plane và propagate xuống mỗi Andromeda agent trên mỗi host. Mỗi Andromeda agent lưu một bản sao local và thực hiện route lookup tại chỗ khi xử lý packet.

Điểm khác biệt với router truyền thống: không có thiết bị trung tâm, không có SPOF về routing, và không có lookup round-trip về control plane cho mỗi packet.

Anatomy Của Một Route

Mỗi route trong GCP VPC có các thành phần:

yaml

Destination: 10.100.0.0/24        # Prefix đích
Next-hop type: instance            # Loại next hop
Next-hop value: my-gateway-vm     # Giá trị cụ thể
Priority: 1000                     # Độ ưu tiên (lower = higher priority)
Applicable to: tag:internal-only  # VMs nào dùng route này (optional)

Destination là IP prefix. Khi Andromeda xử lý packet, nó tìm route có destination prefix match tốt nhất (longest prefix match).

Next hop xác định packet sẽ được gửi đến đâu. GCP hỗ trợ nhiều loại next hop — mỗi loại có behavior khác nhau.

Các Loại Route Trong GCP

Theo tài liệu GCP, route được chia thành các loại sau (theo thứ tự ưu tiên evaluation):

1. Special Routing Paths (Non-removable)

Không xuất hiện trong route table nhưng luôn được evaluate trước tất cả:

35.235.240.0/20 → Identity-Aware Proxy (IAP)
35.199.192.0/19 → Cloud DNS và Service Directory
35.199.224.0/19 → Serverless VPC Access
External passthrough Network Load Balancers
Health check systems (35.191.0.0/16, 130.211.0.0/22)

Bạn không thể xóa hay override các routes này. Chúng là hardcoded behavior của GCP networking.

2. Policy-Based Routes (PBR)

Route theo policy — evaluated TRƯỚC subnet routes và custom routes. Cho phép routing dựa trên:

Source IP
Destination IP
Protocol
Combinations

Dùng cho các use case phức tạp như forcing all HTTP traffic qua NGFW, hoặc routing traffic từ specific source CIDRs qua inspection gateway.

3. Subnet Routes (Tự Động)

GCP tự động tạo khi bạn tạo subnet:

10.0.0.0/20 → local (primary range)
10.1.0.0/16 → local (secondary range)

Không thể xóa subnet routes (chúng tồn tại chừng nào subnet còn tồn tại). Có thể override bằng policy-based route với cùng destination.

4. Custom Static Routes

Routes bạn tạo thủ công với next-hop cụ thể. Đây là loại route phổ biến nhất khi cần kiểm soát traffic.

5. Dynamic Routes (Cloud Router + BGP)

Routes học được từ BGP peers (on-premises, Cloud VPN, Cloud Interconnect). Được thêm và xóa tự động khi BGP session thay đổi.

Next Hop Types và Hành Vi Chi Tiết

Next Hop: Instance (VM)

bash

gcloud compute routes create route-to-nva \
  --network=prod-vpc \
  --destination-range=10.100.0.0/24 \
  --next-hop-instance=network-appliance-vm \
  --next-hop-instance-zone=us-west1-a \
  --priority=1000

Behavior: Packet được gửi đến primary IP của VM đó. VM cần --can-ip-forward=true để nhận packet có destination IP không phải của nó và forward tiếp.

Điều cần biết: GCP tự động vô hiệu hóa route khi VM next-hop bị stop hoặc delete:

"Google Cloud disregards each static route whose next hop VM instance has been stopped or deleted."

Điều này có nghĩa là khi VM gateway bị dừng, traffic đến destination đó sẽ không được route — có thể hit route có priority thấp hơn, hoặc bị drop. Đây là failure mode quan trọng cần monitor.

Production consideration: Không dùng single VM làm next-hop cho critical traffic. Thay vào đó, dùng Internal Load Balancer (xem bên dưới) với nhiều VMs phía sau.

Next Hop: Internal Load Balancer (ILB)

bash

gcloud compute routes create route-via-ilb \
  --network=prod-vpc \
  --destination-range=10.100.0.0/24 \
  --next-hop-ilb=my-gateway-ilb \
  --next-hop-ilb-region=us-west1 \
  --priority=1000

Behavior: Traffic được forward đến ILB, ILB phân phối đến backend VMs. Đây là pattern đúng cho Network Virtual Appliances (NVA) trong production.

Ưu điểm so với instance next-hop:

High availability: nếu một backend VM fail, ILB route traffic đến VM khác
Health checking: ILB tự động loại bỏ unhealthy backends
Route không bị vô hiệu hóa khi VM cụ thể dừng

Constraint quan trọng: ILB next-hop chỉ hoạt động trong cùng region. Nếu route cần forward traffic đến NVA ở region khác, phải dùng VPN/Interconnect.

Next Hop: Default Internet Gateway

bash

# Tự động được tạo bởi GCP
Route: 0.0.0.0/0 → default-internet-gateway

Behavior: Traffic được forward ra internet thông qua Google's edge network. VM phải có external IP để traffic return được.

Đây là system-generated route — GCP tạo nó tự động khi VPC được tạo. Bạn có thể xóa route này nếu muốn prevent internet access hoàn toàn (private VPC).

Next Hop: Cloud VPN Tunnel (Classic VPN)

bash

gcloud compute routes create route-to-onprem \
  --network=prod-vpc \
  --destination-range=192.168.0.0/16 \
  --next-hop-vpn-tunnel=prod-vpn-tunnel \
  --next-hop-vpn-tunnel-region=us-west1 \
  --priority=1000

Behavior: Traffic được encrypt và sent qua VPN tunnel đến on-premises. Chỉ hỗ trợ với Classic VPN (HA VPN dùng Cloud Router với BGP, không dùng static routes).

Thứ Tự Đánh Giá Route: 11 Bước

GCP sử dụng quy trình 11 bước để chọn route cho mỗi packet. Hiểu thứ tự này là critical để debug routing issues:

1. Special routing paths (luôn checked first, non-removable)
   → IAP, Cloud DNS, Serverless VPC Access, health checks

2. Policy-based routes (theo priority, evaluated trước subnet/custom)
   → Nếu match → execute action (forward hoặc skip PBR)

3. Subnet routes (nếu destination match subnet CIDR)
   → Local subnet traffic được forward locally

4. Most specific destination (Longest Prefix Match)
   → /28 được ưu tiên hơn /24, /24 hơn /16, v.v.

5. Most favorable custom route type
   → Local static/dynamic > NCC routes > Peering routes

6. Single peer VPC network selection
   → Nếu nhiều peered VPCs có cùng route, chọn một

7. Discard unusable next hops
   → VM đã stop, invalid IPs bị loại

8. Discard low-priority routes
   → Route với priority thấp hơn (số cao hơn) bị loại

9. Single NCC routing VPC selection
   → Nếu nhiều NCC routes tương đương, chọn một

10. Most favorable preference category
    → Static instance > dynamic > static ILB > internet gateway

11. Send hoặc drop
    → Nếu nhiều routes bằng nhau: ECMP (Equal Cost Multipath)
    → Nếu không có route nào: drop packet

Longest Prefix Match: Rule Quan Trọng Nhất

Trong thực tế, bước 4 (longest prefix match) thường quyết định outcome:

Route table:
  0.0.0.0/0    → internet-gateway (priority 1000)
  10.0.0.0/8   → vpn-tunnel (priority 1000)
  10.100.0.0/16 → ilb-nva (priority 1000)
  10.100.5.0/24 → specific-vm (priority 1000)

Packet đến 10.100.5.7:
  Match 0.0.0.0/0     → /0 (least specific)
  Match 10.0.0.0/8    → /8
  Match 10.100.0.0/16 → /16
  Match 10.100.5.0/24 → /24 (MOST SPECIFIC → WINS)

→ Traffic đến 10.100.5.7 sẽ đi qua specific-vm, không phải ilb-nva

Priority: Tiebreaker Khi Cùng Prefix Length

Nếu có nhiều routes cùng destination prefix:

Route A: 10.100.0.0/24 → vm-gateway-1 (priority 100)
Route B: 10.100.0.0/24 → vm-gateway-2 (priority 200)
Route C: 10.100.0.0/24 → vm-gateway-3 (priority 200)

Packet đến 10.100.0.5:
  Route A wins (priority 100 < 200)
  Route B và C bị loại

→ Traffic đến vm-gateway-1

Nếu Route A và B cùng priority (ví dụ cả hai là 100):

Route A: 10.100.0.0/24 → vm-gateway-1 (priority 100)
Route B: 10.100.0.0/24 → vm-gateway-2 (priority 100)

→ ECMP: Traffic được phân phối across cả hai next hops
   (thực tế là per-flow ECMP — mỗi flow đi một path)

ECMP (Equal Cost Multipath) trong GCP là per-flow, không phải per-packet. Điều này quan trọng vì packet reordering trong cùng flow được tránh.

Xung Đột Route: Khi Nào GCP Từ Chối

GCP có các constraints nghiêm ngặt về xung đột giữa custom routes và subnet routes:

Không Thể Tạo Static Route Chồng Lấp Với Subnet Route

bash

# Subnet đã có: 10.0.0.0/20 → local (subnet route)

# Thử tạo static route:
gcloud compute routes create bad-route \
  --destination-range=10.0.0.0/24 \
  --next-hop-instance=my-vm
# LỖI: "Destination range 10.0.0.0/24 is contained within subnet range 10.0.0.0/20"

GCP không cho phép bạn tạo static route có destination "chứa trong" hoặc "là superset của" subnet range, trừ khi bật "hybrid subnet routing."

Lý do: Nếu cả subnet route và static route cùng match một destination, routing sẽ ambiguous. GCP enforce consistency bằng cách không cho phép tạo conflicting routes.

Hybrid Subnet Routing: Exception Case

Hybrid subnet routing cho phép override subnet routes với custom routes — dùng cho trường hợp có workloads on-premises trùng CIDR với GCP subnet:

bash

gcloud compute networks subnets update my-subnet \
  --region=us-west1 \
  --enable-private-ipv6-google-access
# (Hybrid subnet routing được bật qua đặc tính subnet)

Đây là advanced use case, thường gặp khi migrating workloads từ on-premises sang GCP trong giai đoạn transition.

Static Routes Với Network Tags: Route Per VM Group

Không phải tất cả routes phải áp dụng cho toàn bộ VPC. Bạn có thể giới hạn route chỉ áp dụng cho VMs có network tag cụ thể:

bash

gcloud compute routes create route-for-secure-vms \
  --network=prod-vpc \
  --destination-range=0.0.0.0/0 \
  --next-hop-instance=security-proxy \
  --tags=requires-inspection \
  --priority=900

Hành vi: Chỉ VMs có tag requires-inspection sẽ dùng route này cho default traffic. VMs khác vẫn dùng default internet gateway.

Use case: Force tất cả traffic từ "sensitive" VMs qua security proxy/NGFW, trong khi VMs thông thường đi thẳng ra internet.

Quan trọng: Route tags khác với firewall tags — route tags chỉ xác định VMs nào "áp dụng route này". Không có route exchange qua VPC peering cho routes có tags.

Policy-Based Routes: Advanced Traffic Steering

Policy-based routes (PBR) được evaluate trước subnet routes và cho phép routing dựa trên nhiều criteria hơn:

bash

gcloud compute networks policies create steer-http-traffic \
  --network=prod-vpc \
  --from-region=us-west1 \
  --filter-source-range=10.0.0.0/20 \
  --filter-dest-range=0.0.0.0/0 \
  --filter-protocol=tcp \
  --filter-dest-port-range=80-80 \
  --next-hop=10.0.5.1 \
  --next-hop-region=us-west1

PBR hữu ích cho:

Forcing HTTP traffic qua web proxy
Routing traffic từ specific source CIDRs qua inspection
Implementing asymmetric routing cho advanced security architectures

Limitation quan trọng: Policy-based routes không được exchange qua VPC Peering. Nếu bạn có peered VPC, PBR của VPC này không áp dụng cho traffic từ VPC đối tác.

Route Conflicts và Debugging

Khi routing behave sai (traffic không đến đúng nơi), process debug:

1. List Tất Cả Routes

bash

gcloud compute routes list --network=prod-vpc \
  --format="table(name,destRange,nextHopType,nextHopInstance,priority,tags)"

2. Kiểm Tra Specific VM Áp Dụng Routes Nào

bash

# Connectivity test
gcloud network-management connectivity-tests create test-route \
  --source-instance=projects/my-project/zones/us-west1-a/instances/vm-a \
  --destination-instance=projects/my-project/zones/us-east1-b/instances/vm-b \
  --protocol=TCP \
  --destination-port=443

# Xem kết quả
gcloud network-management connectivity-tests describe test-route

3. Route Table Từ Perspective Của VM

bash

# Xem routing tại VM qua metadata
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/routes

Khi Route Bị Vô Hiệu (Inactive)

GCP đánh dấu route là inactive khi:

Next-hop VM đã stop (route bị discard, không apply)
Next-hop IP không thuộc bất kỳ subnet nào trong VPC
Next-hop tunnel không active

Route inactive không bị xóa — nó vẫn còn trong route table nhưng không được apply. Khi VM khởi động lại hoặc tunnel trở lại active, route trở thành active tự động.

bash

# Kiểm tra inactive routes
gcloud compute routes list --network=prod-vpc \
  --filter="nextHopType=instance" \
  --format="table(name,destRange,nextHopInstance,status)"

Production Patterns Với Static Routes

Pattern: Hub-and-Spoke Với NVA

Spoke VPCs (teams)         Hub VPC (network team)
                            ┌─────────────────────┐
[Team A VPC] ─peering─→   │ NVA (NGFW cluster)  │
[Team B VPC] ─peering─→   │ behind ILB          │
[Team C VPC] ─peering─→   │                     │
                            └─────────────────────┘
                                      ↓ ILB next-hop route
                              Internet / On-premises

Hub VPC route:
  0.0.0.0/0 → ilb-ngfw (priority 100) -- force all egress qua NGFW

Static routes với ILB next-hop là foundation của pattern này. Peering custom routes phải được export từ hub cho spoke VPCs nhận được routes.

Pattern: Failover Với Priority

Primary path (priority 100):
  10.100.0.0/16 → vpn-tunnel-primary

Backup path (priority 200):
  10.100.0.0/16 → vpn-tunnel-backup

Khi primary tunnel active: traffic dùng priority 100
Khi primary tunnel fail:   GCP disable route, traffic fallover sang priority 200

Đây không phải active-active — là active-passive failover dựa trên route priority.

References

GCP Routes Overview — Tài liệu chính thức về routing
Using Routes — Tạo và quản lý routes
Policy-based Routes — Advanced traffic steering
Network Connectivity Center — Hub-and-spoke networking

Static Routes và Next Hops — Kiểm Soát Đường Đi Của Traffic ​

Internal Model: Route Table Phân Tán Của GCP ​

Anatomy Của Một Route ​

Các Loại Route Trong GCP ​

1. Special Routing Paths (Non-removable) ​

2. Policy-Based Routes (PBR) ​

3. Subnet Routes (Tự Động) ​

4. Custom Static Routes ​

5. Dynamic Routes (Cloud Router + BGP) ​

Next Hop Types và Hành Vi Chi Tiết ​

Next Hop: Instance (VM) ​

Next Hop: Internal Load Balancer (ILB) ​

Next Hop: Default Internet Gateway ​

Next Hop: Cloud VPN Tunnel (Classic VPN) ​

Thứ Tự Đánh Giá Route: 11 Bước ​

Longest Prefix Match: Rule Quan Trọng Nhất ​

Priority: Tiebreaker Khi Cùng Prefix Length ​

Xung Đột Route: Khi Nào GCP Từ Chối ​

Không Thể Tạo Static Route Chồng Lấp Với Subnet Route ​

Hybrid Subnet Routing: Exception Case ​

Static Routes Với Network Tags: Route Per VM Group ​

Policy-Based Routes: Advanced Traffic Steering ​

Route Conflicts và Debugging ​

1. List Tất Cả Routes ​

2. Kiểm Tra Specific VM Áp Dụng Routes Nào ​

3. Route Table Từ Perspective Của VM ​

Khi Route Bị Vô Hiệu (Inactive) ​

Production Patterns Với Static Routes ​

Pattern: Hub-and-Spoke Với NVA ​

Pattern: Failover Với Priority ​

References ​

Static Routes và Next Hops — Kiểm Soát Đường Đi Của Traffic

Internal Model: Route Table Phân Tán Của GCP

Anatomy Của Một Route

Các Loại Route Trong GCP

1. Special Routing Paths (Non-removable)

2. Policy-Based Routes (PBR)

3. Subnet Routes (Tự Động)

4. Custom Static Routes

5. Dynamic Routes (Cloud Router + BGP)

Next Hop Types và Hành Vi Chi Tiết

Next Hop: Instance (VM)

Next Hop: Internal Load Balancer (ILB)

Next Hop: Default Internet Gateway

Next Hop: Cloud VPN Tunnel (Classic VPN)

Thứ Tự Đánh Giá Route: 11 Bước

Longest Prefix Match: Rule Quan Trọng Nhất

Priority: Tiebreaker Khi Cùng Prefix Length

Xung Đột Route: Khi Nào GCP Từ Chối

Không Thể Tạo Static Route Chồng Lấp Với Subnet Route

Hybrid Subnet Routing: Exception Case

Static Routes Với Network Tags: Route Per VM Group

Policy-Based Routes: Advanced Traffic Steering

Route Conflicts và Debugging

1. List Tất Cả Routes

2. Kiểm Tra Specific VM Áp Dụng Routes Nào

3. Route Table Từ Perspective Của VM

Khi Route Bị Vô Hiệu (Inactive)

Production Patterns Với Static Routes

Pattern: Hub-and-Spoke Với NVA

Pattern: Failover Với Priority

References