On 01/13/2016 02:50 AM, Han Zhou wrote: > Currently we have "localnet" in OVN to connect VIF to physical network, > but there seems to be no way to support intra-hypervisor communication > with exiting model mentioned in ovn-sb.xml: > > <dt><code>localnet</code></dt> > <dd> > A connection to a locally accessible network from each > <code>ovn-controller</code> instance. A logical switch can only > have a single <code>localnet</code> port attached and at > most one > regular logical port. This is used to model direct > connectivity to > an existing network. > </dd> > > The reason is that packets going though patch port to external bridge > cannot return back to br-int through the same patch which is the in_port.
Yes, this was a pretty critical oversight. Sorry about that. > My proposal is that we can still use similar model as for overlay > networks: putting all VIF lports on a single lswitch, just adding an > extra lport of type localnet. With this model, intra-hypervisor (VIFs on > same hypervisor) communication is naturally supported in the same way as > for overlay. Packets to other subnets would also work properly because > default GW in this case will be in physical network, and ARP to the GW > will get a MAC that is unknown by the logical pipeline, thus packets to > the GW will go through the physical port only. > > However, some changes are required so that communication between VIFs of > same lswitch on different hypervisors to go through physical ports > rather than tunnels. (Maybe it does not matter whether the packets come > from tunnel or physical network from end user point of view, and it may > be interesting to have both overlay and physical connectivity at the > same time, but let's have the correct behaviour implemented first :)) > > The changes required would be: > > 1. For lswitches with localnet, set tunnel-key to -1 in datapath_binding > table in southbound db > 2. In ovn-controller, when building physical pipeline, if tunnel-key is > -1, then: > 2.1 Do not output to tunnel port for remote ports but use localnet > port instead. > 2.2 Do not include tunnel port for multicast. > > Please share your views on this. I can start on code changes if the > direction is right. The current model is really nice because it largely just fell into place. From OVN's perspective, really what OVN is implementing for every port is a simple 2-port switch (with OVN ACLs and such) between the VIF and physical network. The model you propose is what I tried to implement first, and it the implementation was much more invasive. I have another idea that could resolve this. Instead of having a single patch port, how about creating separate patch ports? It would be something like: create patch ports for every logical port with type=localnet that is on a logical switch with a locally bound logical port with type=<empty>. ovn-controller is already doing more dynamic patch port management since the implementation of logical routers, so maybe we can just build on that here. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
