Production Patterns & Monitoring — Hybrid Connectivity

Tại sao quan trọng trong production

Thiết kế hybrid connectivity không dừng lại ở việc tạo tunnel hay attachment. Điều quyết định reliability thực sự là failover behavior (traffic reroute đúng khi có failure không?) và observability (bạn biết trước khi user bị ảnh hưởng không?).

Hai failure modes phổ biến nhất mà teams gặp trong production:

1. Failover không xảy ra hoặc mất quá lâu — vì BGP hold timer chưa expire, BFD không được bật, hoặc routes không được cấu hình đúng để allow failover.
2. Monitoring bỏ sót early warning — BGP session flap không được alert, packet loss tích lũy nhỏ không được detect cho đến khi application-level impact đã xảy ra.

Chương này tập trung vào cơ chế của hai khía cạnh này.

---

Active-Passive vs Active-Active — Cơ Chế Failover

Active-Active — Cả Hai Paths Forward Traffic

Trong active-active, tất cả tunnels/connections đều up và forward traffic đồng thời. Cloud Router sử dụng ECMP để phân phối traffic.

Cơ chế: Cloud Router advertise prefix với cùng MED (Multi-Exit Discriminator) và priority trên tất cả BGP sessions. On-premises router nhận routes với cost tương đương và ECMP distribute outbound traffic. GCP side cũng ECMP trên multiple VLAN attachments/tunnels.

[On-premises Router]
    |           |
    |           |
 [Tunnel 0]  [Tunnel 1]    ← cả hai active, ECMP distribute traffic
    |           |
[Interface 0] [Interface 1]
    \           /
    [HA VPN Gateway]
           |
       [Cloud Router]
           |
       [VPC routes]

Failover trong active-active:

• Khi Tunnel 0 fail → BGP session trên Tunnel 0 mất → Cloud Router withdraw routes learned qua Tunnel 0 → on-premises router remove routes qua Tunnel 0 → traffic tự động shift sang Tunnel 1.
• Từ GCP side: Cloud Router detect tunnel down, ECMP table update, traffic chỉ forward qua Tunnel 1.
• Thời gian failover: với BFD, dưới 1 giây. Không có BFD: BGP hold timer (60 giây mặc định).

Advantage của active-active: Không có wasted capacity. Bandwidth aggregate được dùng cho normal operation, không chỉ khi có failure.

Disadvantage: Asymmetric routing có thể xảy ra nếu on-premises router chọn path khác với GCP. Điều này thường không phải vấn đề, nhưng với stateful firewall on-premises, asymmetric routing (inbound qua Tunnel 0, outbound qua Tunnel 1) có thể break connection tracking.

Active-Passive — Một Path Primary, Một Path Standby

Trong active-passive, chỉ primary tunnel/connection forward traffic. Standby tunnel được maintain nhưng không forward traffic dưới điều kiện bình thường.

Cơ chế implement: BGP routing dùng MED (Multi-Exit Discriminator) hoặc AS Path prepending để signal preference:

• MED: Cloud Router advertise primary routes với MED thấp hơn (preferred), standby routes với MED cao hơn. On-premises router ưu tiên path có MED thấp hơn.
• AS Path prepending: Tăng length của AS Path trên standby advertisement để giảm preference.
• Local Preference (từ on-premises router): Set local-preference cao hơn cho primary path.

Ví dụ với custom route advertisement từ Cloud Router:

# Advertise primary routes qua Tunnel 0 với MED 100 (lower = preferred)
gcloud compute routers update-bgp-peer my-router \
  --peer-name=tunnel-0-peer \
  --advertise-mode=CUSTOM \
  --advertised-route-priority=100 \
  --region=us-central1

# Advertise standby routes qua Tunnel 1 với MED 200 (higher = less preferred)
gcloud compute routers update-bgp-peer my-router \
  --peer-name=tunnel-1-peer \
  --advertise-mode=CUSTOM \
  --advertised-route-priority=200 \
  --region=us-central1

Failover trong active-passive:

• Khi primary tunnel fail → BGP session mất → routes via primary withdrawn → on-premises router và GCP switch sang standby path.
• Với BFD: failover trong vài trăm milliseconds.
• Không có BFD: BGP hold timer expiry (60 giây), sau đó convergence.

Khi nào chọn active-passive:

• Khi primary path có higher bandwidth và muốn đảm bảo traffic chỉ dùng primary trong bình thường (ví dụ: 100G Interconnect primary, HA VPN 1G secondary).
• Khi muốn đơn giản hóa traffic flow để easier debugging.
• Khi cost của standby path là thấp (HA VPN tunnel không tốn tiền khi không có data flow qua).

---

BFD — Fast Failure Detection

BFD (Bidirectional Forwarding Detection) là giao thức detection failure nhanh chạy độc lập với BGP. Trong khi BGP hold timer mặc định là 60 giây, BFD có thể detect failure trong 300–1000 milliseconds.

Cơ chế: Hai router liên tục gửi BFD hello packets với interval rất nhỏ. Nếu một bên không nhận được hello trong timeout (interval × multiplier), nó tuyên bố neighbor down và notify BGP để remove routes.

Cấu hình điển hình:

• min-receive-interval: 300ms
• min-transmit-interval: 300ms
• multiplier: 3

Timeout = 300ms × 3 = 900ms. Failure detected trong dưới 1 giây.

BFD trên Cloud VPN và Cloud Interconnect phải được bật explicitly. Nó không tự động bật theo mặc định vì có overhead. Trong production hybrid connectivity với redundancy requirements, BFD là bắt buộc — không phải tùy chọn.

Chú ý: BFD chạy qua tunnel (đối với HA VPN) hoặc qua VLAN attachment (đối với Interconnect). Nếu physical link down nhưng BFD packets vẫn đến (ví dụ qua một path khác), BFD sẽ không trigger failover. BFD detect forwarding plane failure, không phải routing failure.

---

Failover trong Thực Tế: Sequence of Events

Khi một hybrid connection fail, đây là sequence events xảy ra:

Với BFD:

T=0ms    Physical failure hoặc tunnel drop
T=~300ms BFD detect failure (hello miss)
T=~300ms BFD notify BGP session
T=~301ms BGP session torn down
T=~301ms BGP withdraw routes
T=~500ms Cloud Router re-program VPC routes
T=~500ms Traffic shift sang backup path

Không có BFD:

T=0ms    Physical failure
T=0ms    (Không có fast detection)
T=60,000ms BGP hold timer expire
T=60,001ms BGP session torn down
T=60,001ms BGP withdraw routes
T=60,500ms Traffic shift sang backup path

Difference: 500ms vs 60,500ms. Với tính toán 99.99% availability (khoảng 52 phút downtime/năm), một failure event 60 giây đã là significant. Vì vậy BFD là yếu tố kỹ thuật quan trọng, không phải nice-to-have.

Traffic đang in-flight: Trong thời gian failover (dù chỉ 500ms), TCP connections có thể timeout tùy vào application timeout settings. UDP traffic bị drop không có retransmit. Application cần implement retry logic phù hợp với expected failover time.

---

Monitoring — Observability cho Hybrid Connectivity

Metrics cần track cho Cloud VPN

1. Tunnel health metrics (Cloud Monitoring):

vpn.googleapis.com/gateway/connections

Metric này tracking số lượng active tunnels. Giá trị giảm từ 2 xuống 1 (HA VPN) là signal immediate của tunnel failure. Set alert cho < expected tunnel count.

vpn.googleapis.com/network/received_bytes_count
vpn.googleapis.com/network/sent_bytes_count

Bytes through/seconds. Bình thường nên thấy traffic trên cả hai tunnels (active-active). Nếu một tunnel có 0 bytes trong 5 phút trong giờ high-traffic, đó là indicator có vấn đề.

2. Packet loss metrics:

vpn.googleapis.com/tunnel/dropped_sent_packets_count
vpn.googleapis.com/tunnel/dropped_received_packets_count

Drop rate nonzero cho thấy: congestion, MTU mismatch, hoặc replay protection triggering (out-of-order packets ngoài window 4096).

3. BGP session state (qua Cloud Router metrics):

router.googleapis.com/bgp/sessions_count
router.googleapis.com/bgp/received_routes_count

BGP session count drop hoặc received routes count về 0 là critical signal.

Metrics cần track cho Cloud Interconnect

1. Operational status của VLAN attachment:

interconnect.googleapis.com/network/attachment/received_bytes_count
interconnect.googleapis.com/network/attachment/sent_bytes_count
interconnect.googleapis.com/network/attachment/capacity

Ratio received_bytes / capacity cho thấy utilization. Nếu consistently >80%, cần tăng capacity.

2. Physical link status (cho Dedicated Interconnect):

interconnect.googleapis.com/link/rx_power_level
interconnect.googleapis.com/link/tx_power_level

Optical power levels cho physical fiber. Degradation trong optical power là early warning của fiber issues trước khi link down hoàn toàn. Thường thấy optical power giảm dần trước khi bit error rate tăng.

3. Bit error rate:

interconnect.googleapis.com/link/bit_errors
interconnect.googleapis.com/link/raw_ber

BER (Bit Error Rate) tăng là dấu hiệu của physical layer degradation — fiber bend, connector bị bẩn, optical amplifier issue trong colocation.

BGP Session Monitoring — Phát Hiện Instability

BGP session flap (session up → down → up liên tục) là vấn đề tinh vi. Nếu session flap trong 10 giây và recover, application có thể không bị ảnh hưởng — nhưng routing table đã bị disrupted tạm thời.

Metric để track BGP stability:

router.googleapis.com/bgp/sent_routes_count
router.googleapis.com/bgp/received_routes_count

Nếu hai metrics này drop về 0 rồi recover trong vòng minutes, đó là BGP session flap. Cần investigate physical layer và BFD configuration.

Alert pattern cho BGP instability:

# Cloud Monitoring Alerting Policy
alertPolicy:
  conditions:
  - conditionThreshold:
      filter: 'resource.type="vpn_gateway" AND metric.type="vpn.googleapis.com/tunnel/dropped_sent_packets_count"'
      comparison: COMPARISON_GT
      thresholdValue: 0
      duration: 60s
      aggregations:
      - alignmentPeriod: 60s
        perSeriesAligner: ALIGN_RATE

End-to-End Latency Monitoring

Metrics của Cloud Monitoring chỉ đo đến/từ Google's edge. Để có visibility về end-to-end latency (bao gồm on-premises network), cần synthetic monitoring:

Option 1: ICMP ping từ VM trong GCP đến on-premises endpoint

Tạo một scheduled monitoring VM chạy ping đến on-premises IPs định kỳ, export results vào Cloud Monitoring qua custom metrics.

Option 2: TCP probe

TCP connection probe đến một port trên on-premises server, measure connection time. Reliable hơn ICMP vì firewall ít block TCP hơn ICMP.

Option 3: Network Intelligence Center — Connectivity Tests

Cloud Console cung cấp Connectivity Tests: chạy simulated packet forwarding simulation qua network topology để verify reachability và diagnose routing issues. Không measure actual latency nhưng verify routing configuration.

---

Operational Runbook

Khi nào tunnel/attachment down

1. Check BGP session status:
   gcloud compute routers get-status <router-name> --region=<region>
   → Xem: bgpPeerStatus[].status (UP/DOWN)

2. Nếu BGP DOWN, check tunnel status:
   gcloud compute vpn-tunnels describe <tunnel-name> --region=<region>
   → Xem: detailedStatus, status

3. Nếu tunnel ESTABLISHED nhưng BGP DOWN:
   → Check IKE negotiation: xem Cloud Logging cho VPN tunnel events
   → Check BGP config: IP ranges, ASN, authentication

4. Nếu tunnel DOWN:
   → Check peer gateway reachability (UDP 500, UDP 4500 từ Cloud VPN external IP)
   → Check IKE logs ở peer router
   → Check pre-shared key match

5. Verify failover đã xảy ra:
   → Check traffic metrics trên backup tunnel/attachment
   → Từ on-premises: traceroute đến GCP VM, verify path qua backup

Khi nào có packet loss

1. Identify scope: loss trên tất cả traffic hay một subset?
   → Loss trên large packets → MTU issue
   → Loss uniform → congestion hoặc physical issue

2. Kiểm tra MTU:
   ping -M do -s 1400 <gcp-vm-ip>  # từ on-premises
   → Nếu fail, giảm packet size cho đến khi pass
   → Compute expected payload MTU dựa trên cipher suite

3. Kiểm tra optical power (Interconnect):
   gcloud compute interconnects get-diagnostics <interconnect-name>
   → Xem: bundleAggregationType, links[].operationalStatus

4. Kiểm tra congestion:
   → Compare actual throughput vs attachment capacity
   → Xem dropped_sent_packets_count metric

5. Check replay protection:
   → BER cao hoặc out-of-order packets có thể trigger replay protection
   → Look for pattern: loss correlates with high-speed bursts

Khi nào BGP flapping

1. Identify frequency:
   → Xem router.googleapis.com/bgp/sessions_count qua thời gian
   → Detect drops về 0

2. Correlate với physical events:
   → Check interconnect link optical metrics
   → Check VPN tunnel detailedStatus trong Cloud Logging

3. Check BFD configuration:
   → Verify BFD bật trên Cloud Router: gcloud compute routers get-status
   → Verify BFD bật trên on-premises router
   → BFD thresholds quá aggressive có thể gây false flap

4. Check BGP timers:
   → Hold timer quá thấp + high-latency path = false BGP timeout
   → Default: keepalive 20s, hold 60s — thường đủ

5. Hardware investigation:
   → Nếu flap correlates với traffic bursts: possible buffer overflow ở physical layer
   → Liên hệ Google support nếu Interconnect physical issue

---

Anti-patterns Phổ Biến

1. Dùng BGP hold timer thay vì BFD

Nhiều team deploy HA VPN với active-passive mà không bật BFD, rồi set hold timer rất thấp (ví dụ: 15 giây) để có "fast failover". Vấn đề: hold timer thấp + high-latency link = false BGP timeout khi không có failure thực sự. BGP keepalive phải arrive trong hold timer — nếu latency spike, keepalive bị delay, BGP kết thúc session không cần thiết.

BFD được thiết kế đặc biệt cho fast failure detection với lightweight hello mechanism. Dùng BFD + default hold timer là approach đúng.

2. Active-passive với primary path tắt BGP

Một số team implement active-passive bằng cách tắt BGP trên standby tunnel trong điều kiện bình thường. Khi primary fail, manually enable BGP trên standby. Đây là anti-pattern nghiêm trọng:

• Failover không automatic — cần manual intervention.
• Standby path không được monitor.
• Không biết standby path có hoạt động không cho đến khi cần đến nó.

Đúng: Cả primary và standby đều UP và BGP ESTABLISHED, chỉ khác nhau ở MED/priority.

3. Không configure ECMP load balancing

Với active-active và multiple VLAN attachments, bandwidth aggregate chỉ được dùng nếu Cloud Router biết distribute traffic. Nếu chỉ configure một attachment trong BGP và để attachment kia như "failover only", bạn đang để 50% capacity waste.

Cloud Router dùng ECMP by default khi cùng prefix được học qua nhiều paths với cùng priority. Không cần cấu hình gì thêm — chỉ cần đảm bảo cả hai attachments đều trong BGP session với cùng route priority.

4. Overlook optical degradation signals

Với Dedicated Interconnect, optical power metrics là early warning system tốt nhất. Fiber degradation không xảy ra tức thì — optical power giảm dần trong nhiều giờ/ngày trước khi link down hoàn toàn. Team không monitor optical metrics sẽ bị surprise bởi outage. Team monitor optical metrics sẽ có cơ hội schedule maintenance trước khi outage.

---

References

• HA VPN Topologies
• Cloud Router BFD
• Cloud Interconnect Monitoring
• Cloud VPN Monitoring
• Network Intelligence Center Connectivity Tests
• Cloud Interconnect Diagnostics