On Thu, Apr 30, 2020 at 08:52:38AM -0400, Vasu Dasari wrote: > This email is with the technical difficulty I am having with supporting > above feature. > > I have implemented all infrastructure necessary to support the > CLI, netdev-vport, netdev-native-tnl, etc, and currently debugging my way > through this. > > I am stuck in ofproto-dpif-xlate::native_tunnel_output(). What I see is > that, although this function has all the parameters needed to create > encapsulation header and know which odp_port to send it out of, it would > still rely on "NORMAL" flow to send out the packet. And "NORMAL" flow > relies on Mac learning table to figure out whether to flood or send it out > of a learned port. > > In this new case I am trying out, encap-dst-mac is not programmed in > Mac-learning table(as the encap-dst-mac and out_port are explicitly > specified and can be retrieved from netdev directly. And hence, > xlate_normal() would flood the packet out of all ports and would never > resolve dst-mac address as IP infrastructure on local machine is not > configured for the source-ip address. > > My question is: > 1. How can I accomplish sending out encapsulated frame without going > through "NORMAL" processing?
I don't think you need NORMAL flow. You can always add OpenFlow rules to redirect packets to your tunnel port. > 2. Any suggestions on how can I go about getting this done? > > Thanks > -Vasu > > *Vasu Dasari* > > > On Thu, Apr 30, 2020 at 8:42 AM Vasu Dasari <[email protected]> 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 > > > > This would create a fully specified tunnel port, it includes all L2 and L3 > > parameters needed to create encapsulated frame. This kind of syntax would > > mimic what is supported by off the shelf hardware like Broadcom. I also > > noticed that pica8's Openflow switch supports this kind of syntax as well > > (Configuring > > VXLAN <https://docs.pica8.com/display/PICOS2111cg/Configuring+VXLAN>) > > > > And the user could create flows of this sort to transport user packets > > with VxLAN payload: > > > > ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 > > ovs-ofctl add-flow br0 priority=1,in_port=at_vxlan_fp1,actions=ovs-ap0 > > > > > > I have initiated a discussion for this kind of request in June, 2019 at, > > ovs-discuss > > thread > > <https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048754.html>. > > And would like to use this thread for design and any other comments. > > > > > > Please let me know what you think. > > > > > > Thanks > > > > -Vasu > > > > > > *Vasu Dasari* > > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
