[neutron] OVS tunnels and VLAN provider networks on the same interface

Sean Mooney smooney at redhat.com
Wed Jun 23 14:04:14 UTC 2021


On Wed, 2021-06-23 at 15:50 +0200, Krzysztof Klimonda wrote:
> 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?
you can do takgin with openflow rules or by taggin the interface in
ovs.

the l2 agent does not manage flows on the br-ex or your phsyical bridge
so you as an operator are allowed to tag them
> 
> What if I want ovs to handle only a subset of VLANs and have other
> directed to the host?
you can do that with a vlan subport on the ovs port but you should
ensure that its outside of the range in the ml2 driver config for the
avaible vlans on the phsynet.

>  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,
> > > 
> > 
> > 
> > 
> > 
> 
> 





More information about the openstack-discuss mailing list