PPPoE mtu/mru on wan

epek

@ThorstenK:

Customizing mtu is symphatic for special cases, like if you have eg vrfs behind and so on.

It is up to the user to decide, if he wants to change this value depending on his use case.

@ThorstenK:

But not to set this value as a default, as this would produce smaller packets on pppoe links in general.

A default of 1492 is ok in most cases, but you should have the freedom to change it.

@ThorstenK:

And what do you think for the case (not mentioned in the link) if the packet is decapsylated by the DSLmodem and
reencapsylated in PPPoverATM to get rid of the pppoe header ?

As mentioned, it's up to the user to decide. Setting an overall value in general without the option to change it, is a quite ignorant approach to work with heterogenuous networks.

Setting an MTU of 1500 on Ethernet-Interfaces is also ok in most cases, but there are always exceptions to a general rule.

regard
epek

Hi, yes - cause of this i started some work to get more customization into pfsenses ppp Dialog.
For sure everyone should have the freedom to write patches - thats what oss is all about ;)
I trained js and jQuery the whole weekend to get the knowledge required for that task.

If you are searching for a start, you might want to look at
http://forum.pfsense.org/index.php/topic,49478.0.html

oh, and for the ethernet example we could imaging a jumbo frames case where we want to use a MTU of 8192 so theres alot to imagine :)

hanD!

epek

@ThorstenK:

Hi, yes - cause of this i started some work to get more customization into pfsenses ppp Dialog.

Well, thanks!

edit: I just took a look at it in /usr/local/www/interfaces_ppps_edit.php - it seems we are only missing the table cells and table rows. The script itself checks for mtu, mru, mrru, if they are set.
…
it seems i cannot use them - I do not understand yet.

@ThorstenK:

For sure everyone should have the freedom to write patches - thats what oss is all about ;)
I trained js and jQuery the whole weekend to get the knowledge required for that task.

I am currently under pressure. Maybe can contribute in the first two weeks of July, when another wave of exams has passed by.
To be honest, I am new to BSD - I usually work with the debian and ubuntu distributions and have yet to readapt my mind to some of the diverging concepts of BSD.

@ThorstenK:

If you are searching for a start, you might want to look at
http://forum.pfsense.org/index.php/topic,49478.0.html

Thanks for the info. I'll have to do some more reading first. I am not yet familiar with it in detail.

@ThorstenK:

oh, and for the ethernet example we could imaging a jumbo frames case where we want to use a MTU of 8192 so theres alot to imagine :)

hanD!

Since the Jumbo Frames as such are not subject to a specific standard as such, shouldn't it be sufficient to just set the MTU to 8210 as long as the other components can handle it?
http://en.wikipedia.org/wiki/Jumbo_Frames
Or is there any limitation by the protocol stack?

databeestje

jumbo frames already work, just not all adapters, i've not had any issues with em,igb or bge nics.

The pretty much agreed upon standard size for "jumbo frames" is 9000 bytes, or exactly 4 times the standard frame.

Some implementations differ though, some have 9018 that take into account vlan tags and/or checksums.

epek

hej databeestje!

See my edit please - any hints?

ui - thats good to know - i remembered this value because its 64bit aligned. thanks for correcting :)

dadiy

Does this mean we might see baby jumbo frames (MTU 1508) for PPPoe connections soon?

databeestje

Unlikely, although nothing prevents this in theory, the ISP needs to cooperate.

dadiy

My ISP AAISP does support baby jumbo frames for PPPoE connections, that's why I asked.

@databeestje:

Unlikely, although nothing prevents this in theory, the ISP needs to cooperate.

Sweety ! Ill call them baby-jumbo-frames from now !:) This term is just way to cool to not use it, hehe :))