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

William Tu u9012063 at gmail.com
Fri May 1 16:00:57 UTC 2020


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


More information about the dev mailing list