BGP 配置是 ANS-C01 考試中難度最高的主題。雖然解決方案架構師 (Solutions Architect) 考試僅將 BGP 視為一個核取方塊（例如：「是的，Direct Connect 使用 BGP」），但進階網路專項 (Advanced Networking Specialty) 考試會問：「假設客戶端有一個 AS-PATH 預置 (prepend) 了 3 次的主動 Direct Connect，以及一個採用預設 AS-PATH 的備援 VPN，客戶希望來自特定子網的內部部署流量優先選擇 VPN —— 你該操作哪種 BGP 屬性，且在工作階段的哪一側進行操作？」這就是透過 BGP 屬性執行的路由政策，而 ANS-C01 在此領域至少有 4 到 6 題。
本主題涵蓋了 AWS 混合網路的 BGP 基本元件：Direct Connect 和 Site-to-Site VPN 上的 eBGP 基礎知識、透過 AS-path prepending 進行的入站流量工程、透過 LOCAL_PREF 進行的出站流量工程、AS 對之間 MED 的特殊語義、Direct Connect 上 AWS 受管的 BGP 社群 (7224:7100/7200/7300 範圍及 7224:1–9 NO_EXPORT 訊號)、用於次秒級故障偵測的 BFD、跨多個 BGP 路由連線的 ECMP 負載共用、BGP 計時器微調，以及考試中最常出現的主動/被動與主動/主動故障轉移模式。此部分對應到任務陳述 2.1（實作內部部署網路與 AWS 雲端之間的路由與連線）。
為什麼 BGP 是 ANS-C01 混合連線的核心
BGP 是 AWS 唯一支援混合連線的路由協定。內部部署與 AWS 之間沒有 OSPF、IS-IS 或 EIGRP —— 每個 Direct Connect VIF 和每個使用動態路由的 Site-to-Site VPN 都在客戶自治系統與 AWS 自治系統之間運行 eBGP (外部 BGP)。靜態路由可作為 VPN 連線的備案，但 Direct Connect 要求使用 BGP，且對於任何非簡單的混合情境，現代最佳實務答案都是 BGP。因此，BGP 屬性知識是進入網域 1.5、2.1、3.1 以及網域 4 多個問題的必備門檻。
本主題的核心在於透過屬性階層進行決定性的路徑選擇。BGP 會透過檢查排序後的決策準則清單，從多個廣告中挑選最佳路徑：權重 (weight，Cisco 專有)、LOCAL_PREF、本地起源、AS-PATH 長度、起源類型、MED、eBGP 優於 iBGP、前往下一躍點的 IGP 指標、最舊路徑、路由器 ID、鄰居 IP。ANS-C01 可測試的子集包括 AS-PATH 長度、LOCAL_PREF、MED 與 BGP 社群。精通哪種屬性影響哪個方向的流量，以及哪種屬性由工作階段的哪一側設置，是考試中最重要的加分項。
考試會以三種形式測試 BGP。單一工作階段屬性操作會問：「為了讓 AWS 偏好特定路徑，你應該設置哪種屬性？」多路徑比較會問：「假設有兩個來自不同 AS、具有不同 AS-PATH 長度和不同 MED 的 BGP 廣告，AWS 會選擇哪條路徑？」故障轉移情境會問：「給定主動 Direct Connect 與被動 VPN 備援，請設計 BGP 屬性，使得只有在 DX 故障時 VPN 才會接管流量。」
白話文解釋 BGP — 透過屬性階層進行路徑選擇
BGP 結合了幾個屬性（AS-PATH、LOCAL_PREF、MED、社群）來進行決定性的路徑選擇。這三個類比有助於理解這些組件。
類比 1：具有多個收費站與繞道路線的高速公路導航
將 BGP 想像成在具有多種到達目的地方式的高速公路網路中選擇路線。每條路徑都是汽車必須經過的一系列收費站（自治系統）。AS-PATH 長度是「這條路線上有多少個收費站」 —— 收費站越少越好。AS-PATH prepending 是「透過重複列出兩次或三次你的收費站，讓你的路線看起來更長」 —— 當你希望迎面而來的流量選擇其他路線時很有用。LOCAL_PREF 是你家中導航系統的個人偏好，告訴你自己的車在離開家時應該走哪個出口 —— 這完全不會影響迎面而來的流量，因為對方看不到它。MED 是你對特定鄰居私下說的提示：「如果你有多種進入我網路的方式，請使用這個入口」 —— 鄰居可以忽略或採納此提示，但該提示僅傳播到直接鄰居。BGP 社群是貼在你的路線廣告上的貼紙：「此路線僅限本地配送，請勿轉發」 —— 每個 AWS 區域或範圍都會讀取這些貼紙並調整行為。
類比 2：帶有郵資類別標記的國際郵件
BGP 廣告就像是從一個國家 (AS) 寄往另一個國家的郵件。郵件標籤上的每個海關蓋章都是 AS-PATH 中的一個 AS。AS-PATH prepending 是在包裹上蓋三次你國家的章，讓接收國認為你的包裹跨越了三個邊界 —— 讓你的運輸路線看起來更長，並阻止收件人偏好它。LOCAL_PREF 是你郵局內部的分揀偏好：當你有兩台卡車可以寄送包裹時，你的經理會告訴你使用哪台卡車 —— 這種選擇對收件人來說是不可見的。MED 是包裹上的「首選入境港口」貼紙 —— 收件郵局在決定從哪個入境港口發送包裹時可以使用此提示，但前提是所有其他標準都相等。NO_EXPORT 是「此信件僅供收件郵局使用 —— 請勿轉發至任何其他國家」的印章。
類比 3：具有特快與區間服務的火車路由
BGP 路由就像是從 A 站到 B 站的火車路線。AS-PATH 長度是「所需的換乘次數」 —— 換乘次數越少越好。AS-PATH prepending 是透過插入虛假的換乘公告，讓你的路線看起來比實際更長。LOCAL_PREF 是出發站的站務員決定這位旅客登上下哪班火車 —— 目的地不可見。MED 是給終點站的提示：「如果我的線路有多班火車到達，請引導這位旅客前往第 3 月台」 —— 僅由直接目的地採納。BFD 是每 100 毫秒發出一次訊號的火車監控系統 —— 如果三次訊號失敗，火車會發出「軌道故障」訊號並自動切換到備援路線。
對於 ANS-C01，當問題詢問 Direct Connect 與 VPN 之間的路徑選擇時，高速公路導航類比是最有效的心智模型 —— 多收費站的高速公路圖像非常精確。對於入站 vs 出站方向的問題（常見陷阱），郵局類比能讓「你的分揀偏好對收件人不可見」變得直觀。對於故障轉移和 BFD 計時問題，火車監控系統子類比最為敏銳。參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
AWS 上的 BGP 基礎知識 — eBGP、ASN 與工作階段建立
BGP 是公共網際網路的網域間路由協定，定義於 RFC 4271。AWS 在每個 BGP 工作階段上運行 eBGP（不同 AS 之間） —— AWS 與客戶之間沒有 iBGP，因為總是會跨越 AS 邊界。
自治系統編號 (ASN)
ASN 是識別路由網域的 16 位元（2 位元組）或 32 位元（4 位元組）整數。公共 ASN 由 IANA 分配並用於公共網際網路。私有 ASN 範圍為 64512–65534（2 位元組）或 4200000000–4294967294（4 位元組） —— 用於內部且不會在公共網際網路上廣告。AWS 預設使用 ASN 64512 作為 Direct Connect 和 Site-to-Site VPN 的客戶側 ASN，使用 7224 處理 Direct Connect 上的 AWS 側公共服務。客戶可以使用任何私有 ASN 或其自身的公共 ASN。
Direct Connect 上的 eBGP 工作階段建立
Direct Connect 私有 VIF 在客戶路由器（169.254.x.x 連結本地範圍內的 BGP 對等 IP）與 AWS 的 BGP 說話者 (BGP speaker) 之間建立 eBGP 工作階段。工作階段使用 TCP 連接埠 179。支援透過共享密鑰進行 MD5 驗證。對於直接交叉連線，最大躍點數 (Maximum hop count) 通常為 1（單躍點 eBGP）。工作階段建立後，雙方交換 OPEN、UPDATE、KEEPALIVE 與 NOTIFICATION 訊息；UPDATE 訊息攜帶 NLRI (網路層可達性資訊) —— 正在廣告的前綴 —— 以及路徑屬性 (AS-PATH, MED, 社群, NEXT_HOP, ORIGIN)。
Site-to-Site VPN 上的 eBGP
具備動態路由的 Site-to-Site VPN 在每個 IPsec 隧道內建立 eBGP 工作階段 —— 每個 VPN 連線有兩個隧道，每個隧道都有自己的 BGP 工作階段。客戶閘道與 AWS 側的虛擬私有閘道 (VGW) 或 Transit Gateway (TGW) 建立對等關係。適用相同的 BGP 屬性，但某些 AWS 受管社群僅限 Direct Connect 使用。
Transit Gateway Connect 上的 eBGP
Transit Gateway Connect 是一種連線類型，它在底層 VPC 或 DX 連線之上的 GRE 隧道內（而非 IPsec）建立 BGP。主要用於 SD-WAN 整合，客戶的 SD-WAN 設備直接與 TGW 建立 BGP。每個 Connect 對等點支援最多 4 個 BGP 對等點以進行 ECMP，支援比單個 VPN 隧道更高的彙整頻寬。
- eBGP：外部 BGP，不同 AS 之間。
- iBGP：內部 BGP，相同 AS 內部。AWS 與客戶之間不直接使用。
- ASN：自治系統編號；AWS 側預設為 64512（私有）、7224（公共 Direct Connect）。
- NLRI：網路層可達性資訊；正在廣告的前綴。
- AS-PATH：路由經過的 AS 有序列表；較短者勝。
- LOCAL_PREF：本地 AS 內部的出站偏好；僅限 iBGP 屬性。
- MED (多結束點鑑別器)：給鄰居 AS 的首選進入點提示；較低者勝。
- BFD：雙向轉發偵測；次秒級鏈路存活檢查。
- 參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
AS-PATH Prepending — 入站流量工程
AS-PATH prepending 是指在向鄰居廣告前綴時，在 AS-PATH 屬性中人為地多次插入你自己的 ASN。鄰居會看到較長的 AS-PATH，並且（在所有其他屬性相等的情況下）偏好 AS-PATH 較短的路徑。這是影響入站流量的機制 —— 讓 AWS 為流向你網路的流量在路徑 A 與路徑 B 之間做出選擇。
Direct Connect 上的機制
典型的 Direct Connect 故障轉移情境在客戶與 AWS 之間有兩條連線 —— 主動與備援 —— 兩者都向 AWS 廣告相同的預綴（例如 10.0.0.0/16）。預設情況下，AWS 認為兩條路徑相等並使用 ECMP。為了讓主動連線成為首選，客戶在備援連線的 BGP 廣告上預置兩次或三次其自身的 ASN，使得備援路徑看起來 AS-PATH 長度為 3，而主動路徑長度為 1。AWS 會為入站流量選擇較短的路徑（主動）。
方向很重要 — Prepending 影響入站
ANS-C01 BGP 中最常考的事實：AS-PATH prepending 會影響接收廣告的 AS 到發送廣告的 AS 之間的流量方向。因此，從客戶到 AWS 方向的 Prepending 會影響從 AWS 到內部部署的流量。為了影響從內部部署到 AWS 的流量，客戶必須使用影響本地路由決策的工具 —— 通常是客戶側的 LOCAL_PREF（這對 AWS 是不可見的）。
主動/被動 Direct Connect + VPN 備援
典型的 ANS-C01 情境：客戶擁有一條主動 Direct Connect 私有 VIF 和一條作為備援的被動 Site-to-Site VPN。兩者都向 AWS 廣告內部部署的 CIDR。為了確保 AWS 在正常運作期間偏好 DX：
- 客戶側：在 VPN 側向 AWS 發出的廣告中，將內部部署 CIDR 的 AS-PATH 預置 2-3 個 AS。AWS 看到 DX 的 AS-PATH 長度為 1，VPN 為 3-4，因此偏好 DX。
- AWS 側：客戶還可以額外使用 AWS 受管的 BGP 社群 (7224:7100 / 7200 / 7300) 來影響 AWS 側的偏好，但通常在客戶側進行 Prepending 就足夠了。
當 Prepending 失效時
只有在其他屬性相等時，Prepending 才能作為平手決勝因素。如果 VPN 在 AWS 側廣告了更高的 LOCAL_PREF（罕見，通常客戶無法調整），或者 MED 不同，Prepending 就會被覆蓋。考試期望你能識別 AS-PATH 長度是 BGP 路徑選擇的一個準則，但不是優先級最高的。
考生經常混淆 Prepending 的方向。請記住：你在向鄰居廣告的路徑上進行 AS-PATH prepending，會影響從該鄰居到你的流量。因此，如果你希望 AWS 到內部部署的流量偏好 DX，請在向 AWS 廣告的 VPN 側進行 Prepending。如果你希望內部部署到 AWS 的流量偏好 DX，你不能對 AWS 給你的廣告使用 AS-PATH prepending（AWS 設置其 AS-PATH）；相反，請使用你內部部署路由器上的 LOCAL_PREF 將 DX 標記為更高的本地偏好。考試會利用調換方向的選項來測試這一區別。參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
LOCAL_PREF — 出站流量工程
LOCAL_PREF (Local Preference) 是一個 32 位元值，AS 用於在內部表達對前往同一目的地的多條路徑的偏好。較高的 LOCAL_PREF 勝出。LOCAL_PREF 僅限 iBGP —— 它不會在 eBGP UPDATE 訊息中傳輸，且對鄰居 AS 不可見。
為什麼 LOCAL_PREF 用於出站
由於 LOCAL_PREF 僅影響本地 AS 的路徑選擇，因此它是影響從你的 AS 到另一個 AS 中目的地的出站流量的正確工具。在客戶側，內部部署 BGP 路由器會對接收到的 AWS 廣告設置 LOCAL_PREF：對透過 DX 學習到的路由設置較高的 LOCAL_PREF，會使出站流量偏好 DX，不論 AWS 側的屬性如何設置。
LOCAL_PREF 與 AWS 側廣告
AWS 不向客戶開放直接的 LOCAL_PREF 操作。相反，客戶使用 AWS 受管的 BGP 社群 (7224:7100/7200/7300)，AWS 會將這些社群翻譯成 AWS 網路內部的 LOCAL_PREF 設置。因此，雖然 LOCAL_PREF 屬性本身是僅限 iBGP 的，但 AWS 提供了基於社群的掛鉤來實現類似效果。
實作範例 — DX 的出站偏好
客戶擁有連往 AWS 的 DX 與 VPN，兩者都將輪輻式 VPC CIDR 廣告回內部部署。為了使內部部署到 AWS 的流量偏好 DX：
- 內部部署路由器：對透過 DX 接收到的路由設置
local-preference 200，對透過 VPN 接收到的路由設置local-preference 100。較高的 LOCAL_PREF 勝出，因此偏好 DX。 - AWS 看到客戶的 LOCAL_PREF 沒有變化（僅限 iBGP），並繼續正常廣告。
這與 Prepending 範例是對稱的：AS-PATH prepending 控制入站；LOCAL_PREF 控制出站。兩者結合即可實作雙向流量工程。
MED (多結束點鑑別器) — 針對鄰居的進入點提示
MED 是一個攜帶在 eBGP UPDATE 訊息中的 32 位元值。較低的 MED 勝出。當鄰居有多種方式抵達一個前綴時，MED 是從一個 AS 給特定鄰居 AS 關於首選進入點的提示。
MED 範圍
MED 僅在來自同一鄰居 AS 的路徑之間進行比較。如果 AWS 接收到來自 AS 65000 且 MED 為 100 的路徑，以及來自 AS 65001 且 MED 為 50 的路徑，則不會比較 MED，因為路徑來自不同的 AS。在 AS 65000 的兩條路徑（例如，終止於同一 AS 的兩條不同 DX 連線）中，較低的 MED 勝出。
Direct Connect 上的 MED
擁有兩條來自同一內部部署 AS 的 DX 連線連往 AWS 的客戶可以使用 MED 來表達偏好：連線 A 廣告時帶有 MED 100，連線 B 帶有 MED 200。AWS 接收到這兩者，並在前往該前綴時偏好連線 A。這是一種入站流量工程的形式，類似於 AS-PATH prepending，但更細緻，且僅在兩條路徑來自同一客戶 AS 時有效。
MED 比較規則
預設情況下，AWS 僅在來自同一鄰居 AS 的路徑之間比較 MED。選用的 always-compare-med 設置（在 AWS 上不可由客戶配置）會跨所有路徑比較 MED，而不論其 AS 為何，這可能會導致非預期的路徑選擇。
ANS-C01 經常出現的干擾項：考生看到一條路徑上的 MED 為 50，另一條路徑為 100，就假設 50 勝出。但如果這兩條路徑來自不同的 AS，則不會比較 MED，決策會回退到 AS-PATH 長度、ORIGIN 等準則。只有在比較來自同一個鄰居 AS 的兩條路徑時（通常是來自同一個內部部署 AS 的兩條 DX 連線），MED 才有意義。如果你有一條 DX (AS 65000) 和一條 VPN（同一個內部部署的 AS 65000），則適用 MED 比較。如果你有一條 DX (AS 65000) 和一條透過合作夥伴建立的 VPN (AS 65001)，則不會比較 MED。參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
Direct Connect 上的 BGP 社群 — AWS 受管範圍與偏好
BGP 社群是附加在路由廣告上的 32 位元標籤（通常格式化為 XXXX:YYYY）。AWS 在 Direct Connect 公共 VIF 和（以有限形式）私有 VIF 上公開特定社群，以控制 AWS 側的路由行為。
AWS 受管範圍社群 (公共 VIF)
在公共 VIF 上向 AWS 廣告前綴時，客戶可以附加範圍社群來控制哪些 AWS 區域接收廣告：
- 7224:9100 — 僅限本地 AWS 區域。AWS 不會將此前綴傳播到 DX 連線終止區域之外。
- 7224:9200 — 相同大陸。僅在該大陸的區域內傳播。
- 7224:9300 — 全球（預設）。傳播到所有 AWS 區域。
這對於希望其廣告僅能從特定區域存取的客戶（例如，不得從國外存取的受監管工作負載）至關重要。
AWS 受管本地偏好社群 (公共與私有 VIF)
當 AWS 向客戶廣告前綴時，客戶可以透過在入站廣告中附加本地偏好社群來影響 AWS 的出站偏好（AWS 使用哪條 DX 路徑流向客戶）：
- 7224:7100 — 低 LOCAL_PREF（較不偏好）。
- 7224:7200 — 中 LOCAL_PREF（預設）。
- 7224:7300 — 高 LOCAL_PREF（最偏好）。
如果客戶有兩條 DX 連線並希望 AWS 偏好連線 A，他們可以在連線 A 的廣告上附加 7224:7300，並在連線 B 的廣告上附加 7224:7100。AWS 內部會將這些翻譯成 LOCAL_PREF 並偏好連線 A。
NO_EXPORT 與 NO_ADVERTISE
標準 BGP 社群 NO_EXPORT (65535:65281) 和 NO_ADVERTISE (65535:65282) 在 AWS 上也有效：
- NO_EXPORT — 路由不會被廣告到接收 AS 之外。
- NO_ADVERTISE — 路由完全不會被廣告到任何其他 BGP 對等點。
當客戶希望 AWS 接收廣告但不進一步傳播時（例如，應到達 AWS 區域 A 但不傳播到區域 B 的私有前綴），這非常有用。
- 7224:9100/9200/9300 — 公共 VIF 範圍（本地區域 / 大陸 / 全球）。
- 7224:7100/7200/7300 — AWS 出站的本地偏好（低 / 中 / 高）。
- 65535:65281 — NO_EXPORT（不要廣告到接收 AS 之外）。
- 65535:65282 — NO_ADVERTISE（不要廣告給任何對等點）。
- AWS ASN：64512（私有 VIF 預設）、7224（公共服務）。
- AWS 上的預設 BGP 計時器：keepalive 30s, hold-time 90s（Direct Connect 預設；可協商縮短）。
- BGP 驗證：帶有共享密鑰的 MD5，選配但推薦使用。
- 參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html
BFD — 用於次秒級故障轉移的雙向轉發偵測
BFD 是一種輕量級協定，它能在毫秒級偵測鏈路存活情況，而不是依賴需要 60-180 秒才能宣告工作階段失效的 BGP keepalive 計時器。當 BFD 偵測到故障時，它會觸發立即的 BGP 工作階段拆除，將故障轉移時間從分鐘級縮短到一秒以內。
Direct Connect 上的 BFD
AWS 支援 Direct Connect 上的 BFD，預設參數為：300 ms 發送間隔，3 次倍數 —— 意味著在錯過 900 ms 的封包後宣告故障。雙方都必須支援 BFD；客戶的 BGP 路由器按鄰居啟用 BFD。一旦客戶在自己的一側啟用，AWS 的 BFD 支援就會自動生效。
Site-to-Site VPN 上的 BFD
Site-to-Site VPN 在 IPsec 隧道上支援 BFD，以便在連線中的兩個隧道之間進行快速故障轉移。結合主動/主動 BGP 路由，BFD 可確保如果一個隧道關閉，流量會在一秒內切換到另一個隧道。
TGW Connect 上的 BFD
Transit Gateway Connect (GRE + BGP) 在每個 BGP 對等點上支援 BFD，為 SD-WAN 設備實現次秒級故障轉移。
為什麼 BFD 很重要
沒有 BFD 時，BGP keepalive 為 30 秒，hold-time 為 90 秒，這意味著在錯過 90 秒的 keepalive 後才會偵測到鏈路故障。對於許多生產工作負載來說，90 秒的停機是不可接受的。BFD 將此時間縮短到一秒以內。
ANS-C01 干擾項：題目描述光纖斷裂後 Direct Connect 出現 90 秒的連線中斷。考生選擇「將 BGP keepalive 和 hold-time 微調為 5/15 秒」，認為這樣可以解決問題。但激進的 BGP 計時器會給 BGP 控制平面帶來壓力，且不是 AWS 推薦的方法。正確答案是啟用 BFD —— 它在資料平面運作，具備毫秒級的存活檢查，在偵測到故障時透過 BGP NOTIFICATION 觸發 BGP 工作階段拆除，是 AWS 推薦的快速故障轉移機制。只有在客戶硬體不支援 BFD 時，微調 BGP 計時器才是次優答案。參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/bfd.html
ECMP — 等價多路徑負載共用
ECMP 允許路由器同時使用多條等價路徑，並透過基於雜湊的負載平衡在這些路徑之間分發流量。在 AWS 上，當存在多條 BGP 路由路徑且 BGP 最佳路徑演算法宣告它們等價時，ECMP 預設會啟用。
TGW 上的 ECMP
Transit Gateway 預設支援 VPN 連接和 Direct Connect 連接的 ECMP。連往同一個 TGW 且具備 BGP 的多個 Site-to-Site VPN 連線可以彙整頻寬：兩個 1.25 Gbps 的 VPN 連線透過 ECMP 可提供約 2.5 Gbps 的頻寬。現代 TGW 配置支援最多 50 條 ECMP 路徑。
ECMP 要求
- 所有路徑必須具有完全相同的 AS-PATH 長度（否則 BGP 會選擇最短的路徑）。
- 所有路徑必須具有相同的 LOCAL_PREF、MED 與其他路徑屬性。
- 路徑選擇演算法使用 5 元組雜湊 (5-tuple hash)（來源 IP、目的地 IP、來源連接埠、目的地連接埠、協定） —— 相同的流量 (flow) 始終走同一條路徑；不同的流量則分散開來。
VGW vs TGW 上的 ECMP
VGW (虛擬私有閘道) 不支援跨多個 VPN 連線的 ECMP。如果你需要頻寬彙整，請遷移至 TGW。
ECMP 與順序
流量的雜湊值決定其路徑。在一個流量內部，封包保持在同一路徑上，因此保留了 TCP 順序。跨流量時，分發是均勻雜湊的。這意味著單個高頻寬流量無法超過單條路徑的頻寬；ECMP 擴展的是彙整頻寬，而非單個流量的頻寬。
常見的 ANS-C01 情境：客戶需要內部部署與 AWS 之間達到 5 Gbps 的彙整輸送量，並使用 Site-to-Site VPN。選擇「對 VGW 使用多個 VPN 連線」的考生是錯誤的 —— VGW 不支援 ECMP，因此即使有 5 個連線也僅提供 1.25 Gbps。正確答案是遷移至 Transit Gateway 並對多個具備 BGP 的 VPN 連接使用 ECMP。每個 VPN 提供約 1.25 Gbps；使用 4 個連線，透過 TGW ECMP 可彙整約 5 Gbps。或者，使用 Direct Connect（原生 1/10/100 Gbps）以獲得保證的輸送量。參考資料：https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html
主動/被動 vs 主動/主動故障轉移模式
ANS-C01 期望你能使用 BGP 屬性設計兩種典型的故障轉移拓撲。
主動/被動 — Direct Connect 為主，VPN 為備
目標：DX 為主動；僅當 DX 故障時 VPN 才接管。
- 客戶側：在向 AWS 發出的 VPN 廣告中進行 AS-PATH prepend，插入 2-3 個 AS。AWS 看到 DX 為較短路徑，偏好 DX。
- AWS 側：客戶對從 VPN 側接收到的廣告附加 7224:7100（低 LOCAL_PREF），對 DX 廣告附加 7224:7300（高 LOCAL_PREF）。AWS 出站偏好 DX。
- 在 DX 上啟用 BFD 以進行次秒級故障轉移偵測。
- 當 DX BGP 工作階段關閉時，AWS 僅能看到 VPN 路徑並使用它；當 DX 恢復時，BGP 重新收斂，流量切換回 DX。
主動/主動 — 兩條具備 ECMP 的 Direct Connect
目標：兩條 DX 連線同時承載流量；故障時互為備援。
- 兩條 DX 連線廣告相同的前綴，且具有相同的 AS-PATH、LOCAL_PREF、MED。AWS 認為它們等價。
- ECMP 透過 5 元組雜湊實現 50/50 的流量分發。
- 在兩者上均啟用 BFD 以實現快速故障偵測。
- 如果一條失敗，另一條會立即承擔 100% 的流量（取決於頻寬餘裕）。
主動/主動 — DX + VPN 具備 ECMP（較少見）
可行但少見。兩者必須廣告相同的屬性，這與通常偏好 DX 的意圖相左。用於頻寬彙整優先於路徑偏好的情況。針對對稱的 AS-PATH 和 LOCAL_PREF 進行調整。
BGP 計時器微調與工作階段穩定性
BGP 工作階段的穩定性取決於 keepalive 與 hold-time 參數。兩者在工作階段建立時進行協商；採用雙方中的較小值。
預設值與推薦值
- AWS 預設：keepalive 30 秒，hold-time 90 秒。
- 激進（配合 BFD）：keepalive 30，hold-time 90，加上 BFD 設置為 300 ms / 3 次倍數。
- 不配合 BFD 時的快速故障轉移：keepalive 10，hold-time 30（協商後採用）。
在沒有 BFD 的情況下使用激進計時器會給 BGP 控制平面帶來壓力，並在發生臨時擁塞時面臨虛假閃斷 (flap) 的風險。AWS 推薦使用 BFD，而非激進的計時器微調。
BGP 工作階段閃斷 (Flapping)
閃斷的工作階段（反覆建立與拆除）通常由以下原因引起：
- 物理層不穩定（光纖、光訊號）。
- 第 2 層問題（VLAN 配置、MTU 不匹配）。
- BGP 計時器不匹配（在 AWS 上不常見 —— AWS 協商非常靈活）。
- 超過 BGP 路由限制 —— 如果廣告的前綴數量超過限制，AWS 會關閉工作階段。
AWS 上的 BGP 前綴限制
- Direct Connect 私有 VIF：從客戶接收的最大前綴數為 100。
- Direct Connect 公共 VIF：從客戶接收的最大前綴數為 1000。
- Site-to-Site VPN：從客戶接收的最大前綴數為 100。
超過限制會關閉工作階段。修復方法是路由彙總 (route summarisation) —— 在客戶側將多個 /24 彙總為 /16。
客戶從 MPLS 遷移至 AWS，透過 Direct Connect 私有 VIF 從內部部署廣告 250 個特定的 /24 前綴。工作階段最初會建立，但隨著 AWS 偵測到違反限制而掉線。考生假設是配置錯誤或 BFD 配置錯誤 —— 實際原因是 100 個前綴的限制。修復：彙總為較少數量且較大的前綴（例如，使用 16 個 /20 代替 250 個 /24）。考試會測試此類情境；請識別「工作階段在建立後不久反覆掉線，且客戶正在廣告數百條路由」的症狀。參考資料：https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html
ANS-C01 BGP 常考陷阱總結
陷阱 1：AS-PATH prepending 影響出站流量
錯誤。AS-PATH prepending 影響來自鄰居 AS 的入站流量。要影響出站，請在你的本地路由器上使用 LOCAL_PREF。
陷阱 2：LOCAL_PREF 對 AWS 可見
錯誤。LOCAL_PREF 僅限 iBGP —— 不會在 eBGP UPDATE 訊息中傳輸。AWS 無法直接看到客戶側的 LOCAL_PREF。請使用 BGP 社群 (7224:7100/7200/7300) 實現 AWS 側的偏好。
陷阱 3：MED 是全局比較的
錯誤。MED（預設情況下）僅在來自同一個鄰居 AS 的路徑之間進行比較。
陷阱 4：BGP 計時器可以實現次秒級故障轉移
錯誤。預設的 BGP keepalive/hold-time 需要 90 秒偵測時間。請使用 BFD 實現次秒級故障轉移。
陷阱 5：VGW 支援跨多個 VPN 連線的 ECMP
錯誤。VGW 不支援 ECMP。請使用 TGW 在 VPN 連接之間實現 ECMP。
陷阱 6：Direct Connect 支援靜態路由
錯誤。Direct Connect 要求使用 BGP。Site-to-Site VPN 支援靜態與動態 (BGP)；推薦使用 BGP。
陷阱 7：7224:7300 用於出站偏好
錯誤。7224:7300 是 AWS 的出站偏好（即 AWS 到客戶的方向） —— 由客戶在向 AWS 廣告路徑時設置。若要影響客戶的出站偏好，請在客戶自己的路由器上設置 LOCAL_PREF。
陷阱 8：前綴限制是按 ASN 計算的
錯誤。前綴限制按 VIF 類型計算：私有 VIF 為 100，公共 VIF 為 1000，VPN 為 100。
FAQ — AWS 上的 BGP 配置
Q1：我應該使用哪種 BGP 屬性讓 AWS 偏好 Direct Connect 而非 VPN 來處理流向內部部署網路的流量？
這是入站流量工程（AWS 到客戶方向）。請在 VPN 側使用 AS-PATH prepending：當從你的客戶閘道向 AWS 廣告內部部署前綴時，在 VPN BGP 工作階段上將你的 ASN 預置 2 或 3 次。AWS 看到 DX 的 AS-PATH 長度為 1，VPN 長度為 3-4，因此偏好 DX（短路徑勝出）。或者，也可以在 VPN 廣告上附加 BGP 社群 7224:7100（AWS 的低本地偏好），並在 DX 廣告上附加 7224:7300（高本地偏好）。AWS 內部會將這些翻譯成其網路內的 LOCAL_PREF 設置。這兩種方法可以結合使用，結合使用可提供最強的偏好引導。
Q2：為什麼我的 LOCAL_PREF 設置沒有影響 AWS 的路徑選擇？
因為 LOCAL_PREF 僅限 iBGP —— 它是一個不會在 eBGP UPDATE 訊息中跨越 AS 邊界的路徑屬性。你的客戶側 LOCAL_PREF 僅影響你自己的路由器關於從內部部署到 AWS 的出站流量的決策。若要影響 AWS 對進入內部部署路徑的選擇，請使用 AS-PATH prepending 或 AWS 受管的 BGP 社群 (7224:7100/7200/7300)。考試經常測試這種區別 —— 選項中通常會將「在 AWS 側廣告上設置 LOCAL_PREF 200」（無效操作）與「在備援廣告上設置 AS-PATH prepend 3 次」（正確）成對出現。請記住，LOCAL_PREF 是你本地 AS 用於出站偏好的工具，而 AS-PATH prepending 是用於入站偏好的跨 AS 工具。
Q3：MED 與 AS-PATH prepending 在入站流量工程上有何不同？
兩者都會影響鄰居 AS 回到你網路的路徑選擇。MED 是針對 AS 對的提示 —— 僅在來自同一鄰居 AS 的路徑之間進行比較，粒度更細，較低者勝。AS-PATH prepending 則是跨所有路徑可比較的 —— 不論來源 AS 為何，AS-PATH 較長的路徑都較不被偏好。當你有兩條來自同一內部部署 AS 的 DX 連線，並希望在它們之間建立微弱的偏好時，請使用 MED；AWS 會比較 MED 並偏好較低的值。當你有來自不同拓撲（DX vs VPN）的路徑，或者需要更強、依階層評估的偏好時，請使用 AS-PATH prepending。AS-PATH prepending 更為穩健，因為 BGP 的路徑選擇演算法在評估 MED 之前會先評估 AS-PATH，因此當兩屬性衝突時，Prepending 勝出。
Q4：我何時應該在 Direct Connect 上啟用 BFD，權衡取捨是什麼？
只要需要快速故障轉移且客戶路由器支援，就應該啟用 BFD。預設的 BFD 參數（300 ms 發送間隔，3 次倍數）可偵測 900 ms 內的故障並立即觸發 BGP 工作階段拆除，實現次秒級的備援路徑故障轉移。權衡：BFD 會產生額外的封包（每個方向每 300 ms 一次），因此在極低頻寬的鏈路上會增加適度的開銷 —— 在 Direct Connect (1+ Gbps) 上通常可以忽略不計。BFD 需要雙方的 CPU 資源；處理能力不足的客戶路由器可能難以應對激進的計時器。在某些實作中，BFD 無法在 GRE 隧道上運行；請驗證客戶路由器的支援情況。AWS 推薦的預設做法：在每個 BGP 工作階段上啟用 BFD 以實現次秒級故障轉移，並接受這點微小的開銷。
Q5：如何彙整來自多個 Site-to-Site VPN 連往 AWS 的頻寬？
請使用 Transit Gateway 搭配 ECMP，而非 VGW。VGW 不支援跨多個 VPN 連線的 ECMP —— 一次只有一個隧道是主動的。TGW 支援跨具備 BGP 路由的 VPN 連接和 Direct Connect 連接的 ECMP。架構：創建 N 個 Site-to-Site VPN 連線到單個 TGW，每個連線有兩個 IPsec 隧道（總共 2N 個隧道），每個隧道運行具有相同 AS-PATH 和相同屬性的 BGP。TGW 會認為它們是等價的並在它們之間雜湊流量。彙整頻寬約等於 N × 1.25 Gbps（單個 VPN 隧道最大值）。現代 TGW 支援最多 50 條 ECMP 路徑。對於 5-10 Gbps 以上的頻寬需求，Direct Connect 更具成本效益且能提供保證的輸送量。
Q6：BGP 社群 7224:9100 與 7224:9300 在 Direct Connect 公共 VIF 上有什麼作用？
這些是 AWS 受管的範圍社群，用於控制 AWS 在公共 VIF 上傳播客戶前綴廣告的距離。7224:9100 將廣告限制在 DX 連線終止的 AWS 區域內 —— AWS 不會將該前綴傳播到其他區域。7224:9200 在大陸內傳播（例如，所有北美區域）。7224:9300 則是全球傳播 —— 這是預設值。當客戶的前綴僅應從特定區域存取時（例如，不得從國外存取的受監管工作負載），請使用 7224:9100。當客戶希望透過 AWS 主幹網實現全球存取時，請使用 7224:9300。
Q7：Direct Connect 私有 VIF、公共 VIF 和 Transit VIF 在 BGP 行為上有什麼區別？
私有 VIF 在客戶與特定 VPC 中的虛擬私有閘道 (VGW) 之間建立 BGP。AWS 廣告 VPC 的 CIDR（或 DXGW 關聯的 VPC CIDR）；客戶廣告內部部署前綴。限制為從客戶接收 100 個前綴。公共 VIF 在客戶與 AWS 邊緣之間建立 BGP，用於公共 AWS 服務。AWS 廣告所有公共 AWS 服務前綴（整個 AWS 公共 IP 空間）；客戶可以廣告其自身的公共前綴。限制為從客戶接收 1000 個前綴。範圍社群 (7224:9100/9200/9300) 在此非常有用。Transit VIF 建立連往 Direct Connect Gateway (DXGW) 的 BGP，該網關向多個區域的 Transit Gateway 扇出。在語義上與私有 VIF 相似，但透過 DXGW + TGW 支援多區域、多 VPC 連線。考試會測試你是否能為特定場景識別正確的 VIF 類型。
Q8：BGP 路由彙總如何幫助我保持在前綴限制內？
Direct Connect 私有 VIF 接受來自客戶的最多 100 個前綴。如果客戶內部部署有 200 個特定的 /24，超過限制後 BGP 工作階段會中斷。解決方案：配置客戶路由器在廣告前將特定路由彙總為較不具體的聚合路由。例如，將 10.5.0.0/24 到 10.5.15.0/24 的 16 個 /24 彙總為一個 /20 (10.5.0.0/20)。200 個 /24 可以變成約 12 個 /20，遠低於 100 的限制。彙總是在客戶側透過 BGP aggregate-address 或平台特定指令配置的。權衡：彙總會隱藏較長前綴的路由，因此流向 10.5.99.99 (位於 10.5.96.0/20 內) 的流量會走與 10.5.5.5 相同的路徑；你會失去子彙總前綴的路徑多樣性。AWS 不會自動彙總你廣告的路由 —— 這是客戶的責任。
Q9：當 BGP 工作階段的一側超過 BFD 逾時時間時會發生什麼事？
BFD 偵測到鏈路故障（預設參數通常為 900 ms），然後立即觸發 BGP NOTIFICATION 來拆除工作階段。路由器會清除從該工作階段學習到的所有路由並重新收斂。配置了備援路徑（第二條 DX 或 VPN）後，流量會透過 BGP 最佳路徑選擇在一秒內切換到倖存的路徑。如果沒有 BFD，BGP 工作階段會一直保持直到 hold-time 到期（預設 90 秒），在此期間流向故障路徑的流量會進入黑洞。BFD 是次秒級停機與 90 秒停機在物理鏈路故障時的區別。請為每個生產 BGP 工作階段配置 BFD。
Q10：AWS 推薦的主動/主動混合連線模式是什麼，以最大化可用性？
從兩個不同的 Direct Connect 位置（不同的物理站點）建立兩條 Direct Connect 連線，每條連線都有通往內部部署網路的備援光纖。兩條連線廣告相同的前綴，並具備相同的 BGP 屬性 —— 等價。AWS 會使用 ECMP（透過 TGW 時）或單一最佳路徑（透過 VGW 時）。兩者都啟用 BFD。每條連線終止於不同的客戶路由器，以實現完全的韌性。透過公共網際網路添加 Site-to-Site VPN 作為第三級備援，並預置 4-5 次 AS-PATH，以確保僅在兩條 DX 均故障時才使用它。這種設計的預期可用性：混合路徑為 99.99%。AWS Well-Architected 可靠性支柱將此模式描述為一級混合連線的金級標準。ANS-C01 題目若提到「一級任務關鍵型混合連線」，通常期望選擇雙 DX + VPN 三級備援作為答案。
延伸閱讀
- Direct Connect 路由政策與 BGP 社群
- Site-to-Site VPN 路由選項
- Direct Connect 上的 BFD
- Transit Gateway Connect 連接
- AWS 混合連線白皮書
- RFC 4271 — 邊界閘道協定 4 (BGP-4)
- AWS ANS-C01 考試指南
BGP 是路由協定；下一個層級是承載 BGP 的 Direct Connect VIF 類型與物理層設計、成本較低的 具備 BGP 的 Site-to-Site VPN、BGP 廣告注入的 Transit Gateway 路由，以及傳播後的路由如何在子網路路由表內最終變成轉發決策的 VPC 路由基本元件。