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 <[email protected]>
> txfh2007 <[email protected]>
> ovs-discuss <[email protected]>
> 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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
