[ovs-discuss] Preserve vxlan headers when sending to a non-vxlan port on bridge?

[Jesse Gross]

On Thu, Aug 20, 2015 at 1:58 PM, Sam Hague <shague at gmail.com> wrote:
>
>
> On Thu, Aug 20, 2015 at 1:32 PM, Jesse Gross <jesse at nicira.com> wrote:
>>
>> On Thu, Aug 20, 2015 at 8:20 AM, Sam Hague <shague at 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.

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.