方法2: 通过路由传播功能，控制明细路由

在 AWS VPC 网络中有一个特性，即如果存在到达路径的多个不同路由条目，则会选取最明细的一条路径。

举个例子，如果我们需要到达10.0.0.1的机器，目前路由表中有条目A（10.0.0.0/8，下一跳VGW-A），有条目B（10.1.0.0/24，下一跳是VGW-B），两个路由条目都包含了去目标机器的路由，但是 VPC 此时会选择条目 B，因为它更精细。

基于这个特性，我们也可以设计出在 Direct Connect 专线和 SDWAN 线路之间的动态路由切换机制。

首先到所有的 VPC 的相应路由表中，打开路由传播的功能，此功能默认是关闭的。

勾选传播这个选项，然后保存。

开启了路由传播功能之后，我们可以看到这个路由表已经收到了来自 Customer Gateway 的动态路由条目了。这里也是所有 SDWAN 网络里面包含的路由条目。

编辑路由表，将 SDWAN 的路由设置得更范围更大一些，让它不优先起作用。

我们到 SDWAN 控制台将 Direct Connect 线路手动断掉，并且我们保持 AWS 北京的一台客户端长期 ping 一个新加坡客户端的地址。

可以看到，在断开线路的一瞬间，我们可以看到路由表的 ”Propagated“ 路由条目中 ”Yes“ 的路由已经消失了，只剩下一些手动创建的路由条目。并且这些路由条目也能指引客户端找到访问对端的路径，并且这些路径是经过 SDWAN 网络过去的。

在整个切换过程中，持续的 Ping 只丢了3个包，切换时间还是非常迅速的。

同样，我们如果将 Direct Connect 线路恢复，这些动态路由也会在几分钟之内完全恢复。

优劣分析

第二种方法的切换时间更快，而且在出现专线故障的情况下，我们希望切换的这个过程越快越好，而如果专线恢复，我们对切换回来的时间要求相对就没那么高了。所以这个方法还是很符合实际的使用要求的。

但如果路由条目比较复杂，我们在编写泛路由的时候需要比较小心，而且也需要注意 VPC 中路由表条目的硬限制（100个路由条目）。

在业务连续性和 RTO (Recovery Time Objective) 要求比较高的情况下，非常建议在网络的设计中考虑到双设备，双线路的冗余。并且需要整个切换的过程自动化，对业务的影响最小。

本文提供的两种方法，各有优缺点：

AWS CLI 方法：能够集成更多功能，比如 VPC 路由表切换，SNS等，能为切换带来更多的操作可能性；但切换时间在3-5分钟不等。
路由传播方法：从 DX 切换到 SDWAN 的切换时间在3秒左右，反过来的切换时间在几分钟的时间内，并且操作更加简单，不涉及 IAM 设置和两套路由表以及监控脚本。

作者介绍：

!

### 肖培庆

亚马逊AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广。现主要负责初创企业行业解决方案，曾任职于IBM，联想，Avnet，多年大型企业网络架构和运维经验。

本文转载自AWS技术博客。