config dsl 'dsl'
option annex 'a'
option tone 'av'
option ds_snr_offset '0'
option xfer_mode 'atm'
option line_mode 'adsl'
option firmware '/lib/firmware/lantiq-vrx200-a.bin'
config device
option name 'br-lan'
option type 'bridge'
option ipv6 '0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config device
option name 'lan1'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ipv6 '0'
config device
option name 'lan2'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ipv6 '0'
config device
option name 'lan3'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ipv6 '0'
config device
option name 'lan4'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ipv6 '0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config device
option name 'dsl0'
option macaddr 'xx:xx:xx:xx:xx:xx'
option ipv6 '0'
config interface 'wan'
option proto 'pppoa'
option encaps 'vc'
option atmdev '0'
option vci '35'
option vpi '8'
option username '****'
option password '****'
option mtu '1478'
option peerdns '0'
list dns '94.140.14.14'
list dns '94.140.15.15'
config device
option name 'eth0'
option ipv6 '0'
config device
option name 'wlan1'
option ipv6 '0'
Since my WAN has PPPoA, I set the WAN MTU to 1478 (because from what I understod its the best MTU for PPPoA, from an actual- data vs padding pov, 1438 data + 205 padding, I might be wrong PLS correct me if I'm wrong).
Since my router supports jumbo frames should I set the other interface ('lan') to have an MTU as multiple of 1438? or 1478? Or something else + some kind of padding?
Also from luci I see I can set the single MTU of each device, should I set the mtu also there? or setting it only on the interface is enough?
Also, do I really need to create a bridge interface to bridge my switch ports? Shouldn't I be able to just write something like:
config interface 'lan'
option device 'eth0' <--- changed br-lan to eth0
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
But isn't it bad for the LAN <-> WAN coms? Like if data going in/out from/to WAN is stored in 1438 bytes packets (if my assumption in the first post is correct) and LAN communicate with something else, shouldn't this this make the communication less efficient because the router has to split single packets of one network in multiple packets of the other network?
Also btw, I could need, or at least try, bigger MTUs to improve in-home streaming.
Also I assume buffers are in place to smooth the transitions, like if (as example) my WAN uses 10 byte packets and my LAN use 11, when my LAN send two packets (so 11 + 11) the router waits a bit and send only 3 packets to WAN (10 + 10 + 2) and not 4 (10 + 1 + 10 + 1).
L2 network ends at gateway router. It would need to do an extra job of fragmenting IP packets. However because TCP connections become less robust if fragmentation takes place there is MSS discovery algorithm which limits packet sizes. UDP connections still may suffer.
AFAIK there is no buffering on L3 layer, so small fragments will be sent separately. There is something similar in TCP, but it probably won't apply.
Jumbo frames are not likely to improve streaming in your LAN. I believe their primary purpose fix packet rate bottlenecked scenarios, like CPU load.
You only need to specify the proper MTU for upstream interfaces. PMTUD should automatically adjust MTU for traffic traversing the router.
It's best to keep the default MTU for downstream interfaces.
AFAIK the devices on a LAN have to agree on the MTU, unless you configure MTU in specific routes to some devices on the LAN which supports jumbo frames.
And you probably need to use MSS clamping anyway on the WAN interface. You can't rely on PMTUD for IPv4 over the Internet since the ICMP messages it depends on are often blocked.
Could this be related to the fact that I can (at least now with the new DSA config style, I can't remember how it was with the old config) set a specific MTU for each lan port?
Anyway setting it to the max the router supports isn't still a good thing? From what I understood (from yours and the other responses), if two hosts, in the same lan, wants to talk to each other but only one of them and the router supports 9K MTU everything should just works anyway right?
Also, from my Intel NIC settings I see "9K" is it 9000 or 9216?
The MTU is both used when sending and receiving. It means that a receiver configured with MTU 1500 will drop the frame if it receives a jumbo frame (payload > 1500) from a sender configured with MTU larger than 1500.
So PPPoA will have an overhead of either 2+8 = 10 (VC/MUX) or 2+12 = 14 bytes (LLC) on top of the ethernet frame payload.
So the total size of a packet is MTU+10 or MTU+14 (but the maximum segment size is at best 1500-20-20 = 1460).
ATM/AAL5 will be most efficient if no padding is required, that is when the size (payload + per-packet-overhead) of a packet is an integer multiple of ATM's 48 byte payload per ATM cell:
((MTU+outer-per-packet-overhead)/ ATM payload-size)
((1500+14)/48) = 31.5416666667
or
((1500+10)/48) = 31.4583333333
-> which both will result in 32 ATM cells (as AAL5 requires, that each user data frame is packaged into an integer number of ATM cells and no ATM cell contains data from multiple user data frames.
If one knows the exact encapsulation parameters (for ATM/AAL5 these can be heuristically deduced) one can set the MTU such that the data of a full sized data frames fills an integer number of ATM cells completely resulting in zero padding bytes and maximum efficiency (as ratio of payload to data transmitted over the link):
so depending on the actual encapsulation, the most efficient MTU will be either
((1500-26+14)/48) = 31 -> MTU 1500-26 = 1474
or
((1500-22+10)/48) = 31 -> MTU 1500-22 = 1478
note that your number assumes VC/MUX, but if your ISP should use LLC you get:
(1478+26)/48 = 31.3333333333 -> 32 ATM cells, just the same as with MTU 1500, except you lowered efficiency by reducing the payload to 1478 instead of 1500 Bytes.
AND you now have the problem that path MTU discovery (pMTUd) needs to work reliably, as otherwise some senders will not be able to properly reach you... for TCP you can help this discovery process by clamping MSS values to 1478-20-20 = 1438 for IPv4 and to 1478-40-20 = 1418, as MSS is negotiated between endpoints, but for UDP no such signaling technique exists today (albeit the IETF is working on an UDP options specification that would add such information to UDP, helping exactly zilch for all the existing UDP senders deployed in the field).
So you need to make a decision between the following three options:
efficiency is most important, in which case reduce the MTU to 1478 or 1474 after figuring out the actual encapsulation on your link.
play it safe, and only use MSS clamping to make TCP more efficient but keep UDP from breaking in light of pMTUd being unreliable
dont't bother keep MTU at 1500 and accept the smallish peak goodput sacrifice of
100 * (((1500-20-20)/((ceil((1500+10)/48)*53))) - ((1478-20-20)/((ceil((1478 +10)/48)*53)))) = -1.44%-age points
Personally I would probably go for 3) above and simply hope that my ISP would switch me away from ADSL soon
To enable jumbo frames should I set option mtu '9014' on eth0, br-lan, lan1 to 4 and wan? I choose 9014 because on my win machine is see this:
Should I set eth0 to be 8 more (so 9022)?
Also, isn't this a really big mess? I remember (before this DSA thing, on my "old" TD-W8980) to be able to avoid any per-port definition, bridges and VLAN bs, and just set (from an high-level pov) the eth interface (the switch) to be the 192.168.1.X network and the wlan is the 192.168.2.X network... this was also clear by running ifconfig, which before DSA would return just 4 entries (pppoa, wlan, eth and lo) and now is this thing:
So I believe that people invested time to enable baby jumbo frames on DSL SoCs to allow a usable MTU of 1500 into the wider internet even over PPPoE tunnels. If you use the router as bridged modem and have another router handle the PPPoE termination, you need MTU 1508 over ethernet...
BUT your ISP needs to support that, which my ISP does not, so I have no first hand experience if/how this feature works/performs IRL.
Erm, no first hand experience with Jumbo frames on my side, but I think I once read, that the upper limit is implementation dependent, so you need to get a list of the highest supported MTUs for all your devices and then configure the minimum of that, IFF you actually want to go that route at all.
Probably not, your MTU to the internet will be limited to 1500 anyway, the whole 1508 business is just to allow the 8 byte PPPoE overhean not to "eat into" the internet MTU (so after PPPoE decasulation at your ISP). Once your LAN MTU is >= 1508, rfc4638 should work, IFF your ISP actually supports that.
Jumbo frames? Yes, as far as I can tell they are, at least they are not really "plug and play".
Yes, DSA is decidedly different from swconfig, and appears more complicated. BUT the upstream Linux kernel has rejected OpenWrt's swconfig (when it was offered) and decided on DSA, so OpenWrt is a good Linux citicen here, and makes DSA work. But that means that all of us users who "learned" swconfig will have to adapt (and probably also shake out a few bugs in the DSA implementation).
Lucky I have only one device for everything (switch / modem / wi-fi ap.... I love my HomeHub 5A).
I would try to enable jumbo frames regardless, even if just for fun / learning. I mostly want to try if it improves my in-home streaming or interactions with my NAS... but I already understood that probably it will be just placebo.
Btw ty for all yours responses. You really helped me a lot!
Yes, AIO is a convenient form-factor especially if a single AP is enough to supply your full area. Then again that HH5A easily reaches its limit. In my testing on a 50/10 VDSL2 link I could not run PPPoE/Nat/firewall/SQM/WiFi at the 45/9 shaper rate I aimed for, and other users report that as a router without SQM it barely is fast enough for BT's 80/20 speed tier. (I configured mine as bridged-modem under OpenWrt a configuration under which it manages to bi-directionally saturate my 116/35 synced link)
Then go for it learning is always a good thing. And no, if properly configured on all devices Jumbo frames can help speed up bulk transfers that quantitatively will use large packets. So for data transfers to/from a powerful NAS it might actually help a bit. As long as you manage your expectation like above I hope you will be pleasantly surprised. (What Jumbo frames will not magically do is have your network perform magically better in all dimensions, but since you understand that, you are fine).
DSA adds a(n often proprietary, matching your switch hardware) DSA header to each packet, to allow the internal seitch doing the VLAN filtering that way. This means the physical interface/ CPU port now needs to account for this additional header (+8).
