I reckon that this approach makes sense, as it alters very little OVN's northbound schema; moreover at first glance I do not see in the patch series any change to the OVN pipeline.
Also mapping neutron provider networks extension onto OVN should not be too difficult. Perhaps neutron will have to do something to keep track of all the OVN logical switches composing a neutron provider network. Something might be added to this aim to the Northbound schema but I do not thing that it would be a requirement at this stage. Salvatore On 21 July 2015 at 17:59, Russell Bryant <rbry...@redhat.com> wrote: > v2-v3: > - Dropped first patch that was merged. > - Reorder remaining patches to put everything directly related to > the feature at the end and all of the pre-reqs at the beginning. > - Update flows to ensure that a packet that comes in via a localnet > port never goes out over a tunnel to avoid having multiple copies > of the same packet arrive at a chassis. > - This is still only tested using ovs-sandbox, but I think it's fine > to go ahead and review. Neutron integration and testing will > follow soon after. > - Follow-up work to do: > - add VLAN support for "localnet" ports > - create OVN admin manual that discusses OVN deployment and config > - make ovn-controller automatically create br-int if needed > - consider plain text file config support for ovn-controller > > Russell Bryant (10): > lib: Add smap_equal(). > ovn: Fix uninit access warning from valgrind. > ovn: Make column comparisons more generic. > ovn: Drop unnecessary br_int local variable. > ovn: Add bridge mappings to ovn-controller. > ovn: Add patch ports for ovn bridge mappings. > ovn: Set up some bridge mappings in ovs-sandbox. > ovn: Add type and options to logical port. > ovn: Get/set lport type and options in ovn-nbctl. > ovn: Add "localnet" logical port type. > > lib/smap.c | 34 ++++++++ > lib/smap.h | 2 + > ovn/controller/ofctrl.c | 2 +- > ovn/controller/ovn-controller.c | 173 > +++++++++++++++++++++++++++++++++++++++- > ovn/controller/ovn-controller.h | 7 ++ > ovn/controller/physical.c | 141 +++++++++++++++++++++++++------- > ovn/northd/ovn-northd.c | 42 +++++++--- > ovn/ovn-nb.ovsschema | 6 ++ > ovn/ovn-nb.xml | 27 +++++++ > ovn/ovn-nbctl.8.xml | 24 +++++- > ovn/ovn-nbctl.c | 111 ++++++++++++++++++++++++++ > ovn/ovn-sb.ovsschema | 6 ++ > ovn/ovn-sb.xml | 41 ++++++++++ > tutorial/ovs-sandbox | 3 + > 14 files changed, 570 insertions(+), 49 deletions(-) > > OpenStack Neutron as an API extension called "provider networks" which > allows an administrator to specify that it would like ports directly > attached to some pre-existing network in their environment. There was a > previous thread where we got into the details of this here: > > http://openvswitch.org/pipermail/dev/2015-June/056765.html > > The case where this would be used is an environment that isn't actually > interested in virtual networks and just wants all of their compute > resources connected up to externally managed networks. Even in this > environment, OVN still has a lot of value to add. OVN implements port > security and ACLs for all ports connected to these networks. OVN also > provides the configuration interface and control plane to manage this > across many hypervisors. > > Let's start from how this would be used from Neutron and go down through > OVN to show how it works in OVN. > > Imagine an environment where every hypervisor has a NIC attached to the > same physical network that you would like all of your VMs connected to. > We'll refer to this physical network as "physnet1". Let's also assume > that the interface to "physne1" is eth1 on every hypervisor. You would > need to first create an OVS bridge and add eth1 to it by doing something > like: > > $ ovs-vsctl add-br br-eth1 > $ ovs-vsctl add-port br-eth1 eth1 > > Now you must also configure ovn-controller to tell it that it can get > traffic to "physnet1" by sending it to the bridge "br-eth1". > > $ ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet1:br-eth1 > > When ovn-controller starts up, it parses the bridge mappings and > automatically creates patch ports between the OVN integration bridge and > the bridges specified in bridge mappings. > > Now that ovn-controller on every hypervisor understands what "physnet1" > is, you can create this network in Neutron. The following command > defines a network in Neutron called "provnet1" which is implemented as > connecting to a physical network called "physnet1". The type is set to > "flat" meaning that the traffic is not tagged. > > $ neutron net-create provnet1 --shared \ > > --provider:physical_network physnet1 \ --provider:network_type flat > > (Note that the Neutron API supports specifying a VLAN tag here, but that > is not yet supported in this patch series but will be added later as an > addition.) > > At this point an OpenStack user can start creating Neutron ports for VMs > to be attached to this network. > > $ neutron port-create provnet1 > > When the Neutron network is defined, nothing is actually created in > OVN_Northbound. Instead, every time a Neutron port is created on this > Neutron provider network, this connection is modeled as a 2-port OVN > logical switch. > > At this point, we can model what would happen by using ovn-nbctl. > Consider the following script, which sets up what Neutron would create > for 2 Neutron ports connected to the same Neutron provider network. > > for n in 1 2 ; do > ovn-nbctl lswitch-add provnet1-$n > > ovn-nbctl lport-add provnet1-$n provnet1-$n-port1 > ovn-nbctl lport-add provnet1-$n provnet1-$n-port1 > ovn-nbctl lport-set-macs provnet1-$n-port1 00:00:00:00:00:0$n > ovn-nbctl lport-set-port-security provnet1-$n-port1 > 00:00:00:00:00:0$n > ovs-vsctl add-port br-int lport$n -- set Interface lport$n > external_ids:iface-id=provnet1-$n-port1 > > ovn-nbctl lport-add provnet1-$n provnet1-$n-physnet1 > ovn-nbctl lport-set-macs provnet1-$n-physnet1 unknown > ovn-nbctl lport-set-type provnet1-$n-physnet1 localnet > ovn-nbctl lport-set-options provnet1-$n-physnet1 > network_name=physnet1 > done > > This creates 2 OVN logical switches. One port on each logical switch is > a "normal" port to be used by a VM or container. The other is a special > type of port which represents the connection to the provider network. > The special port has a type of "localnet" and a type-specific option > called "network_name" which maps to the value we put in > "ovn-bridge-mappings". > > When ovn-northd processes this, the logical Pipeline is no different > than it would be for 2 "normal" logical ports on a logical switch. As a > result, the OpenFlow flows that implement the logical pipeline also > remain unchanged. > > ovn-northd copies the "type" and "options" columsn from the logical port > in OVN_Northbound to the Binding table in OVN_Southbound. With that > information, ovn-controller can wire things up appropriately. > Specifically, the changes are in ovn-controller's code that does the > logical to physical mappings and creates the associated OpenFlow flows. > > Here is the final state of the system using ovs-sandbox using this > example. First, here's a list of the bridges and ports: > > $ ovs-vsctl show > 1500b021-0bd4-447c-b79f-4ca91a982c46 > Bridge "br-eth1" > Port "patch-br-eth1-to-br-int" > Interface "patch-br-eth1-to-br-int" > type: patch > options: {peer=br-int} > Port "br-eth1" > Interface "br-eth1" > type: internal > Bridge br-int > fail_mode: secure > Port "lport1" > Interface "lport1" > Port "lport2" > Interface "lport2" > Port br-int > Interface br-int > type: internal > Port "patch-br-int-to-br-eth1" > Interface "patch-br-int-to-br-eth1" > type: patch > options: {peer="br-eth1"} > > Before showing the flows, here are the OpenFlow port numbers for the > ports on br-int: > > patch-br-int-to-br-eth1 -- 1 > lport1 -- 2 > lport2 -- 3 > > Finally, here are the flows (with unimportant pieces stripped) related > to physical-to-logical and logical-to-physical translation: > > table=0, priority=100,in_port=2 > actions=set_field:0x1->metadata,set_field:0x1->reg6,resubmit(,16) > table=0, priority=100,in_port=3 > actions=set_field:0x2->metadata,set_field:0x3->reg6,resubmit(,16) > table=0, priority=100,in_port=1 > actions=set_field:0x1->reg5,set_field:0x2->metadata,set_field:0x4->reg6,resubmit(,16),set_field:0x1->reg5,set_field:0x1->metadata,set_field:0x2->reg6,resubmit(,16) > table=0, priority=50,tun_id=0x1 actions=output:2 > table=0, priority=50,tun_id=0x3 actions=output:3 > ... > table=64, priority=100,reg6=0x1,reg7=0x1 actions=drop > table=64, priority=100,reg6=0x2,reg7=0x2 actions=drop > table=64, priority=100,reg6=0x3,reg7=0x3 actions=drop > table=64, priority=100,reg6=0x4,reg7=0x4 actions=drop > table=64, priority=50,reg7=0x1 actions=output:2 > table=64, priority=50,reg7=0x2 actions=output:1 > table=64, priority=50,reg7=0x3 actions=output:3 > table=64, priority=50,reg7=0x4 actions=output:1 > > As a variation to this example, consider the same set of OVN switches > and ports, but for a hypervisor where the logical ports are on a > different chassis. When a packet comes in on a localnet port, a bit is > set in reg5 to remember that it came in on a localnet port. When doing > logical-to-physical translation for output, a packet is only sent out on > a tunnel if it did *not* arrive on a localnet port. > > table=0, priority=100,in_port=1 > actions=set_field:0x1->reg5,set_field:0x1->metadata,set_field:0x2->reg6,resubmit(,16),set_field:0x1->reg5,set_field:0x2->metadata,set_field:0x4->reg6,resubmit(,16) > ... > table=64, priority=100,reg6=0x2,reg7=0x2 actions=drop > table=64, priority=100,reg6=0x4,reg7=0x4 actions=drop > table=64, priority=100,reg6=0x1,reg7=0x1 actions=drop > table=64, priority=100,reg6=0x3,reg7=0x3 actions=drop > table=64, priority=50,reg7=0x2 actions=output:1 > table=64, priority=50,reg7=0x4 actions=output:1 > table=64, priority=50,reg5=0/0x1,reg7=0x1 > actions=set_field:0x1->tun_id,output:2 > table=64, priority=50,reg5=0/0x1,reg7=0x3 > actions=set_field:0x3->tun_id,output:2 > > Thanks! > > -- > 2.4.3 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
