PPPOE MTU ALWAYS DEFAULTS TO 1480 INSTEAD OF 1492

[rextended]

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.

If you don’t show (the export) how you configured the device, what do you expect?

I have hAPs from dozens of customers, and they all work fine with PPPoE at 1500.

[Tathastu]

Hope you find the underlying issue soon best of luck!!

[himurae]

why does VyOS only go to 1492 instead of 1500???

For VyOS to set ppp-max-payload=1500 in the PADI message the OP will need to do the following:

• Set mru and mtu on the pppoe interface to 1500 (E.g. set interfaces pppoe pppoe0 mru 1500 / set interfaces pppoe pppoe0 mtu 1500), or delete both (don't let them at 1492).
• Increase the MTU of the internet interface to at least 1508 (this is not needed in RouterOS but it's a must in VyOS, I just tested and if you don't do this there is no ppp-max-payload parameter in PADI/PADR).

OP probably did not explicitly do that. In that case 1492 is the max negotiated MRU value for both sides (MRU of one side is MTU of the other side).

@CGGXANNX UR THE MAN!!!!!!! vyos pppoe is now 1500

Edit i noticed streaming/utube/iptv is fine but web pages were loading slower than before ,i think its a mtu issue.. 1492 is faster for me

[himurae]

This is how you change the MTU in a virtual environment running CHR (or any other virtual guest).

Windows Hyper-V

• With SR-IOV: MTU can be changed directly by CHR.
• Without SR-IOV (using the Hyper-V virtual switch): MTU must be set on the host first and then on the virtual switch for changes to take effect in CHR.

Linux KVM and similar

• With SR-IOV/PCI Passthrough: MTU can be changed directly by CHR.
• With Bridge or NAT: MTU must be set on the host first for changes to take effect in CHR.

For SR-IOV to work properly, a specific NIC driver must be installed on both the host and the virtual guest. The host needs a driver that supports SR-IOV for the physical NIC, while the guest must have a compatible driver for the Virtual Function (VF) of the NIC. If the driver is missing on either side, the guest won’t be able to use the SR-IOV interface correctly.

@Larsa
i did further tests using pci passthrough its still mtu is behaving exactly same as before mtu wont go 1492 no matter what, so it must be the driver issue then…

[rextended]

Not to insist, but I’ve been writing this since the beginning I wrore about compatibility…

[himurae]

Not to insist, but I've been writing this since the beginning...

yes your inputs have been very valuable my friend ,you are a senior member in this forum if possible send this information to the team..

[rextended]

As already written, I’m an ordinary user (and not even a moderator as you thought),
you have to write directly to support@mikrotik.com if you want to contact the staff, this is a user forum where sometime staff appear here.
But, as already written, RouterOS uses an old kernel
and I don’t know if they can put an updated driver just for your device (and other similar) (there is a list of supported cards a few posts ago)

[anav]

Moderator hah, if only we could be so lucky!
As for ordinary, one of the last words I would have used…

[Flannels]

This may be useful to you:
http://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546/1

[himurae]

This may be useful to you:
http://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546/1

Yes!!! Finally someone has found out the real issue @Flannels wonderful work man so as per you deployment of RFC4638 test is the reason for this issue in particular

[BartoszP]

Just for the records: Mikrotik ↔ Mikrotik gives 1492 with no additional settings except identity

[himurae]

Just for the records: Mikrotik ↔ Mikrotik gives 1492 with no additional settings except identity

This is not the same since pppoe server is from Mikrotik not outside, look in this post for actual reason
http://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546/1

[fischerdouglas]

Just for the records: Mikrotik ↔ Mikrotik gives 1492 with no additional settings except identity

A suggestion to the Topic Author and other interested on it:

• Reproduce those two scenarios, MTU with 1492 and MTU Failed-Back-to-1480.
• Capturing a PCAP of the initial part of PPP negotiation on that scenario of 1492.
• Capturing the equivalent PCAP on a scenario of Failed-Back-to-1480.
• Decoding and comparing both captures.

Wireshark is the way, the truth, and the life!

If you are on a lab scenario with no sensitive information (IP address, Mac Address, PPP user and password.), you could even share those PCAPs here and other guys could help in the comparison and analysis.

[himurae]

I could provide that if could you guide me how to do a packet capture in chr in a easy way ?

[fischerdouglas]

I could provide that if could you guide me how to do a packet capture in chr in a easy way ?

Hey… This “the one” of the few things I really like in MikroTik.
It works like a charm.

Edit:

• In the interface, you should choose the one where de PPPoE-Client is running.
• I would recommend start the capture right before enabling de PPPoE-Client interface, and wait a bit more then 30-35 seconds and then stop it.
  

[himurae]

these are some packets with mtu as 1492,hope you see something..

[fischerdouglas]

Hey dude…
You need to download the PCAP file from files in your router to you computer, and then send it here.

[himurae]

Ok will send you a message

[himurae]

Reply from mikrotik

—-—-—-—
Please REPLY ABOVE THIS LINE ^ (for faster response, use our support portal).
Hello
We do not see any software errors in the supout rif file. There must be some device in the middle that causes this issue.
Thanks

Everyone who replied is giving valuable input we are so close to resolving this issue people ,i am willing to put my 100% in this to get it to work and just on the verge of purchasing CHR..
I need all the support from each and everyone of you,like i said this forum has much knowledgeable than others which i am part of!!!
So lets resolve this

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/

[CGGXANNX]

Normally the file without platform suffix, the one named routeros-7.18_ab244.npk is for x86 (same naming convention as on https://mikrotik.com/download).