L2population是作用在br-tun桥上的，因此该功能只用于VXLAN、GRE等隧道方式的组网场景。同时可以支持Linux Bridge和Openvswitch。
根据前面文章的描述可知，br-tun上虽然提供了自学习功能的流表项，但是在未学习之前也只能通过泛洪机制来发送报文。既然neutron对所创建的虚拟机资源信息有全局的视野，即：neutron数据库存储了所有虚拟机的IP、MAC、虚拟机在哪台服务器等信息。既然有了这些全局资源，就可以在neutron-server测部署一个机制驱动，即：L2population机制驱动。通过这个机制驱动将这些虚拟机的全局资源信息推送到各个节点上的l2 agent(如：neutron-linuxbridge-agent和neutron-openvswitch-agent)。各个l2 agent收到这些信息后就可以自动化地创建隧道端口、单播流表项以及ARP Responder相关的流表。
L2population机制驱动大概的工作流程如下所示：
收到neutron port up事件后，会将对应虚拟机的信息以fdb_entry的形式同步给neutron-openvswitch-agent。neutron-openvswitch-agent会执行如下几个步骤：
首先判断本地是否存在和目标虚拟机在同一个segment(对于VXLAN而言对应的是VNI，对于VLAN而言对应的是VLAN ID)的虚拟机，如果存在，则和目标虚拟机所在的计算节点间自动创建隧道。如果不存在则不继续后面的处理。
建立隧道后，向br-tun桥上的table=22下发泛洪流表项，将新的隧道端口加入到泛洪的出端口列表中。
然后向br-tun桥上的table=21下发Arp Responder流表。
最后向br-tun桥上的table=20下发单播流表项，将后续发往目标虚拟机的数据包以单播的形式发送到目标计算节点上。
从上述的L2population工作流程来看，会在table=20下发单播流表项，这个流表项和前面介绍的自学习流表项都处于table=20，且是共存的。但是二者之间是有区别的。如下图1为Node2上的l2population流表项和自学习流表项的对比，其中红色为L2population下发的单播流表项，黑色为自学习流表项。功能都是一样的，即：匹配内部VLAN ID及目的MAC地址，然后剥离VLAN，打上隧道ID，再从学习到的端口单播出去。区别在于：L2population下发的单播流表项优先级较高(priority=2)，因此两条流表共存的前提下，只有L2population下发的流表项起作用，自学习的流表项是多余的。同时自学习的流表项还有超时机制，默认为300s超时(hard_timeout=300)。下图2为Node1上的L2population流表项和自学习流表项的对比，这里不再分析。
从上面分析得知，L2population流表项和自学习流表项共存时，自学习流表项是没有任何作用的。之所以保留自学习的功能是有些外部网络是neutron无法管控的，意味着无法下发对应的L2population流表项，因此保留自学习的方法来适应这些场景。
图1 L2population流表项和自学习流表项对比(Node2)
图2 L2population流表项和自学习流表项对比(Node1)
