Hi, Nick, On Thu, Jun 9, 2022 at 5:33 AM Nick Bouliane via discuss <[email protected]> wrote: > > Hi > > When vxlan is handled in the kernel, what I understand is that the > vxlan driver creates a fake socket that listens on the vxlan UDP port. > Then the UDP layer looks up for a socket corresponding to the port of > an incoming packet, and realizes it's a socket created by a tunnel. > > Then pass the vxlan packet to the vxlan driver. Then the vxlan driver > decapsulates and because the interface vxlan0 is enslaved to an OVS > bridge (br0)... it eventually just passes the inner packet to the OVS > bridge which sees a packet arriving from vxlan0. > > My question is.. what is happening when I have a whole setup in > userspace. What happens when I create a userspace vxlan interface in > an OVS bridge ? Does the OVS code start automatically checking all > packets arriving from any interface into a bridge to match if it's a > VXLAN packet it has to decapsulate ?
You can test userspace VXLAN like this: https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/, it could help to understand userspace vxlan. In fact, OVS always generates a DPCLS flow rule with TNL_POP action by the NORMAL OpenFlow rule to decapsulate packets received from the port connected to br-phy. > > Once the packets are decapsulated, can the packets be matched with > in_port= with the ofport of the vxlan0 ? You can use OpenFlow tun_id match field to distinguish the decapsulated tunnel packets on br-int. > > regards, > Nicolas > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -- Thanks, Harold. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
