MTU van ADSL aansluiting?
geertjandegroot
weet iemand toevallig:
1. Wat is de maximale MTU die we van XS4all krijgen
(ik heb aanwijzingen dat dit niet 1500 bytes - ethernet - krijgen,
maar een groter getal)
2. Zijn deze parameters anders voor ADSL-van-KPN als voor XS4all-only klanten?
Wellicht dat dit voor de meeste mensen niet veel uitmaakt omdat
het ADSL modem als NAT box werkt, maar ik heb dat niet en ben
daarmee gebonden aan de 1500 bytes MTU vanwege de ethernet link
tussen mijn ADSL modem en de host die erachter zit.
Ik heb aanwijzingen dat, onder bepaalde omstandigheden,
ik grotere packets krijg die ik daardoor kwijtraak tussen
modem en host.
Zijn deze formele specs ergens te vinden?
Geert Jan
Miquel van Smoorenburg
<Geert Jan de Groot> wrote:
>Omdat we als XS4all ADSL abonnees gebruik maken van IP-over-ATM,
>weet iemand toevallig:
>
>1. Wat is de maximale MTU die we van XS4all krijgen
> (ik heb aanwijzingen dat dit niet 1500 bytes - ethernet - krijgen,
> maar een groter getal)
Gewoon 1500.
>2. Zijn deze parameters anders voor ADSL-van-KPN als voor XS4all-only klanten?
Nee.
>Ik heb aanwijzingen dat, onder bepaalde omstandigheden,
>ik grotere packets krijg die ik daardoor kwijtraak tussen
>modem en host.
Lijkt me sterk.
Mike.
Reacher
Vertel. Weid uit. Adstrueer. Licht toe. Leg uit. Enlighten me.
The...@domain.invalid
Hallo ! hij bedoeld hiermee: hij leest zijn logs van de router/modem.
dat begrijp ik zelfs...:)
--
Bedankt, Thanks,
The Fug.
VoIP/SIP switched by: www.mysipswitch.com
A free service sponsored by www.blueface.ie
Reacher
> Reacher schreef:
>> Geert Jan de Groot schreef:
>>> Omdat we als XS4all ADSL abonnees gebruik maken van IP-over-ATM,
>>> weet iemand toevallig:
>>>
>>> 1. Wat is de maximale MTU die we van XS4all krijgen
>>> (ik heb aanwijzingen dat dit niet 1500 bytes - ethernet - krijgen,
>>> maar een groter getal)
>>> 2. Zijn deze parameters anders voor ADSL-van-KPN als voor XS4all-only
>>> klanten?
>>>
>>> Wellicht dat dit voor de meeste mensen niet veel uitmaakt omdat het
>>> ADSL modem als NAT box werkt, maar ik heb dat niet en ben
>>> daarmee gebonden aan de 1500 bytes MTU vanwege de ethernet link
>>> tussen mijn ADSL modem en de host die erachter zit.
>>>
>>> Ik heb aanwijzingen dat, onder bepaalde omstandigheden, ik grotere
>>> packets krijg die ik daardoor kwijtraak tussen
>>> modem en host.
>>
>> Vertel. Weid uit. Adstrueer. Licht toe. Leg uit. Enlighten me.
>
> Hallo ! hij bedoeld hiermee: hij leest zijn logs van de router/modem.
> dat begrijp ik zelfs...:)
Als grote mensen praten...;)
The...@domain.invalid
Ja, maar ik ben breed :)
Nero Imhard
> Wellicht dat dit voor de meeste mensen niet veel uitmaakt omdat
> het ADSL modem als NAT box werkt, maar ik heb dat niet en ben
> daarmee gebonden aan de 1500 bytes MTU vanwege de ethernet link
> tussen mijn ADSL modem en de host die erachter zit.
Als er hierdoor dingen niet werken dan is Path MTU discovery stuk. Dat
komt trouwens relatief veel voor. Soms zie je de aanname dat de MTU
altijd 1500 is, en dat geeft soms problemen.
Maar eigenlijk denk ik dat er bij jou wat anders aan de hand is. Wat
zijn dat dan voor lange packets?
N
de Kameel
>>1. Wat is de maximale MTU die we van XS4all krijgen
>> (ik heb aanwijzingen dat dit niet 1500 bytes - ethernet - krijgen,
>> maar een groter getal)
>
> Gewoon 1500.
Hoe kan je zelf MTU path discovery doen? Is dit de goede methode (NB: ik zit
niet op een Xs4all-aansluiting):
sander@flappie:~$ traceroute -F ping.xs4all.nl 1472
traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1472 byte packets
1 192.168.2.254 (192.168.2.254) 2.499 ms 15.694 ms 19.518 ms
2 192.168.1.254 (192.168.1.254) 26.509 ms 32.339 ms 35.194 ms
3 82-169-27-254.ip.telfort.nl (82.169.27.254) 151.778 ms 152.416 ms
153.046 ms
4 vpn496-telfort.bcsw1.asd-nh.net.tiscali.nl (195.241.4.186) 153.628 ms
153.881 ms 157.895 ms
5 ams-ix.tc2.xs4all.net (195.69.144.166) 184.767 ms 198.289 ms 209.960
ms
6 0.so-2-0-0.xr4.1d12.xs4all.net (194.109.5.9) 224.898 ms 52.688 ms
194.317 ms
7 uucp1.xs4all.nl (194.109.21.51) 195.868 ms 195.943 ms 196.036 ms
sander@flappie:~$ traceroute -F ping.xs4all.nl 1473
traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1473 byte packets
send: Message too long
sander@flappie:~$
Dus ik het een MTU naar ping.xs4all.nl van 1473?
<snip>
>>Ik heb aanwijzingen dat, onder bepaalde omstandigheden,
>>ik grotere packets krijg die ik daardoor kwijtraak tussen
>>modem en host.
>
> Lijkt me sterk.
Alle links (behalve in-huis) zijn toch (10)GigE? Op die GigE-links zouden
dan toch jumboframes mogelijk zijn? En volgens mij kan de ATM-link ook meer
dan dan 1500 bytes. Zo ja, zou dan een >1500 byte frame aan kunnen komen op
je DSL-modem?
de Kameel
Kuifmans
> sander@flappie:~$ traceroute -F ping.xs4all.nl 1472
> traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1472 byte
> packets 1 192.168.2.254 (192.168.2.254) 2.499 ms 15.694 ms 19.518
> sander@flappie:~$ traceroute -F ping.xs4all.nl 1473
> traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1473 byte
> packets send: Message too long
> Dus ik heb een MTU naar ping.xs4all.nl van 1473?
Nee
,
1472 bytes 'payload' plus 28 bytes 'IP header' is samen?
--
Kuifmans
Kuifmans
> traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1472 byte
> packets 1 192.168.2.254 (192.168.2.254) 2.499 ms 15.694 ms 19.518
> traceroute to ping.xs4all.nl (194.109.21.51), 30 hops max, 1473 byte
> packets send: Message too long
> Dus ik het een MTU naar ping.xs4all.nl van 1473?
Nee, het ping pakketje ziet er als volgt uit:
20 bytes IP header
8 bytes ICMP header
1472 bytes "user data" of "payload"
Samen 1500.
--
Kuifmans
de Kameel
Duidelijk. Thanks!
de Kameel
Miquel van Smoorenburg
de Kameel <ik...@hier.nl> wrote:
>Alle links (behalve in-huis) zijn toch (10)GigE? Op die GigE-links zouden
>dan toch jumboframes mogelijk zijn?
Als dat aan zou staan wel, maar dat doet het niet.
>En volgens mij kan de ATM-link ook meer
>dan dan 1500 bytes. Zo ja, zou dan een >1500 byte frame aan kunnen komen op
>je DSL-modem?
Onmogelijk, zie hier wat info van een e320 router waarop de
adsl verbindingen van klanten getermineerd worden:
dr4.d12#show interface ten 0/0/0
TenGigabitEthernet0/0/0 is Up, Administrative status is Up
Hardware is Marvell GT64260, address is 0090.1a43.0e60
Primary MAU is 10000BASE-LR 10km, secondary MAU is XFP (Empty)
MTU: Operational 1518, Administrative 1518
Duplex Mode: Operational Full Duplex, Administrative Full Duplex
Speed: Operational 10000 Mbps, Administrative 10000 Mbps
dr4.d12#show ip interface ten 0/0/0
TenGigabitEthernet0/0/0 line protocol Ethernet is up, ip is up
Network Protocols: IP
Internet address is 194.109.7.130/255.255.255.252
Broadcast address is 255.255.255.255
Operational MTU = 1500 Administrative MTU = 0
Operational speed = 10000 Mbps Administrative speed = 0
Ziedaar, "operational MTU = 1500", daar gaan echt geen grotere
packets doorheen.
Mike.
geertjandegroot
> zijn dat dan voor lange packets?
Laat ik proberen uit te leggen wat ik probeer uit te vinden.
Dit hoort eigenlijk ook thuis bij het IPv6 gebeuren maar daarvoor
bestaat geen aparte nieuwsgroep.
Dit wordt een lang en gedetailleerd verhaal, ik hoop dat ik het
duidelijk krijg.
De tcpdump output is ook breder als 80 tekens. Mea culpa.
Ik ben ADSL-via-KPN klant van XS4all. Ik gebruik op dit moment een
ST780 in transparante mode (geen NAT narigheid) en krijg dus
de rauwe IP packets via ethernet op m'n soekris-box.
Zoals velen hier, heb ik ook een XS4all IPv6 tunnel.
Ik probeerde wat ISO-images te FTP-en van ftp.nl.freebsd.org
(aka ftp.nluug.nl, staat bij SURFnet) via IPv6.
Downloaden van kleine files (checksum files) werkt. Bij downloaden
van een groter file zie ik de 3-way TCP handshake van het datakanaal,
maar zie ik daarna geen enkel datapakket doorkomen.
Dit effect treedt (AFAIK) alleen op naar ftp.nluug.nl.
Als FTP voldoende data heeft, wordt een full-size packet
IPv6 packet uitgezonden. Of XS4all en SURFnet directe IPv6
connectiviteit hebben weet ik niet, wel weet ik dat ik een
tunnel heb omdat de ADSL/ATM spullenboel geen IPv6 spreekt
(en in ieder geval de speedtouch spreekt dit niet).
Als kleine packets aankomen, en grote packets niet, dan
denk je aan MTU issues. Hoe meet je dat? Ik ben gaan meten
met IPv6 pings van diverse grootte en tegelijk meekijken op
de interface waarop de tunnel packets binnenkomt.
Als in onderstaande een packet "kwijtraakt" dan is dat niet
vanwege packet loss. Ik heb de experimenten vele malen herhaald
maar slechts 1 ping zien anders wordt 't helemaal onoverzichtelijk.
Ik kan IP adressen verhullen maar dat is me teveel werk,
ik hoop dat ieder zo sportief is geen vervelende dingen
te gaan proberen. Mijn ADSL IP is 213.84.211.19 en 2001:888:10:dc::2
Ik test zowel naar ftp.nluug.nl als naar psg.com. De laatste is
een machine van een goede kennis van me, in een colo in Seattle.
Allereerst de ping test.
$ ping6 psg.com :werkt
$ ping6 -s 2000 psg.com :werkt
$ ping6 ftp.nluug.nl :werkt
$ ping6 -s 2000 ftp.nluug.nl :WERKT NIET
Laten we eerst naar psg.com kijken.
-bash-3.00$ ping6 -c 1 psg.com
PING6(56=40+8+8 bytes) 2001:888:10:dc::2 --> 2001:418:1::62
16 bytes from 2001:418:1::62, icmp_seq=0 hlim=53 time=191.74 ms
--- psg.com ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 191.740/191.740/191.740/0.000 ms
14:01:05.968045 IP (tos 0x0, ttl 30, id 38260, offset 0, flags [none], length:
76) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:418:1::62: [icmp6
sum ok] icmp6: echo request seq 0 (len 16, hlim 64)
14:01:06.159153 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 76) 1
94.109.5.241 > 213.84.211.19: 2001:418:1::62 > 2001:888:10:dc::2: [icmp6 sum ok
] icmp6: echo reply seq 0 (len 16, hlim 53)
Dat werkt dus. Wat gebeurt er bij een groot packet?
Groot pakket:
-bash-3.00$ ping6 -c 1 -s 2000 psg.com
PING6(2048=40+8+2000 bytes) 2001:888:10:dc::2 --> 2001:418:1::62
2008 bytes from 2001:418:1::62, icmp_seq=0 hlim=53 time=224.11 ms
--- psg.com ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 224.110/224.110/224.110/0.000 ms
14:01:49.036734 IP (tos 0x0, ttl 30, id 38287, offset 0, flags [none], length:
1300) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:418:1::62: frag
(0x7d3529a6:0|1232) icmp6: echo request seq 0 (len 1240, hlim 64)
14:01:49.036896 IP (tos 0x0, ttl 30, id 38288, offset 0, flags [none], length:
844) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:418:1::62: frag (
0x7d3529a6:1232|776) (len 784, hlim 64)
14:01:49.255806 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 1500)
194.109.5.241 > 213.84.211.19: 2001:418:1::62 > 2001:888:10:dc::2: frag (0x305
a5dae:0|1432) icmp6: echo reply seq 0 (len 1440, hlim 53)
14:01:49.259234 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 644)
194.109.5.241 > 213.84.211.19: 2001:418:1::62 > 2001:888:10:dc::2: frag (0x305a
5dae:1432|576) (len 584, hlim 53)
Grote packets werkt dus ook. Zowel inkomend als uitgaande packets worden
geIPv4-fragmenteerd, en op dezelfde offset (1232).
Nu eens kijken naar ftp.nluug.nl:
-bash-3.00$ ping6 -c 1 ftp.nluug.nl
PING6(56=40+8+8 bytes) 2001:888:10:dc::2 --> 2001:610:1:80aa:192:87:102:42
16 bytes from 2001:610:1:80aa:192:87:102:42, icmp_seq=0 hlim=58 time=11.459 ms
--- ftp.nluug.nl ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 11.459/11.459/11.459/0.000 ms
14:02:45.802952 IP (tos 0x0, ttl 30, id 38320, offset 0, flags [none], length:
76) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:87:
102:42: [icmp6 sum ok] icmp6: echo request seq 0 (len 16, hlim 64)
14:02:45.813791 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 76) 1
94.109.5.241 > 213.84.211.19: 2001:610:1:80aa:192:87:102:42 > 2001:888:10:dc::2
: [icmp6 sum ok] icmp6: echo reply seq 0 (len 16, hlim 58)
Dit werkt en er gebeurt hetzelfde als bij psg.com hierboven
Maar, ping van grote pakketten naar ftp.nluug.nl werkt niet. Wat gebeurt er?
-bash-3.00$ ping6 -c 1 -s 2000 ftp.nluug.nl
PING6(2048=40+8+2000 bytes) 2001:888:10:dc::2 --> 2001:610:1:80aa:192:87:102:42
--- ftp.nluug.nl ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
14:03:43.150480 IP (tos 0x0, ttl 30, id 38362, offset 0, flags [none], length:
1300) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:8
7:102:42: frag (0x0567b601:0|1232) icmp6: echo request seq 0 (len 1240, hlim 64
)
14:03:43.150641 IP (tos 0x0, ttl 30, id 38363, offset 0, flags [none], length:
844) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:87
:102:42: frag (0x0567b601:1232|776) (len 784, hlim 64)
14:03:43.188486 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 628)
194.109.5.241 > 213.84.211.19: 2001:610:1:80aa:192:87:102:42 > 2001:888:10:dc::
2: frag (0x0000004a:1448|560) (len 568, hlim 58)
Het uitgaande packet wordt zoals gebruikelijk gefragmenteerd op 1232 bytes.
Maar bij de terugkomende packets gebeurt er iets interessants:
Ik zie alleen het tweede fragment, en niet het eerste fragment.
Het tweede fragment geeft aan dat het eerste fragment 1448 bytes bevat,
maar dit eerste fragment komt *nooit* aan.
Ik ben verder gaan experimenteren met de packetsize:
-bash-3.00$ ping6 -c 1 -s 1432 ftp.nluug.nl
PING6(1480=40+8+1432 bytes) 2001:888:10:dc::2 --> 2001:610:1:80aa:192:87:102:43
1440 bytes from 2001:610:1:80aa:192:87:102:43, icmp_seq=0 hlim=58 time=33.564 m
s
--- ftp.nluug.nl ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 33.564/33.564/33.564/0.000 ms
14:05:00.426908 IP (tos 0x0, ttl 30, id 38388, offset 0, flags [none], length:
1300) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:8
7:102:42: frag (0xa5c71017:0|1232) icmp6: echo request seq 0 (len 1240, hlim 64
)
14:05:00.427069 IP (tos 0x0, ttl 30, id 38389, offset 0, flags [none], length:
276) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:87
:102:42: frag (0xa5c71017:1232|208) (len 216, hlim 64)
14:05:00.458989 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 1500)
194.109.5.241 > 213.84.211.19: 2001:610:1:80aa:192:87:102:42 > 2001:888:10:dc:
:2: icmp6: echo reply seq 0 (len 1440, hlim 58)
Deze grootte werkt. Let op: het uitgaande packet wordt gefragmenteerd op 1232
zoals gebruikelijk, maar het terugkomende packet wordt *niet* gefragmenteerd.
Dit resulteert, met tunneling, in een IPv4 packet van 1500 bytes, de maximale
MTU van ethernet.
Dit laatste heb ik echt nagekeken, en het is echt 1500 bytes gemeten vanaf
de 0x45 (eerste byte IPv4 header) tot aan de laatste databyte.
Wat gebeurt er als we de packetsize een groter maken, 1432 -> 1433?
-bash-3.00$ ping6 -c 1 -s 1433 ftp.nluug.nl
PING6(1481=40+8+1433 bytes) 2001:888:10:dc::2 --> 2001:610:1:80aa:192:87:102:42
--- ftp.nluug.nl ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
14:06:08.643034 IP (tos 0x0, ttl 30, id 38426, offset 0, flags [none], length:
1300) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:8
7:102:42: frag (0xcc46b7b6:0|1232) icmp6: echo request seq 0 (len 1240, hlim 64
)
14:06:08.643190 IP (tos 0x0, ttl 30, id 38427, offset 0, flags [none], length:
277) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:87
:102:42: frag (0xcc46b7b6:1232|209) (len 217, hlim 64)
Nu komt er geen packet meer terug.
Het terugkomend packet is, zonder fragmentatie, 1501 bytes, dus er zou
gefragmenteerd moeten worden. Omdat ik met een packet size van 2000 bytes
hierboven wel het tweede fragment terug zie komen, vermoed ik dat er
niet gefragmenteerd wordt en dat er ergens in de weg naar mijn toe,
het 1501-bytes packet schipbreuk leidt.
Ik heb ge-experimenteerd met de packetsize tot ik weer iets nieuws zie.
Tot en met 1452 bytes hetzelfde. Bij 1453 zie ik:
-bash-3.00$ ping6 -c 1 -s 1453 ftp.nluug.nl
PING6(1501=40+8+1453 bytes) 2001:888:10:dc::2 --> 2001:610:1:80aa:192:87:102:42
--- ftp.nluug.nl ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
14:08:52.444780 IP (tos 0x0, ttl 30, id 38468, offset 0, flags [none], length:
1300) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:8
7:102:42: frag (0x71698f46:0|1232) icmp6: echo request seq 0 (len 1240, hlim 64
)
14:08:52.444940 IP (tos 0x0, ttl 30, id 38469, offset 0, flags [none], length:
297) 213.84.211.19 > 194.109.5.241: 2001:888:10:dc::2 > 2001:610:1:80aa:192:87
:102:42: frag (0x71698f46:1232|229) (len 237, hlim 64)
14:08:52.475130 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], length: 81) 1
94.109.5.241 > 213.84.211.19: 2001:610:1:80aa:192:87:102:42 > 2001:888:10:dc::2
: frag (0x0000004b:1448|13) (len 21, hlim 58)
Dus, daar zie ik het 2e fragment weer terugkomen, 1e fragment is nog steeds
weg.
Hoe nu verder?
Het lijkt erop dat de tunnel box me packets probeert te sturen die groter
zijn als de ethernet-MTU (1500 bytes). Ik vermoed dat de MTU uitkomt
op 1520 bytes, want dan komen er wel fragmenten.
Het is niet illegaal om een MTU groter als 1500 bytes te hebben,
maar dat kan niet over ethernet (geen jumbograms). Bij leased lines
zijn bij sommige ISP's, grotere MTU's gebruikelijk, en bij PPP-over-ATM
*kan* het.
Als dat gebeurt heb ik een probleem: de ST780 kan deze grotere packets
niet omzetten naar ethernet (daarvoor zijn de packets te groot), maar
of 'ie zelf kan fragmenteren - ik weet het niet.
Door Mike's antwoord weet ik nu dat de maximale MTU 1500 bytes is,
en dus hoef ik me geen zorgen te maken.
Feit blijft dat m'n IPv6 verbinding zo niet goed bruikbaar is.
Het overgrote gedeelte van de IPv6 wereld heeft elders MTU caps
waardoor het bijna niet voorkomt dat de tunnel box moet gaan
fragmenteren. Zelfs de xs4all servers (bijvoorbeeld xs6.xs4all.nl)
leveren correcte, korte packets af.
Ik weet niet wat ik kan doen om de MTU aan de tunnelserver-zijde
te corrigeren, want dit zit hard gecodeerd.
Stuur ik grote IPv4 packets dan gaat alles goed.
Iemand een idee?
Geert Jan
Miquel van Smoorenburg
<Geert Jan de Groot> wrote:
>$ ping6 psg.com :werkt
>$ ping6 -s 2000 psg.com :werkt
>$ ping6 ftp.nluug.nl :werkt
>$ ping6 -s 2000 ftp.nluug.nl :WERKT NIET
Zoals ik je ook al mailde, als alles werkt, behalve ftp.nluug.nl,
dan is het vast een path mtu discovery probleem, en ligt dit ergens
op of rond ftp.nluug.nl.
Mike.
Philip Homburg
Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>In article <496f0cd9$0$201$e4fe...@news.xs4all.nl>,
> <Geert Jan de Groot> wrote:
>>Omdat we als XS4all ADSL abonnees gebruik maken van IP-over-ATM,
>>weet iemand toevallig:
>>
>>1. Wat is de maximale MTU die we van XS4all krijgen
>> (ik heb aanwijzingen dat dit niet 1500 bytes - ethernet - krijgen,
>> maar een groter getal)
>
>Gewoon 1500.
Hmm, ik heb net even 2000 ingevuld. en dat levert gewoon een ACK op. Eens
even test of het ook echt werkt...
Het lijkt ook echt te werken. Mijn link naar de access router van xs4all heeft
nu een grotere MTU.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Jan Hugo Prins
Ik heb in het verleden ook regelmatig gezien dat bij IPv6 grotere packets
regelmatig stranden doordat IPv6 PMTU fout gaat. Om dat op te lossen heb
ik in mijn router het volgende gedaan:
# Fix for pMTU problem.
# Tell upstream hosts never to send packets bigger then 1280 bytes.
$IP6TABLES -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
--set-mss 1280
Sinds dat er bij mij in staat heb ik nergens meer last van.
Jan Hugo
de Kameel
> Ik heb in het verleden ook regelmatig gezien dat bij IPv6 grotere packets
> regelmatig stranden doordat IPv6 PMTU fout gaat. Om dat op te lossen heb
> ik in mijn router het volgende gedaan:
>
> # Fix for pMTU problem.
> # Tell upstream hosts never to send packets bigger then 1280 bytes.
> $IP6TABLES -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
> --set-mss 1280
>
> Sinds dat er bij mij in staat heb ik nergens meer last van.
Aha: dat herinner ik me ook nog: 1200-nog-iets aanzetten als MTU op een
IPv6-tunnel.
de Kameel
Rob
Waarom moet die MSS zo laag eigenlijk?
220 bytes voor een header lijkt me wat veel.
de Kameel
>>> # Fix for pMTU problem.
>>> # Tell upstream hosts never to send packets bigger then 1280 bytes.
>>> $IP6TABLES -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
>>> --set-mss 1280
>>>
>>> Sinds dat er bij mij in staat heb ik nergens meer last van.
>>
>> Aha: dat herinner ik me ook nog: 1200-nog-iets aanzetten als MTU op een
>> IPv6-tunnel.
>
> Waarom moet die MSS zo laag eigenlijk?
> 220 bytes voor een header lijkt me wat veel.
Kweenie. Ik kan alleen dit vinden:
Increased Default MTU: In IPv4, the minimum MTU that routers and physical
links were required to handle was 576 bytes. In IPv6, all links must handle
a datagram size of at least 1280 bytes. This more-than-doubling in size
improves efficiency by increasing the ratio of maximum payload to header
length, and reduces the frequency with which fragmentation is required.
Dus 1280 is bij IPv6 je minimum-garantie, dus veilig. Maar waarom dat zo
laag is ... ?
de Kameel
Rob
Wat heeft een minimum default MTU van 1280 dan te maken met jouw setting
van 1280 voor de MSS? Als je binnen die 1280 wilt blijven dan moet de MSS
NOG lager. Immers daar komen nog de TCP en IP headers bij.
Het zetten van een MSS van 1280 lijkt me niet optimaal. Te groot voor
de gagarandeerde MTU en te klein voor de praktijk MTU.