In a previous article I showed an analysis of the Openflow rules on the OVS bridge used for tunneling traffic between nodes.
Openstack Neutron offers an option to populate MAC entries on br-tun. In order to use this option, the mechanism driver l2population has to be added to the file ml2_conf.ini .
[ml2] type_drivers = vxlan,local,vlan,flat tenant_network_types = vxlan mechanism_drivers = openvswitch,l2population
When using the mechanism driver l2population, the openflow table 20 is prepopulated with MAC entries by the OVS agent. A snapshot of the Openflow rules from br-tun is shown below:
prepopulated MAC addresses on br-tun, together with learned MAC addresses
Without l2population, all rules which do not drop traffic are learned using the learning rule in table 10. These learned entries are inserted with priority=1 into table=20. All preconfigured rules by the l2population mechanism driver are inserted into table=20 using priority=2.
The flow through table=20:
- If the Vlan and destination MAC address of a packet is a valid entry with priority=2, the packet will be forwarded using the output port as specified in the action for the Openflow rule.
- If the Vlan and destination MAC address of a packet is a valid entry with priority=1, the packet will be forwarded using the output port as specified in the action for the Openflow rule.
- If no valid combination is found, the packet will be processed by the entry with priority=0 and is resubmitted to table=21. Table=21 is the packet flooding rule. Flooding is performed using unicast.
Benefits of using l2population
The advantage of using the mechanism driver l2population is very limited with the current (Icehouse) implementation. Practically only the traffic type „unknown unicast“ benefit from l2population. For all environments, the amount of unknown unicast traffic is very low.
The more important part to avoid the flooding of ARP requests is missing. ARP packet mangling by the OVS is supported starting with OVS version 2.1. Ubuntu 14.04 is using OVS 2.0.1. IPV6 ND is also not handled.
At least up to now (July 2014/Icehouse) the advantage of using l2population for the infrastructure is too low compared to the risk of running Neutron with l2population under high load conditions (RPC communication…).
I do not use l2population in Icehouse.
The next Openstack release Juno has the necessary code for the local ARP responder when the Openvswitch version 2.1+ is used on the OS layer.