前段时间有幸和国内的同行们交流了一番，发现形势大好。云，openstack，VMWare，SDN都开始有repeatable use case出现了，技术落地也越来越扎实。这是好事，大家加油。

这篇文章会用上篇文章中的概念继续聊如何在多租户数据中心里进行数据包的转发。在聊具体方案之前，大家先尝试回答一下这个问题：如果你是当初第一个设计多租户数据中心转发平面的架构师，openstack上的一个租户起了一个router，你会如何实现这个router呢？想清楚这个问题，多租户数据中心数据平面的大框架就有了，剩下的都是在为这个大框架添砖加瓦，小修小补。目前工业界有两大类方案，overlay和fabric。这两个方案完全不同，而他们之所以不同的最根本原因就是对上面这个问题的答案不同。

Overlay

这类方案的设计者是这样回答以上问题的：既然用户在orchestration系统上起了一个router，那我们也对应起一个router就好了。问题是这个router应该起在哪儿呢？在一台服务器上起一个软件router是最直接的选择(在多租户的概念刚兴起的时候，这甚至是唯一的选择)。于是这个orchestration系统中逻辑上的router就和一台软件router一一对应了。这台软件router很自然的便成了那个租户所有subnet的default gateway。一个很自然的问题便是：如果一个租户的vm和router不在同一台物理服务器上，那这个vm要如何才能够和这个router实现二层互联呢？两个最容易想到的选择便是：1) 通过配置vlan直接实现二层互联，2) 通过隧道实现layer2 over layer3。选项1)在实践中一直是一个很头疼的问题：给定任意的拓普，都能够动态的配置vlan，trunk和STP，这是整个网络行业解决了20年都没有解决好的问题。于是选项2)成了唯一的选择。

接下来的故事就非常顺理成章了：vxlan应运而生，用来打隧道以及通过VNI来区分更多数量的租户；一个软件router没有HA，于是先引入VRRP做冗余，之后是DVR；软件router的性能可能会成为瓶颈，于是DPDK相关的技术又迎来了春天。

笔者还是坚持一直以来的观点：所有的技术都是上层应用驱动的。如果最初的架构师们对以上那个问题给出了不同的答案，vxlan，DVR，DPDK这些技术就很可能不会有今天这样火爆了。

Fabric

这类方案的设计者对以上那个黑体字问题的回答完全不同：这个router应该实现在交换机上，因为这是交换机的专长。既然在多租户的数据中心里subnet并不和机架绑定，一个IP可能被orchestration系统分配到任何位置，那么这个router就应该分布式的实现在所有交换机上。

这是一个非常合理同时也非常大胆的回答。我们先来看看在这样的回答之下，一台交换机究竟在扮演怎样的角色。我们首先把目光关注在第一跳的交换机上 (如果是VM，那这第一跳交换机就是一台软件交换机；如果是bare metal服务器，那这第一跳交换机就是一台硬件交换机)。不管是软件还是硬件交换机，如果服务器发出的是二层报文，这台交换机就应该能够进行二层转发/广播；如果服务器发ARP要gateway的mac，这台交换机就应该做ARP reply；如果服务器发出的是三层报文，这台交换机就应该能够进行三层转发。例子举到这里，大家就会发现在fabric的解决方案里，一台交换机究竟是二层还是三层已经变得模糊，数据的转发平面需要进行精心的设计。在这类解决方案当中，最具代表性的是Big Cloud Fabric。

比较到这里，两类方案最大的区别就讲清楚了：在overlay方案里，default gateway往往在某一台物理服务器上；在fabric方案里，default gateway在第一跳的交换机上。不少方案就是在这两种极端的解决方案之间寻找一个折中：比如有些方案会把tunnel打在硬件交换机上，用来保证性能以及满足bare metal用户的需求。关于两种方案的优劣，笔者之前已经聊了不少(文章4，文章10)。从各个角度来看，笔者依然坚定的认为fabric是在技术上更加优秀的方案。在之后的文章中，笔者会对fabric方案中，default gateway之后究竟会发生什么进行进一步讨论。

本文系BigSwitch工程师吴鑫授权发布，如需转载请注明出处和链接