netdev - Re: a vxlan question.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 12 Jan 2014 13:38:16 -0500
From:	sowmini varadhan <sowmini05@...il.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev@...r.kernel.org, sowmini.varadhan@...com
Subject: Re: a vxlan question.

On Sun, Jan 12, 2014 at 1:25 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:

> The VXLAN like all layer 2 tunnels is not allowed to respond IP packets
> in the inner header.

Ok, so I see that the other tunnels don't relay packets, but
I noticed that they do take note of  FRAG_NEEDED and
update the soft state (e.g., ipip_err)

> One of the principles of network virtualization
> is that the inner network IP space may overlap or be invalid in the
> outer IP domain. Therefore an intermediate system (like VXLAN) does
> not have a valid IP in the inner domain to send a response.

Understood. And I recognize that the other tunnel drivers
don't relay pmtu today.

 But if you have  the rfc1812 conformant 576 bytes of the offending IP
in your error, you should have enough information (vmi, mac addrs,
vlans, IP addrs) to figure out who generated this packet?

>
> Another way to look at is that VXLAN is more of L2 bridge rather
> than a L3 router.

Well I guess the difference is that this flavor of L2 bridge
does in fact reduce the mtu by adding the udp/ip header.
Thus if I was a VM talking to another VM on my own pod
(i.e, no vxlan encaps in the way), I'd have a different mtu than if
I migrated to to another ToR/pod, and ended up with a reduced
mtu (I'd need to either bump up to 1600 byte mtus so that the
VM could continue to send 1500 byte pre-encaps frames, or
figure out the reduced mtu via pmtu, no?)

At the very least, shouldn't the VTEP track the reduced mtu
(in the same way that other tunnel drivers do)?

--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html