咱们都知道,对于企业来说,随着业务的发展和重点不一样,对网络的实际需求也是不一样的,尤为是对于公有云的网络架构,随着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也有一些限制条件,并非任什么时候候都适用,限制以下: