[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Preserve vxlan headers when sending to a non-vxlan port on bridge?
From:       jesse () nicira ! com (Jesse Gross)
Date:       2015-08-26 0:08:56
Message-ID: CAEP_g=8NsFEH1-BwbHu-fRbrtpSxAe4KVo1XPy6cmvLK=M6NUw () mail ! gmail ! com
[Download RAW message or body]

On Fri, Aug 21, 2015 at 7:24 PM, Sam Hague <shague at gmail.com> wrote:
> On Fri, Aug 21, 2015 at 8:57 PM, Jesse Gross <jesse at nicira.com> wrote:
>> 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.
>
>
> 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.

[prev in list] [next in list] [prev in thread] [next in thread]