Network Connectivity Center — Hub-and-Spoke Orchestration
Tại sao quan trọng trong production
Khi hạ tầng mở rộng, một vấn đề xuất hiện không ai dự đoán từ đầu: việc quản lý kết nối trở thành bottleneck. Một tổ chức với 5 on-premises sites và 3 VPC regions cần kết nối full-mesh sẽ phải quản lý O(n²) connections. Thêm một site mới yêu cầu thêm kết nối đến tất cả sites hiện có.
Network Connectivity Center (NCC) giải quyết bài toán này theo cách khác: thay vì kết nối point-to-point giữa mọi cặp, tất cả sites kết nối đến một hub trung tâm, và hub điều phối routing giữa các sites. Đây là mô hình hub-and-spoke cổ điển, nhưng NCC thực hiện nó dưới dạng managed service trên Google's global network.
Điều quan trọng cần hiểu ngay từ đầu: NCC không phải chỉ là "management layer" cho phép bạn quản lý nhiều connections. NCC thực sự thay đổi routing model — nó enable một loại connectivity (site-to-site qua Google backbone) mà không có NCC, bạn không thể làm được với Cloud VPN hoặc Interconnect đơn lẻ.
Internal Model — Cơ Chế Hoạt Động Bên Trong
Hub: Global Resource và Routing Orchestrator
Hub là resource global duy nhất của NCC. Nó không phải router, không phải server — nó là control plane abstraction chứa policy về cách các spokes kết nối với nhau.
Khi bạn tạo hub và attach spokes vào, NCC orchestrator thực hiện:
- Thu thập routes từ tất cả hybrid spokes (routes học được từ on-premises qua BGP).
- Re-advertise các routes này đến các hybrid spokes khác qua Cloud Router.
- Cho phép traffic flow giữa on-premises sites qua Google's network.
Đây là điều không thể làm nếu không có NCC: một Cloud Router thông thường học routes từ on-premises qua VPN/Interconnect, nhưng không thể quảng bá lại routes đó đến một VPN tunnel khác (do thiết kế của BGP trong Cloud Router — tránh routing loops). NCC vượt qua giới hạn này bằng cách sử dụng route re-advertisement mechanism được kiểm soát ở cấp hub.
Spoke Types — Các Loại Kết Nối Attach vào Hub
NCC hỗ trợ nhiều loại spoke, và mỗi loại có cơ chế routing khác nhau:
VPC Spoke
VPC spoke kết nối một VPC network với hub. Khi một VPC network được add vào hub như một spoke, subnet routes của VPC đó được trao đổi với tất cả VPC spokes khác trong hub.
Đây là alternative cho VPC Peering với một số tradeoff:
- Pros: Không có transitivity limitation như VPC Peering. VPC A và VPC B đều spoke của cùng hub có thể "nhìn thấy" nhau dù không peering trực tiếp.
- Cons: NCC VPC spoke không hỗ trợ tất cả use cases của VPC Peering (ví dụ: Private Service Access, GKE control plane access qua spoke vẫn có giới hạn).
- NCC VPC spoke hiện không hỗ trợ overlapping IP ranges giữa các spokes.
Producer VPC spoke là extension: nếu VPC của bạn đang consume dịch vụ từ producer qua VPC Peering, producer VPC spoke cho phép các spokes khác trong hub cũng access được dịch vụ đó — giải quyết transitivity limitation của peering.
Hybrid Spoke
Hybrid spoke attach một hybrid connectivity resource vào hub:
- HA VPN tunnels
- Cloud Interconnect VLAN attachments
- Cross-Cloud Interconnect VLAN attachments
- Router appliance VMs
Khi on-premises site A và on-premises site B đều có hybrid spoke vào cùng hub, routes từ site A được re-advertised đến Cloud Router của site B (và ngược lại). Traffic từ A đến B đi qua Google's backbone — Google's network becomes your WAN.
[On-prem Site A] ── HA VPN ── [Hybrid Spoke A] ──┐
├── [HUB] ── route re-advertisement
[On-prem Site B] ── Interconnect ── [Hybrid Spoke B] ──┘Traffic từ Site A đến Site B: packet từ Site A đi qua HA VPN tunnel vào GCP, được routing qua Google backbone đến VLAN attachment kết nối với Site B, rồi ra Site B. Không có direct VPN tunnel giữa A và B.
Đây là mô hình Site-to-Site Data Transfer — một feature phải được explicitly enable trên hub.
NCC Gateway Spoke
Gateway spoke cho phép traffic cross-cloud được inspect bởi security appliance (SASE, SSE — Security Service Edge). Nó attach một gateway trong Google Cloud (thường là Cloud Next Generation Firewall Enterprise hoặc third-party security VM) vào hub.
Traffic từ spoke khác có thể được route qua gateway spoke để inspection trước khi forward tiếp. Use case: enforce consistent security policy cho tất cả cross-spoke traffic.
Site-to-Site Data Transfer — Cơ Chế Quan Trọng Nhất
Site-to-site data transfer là feature cốt lõi làm NCC trở nên valuable cho enterprise WAN. Nó cho phép hai hybrid spokes (connected đến các on-premises sites khác nhau) trao đổi traffic qua Google backbone.
Yêu cầu để enable:
- Site-to-site data transfer phải được explicitly enable trên mỗi hybrid spoke.
- Tất cả hybrid spokes trong cùng group phải reference resources trong cùng một VPC network — Google dùng VPC đó như "transit fabric" để route traffic giữa các sites.
- Chỉ hỗ trợ IPv4 cho hybrid spokes.
Cách route re-advertisement hoạt động:
Khi site-to-site enabled:
- Cloud Router của Spoke A học routes từ Site A qua BGP.
- NCC hub collect routes này.
- Hub advertise routes của Site A vào Cloud Router của Spoke B.
- Cloud Router của Spoke B announce routes Site A đến Site B.
- Kết quả: Site B biết cách reach Site A qua GCP backbone.
Traffic flow khi Site B gửi packet đến Site A:
- Packet từ Site B vào Spoke B (VPN tunnel hoặc Interconnect).
- Cloud Router lookup route, next-hop là VPN tunnel hoặc Interconnect của Spoke A.
- Packet traverse Google backbone.
- Packet ra qua Spoke A, delivered đến Site A.
Billing: Site-to-site data transfer có additional charge theo volume ($/GB). Đây khác với regular hybrid connectivity (chỉ tính theo attachment/port, không tính per-GB). Với large data volumes, cost có thể significant.
Giới hạn: Không phải mọi region đều support site-to-site data transfer. Phải verify danh sách supported regions trước khi thiết kế.
NCC vs Các Giải Pháp Thay Thế
Để hiểu khi nào dùng NCC, cần so sánh với các alternatives:
NCC vs VPC Peering Mesh
VPC Peering mesh (mỗi VPC peer với mọi VPC khác) bị giới hạn bởi:
- Non-transitivity: Peering không transitive — A-B và B-C không tự động cho A-C connectivity.
- Scale: Với N VPC, cần N*(N-1)/2 peering connections. Với 10 VPC: 45 connections. Với 50 VPC: 1,225 connections — không scale được.
- Management overhead: Mỗi peering phải được maintain riêng.
NCC VPC spoke: tất cả VPC kết nối vào hub, scale tuyến tính O(N).
NCC vs HA VPN Mesh cho Site-to-Site
Thay vì NCC, bạn có thể tạo HA VPN tunnel giữa mỗi cặp on-premises sites. Với 10 sites: 45 tunnel pairs. Vấn đề:
- Chi phí tuyến tính theo số cặp.
- Bandwidth per-tunnel bị giới hạn ở 3 Gbps.
- Management complexity: 90+ tunnel endpoints.
NCC với 10 hybrid spokes: 10 spokes, 1 hub. Route re-advertisement tự động.
NCC vs SD-WAN
SD-WAN (Software-Defined WAN) là một category sản phẩm khác, thường được deploy on-premises hoặc tại edge. NCC không thay thế SD-WAN — thực tế, nhiều tổ chức dùng cả hai: SD-WAN quản lý traffic giữa branches và data center, NCC quản lý connectivity lên cloud. Một số SD-WAN vendors integrate với NCC qua Router Appliance spoke.
Router Appliance Spoke
Router Appliance là một pattern đặc biệt trong NCC: thay vì dùng HA VPN hoặc Interconnect, bạn chạy một VM trong GCP với routing software (third-party, ví dụ Cisco CSR 1000v, Palo Alto VM-Series) và attach nó vào hub như một spoke.
Điều này có ích khi:
- Cần BGP communities hoặc routing policies phức tạp hơn Cloud Router hỗ trợ.
- Đã có investment vào một vendor's routing stack.
- Cần protocol-specific features (ví dụ: specific MPLS capabilities).
Router Appliance VM chạy trong VPC, có interface vào on-premises qua VPN hoặc Interconnect, và NCC xem nó như một routing endpoint. Cloud Router vẫn phải có mặt để "bridge" giữa VM và NCC hub routing.
Constraints & Giới Hạn
Chỉ IPv4 cho hybrid spokes
Site-to-site data transfer và hybrid spoke support chỉ IPv4. VPC spoke support IPv6 cho subnet exchange, nhưng hybrid (VPN, Interconnect) chưa support IPv6 data transfer qua NCC. Nếu hạ tầng của bạn có dual-stack requirement cho on-premises, đây là giới hạn quan trọng.
ASN requirement cho Router Appliances
Tất cả non-Google peering routers trong một spoke phải có cùng ASN. Không thể mix ASN trong một spoke. Điều này có thể là constraint nếu bạn có legacy on-premises infrastructure với different ASN assignments.
BGP communities không được support
NCC không propagate BGP communities giữa spokes. Nếu traffic engineering policy của bạn phụ thuộc vào BGP communities (ví dụ: để implement policy-based routing khác nhau cho các traffic types), NCC không phải giải pháp phù hợp.
Classic VPN không được support
Classic VPN tunnel không thể attach vào NCC spoke. Phải dùng HA VPN. Đây là một lý do khác để migrate từ Classic VPN.
Route Aggregation Limit
Hub có giới hạn về số lượng routes có thể propagate. Với large-scale deployments (nhiều on-premises sites, mỗi site advertise nhiều prefixes), cần route summarization ở on-premises side để không vượt quá limits.
GCP-native Implementation Guidance
Tạo NCC hub với hybrid spokes:
# 1. Tạo NCC Hub
gcloud network-connectivity hubs create enterprise-hub \
--description="Enterprise connectivity hub"
# 2. Attach HA VPN tunnels vào hub (tạo spoke cho Site A)
gcloud network-connectivity spokes linked-vpn-tunnels create site-a-spoke \
--hub=enterprise-hub \
--region=us-central1 \
--vpn-tunnels=tunnel-a-0,tunnel-a-1 \
--site-to-site-data-transfer
# 3. Attach Interconnect attachment vào hub (tạo spoke cho Site B)
gcloud network-connectivity spokes linked-interconnect-attachments create site-b-spoke \
--hub=enterprise-hub \
--region=us-east1 \
--interconnect-attachments=vlan-attachment-b1,vlan-attachment-b2 \
--site-to-site-data-transfer
# 4. Kiểm tra trạng thái hub và spokes
gcloud network-connectivity hubs describe enterprise-hub
gcloud network-connectivity spokes list --hub=enterprise-hub
# 5. Verify route propagation
gcloud compute routers get-status my-cloud-router \
--region=us-central1 \
--format='json(result.bgpPeerStatus, result.bestRoutesForRouter)'Verify site-to-site connectivity sau khi cấu hình:
# Từ VM trong GCP, kiểm tra route reachability đến cả hai sites
ip route show | grep -E "10\.(0|1)\."
# Từ on-premises Site A, kiểm tra route đến Site B
# (trên on-premises router)
show ip bgp summary
show ip route 192.168.2.0Khi Nào Dùng NCC — Decision Framework
| Scenario | Giải pháp tốt nhất |
|---|---|
| 2–3 VPC cần kết nối | VPC Peering (đơn giản hơn) |
| 10+ VPC cần kết nối | NCC VPC spoke |
| 2 on-premises sites cần kết nối GCP | HA VPN hoặc Interconnect riêng lẻ |
| 5+ on-premises sites cần kết nối với nhau qua GCP | NCC với site-to-site data transfer |
| Cần transit routing qua appliance | NCC Router Appliance spoke |
| Legacy Classic VPN topology | Migrate sang HA VPN, rồi xét NCC |
| BGP community-based policy | NCC không phù hợp, xét SD-WAN |