On Fri, Aug 21, 2015 at 8:57 PM, Jesse Gross <je...@nicira.com> wrote:
> On Thu, Aug 20, 2015 at 1:58 PM, Sam Hague <sha...@gmail.com> wrote: > > > > > > On Thu, Aug 20, 2015 at 1:32 PM, Jesse Gross <je...@nicira.com> wrote: > >> > >> On Thu, Aug 20, 2015 at 8:20 AM, Sam Hague <sha...@gmail.com> wrote: > >> > Is it possible to send vxlan encapsulated packets to a bridge port and > >> > keep > >> > the vxlan headers? > >> > >> It's not possible unless you don't terminate the tunnels, in which > >> case you can't match on anything in the header. > > > > > > Is the only way to add vxlan headers by sending a packet out a vxlan > port - > > whether the key/srcip/dstip are port or flow-based? > > Yes. > > > Is there any way to "overload" the vm port such that if I sent a vxlan > > packet froma normal vxlan port on the bridge it could come back into the > > bridge and to that vm port such that the vm would terminate the tunnel? > > > > The use case is for the typical openstack setup where the VMs are ports > > hanging off the bridge and flows are added to simply push normal l2-l4 > > packets to the port. But I would like to terminate vxlan inside the VM > > itself but under this constraint that is was OpenStack that instantiated > the > > VM in the way it typically does. > > > > So I could see adding some flows to send a vxlan packet out a port on the > > bridge, and somehow getting it to come back into the bridge and not have > the > > header stripped. Typically those VM addresses are internal addresses > which > > the host wouldn't know about so if I sent a vxlan out a bridge port, the > > network stack wouldn't send it back. > > Presumably, in this case the destination IP address is owned by the > hypervisor. In that case, the hypervisor IP stack is going to consume > the packet regardless of what the OVS or VXLAN configuration is. The > only way around that is either to actually address packets to the VM > (either on the remote side or by re-encapsulating the packet locally) > or hack together some rules to prevent the hypervisor IP stack from > seeing the packet altogether, likely using NAT. > Yeah, was hoping I could find the trickery to get around this. I assigned IP addresses to the two bridges and used those address as the src/dst for the vxlan tunnel - without adding a vxlan port on the destination bridge, thinking maybe it would sneak into the bridge as a l3 packet. But looks like somewhere in the stack the packet was identified as vxlan and got into OVS and OVS dropped it. I can't think of a way to address packets to the VM directly since the VM's address is an internal address that isn't visible outside the typical Openstack neutron vxlan overlay. That overlay is from bridge to bridge so not sure how to also get an overlay into the VM. When you mention NAT, I think I would still have the same issue right? Meaning I have to send the packet using vxlan so that I can get the payload encapsulated with vxlan. Once that happens I am stuck with the problem that somewhere that vxlan packet is getting consumed. Is there any other type of flows I can add to get these packets? > To answer your question from the other thread, the UDP dest port can't > be set by the flow. The reason for this is specifically to prevent the > situation you are trying to create - to receive packets, you need to > bind to the port ahead of time. >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
