现有的Openstack服务商网络是基于VLAN或FLAT组网模式实现，其默认网关分布在物理交换机，因此物理交换机会接受默认网关IP的ARP请求。通常一台网络节点会虚拟化出数百个NAT网关，NAT网关外网口接入到Openstack服务商网络，因此会出现批量请求默认网关ARP的情况，而物理交换机批量接受ARP请求的容量是存在规格上限的，在面对大规模网络节点集群时很容易突破上限，进而导致物理交换机不可用，既浪费了昂贵的物理资源，同时严重影响了业务网络的转发及发展。为此提出一种改进的方法：利用Ryu+ARP代答技术，将服务商网络默认网关的ARP处理从物理交换机下沉到网络服务器，网络服务器利用Ryu控制器周期向物理交换机发送ARP请求Packet-Out报文以获取其MAC地址，接着利用OpenFlow流表拦截服务商网络默认网关的ARP请求并做本地代答。此方法有效避免了物理交换机直接大批量处理ARP请求，可有效地充分利用物理交换机的资源，同时能够适应大规模集群的场景。

1 当前的做法

  上图为现有Openstack服务商网络组网模型：

  1) 服务商网络默认网关分布在物理核心交换机。

  2) 一台网络节点上会虚拟化出数百个NAT网关，其外网口接入到服务商网络。

  3) NAT网关外网口请求默认网关的ARP。

  上述这种做法存在的问题：

  1) 当网络节点规模越来越大时，总的NAT网关越来越多，最终出现物理核心交换机大批量接受ARP请求进而突破硬件规格上限，导致核心交换机不可用，严重影响网络转发。

2 改进方案

  上图为改进后的Openstack服务商网络组网模型：

  1) 网络节点部署Ryu控制器，周期向核心交换机发送ARP请求Packet-Out报文，ARP回应报文上送Ryu控制器，学习到核心交换机的MAC地址。

  2) 网络节点上对OpenvSwitch编排ARP代答流表，拦截NAT网关发出的ARP请求，利用学习到的核心交换机MAC地址作本地代答。

  改进后：

  1) 有效避免了物理交换机直接面对大批量ARP请求，可有效地充分利用物理交换机的资源。

  2) 能够适应大规模集群的场景。

3 流表设计