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,