PPPOE MTU ALWAYS DEFAULTS TO 1480 INSTEAD OF 1492

[himurae]

didnt help its still exactly the same as before

[himurae]

Update !!! mikrotik is working on a implementation to disable RFC4638 test they emailed me the same..

[hasmidzul]

Same here (hap ax3 user)…I could never get mtu 1492 pppoe client…always goes back to mtu 1480, no matter how i manually set mtu mru etc..
But when I use my openwrt router (pppoe client), I can get mtu 1492 automatically.

ok there has been response from support@ mikrotik they have made some changes for pppoe Finally!!!

But i have a x86 box and there is no chr/iso image in this can someone test it and give feedback!!

https://box.mikrotik.com/d/bc148d4405e94feaa2cc/

Flashed to my hap ac2…Stil the same…1-2 second only on 1492 and back to 1480.

[himurae]

ok there has been response from support@ mikrotik they have made some changes for pppoe Finally!!!

But i have a x86 box and there is no chr/iso image in this can someone test it and give feedback!!

https://box.mikrotik.com/d/bc148d4405e94feaa2cc/

Flashed to my hap ac2…Stil the same…1-2 second only on 1492 and back to 1480.

i know i tested it myself and told them they are implementing something new for pppoe users now lets wait and see

[ppptran]

Just my two cents.

I’m inclined to think it’s your ISP.

I’m currently running a CHR on Proxmox 8.3.4 with a dual Intel 10Gbps NIC via PCIe Passthrough (82599ES 10-Gigabit SFI/SFP+ Network Connection (rev: 1))

ISP is Vodafone Ireland FTTH and uses PPPoE served on VLAN10. The default PPPoE interface MTU was 1492 as expected. However Vodafone support baby jumbos so I have manually set MTU of ether1 to 1508. As ISP uses VLAN10 a VLAN interface was added for ether1 also with an MTU of 1508

/interface vlan
add comment=ISP interface=ether1 mtu=1508 name=VF_VLAN_10 vlan-id=10

/interface ethernet
set [ find default-name=ether1 ] comment="ISP_ONT" mtu=1508

PPPoE interface is under the VLAN interface and has automatically assigned MTU of 1500 and everything works as expected.
pppoe1.png
pppoe2.png

So, does the PCIe Passthrough (82599ES ) show SFP information ? or is it just shown as regular ethernet port ?

Im in the same situation right now, CHR on Promox, with 82599ES card. I’m using linux bridge, and add this card to bridge. Then add bridge as Network port on CHR.
With this linux-bridge, CHR show those 2 ports as regular ethernet. It works fine with uplink 1G. I havent test 10Ge uplink cause i dont have 10G switch to test yet.

It would be nice if we can actually passthrough PCI for 82599ES and see the SFP information

[magnavox]

Update !!! mikrotik is working on a implementation to disable RFC4638 test they emailed me the same..

Hi, does anyone know if MikroTik has released a definitive fix for this issue?

[himurae]

not yet in the meantime please send emails to Oskar at support@mikrotik.com and mention this specifically so he understands “Could RouterOS launch an option that allows you to disable the RFC4638 test. since my pppoe mtu defaults to 1480”

[magnavox]

not yet in the meantime please send emails to Oskar at support@mikrotik.com and mention this specifically so he understands “Could RouterOS launch an option that allows you to disable the RFC4638 test. since my pppoe mtu defaults to 1480”

Ok, many thanks, just sent!

[himurae]

Ok people seems they finally listened and our issue gets resolved in RouterOS version
7.20beta
ppp - do not send initial echo request if keepalive-timeout=disabled;



Please test this version and see folks!!!¡

[raelcx]

Ok people seems they finally listened and our issue gets resolved in RouterOS version
7.20beta
ppp - do not send initial echo request if keepalive-timeout=disabled;



Please test this version and see folks!!!¡

I can confirm that 7.20beta2 fixed the issue.
Now i am able to get 1492 MTU and it does not change to 1480 MTU after few seconds.

My internet connection is working flawless now!!!

[himurae]

Finally it works guys ,the key point for x86 version was disabling keep alive timeout (default is 10)
Thanks mikrotik and guys we made it after all