Forum - Debugging MTU on "native" 6rd / OpenWRT [Sunset] :: SixXS

Debugging MTU on "native" 6rd / OpenWRT [Sunset]

Shadow Hawkins on Wednesday, 19 April 2017 07:01:52

Since aiccu handled MTU issues rather well, there hasn't really been any need for me to read ipv6 tcpdumps concerning MTU issues. Any hints on how to interpret the following dump? AFAIK ayiya and pinger1 should handle things correctly. Earlier the same openwrt box used aiccu with static tunnel / mtu 1480 without issues, but with 6rd it appears to get that default/minimum mtu from somewhere? openwrt 2001:db8:f:b00::1/56, 2001:db8:f:bc0::1/64 6rd landest 2001:db8:f:bc0::33/64 ayiya 2001:db8:5:71::1/48 pinger1 2001:db8:5:59::1/64, 2001:db8:5:71::21/64 $ ping6 -c 1 -M do -s 1380 2001:db8:f:bc0::33 PING 2001:db8:f:bc0::33(2001:db8:f:bc0::33) 1380 data bytes From 2001:db8:f:b00::1 icmp_seq=1 Packet too big: mtu=1280 --- 2001:db8:f:bc0::33 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms $ ping6 -M do -s 1380 2001:db8:5:71::1 PING 2001:db8:5:71::1(2001:db8:5:71::1) 1380 data bytes 1388 bytes from 2001:db8:5:71::1: icmp_seq=2 ttl=54 time=176 ms 1388 bytes from 2001:db8:5:71::1: icmp_seq=3 ttl=54 time=164 ms ^C --- 2001:db8:185:5d71::1 ping statistics --- 3 packets transmitted, 2 received, 33% packet loss, time 2008ms rtt min/avg/max/mdev = 164.182/170.336/176.490/6.154 ms root@OpenWrt:~# tcpdump -nettti 6rd-rd6 icmp6 tcpdump: WARNING: 6rd-rd6: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 6rd-rd6, link-type RAW (Raw IP), capture size 65535 bytes 00:00:00.000000 ip: 2001:db8:5:59::1 > 2001:db8:f:bc0::33: ICMP6, echo request, seq 1, length 1388 00:00:48.433027 ip: 2001:db8:f:bc0::33 > 2001:db8:5:71::1: ICMP6, echo request, seq 1, length 1388 00:00:00.252362 ip: 2001:db8:5:71::1 > 2001:db8:f:bc0::33: ICMP6, echo reply, seq 1, length 1388 00:00:00.000247 ip: 2001:db8:f:b00::1 > 2001:db8:5:71::1: ICMP6, packet too big, mtu 1280, length 1240 00:00:00.755739 ip: 2001:db8:f:bc0::33 > 2001:db8:5:71::1: ICMP6, echo request, seq 2, length 1388 00:00:00.174998 ip: 2001:db8:5:71::1 > 2001:db8:f:bc0::33: frag (0|1232) ICMP6, echo reply, seq 2, length 1232 00:00:00.001118 ip: 2001:db8:5:71::1 > 2001:db8:f:bc0::33: frag (1232|156) 00:00:00.824260 ip: 2001:db8:f:bc0::33 > 2001:db8:5:71::1: ICMP6, echo request, seq 3, length 1388 00:00:00.162697 ip: 2001:db8:5:71::1 > 2001:db8:f:bc0::33: frag (0|1232) ICMP6, echo reply, seq 3, length 1232 00:00:00.001141 ip: 2001:db8:5:71::1 > 2001:db8:f:bc0::33: frag (1232|156)

Debugging MTU on "native" 6rd / OpenWRT [Sunset]

Jeroen Massar SixXS Staff

on Wednesday, 19 April 2017 09:13:48

Since aiccu handled MTU issues rather well, there hasn't really been any need for me to read ipv6 tcpdumps concerning MTU issues.

aiccu has no special handling of MTU. It just configures the default of 1280 (or what is configured in the webinterface) on both sides of the tunnel. The PoP properly sends back ICMPv6 Packet Too Big if an inbound packet does not fit, and so does the client end. That is thus simply a case of a properly configured network and a stack that properly sends out and handles ICMPv6 PTBs.

Any hints on how to interpret the following dump?

AFAIK ayiya and pinger1 should handle things correctly.

Earlier the same openwrt box used aiccu with static tunnel / mtu 1480 without issues,

but with 6rd it appears to get that default/minimum mtu from somewhere?

It seems you might be configuring multiple address spaces on a host with multiple default routes etc. Do note that you need to have proper source selection for that to properly work. You need to ask the operator of the tunneling service what their MTU is configured to. There is no guessing there. Noting though that the MTU here is only the link MTU. The moment you go a hop further the MTU might be bigger or smaller (if not the minimum of 1280 already). Also note that there are a bunch of "hosts", especially CDNs like used by Google that are actually loadbalanced IPs that do not properly handle ICMPv6 Packet Too Big and fake things (Google for instance just fakes the TCP MSS, which indeed means that large packets in UDP do not work, which is fun with QUIC which is UDP based; oh and on top of that QUIC does not support non-1500 MTU sizes.... great "protocol" yes they have been made aware, no they do not care...) Hence, when you are testing test against know hosts, otherwise you might be debugging the unknown which is not useful. Also read up on CloudFlare's Path MTU discovery in practice for some more details.

Please note Posting is only allowed when you are logged in.