1fda57f4b9
Current packet processing in br-tun is based on tun-id, as a consequence, two networks using different tunnel types but sharing the same tun-id would not be properly isolated. To ensure proper isolation within a single bridge, NORMAL action can't be used any more as it floods unknown unicasts on all bridges ports. It is replaced by a learn action that dynamically sets-up flows when packets are recieved from tunnel ports. As mac address are learnt in explicit flows (in table 20), we can use a default action in that table to flood unknown unicasts to the right set of ports, like broadcasts and multicasts packets. See https://wiki.openstack.org/wiki/Ovs-flow-logic for a more detailled explanation of the flow logic Another alternative could have been to use distinct bridges for each tunnel type (whithout modifying the current flow logic), but previous alternative may be preferable as it paves the way for new tunneling optimisations (like RPC based mac learning and partial-mesh flooding proposed in bp/l2-population) Change-Id: I1dfe74f96680c2c6fe4d8d4aac4821c6b020c005 Closes-Bug: #1196963
# -- Welcome!
You have come across a cloud computing network fabric controller. It has identified itself as "Neutron." It aims to tame your (cloud) networking!
# -- External Resources:
The homepage for Neutron is: http://launchpad.net/neutron . Use this site for asking for help, and filing bugs. Code is available on github at <http://github.com/openstack/neutron>.
The latest and most in-depth documentation on how to use Neutron is available at: <http://docs.openstack.org>. This includes:
Neutron Administrator Guide http://docs.openstack.org/trunk/openstack-network/admin/content/
Neutron API Reference: http://docs.openstack.org/api/openstack-network/2.0/content/
The start of some developer documentation is available at: http://wiki.openstack.org/NeutronDevelopment
For help using or hacking on Neutron, you can send mail to <mailto:openstack-dev@lists.openstack.org>.