On Fri, Aug 21, 2015 at 7:24 PM, Sam Hague <sha...@gmail.com> wrote: > 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.
Yes, as I said before, this is not specific to OVS or VXLAN. You can't expect to send a packet destined to the local host's IP address and expect the stack not to consume it. If there is no VXLAN listener, it still won't get forwarded - you'll get an ICMP unreachable message. Fundamentally, there are two communication paths here: remote vSwitch to local vSwitch and local vSwitch to VM. I think you need to actually model it this way rather than as forwarding, otherwise you will be forever running into addressing problems. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
