Route Advertisement & Import — Điều Khiển Routes Đi Đâu Về Đâu

Tại Sao Quan Trọng Trong Production

Route advertisement là nơi nhiều sự cố hybrid connectivity im lặng nhất xảy ra. BGP session có thể ở trạng thái ESTABLISHED — session hoạt động bình thường — nhưng routes vẫn không đến được đúng chỗ vì advertisement mode sai, custom routes không được cấu hình, hoặc routes từ on-prem bị coi là "inferior" trong best-path selection và không được install.

Điều quan trọng hơn: Cloud Router không chỉ là "passive receiver" routes từ on-prem. Nó cũng là "active advertiser" — nó quảng bá VPC subnets và custom prefixes ra on-prem. Nếu advertisement mode không đúng, on-prem sẽ không biết cách reach các subnets trong VPC, và kết nối sẽ fail một chiều (VPC → on-prem OK, nhưng on-prem → VPC fail).

---

Internal Model — Luồng Routes Trong Cloud Router

Hai Chiều Của Route Exchange

GCP VPC                         On-Premises Network
─────────────────               ─────────────────────
                                
VPC Subnets ──advertise──►  BGP Session ──receive──► On-prem routing table
                                
On-prem prefixes ◄──receive── BGP Session ◄──advertise── On-prem router
         │
         ▼
Dynamic Route Control Plane
         │
         ▼
VPC Network Control Plane
         │
         ▼
Andromeda (data forwarding)

Chiều outbound (GCP → on-prem): Cloud Router quảng bá VPC subnets và custom prefixes đến on-prem router qua BGP UPDATE messages. On-prem router nhận các routes này và install vào routing table của mình, từ đó biết cách forward traffic về VPC.

Chiều inbound (on-prem → GCP): On-prem router quảng bá các prefixes on-prem đến Cloud Router qua BGP UPDATE messages. Cloud Router nhận, chọn best-path, và install vào VPC dynamic route table thông qua dynamic route control plane.

---

Advertisement Mode — Điều Khiển Chiều Outbound

Hai Tầng Configuration

Cloud Router hỗ trợ advertisement mode ở hai tầng:

1. Router-level mode: Áp dụng cho tất cả BGP sessions trên Cloud Router đó, trừ khi bị override ở session level
2. BGP session-level mode: Override router-level mode cho một session cụ thể

Ưu tiên: Session-level mode LUÔN override router-level mode. Nếu router là default mode nhưng session là custom mode, session sẽ dùng custom mode.

Default Advertisement Mode

Trong default mode, Cloud Router tự động quảng bá:

1. IPv4 subnets trong cùng VPC network: Tất cả primary IPv4 subnet ranges trong cùng VPC network mà Cloud Router thuộc về đều được tự động advertise. Khi bạn tạo subnet mới trong VPC, Cloud Router tự động thêm nó vào advertisements — không cần cấu hình thêm.

Điều này cũng áp dụng theo chiều ngược lại: khi xóa subnet, Cloud Router tự động rút lại advertisement của subnet đó.

2. IPv4 subnets import từ NCC (Network Connectivity Center): Nếu VPC là một NCC spoke và cho phép import subnet routes, các routes nhập từ NCC cũng có thể được advertise, tùy thuộc vào hybrid spoke filter configuration.

3. Internal IPv6 subnets: Khi subnet được cấu hình dual-stack hoặc IPv6-only, Cloud Router tự động advertise internal IPv6 prefix tương ứng.

Hạn chế của default mode:

• Bạn không kiểm soát được subnet nào được advertise
• Không thể advertise prefixes không thuộc VPC (ví dụ: aggregate routes, default route 0.0.0.0/0)
• Mọi subnet đều được advertise — kể cả những subnet "internal only" mà bạn không muốn on-prem thấy

Custom Advertisement Mode

Custom mode cho phép bạn kiểm soát hoàn toàn những gì được advertise. Bạn chỉ định danh sách prefix cụ thể.

Các loại prefix có thể advertise trong custom mode:

1. Subnet ranges từ VPC — có thể chọn subset, không phải toàn bộ
2. Custom IP ranges bất kỳ — bao gồm:
   • Aggregate routes (supernet của nhiều subnets)
   • Default route 0.0.0.0/0 (để force all on-prem traffic qua VPC)
   • Prefixes không thuộc VPC nhưng cần được advertise vì lý do architectural

Hành vi kết hợp router-level và session-level:

Router Mode	Session Mode	Kết Quả
Default	Default (inherit)	Advertise tất cả subnets từ router
Custom	Default (inherit)	Advertise custom prefixes từ router
Default	Custom	Advertise custom prefixes từ session (bỏ qua router)
Custom	Custom	Advertise custom prefixes từ session (bỏ qua router)

Ví dụ use case custom mode:

# Advertise aggregate route thay vì từng subnet
gcloud compute routers update-bgp-peer ROUTER_NAME \
    --peer-name=PEER_NAME \
    --advertisement-mode=CUSTOM \
    --set-advertisement-ranges=10.0.0.0/8

Thay vì advertise 10.1.0.0/24, 10.2.0.0/24, 10.3.0.0/24 riêng lẻ, bạn advertise 10.0.0.0/8. On-prem thấy ít routes hơn, đơn giản hóa routing table của họ. Tuy nhiên, bạn phải đảm bảo không có gì ngoài VPC sử dụng 10.0.0.0/8.

---

Route Import — Nhận Routes Từ On-Prem

BGP-Received Routes

Khi BGP session ESTABLISHED, on-prem router gửi UPDATE messages chứa các prefixes on-prem. Cloud Router nhận các updates này và:

1. Validate: AS_PATH không loop, prefix không bị filter bởi route policies
2. Lưu vào BGP Routing Information Base (RIB) — tập hợp tất cả routes nhận được
3. Chạy best-path selection để chọn route tốt nhất cho mỗi prefix
4. Gửi best-path routes lên dynamic route control plane
5. Dynamic route control plane tạo VPC dynamic routes với next-hop là VPN tunnel/VLAN attachment

Kết quả: Các routes on-prem xuất hiện trong VPC route table dưới dạng dynamic routes với next-hop tương ứng.

Tại Sao Routes Từ On-Prem Không Được Re-Advertise

Một điểm cực kỳ quan trọng: Cloud Router mặc định không re-advertise routes đã học từ peers.

Ví dụ: Cloud Router học route 192.168.100.0/24 từ on-prem router A. Cloud Router sẽ KHÔNG advertise 192.168.100.0/24 cho on-prem router B — ngay cả khi cả A và B đều là peers của cùng Cloud Router.

Lý do thiết kế: Đây là protection chống routing loops và để tránh tình huống GCP VPC trở thành transit AS không mong muốn. Nếu Cloud Router re-advertise routes, traffic từ A có thể đi qua GCP VPC để đến B — điều này không phải lúc nào cũng mong muốn và có thể gây ra unexpected traffic patterns và billing.

Ngoại lệ: Network Connectivity Center (NCC) với hybrid spoke có data transfer enabled. Trong trường hợp này, routes CÓ được re-advertise giữa các spoke — đây là tính năng có chủ đích để kết nối site-to-site qua GCP backbone.

Custom Learned Routes

Custom learned routes là routes được cấu hình thủ công trên Cloud Router để "simulate" routes học được từ BGP peer, khi bạn không có quyền configure BGP trên thiết bị phía bên kia.

Ví dụ use case: Bạn có một Cloud Interconnect VLAN attachment nhưng thiết bị on-prem phía bên kia không support BGP (ví dụ: thiết bị cũ chỉ dùng static routing). Thay vì không thể dùng dynamic routing, bạn cấu hình custom learned routes trên Cloud Router để "tiêm" các routes on-prem vào VPC.

Cơ chế hoạt động:

Custom learned routes đi qua pipeline tương tự BGP-received routes:

1. Dynamic route control plane xử lý route
2. VPC network control plane tạo dynamic route
3. Andromeda forward traffic theo route này

Nếu BGP session của next-hop VPN tunnel/attachment bị down, custom learned routes tự động bị withdraw — không giống static routes (vẫn tồn tại dù next-hop down).

BGP attributes của custom learned routes:

• AS_PATH: chỉ chứa peer ASN (độ dài 1)
• ORIGIN: INCOMPLETE
• MED value: lấy từ "priority" của custom learned route, được map thành MED
• Inter-region cost: 0

# Tạo custom learned route
gcloud compute routers update-bgp-peer ROUTER_NAME \
    --peer-name=PEER_NAME \
    --add-custom-learned-route-ranges=192.168.200.0/24

---

MED và Best-Path Selection

Multi-Exit Discriminator (MED)

MED là một optional BGP attribute (path attribute code 4) dùng để gợi ý cho peer ASN về đường nào "tốt hơn" khi có nhiều exit points. MED có giá trị nhỏ hơn thì tốt hơn (lower is preferred).

Trong Cloud Router, MED ảnh hưởng đến:

• Khi có nhiều tunnels/attachments dẫn đến cùng destination, MED được dùng để chọn active path
• Priority của custom learned routes được map thành MED value

Quan trọng về MED propagation: MED không được propagate sang AS khác theo RFC tiêu chuẩn (là non-transitive attribute). Khi Cloud Router re-advertise một route (hiếm xảy ra, chỉ qua NCC), MED bị reset.

Hạn chế với Partner Interconnect Layer 3: Theo tài liệu GCP, MED không thể được gửi/nhận qua Layer 3 Partner Interconnect connections. Điều này giới hạn khả năng traffic engineering với Partner Interconnect L3. Để control traffic routing với Partner Interconnect L3, phải dùng AS path prepending.

Best-Path Selection — Legacy Mode và Standard Mode

Cloud Router hỗ trợ hai chế độ best-path selection:

Legacy Mode (mặc định):

Trong legacy mode, AS path comparison không được thực hiện đồng nhất qua tất cả BGP tasks. Mỗi BGP task chọn best-path độc lập dựa trên routes nó thấy. Điều này có thể dẫn đến behavior không nhất quán khi bạn cố dùng AS path prepending để steer traffic.

Theo tài liệu GCP: "don't rely on selecting the best path based on AS-path length information when different Cloud Router software tasks are involved."

Standard Mode:

Standard mode cung cấp consistent AS path-based routing bằng cách xem xét AS path information từ tất cả Cloud Router instances. Điều này cho phép:

• AS path prepending hoạt động đúng như kỳ vọng
• MED comparison nhất quán (always vs conditionally)

Standard mode phù hợp với workflows cần fine-grained traffic engineering.

Cách chọn:

gcloud compute networks update NETWORK_NAME \
    --bgp-best-path-selection-mode=STANDARD

Khuyến nghị thực tế: Với critical workloads và legacy mode đang hoạt động ổn định, không nên migrate sang standard mode mà không test kỹ. Theo tài liệu: "using legacy best path selection mode for critical workloads" là best practice. Standard mode hữu ích khi bạn cần AS path-based traffic engineering hoạt động đúng.

---

Ảnh Hưởng Của Routing Mode Lên Route Import

Khi Cloud Router học được một route từ on-prem, dynamic route control plane quyết định phạm vi áp dụng của route đó dựa trên routing mode của VPC network:

Regional mode (mặc định):

• Route từ Cloud Router trong us-central1 chỉ tạo dynamic route trong us-central1
• Resources trong us-east1 KHÔNG thấy route này
• Traffic từ us-east1 VMs đến on-prem phải đi qua một Cloud Router trong us-east1 (nếu có) hoặc không reachable

Global mode:

• Route từ Cloud Router trong us-central1 được propagate đến tất cả regions trong VPC
• Resources trong us-east1 CÓ thể thấy route này và dùng nó để reach on-prem
• Next-hop của dynamic route ở us-east1 sẽ là tunnel/attachment ở us-central1 — traffic sẽ phải đi cross-region trong GCP

Hệ quả của global mode: GCP thêm một inter-region cost khi route từ Cloud Router region A được dùng bởi resources trong region B. Cost này ảnh hưởng đến best-path selection — Cloud Router trong region cùng hoặc gần hơn sẽ được ưu tiên hơn.

---

Constraints và Failure Modes Thực Tế

Prefix Limit

Tổng số unique prefixes (BGP-received + custom learned routes) bị giới hạn theo quota. Khi đạt limit:

• Các routes mới sẽ không được nhận/install
• BGP session có thể vẫn ở ESTABLISHED nhưng routes bị truncate ngầm

Phát hiện: Kiểm tra Cloud Router metrics về route count. So sánh số routes on-prem đang advertise vs số routes VPC nhận được.

Flapping Routes

Routes liên tục appear và disappear trong VPC route table. Nguyên nhân:

• BGP session không ổn định (xem phần session internals)
• On-prem router không ổn định
• Route policies hoặc filters tạo ra behavior không nhất quán

Hệ quả: Traffic disruption liên tục, khó debug vì tại thời điểm bạn kiểm tra thì route lại có mặt.

Asymmetric Routing

Chiều đi (VPC → on-prem) và chiều về (on-prem → VPC) đi theo đường khác nhau. Điều này không phải lúc nào cũng là vấn đề nhưng có thể gây issues với:

• Stateful firewalls (họ chỉ thấy một chiều của connection)
• Troubleshooting (rất khó trace vì hai chiều đi qua điểm khác nhau)

Nguyên nhân: MED/AS_PATH configuration không nhất quán ở hai bên, routing mode regional tạo ra asymmetry khi một bên có Cloud Router nhưng bên kia không có.

---

References

• Cloud Router Advertised Routes
• Cloud Router Learned Routes
• Custom Learned Routes
• Advertise specific VPC subnets
• Set Routing and Best Path Selection Modes
• Specify and Manage Custom Learned Routes