[ovs-discuss] Re:Re: Re:[HELP] Question about userspace geneve/vxlan port

Vasu Dasari vdasari at gmail.com
Wed Jul 17 13:09:09 UTC 2019


I think author of example you referred to in userspace-tunnel.rst tried to
show a scenario where underlay and overlay networks are separated on two
different bridges. OVS does not need to have two separate bridges for
userspace-tunnel to work.

*Vasu Dasari*


On Wed, Jul 17, 2019 at 5:05 AM txfh2007 via discuss <
ovs-discuss at openvswitch.org> wrote:

> Hi Ben & all:
>     Another question about userspace tunnel: in userspace-tunnel.rst , I
> have found the tunnel port(vxlan port) and VM port(vhu port e.g.) should on
> the same bridge(br-int). Is this necessary ? Should the tunnel port on a
> different bridge ? can anyone explain the reason?
>
> Thanks
> Timo
>
>     +--------------+
>     |     vm0      | 192.168.1.1/24
>     +--------------+
>        (vm_port0)
>            |
>            |
>            |
>     +--------------+
>     |    br-int    |                                    192.168.1.2/24
>     +--------------+                                   +--------------+
>     |    vxlan0    |                                   |    vxlan0    |
>     +--------------+                                   +--------------+
>            |                                                  |
>            |                                                  |
>            |                                                  |
>      172.168.1.1/24                                           |
>     +--------------+                                          |
>     |    br-phy    |                                   172.168.1.2/24
>     +--------------+                                  +---------------+
>     |  dpdk0/eth1  |----------------------------------|      eth1     |
>     +--------------+                                  +---------------+
>     Host A with OVS.                                     Remote host.
>
>
> Native tunneling and userspace tunneling are the same thing.
>
> The mechanism should be symmetric: configuration for sending packets out
> should also work for parsing them on the way back in.
>
> On Mon, Jul 08, 2019 at 03:57:46PM +0800, txfh2007 wrote:
> > Hi Ben:
> >     Thanks for your reply ! I didn't find the "native tunneling"
> document in OpenvSwitch repository. Did you mean the document
> "userspace-tunneling.rst". this document just tells us the br-phy can send
> tunnel pkt out, but when dpdk type port receives pkts with tunnel hdr, how
> could I configure the "native tunnel" mechanism to parse and handle these
> pkts? Or what you mean is currently OVS cannot handle parsing tunnel pkts
> in userspace ?
> >
> >     Thank you
> >
> > Timo
> >
> >
> > ------------------------------------------------------------------
> > Ben Pfaff <blp at ovn.org>
> > txfh2007 <txfh2007 at aliyun.com>
> > ovs-discuss <ovs-discuss at openvswitch.org>
> > Re: [ovs-discuss] Re:[HELP] Question about userspace geneve/vxlan port
> >
> >
> > On Thu, Jul 04, 2019 at 05:27:28PM +0800, txfh2007 via discuss wrote:
> > > I have found theoritically during the upcall process, task
> > > tnl_port_receive could be called(via upcall_cb() -> upcall_receive()
> > > -> xlate_lookup() ->xport_lookup). But in my env, after tracing code
> > > by gdb, I have found the task "tnl_port_should_receive(flow)" always
> > > returns "false" for flow->tunnel->ip_dst is "0", even if the pkt
> > > received by dpdk port has a tunnel header.
> >
> > Yes.
> >
> > > I guess the reason is in userspace task "handle_packet_upcall", the
> > > match.tun_md.valid has been set "false", so the expanded flow has no
> > > tunnel info, and also in task "miniflow_extract" in flow.c, the
> > > packet->md is null as in dfc_processing task the "md_is_valid" flag is
> > > always "false". Am I right ?
> >
> > Yes.
> >
> > OVS takes what some might consider an idiosyncratic approach to tunnel
> > processing.  The "obvious" approach is to simply parse tunnel headers
> > and throw those into the flow.  If OVS did that, then you'd see what you
> > expect, but this isn't what OVS does.
> >
> > Instead, OVS treats tunnel and their headers as metadata.  This is
> > because of OVS's history as part of the Linux kernel.  The Linux kernel
> > has tunnel implementations as part of the TCP/IP stack.  When a tunnel
> > packet arrives at a physical port in Linux, it passes into the TCP/IP
> > stack, where it gets processed and received on a tunnel network device.
> > This effectively strips the tunnel headers and transforms them into
> > metadata.  If the tunnel network device is part of an OVS bridge, then
> > it gets the packet at that point, and treats the metadata as something
> > that can be matched.
> >
> > With other datapaths, OVS expects some equivalent mechanism to exist.
> > For the userspace datapath, OVS implements "native tunneling" to provide
> > that mechanism.  It's described in the OVS documentation.
> >
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190717/a91c1e67/attachment.html>


More information about the discuss mailing list