My Awesome Project

Appearance

Cloud Interconnect — Kết Nối Vật Lý, VLAN, BGP & MACsec ​

Tại sao quan trọng trong production ​

Cloud Interconnect giải quyết bài toán mà Cloud VPN không thể: băng thông cao, latency thấp và nhất quán, không đi qua public internet. Đây là lựa chọn bắt buộc cho các use case:

  • Data-intensive workloads: database replication, analytics pipelines, media processing — cần throughput ổn định >3 Gbps.
  • Latency-sensitive applications: trading platforms, real-time telemetry — cần predictable latency không bị jitter của internet.
  • Compliance/security: môi trường yêu cầu traffic không đi qua public internet (dù đã mã hóa bằng IPsec).

Nhưng Interconnect phức tạp hơn VPN về nhiều mặt: đòi hỏi hạ tầng vật lý (colocation hoặc service provider), chi phí cao hơn, và topology để đạt 99.99% SLA có những yêu cầu cụ thể mà sai một chi tiết sẽ không đạt được SLA tier đó.

Internal Model — Cơ Chế Hoạt Động Bên Trong ​

Kiến trúc tổng thể: Dedicated vs Partner ​

Cloud Interconnect có hai loại, khác nhau về cách thiết lập kết nối vật lý với Google's network:

Dedicated Interconnect: Kết nối vật lý trực tiếp. Thiết bị on-premises của bạn (hoặc thiết bị trong colocation facility mà bạn thuê) được kết nối fiber trực tiếp với Google's edge routers. Không có trung gian.

Partner Interconnect: Kết nối qua service provider. Provider đã có kết nối vật lý với Google's network, và bạn thuê một phần capacity đó. Bạn không cần thiết bị trong colocation facility của Google.

Sự khác biệt quan trọng nhất không phải là "ai vận hành dây cáp" mà là ai chịu trách nhiệm về từng segment của đường truyền:

Khía cạnhDedicatedPartner
Physical last-mileBạnProvider
SLA on Google sideGoogle cam kếtGoogle cam kết
SLA on last-mileBạn quản lýProvider cam kết (tách biệt SLA)
Bandwidth10G/100G/400G per port50 Mbps đến 50 Gbps per attachment
Colocation requirementCầnKhông cần
Activation timeNhiều tuầnCó thể nhanh hơn

Với Dedicated, end-to-end SLA phụ thuộc vào chính bạn (bạn phải tự đảm bảo cáp, thiết bị, redundancy trong colocation). Với Partner, SLA của last-mile phụ thuộc vào provider — Google chỉ cam kết phần từ edge của Google đến VPC của bạn.

Dedicated Interconnect — Physical Layer ​

Dedicated Interconnect đòi hỏi thiết bị kết nối trực tiếp với Google's Interconnect facility. Google có một danh sách các colocation facilities trên toàn cầu (gọi là "Interconnect locations" hoặc "Points of Presence").

Yêu cầu vật lý:

Loại circuitFiber standardTốc độMax per link bundle
10-Gbps10GBASE-LR (single-mode, 1310nm)10 Gbps8 circuits = 80 Gbps
100-Gbps100GBASE-LR4100 Gbps8 circuits = 800 Gbps
400-Gbps400GBASE-LR4400 Gbps8 circuits = 3,200 Gbps

Giới hạn quan trọng: Fiber length tối đa là 10 km cho tất cả các loại (10GBASE-LR, 100GBASE-LR4, 400GBASE-LR4). Điều này có nghĩa là thiết bị của bạn phải ở trong cùng hoặc gần colocation facility của Google. Nếu data center của bạn ở xa hơn 10 km, bạn cần extended reach optics (yêu cầu liên hệ Google account manager) hoặc phải dùng Partner Interconnect.

Link type (10G/100G/400G) là không thể thay đổi sau khi đã provision. Đây là quyết định permanent hardware.

LACP (Link Aggregation Control Protocol): Thiết bị của bạn phải hỗ trợ LACP. Google dùng LACP để bundle nhiều physical circuits thành một logical interface (LAG — Link Aggregation Group) để aggregate bandwidth.

VLAN Attachments — Lớp Logic Kết Nối VPC với Interconnect ​

VLAN attachment (còn gọi là interconnect attachment hoặc VLAN attachment) là resource logic chạy trên đỉnh physical Interconnect connection. Đây là điểm kết nối giữa:

  • Phía GCP: Cloud Router trong VPC của bạn.
  • Phía on-premises: Router của bạn (Dedicated) hoặc router của provider (Partner).

Mỗi VLAN attachment đại diện cho một 802.1Q VLAN trên physical link. Bạn có thể tạo nhiều VLAN attachment trên cùng một physical Interconnect, mỗi attachment tương ứng với một VLAN khác nhau và kết nối với một Cloud Router khác nhau.

Physical Interconnect Link
├── VLAN 100 → Attachment A → Cloud Router A → VPC Production
├── VLAN 200 → Attachment B → Cloud Router B → VPC Staging
└── VLAN 300 → Attachment C → Cloud Router C → VPC Management

Điều này cho phép network segmentation — nhiều VPC chia sẻ một physical connection nhưng traffic được cách ly ở L2.

MTU trên VLAN attachments: Dedicated Interconnect hỗ trợ jumbo frames, với các MTU options: 1440, 1460, 1500, hoặc 8896 bytes (jumbo frames). Tuy nhiên, jumbo frames (8896) chỉ hoạt động với unencrypted IPv4/IPv6 traffic. Nếu bạn chạy HA VPN over Interconnect (thêm IPsec trên Interconnect), MTU giảm xuống 1440.

VLAN attachment bandwidth: Bạn cấu hình capacity cho mỗi attachment (ví dụ: 5 Gbps, 10 Gbps). Đây là capacity được sử dụng cho ECMP load balancing và bandwidth accounting — không phải hard limit enforcement ở L1.

BGP Sessions over Interconnect ​

Sau khi VLAN attachment được cấu hình, Cloud Router thiết lập BGP session với peer router on-premises (Dedicated) hoặc peer router của provider (Partner L2).

Địa chỉ BGP peer: Sử dụng IPv4 link-local addresses (169.254.0.0/16), không phải global routable addresses. Điều này tương tự VPN over BGP. Mỗi BGP session cần một /30 subnet unique trong dải 169.254.0.0/16.

Dedicated vs Partner L2 vs Partner L3:

  • Dedicated: Bạn configure BGP session trực tiếp giữa Cloud Router và on-premises router của bạn.
  • Partner L2: Provider cung cấp L2 connectivity, bạn vẫn phải configure BGP giữa Cloud Router và on-premises router của bạn.
  • Partner L3: Provider handle BGP session với Cloud Router thay mặt bạn, và quảng bá routes theo thỏa thuận với provider. Bạn không cần configure BGP trên Cloud Router side. Đây là "easiest" nhưng cũng là "least control".

BGP session health và route exchange:

Cloud Router (ASN 16550) ←── BGP session (169.254.x.x/30) ──→ On-premises router (ASN 65001)
       |                                                              |
  VPC subnets (advertised to on-prem)                  On-prem subnets (learned by Cloud Router)
       |                                                              |
  Install into VPC route table                        Install into on-prem routing table

Cloud Router học routes qua BGP, và program chúng vào VPC route table với next-hop là VLAN attachment. Khi attachment down, BGP session mất, routes bị withdrawn.

MP-BGP và dual-stack: Nếu cần IPv6, có thể configure dual-stack VLAN attachment với:

  • Separate IPv4 và IPv6 BGP sessions, hoặc
  • Multiprotocol BGP (MP-BGP) kết hợp cả hai address families trong một session.

Redundancy Model — Đạt 99.99% SLA ​

Đây là phần dễ bị hiểu sai nhất. Google cam kết SLA tier khác nhau tùy vào topology bạn deploy:

SLA TierTênYêu cầu topology
99.99%Critical production4 connections, 2 metros, 2 edge availability domains per metro
99.9%Non-critical production2 connections, 1 metro, 2 edge availability domains
Không có SLA—1 connection

Edge Availability Domain là khái niệm cốt lõi. Trong mỗi metro (thành phố/khu vực), Google có nhiều facilities, và các facilities này được nhóm thành edge availability domains — các failure domains độc lập về maintenance và infrastructure. Google coordinate maintenance schedules theo domain, không phải theo individual facility.

Để đạt 99.9% SLA: hai connections trong cùng metro, nhưng phải ở hai edge availability domains khác nhau. Hai connections trong cùng domain không count.

Để đạt 99.99% SLA: bốn connections, phân bổ trên hai metros khác nhau, mỗi metro có hai connections trên hai edge availability domains khác nhau. Ví dụ:

Metro A (ví dụ: Ashburn, VA)
├── Edge Domain 1 → Connection 1 (10 Gbps)
└── Edge Domain 2 → Connection 2 (10 Gbps)

Metro B (ví dụ: Atlanta, GA)
├── Edge Domain 1 → Connection 3 (10 Gbps)
└── Edge Domain 2 → Connection 4 (10 Gbps)

Tại sao cần 2 metros cho 99.99%? Maintenance windows trong một metro có thể ảnh hưởng đến tất cả connections trong metro đó (dù ở các domains khác nhau), vì maintenance được coordinate ở metro level. Nếu chỉ có một metro, một maintenance event có thể đưa tất cả connections xuống simultaneously — vi phạm 99.99%.

Load balancing giữa connections: Cloud Router quảng bá prefix với cùng capacity lên tất cả active connections. Google sử dụng ECMP (Equal-Cost Multi-Path) để phân phối egress traffic tỷ lệ theo capacity của mỗi VLAN attachment. Nếu attachment A có capacity 10 Gbps và attachment B có capacity 5 Gbps, Google sẽ gửi 2/3 traffic qua A và 1/3 qua B.

Khi một connection fail, traffic automatically reroute sang connections còn lại. Failover time phụ thuộc vào BGP hold timer và BFD — với BFD bật, thường dưới 1 giây.

MACsec — Layer 2 Encryption ​

Tại sao MACsec tồn tại bên cạnh IPsec ​

IPsec (qua HA VPN over Interconnect) mã hóa ở L3. MACsec mã hóa ở L2. Hai cơ chế này bảo vệ ở các points khác nhau:

  • IPsec: Bảo vệ traffic từ on-premises network đến GCP VPC, encrypt ngay khi packet rời host/router on-premises.
  • MACsec: Bảo vệ "first-mile/last-mile" — đoạn physical link giữa on-premises router của bạn và Google's edge router. Giải quyết threat model: ai đó tap vào cable trong colocation facility.

Với Dedicated Interconnect không có MACsec, traffic giữa on-premises router và Google edge router đi dưới dạng plaintext Ethernet frames (chỉ có VLAN tagging, không encrypt). Nếu ai đó có physical access hoặc compromise thiết bị trong facility, họ có thể đọc traffic.

MACsec (IEEE 802.1AE) encrypt Ethernet frames tại chính điểm kết nối, trước khi chúng đi qua physical medium.

Cơ chế hoạt động ​

MACsec hoạt động ở L2, point-to-point giữa hai adjacent devices. Điểm này quan trọng: MACsec không phải end-to-end encryption giữa on-premises host và GCP VM — nó chỉ encrypt đoạn from your router to Google's edge router.

[On-prem Host] ──── [On-prem Router] ═══MACsec encrypted═══ [Google Edge Router] ──── [GCP VPC]
                       (MACsec capable)                        (MACsec capable)

Encryption: GCM-AES-256. Hai cipher suites:

  • GCM-AES-256-XPN (extended packet numbering): Khuyến nghị cho high-bandwidth links (100 Gbps, 400 Gbps). XPN dùng 64-bit extended sequence number, tránh wrap-around ở high throughput.
  • GCM-AES-256: Đủ cho 10 Gbps, nhưng có thể có packet loss nếu sequence number wrap-around trong điều kiện control plane overload.

Key Management:

  • Google generate Connectivity Association Key (CAK) và Connectivity Association Key Name (CKN) qua Cloud Console hoặc gcloud CLI.
  • CAK là symmetric key dùng để derive session keys (SAK — Secure Association Key) qua MACsec Key Agreement (MKA) protocol.
  • Hỗ trợ hitless key rotation — có thể rotate key mà không interrupt traffic. Hỗ trợ tối đa 5 keys trên một connection, với rekey interval mặc định 28,800 giây.
  • Keys có "infinite validity" theo docs — nhưng bạn nên rotate định kỳ theo security policy.

Supported connections:

  • Tất cả 100-Gbps circuits.
  • Tất cả 400-Gbps circuits.
  • 10-Gbps circuits: hỗ trợ hạn chế, cần liên hệ account manager.
  • Không có additional cost cho MACsec.

Failover với MACsec: Nếu một connection fail và traffic reroute sang connection khác, MACsec key phải được re-negotiated trên connection mới. Điều này thêm vào failover time, nhưng thường là sub-second với MKA protocol.

MACsec vs HA VPN over Interconnect ​

Hai approach bảo vệ các threat models khác nhau:

AspectMACsecHA VPN over Interconnect
LayerL2L3
Bảo vệ đoạnOn-prem router ↔ Google edge routerOn-prem network ↔ GCP VPC
OverheadRất nhỏ (line-rate hardware)IPsec overhead, MTU giảm xuống 1440
Throughput impactMinimalSignificant (fragmentation, reassembly)
Use caseCompliance requiring physical link encryptionTraffic encryption end-to-end kể cả trong GCP

Một số regulatory requirements (FIPS 140-2, PCI-DSS) yêu cầu encryption "in transit" bao gồm physical links — MACsec đáp ứng requirement này. Nếu yêu cầu chỉ là "traffic không đi qua public internet", Interconnect không có MACsec cũng đủ.

Partner Interconnect — Mô Hình Kết Nối qua Provider ​

Partner Interconnect phù hợp khi:

  • Data center của bạn không gần colocation facility của Google.
  • Bandwidth cần thiết dưới 10 Gbps (Dedicated minimum là 10 Gbps per circuit).
  • Muốn on-board nhanh hơn mà không cần thiết lập hạ tầng colocation.

VLAN attachment và pairing key: Khi bạn tạo Partner Interconnect VLAN attachment, Google generate một pairing key — một string unique bạn cung cấp cho service provider. Provider dùng pairing key để kết nối circuit của họ với attachment của bạn trong hệ thống của Google.

Layer 2 vs Layer 3 partner connection:

  • Layer 2: Provider chỉ cung cấp Ethernet forwarding, không tham gia vào BGP. Bạn phải configure BGP trực tiếp giữa Cloud Router và on-premises router của bạn (tương tự Dedicated).
  • Layer 3: Provider termonate BGP session với Cloud Router thay mặt bạn, và quảng bá routes bạn muốn. Bạn configure routing với provider theo thỏa thuận kinh doanh. Ít control, nhưng đơn giản hơn để vận hành.

SLA với Partner: SLA của Google chỉ bao phủ segment từ Google edge đến VPC. Segment từ on-premises đến provider edge là trách nhiệm của provider (provider có SLA riêng). End-to-end availability phụ thuộc vào cả hai SLAs được thỏa mãn đồng thời.

Pre-activation cho Layer 3: Partner L3 attachment có thể bật pre-activation — attachment pass traffic ngay khi provider configure, không cần manual verification từ phía bạn.

Constraints & Failure Modes ​

Bandwidth per attachment ​

Mỗi VLAN attachment có bandwidth capacity được khai báo (50 Mbps đến 50 Gbps tùy loại). Đây là capacity dùng cho ECMP weighting và billing, không phải hard enforcement ở L1. Nếu bạn gửi nhiều hơn capacity khai báo, traffic không bị drop ngay — nhưng ECMP distribution sẽ lệch.

Physical limit: tổng bandwidth không vượt quá physical port capacity (10 Gbps, 100 Gbps, hoặc 400 Gbps).

BGP session flap và route withdrawal ​

Khi BGP session flap (do maintenance, fiber issue, router restart), Cloud Router withdraw tất cả routes học được qua session đó. Nếu chỉ có một connection và BGP session duy nhất, traffic drop trong suốt thời gian reconvergence.

Với redundant connections và ECMP, route được maintain qua connection còn lại, nhưng:

  • Traffic tạm thời bị drop trong quá trình reroute (thường vài giây nếu không có BFD).
  • Capacity giảm về 50% (hoặc theo trọng số còn lại).

Planned maintenance và SLA exclusions ​

Google's SLA không bao gồm downtime do:

  • Planned maintenance (được thông báo trước).
  • Force majeure.
  • Customer-caused issues.

Với 99.99% SLA topology (4 connections, 2 metros), planned maintenance trên một connection không gây downtime vì traffic reroute sang các connections còn lại. Đây là reason tại sao 4 connections mới đủ cho 99.99% — không phải vì reliability cao hơn, mà vì có đủ redundancy để maintenance zero-impact.

GCP-native Implementation Guidance ​

Tạo Dedicated Interconnect VLAN attachment với Cloud Router:

bash
# 1. Yêu cầu Dedicated Interconnect link (thực hiện qua Cloud Console)
# Sau khi có interconnect resource name, ví dụ: my-interconnect

# 2. Tạo VLAN attachment
gcloud compute interconnects attachments dedicated create vlan-attachment-1 \
  --region=us-central1 \
  --router=my-cloud-router \
  --interconnect=my-interconnect \
  --vlan=100 \
  --bandwidth=10g

# 3. Xem cấu hình BGP được generate
gcloud compute routers get-status my-cloud-router \
  --region=us-central1

# 4. Cấu hình BGP peer IP (169.254.x.x range)
gcloud compute routers update-bgp-peer my-cloud-router \
  --peer-name=attachment-1-peer \
  --peer-ip-address=169.254.1.2 \
  --region=us-central1

# Enable BFD cho fast failover
gcloud compute routers update-bgp-peer my-cloud-router \
  --peer-name=attachment-1-peer \
  --bfd-min-receive-interval=300 \
  --bfd-min-transmit-interval=300 \
  --bfd-multiplier=3 \
  --region=us-central1

Kiểm tra trạng thái attachment:

bash
gcloud compute interconnects attachments describe vlan-attachment-1 \
  --region=us-central1 \
  --format='value(state, operationalStatus)'

# Kỳ vọng: state=ACTIVE, operationalStatus=OS_ACTIVE

Cấu hình MACsec (sau khi có 100G/400G Interconnect):

bash
# Tạo MACsec key
gcloud compute interconnects macsec add-key my-interconnect \
  --key-name=macsec-key-1 \
  --start-time="2025-06-01T00:00:00Z"

# Enable MACsec
gcloud compute interconnects update my-interconnect \
  --enabled-macsec

References ​