My Awesome Project

Appearance

BGP Session Internals — Cơ Chế Thiết Lập Và Duy Trì Session ​

Tại Sao Quan Trọng Trong Production ​

BGP session failure là nguồn gốc của phần lớn các sự cố hybrid connectivity. Tuy nhiên, lý do BGP fail thường bị chẩn đoán sai vì người vận hành không có mental model chính xác về cách session được thiết lập và duy trì.

"BGP không lên được" có thể do ASN không khớp, do BGP identifier trùng, do hold time negotiation fail, do MD5 password sai, hoặc đơn giản là do TCP port 179 bị firewall block. Mỗi nguyên nhân biểu hiện ở một state khác nhau trong BGP Finite State Machine. Hiểu FSM nghĩa là bạn có thể nhìn vào trạng thái session và khoanh vùng vấn đề mà không cần đoán mò.

Ngoài ra, trong bối cảnh GCP có một số đặc thù quan trọng: Cloud Router chỉ chạy eBGP, không chạy iBGP; GCP dùng link-local addresses thay vì routable IP cho BGP peering; và có những giới hạn rõ ràng về ASN mà bạn cần biết trước khi cấu hình.

BGP Finite State Machine (FSM) ​

BGP là một giao thức dựa trên trạng thái. Mỗi BGP session đi qua một chuỗi trạng thái được định nghĩa rõ ràng trong RFC 4271. Hiểu các trạng thái này là điều kiện tiên quyết để debug "tại sao BGP không lên".

6 Trạng Thái BGP FSM ​

1. IDLE

Trạng thái ban đầu. BGP speaker chưa cố kết nối với peer. Có thể ở IDLE vì:

  • Mới khởi tạo, chưa có trigger để connect
  • Sau một lỗi, BGP đang chờ timer hết (ConnectRetry timer) trước khi thử lại
  • Cấu hình peer chưa được kích hoạt

Khi trigger (thường là manual hoặc system startup), BGP chuyển sang CONNECT.

2. CONNECT

BGP đang cố thiết lập TCP connection đến peer (TCP port 179). Ở trạng thái này:

  • TCP SYN được gửi đến BGP peer IP
  • Nếu TCP kết nối thành công → chuyển sang OPENSENT
  • Nếu TCP fail (timeout, reset) → chuyển sang ACTIVE

Nếu BGP bị mắc kẹt ở CONNECT trong thời gian dài, nguyên nhân thường là:

  • Firewall block TCP 179 (inbound hoặc outbound)
  • BGP peer IP không reachable (route không có)
  • On-prem router chưa được cấu hình để nhận connection

3. ACTIVE

BGP đang actively cố gắng kết nối nhưng chưa thành công. Tên "ACTIVE" có phần misleading — state này thực ra là state của nỗ lực kết nối đang xảy ra, không phải "BGP đang hoạt động".

BGP ở ACTIVE nghĩa là TCP connection chưa được thiết lập. Nó sẽ tiếp tục retry theo ConnectRetry timer (thường 120 giây). Nếu nhận được TCP connection từ phía peer trong khi ở ACTIVE, BGP sẽ chấp nhận và chuyển sang OPENSENT.

Nếu BGP bị mắc kẹt ở ACTIVE và luân phiên giữa ACTIVE và CONNECT, nguyên nhân phổ biến là:

  • BGP peering IP không khớp (cấu hình ở GCP khác với cấu hình ở on-prem)
  • Firewall cho phép outbound TCP 179 nhưng không cho phép inbound
  • On-prem router đang cố kết nối đến IP khác với GCP đang listen

4. OPENSENT

TCP connection đã được thiết lập. BGP đã gửi OPEN message và đang chờ OPEN message từ phía peer. Ở trạng thái này, BGP đang negotiate các parameters:

  • BGP version (phải là 4)
  • ASN (Autonomous System Number)
  • Hold time
  • BGP Identifier (thường là router ID, một IPv4 address duy nhất)
  • Optional capabilities (như MP-BGP cho IPv6)

Nếu có vấn đề với OPEN message, BGP sẽ gửi NOTIFICATION message và quay về IDLE. Các lỗi phổ biến ở OPENSENT:

  • Unsupported version: một bên không hỗ trợ BGP version 4 (rất hiếm ngày nay)
  • Bad peer AS: ASN trong OPEN message không khớp với ASN được cấu hình
  • Bad BGP Identifier: Router ID không hợp lệ hoặc bằng 0

5. OPENCONFIRM

Cả hai bên đã nhận OPEN message của nhau và parameters đã được chấp nhận. Bây giờ mỗi bên gửi KEEPALIVE để xác nhận. BGP đang chờ KEEPALIVE từ peer.

Nếu vấn đề xảy ra ở đây:

  • MD5 authentication failure (nếu được cấu hình): NOTIFICATION với error code "BGP Authentication Failure"
  • Hold time đã negotiated quá ngắn và expire trước khi KEEPALIVE đến

6. ESTABLISHED

Trạng thái "bình thường" — BGP session đang hoạt động. Cả hai bên đã trao đổi routes qua UPDATE messages và đang gửi KEEPALIVE định kỳ để duy trì session.

Nếu KEEPALIVE không đến trong vòng Hold Time (mặc định 180 giây trên GCP), session chuyển về IDLE và toàn bộ routes từ peer đó bị withdraw.

Nội Dung Các BGP Messages ​

OPEN Message ​

OPEN là message đầu tiên được gửi sau khi TCP connection được thiết lập. Nó chứa:

BGP OPEN Message:
├── Version: 4 (bắt buộc, BGP version 4)
├── My Autonomous System: <ASN của sender>
├── Hold Time: <giây> (minimum hold time mong muốn)
├── BGP Identifier: <IPv4 address duy nhất, thường router ID>
└── Optional Parameters:
    ├── Capability: Multiprotocol Extensions (RFC 4760)
    │   └── AFI/SAFI: IPv4 Unicast, IPv6 Unicast, etc.
    ├── Capability: Route Refresh (RFC 2918)
    └── Capability: 4-byte AS Numbers (RFC 6793)

Hold Time negotiation: Mỗi bên đề xuất Hold Time của mình trong OPEN. Giá trị thấp hơn được chọn (minimum). Nếu một bên đề xuất 0, hold timer bị disable (không KEEPALIVE, session không expire theo hold time — hiếm dùng). Cloud Router mặc định đề xuất Hold Time 60 giây, dẫn đến Hold Time thực tế là 60 giây nếu peer cũng đề xuất ≥60s.

BGP Identifier: Là một IPv4 address được dùng làm định danh duy nhất của BGP speaker trong AS. Với Cloud Router, Google tự động gán BGP Identifier, không cần cấu hình thủ công.

KEEPALIVE Message ​

Message đơn giản nhất — chỉ có BGP header, không có payload. Được gửi định kỳ (mặc định mỗi 20 giây khi Hold Time là 60 giây — tức 1/3 Hold Time). Mục đích duy nhất: duy trì session không expire.

Tại sao Hold Time quan trọng trong production: Nếu on-prem network có packet loss intermittent, KEEPALIVE có thể bị drop. Nếu Hold Time quá ngắn (ví dụ 30 giây, KEEPALIVE mỗi 10 giây), ba KEEPALIVE bị drop liên tiếp là BGP session reset. Nếu Hold Time quá dài (ví dụ 240 giây), failure detection chậm — bạn phải chờ đến 240 giây trước khi BGP failover. BFD giải quyết vấn đề này bằng cách cung cấp fast failure detection song song với hold timer.

UPDATE Message ​

Là message quan trọng nhất — nó mang thông tin route. Một UPDATE message có thể:

  • Advertise một hoặc nhiều routes mới
  • Withdraw một hoặc nhiều routes đã advertise trước đó
  • Hoặc cả hai cùng lúc

Cấu trúc UPDATE:

BGP UPDATE Message:
├── Withdrawn Routes Length: <bytes>
├── Withdrawn Routes: danh sách prefix bị withdraw (NLRI format)
├── Total Path Attribute Length: <bytes>
├── Path Attributes:
│   ├── ORIGIN: IGP / EGP / INCOMPLETE
│   ├── AS_PATH: chuỗi ASNs route đi qua (eBGP)
│   ├── NEXT_HOP: next-hop IP address
│   ├── MULTI_EXIT_DISC (MED): optional metric
│   ├── LOCAL_PREF: iBGP preference (không dùng trong eBGP)
│   ├── COMMUNITIES: optional tagging
│   └── MP_REACH_NLRI / MP_UNREACH_NLRI: cho IPv6 (MP-BGP)
└── Network Layer Reachability Information (NLRI):
    └── danh sách prefix được advertise (cho IPv4 unicast)

ORIGIN attribute:

  • IGP: Route originate từ IGP (OSPF, IS-IS) trong AS
  • EGP: Route học qua EGP cổ (obsolete)
  • INCOMPLETE: Route học từ redistribution hoặc static (Cloud Router dùng INCOMPLETE cho custom learned routes)

AS_PATH: Danh sách ASNs route đã đi qua. Trong eBGP, mỗi khi route đi qua một AS, AS đó được prepend vào AS_PATH. AS_PATH dùng để ngăn loop (nếu thấy ASN của mình trong AS_PATH → loop → drop route) và là một trong các tiêu chí best-path selection.

eBGP Trong Bối Cảnh GCP ​

Tại Sao Chỉ Có eBGP ​

Cloud Router chỉ chạy eBGP (external BGP) — tức là BGP sessions được thiết lập giữa các Autonomous Systems khác nhau (GCP VPC và on-prem network). Cloud Router không chạy iBGP (internal BGP) với các Cloud Router khác trong cùng VPC.

Sự khác biệt giữa eBGP và iBGP:

Đặc điểmeBGPiBGP
Phạm viGiữa các AS khác nhauTrong cùng một AS
AS_PATHĐược modified (AS prepend)Không được modified
NEXT_HOPĐặt thành interface IP của speakerKhông thay đổi (iBGP next-hop preservation)
LOCAL_PREFKhông áp dụngÁp dụng để chọn exit point
TTL1 (adjacent hop chỉ)255
Loop preventionAS_PATH loop detectionFull mesh hoặc Route Reflector

Tại sao GCP không dùng iBGP giữa các Cloud Routers: Để route từ Cloud Router region A đến Cloud Router region B propagate, không cần iBGP vì VPC control plane đã xử lý việc này. Khi Cloud Router A học một route từ on-prem peer, nó lập trình route đó vào dynamic route control plane, VPC network control plane sau đó quyết định (dựa trên routing mode) có phân phối route này đến region B không. Đây là thiết kế có chủ đích — tách BGP protocol khỏi inter-region routing.

Hệ quả quan trọng: Nếu bạn tạo hai Cloud Routers với cùng ASN trong cùng VPC, họ không tự động thấy routes của nhau qua iBGP. Route exchange giữa chúng đi qua VPC control plane, không phải BGP.

eBGP Multi-hop Và TTL ​

Theo RFC 4271, eBGP mặc định dùng TTL=1, nghĩa là chỉ kết nối được với BGP peer ở directly adjacent hop. Trong bối cảnh GCP:

  • HA VPN: BGP session thiết lập qua VPN tunnel. Peer IP là link-local address ở phía bên kia tunnel — effectively adjacent hop, TTL=1 là đủ.
  • Dedicated Interconnect: BGP session thiết lập qua VLAN attachment. Lại là adjacent hop.
  • Router Appliance: BGP session từ Cloud Router đến Router Appliance VM — trong cùng VPC, adjacent hop.

Trong tất cả các trường hợp GCP hỗ trợ, BGP peer luôn ở adjacent hop, nên eBGP single-hop là đủ và không cần eBGP multi-hop.

Theo tài liệu chính thức: "BGP sessions for the following products use IPv4 link-local addresses in the 169.254.0.0/16 range as BGP peering addresses" — áp dụng cho Dedicated Interconnect, Partner Interconnect, và HA VPN.

Link-local addresses (169.254.0.0/16) là dải địa chỉ chỉ valid trong phạm vi một network segment (không được route qua routers). Chúng thuộc về việc dùng làm BGP peering vì:

  1. Không cần phân bổ IP routable: Bạn không cần tiêu tốn IP range quý giá từ VPC subnet hay on-prem network chỉ để làm BGP peering. Link-local tự động available mà không cần allocate.

  2. Rõ ràng về phạm vi: Cả hai bên của tunnel/attachment biết rằng các địa chỉ này chỉ valid cho BGP peering, không phải cho data traffic.

  3. Tránh conflict: Không xung đột với bất kỳ subnet nào trong on-prem hay VPC.

Cách hoạt động:

Khi tạo HA VPN tunnel hoặc Interconnect VLAN attachment, GCP tự động assign một cặp link-local addresses (ví dụ 169.254.0.1/30 và 169.254.0.2/30 hoặc bạn có thể tự chọn trong dải 169.254.0.0/16). Hai địa chỉ này là BGP peering endpoints:

  • 169.254.0.1 — địa chỉ của Cloud Router BGP interface
  • 169.254.0.2 — địa chỉ peer phía on-prem/partner

BGP OPEN message dùng các địa chỉ này làm nguồn, và NEXT_HOP trong UPDATE messages là các link-local addresses.

Với IPv6: HA VPN hỗ trợ dùng IPv6 Unique Local Addresses (ULA) trong dải fdff:1::/64 với mask /126 hoặc nhỏ hơn.

BGP Session Types ​

Cloud Router hỗ trợ nhiều loại session để xử lý cả IPv4 và IPv6 traffic:

  • IPv4 session: Chỉ trao đổi IPv4 prefixes
  • IPv6 session: Chỉ trao đổi IPv6 prefixes
  • IPv4 session với MP-BGP: Trao đổi cả IPv4 và IPv6 prefixes qua một session
  • IPv6 session với MP-BGP: Trao đổi cả IPv4 và IPv6 prefixes qua một session

Hai session (một IPv4, một IPv6) có thể chạy đồng thời trên cùng một HA VPN tunnel hoặc Dedicated Interconnect VLAN attachment. Đây là cơ chế để hỗ trợ dual-stack hybrid connectivity.

ASN Configuration ​

Autonomous System Number (ASN) ​

ASN là số định danh duy nhất của một Autonomous System — một tập hợp các routers dưới cùng một administrative control với chính sách routing thống nhất. Trong bối cảnh GCP:

  • GCP side ASN: ASN mà Cloud Router sử dụng để identify bản thân trong BGP sessions. Bạn chọn ASN này khi tạo Cloud Router.
  • Peer ASN: ASN của on-prem router, đối tác Interconnect, hay Router Appliance. Bạn cấu hình peer ASN khi tạo BGP session.

Một Cloud Router dùng cùng ASN cho tất cả BGP sessions của nó. Không thể có per-session ASN trên Cloud Router.

Private vs Public ASN ​

ASN 2-byte (16-bit): Range 1–65535

  • Public ASN: 1–64511 — được IANA phân bổ, cần đăng ký
  • Private ASN: 64512–65534 — tương tự private IP, dùng nội bộ, không route trên internet
  • Reserved: 65535

ASN 4-byte (32-bit): Range 1–4294967295 (RFC 6793)

  • Private ASN 4-byte: 4200000000–4294967294
  • Cloud Router hỗ trợ cả 2-byte và 4-byte ASN

Trong production hybrid connectivity: Nếu bạn không có public ASN, dùng private ASN. Dải phổ biến nhất là 64512–65534. Google tự sử dụng public ASN cho infrastructure của họ; bạn không cần quan tâm đến điều đó.

ASN Conflict Và Các Vấn Đề Phổ Biến ​

Vấn đề 1: Cùng ASN ở hai bên BGP session

Nếu Cloud Router có ASN 65000 và on-prem router cũng có ASN 65000, BGP sẽ từ chối kết nối. Lý do: eBGP thiết kế để kết nối các AS khác nhau — nếu hai bên có cùng ASN, nó trông giống iBGP nhưng không được xử lý đúng như iBGP.

Cách phát hiện: BGP session ở OPENSENT/OPENCONFIRM state, sau đó nhận NOTIFICATION với error code "Bad Peer AS".

Vấn đề 2: AS_PATH loop

Nếu route từ on-prem advertise đến Cloud Router, và vì lý do nào đó route đó được re-advertise ngược lại on-prem (hiếm xảy ra với Cloud Router mặc định nhưng có thể xảy ra với Network Connectivity Center), BGP sẽ detect AS_PATH loop và drop route. Đây là cơ chế bảo vệ chứ không phải lỗi.

Vấn đề 3: Hai Cloud Routers với cùng ASN trong cùng VPC

Điều này được phép và thực ra phổ biến — ví dụ khi bạn muốn cùng AS appear từ nhiều regions. Nhưng như đã đề cập, hai Cloud Routers với cùng ASN không tạo iBGP session với nhau. Routes exchange qua VPC control plane.

Vấn đề 4: ASN conflict với partner/on-prem

Nếu dùng Partner Interconnect, partner có ASN riêng. Nếu ASN bạn chọn trùng với ASN của partner's BGP infrastructure, có thể gây ra AS_PATH loop. Luôn confirm ASN với partner trước khi configure.

Hold Timer và Keepalive — Cân Bằng Reliability và Detection Speed ​

Mặc Định Trong Cloud Router ​

Theo tài liệu GCP:

  • Hold time mặc định: 60 giây (negotiated với peer)
  • Keepalive interval: 20 giây (1/3 của Hold Time)

Hold Time 60 giây nghĩa là nếu không nhận được KEEPALIVE trong 60 giây, BGP session bị coi là dead và bị terminate. Đây là con số nhỏ hơn so với BGP default tiêu chuẩn (180 giây), nhưng vẫn là lâu trong nhiều production scenarios.

Tuning Hold Timer ​

Trong production, việc tune hold timer phụ thuộc vào tradeoff:

Hold timer nhỏ hơn:

  • Detect failure nhanh hơn
  • Nhưng dễ bị false positive khi có packet loss intermittent (KEEPALIVE bị drop)
  • Minimum hold time GCP hỗ trợ: kiểm tra tài liệu cụ thể, thường ≥20s

Hold timer lớn hơn:

  • Ít false positive hơn
  • Detect failure chậm hơn — traffic blackhole kéo dài hơn trước khi failover

Kết luận thực tế: Với production system, không nên tune hold timer để tăng tốc failure detection. Thay vào đó, dùng BFD — BFD có thể detect failure trong 5 giây mà không ảnh hưởng đến BGP hold timer. BFD và hold timer là hai cơ chế độc lập, bổ sung cho nhau.

MD5 Authentication ​

BGP MD5 authentication (RFC 2385) cho phép mỗi TCP segment của BGP session được ký bằng MD5 hash với một shared secret. Điều này ngăn các BGP packets giả mạo được inject vào session.

Cấu hình trong Cloud Router: Bạn cài MD5 password khi configure BGP session. On-prem router phải được cấu hình cùng password.

Hạn chế quan trọng: MD5 authentication chỉ available cho một số products — không phải tất cả hybrid connectivity options đều hỗ trợ. Kiểm tra tài liệu cụ thể cho product bạn đang dùng (HA VPN, Interconnect, Router Appliance).

MD5 và troubleshooting: Nếu BGP session bị stuck ở OPENCONFIRM và không lên được ESTABLISHED, một trong những nguyên nhân phổ biến là MD5 password mismatch. Verify password ở cả hai bên (GCP và on-prem).

Multiprotocol BGP (MP-BGP) Cho IPv6 ​

RFC 4760 mở rộng BGP để hỗ trợ multiple address families — không chỉ IPv4 unicast. Cloud Router sử dụng MP-BGP để hỗ trợ IPv6:

  • AFI (Address Family Identifier): 1 = IPv4, 2 = IPv6
  • SAFI (Subsequent AFI): 1 = unicast

Trong một session IPv4 với MP-BGP, Cloud Router có thể advertise và receive cả IPv4 và IPv6 prefixes trong cùng BGP session bằng cách dùng MP_REACH_NLRI và MP_UNREACH_NLRI path attributes thay vì NLRI field thông thường (chỉ cho IPv4 unicast).

Hạn chế: Để negotiate MP-BGP capability, cả hai bên phải khai báo MP-BGP capability trong OPEN message. Nếu on-prem router không hỗ trợ MP-BGP, bạn phải dùng hai session riêng biệt (một IPv4, một IPv6).

Failure Modes Ở Tầng Session ​

Session Flip-Flopping (Instability) ​

BGP session liên tục reset và lên lại. Nguyên nhân phổ biến:

  1. Link quality kém: Packet loss trên VPN tunnel hoặc Interconnect gây KEEPALIVE bị drop
  2. CPU overload ở on-prem router: Router bận xử lý quá nhiều, KEEPALIVE bị delay
  3. Hold timer quá ngắn: Không đủ margin cho packet loss ngẫu nhiên

Hệ quả: Mỗi lần session reset, toàn bộ routes từ peer bị withdraw, sau đó re-advertise — gây oscillation trong routing table, traffic disruption.

Giải pháp: Tăng Hold Timer (nếu đang quá nhỏ), cải thiện link quality, hoặc điều tra on-prem router performance.

Session Stuck Ở Một State ​

Session không bao giờ reach ESTABLISHED:

  • Stuck ở CONNECT: Firewall, route không có, on-prem chưa cấu hình
  • Stuck ở ACTIVE: BGP peer IP sai, bất đối xứng firewall (outbound ok, inbound block)
  • Stuck ở OPENSENT: ASN mismatch, BGP identifier conflict
  • Stuck ở OPENCONFIRM: MD5 mismatch, hold time negotiation không thành công

References ​