Open Stack

Thanks,

Does this assume that the ovs tunnel traffic is untagged, and there are no other tagged vlans that we want to direct to the host instead of ovs?

What if I want ovs to handle only a subset of VLANs and have other directed to the host? That would probably work with with my second option (modulo possible loss of connectivity if vswitchd goes down?) but I'm not sure how to do that with ovs bridges - with normal bridge, I can make it vlan-aware but I'm not sure how this would work with ovs.

Best Regards,
Krzysztof 

On Wed, Jun 23, 2021, at 12:45, Sean Mooney wrote:
> On Wed, 2021-06-23 at 10:10 +0200, Krzysztof Klimonda wrote:
> > Hi All,
> > 
> > What is the best practice for sharing same interface between OVS
> > tunnels and VLAN-based provider networks? For provider networks to
> > work, I must "bind" entire interface to vswitchd, so that it can handle
> > vlan bits, but this leaves me with a question of how to plug ovs tunnel
> > interface (and os internal used for control<->compute communication, if
> > shared). I have two ideas:
> 
> you assign the ovs tunnel interface ip to the bridge with the physical
> interfaces. this is standard practice when using ovs-dpdk for example
> as otherwise the tunnel traffic will not be dpdk acclerated. i suspect
> the same requirement exits for hardware offloaded ovs.
> 
> the bridge local port e.g. br-ex is a interface type internal port.
> ovs uses a chace of the host routing table to determin what interface
> to send the (vxlan,gre,geneve) encapsulated packet too based on the
> next hop interface in the routing table. if you assgign the tunnel
> local endpoint ip to an ovs bride it enable an internal optimisation
> that usesa a spescial out_port action that encuse the encapped packet
> on the bridge port's recive quene then simple mac learing enables it to
> forward the packet via the physical interface.
> 
> that is the openflow view a thte dataplant view with ovs-dpctl (or ovs-
> appctl for dpdk) you will see that the actual datapath flow will just
> encap the packet and transmit it via physical interface although for
> this to hapen theere must be a path between the br-tun and tbe br-ex
> via the br-int that is interconnected via patch ports.
> 
> creating a patch port via the br-ex and br-int and another pair between
> the br-tun and br-int can be done automaticaly by the l2 agent wtih teh
> correct fconfiguration and that allows ovs to collapse the bridge into
> a singel datapath instnace and execut this optimisation.
> 
> this has been implemented in the network-ovs-dpdk devstack plugin and
> then we had it prot to fuel and tripleo depending on you installer it
> may already support this optimisation but its perfectly valid for
> kernel ovs also.
> 
> 
> > 
> > 1) I can bind entire interface to ovs-vswitchd (in ip link output it's
> > marked with "master ovs-system") and create vlan interfaces on top of
> > that interface *in the system*. This seems to be working correctly in
> > my lab tests.
> that inefficent since it required the packet to be rpcessed by ovs then
> sent to the kernel networking stack to finally be set via the  vlan
> interface.
> > 
> > 2) I can create internal ports in vswitchd and plug them into ovs
> > bridge - this will make the interface show up in the system, and I can
> > configure it afterwards. In this setup I'm concerned with how packets
> > from VMs to other computes will flow through the system - will they
> > leave openvswitch to host system just to go back again to be sent
> > through a tunnel?
> this would also work simiar t what i suggested above but its simpelr to
> just use the bridge local port instead. the packtes shoudl not leave
> ovs and renter in this case. and you can verify that by looking at the
> dataplane flows.
> > 
> > I've tried looking for some documentation regarding that, but came up
> > empty - are there some links I could look at to get a better
> > understanding of packet flow and best practices?
> > 
> > Best Regards,
> > 
> 
> 
> 
> 


-- 
  Krzysztof Klimonda
  kklimonda at syntaxhighlighted.com