AWS帳號充值優惠 AWS Direct Connect 專線實體層通但 BGP 鄰居建立失敗排查指南
一、先看鄰居狀態，別一上來就改配置
AWS Direct Connect 最容易讓人誤判的一點，就是把「專線燈亮了」當成「一切都通了」。事實上，物理層和二層正常，只代表線路、交叉連接、埠口和 VLAN 可能沒有明顯故障，並不代表三層的 BGP 一定能建立。很多現場的問題，都卡在鄰居狀態一直停在 Idle、Connect、Active，或者已經走到 OpenSent 卻遲遲無法進入 Established。
排查這類問題，最怕的不是故障本身，而是順序錯了。有人先重開設備，有人先改路由策略，有人一口氣把所有設定全刪重來，結果把原本只是 VLAN 或 IP 的小問題，弄成一個更大的變更事故。正確的做法是先判斷 BGP 卡在哪一階段，再依序回頭查 AWS 端、本地設備、控制平面和過濾策略。
AWS帳號充值優惠 1. Idle、Connect、Active 通常代表什麼
如果鄰居長時間停在 Idle、Connect 或 Active，通常表示雙方的 TCP 179 還沒有真正建立起來。這一類問題多半不是 BGP 路由本身，而是更前面的連線條件沒有滿足。最常見的情況包括 VLAN 標籤不一致、子介面沒有正確綁定、peer IP 和 local IP 不在同一個可達網段、ACL 或防火牆擋住 TCP 179，或者本地設備沒有把封包送到正確的介面。
這個階段要記住一件事：只要 TCP 連不上，BGP 就不可能進入 OpenSent。與其盯著 BGP 計數器，不如先確認本地設備是否真的能對 AWS 對端位址送出封包並收到回覆。很多時候，問題比想像中簡單，只是配置沒對齊。
2. OpenSent、OpenConfirm 常見在哪些問題
如果鄰居已經進入 OpenSent 或 OpenConfirm，代表 TCP 多半是通的，BGP 的 OPEN 訊息也已經送出或收到。這時候要優先懷疑的，通常是 ASN 不一致、MD5 密碼不一致、BGP 功能參數不匹配，或某些設備的 timer、capability 協商失敗。簡單說，就是「線通了，但雙方對彼此的身分驗證或協商條件不認可」。
這一類問題的特徵很明顯：介面看起來正常，TCP 也有短暫建立，但鄰居很快又掉回去。這種反覆振盪通常比完全建立不起來更容易誤判，因為它會讓人以為只是偶發抖動。其實只要把 BGP debug、鄰居狀態和系統日誌對上，多半很快就能看出是 OPEN 協商階段出問題。
二、從 AWS 端先核對三件事
Direct Connect 的排查，不要只盯本地路由器，AWS 端的 Virtual Interface 狀態同樣重要。很多案例最後都發現，是虛擬介面建立好了，但 VLAN、peer IP、客戶 ASN 或對端 ASN 與本地設定不一致。因為 AWS 端的參數通常是控制台或 API 建立時就寫死的，後續只要有一邊改動，鄰居就會失敗。
- 確認 Virtual Interface 已經是可用狀態，而不是仍停在建立中或待驗證。
- 確認 VLAN ID 與本地子介面標籤完全一致，包含大小寫之外的數字本身也不能錯。
- 確認 customer ASN、Amazon ASN、peer IP、amazon side IP 都與控制台內容一致。
1. VLAN、ASN、Peer IP 是否與控制台一致
Direct Connect 雖然是專線，但在實作上往往還是靠 802.1Q VLAN 區分虛擬介面。也就是說，實體埠口 up 了，不代表你的流量真的進到正確的邏輯通道。只要 VLAN 錯一個數字，BGP 訊息就可能直接被送到不存在的子介面上，鄰居自然建立不起來。
ASN 也是同樣道理。AWS 端會根據你建立虛擬介面時填入的 ASN 來協商 BGP，如果本地設備使用了不同的 local-as，或者現場有多層路由設備做了轉發與重寫，最後傳到 AWS 的身分就可能和預期不一致。這種錯誤在多出口、多租戶或設備重整之後特別常見。
2. 先看 VIF 再看路由，順序不要反
不少人一開始就急著看路由表，結果越看越亂。其實正確順序應該是先確認 VIF 是否健康，再確認鄰居狀態，最後才看路由是否有正確宣告。因為沒有鄰居，後面所有路由學習和宣告都無從談起。換句話說，路由表空白不是原因，通常只是結果。
如果你在 AWS 端看到虛擬介面是正常的，但本地一直沒有鄰居，問題通常落在本地設備、鏈路標記或封包過濾。這時候先不要懷疑 AWS 路由控制，因為大多數 BGP 鄰居失敗，和 route filter 沒有直接關係。
三、本地設備排查：介面、子介面、BGP 三件事
本地設備是最常出問題的一端，尤其是跨團隊維運時，網路工程師以為線路團隊已經把埠口弄好，系統工程師以為 BGP 只要填上鄰居就會起來，結果真正的故障在子介面、MTU、ACL 或回程路徑上。要快速定位，就把本地設備拆成三層看：介面狀態、L3 位址、BGP 設定。
1. 介面 up 了，子介面不一定 up
很多人只檢查主介面是否 up，卻忽略了 BGP 實際跑在子介面上。若你使用 VLAN 子介面，必須確認該子介面的封裝標籤、IP 位址與掩碼都正確，且沒有被 shutdown。主介面亮燈不代表子介面已經具備收發三層封包的能力，這是最常見的認知落差之一。
如果現場是多條 Direct Connect 或帶 LAG 的環境，還要再檢查成員埠是否都正常、聚合是否一致、是否有成員埠被 err-disable 或流控異常。表面上看起來是一條線，其實底下可能有多個收斂點，任何一個都可能讓 BGP 卡死在半路。
2. IP 和掩碼錯一點，鄰居就起不來
BGP 鄰居建立失敗，最基礎但也最容易被忽視的，就是 IP 位址和子網掩碼。Direct Connect 的雙端位址通常很小，常見是 /30 或 /31。只要 local 與 peer 不在同一個網段，或者掩碼設定錯誤，路由器就不會把對端視為直連鄰居。這種情況下，即使你手動下了 neighbor 指令，BGP 也只能反覆嘗試連線。
還要特別注意位址重疊。若本地設備上已存在相同或重疊的網段，可能會導致系統把封包送往錯誤的路由表或錯誤的介面。這在使用多 VRF、多租戶或重複規劃位址時很常見。表面看似「能 ping 一下」，實際上回程卻走了另一條路，最後 TCP 三向交握無法完成。
3. ASN、MD5、Timer 要完全對上
AWS帳號充值優惠 BGP 的 OPEN 協商階段對一致性要求很高。ASN 不對，鄰居直接拒絕；MD5 密碼不對，TCP 能短暫建立也會被對方丟棄；hold timer 或 keepalive 設定差異太大，也可能讓 session 不穩定。這些參數看起來都只是小數字，但在 BGP 裡，差一個值就足以讓會話無法進入穩定狀態。
如果你有使用認證，請先確認雙邊是否真的都啟用了相同的密碼，且沒有中間設備重寫 TCP 封包。若本地路由設備曾經升級韌體，某些版本對 MD5 或 BGP capability 的處理也可能與舊版不同，這種情況常讓人誤以為是 AWS 端問題，實際上是本地設備行為改變了。
四、最容易忽略的四類阻斷
1. ACL、防火牆或安全策略擋住 TCP 179
不少團隊會在專線入口或核心區域加上安全策略，目的是避免非預期的路由鄰居接入，但規則寫得太嚴，也會把自己的 BGP 擋掉。BGP 使用的是 TCP 179，雙向都要能通，不能只允許單邊發起。若你在路由器、Firewall 或雲端安全設備上做了流量過濾，要確認沒有誤封這個埠號。
尤其在跨區或多防火牆路徑中，TCP 179 的回程常被忽略。封包可以從本地出去，回包卻被中間設備丟掉，這時候鄰居就會一直卡在 Active 或 OpenSent。排查時不要只看一台設備的規則，要沿著實際路徑一段一段核對。
2. NAT 參與了 BGP 流量
BGP over Direct Connect 本質上應該是直連通信，正常情況下不應經過 NAT。若你的架構中把路由協商流量丟進了 NAT 區，對端看到的來源位址就不再是你設定的 peer IP，這會直接破壞鄰居建立。這種錯誤在經過共享出口、邊界設備整合或臨時轉發策略時特別容易出現。
還有一個常見誤區，是管理人員以為只要能 ping 通就代表 NAT 沒問題。其實 ICMP 與 TCP 179 的處理邏輯完全不同，能 ping 不代表 BGP 能跑。只要路徑中有地址轉換、狀態檢查或策略重寫，就有可能讓 BGP 協商失敗。
3. MTU 或 LAG 一致性問題
Direct Connect 常會搭配 jumbo frame 或鏈路聚合使用。若雙端 MTU 不一致，某些設備在控制平面傳輸時雖然仍能送出小封包，但一旦 BGP 或其他協商封包被分段、丟棄或重組異常，會話就可能不穩。雖然 MTU 問題較少直接造成完全無法建立鄰居，但在反覆 flap 的案例裡很常見。
LAG 環境還要注意成員埠速率、FEC、雙工模式與聚合參數是否一致。實體層看起來正常，不代表聚合層真的健康。若一條成員埠有抖動、錯包或不對稱，控制平面也可能受到影響，讓 BGP 在建立過程中中斷。
4. 路由策略把回程切斷
嚴格來說，route map、prefix list、policy statement 通常不會阻止鄰居本身建立，但它們會讓你誤判故障位置。因為鄰居即使已經建立，如果沒有任何路由被接受或宣告，你看到的仍然像是「專線沒通」。所以當 session 真的建立後，還要確認路由政策沒有把雙方都擋掉。
AWS帳號充值優惠 實務上，先確認 session，再確認路由。不要一開始就把路由策略當成主因。很多人把重點放錯，花了一下午調 policy，最後發現是前面的 VLAN 就錯了。
五、按狀態定位，效率最高
如果只能用一條原則來縮小範圍，那就是「先看狀態，再看層級」。不同鄰居狀態對應不同問題方向，這比盲目翻配置快得多。
- Idle：先看配置是否啟用、介面是否真正 up、鄰居 IP 是否填錯。
- Connect 或 Active：先看 VLAN、子介面、ACL、TCP 179、NAT 與回程路徑。
- OpenSent：優先查 ASN、MD5、BGP capability、timer 與版本相容性。
- Established 但無路由：再看 route policy、prefix limit、宣告範圍與 AWS 端路由傳播設定。
這種分法的好處，是不用每次都把整個環境翻一遍。你只要知道 session 卡在哪一關，就能把排查範圍縮小到幾個最可能的點。這在值班或故障升級時尤其重要，因為時間越久，越容易在雜訊裡迷路。
六、實戰排查流程：照這個順序走，少走很多彎路
如果你現在就面對一條物理層正常但 BGP 起不來的 Direct Connect，建議直接照下面順序做，不要跳來跳去。
第一步，先在 AWS 端確認 Virtual Interface 狀態、VLAN、peer IP、customer ASN 與 Amazon ASN 是否正確。第二步，在本地設備確認主介面與子介面皆為 up，封裝標籤正確，IP 與掩碼沒有錯。第三步，檢查 BGP 鄰居設定，包含 remote-as、MD5、update-source、timer 與 VRF。第四步，排除 ACL、防火牆、NAT、LAG、MTU 與回程路徑。第五步，若仍無法建立，再使用設備日誌或封包擷取，觀察 TCP 179 到底卡在哪一段。
如果 session 能建立但很快掉線，就把重點放在日志與協商細節。如果 session 根本連不上，就不要急著研究路由政策，而是回頭查二層和傳輸路徑。把問題切準，通常很快就能收斂。
七、結語：專線通，不等於 BGP 通
AWS Direct Connect 的故障處理，最需要的是耐心和順序。線路通了，只代表最底層的承載沒有明顯問題；BGP 鄰居能不能建立，還要看 VLAN、IP、ASN、認證、策略和回程是否全部一致。只要你把排查順序定好，先看狀態，再看層級，先查控制平面，再查路由策略，絕大多數問題都能在不長時間內定位出來。
真正高效的排查，不是把所有可能都試一遍，而是根據鄰居狀態快速判斷故障落點。下次再遇到物理層已通、BGP 卻不上來的情況，先別急著重啟，先把這條路徑一項一項對齊，答案通常就藏在最前面的那幾個參數裡。
