I connect to my ISP using PPPoE, and my Route10 has connected using an MTU of 1492 instead of 1500. I have enabled jumbo frames but this appears to have had no effect. On my old router, I set the MTU to 1508 on the L2 interface, and 1500 on the L3 interface.
Is there any update? This is still an issue.
Just a quick clarification on PPPoE MTU:
1492 is actually the correct and expected MTU for a PPPoE WAN. PPPoE adds 8 bytes of overhead, so the standard Ethernet 1500-byte frame can only carry a 1492-byte IP packet. That’s why you’re seeing 1492; the router is behaving correctly.
So the MTU you’re seeing isn’t an error, it’s simply the normal PPPoE limit.
This sounds like it should be a feature request to allow baby jumbos and/or configurable values for jumbo frames.
EDIT: just to clarify further as this doesn’t account for everything. In case you didn’t notice, we also set MSS clamping to subtract 40 bytes from the MTU. So with a 1492 PPPoE MTU, the resulting TCP MSS is 1452.
2 Likes
Hello Alta-MikeD , please take note about the MTU 1500 PPPoE under RFC4638 and please implement it in a future firmware, thanks in advance
These are called baby jumbo frames (also known as baby giants), like I mentioned above. As this isn’t supported currently meaning this should be a feature request to expose/add support for baby jumbos on per WAN basis.
EDIT2: I’m asking if we have existing plans, as I’m not sure off-hand. If not, I’ll convert this topic to a feature request
Since next-generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 octets in order to limit the amount of fragmented packets in networks similar to those described in Section 1.
1 Like
We do not have existing plans. My ISP actually supports this, so let me give it a quick test.. I should make sure it works before switching this to a feature request. Maybe I can even offer a temporary band-aid in the interim; we’ll see.
EDIT: pictures and stuff 
First 2 ping commands are before modification, last ping is after modification showing immediate change on ping with DF bit set.
I think this can safely go into a post-cfg.sh for the time being. Going to convert to a feature request, and will follow up.
1 Like
This should work, or at least it does here. Please make sure to update the variables. The physical interface name, and also the logical WAN name.
For physical naming, ports from left to right are:
eth3, eth2, eth1, eth0, eth5, eth4
The logical name is simpler. If you’re using WAN or WAN1, it’s just wan, and WAN2 is wan2, you can check which one is configured as PPPoE from Settings>Networks>WANs, or by viewing the port overview in the Route10 config modal, and selecting the applicable WAN interface.
This script is recommended for single WAN environments only. If multi-WAN you may require to reboot or powercycle on reboots, upgrades, and/or provisions that touch the Route10. More on this below this comment. 3rd revision:
#!/bin/ash
# rfc4638 (baby jumbo) MTU/MRU fix for PPPoE on Route10
#
# Supports:
# A) PPPoE directly on PHY_IF (VID empty)
# B) PPPoE on VLAN device PHY_IF.VID (VID set)
#
# Behavior:
# - Always set PPP_SECTION MTU/MRU = PPP_MTU (default 1500)
# - If VID is set:
# * WAN_DEV = PHY_IF.VID
# * Set WAN_DEV MTU = CARRIER_MTU (default 1508)
# * Set PHY_IF MTU = CARRIER_MTU + VLAN_OVERHEAD (default 1512)
# - If VID is empty:
# * WAN_DEV = PHY_IF
# * Set PHY_IF MTU = CARRIER_MTU (default 1508)
# - Commit + apply at runtime + bounce PPP_SECTION
PPP_SECTION='wan2' # UCI interface section for PPPoE (e.g. 'wan' or 'wan2')
PHY_IF='eth4' # Parent physical device (e.g. eth4)
VID='' # Optional VLAN ID only (e.g. 35). Leave empty for no VLAN.
CARRIER_MTU='1508' # MTU required on the device carrying PPPoE frames (RFC4638)
PPP_MTU='1500' # MTU/MRU on PPPoE interface
VLAN_OVERHEAD='4' # 802.1Q tag overhead (bytes)
PATH=/sbin:/usr/sbin:/bin:/usr/bin
set -u
log() { logger -p user.notice -t post-cfg-rfc4638 "$*"; }
warn() { logger -p user.warning -t post-cfg-rfc4638 "$*"; }
# Find (or create) a "config device" section whose option name == $1, then set its mtu.
ensure_device_mtu() {
local dev="$1"
local mtu="$2"
local sec=""
# Look for: network.@device[N].name='<dev>'
sec="$(uci -q show network | sed -n "s/^\(network\.@device\[[0-9]\+\]\)\.name='${dev}'$/\1/p" | head -n1)"
if [ -z "${sec}" ]; then
# Create a new anonymous device section
sec="network.@device[-1]"
uci add network device >/dev/null 2>&1 || {
warn "Failed to add device section for ${dev}"
return 1
}
uci set "${sec}.name=${dev}" || return 1
fi
uci set "${sec}.mtu=${mtu}" || return 1
return 0
}
# Decide WAN device and MTUs
WAN_DEV="${PHY_IF}"
PARENT_MTU="${CARRIER_MTU}"
VID_DEV=""
if [ -n "${VID}" ]; then
VID_DEV="${PHY_IF}.${VID}"
WAN_DEV="${VID_DEV}"
PARENT_MTU="$(( CARRIER_MTU + VLAN_OVERHEAD ))"
fi
log "Applying RFC4638: PHY_IF=${PHY_IF} MTU=${PARENT_MTU}, WAN_DEV=${WAN_DEV} carrier MTU=${CARRIER_MTU}, ${PPP_SECTION} MTU/MRU=${PPP_MTU}"
# UCI: enforce device MTUs
ensure_device_mtu "${PHY_IF}" "${PARENT_MTU}" || warn "Failed to set UCI device MTU for ${PHY_IF}"
if [ -n "${VID_DEV}" ]; then
ensure_device_mtu "${VID_DEV}" "${CARRIER_MTU}" || warn "Failed to set UCI device MTU for ${VID_DEV}"
fi
# UCI: PPPoE interface settings
uci set "network.${PPP_SECTION}.device=${WAN_DEV}"
uci set "network.${PPP_SECTION}.mtu=${PPP_MTU}"
uci set "network.${PPP_SECTION}.mru=${PPP_MTU}"
uci commit network
# Apply at runtime (best effort)
ip link set dev "${PHY_IF}" mtu "${PARENT_MTU}" 2>/dev/null || warn "Runtime: failed to set ${PHY_IF} MTU ${PARENT_MTU}"
if [ -n "${VID_DEV}" ]; then
ip link set dev "${VID_DEV}" mtu "${CARRIER_MTU}" 2>/dev/null || warn "Runtime: failed to set ${VID_DEV} MTU ${CARRIER_MTU}"
fi
# Bounce PPPoE to re-negotiate
ifdown "${PPP_SECTION}" 2>/dev/null
ifup "${PPP_SECTION}" 2>/dev/null || warn "Failed to bring up ${PPP_SECTION}"
log "Bounced ${PPP_SECTION} (device=${WAN_DEV}); PHY_IF MTU ${PARENT_MTU}, carrier MTU ${CARRIER_MTU}"
exit 0
HERE’s a guide I wrote a while ago for generating/saving a post-cfg.sh file, if that’s helpful. If you have any questions or issues, please let me know.
EDIT: added note about single WAN recommendation for current iteration of baby jumbo script
3 Likes
Just wanted to circle back here. My apologies, the above script has a pretty nasty bug in a failover multi-WAN env. My PPPoE WAN is my the primary and the backup is DHCP, but it may occur in other multi-WAN combinations.
I have worked on a new version that handles cold/warm boots, firmware upgrades and provisioning more gracefully, and it seems to work albeit it adds some time to some of the aforementioned events. At least it’s graceful—the old one would trigger the routing tables and connections to get mixed up (state drift of sorts).
If you hit this bug and can reach the device via SSH, you should be able to issue a reboot which should fix it, otherwise a powercycle seems to fix it reliably for me. Do note I use a XGS-PON module, and it’s slower boot time might be why a cold-boot works reliably as a fix, and it may not work in all envs.
I’m refraining from sharing just yet as it’s specific to my connection, but I wanted to at least make anyone using it aware. I can try and share an early version if you reach out via DM but ideally I hope to iterate on it to improve the time for the mwan3 logic and also make it portable/universal (say for both failover and load-balancing envs).
2 Likes
Thanks for the update! Fortunately I do not use wan failover, but it is good to know in case I planned to use it.
One question, if my ISP uses a vlan, do I need to set PPP_SECTION to the vlan interface rather than the ethernet interface?
Not quite. The PPP_SECTION is a ubus mapping, and it’ll map to the logical name for the WAN, which are always named wan, wan2, wan3, etc at the system level. By default wan is assigned to the farthest left Ethernet port (eth3), and wan2 is assigned to the farthest right port, which is an SFP+ port (eth4). I’ve renamed the default wan2 to Bell FttH (naming affects FE only), but this is how it looks for me:
You can use ifstatus wan or ifstatus wan2, etc., if you want to check the logical naming from the ubus perspective.
Hope that helps clarify, but please let me know if I can be of further assistance.
Edit: Adjusted wording around logical naming for clarification
EDIT2: secondary mistake 
needs an other update, both the main interface and VID sub-interface need to have the MTU+MRU adjhusted. I earlier suggested to modify the sub-interface, but leave teh parent. That was wrong.
My sincere apologies, I partially led you astray. I updated it with a new version of the script. The parent interface is 2 interfaces, and would actually require a different value compared to the VLAN sub-interface, so I updated the script to handle various cases. Further to that the values may vary depending on which case.
- If
VID=''(no VLAN): it sets PHY_IF = 1508 and PPPoE MTU/MRU = 1500. - If
VID='35'(VLAN): it sets PHY_IF = 1512, PHY_IF.35 = 1508, and PPPoE MTU/MRU = 1500.
The latest revision is above. So you would want to set the PHY_IF to the main interface. Reminder, left to right it’s: eth3, eth2, eth1, eth0, eth5, eth4. If there is no VID, then leave it blank as it is, but if required, just enter the number of the VLAN ID between the single quotes.
1 Like