翻開任何一本網路教科書，BGP 入門教學幾乎都長得一樣：先講 AS 是什麼、接著是四種訊息類型、再把 BGP state machine 從 Idle 畫到 Established。讀完之後會考試，但真的要在機櫃前設定一條跨 ISP 的 eBGP session 時，還是不知道該從哪一步開始。
這篇文章換個切入方式。假設讀者已經大致知道 BGP 是「AS 之間交換路由」的協定，重點放在實務上會卡住的地方：什麼情境下真的需要跑 BGP、要不要自己申請 ASN、路由策略該怎麼規劃、以及小規模網路常見的誤區。
BGP 解決的到底是什麼問題
網際網路由數以萬計的自治系統（Autonomous System，AS）組成，每個 AS 是一個在共同管理策略下運作的 IP 網段集合。臺灣的中華電信、遠傳、臺灣大哥大、各雲端業者、甚至稍具規模的企業，都可能持有自己的 AS。AS 之間要彼此通訊，就需要一種能在不同行政域間交換可達性資訊的協定，這就是 BGP。
跟 OSPF、IS-IS 這類 IGP 不同，BGP 不是為了找最短路徑而生。它的核心是路徑向量（path vector）：每條路由都附帶完整的 AS_PATH，收到的路由器可以自行判斷要不要接受、要不要傳遞、以及何時要優先選擇。換句話說，BGP 的本質是策略工具，不是最佳化工具。這點想清楚，後面許多設計決策就不會走歪。
實務上 BGP 被用在三種場景：ISP 之間互連、企業多家上游（multihoming）做備援或負載分攤、以及資料中心內部 EVPN 這類 overlay 方案。本文聚焦前兩者。
什麼時候真的需要跑 BGP
很多人聽到 BGP 就覺得高級，恨不得立刻導入。實際情況是，絕大多數網路根本不需要。單一上游的環境用靜態預設路由就能完成所有事情；兩條連線只為了做 failover，通常一段 healthcheck script 切換預設路由就夠用，不必動用 BGP。
真正需要跑 BGP 的情境是：同時接兩家以上上游、擁有自己的 IP 區塊、而且希望在任一家上游斷線時，外部流量能自動繞到另一條路徑進來。流量要從網際網路方向主動繞進來這件事靜態路由做不到，必須由自己的 AS 向全世界廣播路由才辦得到。
簡單的判斷準則：擔心的只是出向流量（自家機器連外），靜態路由加上 policy-based routing 就能處理；擔心的是入向流量（客戶連進來）在單一上游掛掉時仍要通，就需要 BGP 加上自有 IP 空間。
申請 ASN 跟 IP 區塊的門檻
臺灣與香港、中國、日韓等地區共同屬於 APNIC 管轄，ASN 與 IPv4/IPv6 區塊必須透過 APNIC 或其下屬 NIR（如 TWNIC）申請。企業通常透過 LIR（Local Internet Registry，多半是 ISP 或資料中心業者）代為申請，提出路由策略文件說明會連接哪些上游、預計廣播哪些前綴。ASN 目前供應充足；IPv4 則只能透過市場轉讓取得，每個 IPv4 位址的市場價格長期維持在數十美元區間。
只想做 multihoming 的企業有一條折衷路徑：跟上游 ISP 申請 Provider Aggregatable（PA）空間並搭配自家 ASN，由 ISP 協助將這段 PA 空間透過 BGP 宣告出去。代價是這段 IP 綁在這家 ISP，換上游就得換 IP。要完全不被綁住，就得申請 Provider Independent（PI）空間，門檻與成本都更高。
路由策略的幾個關鍵工具
跑起 BGP 之後，很多工程師會發現：session 建起來了、路由也收進來了，但流量就是不照預期走。幾個實務上最常用的策略工具：
Local Preference 控制自家 AS 內部要從哪條上游出去，數值越大越優先、預設 100。想讓出向流量優先走 A 上游、B 為備援，就在從 A 收到的路由上設 200，B 維持 100 即可。這是出向流量最直接的控制手段。
AS Path Prepending 影響入向流量的土法——把自家 AS 號在宣告路由時重複多填幾次，讓這條路徑在別人眼裡看起來繞比較遠。效果很粗糙，因為它影響的是全世界所有能看到這條路由的 AS，不一定能精準達到目的。更推薦的做法是跟上游協商 BGP Community，例如請上游對特定地區的 peer 不要宣告這條路由，或降低其 local preference。
Blackhole Community 是 DDoS 防禦的基本動作。當某個 IP 正在被打，可透過 BGP 向上游宣告一條 /32 路由並加上對方文件定義的 blackhole community 值（常見如 65535:666 或自家 ASN 對應值），上游就會在其網路邊緣將這個 IP 的流量丟棄，保住其他服務。這比等封包塞爆自家線路再處理有效得多。
小規模 BGP 常見的幾個誤區
第一個誤區是以為跑了 BGP 就自動 HA。BGP 只負責路由收斂，如果上游線路的 BFD 沒開或 holdtime 設得太長，實際 failover 可能要 3 分鐘以上。建議 eBGP 的 keepalive/holdtime 調整到 3/9 秒，並啟用 BFD，收斂時間可壓到秒級。
第二個誤區是路由宣告沒做過濾。一個小疏忽就可能把全球 BGP table 重新宣告出去，變成路由洩漏（route leak），輕則被上游中斷 session，重則上新聞。正確做法是進出方向都要有 prefix-list 或 route-map 明確限制，只宣告自家的前綴、只接受符合預期的路由。RPKI 的 Route Origin Validation 現在也是必備，Origin Invalid 的路由應該直接拒絕。
第三個誤區是iBGP full-mesh。AS 內部超過四、五台路由器後，兩兩建立 iBGP session 就會變成管理噩夢。這時該導入 Route Reflector 或 Confederation，前者在中小型網路裡幾乎是標配，設定也更直觀。
第四個誤區是用公開可達的 IP 當 BGP peer 端點卻沒加 TTL security 或 MD5。BGP 本身不設防時很脆弱，至少要啟用 TCP MD5 authentication（RFC 2385）或更新的 TCP-AO，並搭配 TTL security（GTSM，RFC 5082）把 hop count 鎖在預期範圍內。
路由驗證：從 IRR 到 RPKI
近年 BGP 安全的討論幾乎都圍繞著 RPKI。這是一套以 X.509 憑證為基礎的機制，讓 IP 持有者可以用密碼學方式簽署一份「我授權這個 AS 宣告這段前綴」的聲明（ROA，Route Origin Authorization）。邊界路由器透過 RTR 協定從 RPKI validator 拉取這些資訊，就能自動拒絕來源錯誤的路由。
臺灣目前多數主要 ISP 都已部署 RPKI，但企業端自己的路由器是否有開 ROV（Route Origin Validation）則參差不齊。申請到 ASN 與 IP 區塊之後，第一件該做的事就是在 APNIC MyAPNIC 或透過 LIR 建立 ROA，然後確認自家 BGP 路由器會拒絕 Invalid。這一步不做，等於把自家前綴暴露在被劫持的風險裡。
IRR（Internet Routing Registry）是比 RPKI 更早的機制，透過公開資料庫登記路由策略。目前仍在使用，主要是許多上游的自動 prefix-list 產生工具仍依賴 IRR 物件。實務上 IRR 跟 RPKI 是並行的，兩個都該維護。
BGP 規劃不是技術問題，是策略問題
回頭看這些實務細節，會發現 BGP 本身協定不複雜，真正難的是策略設計：哪些路由要宣告出去、入向流量希望怎麼進來、多條線路的權重怎麼分、故障時的收斂要多快、安全機制要做到什麼層級。這些決策跟商業需求、預算、上游品質都綁在一起，沒有標準答案。
對於正在考慮建置自有網路的企業，建議分階段走：先確認業務是否真的需要 multihoming、再決定要 PA 還是 PI 空間、接著規劃上游選擇與路由策略，設備選型與組態實作放在最後一步。跳過前面的思考直接跳到設定檔，幾乎一定會在半年內重做一次。
NCSE Network 提供 10M 到 100G 的 IP Transit 服務，支援客戶自帶 ASN 與 IP 區塊進行 BGP 互連，也協助尚未持有 ASN 的企業規劃 multihoming 架構與 RPKI 部署。若正在評估自建網路或優化現有路由策略，歡迎進一步了解 NCSE Network 的網路服務。