On Fri, 6 Nov 2020 17:59:52 +0100 Stefano Brivio wrote:
> Jianlin reports that a bridged IPv6 VXLAN endpoint, carrying IPv6
> packets over a link with a PMTU estimation of exactly 1350 bytes,
> won't trigger ICMPv6 Packet Too Big replies when the encapsulated
> datagrams exceed said PMTU value. VXLAN over IPv6 adds 70 bytes of
> overhead, so an ICMPv6 reply indicating 1280 bytes as inner MTU
> would be legitimate and expected.
>
> This comes from an off-by-one error I introduced in checks added
> as part of commit 4cb47a8644cc ("tunnels: PMTU discovery support
> for directly bridged IP packets"), whose purpose was to prevent
> sending ICMPv6 Packet Too Big messages with an MTU lower than the
> smallest permissible IPv6 link MTU, i.e. 1280 bytes.
>
> In iptunnel_pmtud_check_icmpv6(), avoid triggering a reply only if
> the advertised MTU would be less than, and not equal to, 1280 bytes.
>
> Also fix the analogous comparison for IPv4, that is, skip the ICMP
> reply only if the resulting MTU is strictly less than 576 bytes.
>
> This becomes apparent while running the net/pmtu.sh bridged VXLAN
> or GENEVE selftests with adjusted lower-link MTU values. Using
> e.g. GENEVE, setting ll_mtu to the values reported below, in the
> test_pmtu_ipvX_over_bridged_vxlanY_or_geneveY_exception() test
> function, we can see failures on the following tests:
>
> test | ll_mtu
> -------------------------------|--------
> pmtu_ipv4_br_geneve4_exception | 626
> pmtu_ipv6_br_geneve4_exception | 1330
> pmtu_ipv6_br_geneve6_exception | 1350
>
> owing to the different tunneling overheads implied by the
> corresponding configurations.
>
> Reported-by: Jianlin Shi <ji...@redhat.com>
> Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP
> packets")
> Signed-off-by: Stefano Brivio <sbri...@redhat.com>
Applied, thanks.
