William, My comments are inline. Thanks. On Fri, May 1, 2020 at 12:01 PM William Tu <[email protected]> wrote:
> 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. > I am using a flow of this sort to direct access side traffic to a vxlan tunnel port. ovs-ofctl add-flow br0 priority=1,in_port=ovs-ap0,actions=at_vxlan_fp1 But, at_vxlan_fp1 is a virtual-port riding on a physical port "out_port". There is a lot of logic in native_tunnel_output() which I do not claim to understand completely but understanding that part with experimentation. For the packets to move from at_vxlan_fp to "out_port" leave the switch from "out_port" I think we need "NORMAL" flow. To prove out the idea, I have added a new field called "out_ofp_port" to xlate_ctx data structure in ofproto-dpif-xlate.c, and this field would be used to carry the out_ofp_port as passed by the caller, regardless of what Mac-learning table says. And this solved the transmit problem. Now I am have problem with receiving, that is, being able to classify the packet arriving on a physical port and map it to vxlan virtual port. Looks like this determination is done in classifier_rules. Currently trying to understand that logic. Any pointers to help me get there, it would be great. Thanks, -Vasu > > 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
