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