Kiến Trúc Cloud Router — Distributed BGP Control Plane
Tại Sao Quan Trọng Trong Production
Phần lớn các incident liên quan đến Cloud Router xuất phát từ một hiểu lầm cơ bản: người vận hành nghĩ rằng Cloud Router là một thiết bị mạng đứng trên đường đi của traffic. Khi BGP session bị drop, họ kỳ vọng traffic cũng bị cắt ngay. Hoặc khi cần scale throughput, họ nghĩ Cloud Router là bottleneck cần upgrade.
Cả hai giả định đều sai, và chúng dẫn đến các quyết định sai lầm trong thiết kế và debug.
Cloud Router không bao giờ chạm vào packet của bạn. Nó là control plane — chạy BGP để trao đổi thông tin routing với các peer bên ngoài, sau đó lập trình kết quả vào VPC. Data plane là Andromeda, và Andromeda đưa ra quyết định forwarding hoàn toàn độc lập với Cloud Router. Đây là sự tách biệt control/data plane triệt để, và hiểu điều này là điều kiện tiên quyết để vận hành hybrid connectivity đúng cách.
Internal Model — Cloud Router Thực Sự Là Gì
Định Nghĩa Chính Xác
Cloud Router là một distributed, fully managed BGP speaker và responder chạy trên infrastructure của Google. Theo tài liệu chính thức: "Cloud Router manages corresponding BGP sessions" nhưng không xử lý packet routing hay forwarding — Andromeda đảm nhận phần đó.
Mỗi Cloud Router mà bạn tạo ra được ánh xạ tới một tập hợp các BGP task (tiến trình phần mềm) chạy phân tán trong region. Các BGP task này:
- Duy trì BGP sessions với các peer bên ngoài (on-prem router, VPN endpoint, Router Appliance)
- Xử lý BGP protocol messages (OPEN, KEEPALIVE, UPDATE)
- Quyết định best path trong số các routes nhận được
- Gửi kết quả lên dynamic route control plane của VPC
Kiến Trúc Hai Tầng Control Plane
Cloud Router hoạt động qua hai control plane xếp tầng:
BGP Peers (on-prem, VPN, Interconnect)
│
▼
┌─────────────────────┐
│ Cloud Router │
│ (BGP tasks / │
│ BGP speaker) │
│ │
│ Dynamic Route │◄── Custom Learned Routes
│ Control Plane │
└─────────────────────┘
│
▼
┌─────────────────────┐
│ VPC Network │
│ Control Plane │
│ (route table) │
└─────────────────────┘
│
▼
┌─────────────────────┐
│ Andromeda SDN │
│ (data plane, │
│ forwarding) │
└─────────────────────┘Tầng 1 — Dynamic Route Control Plane: Nhận routes từ BGP tasks và custom learned routes. Chạy best-path selection để chọn route tốt nhất cho mỗi prefix. Kết quả là một tập dynamic routes với next-hop và metric.
Tầng 2 — VPC Network Control Plane: Nhận dynamic routes từ tầng 1, tổng hợp với subnet routes và static routes, và tạo ra bảng route cuối cùng. Bảng này được phân phối đến tất cả các Andromeda instances trong VPC.
Andromeda (Data Plane): Đọc bảng route từ VPC control plane và thực hiện forwarding. Andromeda không biết BGP, không biết Cloud Router — nó chỉ biết "với destination prefix X, next-hop là Y với priority Z".
Tại Sao BGP Drop Không Cắt Traffic Ngay
Đây là hệ quả trực tiếp của kiến trúc tách control/data plane:
- BGP session với on-prem router bị drop
- Cloud Router detect session failure (qua BFD hoặc hold timer)
- Cloud Router withdraw routes đã học từ session đó
- Dynamic route control plane cập nhật, loại bỏ routes từ peer đó
- VPC network control plane cập nhật bảng route
- Andromeda propagate bảng route mới đến tất cả instances
Toàn bộ quá trình này mất thời gian. Trong khoảng thời gian từ khi BGP session drop đến khi Andromeda cập nhật xong, traffic vẫn đi theo routes cũ (và có thể bị drop ở peer nếu phía peer cũng đã withdraw). Đây là lý do BFD quan trọng: rút ngắn thời gian detect failure từ 60-180 giây (BGP hold timer) xuống còn 5 giây (BFD default), từ đó rút ngắn thời gian convergence tổng thể.
Distributed Redundancy Nội Tại
Cloud Router không phải là single instance. Dưới lớp vỏ, Google chạy nhiều BGP task cho mỗi Cloud Router, phân tán trong region. Nếu một BGP task fail, các task khác tiếp tục duy trì sessions. Người dùng không thấy, không quản lý, và không cần lo lắng về redundancy ở tầng này.
Tuy nhiên, điều này không có nghĩa là Cloud Router không thể là điểm failure. Failure xảy ra ở tầng BGP session (phía ngoài), không phải tầng Cloud Router internal. Nếu on-prem router bị down, BGP session từ Cloud Router đến on-prem router đó bị drop, và routes từ peer đó biến mất — bất kể Cloud Router bên trong có bao nhiêu redundancy.
Phạm Vi Và Giới Hạn Của Cloud Router
Regional Scope — Không Phải Global
Mỗi Cloud Router là một regional resource. Khi tạo Cloud Router, bạn chỉ định:
- VPC network nó thuộc về
- Region nó hoạt động
Cloud Router trong us-central1 chỉ quản lý BGP sessions với peers trong hoặc liên quan đến us-central1. Nó không tự động xử lý BGP sessions trong us-east1.
Điều này có hệ quả quan trọng: nếu bạn có Dedicated Interconnect với VLAN attachments ở nhiều regions, bạn cần một Cloud Router riêng cho mỗi region có VLAN attachment. Tương tự với HA VPN — mỗi region cần Cloud Router riêng nếu bạn muốn dynamic routing trong region đó.
Quotas và Giới Hạn Thật
Theo tài liệu chính thức GCP, các giới hạn quan trọng bao gồm:
Per Cloud Router:
- Số BGP sessions tối đa: giới hạn phụ thuộc vào product type (VPN tunnels, Interconnect attachments)
- Tổng số unique prefixes có thể học (BGP-received + custom learned): áp dụng quota
- Số peers tối đa
Tại sao prefix limit quan trọng: Nếu on-prem route table quá lớn (ví dụ route đầy đủ internet BGP table với >900K prefixes), Cloud Router sẽ không nhận hết. Đây là lý do tại sao trong thiết kế hybrid connectivity, bạn phải kiểm soát số lượng routes được advertised từ on-prem, thường bằng cách summarize hoặc filter.
Lưu ý về prefix limit: Limit được áp dụng ở tầng Dynamic Route Control Plane, trước khi BGP route policies evaluate. Điều này nghĩa là bạn không thể dùng route policies để "lọc trước" và vượt qua prefix limit.
Quan Hệ Giữa Cloud Router và Các Sản Phẩm Hybrid Connectivity
Cloud Router là thành phần bắt buộc với:
- Dedicated Interconnect — BGP sessions chạy qua VLAN attachments
- Cross-Cloud Interconnect — tương tự Dedicated Interconnect
- Partner Interconnect — BGP sessions với Google-managed partner edge
- HA VPN — BGP sessions per tunnel
- Router Appliances (NCC) — BGP sessions với VM acting as router
Cloud Router là tùy chọn với:
- Classic VPN — hỗ trợ cả static routing (không cần Cloud Router) và dynamic routing (cần Cloud Router)
Với Classic VPN static routing, bạn cấu hình routes thủ công ở cả hai đầu. Không có BGP, không có dynamic learning. Đây là lý do Classic VPN không phù hợp cho production hybrid connectivity — mọi thay đổi về routing phải được cập nhật thủ công.
Tách Biệt Cloud Router Khỏi Network Data Plane
Implications Cho Capacity Planning
Vì Cloud Router không forward traffic, throughput của Cloud Router không phải là bottleneck cho hybrid connectivity bandwidth. Bottleneck nằm ở:
- Băng thông của HA VPN tunnels (giới hạn per-tunnel)
- Băng thông của Interconnect physical circuits
- Andromeda per-VM egress bandwidth
Khi một senior engineer hỏi "Cloud Router có scale được không khi traffic tăng?", câu trả lời là: Cloud Router không cần scale vì nó không xử lý traffic. Câu hỏi đúng là "tunnel/circuit có đủ bandwidth không?"
Implications Cho Troubleshooting
Khi debug connectivity issues với hybrid connectivity, quy trình cần chia làm hai phần:
Phần 1 — Control Plane (Cloud Router):
- BGP session có ở trạng thái ESTABLISHED không?
- Có routes nào được learned từ peer không?
- Routes đó có được install vào VPC route table không?
- Advertisement mode có đúng không?
Phần 2 — Data Plane (Andromeda/VPN/Interconnect):
- Packet có đến được VPN gateway / Interconnect edge không?
- Encryption/decryption có hoạt động không?
- MTU có đúng không?
- Firewall rules có block không?
Rất nhiều incident được report là "BGP issue" thực ra là data plane issue, và ngược lại. Cloud Router logs và VPC route table giúp phân định ranh giới này.
Khi Nào Cloud Router Thực Sự Là Root Cause
Cloud Router là root cause thực sự khi:
1. BGP session không đạt ESTABLISHED:
- ASN không khớp với peer configuration
- BGP peering IP address sai
- Firewall rule block BGP port (TCP 179)
- MD5 password mismatch
- Hold time negotiation failure
2. Routes không được install sau khi BGP ESTABLISHED:
- Advertisement mode misconfiguration
- Prefix limit exceeded (routes bị truncate)
- Route policy drop routes
- Routing loop detection (AS path loop)
3. Wrong routes được install:
- Custom route advertisement misconfigured
- MED values không như kỳ vọng
- Best-path selection mode không đúng (legacy vs standard)
- Routes từ sai peer được ưu tiên
4. Routes không propagate đến regions khác:
- Routing mode là regional thay vì global
- Inter-region cost ảnh hưởng best-path selection
Trong tất cả các trường hợp trên, data plane (Andromeda) không phải là vấn đề — vấn đề nằm hoàn toàn trong control plane.
Anti-Pattern: Nhầm Cloud Router Là Router Vật Lý
Biểu hiện: Team cố gắng "upgrade" Cloud Router để tăng throughput khi hybrid connectivity bị tắc nghẽn. Họ tìm kiếm option "Cloud Router size" hoặc "Cloud Router throughput".
Vì sao sai: Cloud Router không có size option vì nó không xử lý traffic. Throughput bottleneck là ở VPN tunnel hoặc Interconnect circuit, không phải Cloud Router.
Hệ quả: Tốn thời gian troubleshoot sai layer, delay resolution thực sự.
Cách nhận ra: Nếu BGP session ESTABLISHED và routes được install đúng, nhưng throughput bị giới hạn, thì vấn đề không phải Cloud Router.