在上一期中，我们提到了，由于基于etcd的flannel存在种种限制，硬件SDN方案的开发工程师们研究出了通过CNI插件，让基于EVPN 硬件VXLAN网关的硬件SDN方案能够通过CNI插件，适配Kubernetes容器编排平台。这一类型的硬件SDN方案，最经典的有CISCO的ACI和H3C的SeerEngine。
由于CISCO的ACI中，私有协议的实现过多，我们先以SeerEngine SDN控制器为例：
假设我们已经熟悉了基于EVPN和VXLAN的硬件SDN方案，实际上可以很轻松地对二者做出对比——
- 对于OVS (宿主机或Node上的软件虚拟交换机)的配置：SeerEngine对接Neutron时，这一操作由OVS提供给Neutron的ML2 Mechanism Driver实现，而SeerEngine对接Kubernetes时，Kubelet在创建POD时，通过CNI的ADD操作，向SeerEngine传递POD的IP地址、网段等关键参数。SeerEngine控制器向OVS下发配置。
- 对于TOR和核心交换机的配置：SeerEngine对接Neutron和对接Kubernetes时，均由SeerEngine向TOR和核心硬件交换机下发EVPN等配置。
而这种方案的转发平面，与虚拟机体系中的转发平面类似。
我们先看同一个node内，两个pod之间的二层转发：
可见，这种情况下，OVS就可以自行搞定Node内转发，与其他方案别无二致。
当两个POD不在同一个VLAN(当然，也不在同一个网段）的情况：
如图，OVS会将来自VLAN 100的数据包增加VLAN 100的TAG，送到硬件交换机，进行三层转发，带着VLAN 200的TAG送回OVS，OVS剥离VLAN TAG送到目的POD。回程数据包也类似。
这种情况下，未知数据包的MAC/ARP学习过程，实际上和普通三层交换机的转发流程也是类似的。
再让我们看看复杂的跨TOR转发：
如图，两个POD都在VLAN 100中，但位于两个不同的TOR下。假设这两台TOR的underlay为10.1.1.254和10.1.2.254。
来自POD的数据包会在OVS上打上了VLAN 100的TAG送到TOR。由于TOR上配置了VLAN 100到VXLAN1001的映射关系，TOR会将这个数据包封装进VXLAN 1001。对端TOR解封VXLAN数据包，并将带着VLAN 100的数据包送到目的POD所在的Node上的OVS。目的Node上的OVS剥离VLAN，并将数据包送到目的POD，完成了二层转发的过程。
跨TOR的三层转发则采用分布式网关 对称IRB的实现：
如图，假设POD 100和POD 200分别在VLAN 100和VLAN 200，它们所在的TOR交换机的IP地址分别为10.1.1.254和10.2.1.254。
TOR交换机上配置的VLAN-VXLAN映射关系为VLAN 100-VXLAN 1001， VLAN 200-VXLAN 1002；
由于采用了对称IRB模型，需要公用的L3VNI，这个VNI的编号假设为8001；
POD 100向POD 200发送的数据包，在OVS上加上了VLAN 100的TAG。VLAN 100在TOR上映射到VXLAN 1001。
由于这是一个跨网段转发的数据包，目的MAC为VSI的MAC (对应的分布式网关IP为10.10.100.254)，数据包会被送到VSI 1001处理，进入三层转发流程。
TOR交换机查找目的IP，发现这是一个VXLAN 1002的IP地址，并且目的IP在远端TOR，它会做一次VXLAN RIOT，通过VXLAN的VNI为L3VNI 8001的VXLAN隧道，送到远端TOR 10.2.1.254。
远端TOR 10.2.1.254收到这一数据包后，查找路由表，并根据路由表做RIOT，将VXLAN的VNI替换为1002，然后映射回VLAN 200，剥离VXLAN头部，送到目的OVS，并最终被送到目的POD。
这样一看，SeerEngine控制容器网络时，转发平面的机制实际上与接管虚机 OpenStack Neutron网络的机制是一致的。
这正是：似曾相识燕归来！
这样一来，我们还可以赋予容器网络更多扩展的能力。
敬请期待下期。
