RFC4638 / ppp-max-payload support op glas voor MTU 1500

[Miquel van Smoorenburg]

Sinds vannacht staat op de routers die gebruikt worden om de PPPoE sessies
van glasvezelklanten te termineren RFC4638 / ppp-max-payload support aan.

Dat betekent dat als je een router hebt die dat support, je een
MTU van 1500 kan gebruiken ipv 1492.

De fritzboxen supporten dat op dit moment niet, maar er staat wel
een RFE (request for enhancement) uit bij AVM.

Bij een Cisco zou het 'tag ppp-max-payload' moeten zijn in de
virtual-template config.

Met een Linux router moet je de MTU van je ethernet interface
waar pppd op draait verhogen naar minimaal 1508 (bv 1600 ofzo),
en deze patch toepassen:
http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7

Ben benieuwd of iemand dit client-side aan de praat krijgt :)

Mike.

[Maurice Janssen]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>Sinds vannacht staat op de routers die gebruikt worden om de PPPoE sessies
>van glasvezelklanten te termineren RFC4638 / ppp-max-payload support aan.
>
>Dat betekent dat als je een router hebt die dat support, je een
>MTU van 1500 kan gebruiken ipv 1492.

<knip>

>Ben benieuwd of iemand dit client-side aan de praat krijgt :)

$ ping -c 1 -Ds 1472 ping.xs4all.nl
PING ping.xs4all.nl (194.109.6.8): 1472 data bytes
1480 bytes from 194.109.6.8: icmp_seq=0 ttl=61 time=6.054 ms
--- ping.xs4all.nl ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 6.054/6.054/6.054/0.000 ms

Tegelijkertijd sniffen op de pppoe0 interface:
19:27:40.955805 80.100.207.108 > 194.109.6.8: icmp: echo request (id:472f seq:0) (DF) (ttl 254, id 1618, len 1500)
19:27:40.961462 194.109.6.8 > 80.100.207.108: icmp: echo reply (id:472f seq:0) (ttl 62, id 63270, len 1500)

Kortom: het werkt!

Dit is met een OpenBSD systeem als router/firewall die via een managed switch
aan de NTU hangt.

--
Maurice

[Jan Hugo Prins]

Dat wordt binnenkort maar weer eens een nieuwe kernel voor mijn firewall
builden.

Jan Hugo

[Miquel van Smoorenburg]

In article <5273f339$0$15997$e4fe...@news.xs4all.nl>,

Mooi! Lijkt erop dat OpenBSD de enige van de Linux/BSDs is die
standaard RFC4638 support heeft in pppoe (sinds 5.1, zie ik).

Mike.

[Maurice Janssen]

Het was inderdaad slechts een kwestie van 'mtu 1508' toevoegen aan de
configuratie van de fysieke interface, 'mtu 1500' toevoegen aan de
configuratie van de pppoe interface, de pppoe interface opnieuw starten,
achter m'n oren krabben waarom het niet werkte en tot slot jumbo-frames
aanzetten op de switch ;-)

--
Maurice

[Rob]

Heel mooi dat je hier aan gewerkt hebt Mike!
Een groot nadeel van PPPoE is hiermee van de baan.

(zelf gebruik ik geen PPPoE, dit zou hooguit in de picture komen als
ik op VDSL overstap maar dan wacht ik wel even op AVM...)

[Jan Hugo Prins]

On Thu, 31 Oct 2013 09:39:22 +0000, Miquel van Smoorenburg wrote:

Hoi Mike,

Vanavond een nieuwe versie van Devil-Linux op mijn router gezet en daarin
ook de patch voor ppp meegenomen. Loop alleen tegen het probleem aan dat
ik de ppp verbinding opzet over een vlan interface die weer op een
100Mbit interface ligt. Niet echt een ideale situatie, maar het gevolg is
ook dat ik de mtu van de onderliggende interface op dit moment niet
omhoog krijg en ook pppd zegt dat hij de mtu en mru niet kan verhogen.

Als ik echter de mtu van de ppp interface na connect omhoog gooi naar
1500 dan lijkt er wel verkeer met een mtu van 1500 overheen te komen.

Getuige:
[jhp@hera ~]$ ping -M do -s 1472 ping.xs4all.nl
PING ping.xs4all.nl (194.109.6.8) 1472(1500) bytes of data.
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=1 ttl=61 time=5.21
ms
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=2 ttl=61 time=5.17
ms
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=3 ttl=61 time=5.18
ms
^C

--- ping.xs4all.nl ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.178/5.192/5.215/0.084 ms
[jhp@hera ~]$

En een packet capture laat ook packets van 1508 bytes zien.

23:03:31.295331 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 1500)
jhprins.org > ping.xs4all.nl: ICMP echo request, id 16535, seq 4,
length 1480

Kun jij zien wat er bij jullie op de router over mijn verbinding verteld
wordt?

Jan Hugo

[Miquel van Smoorenburg]

In article <531e452c$0$25292$e4fe...@dreader34.news.xs4all.nl>,

Jan Hugo Prins <j...@jhprins.org> wrote:
>Vanavond een nieuwe versie van Devil-Linux op mijn router gezet en daarin
>ook de patch voor ppp meegenomen. Loop alleen tegen het probleem aan dat
>ik de ppp verbinding opzet over een vlan interface die weer op een
>100Mbit interface ligt. Niet echt een ideale situatie, maar het gevolg is
>ook dat ik de mtu van de onderliggende interface op dit moment niet
>omhoog krijg

Waarom niet? Een VLAN subinterface kan ook best een MTU > 1500 hebben.
Als de onderliggende interface dat ook maar heeft.

>en ook pppd zegt dat hij de mtu en mru niet kan verhogen.

ja, want die checkt de MTU van de ethernet interface natuurlijk.

>Als ik echter de mtu van de ppp interface na connect omhoog gooi naar
>1500 dan lijkt er wel verkeer met een mtu van 1500 overheen te komen.

Alleen dan wordt er helemaal geen RFC4638 onderhandeld, dus dan heb
je zeker geen grotere MTU. Aan de XS4ALL kant wijzigt die ook niet
naturlijk omdat je het aan jouw kant aanpast.

>Getuige:
>[jhp@hera ~]$ ping -M do -s 1472 ping.xs4all.nl
>PING ping.xs4all.nl (194.109.6.8) 1472(1500) bytes of data.
>1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=1 ttl=61 time=5.21
>ms

Nou, blijkbaar accepteert de XS4ALL kant je grote packets alsnog.
Alleen denk ik dat het antwoord dat je terug krijgt wel
gefragmenteerd is.

>23:03:31.295331 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
>ICMP (1), length 1500)
> jhprins.org > ping.xs4all.nl: ICMP echo request, id 16535, seq 4,
>length 1480

Ja die kant op wel, maar terug niet gok ik.

>Kun jij zien wat er bij jullie op de router over mijn verbinding verteld
>wordt?

pp0.1073892925

PAP state: Success
Protocol inet, MTU: 1492, Generation: 17087555, Route table: 0

Mike.

[MM]

Jan Hugo Prins schreef op 11-3-2014 0:05:

Ik heb er maar weinig verstand van dit spul maar die 1508 is dan
inclusief de VLAN header en 1500 zonder.

Als ik op mijn 7390 kijk dan zijn de pakketjes al 1518 bits groot maar
ik kom niet verder dan 1664 op IP4 en 1444 op IPV6 als pakket grootte.

[MM]

MM schreef op 11-3-2014 0:23:

1664 moet zijn 1464
bits moet zijn bytes

[Jan Hugo Prins]

Hoi,

> Ik heb er maar weinig verstand van dit spul maar die 1508 is dan
> inclusief de VLAN header en 1500 zonder.
>
> Als ik op mijn 7390 kijk dan zijn de pakketjes al 1518 bits groot maar
> ik kom niet verder dan 1664 op IP4 en 1444 op IPV6 als pakket grootte.

De 1508 byte packets zag ik op de ppp0 interface outbound.
Daar komt dan nog een vlan header overheen richting de switch.
Uiteindelijk zal XS4ALL het packet dan binnen krijgen inclusief vlan
header en deze er dan waarschijnlijk op de router waar de ppp sessie
getermineerd wordt weer af slopen.

De switch van mij kan wel jumbo frames aan en dat had ik voor dit vlan
dan ook aanstaan. Mijn probleem ligt echter bij de netwerk kaartjes die ik
in de router heb zitten. Dit zijn oude Intel 10/100 kaartjes zonder Jumbo
support, zowel in hardware als in driver. Dus dat is de reden dat ik die
interface nooit naar Jumbo frames zal kunnen zetten. Moet dus even die
netwerk kaarten gaan vervangen voor iets anders, en mogelijk krijg ik het
dan wel goed aan de praat. Toen de router nog achter mijn ADSL lijn hing
destijds was dit meer dan genoeg, het begint nu echter een beperking te
worden.


Jan Hugo

[Jan Hugo Prins]

Hi Mike,

> pp0.1073892925
>
> PAP state: Success
> Protocol inet, MTU: 1492, Generation: 17087555, Route table: 0

Heb vanavond een nieuwe router in gebruik genomen en hierbij heb ik in
Linux de patch van aangebracht die jij eerder in de newsgroup gepost had.

In de log krijg ik de volgende melding:

Mar 20 20:15:55 192.168.178.1 pppd[1046]: Plugin /etc/ppp/plugins/rp-
pppoe.so loaded.
Mar 20 20:15:55 192.168.178.1 pppd[1046]: RP-PPPoE plugin version 3.10
compiled against pppd 2.4.5
Mar 20 20:15:55 192.168.178.1 pppd[1046]: pppd 2.4.5 started by root, uid
0
Mar 20 20:16:00 192.168.178.1 pppd[1046]: PPP session is 3410 (0xd52)
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Connected to 78:fe:3d:ba:bc:00
via interface eth1
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Using interface ppp0
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Connect: ppp0 <--> eth1
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Couldn't increase MTU to 1500
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Couldn't increase MRU to 1500
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Couldn't increase MTU to 1500
Mar 20 20:16:00 192.168.178.1 pppd[1046]: Couldn't increase MRU to 1500
Mar 20 20:16:00 192.168.178.1 pppd[1046]: PAP authentication succeeded
Mar 20 20:16:00 192.168.178.1 pppd[1046]: peer from calling number
78:FE:3D:BA:BC:00 authorized
Mar 20 20:16:00 192.168.178.1 pppd[1046]: local IP address 83.161.158.33
Mar 20 20:16:00 192.168.178.1 pppd[1046]: remote IP address 194.109.5.175
Mar 20 20:16:00 192.168.178.1 pppd[1046]: local LL address
fe80::020d:48ff:fe35:02c0
Mar 20 20:16:00 192.168.178.1 pppd[1046]: remote LL address
fe80::02a0:a50f:fc78:5530

Kun jij kijken of jij aan jou kant kunt zien waarom de MRU/MTU van 1500
niet gehonoreerd wordt?

Verder krijg ik mijn IPv6 prefix op dit moment niet terug. Ik kan me
ergens herrinneren dat er een leasetimeout van 2 uur op zit voordat een
andere router de lease kan krijgen. Zou je deze voor mij kunnen vrijgeven?

Jan Hugo Prins

[Miquel van Smoorenburg]

In article <iv1sva-...@capetown.jhprins.org>,

Jan Hugo Prins <j...@jhprins.org> wrote:

>> pp0.1073892925
>>
>> PAP state: Success
>> Protocol inet, MTU: 1492, Generation: 17087555, Route table: 0
>
>Heb vanavond een nieuwe router in gebruik genomen en hierbij heb ik in
>Linux de patch van aangebracht die jij eerder in de newsgroup gepost had.
>
>In de log krijg ik de volgende melding:
>

>Mar 20 20:16:00 192.168.178.1 pppd[1046]: Couldn't increase MTU to 1500

>Kun jij kijken of jij aan jou kant kunt zien waarom de MRU/MTU van 1500
>niet gehonoreerd wordt?

Nee, maar wel in de source code van de PPPoE plugin. De enige
plek waar die melding voorkomt is:

if (mtu > MAX_PPPOE_MTU) {
warn("Couldn't increase MTU to %d", mtu);
mtu = MAX_PPPOE_MTU;
}

.. dus als je dat ziet, dan heb je toch niet alles gepatcht. Want
blijkbaar is MAX_PPPOE_MTU nog steeds < 1500.

>Verder krijg ik mijn IPv6 prefix op dit moment niet terug. Ik kan me
>ergens herrinneren dat er een leasetimeout van 2 uur op zit voordat een
>andere router de lease kan krijgen. Zou je deze voor mij kunnen vrijgeven?

Nu niet meer nodig denk ik.

Mike.

[Jan Hugo Prins]

Hoi Mike,

> Nee, maar wel in de source code van de PPPoE plugin. De enige plek waar
> die melding voorkomt is:
>
> if (mtu > MAX_PPPOE_MTU) {
> warn("Couldn't increase MTU to %d", mtu); mtu = MAX_PPPOE_MTU;
> }
>
> .. dus als je dat ziet, dan heb je toch niet alles gepatcht. Want
> blijkbaar is MAX_PPPOE_MTU nog steeds < 1500.
>

Ik heb de patch gedeeltelijk moeten reviseren omdat hij niet clean paste
op de versie van PPPD die in Devil-Linux zit. Zal dus even moeten kijken
waar ik iets gemist heb en of een foutje gemaakt heb.

> Nu niet meer nodig denk ik.

Inderdaad.

Jan Hugo

[Jan Hugo Prins]

Ik zie zojuist dat in pppd-2.4.6 de patch al volledig geintergreerd is.
Dit is een redelijk recente versie van pppd (15-02-2014) en zit nog niet
in Devil-Linux.

Ga denk ik maar eens een aanpassing doen in mijn source tree.

Jan Hugo

[Jan Hugo Prins]

On Sat, 22 Mar 2014 00:13:58 +0100, Jan Hugo Prins wrote:

> Ik zie zojuist dat in pppd-2.4.6 de patch al volledig geintergreerd is.
> Dit is een redelijk recente versie van pppd (15-02-2014) en zit nog niet
> in Devil-Linux.
>
> Ga denk ik maar eens een aanpassing doen in mijn source tree.

Ik heb het werkend onder Linux.
rp-pppoe geupped naar 3.11 en ppp geupped naar 2.4.6 en toen alleen nog
de config goed zetten.

10: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 83.161.158.33 peer 194.109.5.175/32 scope global ppp0
inet6 fe80::20d:48ff:fe35:2c0/10 scope link
valid_lft forever preferred_lft forever



Jan Hugo

[Miquel van Smoorenburg]

In article <532f3ec0$0$25051$e4fe...@dreader37.news.xs4all.nl>,

Jan Hugo Prins <j...@jhprins.org> wrote:

w00t :)

mik...@re0.dr11.1d12> show interfaces pp0.1073852683
Logical interface pp0.1073852683 (Index 4473) (SNMP ifIndex 21534)
Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPPoE
Interface set: ti-xs42-8-vlan-2209
PAP state: Success
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re
Protocol inet6, MTU: 1500
Addresses, Flags: Is-Primary

Mike.

[woute...@gmail.com]

Een kick van een oude post. Maar voor degenen die OpenWRT gebruiken is het sinds release 41193 standaard mogelijk om gebruik te maken van deze optie. Voorheen was het noodzakelijk om zelf een image te patchen en te compilen. Dat is nu niet meer nodig.

Ik maak gebruik van een Netgear WNDR3800. Het is daarbij voldoende om de onderliggende interface (eth1) een hogere MTU waarde mee te geven en hetzelfde te doen voor de PPPOE verbinding.

in /etc/config/network toevoegen:

config interface 'eth1'
option ifname 'eth1'
option mtu '1508'

Zoek daarna naar de PPPOE verbinding onder (staat onder config interface 'wan')
en voeg toe:

option mtu '1508'

Sla de file op en herstart het netwerkgedeelte met het volgende commando:

/etc/init.d/network restart

[Rob]

Sorry even een followup op jouw posting ipv de OP omdat die inmiddels
op news.xs4all expired is.

Mijn vraag: is dit alleen op glas of is die optie inmiddels ook op VDSL
aanwezig?

[Miquel van Smoorenburg]

In article <slrnm7gic4...@xs8.xs4all.nl>,

Rob <nom...@example.com> wrote:
>woute...@gmail.com <woute...@gmail.com> wrote:
>> Een kick van een oude post. Maar voor degenen die OpenWRT gebruiken is
>het sinds release 41193 standaard mogelijk om gebruik te maken van deze
>optie.
>

>Sorry even een followup op jouw posting ipv de OP omdat die inmiddels
>op news.xs4all expired is.
>
>Mijn vraag: is dit alleen op glas of is die optie inmiddels ook op VDSL
>aanwezig?

Ook op VDSL.

Mike.

[Rob]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:

Ok gelukkig (ik kom pas hier na de andere groep).
Wellicht gaat deze ellende dus verdwijnen...

[m.vand...@coolblue.nl]

Ik ben sinds kort klant bij XS4ALL en probeer dit aan de gang te krijgen.
Voordat de monteur de FTU vervangde, werkte het wel (op de oude Genexis modem van de oude ISP, de oude ISP gebruikte toevallig dezelfde VLAN IDs). Na het vervangen van het modem werkt het niet meer. Is dit een bekend probleem met de Genexis modems die XS4ALL levert?

[Miquel van Smoorenburg]

In article <3bfe25d7-103c-48f9...@googlegroups.com>,

<m.vand...@coolblue.nl> wrote:
>On Thursday, October 31, 2013 at 10:39:22 AM UTC+1, Miquel van
>Smoorenburg wrote:
>> Sinds vannacht staat op de routers die gebruikt worden om de PPPoE sessies
>> van glasvezelklanten te termineren RFC4638 / ppp-max-payload support aan.
>

>Ik ben sinds kort klant bij XS4ALL en probeer dit aan de gang te krijgen.
>Voordat de monteur de FTU vervangde, werkte het wel (op de oude
>Genexis modem van de oude ISP, de oude ISP gebruikte toevallig
>dezelfde VLAN IDs). Na het vervangen van het modem werkt het niet
>meer. Is dit een bekend probleem met de Genexis modems die XS4ALL
>levert?

Wat werkt niet? "hij doet het niet" kan ik niet debuggen :)

Mike.

[m.vand...@coolblue.nl]

Ik kan een PPPoE sessie starten met een mtu van 1500, maar ik kan geen packets groter dan 1492 versturen. Dezelfde config heeft met de oude genexis van de vorige ISP gewerkt (op xs4all netwerk). Ik zal straks wat meer debug info opsnorren.

[Miquel van Smoorenburg]

In article <2e5e2f02-9a5d-40de...@googlegroups.com>,

Heb je dan ook soort en type van beide FTUs (of NTUs) ?

Mike.

[Rob]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:

Hij schrijft dat hij de XS4ALL router gebruikt. Dan is het toch normaal
dat dit niet werkt?

[Miquel van Smoorenburg]

In article <slrnmc1fso...@xs8.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> In article <2e5e2f02-9a5d-40de...@googlegroups.com>,
>> <m.vand...@coolblue.nl> wrote:
>>>Ik kan een PPPoE sessie starten met een mtu van 1500, maar ik kan geen
>>>packets groter dan 1492 versturen. Dezelfde config heeft met de oude
>>>genexis van de vorige ISP gewerkt (op xs4all netwerk). Ik zal straks
>>>wat meer debug info opsnorren.
>>
>> Heb je dan ook soort en type van beide FTUs (of NTUs) ?
>>
>

>Hij schrijft dat hij de XS4ALL router gebruikt.

Nee, dat schreef hij niet. FTU/NTU != Fritzbox.

Mike.

[m.vand...@coolblue.nl]

Klopt, ik maak geen gebruik van de Fritzbox, maar van een ubiquity edgerouter pro. Volgens mij is het type genexis fxp-100. Ik zal de exacte types van de genexis opzoeken als ik thuis ben.

[m.vand...@coolblue.nl]

On Thursday, January 22, 2015 at 11:47:32 AM UTC+1, m.vand...@coolblue.nl wrote:
> Klopt, ik maak geen gebruik van de Fritzbox, maar van een ubiquity edgerouter pro. Volgens mij is het type genexis fxp-100. Ik zal de exacte types van de genexis opzoeken als ik thuis ben.

Ik heb even de oude config teruggezet in mijn router. Configuratie die op de oude Genexis werkte:

ethernet eth0 {
description "Uplink to FTU"
duplex auto
firewall {
in {
}
local {
}
}
mtu 1508
speed auto
vif 6 {
description "VLAN6 - XS4ALL Internet"
pppoe 0 {
default-route auto
firewall {
in {
ipv6-name wan_in
name WAN_IN
}
local {
ipv6-name wan_local
name WAN_LOCAL
}
}
mtu 1500
name-server auto
password xs4all
user-id sterm
}
}
}

Ik kan een PPPoE sessie opbouwen met MTU van 1500:
pppoe0 Link encap:Point-to-Point Protocol
inet addr:x.x.x.x P-t-P:194.109.5.175 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:709 errors:0 dropped:0 overruns:0 frame:0
TX packets:837 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:84910 (82.9 KiB) TX bytes:76701 (74.9 KiB)

Ping test:
$ ping -c 1 -D -s 1464 xs4all.nl
PING xs4all.nl (194.109.6.93): 1464 data bytes
1472 bytes from 194.109.6.93: icmp_seq=0 ttl=61 time=6.018 ms

--- xs4all.nl ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.018/6.018/6.018/0.000 ms

$ ping -c 1 -D -s 1464 xs4all.nl
PING xs4all.nl (194.109.6.93): 1464 data bytes
1472 bytes from 194.109.6.93: icmp_seq=0 ttl=61 time=6.018 ms

--- xs4all.nl ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.018/6.018/6.018/0.000 ms

$ ping -c 1 -D -s 1472 xs4all.nl
PING xs4all.nl (194.109.6.93): 1472 data bytes

--- xs4all.nl ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

Oude Genexis modem:
FiberXport OCG-2018m_V3

Nieuwe Genexis modem:
Niet helemaal duidelijk omdat deze nu in de meterkast bevestigd is. Maar ik neem aan dat dit bij xs4all bekend moet zijn. http://tweakers.net/ext/f/XdgzJCCV4bCvJrzR7MPCLpg5/full.jpg zo een, maar dan met 1 port.

[Miquel van Smoorenburg]

In article <ba446441-83ee-45a1...@googlegroups.com>,

<m.vand...@coolblue.nl> wrote:
>On Thursday, January 22, 2015 at 11:47:32 AM UTC+1,
>m.vand...@coolblue.nl wrote:
>> Klopt, ik maak geen gebruik van de Fritzbox, maar van een ubiquity
>edgerouter pro. Volgens mij is het type genexis fxp-100. Ik zal de
>exacte types van de genexis opzoeken als ik thuis ben.
>
>Ik heb even de oude config teruggezet in mijn router. Configuratie die
>op de oude Genexis werkte:

Ik ben offline tot ergens volgende week, misschien dat een
collega dit kan onderzoeken, anders ligt het even stil.

Mike.

[m.vand...@coolblue.nl]

Geen probleem, doe ondertussen wel de dirty TCP MSS clamping ;)
Ik laat de PPPoE sessie met de mtu van 1500 voorlopg zo staan als jullie willen testen.

[Maurice Janssen]

m.vand...@coolblue.nl wrote:
>Nieuwe Genexis modem:
>Niet helemaal duidelijk omdat deze nu in de meterkast bevestigd is. Maar ik
>neem aan dat dit bij xs4all bekend moet zijn.
>http://tweakers.net/ext/f/XdgzJCCV4bCvJrzR7MPCLpg5/full.jpg zo een, maar dan
>met 1 port.

De NTU die ik heb is er ook zo één (met 1 gigabit UTP poort en verder niets)
en daar werkt een MTU van 1500 probleemloos vanaf het moment dat Mike
aankondigde dat het zou moeten werken.

--
Maurice

[m.vand...@coolblue.nl]

Op mijn FTU/NTU staat wel gigabit, maar port speed is negotiated op maar 100Mbps. Ik woon in Dordrecht, oud glasvezelgebied wat max 100Mbps heeft. Wellicht is dat bij jou anders?

[Maurice Janssen]

Hier hetzelfde. Waar ik woon kun je sinds kort wel 500 Mbit aanvragen, maar
ik vermoed dat mijn vezeltje dan omgepatcht moet worden naar nieuwe apparatuur
(of hij is al omgepatcht maar staat op max 100 Mbit omdat mijn abonnement
ook 100 Mbit is).
Maar ik weet wel dat 1500 byte MTU al goed werkte voordat je 500 Mbit kon
aanvragen.

--
Maurice

[Bart]

Ik heb even lopen spelen met mijn EdgeRouter Lite, helaas heb ik geen
glas en kan het dus niet in de praktijk testen. In de configs die je
post staat geen mtu waarde op de vlan interface. Als ik daar zelf geen
waarde invul default die naar de 1500 en de ppp sessie krijgt
automatisch -8 op de mtu van de interface waar die onder hangt.

Het lijkt me niet het probleem gezien je post dat het gewoon heeft
gewerkt met die config tot dat de NTU werd gewisseld maar misschien kan
het geen kwaad het een keer zo te testen:

ethernet eth0 {
description "Uplink to NTU"
mtu 1508
vif 6 {
description "XS4ALL Internet"
mtu 1508
pppoe 0 {
mtu 1500
password ****************
user-id xs4...@xs4all.nl
}
}
}

--Bart

[Miquel van Smoorenburg]

In article <ba446441-83ee-45a1...@googlegroups.com>,
<m.vand...@coolblue.nl> wrote:

>On Thursday, January 22, 2015 at 11:47:32 AM UTC+1, m.vand...@coolblue.nl wrote:
>> Klopt, ik maak geen gebruik van de Fritzbox, maar van een ubiquity
>edgerouter pro. Volgens mij is het type genexis fxp-100. Ik zal de
>exacte types van de genexis opzoeken als ik thuis ben.
>
>Ik heb even de oude config teruggezet in mijn router. Configuratie die
>op de oude Genexis werkte:

Heb je de suggestie van Bart al geprobeerd, met:

> ethernet eth0 {
> description "Uplink to FTU"
> duplex auto
> firewall {
> in {
> }
> local {
> }
> }
> mtu 1508
> speed auto
> vif 6 {
> description "VLAN6 - XS4ALL Internet"

^^^^^^^^^^^^

daar in vif 6 { } ook nog eens 'mtu 1508' ?

Mike.

[maa...@vdster.nl]

Het heeft gewerkt zonder, maar ik heb het voor de zekerheid zojuist toegevoegd. Het maakt geen verschil.

[Miquel van Smoorenburg]

In article <4cb4b8c9-8610-453a...@googlegroups.com>,

<maa...@vdster.nl> wrote:
>Het heeft gewerkt zonder, maar ik heb het voor de zekerheid zojuist
>toegevoegd. Het maakt geen verschil.

Ik zie dat je net om 20:15 overnieuw contact hebt gemaakt, en die
sessie staat nog. Dat is dus nu met die settings. Aan de XS4ALL kant:

Protocol inet, MTU: 1492, Generation: 867641, Route table: 0
^^^^^^^^^
en
Negotiated options:
Authentication protocol: pap, Magic number: 517057335,
Initial Advertised MRU: 1500, Peer MRU: 1492
^^^^ ^^^^

Maw, er is toch iets in de onderhandeling misgegaan. Anders zou
alles op 1500 staan en zag je geen 1492 opduiken.

Het is mogelijk dat jouw kant de geadverteerde MRU 1500 heeft
opgepikt, daarom zegt jouw kant 'MTU 1500', maar je zal geen
packets van 1500 bytes kunnen ontvangen, want jouw kant heeft
een MRU van 1492 geadverteerd (dus de MTU aan de xs4all kant
staat op 1492).

Dat kan je testen door vanaf bv xs8.xs4all.nl een ping te doen
naar je eigen IP adres, dan zie je vanzelf dat de router waar je
op zit een 'packet too big' terug stuurt:

$ ping -M do -s 1472 83.162.x.y
PING 83.162.x.y (83.162.x.y) 1472(1500) bytes of data.
From 194.109.7.170 icmp_seq=1 Frag needed and DF set (mtu = 1492)

Mike.

[Miquel van Smoorenburg]

In article <54cfdde6$0$2831$e4fe...@news2.news.xs4all.nl>,

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:

> Authentication protocol: pap, Magic number: 517057335,
> Initial Advertised MRU: 1500, Peer MRU: 1492
> ^^^^ ^^^^

Tips:
1. zorg dat je de laatste firmware draait.
2. controleer dubbel of je config wel goed staat met de mtu op 1508
op de juiste plekken.
3. save en reboot voor de zekerheid

Mike.

[m.vand...@coolblue.nl]

De Edgerouter draait de laatste firmware. Als ik alle interfaces bekijk staan de mtu sizes goed. Het heeft ook gewerkt met de NTU van de vorige ISP (en deze config), totdat Guidion de NTU geswapped heeft. Ik weet niet in hoeverre ik zelf de NTU weer mag wisselen om te testen, ik heb die van de vorige ISP nog liggen.

[Miquel van Smoorenburg]

In article <6ae8191f-a437-47d1...@googlegroups.com>,

Ik heb iemand die mij influistert die veel ervaring heeft met
de router die jij hebt, ook aan betaprogramma's mee heeft gedaan
en met de producent praat, en die is ervan overtuigd dat dit door
je router komt. Een instelling, maar kan net zo goed een bug
zijn, dat komt vaker voor.

Ik denk dat ook, want ik zie dat jij een MRU van 1492 adverteert. Het
is onmogelijk dat dat komt door de NTU die ertussen zit. Dat
is echt je router die dat doet.

Mike.

[Miquel van Smoorenburg]

In article <54d0a510$0$2904$e4fe...@news2.news.xs4all.nl>,

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:

>Ik heb iemand die mij influistert die veel ervaring heeft met
>de router die jij hebt

.. en die zegt, doe eens:

show interfaces pppoe pppoe0 log

"kan je zien wat er gebeurt en mis gaat"

Mike.

[m.vand...@coolblue.nl]

Hmm, dat is vreemd. Het stuk log van de laatste connectie:

using channel 9
Using interface ppp0
Connect: ppp0 <--> eth0.6
LCP: Up event in state 6!
sent [LCP ConfReq id=0x2 <mru 1492> <magic 0x8479d794>]
rcvd [LCP ConfReq id=0xa7 <auth pap> <magic 0x1ed1ab37>]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0xa7 <auth pap> <magic 0x1ed1ab37>]
rcvd [LCP ConfAck id=0x2 <mru 1492> <magic 0x8479d794>]
IPCP: Up event in state 2!
sent [PAP AuthReq id=0x2 user="sterm" password=<hidden>]
rcvd [PAP AuthAck id=0x2 ""]
PAP authentication succeeded
peer from calling number 78:FE:3D:BA:BC:CE authorized
sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x3 <addr 83.162.x.x> <ms-dns1 194.109.6.66> <ms-dns3 194.109.9.99>]
sent [IPCP ConfReq id=0x4 <addr 83.162.x.x> <ms-dns1 194.109.6.66> <ms-dns3 194.109.9.99>]
rcvd [IPCP ConfAck id=0x4 <addr 83.162.x.x> <ms-dns1 194.109.6.66> <ms-dns3 194.109.9.99>]
rcvd [IPCP ConfReq id=0x58 <addr 194.109.5.175>]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x58 <addr 194.109.5.175>]
ipcp: up
Script /etc/ppp/ip-pre-up started (pid 20279)
Script /etc/ppp/ip-pre-up finished (pid 20279), status = 0x0
local IP address 83.162.x.x
remote IP address 194.109.5.175
primary DNS address 194.109.6.66
secondary DNS address 194.109.9.99
Script /etc/ppp/ip-up started (pid 20329)
Script /etc/ppp/ip-up finished (pid 20329), status = 0x0

Is het mogelijk om via de management te zien of de interface in de genexis op max mtu 1500 staat?

[m.vand...@coolblue.nl]

Ah, het probleem gevonden zo te zien :)
Tijdens het opzetten van de PPPoE sessie stond TCP MSS clamping nog enabled. Dit zorgde er dus blijkbaar ook voor dat de PPPoE packets maar max mtu 1492 waren. Ik heb dit nu nu eerst uit de config gehaald, en daarna opnieuw een PPPoE sessie gestart. Dit lijkt nu wel goed te gaan met mtu 1500.

$ ping -c 1 -D -s 1472 xs4all.nl
PING xs4all.nl (194.109.6.93): 1472 data bytes

1480 bytes from 194.109.6.93: icmp_seq=0 ttl=61 time=7.330 ms

--- xs4all.nl ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 7.330/7.330/7.330/0.000 ms

Aan jullie kant zou het nu dus ook goed zijn :)

Thanks!

[Miquel van Smoorenburg]

In article <41833755-91ff-4f57...@googlegroups.com>,

Volgende project natuurlijk: IPv6 aanslingeren!

Mike.

[m.vand...@coolblue.nl]

Yes, staat nog op mijn todo. Mijn vorige ISP assignde een /64 via de PPPoE sessie, hier gaat het net even anders. Nog niet heel diep ingedoken.

[Bart]

Sinds 1.6.0 ondersteund EdgeOS DHCPv6 prefix delegation en zou je met
de volgende config een aardig eind op weg moeten zijn:

set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 prefix-length /48
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 interface
eth1 service slaac
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 interface
eth1 prefix-id :1
set interfaces ethernet eth1 ipv6 router-advert prefix ::/64
set interfaces ethernet eth1 ipv6 router-advert radvd-options "RDNSS
2001:888:0:6::66 {};"

Herstart de router als deze config is gecommit en gesaved. Als het goed
is zal deze config je /48 opvragen via DHCPv6 PD en op eht1
PREFIX:1::/64 adverteren. Mike raad aan (verbeter me als ik dit
verkeerd zeg) om de 1e /64, PREFIX::1, aan de loopback interface te
hangen zodat de router reageerd op ping6 naar PREFIX::1. Ik ben
benieuwt of je het hiermee aan de praat kan krijgen.

--Bart

[recomb...@gmail.com]

Op donderdag 31 oktober 2013 10:39:22 UTC+1 schreef Miquel van Smoorenburg:
> Sinds vannacht staat op de routers die gebruikt worden om de PPPoE sessies
> van glasvezelklanten te termineren RFC4638 / ppp-max-payload support aan.
>
> Dat betekent dat als je een router hebt die dat support, je een
> MTU van 1500 kan gebruiken ipv 1492.
>
> De fritzboxen supporten dat op dit moment niet, maar er staat wel
> een RFE (request for enhancement) uit bij AVM.
>
> Bij een Cisco zou het 'tag ppp-max-payload' moeten zijn in de
> virtual-template config.
>
> Met een Linux router moet je de MTU van je ethernet interface
> waar pppd op draait verhogen naar minimaal 1508 (bv 1600 ofzo),
> en deze patch toepassen:
> http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7
>
> Ben benieuwd of iemand dit client-side aan de praat krijgt :)
>
> Mike.

All,

ik heb sinds kort op m'n EdgeRouter (op glas) ook de wan interface mtu opgehoogd naar 1508 en de pppoe mtu op 1500 gezet. Dit werkt prima echter zonder mss-clamping op 1452 gaat het nog steeds niet goed. Als ik wat checks doe met bijvoorbeeld Netalyzr blijkt dat mijn uitgaande path mtu 1500 ondersteunt maar de weg terug naar mij een max heeft van 1492.
Dit zou fout gaan op 194.109.7.170

xe7-0-0.dr11.d12.xs4all.net (194.109.7.170)

Klopt het dat er dus nog niet overal een mtu van 1500 te gebruiken is??

Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2015-03-09 15:04 CET
SENT (0.0041s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=17648 seq=1] IP [ttl=64 id=30193 iplen=1492 ]
RCVD (0.0112s) ICMP [194.109.7.170 > 10.10.10.50 Echo reply (type=0/code=0) id=17648 seq=1] IP [ttl=63 id=18665 iplen=1492 ]
SENT (1.0085s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=17648 seq=2] IP [ttl=64 id=30193 iplen=1492 ]
RCVD (1.0167s) ICMP [194.109.7.170 > 10.10.10.50 Echo reply (type=0/code=0) id=17648 seq=2] IP [ttl=63 id=19952 iplen=1492 ]

Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2015-03-09 15:03 CET
SENT (0.0042s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=1378 seq=1] IP [ttl=64 id=18520 iplen=1493 ]
SENT (1.0069s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=1378 seq=2] IP [ttl=64 id=18520 iplen=1493 ]
SENT (2.0123s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=1378 seq=3] IP [ttl=64 id=18520 iplen=1493 ]
SENT (3.0172s) ICMP [10.10.10.50 > 194.109.7.170 Echo request (type=8/code=0) id=1378 seq=4] IP [ttl=64 id=18520 iplen=1493 ]

Iemand een idee toevallig??

Grt,
Randy.

[Randy Schumacher]

Ter aanvulling de snippet van Netalyzr :

Path MTU (?): OK -
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1492 bytes. The bottleneck is at IP address 194.109.7.170.

Randy.

[Randy Schumacher]

Nevermind :-)

Path MTU (?): OK -

The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.

er miste nog een aanpassing op de EdgeRouter in de ppp options file. De MRU werd nog steeds vastgezet op 1492. Na een aanpassing in de file gaat het nu prima.

R.

[Miquel van Smoorenburg]

In article <8dad8306-8675-46d3...@googlegroups.com>,

<recomb...@gmail.com> wrote:
>ik heb sinds kort op m'n EdgeRouter (op glas) ook de wan interface mtu
>opgehoogd naar 1508 en de pppoe mtu op 1500 gezet. Dit werkt prima
>echter zonder mss-clamping op 1452 gaat het nog steeds niet goed. Als ik
>wat checks doe met bijvoorbeeld Netalyzr blijkt dat mijn uitgaande path
>mtu 1500 ondersteunt maar de weg terug naar mij een max heeft van 1492.

Dan doet de Edgerouter het fout- als de xs4all router vind dat
de MTU 1492 is, dan komt dat omdat dat zo onderhandeld is met
de Edgerouter (middels de MRU die door de edgerouter zelf
wordt gestuurd), en de Edgerouter zou dat ook moeten weten.

>Iemand een idee toevallig??

Bug in de Edgerouter, misschien fixbaar door de configuratie aan
te passen. Bv zorg dat op zowel op je ethernet interface *als*
op de vlan subinterface de MTU op 1508 staat, en op de PPP
interface op 1500.

Van iemand die verstand heeft van Edgerouters:

"als pppoe onderhandeling op 1492 uit komt en je hebt 1500
geconfigureerd zet hij inteface wel op 1500 niet gerelateerd aan
onderhandeling maar aan setting in cli"

Mogelijke oplossingen:

- zorg ervoor dat je de laatste firmware draait
- check alle MTU settings op alle (sub)interfaces
- gebruik "show interfaces pppoe pppoe0 log " om uit te
vinden wat er mis gaat

Mike.

[Randy Schumacher]

Hi Miquel,

klopt inderdaad. In de pppoe log zag je dat de MRU nog op 1492 werd gezet. Na het handmatig aanpassen van de /etc/ppp/options file werkt het wel en wordt de MRU gewoon op 1500 gezet en werkt het prima zonder Clamping.
Schijnbaar is dit dus niet standaard vanuit de CLI mee te nemen op de Edgerouter en moest dit nog handmatig aangepast worden.

# Disable MRU [Maximum Receive Unit] negotiation (use default, i.e.
# 1500).
-mru

"#" weggehaald voor "-mru" en het draait als een tierelier.

Bedankt in ieder geval..... happy dat het werkt :-)

Grt,
Randy.

[zeil...@gmail.com]

Hoe staat het met de RFE bij AVM? Ik heb een Fritz!Box 7490 en zou graag een hogere MTU gebruiken.

[MM]

On 16-4-2015 10:45, zeil...@gmail.com wrote:
> Hoe staat het met de RFE bij AVM? Ik heb een Fritz!Box 7490 en zou graag een hogere MTU gebruiken.
>

Zal vast nog wel even duren. Op de actuele firmware naar Internationaal
overzetten neemt al een paar maanden in beslag. Ze zijn daar in Berlijn
in slaap gesukkeld of er zijn wel erg veel bugs gemeld door de beta testers.

[Miquel van Smoorenburg]

In article <c74c025f-7e06-4d53...@googlegroups.com>,

<zeil...@gmail.com> wrote:
>Hoe staat het met de RFE bij AVM? Ik heb een Fritz!Box 7490 en zou graag
>een hogere MTU gebruiken.

Het is nog steeds een RFE, met de R van request ....

Mike.

[zeil...@gmail.com]

Dat begrijp ik, maar XS4ALL zou hier toch wel een status van kunnen opvragen? Zelf heb ik ook navraag gedaan bij AVM support en kreeg het volgende antwoord: "Bedankt voor uw bericht. Ik heb het doorgestuurd als Enhancement. Deze vraag is mij niet nieuw en ik hoop, dat deze optie met een komende firmware update aangeboden wordt."

[Miquel van Smoorenburg]

In article <5d17a75b-8284-46bf...@googlegroups.com>,

Ik heb hier regelmatig contact over. Er wordt naar gekeken- maar
wanneer dit in een firmware release komt (en op welke modellen,
misschien kunnen ze het niet allemaal - moet ook uitgezocht)
is nog niet bekend.

Mike.