[ovs-dev] tunneling: RFC: Handle fully specified VxLAN tunnel port

[William Tu]

On Fri, May 01, 2020 at 02:58:11PM -0400, Vasu Dasari wrote:
> William, My comments are inline. Thanks.
> 
> On Fri, May 1, 2020 at 12:01 PM William Tu <u9012063 at gmail.com> 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.

I see. For xmit, the reason might be around
3652     err = tnl_neigh_lookup(out_dev->xbridge->name, &d_ip6, &dmac);
3653     if (err) {
3654         xlate_report(ctx, OFT_DETAIL,
3655                      "neighbor cache miss for %s on bridge %s, "
3656                      "sending %s request",
3657                      buf_dip6, out_dev->xbridge->name, d_ip ? "ARP" : "ND");

Where neighbor lookup fails to find the remote_ip's MAC address.

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

Can you aslo manually insert a flow for rx?
ex: in_port=<arriving physical port>, action=vxlan vport
William

> 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 <vdasari at gmail.com> 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
> > > dev at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >