VPC（全称是Virtual Private Cloud，做网络的同学尤其注意，不是思科vPC的virtual Port Channel）是AWS的云平台概念，OpenStack里并没有这一个内容；比较起来，VPC对应OpenStack的一个vRouter及其相关的 网络和子网等资源。通常来讲，Neutron的两个vRouter是相互隔离的，才能确保尤其是不同租户之间的安全性，但是在某些场景下存在两个VPC间 互通的需求，这种需求的解决方案在AWS里称之为VPC-Peering

（http://docs.aws.amazon.com/zh_cn/AmazonVPC/latest/PeeringGuide/Welcome.html
），这些场景举例来说：

1. 灾难恢复的场景，需要将VPC的数据同步到另一个VPC，实现容灾备份；AWS的VPC现在是不能跨Region的，特定VPC子网也不能跨AZ（Availability Zone），但AWS的VPC-Peering虽不支持跨Region，但支持跨账户；

2. 混合云中尤其是不同云平台的数据间通信时，使用VPC间通信也是可以的，但VPC通信并不是一种标准的通信特性或通信协议，所以会对管理平台或数据模型有一定匹配度要求；

3. 在云平台部署到众多DC规模较小且相互联接的情况下，通过VPC互通为节省用户数据通信的成本；

AWS的官网明确说明，“AWS 使用现有 VPC 基础设施创建 VPC 对等连接，既不是网关，也不是 VPN 连接，因此不依赖某个独立的实体硬件。没有单点通信故障也没有带宽瓶颈”，并且有如下主要限制

（http://docs.aws.amazon.com/zh_cn/AmazonVPC/latest/PeeringGuide/vpc-peering-overview.html#vpc-peering-limitations）：

1）无法在具有匹配或重叠的 CIDR 块的 VPC 之间创建 VPC 对等连接；
2）无法在位于不同区域中的 VPC 之间创建 VPC 对等连接；
3）只能为每个 VPC 创建数量有限的活动和待定 VPC 对等连接；
4）VPC 对等不支持传递的对等关系；
5）不能在相同两个 VPC 之间同时建立多个 VPC 对等连接；
6）通过 VPC 对等连接的最大传输单元 (MTU) 为 1500 字节；
7）不支持在 VPC 对等连接中进行单一地址反向传输路径转发；
8）置放组可以跨越对等的 VPC；但是，您不会在对等 VPC 中的实例之间获得完全等分的带宽；
9）一个实例的公有 DNS 主机名称不会跨对等的 VPC 解析为其私有 IP 地址。

AWS的VPC-Peering管理模型和建立过程与VPN有类似之处，需要建立一个通信认证机制和通信的状态管理，这些都是OpenStack控制面所缺少的，AWS的VPC-Peering通信状态机制如下：

相比于AWS的网络丰富特性之一，VPC-Peering，除了需要实现建立通信认证机制外，OpenStack的网络组件Neutron也并没有明确支持的对象，不过我们可以在现有Neutron能力基础上， 在此类讨论下有哪些可能的实现方案：

1）基于IPSec类似的端到端VPN

如果将两个vRouter之间建立一条端到端的VPN隧道，实现VPC互通是行的通的，但是这个方案对云平台的依赖度较高，就是说如果建立VPN隧 道是通过公网IP来进行，那么基本可以归结为VPN功能（这个时候的带宽和网络延迟就会有影响），特性也不是VPC-Peering了，所以需要对云平台 内网要求有一个内网网段和vRouter打通，让租户感知来创建基于内网的诸如IPSec VPN隧道。另外，还需要考虑到，IPSec自身是不支持组播和广播的，租户此类业务需要通过GRE+IPSec的技术租户来实现。

2）share network

基于OpenStack云平台的管理员可以使用Neutron来创建Shared类型的Network，这样基本所有租户都看的到并创建虚拟机在上面进行 通信，比如浮动IP的external-network基本是将Shared属性设置为True的。那么需要互通的两个VPC网段的虚拟机可以都多出来一 个port连接到Shared network上实现VPC互通。这个Share Network为了防止占用公网地址成本高，可以选择一个大范围的私网地址段；这种方式

a）要求这个Shared network必须预先创建，且其网段范围有特殊要求，尽量减少与租户VPC网段地址重叠的影响；

b）该Share Network为管理员创建的，所以所有租户都可以看到并使用，这样就破坏了VPC的安全隔离性，需要不同VPC之间互通的时候做好安全控制；

3）VM连接跨VPC的network实现VNF

当一个租户的两个VPC想互通，可以简单的启动一个虚拟机实例，让该虚拟机同时连接到两个VPC各对应由互通诉求的网络上；该方案相比于AWS的VPC- Peering需要指定虚拟机的Fixd IP，并在虚拟机内部加载路由和过滤规则，实现指定网段地址的VPC互通；另外为了实现将某个VPC发往另一个VPC流量到该虚拟机实例进行中转，需要借 助Service chain或者策略路由的方式进行引流，然后让虚拟机实现VNF(Virtual Network Function)的功能打通VPC通路。

但是该方案若是有需求实现两个租户其各自一个VPC之间互通时，因为没有任何一个租户可以看到对端的资源，所以就会产生创建虚拟机时连接网络的权限问题，需要借助管理员创建虚拟机来打通两个VPC；这无疑为VPC互通时租户的管理和维护带来不方便。

4）借助Gre/Vxlan等隧道模式

最后说一种业界比较常用的方案，就是在两个vRouter之间建立一条Gre或Vxlan的内网新隧道，该方案原理上与Share Network类似，都是使用一个新的隔离域，但是仅是两个VPC间私有，不为其他VPC共享。该方案中的Gre或Vxlan隧道隔离域值可以是 Neutron从预留的范围里面进行分配，然后借助SDN控制器打通整条链路的通道，从而实现两个VPC间的互通，猜测AWS的VPC-Peering的 实现是基于此方案。但是该方案需要针对Neutron进行特定的开发，而且使用成本也相对较高，当然所能使用的带宽和延迟等性能指标，也会较好。

当然，当Neutron的租户网络使用Vxlan时，VPC间通信使用另一种隔离方式比如Gre思路会比较清晰，但是数据转发面实现和运维相对会增加复杂度。

总之，基于Neutron的VPC间通信方案还没有社区的统一实现，各种方案成本、可靠性、性能、隔离性和可维护性等不太相同，需要根据自己的业务实际情况和技术积累，选择合理低成本的方案。