My Awesome Project

Appearance

BGP trên GCP — Session được dựng và duy trì thế nào, failover nhanh tới đâu ​

Why this matters in production ​

BGP là giao thức duy nhất nối thế giới định tuyến động của GCP với on-prem. Nhưng phần lớn kỹ sư chỉ "biết BGP đủ để copy lệnh add-bgp-peer" mà không hiểu cơ chế bên dưới — và rồi gặp những sự cố mà không có hiểu biết đó thì không thể giải:

  • BGP session "stuck ở Connect/Active", không bao giờ lên Established. Vì sao?
  • Failover khi đứt cáp mất tới 60–180 giây thay vì vài giây như kỳ vọng. Tại sao chậm vậy, và làm sao nhanh hơn?
  • Session "flap" liên tục, route nhấp nháy. Nguyên nhân gốc ở đâu?
  • Bạn cần load-balance qua hai đường nhưng BGP chỉ chọn một. Multipath bật thế nào và điều kiện là gì?

Những câu hỏi này quy về các tham số và máy trạng thái của BGP: ASN, địa chỉ peering, timers, cơ chế phát hiện lỗi. File này mổ xẻ chính xác cách Cloud Router nói BGP, với các con số cụ thể, để bạn vừa thiết kế đúng vừa debug được.

Internal model — giải phẫu một BGP session của Cloud Router ​

ASN: ai là ai trong cuộc đối thoại ​

BGP định danh mỗi bên bằng Autonomous System Number (ASN). Trong một kết nối Cloud Router ↔ on-prem:

  • Phía Google (Cloud Router) dùng một ASN bạn gán khi tạo Cloud Router. Thường dùng 16-bit private ASN: 64512–65534. Cloud Router cũng hỗ trợ 32-bit private ASN: 4200000000–4294967294.
  • Phía on-prem (peer) dùng --peer-asn của riêng nó.

Vì cả hai phía dùng ASN khác nhau, đây là eBGP (external BGP). Lưu ý đặc thù GCP: một số ASN bị dành riêng và không được dùng cho Cloud Router (ví dụ các ASN công khai của Google như 16550, và một vài ASN reserved khác); luôn ưu tiên private ASN trừ khi có lý do rõ ràng. ASN của Cloud Router là thuộc tính của router, dùng chung cho mọi BGP session trên router đó.

BGP session chạy trên một cặp địa chỉ link-local trong dải 169.254.0.0/16. Mỗi BGP peering có một interface nhỏ (thường /30 hoặc /29), ví dụ:

Cloud Router BGP interface : 169.254.1.1
On-prem BGP peer IP        : 169.254.1.2
(cùng subnet link-local /30)

Các địa chỉ này không phải IP của workload; chúng chỉ là điểm cuối của phiên BGP, chạy bên trong tunnel VPN hoặc trên VLAN attachment của Interconnect. Với HA VPN, mỗi tunnel có cặp link-local riêng → một Cloud Router thường có nhiều cặp 169.254.x cho nhiều tunnel. Một lỗi cấu hình cực kỳ phổ biến: link-local hai phía không cùng subnet (ví dụ một bên 169.254.1.1/30, bên kia 169.254.2.2/30) → hai đầu không "nhìn thấy" nhau ở L3 → session không bao giờ Established.

BGP Finite State Machine: vì sao session "stuck" ​

Một BGP session đi qua máy trạng thái chuẩn (RFC 4271). Hiểu nó để chẩn đoán "stuck":

Idle ──► Connect ──► OpenSent ──► OpenConfirm ──► Established
  ▲         │                                          │
  └─────────┴── Active (thử lại TCP) ◄─────────────────┘ (lỗi → quay lại)
  • Idle: chưa khởi động / vừa reset.
  • Connect / Active: đang thử dựng TCP cổng 179. Nếu kẹt ở đây → vấn đề kết nối L3/L4: tunnel chưa up, link-local sai subnet, firewall chặn TCP 179 trên đường BGP, hoặc MTU làm rớt SYN. BGP chưa nói chuyện được.
  • OpenSent / OpenConfirm: TCP đã lên, đang trao đổi OPEN message (so khớp ASN, BGP identifier, timers, capabilities). Kẹt ở đây → bất khớp tham số: ASN không đúng (Cloud Router mong --peer-asn X nhưng on-prem gửi Y), capability mismatch, hoặc MD5 lệch.
  • Established: session lên; hai bên trao đổi UPDATE (route) và KEEPALIVE.

Bài học chẩn đoán: trạng thái session cho bạn biết tầng nào hỏng. Kẹt Connect/Active = lỗi mạng/L4 (tunnel, link-local, MTU, firewall 179). Kẹt OpenSent/OpenConfirm = lỗi tham số (ASN, MD5, capability). Established mà không có route = lỗi advertisement/import policy (file 05). Đừng debug "route không thấy" trước khi xác nhận session đã Established.

Keepalive & Hold timer: phát hiện "peer chết" bằng cách nào ​

Sau khi Established, hai bên gửi KEEPALIVE định kỳ để chứng minh "tôi còn sống". Hai timer điều khiển việc này:

  • Keepalive interval: tần suất gửi KEEPALIVE. Cloud Router mặc định 20 giây, có thể cấu hình 20–60 giây.
  • Hold time: nếu không nhận được KEEPALIVE/UPDATE nào trong khoảng này, peer bị coi là chết và session bị tear down (route bị rút). Theo chuẩn, hold time = 3 × keepalive → mặc định 60 giây (dải ~60–180s tùy keepalive).

Đây là chìa khóa hiểu vì sao failover qua BGP "trần" lại chậm: nếu cáp đứt đột ngột mà không có tín hiệu chủ động, BGP phải đợi hết hold time (tới ~60s, có thể 180s với cấu hình bảo thủ) mới nhận ra peer chết và rút route. Trong suốt cửa sổ đó, datapath vẫn forward về đường đã chết → blackhole 60–180 giây. Với nhiều SLA, đó là vĩnh cửu.

Giảm keepalive/hold có rút ngắn cửa sổ, nhưng có trần (keepalive tối thiểu 20s ⇒ hold tối thiểu ~60s) và làm session nhạy với jitter (dễ flap). Đây là lý do tồn tại BFD.

BFD: tách phát hiện lỗi ra khỏi nhịp BGP ​

Bidirectional Forwarding Detection (BFD) là cơ chế phát hiện đứt đường độc lập và nhanh hơn nhiều so với hold timer. Thay vì dựa vào KEEPALIVE mỗi 20s, BFD gửi gói "hello" siêu nhẹ ở tần suất mili-giây:

  • Transmit/receive interval: cấu hình ở thang mili-giây (ví dụ 1000ms mặc định, có thể nhỏ hơn xuống hàng trăm ms tùy hỗ trợ).
  • Multiplier: số gói liên tiếp bị mất trước khi tuyên bố đường chết (ví dụ 5).

Khi BFD phát hiện mất liên kết, nó lập tức báo cho BGP để rút route — không cần đợi hold timer. Kết quả: failover từ 60–180 giây (chỉ BGP) xuống còn dưới một giây (BFD). Theo best practices Cloud Router, Google khuyến nghị bật BFD cả hai phía (on-prem và Cloud Router) khi thiết bị on-prem hỗ trợ, chính vì lý do failover nhanh này.

Phát hiện đứt đường:
  Chỉ BGP hold timer:  ████████████████████  ~60–180s   (blackhole dài)
  Có BFD:              ▌                       <1s        (failover nhanh)

Lưu ý cơ chế: BFD chỉ phát hiện lỗi liên kết/đường đi. Nó không thay graceful restart (giải bài toán control-plane restart lành tính — file 03). BFD nói "rút nhanh khi đường chết"; graceful restart nói "đừng rút vội khi chỉ là control plane khởi động lại". Một thiết kế hybrid production-grade thường bật cả hai: BFD cho lỗi đường thật, graceful restart cho restart control-plane.

MD5 authentication: chống chiếm phiên ​

Mặc định BGP session không xác thực — bất kỳ ai chiếm được đường link-local đều có thể giả peer. Cloud Router hỗ trợ MD5 authentication: hai phía cấu hình cùng một secret, mọi BGP segment được ký MD5. Theo best practices, nên bật MD5 nếu peer hỗ trợ. Lưu ý vận hành: secret lệch giữa hai phía sẽ làm session không lên được (kẹt ở giai đoạn bắt tay TCP/OPEN tùy cách thiết bị triển khai) — một nguồn "stuck session" khó chịu nếu quên đồng bộ key.

MP-BGP & multipath: học IPv6 và load-balance ​

Cloud Router hỗ trợ MP-BGP (Multiprotocol BGP): một BGP session IPv4 có thể mang cả prefix IPv4 và IPv6 (và ngược lại). Theo tài liệu, các tổ hợp được hỗ trợ gồm session IPv4 chỉ IPv4, IPv6 chỉ IPv6, và IPv4/IPv6 session với MP-BGP mang cả hai address family. Điều này cho phép một session duy nhất quản lý cả hai stack thay vì dựng session riêng.

Về multipath/ECMP: khi nhiều BGP path tới cùng prefix có thuộc tính "tương đương" (cùng độ dài AS_PATH, cùng MED... dẫn tới cùng priority sau khi dịch sang VPC route), Cloud Router có thể program nhiều dynamic route cùng đích/priority → kích hoạt ECMP ở tầng VPC (file 02). Đây là cơ chế "load-balance qua nhiều tunnel": bạn advertise cùng prefix với cùng MED qua nhiều tunnel để chúng trở thành equal-cost. Nếu MED khác nhau, chỉ đường tốt nhất được dùng (active/passive) — đó cũng là cách bạn chủ động chọn active/standby (file 06).

Constraints, trade-offs & failure modes ​

Trần keepalive làm BGP "trần" không bao giờ đủ nhanh cho SLA cao ​

Vì keepalive tối thiểu 20s và hold ~60s, không thể đạt failover dưới giây nếu chỉ dựa vào timer BGP. Đây là ràng buộc cứng, và là lý do BFD gần như bắt buộc cho production có yêu cầu RTO thấp. Đừng cố "vặn timer thật nhỏ" — vừa chạm trần, vừa làm session flap vì nhạy jitter.

BFD đánh đổi độ nhạy lấy ổn định ​

BFD interval quá nhỏ trên một đường có jitter/loss sẽ tạo false positive: tuyên bố đường chết khi nó chỉ chậm, gây flap. Cân chỉnh interval × multiplier theo chất lượng thật của đường (VPN qua internet công cộng cần khoan dung hơn Dedicated Interconnect). BFD nhanh chỉ tốt khi đường ổn định đủ để không báo động giả.

MTU & fragmentation âm thầm giết BGP ​

BGP chạy trên TCP; nếu MTU end-to-end không khớp và packet bị phân mảnh/rớt, UPDATE message lớn có thể bị mất → session lên rồi flap khi trao đổi nhiều route, hoặc kẹt khi route table lớn. Triệu chứng: session Established với ít route thì ổn, nhưng "vỡ" khi số prefix tăng. HA VPN có MTU đặc thù (thường ~1460); on-prem phải khớp. Đây là failure mode kinh điển bị chẩn đoán nhầm thành "lỗi BGP" trong khi gốc là MTU.

Session flapping: vòng xoáy bất ổn ​

Session up/down liên tục gây rút/thêm route dồn dập → recompute + reprogram control plane liên tục (file 01) → mạng bất ổn. Nguyên nhân gốc thường là: loss/jitter trên tunnel (→ BFD hoặc keepalive timeout), MTU mismatch, hoặc cấu hình lệch. Cách xử lý đúng là truy nguyên gốc (chất lượng đường, MTU, tham số), không phải nới timer để "giấu" flap.

Anti-pattern: dựa vào hold timer cho failover ​

  • Vì sao xảy ra: BGP "tự" failover nên kỹ sư cho rằng nó nhanh; bỏ qua việc cơ chế phát hiện mặc định là hold timer ~60–180s.
  • Hệ quả ở scale: mỗi sự cố đứt đường gây blackhole tới vài phút; SLA bị phá; người dùng thấy timeout hàng loạt dù "BGP rồi sẽ tự chuyển".
  • Cách tư duy đúng: failover nhanh = BFD (phát hiện đường chết sub-giây) + route dư thừa sẵn sàng (multipath hoặc standby với MED) đã được program từ trước để Andromeda chuyển ngay khi route chính bị rút. Hold timer là lưới an toàn cuối, không phải cơ chế failover chính.

GCP-native implementation guidance ​

bash
# Thêm BGP peer với BFD bật để failover nhanh
gcloud compute routers add-bgp-peer cr-us-central1 \
  --peer-name=peer-onprem-a \
  --interface=if-tunnel-a \
  --peer-asn=65001 \
  --region=us-central1 \
  --bfd-session-initialization-mode=ACTIVE \
  --bfd-min-transmit-interval=1000 \
  --bfd-min-receive-interval=1000 \
  --bfd-multiplier=5

# Bật MD5 cho session (đồng bộ secret hai phía!)
gcloud compute routers update-bgp-peer cr-us-central1 \
  --peer-name=peer-onprem-a --region=us-central1 \
  --md5-authentication-key-name=key1 \
  --md5-authentication-key="<shared-secret>"

# Kiểm tra trạng thái FSM + BFD của từng peer
gcloud compute routers get-status cr-us-central1 --region=us-central1 \
  --format="table(result.bgpPeerStatus[].name,
                  result.bgpPeerStatus[].state,
                  result.bgpPeerStatus[].bfdStatus.localState,
                  result.bgpPeerStatus[].numLearnedRoutes)"

Khi session "stuck", đọc state: chưa Established thì đừng đụng tới advertisement/import — vấn đề nằm ở tunnel/link-local/MTU/ASN/MD5 theo đúng phân tầng FSM ở trên.

Tóm tắt mental model ​

  • Cloud Router nói eBGP với ASN private (16-bit 64512–65534 hoặc 32-bit), trên link-local 169.254.0.0/16 bên trong tunnel/attachment.
  • FSM cho biết tầng hỏng: Connect/Active = L3/L4 (tunnel, link-local, MTU, firewall 179); OpenSent/Confirm = tham số (ASN, MD5); Established-no-route = advertisement/import.
  • Phát hiện peer chết mặc định dựa hold timer ~60–180s ⇒ failover BGP trần chậm. BFD kéo xuống sub-giây.
  • BFD ≠ graceful restart: BFD "rút nhanh khi đường chết", graceful restart "đừng rút vội khi control plane restart". Production thường bật cả hai.
  • MD5 chống giả peer (mặc định tắt). MP-BGP mang cả IPv4/IPv6 trên một session. Multipath (cùng MED) → ECMP.
  • MTU mismatch là sát thủ thầm lặng của BGP; flap = truy gốc (đường/MTU/tham số), không nới timer.

References ​