langzaam upload (rsync ssh) over ipv6 xs4all

[DDX]

Sinds aantal dagen heb ik xs4all glas 100/100 verbinding, werkt allemaal prima en snel.
Tot ik gisteren wat bestanden wou overzetten via rsync naar machine die
achter een 20/2 vdsl verbinding hangt.
Max upload snelheid zo rond de 420kbyte/sec
Nog eens geprobeerd via ipv4 en dan wel 2,1megabyte/sec die ik ongeveer
verwacht.

Beide machines draaien centos6.2 en hangen achter een fritzbox (7390 bij de
glas verbinding en 7340 bij de vdsl verbinding)

Even tcpdump losgelaten op de host waar ik bestanden heenstuur zie ik erg
veel van deze meldingen :

code:

21:12:12.991338 IP6 (hlim 59, next-header Fragment (44) payload length: 740) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0xb5f2451a:728|732)
21:12:12.991729 IP6 (hlim 59, next-header Fragment (44) payload length: 736) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x0969cf15:0|728) 48273 > 
ssh: Flags [.], seq 217698:218394, ack 408366, win 501, options [nop,nop,TS 
val 2758319854 ecr 2702102651], length 696
21:12:12.992025 IP6 (hlim 59, next-header Fragment (44) payload length: 740) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x0969cf15:728|732)
21:12:12.992375 IP6 (hlim 59, next-header Fragment (44) payload length: 736) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x60f3ed20:0|728) 48273 > 
ssh: Flags [.], seq 219126:219822, ack 408366, win 501, options [nop,nop,TS 
val 2758319854 ecr 2702102651], length 696
21:12:12.992394 IP6 (hlim 59, next-header Fragment (44) payload length: 740) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x60f3ed20:728|732)
21:12:28.448658 IP6 (hlim 59, next-header Fragment (44) payload length: 736) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x21275e24:0|728) 48273 > 
ssh: Flags [.], seq 2256950:2257646, ack 408846, win 501, options 
[nop,nop,TS val 2758335311 ecr 2702118108], length 696

Vanaf mijn machine rsync naar xs4all shell server en daarna door naar de server achter de vdsl verbinding gaat op volle snelheid.
(en dan geen frag meldingen in tcpdump)

Iemand tips wat dit kan zijn/wat ik nog meer kan debuggen ?
(eerste vermoeden zou zijn dat de fritzbox(en) wat geks doet met de pakketjes)

[DDX]

Ook nog even ping -s 1500 gedaan vanaf de linux host :

code:

]# ping6 -s 1500 2001:980:5e55:1::2
PING 2001:980:5e55:1::2(2001:980:5e55:1::2) 1500 data bytes
From 2001:980:9e4e:1:c225:6ff:fedb:4f81 icmp_seq=1 Packet too big: mtu=1492
^C
--- 2001:980:5e55:1::2 ping statistics ---
2 packets transmitted, 0 received, +1 errors, 100% packet loss, time 1867ms

En tcpdump die ik tegelijk heb lopen aan mijn kant :

code:

]# tcpdump -n -vv -i eth2 "src or dst 2001:980:5e55:1::2"
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 
bytes
00:13:15.783863 IP6 (hlim 64, next-header Fragment (44) payload length: 
1456) 2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0xc7951b2e:0|1448) 
ICMP6, echo request, length 1448, seq 1
00:13:15.783878 IP6 (hlim 64, next-header Fragment (44) payload length: 68) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0xc7951b2e:1448|60)
00:13:16.785332 IP6 (hlim 64, next-header Fragment (44) payload length: 
1448) 2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x02a6aacb:0|1440) 
ICMP6, echo request, length 1440, seq 2
00:13:16.785345 IP6 (hlim 64, next-header Fragment (44) payload length: 76) 
2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x02a6aacb:1440|68)

En een tcpdump aan de andere kant :

code:

]# tcpdump -n -vv -i p2p1 "src or dst 2001:980:9e4e:1::2"
tcpdump: listening on p2p1, link-type EN10MB (Ethernet), capture size 65535 
bytes
00:13:16.829136 IP6 (hlim 59, next-header Fragment (44) payload length: 
1448) 2001:980:9e4e:1::2 > 2001:980:5e55:1::2: frag (0x02a6aacb:0|1440) 
ICMP6, echo request, length 1440, seq 2
00:14:16.828700 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) 
2001:980:5e55:1::2 > 2001:980:9e4e:1::2: [icmp6 sum ok] ICMP6, time exceeded 
in-transit, length 1240 (reassembly)

2001:980:9e4e:1:c225:6ff:fedb:4f81 is de fritz die stuurt dus wel packet too
big terug, en in tcpdump zie ik daarna ook aanpassen van lengt
alleen geen effect ?
En aan andere kant komen minder pakketjes aan ?

[Jaap-Jan]

En als je je MTU wat lager zet, op 1280 bijvoorbeeld?

[Snow_King]

Jaap-Jan schreef op woensdag 06 juni 2012 @ 19:15:
En als je je MTU wat lager zet, op 1280 bijvoorbeeld?

Dat hoeft niet, IPv6 heeft MTU path detection.

Kan je eens een tracepath doen? Deze toont de MTU op de route. Het lijkt me stug dat het daar zit, maar toch.

[DDX]

code:

]# tracepath6 2001:980:5e55:1::2
 1?: [LOCALHOST]                      pmtu 1500
 1:  2001:980:9e4e:1:c225:6ff:fedb:4f81         0.770ms 
 1:  2001:980:9e4e:1:c225:6ff:fedb:4f81         0.626ms 
 2:  2001:980:9e4e:1:c225:6ff:fedb:4f81         0.798ms pmtu 1492
 2:  lo1.dr7.1d12.xs4all.net                   24.596ms 
 2:  lo1.dr7.1d12.xs4all.net                   21.807ms 
 3:  1417.ae3.xr4.1d12.xs4all.net               3.797ms asymm  4 
 4:  no reply
 5:  2001:980:5e55::1                          31.929ms !A
     Resume: pmtu 1492

Zet ik mtu op 1280 aan mijn kant dan is de rsync snelheid prima in orde.
Maar de ping (-s 1500) blijft mislukken. (ook de mtu aan andere kant op 1280 zetten lost dit niet op)

tracepath als ik de mtu aan mijn kant op 1280 zet :

code:

]# tracepath6 2001:980:5e55:1::2           
 1?: [LOCALHOST]                      pmtu 1280
 1:  2001:980:9e4e:1:c225:6ff:fedb:4f81         0.606ms 
 1:  2001:980:9e4e:1:c225:6ff:fedb:4f81         0.481ms 
 2:  lo1.dr7.1d12.xs4all.net                    4.763ms 
 3:  1417.ae3.xr4.1d12.xs4all.net               3.702ms asymm  4 
 4:  no reply
 5:  2001:980:5e55::1                          30.759ms !A
     Resume: pmtu 1280

[Jaap-Jan]

Dat die ping mislukt is niet zo raar, de payload wordt niet automatisch uitgespreid over 2 pakketjes. Niets raars dus.

Snow_King schreef op woensdag 06 juni 2012 @ 19:41:
[...]
Dat hoeft niet, IPv6 heeft MTU path detection.

Wikipedia geeft het antwoord: als dat type ICMP- pakketjes geblokkeerd wordt, werkt Path MTU Discovery niet meer. Wellicht dat dat het geval is bij XS4ALL.

[Snow_King]

Jaap-Jan schreef op woensdag 06 juni 2012 @ 20:57:
Dat die ping mislukt is niet zo raar, de payload wordt niet automatisch uitgespreid over 2 pakketjes. Niets raars dus.


[...]
Wikipedia geeft het antwoord: als dat type ICMP- pakketjes geblokkeerd wordt, werkt Path MTU Discovery niet meer. Wellicht dat dat het geval is bij XS4ALL.

Klopt, maar als ik het zo zie lijkt de pmtu wel te werken?

Je ziet dat hij met 1500 vertrekt in de eerste tracepath en daarna staat er:

Resume: pmtu 1492

Zo te zien werkt de detectie wel? Al vind ik het wel apart dat het prima werkt als het handmatig naar 1280 wordt gezet.

[DDX]

Ja dat idee heb ik dus ook dat de detectie gewoon werkt, maar waarom het dan toch verkeerd blijft gaan snap ik niet helemaal.
Opzich denk ik gewoon aan oplossing om op al m'n hosts hier de mtu wat omlaag te zetten.

Maarja dat is eigenlijk niet de meest nette oplossing.

[DDX]

Heb inmiddels de mtu van al mijn machines op 1280 gezet (ipv 1500)
Mocht iemand nog een idee hebben wat de echte oorzaak en oplossing is ?