<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="margin:0px;font-family:Papyrus"><span style="letter-spacing:0px"><b><font size="2">Vasu Dasari</font></b></span></p></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 17, 2019 at 5:05 AM txfh2007 via discuss <<a href="mailto:ovs-discuss@openvswitch.org">ovs-discuss@openvswitch.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Ben & all:<br>
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?<br>
<br>
Thanks<br>
Timo<br>
<br>
+--------------+<br>
| vm0 | <a href="http://192.168.1.1/24" rel="noreferrer" target="_blank">192.168.1.1/24</a><br>
+--------------+<br>
(vm_port0)<br>
|<br>
|<br>
|<br>
+--------------+<br>
| br-int | <a href="http://192.168.1.2/24" rel="noreferrer" target="_blank">192.168.1.2/24</a><br>
+--------------+ +--------------+<br>
| vxlan0 | | vxlan0 |<br>
+--------------+ +--------------+<br>
| |<br>
| |<br>
| |<br>
<a href="http://172.168.1.1/24" rel="noreferrer" target="_blank">172.168.1.1/24</a> |<br>
+--------------+ |<br>
| br-phy | <a href="http://172.168.1.2/24" rel="noreferrer" target="_blank">172.168.1.2/24</a><br>
+--------------+ +---------------+<br>
| dpdk0/eth1 |----------------------------------| eth1 |<br>
+--------------+ +---------------+<br>
Host A with OVS. Remote host.<br>
<br>
<br>
Native tunneling and userspace tunneling are the same thing.<br>
<br>
The mechanism should be symmetric: configuration for sending packets out<br>
should also work for parsing them on the way back in.<br>
<br>
On Mon, Jul 08, 2019 at 03:57:46PM +0800, txfh2007 wrote:<br>
> Hi Ben:<br>
> 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 ?<br>
> <br>
> Thank you <br>
> <br>
> Timo <br>
> <br>
> <br>
> ------------------------------------------------------------------<br>
> Ben Pfaff <<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>><br>
> txfh2007 <<a href="mailto:txfh2007@aliyun.com" target="_blank">txfh2007@aliyun.com</a>><br>
> ovs-discuss <<a href="mailto:ovs-discuss@openvswitch.org" target="_blank">ovs-discuss@openvswitch.org</a>><br>
> Re: [ovs-discuss] Re：[HELP] Question about userspace geneve/vxlan port<br>
> <br>
> <br>
> On Thu, Jul 04, 2019 at 05:27:28PM +0800, txfh2007 via discuss wrote:<br>
> > I have found theoritically during the upcall process, task<br>
> > tnl_port_receive could be called(via upcall_cb() -> upcall_receive()<br>
> > -> xlate_lookup() ->xport_lookup). But in my env, after tracing code<br>
> > by gdb, I have found the task "tnl_port_should_receive(flow)" always<br>
> > returns "false" for flow->tunnel->ip_dst is "0", even if the pkt<br>
> > received by dpdk port has a tunnel header.<br>
> <br>
> Yes.<br>
> <br>
> > I guess the reason is in userspace task "handle_packet_upcall", the<br>
> > match.tun_md.valid has been set "false", so the expanded flow has no<br>
> > tunnel info, and also in task "miniflow_extract" in flow.c, the<br>
> > packet->md is null as in dfc_processing task the "md_is_valid" flag is<br>
> > always "false". Am I right ?<br>
> <br>
> Yes.<br>
> <br>
> OVS takes what some might consider an idiosyncratic approach to tunnel<br>
> processing. The "obvious" approach is to simply parse tunnel headers<br>
> and throw those into the flow. If OVS did that, then you'd see what you<br>
> expect, but this isn't what OVS does.<br>
> <br>
> Instead, OVS treats tunnel and their headers as metadata. This is<br>
> because of OVS's history as part of the Linux kernel. The Linux kernel<br>
> has tunnel implementations as part of the TCP/IP stack. When a tunnel<br>
> packet arrives at a physical port in Linux, it passes into the TCP/IP<br>
> stack, where it gets processed and received on a tunnel network device.<br>
> This effectively strips the tunnel headers and transforms them into<br>
> metadata. If the tunnel network device is part of an OVS bridge, then<br>
> it gets the packet at that point, and treats the metadata as something<br>
> that can be matched.<br>
> <br>
> With other datapaths, OVS expects some equivalent mechanism to exist.<br>
> For the userspace datapath, OVS implements "native tunneling" to provide<br>
> that mechanism. It's described in the OVS documentation.<br>
> <br>
<br>
_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
<a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
</blockquote></div>