Thanks William. I am trying out your suggestions. Will keep you posted how it goes.
Meanwhile, I found another issue without any of my changes related to flooding and multiple tunnels in the same bridge. So, I initiated separate discussion. Would you mind comment on my flooding issue. I am thinking, if that issue is resolved, my Tx and Rx logic would also get simplified considerably. Here is the link <https://mail.openvswitch.org/pipermail/ovs-dev/2020-May/370067.html> for the flooding issue. -Vasu *Vasu Dasari* On Mon, May 4, 2020 at 7:03 PM William Tu <[email protected]> wrote: > On Fri, May 01, 2020 at 02:40:41PM -0400, Vasu Dasari wrote: > > Thanks William for your comments. > > > > > > *Vasu Dasari* > > > > > > On Fri, May 1, 2020 at 11:52 AM William Tu <[email protected]> wrote: > > > > > On Thu, Apr 30, 2020 at 08:42:04AM -0400, Vasu Dasari wrote: > > > > Hi, > > > > > > > > I am trying to implement a functionality, where in if user specifies > port > > > > through which a VxLAN encapsulated packet can be sent out, then use > that > > > > port rather than going through routing procedure. > > > > > > > > ovs-vsctl add-port br0 at_vxlan_fp1 -- \ > > > > set int at_vxlan_fp1 type=vxlan \ > > > > options:remote_ip=172.32.2.1 options:local_ip=172.32.2.100 \ > > > > options:dst_mac=00:00:00:00:01:02 > > > options:src_mac=00:00:00:00:01:01 > > > > \ > > > > options:out_port=1 > > > > > > > Why do you need to add dst_mac and src_mac? > > > Usually in the OVS kernel datapath case, OVS will consult the Linux > > > kernel's > > > arp table and get the src/dst mac address. > > > What if the manually set dst_mac here is different than the entry in > > > kernel? > > > > > > > > The goal is not to use Linux kernel's capabilities to determine which > path > > the tunnel to take. > > > > Imagine a set of switches in a fabric controlled by a controller and it > is > > used primarily for L2 services and some L3 services. If I were to use > Linux > > kernel to dictate which path to take, it would lead to using one bond or > a > > physical interface all the time for a particular destination switch. By > > doing so, there is no fabric diversity. Hence, as controller has view of > > the network, it can dictate which path/topology to take for a particular > L2 > > or L3 service. By using virtualized the fabric, I do not have to worry > > about about Mac pollution and loops (I can detail this separately if > > needed). And hence wanted to use VxLAN. > > > I see your use case, thanks! > William > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
