咱們都知道,對於企業來說,隨着業務的發展和重點不一樣,對網絡的實際需求也是不一樣的,尤爲是對於公有云的網絡架構,隨着AWS的功能完善和發展,愈來愈多的網絡功能得以實現。本文將結合實際案例講述如何以及爲何從DX過渡到DX gateway的node
企業上雲絕非一蹴而就的事情,這就意味着必然存在着一個本地雲與公有云共同存在的時期,這就涉及到了本地IDC與雲上IDC的互通問題。因咱們啓用業務上雲的方案較早,當時的 AWS還僅有DX的功能,經過此功能咱們可使用AWS合做夥伴專線將本地IDC與AWS鏈接起來。具體網絡架構以下:網絡
DX的出現,使得企業能夠經過DX的private VIF或者 public VIF將企業的分支/本地IDC與AWS鏈接起來。而爲了實現高可用性,通常不會僅創建一個DX通道,可能會採用以下冗餘方案:架構
因AWS DX功能比較弱,沒法經過AWS側設備實現路由的選路,這就致使咱們須要經過遠端局點的路由控制來實現主備路徑的選擇,從而使得兩條路徑互爲備份。app
若是要選擇ISP A的專線爲主用線路,則須要以下配置:ide
1.在Customer GW A上,從ISP A 的EBGP鄰居接收路由時,使用route-map修改local-preference的值,將local-preference設置的大於B線路的,使得IDC本地到AWS時,優選A線路。
2.同時,在Customer GW B上向B線路的EBGP鄰居發佈路由時,使用route-map修改AS-path屬性,在AS-path後增長几個as-path,使得AWS側接收到B線路的路由爲非優選路由。
3.固然,爲了切換便利性,咱們能夠一次性寫兩套A、B分別爲主用線路時的route-map,經過自動化工具,實現路徑的一鍵切換。工具
配置參考以下:code
Customer GW A上: route-policy IN_EBGP_A permit node 10 if-match ip-prefix AWS apply local-preference 200 route-policy OUT_EBGP_A permit node 10 if-match ip-prefix LOCAL_IDC route-policy IN_EBGP_B permit node 10 if-match ip-prefix AWS route-policy OUT_EBGP_B permit node 10 if-match ip-prefix LOCAL_IDC Apply as-path 64512 64512 add Customer GW B上: route-policy IN_EBGP_A permit node 10 if-match ip-prefix AWS route-policy OUT_EBGP_A permit node 10 if-match ip-prefix LOCAL_IDC Apply as-path 64512 64512 add route-policy IN_EBGP_B permit node 10 if-match ip-prefix AWS apply local-preference 200 route-policy OUT_EBGP_B permit node 10 if-match ip-prefix LOCAL_IDC
通過一段時間的運行和實踐,發現該方案有不少不足之處。好比,因DX功能限制,從ISP A學到的路由會向ISP B傳遞,從而致使路由環路或者專線路由條目超限的問題等。
在屢次踩坑以後,痛定思痛,進行了DX到DX GW的改造。對象
先看一下沒有DX gateway(如下簡稱DXGW)以前,若是要互聯VPC是什麼樣的?blog
有了DXGW以後,又是什麼樣的呢?ip
每一個DX Gateway都是跨全部公共AWS區域存在的全局對象,這就使得全部AWS區域之間能夠經過網關進行全部的通訊,大大減小了VIF的數量和BGP會話的數量,同時也簡化了網絡結構和維護成本。
更更重要的是,多了一個DXGW,至關於在DXGW側多了一臺路由器,路由多了一跳,從ISP A學到的路由不再會默認向ISP B發佈了,一勞永逸的解決了因DX功能限制而致使的路由環路和路由條目超限的問題。
改造爲DX GW以後,雙路徑的主備切換和DX時保持一致,仍是要經過企業本地IDC側CE 上BGP的選路來控制的。配置同:DX雙專線接入時,雙活的實現。
固然,如此便利的DXGW也有一些限制條件,並非任什麼時候候都適用,限制以下: