[闲话] 聊一聊阿里云的“云上网络”

这篇来跟大家聊一下阿里云的“云上网络”，我当然没有在阿里云工作过，所以我不可能知道承载阿里云的那张大网是什么样子的，但是作为阿里云的一个用户，我知道阿里云的“云上网络”是什么样子，也就是 VPN，高速通道，云企业网 这些“云网络产品”。

这篇文章所讲的内容很有可能会过时，譬如，去年我写过的一个Cisco路由器和阿里云VPC通过IPSec VPN连接的一个“奇怪”配置方法，今年可能就没什么意义了，因为阿里云的IPSec VPN总算是追平了AWS，既支持了VTI隧道，也支持了BGP。

有哪些上云的方式？老三样——

• 针对个人终端的SSL VPN
• 针对站点的IPSec VPN
• 针对站点的专线

画个图大概是这个也样子的——

每个阿里云上的VPC至少要有一个路由表，在路由表里，你会看到四种路由区分—— 系统/自定义/云企业网/BGP ，我在去年玩阿里云的时候，它还没有这么多类型。

IPSec VPN去年还不支持动态路由协议，也不支持VTI隧道，你只能配置感兴趣流的模式，我利用地址借用的特性，在Cisco路由器上搞了一把骚操作，实现了路由器一侧可以具备VTI接口的模式。

挖个坟，去年的骚操作见这里——

蓝莓的铲屎官：[Router] 一个略显"奇怪"的IPSec VPN配法

专线经历了两种形态，第一种形态是高速通道业务，很明显是对标AWS的Direct Connect，第二种形态是云企业网。

我们算是用VBR比较早的用户，目前我们仍有一对儿高速通道业务的VBR，其甚至不支持转换到云企业网，早期也没有BGP，以 静态路由+健康检查 的形式交付的。高速通道业务在VBR和VPC之间还夹了一个名字很土的东西——VBR上联。嘛，意思倒是表达的很清楚，VBR上联云端是吧。

云企业网是阿里云现在主推的产品，有些feature甚至是AWS也没有的，比如云端的路由策略。在连接AWS的时候，我完全靠IDC一侧的双向路由映射来控制路由。然而让我颇为不爽的是，阿里似乎总喜欢重新发明轮子，譬如我们所熟知的LPM(最长前缀匹配)，在阿里云上表现为了两种不同的形式——

• 在VPC里，不知是不是由于历史原因，阿里云的规则是—— 高速通道的静态路由可以比云企业网传播过来的路由更明细，但反过来不行，如果云企业网的路由更明细，这条路由就无法进入VPC。 还是个限定了条件的LPM。
• 在CEN中，这个功能被描述为 路由重叠 ，在我第一次测试CEN的时候，阿里云还没有这个功能，后来才加进来的。而且文档还写的有显而易见的Bug，前几天的想法里已经吐槽过了，这里不再多说。

LPM是路由器最最基本的选路原则，可说是全世界共识的一个功能，随便买个tplink都支持的东西，而阿里云自作聪明的给它加了各种特效，CEN还单独做成了一个feature，真是让人哭笑不得。

由VPC里关于LPM的神奇限制，还引出了阿里独有的平滑迁移至云企业网的方案，你要说行不行嘛，那也是行的，就是怎么看怎么蠢到家了——

• 先把指向高速通道的静态路由拆的更细，比如/16拆成两个/17
• 通过BGP传递/16的路由到CEN
• 由于高速通道的静态路由可以比CEN传播的路由更细，所以CEN的路由将可以传播至VPC
• 这样你的VPC里就有了基于LPM这个原则实现的路由备份，切换的时候，只要删掉/17的静态路由，/16的路由就可以生效了......
• 真TM神来之笔

VPN网关

本想创建一个VPN网关，但是发现不像AWS那样按流量后付费，也找不到后付费的选项，遂放弃，还是太小家子气了。

就翻翻文档好了——

建立VPC到本地数据中心的连接（BGP动态路由）_IPsec-VPN入门_VPN网关-阿里云

友情提示，不要尝试跨国直接建立IPSec VPN，甚至跨省都不要去想，除非你想感受抖动的乐趣。在超远距离的情境下如果要提供稳定可靠的服务，一个二层/三层的虚拟网络服务是必要的，在这点上传统的MPLS运营商和阿里云的云企业网，其实没有什么太大的差别，依赖云你就上阿里云，依赖AWS你就上AWS，谁都不依赖你就买第三方的MPLS VPN。

VBR

这个我有现成的，可以直接截图了！

从产品分类上来看，VBR仍然被视为高速通道的一部分，这其实挺怪异的，这导致我在将其和CEN关联后，还要在云企业网和CEN的页面之间反复横跳。AWS在这方面做的就比较好，它清楚的区分了VGW和TGW这两个独特的实体，所有的网络连接，无论是VPN还是Direct Connect，都和VGW或者TGW相关联，实际中取决于用户的用法，这种层次分明的结构深得我心，反观阿里云，则完全是搭积木的风格，东一块西一块的拼起来，不同的网络产品的文档，描述，都缺乏一致性，属于那种一眼看过去就知道它们不是自上而下设计过的产品。

VBR通常和物理专线相关联，但我们一般是由专线供应商来开通VBR，然后直接推送到我们的账号上，所以在我们这边看到的VBR，编辑它的时候，VLAN ID都是已经确定的，可以自由调整的，只有VBR和IDC的互连IP地址。

具体点入一个VBR中，看到是这样的页面

物理专线接口显示实际的物理专线信息，路由条目自然就是你收到的路由，在早期没有BGP的时候，这里要对上VPC和对下IDC写两条静态；BGP组有点像是peer-group的意思，BGP邻居就是BGP邻居了；云企业网授权似乎和跨账号有关，我们没有用到；对等连接是没有云企业网时的功能，VBR上联和VPC互连就是在这里创建的。

创建CEN实例后，则可以将VBR加载到CEN中。

如果出现前文讲到的，加载到CEN的VBR收到了一条和静态指向高速通道同样前缀的路由，或者CEN收到的路由更明细（比如极端点的，/32），它都会显示为冲突——

CEN 云企业网

云企业网的想法和概念还是蛮好的，只不过，阿里云推销云企业网的方式让人哭笑不得。有些功能，譬如SLB为IDC的后端提供服务，直接告诉你不支持高速通道，强绑定云企业网，还有我们在连接AWS的时候，阿里云跑来推销说，通过云企业网去连接，拜托，放着那么多成熟的专线供应商我不选，我选你这玩意在中间倒一手路由？我又不傻。

实质上就是一个三层的虚拟网络实例，云企业网本身不特别，承载云企业网的那张骨干网才比较有趣。可惜看不到。

CEN的使用限制还是蛮多的

使用限制_产品简介_云企业网-阿里云

从这些使用限制中，仍然可以很清晰的看出阿里云的网络产品最大的问题——割裂，缺少成体系的设计。这很明显就是不同的产品研发基于需求各自开发，最后坐在一起开了无数次会以后，拼凑出来的产品。比如其中有一条——

当你在VPC里创建NAT网关的时候，NAT网关会创建一条默认路由，让人哭笑不得的地方又来了，这条默认路由会被系统尝试放到CEN里去，然后显示为冲突，虽然实际上无影响，但看起来就是很怪异，你还要额外再去撤回掉这条默认路由的通告。

另一个比较落后的地方是关于计费的——

计费说明_产品定价_云企业网-阿里云

以预付费形式卖带宽包，和VPN网关那个路数一样，我建议阿里云好好研究下AWS的计费方法，看看人家是怎么带给用户一个好的使用体验的同时还把用户给lock住的。AWS的计费很有趣，上云的流量不收钱，下云的流量收，甭管什么东西都是先用后付，资本主义真是邪恶无比。

CEN最大的亮点还是路由策略，这是我在AWS没见到的，我觉得很不错的一个功能。

路由策略概述_路由策略_用户指南_云企业网-阿里云

界面大概长这样——

可以配置比较复杂的路由策略来控制入站和出站的路由，难怪阿里云敢把自己作为三层传输来卖。

然而功能再强的三层传输，也不如一根二层通道来的更有吸引力，而无论多低的延时，经过三层网络转发的总延时，还是不如你买条波分通道甚至拉条裸光纤来的快，而在那些真正会用到一张三层传输网络的场景里，CEN的覆盖面又不太够，譬如大量的分散的分支机构。

Anyway，支持这么丰富的路由策略总归是一件好事情，毕竟是做出来了AWS没有的东西，值得鼓励。

小结

阿里云在引入CEN之前的网络产品，可以说是非常l~o~w的，和AWS相比基本上就没什么战斗力。CEN一定程度上挽回了点面子，在路由策略上甚至还赢了一手，但总的来说，还是比AWS差点火候，尤其是在计费上，资本主义真是太了解用户了，阿里还得再想想计费要怎么做。

另外无论是阿里云还是AWS，在QOS上能提供的东西都很少，几乎没有。这也导致对于我这样内部还有多租户区分的用户，只能依靠加设备，做shapper或者做子接口的方式来进一步拆分资源，为内部的多用户提供服务。

最后，虽然我对CEN和VPC之间神奇的LPM限制表达了强烈不满，但换个角度想想却也能理解这种做法，CEN是个新设计的产品，用这种方式或许是无奈之举。

AWS也好，阿里云也罢，云上网络产品实际上都没有什么实质的创新，这也好理解，毕竟底层依赖的技术可创新的东西就不是很多，云上网络产品实际上是乘上了AWS和阿里云其它产品的风才起来的，毕竟业务在哪，才最终决定网络用谁家的，而不是网络谁家做的好，我就用谁家的虚拟机。

既然如此，又何必做那么多稀奇古怪的设计，照着传统的路由器的设计思想设计就好了，那都是现成的东西。路由实际上已经是一个非常成熟的体系，它发展的足够久了，云厂商在对网络，对路由做太多的进一步封装其实没有太多意义，除了给用户增加困惑和苦恼之外。我虽然褒奖了AWS的很多，但实际上AWS的使用体验也很糟糕，尤其是你试图部署一个网络厂商的虚拟机进去的时候，那基本上是不可运维的。

哦对了，AWS实现了VPC内的真实MAC地址学习的，阿里云则完全依赖网关ARP代答，这点还是落后了人家一大截。

碎碎念

其实这篇写的可能不怎么好，因为我没有对阿里云的网络产品像AWS那样做很多的尝试和测试，有几方面原因，一方面专线这种东西不是说有就有的，我们也是手里有资源了，才试着用一下，另一方面则是阿里云的计费模式问题，包月模式让我们没什么去测试它的欲望。

其实现在我对云已经基本上没什么期待了，保持着一种，能通就行的态度，一旦上云之后，很多东西都变成了黑盒子，一个按钮点下去，并不能期待一切都是正常的，譬如在连接AWS的时候，就碰到过TGW莫名其妙丢包的问题，还有神奇的IPSec VPN抖动，AWS的论坛上也有很多人在问这个问题，始终没有个有用的答案，连Debug你也只能看到抖动的大概原因，但你没办法解决，因为对端不是我们自己控制的路由器——路由器现在软件版本再不稳定，我们也总有那三板斧可以用，升级重启和RMA。

我甚至有时候在想，现在所谓的混合云，多云，是否只是一个变革中的时代的产物，客户仍然留有自建数据中心的执念，其实自建你也是被lock-in，上云你也是被lock-in，完全上云在我看来倒也不是那么非常难以接受啦。当然，做支付的公司，为了建立支付通道，有很多很多的专线，这些第三方专线现在都是和我们的IDC对接的，云怎么去对接他们？NAT做到哪里去？这些都还没有答案，混合的基础设施还将长期的存在下去。

云上也好，云下也好，真正的创新已经不在IaaS这一层了，现在都是更顶层的东西反向来驱动网络/计算/存储为它们服务，更何况基础设施始终逃不过，多个一个9就要多很多投入的魔咒，未来网工去向何方？我的答案其实很明确——网络世界的管道工，一群少不了，却又透明到不被关注的人。服务器和存储的工程师，大概就是泥瓦匠了。