Transitive Routing & NCC — Tại sao spoke-to-spoke không thông, và lời giải đúng

Why this matters in production

Đây là một trong những hiểu lầm gây tốn thời gian nhất khi thiết kế multi-VPC trên GCP. Một kỹ sư dựng hub-and-spoke bằng VPC peering: hub peer với spoke-A, hub peer với spoke-B. Họ kỳ vọng spoke-A nói chuyện được với spoke-B qua hub. Nó không thông. Họ kiểm tra firewall — đúng. Kiểm tra route nội bộ — có. Họ mất nhiều giờ trước khi phát hiện sự thật: VPC peering không transitive, và đây là quyết định thiết kế có chủ đích của GCP, không phải bug hay thiếu sót cấu hình.

Hiểu vì sao phi-transitive (chứ không chỉ "nhớ rằng nó phi-transitive") cho phép bạn (1) ngừng cố "lách" bằng những route tĩnh chắp vá vốn không bao giờ hoạt động sạch, và (2) chọn đúng công cụ — Network Connectivity Center (NCC) — vốn được thiết kế chính xác cho transitive connectivity. File này giải thích cơ chế phi-transitivity ở tầng routing rồi mổ xẻ mô hình route exchange của NCC.

Internal model — phi-transitivity là hệ quả của cách peering trao đổi route

Peering trao đổi route gì, và không trao đổi route gì

Khi hai VPC peer, chúng trao đổi subnet route của nhau (và tùy chọn một số custom route). Điểm mấu chốt về cơ chế nằm ở từ "của nhau":

   spoke-A ◄──peering──► hub ◄──peering──► spoke-B

   Qua peering A↔hub:  hub học subnet route CỦA A;  A học subnet route CỦA hub
   Qua peering hub↔B:  hub học subnet route CỦA B;  B học subnet route CỦA hub

   Nhưng: A KHÔNG học subnet route của B, và ngược lại.

Lý do ở tầng control plane: peering import vào VPC này chỉ những route thuộc về VPC kia trực tiếp, không re-export những route mà VPC kia đã học từ một peering khác. Hub học route của B, nhưng hub không quảng bá lại route đó cho A qua peering A↔hub. Theo tài liệu VPC peering, peering không transitive: "only directly peered networks can communicate"; route học qua một peering không được truyền tiếp qua một peering khác.

Vì A không bao giờ nhận route tới subnet của B, forwarding state của VM trong A không có entry nào trỏ tới B (quay lại file 01: không có route ⇒ không thể forward). Đây là gốc rễ thực sự của "spoke-to-spoke không thông" — nó là vấn đề vắng route, không phải vấn đề firewall. Đó là lý do debug firewall vô vọng.

Vì sao đây là thiết kế có chủ đích, không phải hạn chế

Phi-transitivity không phải Google "quên làm" transitive. Nó là một thuộc tính bảo mật và khả-suy-luận có chủ đích:

• Ngăn rò rỉ kết nối ngoài ý muốn. Nếu peering transitive, peer với một VPC sẽ vô tình cho bạn kết nối tới mọi VPC mà nó từng peer — một bề mặt tấn công lan rộng không kiểm soát. Phi-transitivity giữ mỗi quan hệ peering là một hợp đồng song phương, tường minh.
• Giữ route table suy luận được. Transitive routing dễ tạo vòng lặp và route table phình to khó kiểm soát. Phi-transitivity giữ mỗi VPC chỉ biết về các láng giềng trực tiếp của nó.
• Buộc transitive phải là quyết định tường minh. Nếu bạn thật sự muốn transitive, bạn phải chọn một công cụ được thiết kế cho nó (NCC, hoặc một router appliance ở hub) — một hành động có chủ đích, có kiểm soát, thay vì transitive "tự nhiên xảy ra".

Bài học kiến thức: "spoke-to-spoke không thông qua peering" không phải lỗi cần fix bằng mẹo. Nó là hành vi đúng theo thiết kế. Câu hỏi đúng không phải "làm sao lách phi-transitivity" mà là "công cụ nào được thiết kế để cung cấp transitive connectivity một cách tường minh".

Những "lời giải sai" và vì sao chúng tệ

Trước khi tới lời giải đúng, hiểu vì sao các workaround phổ biến đều dở giúp củng cố mental model:

• Static route trỏ qua hub: Bạn có thể tạo static route trong A: subnet-B → next-hop trong hub. Nhưng hub không forward giúp A trừ khi có thiết bị forwarding ở hub (peering không tự "transit" giúp). Và ngay cả khi dùng next-hop ILB/VM ở hub, bạn phải duy trì thủ công route hai chiều cho mọi cặp spoke → bùng nổ tổ hợp O(n²), dễ lệch, không scale.
• Full mesh peering (mọi spoke peer với mọi spoke): Loại bỏ nhu cầu transitive bằng cách cho mọi cặp trực tiếp peer. Nhưng số quan hệ peering là O(n²); GCP có giới hạn số peering trên mỗi VPC; và quản lý mesh thủ công là ác mộng vận hành ở quy mô hàng chục VPC.
• Router appliance ở hub: Đặt một VM router (next-hop) ở hub để transit giữa các spoke. Hoạt động, nhưng giờ bạn tự vận hành một datapath appliance (HA, scaling, patching, throughput) — gánh nặng mà GCP đã giải bằng NCC.

Network Connectivity Center: transitive connectivity được quản lý

NCC là dịch vụ được thiết kế chính xác để cung cấp transitive connectivity mà peering cố tình không làm. Theo tài liệu NCC, mô hình là hub-and-spoke:

                    ┌─────────────────────────┐
                    │   NCC Hub (global)      │
                    │   - route exchange      │
                    │     trung tâm giữa spoke│
                    └─────────────────────────┘
            ┌──────────────┬──────────┴───────┬──────────────┐
            ▼              ▼                  ▼              ▼
        VPC spoke     VPC spoke          Hybrid spoke    Hybrid spoke
        (spoke-A)     (spoke-B)          (HA VPN tunnel) (Interconnect
                                                          VLAN attach)

Cơ chế cốt lõi khác hẳn peering:

• Hub là global resource mà bạn gắn (attach) các spoke vào. Một hub chứa spoke từ nhiều region.
• VPC spoke: theo tài liệu, "VPC spoke export subnet route lên hub và import subnet route + dynamic route từ hub". Mấu chốt: route được tập trung tại hub rồi phân phối lại cho mọi spoke — chính cái mà peering từ chối làm. Vì hub re-export, spoke-A học được subnet route của spoke-B (qua hub) → forwarding state của A giờ có entry tới B → thông.
• Hybrid spoke: đại diện HA VPN tunnel, Interconnect VLAN attachment, router appliance, Cross-Cloud Interconnect. Hybrid spoke học và phân phối lại dynamic route qua BGP qua hub.
• Any-to-any: tài liệu nêu rõ "khi hub dùng cả VPC spoke và hybrid spoke, any-to-any connectivity được hỗ trợ across tất cả các spoke đó". Đây là sự khác biệt nền tảng so với peering point-to-point.

Mental model: Peering là song phương, phi-transitive — mỗi VPC chỉ biết láng giềng trực tiếp. NCC là hub trung tâm re-export route — hub đóng vai trò "route reflector" cho mọi spoke, nên route của một spoke đến được mọi spoke khác. Transitive connectivity của NCC không phải "peering nhưng tốt hơn"; nó là một mô hình route exchange khác về bản chất (tập trung qua hub thay vì phân tán song phương).

NCC vs peering: chọn cái nào

Tiêu chí	VPC Peering	NCC
Transitivity	Không (song phương)	Có (any-to-any qua hub)
Topology điển hình	Vài VPC, quan hệ tường minh	Hub-and-spoke nhiều VPC + hybrid
Hybrid (VPN/Interconnect) trong cùng mô hình	Không thống nhất	Có (hybrid spoke)
Độ phức tạp khi scale	O(n²) quan hệ, chạm giới hạn peering	O(n) spoke gắn vào 1 hub
Khi nào dùng	Kết nối 1-1 đơn giản, kiểm soát chặt từng cặp	Landing zone nhiều VPC cần transit + hybrid tập trung

Peering vẫn đúng cho các kết nối 1-1 đơn giản nơi bạn muốn sự cô lập của phi-transitivity. NCC đúng khi bạn cần một fabric transit nhiều spoke và muốn gộp cả on-prem (hybrid spoke) vào cùng một mô hình route exchange.

Constraints, trade-offs & failure modes

Tập trung route ⇒ hub là điểm cần suy nghĩ kỹ

NCC tập trung route exchange tại hub. Đây là sức mạnh (transitive) nhưng cũng nghĩa là chính sách route và quota tập trung tại hub cần được thiết kế cẩn thận: overlap subnet giữa các spoke gây nhập nhằng route; số prefix tổng hợp qua hub đếm vào quota. Khác peering (overlap chỉ ảnh hưởng cặp liên quan), trong NCC một spoke có subnet chồng lấn có thể ảnh hưởng khả-suy-luận của toàn fabric.

Overlap CIDR vẫn là kẻ thù

Cả peering lẫn NCC đều không cho phép subnet CIDR chồng lấn giữa các mạng tham gia, vì route table không thể có hai route cùng đích từ hai nguồn mà vẫn suy luận sạch. Đây là lý do IP address management (IPAM) tập trung là điều kiện tiên quyết của mọi multi-VPC topology — quyết định bạn phải làm trước khi chọn peering hay NCC, không phải sau.

Transitive làm blast radius rộng hơn

Đổi lại sự tiện lợi của any-to-any, NCC mở rộng blast radius: một route sai hoặc một spoke bị xâm phạm có khả năng ảnh hưởng tới mọi spoke khác (vì chúng giờ reachable). Đây là sự đánh đổi cố hữu của transitive connectivity — chính lý do peering chọn phi-transitive. Khi dùng NCC, bù lại bằng firewall (file 08) và phân đoạn rõ ràng giữa các spoke; transitive routing không có nghĩa là transitive quyền truy cập.

Anti-pattern: cố "sửa" phi-transitivity của peering bằng route tĩnh

• Vì sao xảy ra: hiểu lầm rằng phi-transitivity là một thiếu sót cần workaround, thay vì một thuộc tính thiết kế; cộng với việc không biết NCC tồn tại.
• Hệ quả ở scale: một mạng nhện route tĩnh O(n²) trỏ qua hub, dễ lệch, không ai dám sửa; hoặc full-mesh peering chạm giới hạn và biến thành nợ vận hành; sự cố routing khó truy nguyên vì route được "vá" thủ công khắp nơi.
• Cách tư duy đúng: phi-transitivity là đúng theo thiết kế. Nếu cần transitive, dùng công cụ được thiết kế cho transitive (NCC, hoặc router appliance có chủ đích) — đừng tái tạo nó bằng route tĩnh. Quyết định transitive phải tường minh, tập trung, và quản lý được.

GCP-native implementation guidance

# Tạo NCC hub (global) và gắn các VPC spoke — route được re-export qua hub
gcloud network-connectivity hubs create prod-hub --global

gcloud network-connectivity spokes linked-vpc-network create spoke-a \
  --hub=prod-hub --vpc-network=vpc-a --global

gcloud network-connectivity spokes linked-vpc-network create spoke-b \
  --hub=prod-hub --vpc-network=vpc-b --global
# → giờ spoke-a học subnet route của spoke-b QUA hub (điều peering không làm)

# Hybrid spoke: gắn HA VPN tunnel để on-prem cũng vào fabric any-to-any
gcloud network-connectivity spokes linked-vpn-tunnels create onprem-spoke \
  --hub=prod-hub --region=us-central1 --vpn-tunnels=tun-to-A,tun-to-B

Kiểm chứng transitive bằng Connectivity Tests giữa một VM ở spoke-A và một VM ở spoke-B: nếu route đã re-export đúng qua hub, test cho thấy đường đi thông; nếu vẫn "no route", kiểm tra overlap CIDR và trạng thái spoke trước khi nghi firewall.

Tóm tắt mental model

• VPC peering phi-transitive vì peering chỉ import route trực tiếp của láng giềng, không re-export route học từ peering khác. "Spoke-to-spoke không thông" là vấn đề vắng route, không phải firewall.
• Phi-transitivity là thiết kế có chủ đích: chống rò rỉ kết nối, giữ route table suy luận được, buộc transitive phải tường minh.
• Các workaround (static route O(n²), full-mesh peering, tự vận hành router appliance) đều dở; lời giải đúng là NCC.
• NCC = hub re-export route cho mọi spoke → any-to-any (VPC spoke + hybrid spoke). Đây là mô hình route exchange khác bản chất so với peering, không phải "peering tốt hơn".
• Đổi lại: route/quota/policy tập trung ở hub, blast radius rộng hơn, và không overlap CIDR vẫn là điều kiện tiên quyết (IPAM tập trung trước tiên).

References

• VPC Network Peering — phi-transitivity, trao đổi subnet route, giới hạn
• Network Connectivity Center Overview — hub/spoke, VPC vs hybrid spoke, any-to-any, route exchange
• NCC VPC spokes — export/import subnet & dynamic route qua hub
• VPC Routes — vắng route ⇒ không forward; tương tác route nội bộ vs NCC vs peering