PPPOE MTU ALWAYS DEFAULTS TO 1480 INSTEAD OF 1492

himurae · Sat Feb 15, 2025 4:21 pm

hello people

i have ros 17.7 x86 on a bare metal mini pc ,my issue is my isp provides mtu 1492 (i have tested on VYOS/OPNSENSE it is indeed this and it works without any issues )but on mk ros it always defaults to 1480 .
I tried changing parent interface mtu to 1508/1504 also pppoe interface max mtu to 1492/1500 but actual mtu goes to 1492 after any change for 5 secs then reverts back to 1480.
why this strange behavior

Edit I tested also on promomox CHR version results are absolutely the same after help from community i have been able to bump mtu to 1488 ,but still not 1492

mkx · Sat Feb 15, 2025 5:28 pm

Yes, MT seems to think it needs extra 12 bytes of PPPoE overhead. And since PPPoE rarely allows for full standard 1500 byte MTU, there will be fragmentation either way. With MT's lower MTU of 1480 (versus more generous 1492) there will be a tiny bit more fragmentation, but not much more (IMO only a few packets are between 1481 and 1492 bytes in length which would make a difference here).
If you implenent "MTU clamping" or PMTUD works out as intended, then you may see less than 1% of reduction of throughput. If neither "MTU clamping" nor PMTUD work, then you'll eiher see massive fragmentation (but in most cases packet will get fragmented regardless the PPPoE MTU) or you'll see massive packet loss (again the magnitude will be the same regardless the PPPoE MTU.

So I wouldn't sweat over MTU issue too much.

neelc · Sat Feb 15, 2025 9:16 pm

While this article is aimed at ISPs running PPPoE servers, it could also be useful for a PPPoE client: https://blog.apnic.net/2021/06/24/how-t ... imization/

You could try this:

/interface ethernet set [ find default-name=ether1_for_customer_delegation ] mtu=1520

Then you could increase the MRU to 1492. It seems MikroTik likes a bit more overhead versus other NOS'.

I haven't tested it though since I haven't had PPPoE for almost a year (homelab networks aside) when I moved eastwards and have exclusively used DHCP. Well, I'm moving again to a house where it's basically T-Mobile 5G+BuyVM L2TP. I'll try to get Verizon to add fiber to our townhome, but if not it's 5G until Spectrum does DOCSIS 4.0 (I get 60 Mbps uploads vs 35 on Spectrum as I already have the router, but we're awaiting some home additions).

tdw · Sun Feb 16, 2025 12:20 am

The underlying layer 3 mtu setting is irrelevent for PPPoE, only the l2mtu has to be sufficiently large (greater than PPPoE mtu +

. Not sure why the value is showing up as zero in the OP, certainly on MIkrotik hardware rather than bare-metal x86 it is typically around 1600 and setting the PPPoE client mtu and mru to 1492 just works.

rplant · Sun Feb 16, 2025 2:11 am

For me with v7 it just chose 1492 with v6 it always chose 1480.

However as @tdw mentioned, you need to set both mru and mtu to 1492.

himurae · Sun Feb 16, 2025 6:25 am

I tried setting max mtu and mru to 1492 didn't help ,maybe l2mtu is disabled for x86 WHY CANT MIKROTIK guys fix this important basic feature which every-other firewall/router platform is doing ( i checked OPNSENSE/VYOS/IPFIRE/SOPHOS) all default to 1492 mtu is it too much to ask ????????the isp wont change...

rextended · Mon Feb 17, 2025 3:35 pm

The forum supports attaching images without forcing users to see your advertising banners.

himurae · Tue Feb 18, 2025 3:16 pm

The forum supports attaching images without forcing users to see your advertising banners.

i am a newbie still learning around can you comment on my issues since you seem a expert in here.

qatar2022 · Wed Feb 19, 2025 5:26 am

I have seam issue
viewtopic.php?p=1071228#p1071228

CGGXANNX · Wed Feb 19, 2025 7:56 am

Do you have a VLAN interface underneath the pppoe-out interface? Maybe you can temporarily turn on logging for PPPoE by adding a new rule for that topic under System -> Logging:

pppoe-log.png

You should see in the log that, when initiating the PPPoE connection, your router broadcasts PADI messages, with ppp-max-payload=xxxx (1492 if you didn't set Max MTU and Max MRU, otherwise their value will be here).

The other side will send back a PADO message. Does it message also include a ppp-max-payload parameter (it would if the PPPoE server supports RFC 4638)? If yes, is the number smaller than 1492?

After that your router will send out PADR message, and get back PADS message. Then there will be several LCP messages being sent back and forth. Do they specify the mru value (such as 1492)? With the LCP messages, the two sides will also agree on the MRU value (MRU of the other side is MTU for your side). Is the agreed MRU value still 1492 or has it been lowered after the LCP exchanges?

Then authentication will be performed. Once this is done, your router will do something that I think is relevant to your issue: It will try to send a LCP echo message with a very large payload, the payload will be chosen so that the packet reaches the MTU/MRU agreed above (in this example below 1484 + 8 = 1492):

pppoe-mru-6.png

If the PPPoE server sends back a EchoRep reply with the same payload length, then the MTU/MRU value is valid and will be displayed in Actual MTU in WinBox. If, however, the underlying ethernet layer could not send a packet that big, no EchoRep will arrive. After a timeout RouterOS will reduce the MTU/MRU of the connection to 1480.

Because my ISP supports RFC 4638, I can replicated this issue by making a PPPoE connection with Max MTU and Max MRU set to something that will later cause the EchoReq message to be larger than my L2MTU. My L2MTU is 1510 and I'll try to create a PPPoE connection with Max MTU = Max MRU = 1506:

pppoe-mru-9.png

Red arrow is my router setting ppp-max-payload in PADI and blue arrow is my ISP saying that that's ok because it supports RFC 4638. Next is the agreement on MRU and PAP as authentication method:

pppoe-mru-10.png

Authentication succeeded, and here you can see my router sending out the EchoReq message to test whether a packet with size 1506 could really be sent (1498 + 8 = 1506).

pppoe-mru-11.png

This packet will require the ethernet layer to be able to send 1514 bytes payload (1506 + 8 = 1514), but my L2MTU is only 1510:

pppoe-mru-12.png

So it could not be sent, and no reply will be received. After a few more tries RouterOS will drop the Actual MTU to 1480!

pppoe-mru-13.png

I suspect this is what happened with your configuration, it also explains the 5-second delay before the MTU drop (it's the wait for the EchoReq tries). And I have seen others observing the same problem, and one thing they have in common with you is that they were also running RouterOS on x86.

I suspect that your network adapter has a low upper limit for the max possible MTU (what MikroTik normally shows with L2MTU). Maybe the adapter supports ethernet frame just large enough for the usual ethernet header and trailer for a 1500-byte IP packet. That's why I asked above if you have VLAN set up. Normally with VLAN the ethernet frame must be able to grow by 4 more bytes, if you still want to be able to send an IP packet of 1500 bytes. MikroTik hardwares all have L2MTU > 1500 + 4 so you can always enable VLAN and have no problem with MTU 1500. But that's not necessarily true of the network adapter in your x86 build. Does the adapter have a setting toggle for VLAN support?

himurae · Sun Feb 23, 2025 9:42 am

Do you have a VLAN interface underneath the pppoe-out interface? Maybe you can temporarily turn on logging for PPPoE by adding a new rule for that topic under System -> Logging:

pppoe-log.png

You should see in the log that, when initiating the PPPoE connection, your router broadcasts PADI messages, with ppp-max-payload=xxxx (1492 if you didn't set Max MTU and Max MRU, otherwise their value will be here).

The other side will send back a PADO message. Does it message also include a ppp-max-payload parameter (it would if the PPPoE server supports RFC 4638)? If yes, is the number smaller than 1492?

After that your router will send out PADR message, and get back PADS message. Then there will be several LCP messages being sent back and forth. Do they specify the mru value (such as 1492)? With the LCP messages, the two sides will also agree on the MRU value (MRU of the other side is MTU for your side). Is the agreed MRU value still 1492 or has it been lowered after the LCP exchanges?

Then authentication will be performed. Once this is done, your router will do something that I think is relevant to your issue: It will try to send a LCP echo message with a very large payload, the payload will be chosen so that the packet reaches the MTU/MRU agreed above (in this example below 1484 + 8 = 1492):

pppoe-mru-6.png

If the PPPoE server sends back a EchoRep reply with the same payload length, then the MTU/MRU value is valid and will be displayed in Actual MTU in WinBox. If, however, the underlying ethernet layer could not send a packet that big, no EchoRep will arrive. After a timeout RouterOS will reduce the MTU/MRU of the connection to 1480.

Because my ISP supports RFC 4638, I can replicated this issue by making a PPPoE connection with Max MTU and Max MRU set to something that will later cause the EchoReq message to be larger than my L2MTU. My L2MTU is 1510 and I'll try to create a PPPoE connection with Max MTU = Max MRU = 1506:

pppoe-mru-9.png

Red arrow is my router setting ppp-max-payload in PADI and blue arrow is my ISP saying that that's ok because it supports RFC 4638. Next is the agreement on MRU and PAP as authentication method:

pppoe-mru-10.png

Authentication succeeded, and here you can see my router sending out the EchoReq message to test whether a packet with size 1506 could really be sent (1498 + 8 = 1506).

pppoe-mru-11.png

This packet will require the ethernet layer to be able to send 1514 bytes payload (1506 + 8 = 1514), but my L2MTU is only 1510:

pppoe-mru-12.png

So it could not be sent, and no reply will be received. After a few more tries RouterOS will drop the Actual MTU to 1480!

pppoe-mru-13.png

I suspect this is what happened with your configuration, it also explains the 5-second delay before the MTU drop (it's the wait for the EchoReq tries). And I have seen others observing the same problem, and one thing they have in common with you is that they were also running RouterOS on x86.

I suspect that your network adapter has a low upper limit for the max possible MTU (what MikroTik normally shows with L2MTU). Maybe the adapter supports ethernet frame just large enough for the usual ethernet header and trailer for a 1500-byte IP packet. That's why I asked above if you have VLAN set up. Normally with VLAN the ethernet frame must be able to grow by 4 more bytes, if you still want to be able to send an IP packet of 1500 bytes. MikroTik hardwares all have L2MTU > 1500 + 4 so you can always enable VLAN and have no problem with MTU 1500. But that's not necessarily true of the network adapter in your x86 build. Does the adapter have a setting toggle for VLAN support?

Thanks for this detailed reply

This same box has run Vyos/opnsense/ipfire/pfsense all with pppoe mtu of 1492 nic are intel

please check my logs no matter what i change it defaults to 1480 mtu

CGGXANNX · Sun Feb 23, 2025 6:52 pm

Can you look further down in the log, after the authentication has been performed? There should be a relevant section where your router sent LCP EchoReq messages with <data len=xxxx>. Are there any rcvd LCP EchoRep lines after that?

Looking at your screenshots it looks like the server side does support RFC 4638 and it let your router know that ppp-max-payload can be 1500 bytes. According to the provided log, it looks like your router and the PPPoE server has negotiated a (for your side) MRU of 1500 and MTU of 1492 (which means for the server side, the negotiated MRU is 1492 and MTU is 1500). Your router will send packet with payload up to 1492 bytes, and the server will send packet with payload up to 1500 bytes. Probably this later part will fail, but we don't see that part of the log from your screenshots.

When you wrote that you did set the MTU to 1492, did you set both values of Max MRU and Max MTU in the PPPoE connection property dialog to 1492? or only the Max MTU part? According to the log, your router still says that it can accept MRU up to 1500, which means you probably didn't set Max MRU = 1492. Can you try setting both parameters Max MRU = 1492 and Max MTU = 1492?

himurae · Mon Feb 24, 2025 7:33 pm

Hope you can see the bug....

CGGXANNX · Tue Feb 25, 2025 9:53 am

Yes, from the screenshots of the log, it looks like it happened like I described above. In the new log screenshots both ends of the tunnel now has agreed on MRU = 1492, after successful authentication your router send a test packet with 1484 bytes payload. Together with the LCP header and the Magic number (total 8 bytes) it forms a 1492 bytes PPP payload packet (equals MTU and MRU). But either this packet cannot be sent to the other side, or the reply message (LCP EchoRep, which will be of the same size) does not arrive from the other side, hence the "missed echo reply" log message. RouterOS then drops Actual MTU to 1480 as the result.

Can you try to gradually reduce Max MTU and Max MRU 2 bytes at a time (1490,1488, 1486, etc...) to see at which size the LCP EchoReq packet can be successfully sent, and LCP EchoRep successfully received?

himurae · Tue Feb 25, 2025 9:57 am

Yes, from the screenshots of the log, it looks like it happened like I described above. In the new log screenshots both ends of the tunnel now has agreed on MRU = 1492, after successful authentication your router send a test packet with 1484 bytes payload. Together with the LCP header and the Magic number (total 8 bytes) it forms a 1492 bytes PPP payload packet (equals MTU and MRU). But either this packet cannot be sent to the other side, or the reply message (LCP EchoRep, which will be of the same size) does not arrive from the other side, hence the "missed echo reply" log message. RouterOS then drops Actual MTU to 1480 as the result.

Can you try to gradually reduce Max MTU and Max MRU 2 bytes at a time (1490,1488, 1486, etc...) to see at which size the LCP EchoReq packet can be successfully sent, and LCP EchoRep successfully received?

i will report back this evening thanks for your inputs hope mikrotik guys are reading this and making some changes to their PPPOE stack.

himurae · Tue Feb 25, 2025 7:04 pm

Yes, from the screenshots of the log, it looks like it happened like I described above. In the new log screenshots both ends of the tunnel now has agreed on MRU = 1492, after successful authentication your router send a test packet with 1484 bytes payload. Together with the LCP header and the Magic number (total 8 bytes) it forms a 1492 bytes PPP payload packet (equals MTU and MRU). But either this packet cannot be sent to the other side, or the reply message (LCP EchoRep, which will be of the same size) does not arrive from the other side, hence the "missed echo reply" log message. RouterOS then drops Actual MTU to 1480 as the result.

Can you try to gradually reduce Max MTU and Max MRU 2 bytes at a time (1490,1488, 1486, etc...) to see at which size the LCP EchoReq packet can be successfully sent, and LCP EchoRep successfully received?

Brilliant analysis!!!!!!!!!! as you told mtu/mru 1488 is accepted finally and now i have 1488 as actual mtu ,Wish we could make it 1492 any chance i already see perceived improved latency in my system now...Thanks

rplant · Wed Feb 26, 2025 3:50 am

It sort of looks like there are 4 bytes required.

Perhaps the pppoe comes on a vlan (quite common)
Or perhaps they are adding a priority vlan header.

Can you manually set the l2mtu of the interface to something higher than 0
eg. 1504

Perhaps via webfig/winbox/cli if you can't do it from the mobile.

himurae · Wed Feb 26, 2025 8:11 am

It sort of looks like there are 4 bytes required.

Perhaps the pppoe comes on a vlan (quite common)
Or perhaps they are adding a priority vlan header.

Can you manually set the l2mtu of the interface to something higher than 0
eg. 1504

Perhaps via webfig/winbox/cli if you can't do it from the mobile.

There are no options through winbox to change L2mtu of pppoe parent interface perhaps through cli can you tell me the command to do so??

CGGXANNX · Wed Feb 26, 2025 9:14 am

You can only change L2MTU on MikroTik made devices. You have a x86 system with network adapters not in control of MikroTik so that is not possible. Do you run RouterOS directly on the mini PC or do you have a hypervisor in between?

himurae · Wed Feb 26, 2025 9:24 am

You can only change L2MTU on MikroTik made devices. You have a x86 system with network adapters not in control of MikroTik so that is not possible. Do you run RouterOS directly on the mini PC or do you have a hypervisor in between?

Yes presently i am running on proxmoxx hypervisor on x86 boxes with intel nic and i have in past run direct on this box also result is same no difference

CGGXANNX · Wed Feb 26, 2025 10:49 am

If you use Proxmox, can you try in Proxmox to increase the MTU value of:

* The network device (ensXXXX) corresponding to the port connecting to the ISP
* The corresponding Linux bridge over that port

to, let's say 1540 (assuming the network adapter support jumbo frames)? Or are you using NIC passthrough (if this is the case try switching to virtio)?

himurae · Wed Feb 26, 2025 10:52 am

If you use Proxmox, can you try in Proxmox to increase the MTU value of:

* The network device (ensXXXX) corresponding to the port connecting to the ISP
* The corresponding Linux bridge over that port

to, let's say 1540 (assuming the network adapter support jumbo frames)? Or are you using NIC passthrough (if this is the case try switching to virtio)?

interesting will report back soon with findings!!!!

himurae · Wed Feb 26, 2025 8:24 pm

I changed mtu to 1540 in 3 places parent interface ,bridge port and also in mikrotik network interface,but nothing changed for me pppoe mtu is still 1488 ,also it breaks internet everytime i change parent interface mtu (son has his board exams going on ) so i will try again tomorrow when he is off to school,but didnt see much difference.
But i am not losing hope will try ,my main question is when other software vendors can achieve why cant mikrotik ,so definitely they are locking down something...

yuripg1 · Wed Feb 26, 2025 8:53 pm

This is kind of a shot in the dark, but the default PPP profile has MPLS enabled (it actually says "default", which explains nothing, but in reality this "default" acts like "enabled"). Try to either create a new PPP profile with MPLS disabled or disable MPLS on the default PPP profile.

This is nothing more than wild speculation from my part (and I'm not proud), but it could be that that's where those 4 extra bytes come from.

himurae · Thu Feb 27, 2025 6:06 am

I changed in both profiles made no difference

himurae · Thu Feb 27, 2025 6:20 am

If you use Proxmox, can you try in Proxmox to increase the MTU value of:

* The network device (ensXXXX) corresponding to the port connecting to the ISP
* The corresponding Linux bridge over that port

to, let's say 1540 (assuming the network adapter support jumbo frames)? Or are you using NIC passthrough (if this is the case try switching to virtio)?
interesting will report back soon with findings!!!!

i tried again this morning with 1540 mtu on wan interfaces across the board also in mk pppoe tried to play with mtu but only 1488 works any other value it defaults to 1480 .........

CGGXANNX · Thu Feb 27, 2025 9:03 am

I guess another thing that you can try is to turn on the VLAN Aware checkbox in Proxmox on the Linux Bridge matching the interface used to dial PPPoE? It probably won't help much though.

Another attempt that requires more work is to passthrough the network adapter (NIC Passthrough) instead of using the virtual adapter. But it probably won't help because like you wrote you've already installed RouterOS on the bare metal hardware before.

himurae · Thu Feb 27, 2025 7:46 pm

i made the interface vlan aware but no changes in mtu still a mystery hope some one tags mk team to solve this issue

himurae · Fri Feb 28, 2025 6:16 am

just ran vyos instance and immediately pppoe mtu is 1492 without any effort!!!!
Hope one day its same with @mikrotik......

anav · Sat Mar 01, 2025 7:28 pm

@CGG great analysis, you are indeed knowledgeable in networking on many fronts!!

The interesting thing is that you seem to indicate that the problem is that the OP is to cheap to buy MT products and is using an X86 machine to hose RoS.

In other words the RoS is is working fine and the limitation is caused by the hardware.
The OP is pointing out that the issue does not exist when the OP uses a different RoS, namely VYOS.

So which is it
a. MT RoS cannot handle the MTU properly and needs fixing.
b. VYOS somehow reads the NiC card parameters and adjusts on the fly ( again MT RoS is deficient in comparison and needs work )
c. ???????????

rextended · Sun Mar 02, 2025 2:33 am

Stop resurrecting old topics and merging them all here.

You've had your moment of attention.

Write to support@mikrotik.com or buy a MiroTik device if you want to use RouterOS in full.

anav · Sun Mar 02, 2025 2:36 am

Hey R.............. get some sleep its got to be like 1:35 am LOL

rextended · Sun Mar 02, 2025 2:49 am

I had to reply to a user in another topic and I found yet another post resurrected to draw attention to his problem with 1492 / 1480 MTU.
But the user still doesn't understand the difference between L2 and L3 MTU,
and RouterOS doesn't support all the functions on non-RouterBOARD hardware or that doesn't have fully compatible drivers inside RouterOS...

anav · Sun Mar 02, 2025 3:12 am

Understood, but the grapes will grow in the dark you dont have to watch them. zzzzzzzzzzzzzzzzzzzz

Tathastu · Sun Mar 02, 2025 11:57 am

Strange logic !!
Cloud Hosted Router (CHR) is a RouterOS version intended for running as a virtual machine. It supports the x86 64-bit architecture so it must support intel nics ,i think its a bug that needs to be fixed.

Sun Mar 02, 2025 12:19 pm

That is really strange logic!!!
Are you suggesting that emulator HAS to be Intel based? Are you aware of x64 emulators on ARM processors or ARM emulators on Intel platforms?
Or maybe you suggest that CHR should have support for any Intel based product?
Dont you think that CHR should have support just for that devices that are exposed by virtualization system?

Tathastu · Sun Mar 02, 2025 7:02 pm

yes i meant chr must at least support intel nics since they are so widely used .

wrkq · Sun Mar 02, 2025 7:32 pm

What they're trying to explain to you, is that CHR is a virtual machine.
It doesn't see the Intel, Broadcom, Mellanox, or whatever NICs you have. It sees the virtual-simulated basic NIC provided by the virtualization platform.
It (for now) does not support passthrough-real-hardware-to-VM setups. (Its main target market is cloud hosting which doesn't offer such features anyway.)
Any tuning of the hardware NICs must happen on the hypervisor.

rextended · Sun Mar 02, 2025 11:54 pm

Finally wise words.

Tathastu · Mon Mar 03, 2025 5:51 am

hello people

i have ros 17.7 x86 on a bare metal mini pc ,my issue is my isp provides mtu 1492 (i have tested on VYOS/OPNSENSE it is indeed this and it works without any issues )but on mk ros it always defaults to 1480 .
I tried changing parent interface mtu to 1508/1504 also pppoe interface max mtu to 1492/1500 but actual mtu goes to 1492 after any change for 5 secs then reverts back to 1480.
why this strange behavior

Edit after help from community i have been able to bump mtu to 1488 ,but still not 1492

Thanks for the simple explanation, i get it ,but you see the OP has initially setup x86 version and even then he faced this issue ,care to explain ????

himurae · Mon Mar 03, 2025 9:33 am

Yes i started with Ros on x86 box directly ,then i tried with chr on proxmoxx,but result is absolutely the same the mtu never goes to 1492..

anav · Mon Mar 03, 2025 1:44 pm

Hence why I asked (x86 example), why it works on VYOS and not on RoS. Just curious.
a. either the MT follows the standard and is correct
b. or the VYOS follows the standard and is correct
c. or the VYOS does some bastardized implementation that allows it to work.

WHich is plausible??

himurae · Mon Mar 03, 2025 2:25 pm

Hence why I asked (x86 example), why it works on VYOS and not on RoS. Just curious.
a. either the MT follows the standard and is correct
b. or the VYOS follows the standard and is correct
c. or the VYOS does some bastardized implementation that allows it to work.

WHich is plausible??

Not just VYOS I checked with openwrt/opnsense/ipfire

It's something to do with ROS !!!!!!!! Or maybe I am plain stupid...

rextended · Mon Mar 03, 2025 2:40 pm

You've already had an answer, how long does it take you to figure it out?

I had to reply to a user in another topic and I found yet another post resurrected to draw attention to his problem with 1492 / 1480 MTU.
But the user still doesn't understand the difference between L2 and L3 MTU,
and RouterOS doesn't support all the functions on non-RouterBOARD hardware or that doesn't have fully compatible drivers inside RouterOS...

anav · Mon Mar 03, 2025 2:41 pm

Hence why I asked (x86 example), why it works on VYOS and not on RoS. Just curious.
a. either the MT follows the standard and is correct
b. or the VYOS follows the standard and is correct
c. or the VYOS does some bastardized implementation that allows it to work.

WHich is plausible??
Not just VYOS I checked with openwrt/opnsense/ipfire

It's something to do with ROS !!!!!!!! Or maybe I am plain stupid...

Everyone else seems annoyed but it seems to me you have a point. No one has presented any logic on the x86 issue, stating why vyos works and RoS does not.
I have no skin in the game and I really dont care how expert people are, if they cannot provide a reasonable explanation, their shit stinks like everyone elses.

Sorry rextended, you have not explained why RoS fails, and VYOS succedes on an x86 machine.
Are you saying VYOS and also openwrt and opnsense etc. includes drivers or something that ROS does not? etc. Just looking for a reasonable explanation.
Would seem if they do, perhaps its no much of a stretch for RoS to include same, or do they use some magical operating system.?????

rextended · Mon Mar 03, 2025 2:43 pm

@anav, is the same:

and RouterOS doesn't support all the functions on non-RouterBOARD hardware or that doesn't have fully compatible drivers inside RouterOS...

Unzip the .npk and you have the list of what kext are inside the RouterOS...

Usually you have to prove the existence of something you claim exists,
not prove that not exist something you claim doesn't exist (and that no one has ever been able to incontrovertibly demonstrate that it exists)...

@anav, in this case, your logic is flawed.

anav · Mon Mar 03, 2025 2:48 pm

Rextended I am not purporting to be any sort of an expert in this area, or any area for that matter, couldnt tell the difference between popcorn ( which is yummy ) and kext ???

So the explanation then is that three or four other Operating Systems, based on a completely different architecture, (not linux or whatever based but some magical potion based ) can handle x86 devices because they include some set of drivers that are oh so unique and special and probably very very very expensive????

In this case your logic is not sound either.
The OP has demonstrated that he can use x86, without MTU issues when using three or four other operating systems without special shananigans.
The issue is to resolve why is this the case?

It would seem there is something lacking in RoS.
Can these drivers be added?

rextended · Mon Mar 03, 2025 2:51 pm

A trivial example (direct on bare metal x86, not CHR), VyOS supports the Intel i211AT chip because it has dedicated and specific drivers inside.
RouterOS does not have specific drivers, but generic ones, which do not allow you to make popcorn(...) with the network card.

rextended · Mon Mar 03, 2025 2:57 pm

It would seem there is something lacking in RoS.

And what have I written so far?
There are no drivers.

Can these drivers be added?

Last VyOS release is ~600MB,
last x86_64 / CHR RouterOS release is ~20MB?
(i do not remember correct size but are closed to what I wrote)
so RouterOS has ~580MB of "stuff" inside, probably even less drivers.

EDIT: check size
6.6.79-vyos has ~100M of driver,
5.6.3-64 RouterOS... ~6M!....

However, the user does not seem to have directly installed RouterOS on the physical machine, but is using a virtualiser with multiple systems inside.
So, whatever happens, RouterOS runs on virtualised hardware, of which even that, without specific drivers,
cannot exploit all the potential as if it had access to a real ethernet card.

Remember that VyOS is open-source, so anyone can contribute with, RouterOS is a closed-source.

rextended · Mon Mar 03, 2025 3:20 pm

NIC drivers on RouterOS 7.18.1 for CHR / x86_64 5.6.3 kernel (2020)
Intel(R) PRO/100 Network Driver e100 (2016)
Intel(R) PRO/1000 Network Driver e1000 7.3.21
Intel(R) PRO/1000 Network Driver e1000e 3.2.6
Intel(R) Gigabit Virtual Function Network Driver igbvf 2.4.0

NIC drivers on VyOS 6.6.79 kernel (2025)
Intel(R) PRO/100 Network Driver e100 6.6.79
Intel(R) PRO/1000 Network Driver e1000 6.6.79
Intel(R) PRO/1000 Network Driver e1000e 6.6.79
Intel(R) Gigabit Virtual Function Network Driver igbvf [I350 82576] 6.6.79
and
Intel(R) 10GbE PCI Express Linux Network Driver ixgbe 6.0.6
Intel(R) 10GbE PCI Express Virtual Function Driver 5.0.2
Intel(R) Ethernet Connection XL710 Network Driver i40e 6.6.79
Intel(R) Ethernet Adaptive Virtual Function Network Driver iavf 6.6.79
Intel(R) Ethernet Connection E800 Series Linux Driver ice 6.6.79
Intel(R) Gigabit Ethernet Network Driver igb 6.6.79
Intel(R) 2.5G Ethernet Linux Driver igc 6.6.79

And here I only compared Intel hardware/virtual, not counting all the others.

Obviously RouterOS still to 5.6.3 kernel (2020) can not use directly new drivers...

himurae · Mon Mar 03, 2025 3:53 pm

NIC drivers on RouterOS 7.18.1 for CHR / x86_64 5.6.3 kernel (2020)ù
2006: Intel(R) PRO/100 Network Driver e100
2020: Intel(R) PRO/1000 Network Driver e1000 7.3.21
2015: Intel(R) PRO/1000 Network Driver e1000e 3.2.6
2016: Intel(R) Gigabit Virtual Function Network Driver 2.4.0

NIC drivers on VyOS 6.6.79 kernel (2025)
2006: Intel(R) PRO/100 Network Driver e100 6.6.79
2006: Intel(R) PRO/1000 Network Driver e1000 6.6.79
2015: Intel(R) PRO/1000 Network Driver e1000e 6.6.79
2025: Intel(R) 10GbE PCI Express Linux Network Driver ixgbe 6.0.6
2025: Intel(R) 10GbE PCI Express Virtual Function Driver 5.0.2
2019: Intel(R) Ethernet Connection XL710 Network Driver i40e 6.6.79
2018: Intel(R) Ethernet Adaptive Virtual Function Network Driver iavf 6.6.79
2018: Intel(R) Ethernet Connection E800 Series Linux Driver ice 6.6.79

And here I only compared Intel hardware/virtual, not counting all the others.

Obviously RouterOS still to 5.6.3 kernel (2020) can not use directly new drivers...

Thanks for BANNING me for 24 hours I learnt my lesson !!!!!!!
Let me clear misunderstanding I had installed direct x86 on device ,mtu never saw 1492 then I thought chr is better so I installed proxmox and same result i can again do it for you in the meantime

—-—-—
Please REPLY ABOVE THIS LINE ^ (for faster response, use our support portal).
Hello,

Thank you for contacting MikroTik Support.

Seems like some HW limitation, try using hypervisor and install CHR, this will allow to deal with hw incompatibilities if such arise. We do not create drivers for hw, they are based on Linux kernel.

Best regards,

Oskars K.

So official support is telling otherwise CHR is better than x86

@anav thnks for standing up for new comers like me in this wild world because others get intimidated and stop asking questions in fear of getting insulted by seniors....

rextended · Mon Mar 03, 2025 3:55 pm

I'm not a moderator, so I didn't ban anything, it was your behavior (not in this thread/topic)

anav · Mon Mar 03, 2025 3:59 pm

@rextended --> Thank you very much for your patience and explanation.
That makes much sense. I honestly thought that the RoS kernel was recently updated to the latest.
Clearly, it would be nice if their kernel was kept up to date, but I assume that stability is of greater importance, so its a balance.
Understand that there are storage and kernel issues with hosting all drivers and that at some point decisions have to be made.

In conclusion, business decisions made, make it untenable to solve every possible usage of RoS and in this case, there are some functionalities that may not solve x86 hardware issues.
As noted, the easy answer is to buy MT hardware, or as discovered use alternative OS for your needs.
Any expectation of RoS applying the same solutions is currently not viable due to the size of RoS and to the state of the kernel.
Even if the kernel is updated, storage is still a limiting factor.

These are all trade-offs and economics, and thus for the OP can only recommend that you send a suggestion to mikrotik through their support portal, for the inclusion of drivers for X86 pointing to the MTU issue. I agree there is no point in dissing your valid issues and concerns, and having a rational discussion is more fruitful. It would seem that MT is not quite the right OS fit for your x86 needs.

himurae · Mon Mar 03, 2025 4:03 pm

But I will never stop helping others and will post the correct solution when I find it out in a simple way that others can benefit, the only reason I was in hyper drive was I wanted mk to know about this flaw and fix it since whole middleeast countries including India runs on pppoe protocol and many users like me will face this issue ,my isp in dubai has world class infrastructure so their settings won't be ancient ..

anav · Mon Mar 03, 2025 4:06 pm

To be clear, its not a flaw. Its simply missing drivers nothing more nothing less.

himurae · Mon Mar 03, 2025 4:08 pm

My humble mind is asking me why publish a image x86 if it doesn't support x86 anyways will see their answer

anav · Mon Mar 03, 2025 4:12 pm

My humble mind is asking me why publish a image x86 if it doesn't support x86 anyways will see their answer

I have little IT knowledge of such things, as I admitted earlier, but many have used x86 and not reported such difficulties, so I can only assume that it works fine for some users.
Other than that, if this is something that negatively affects every x86 user, then I would agree and x86 option should be removed.

rextended · Mon Mar 03, 2025 4:21 pm

(
I forgot, the driver for Intel i211AT is only present on VyOS
==> Intel(R) Gigabit Ethernet Network Driver igb 6.6.79
that on RouterOS is not present but e000e driver can use only basic functions due that do not support completely 82575-, 82576-, 82580-, I350-, I210-, I211- based NIC.
)

rextended · Mon Mar 03, 2025 4:23 pm

I can only assume that it works fine for some users.

There are already some complaints on the forum about the same thing on x86 systems because you can't change the MTU from 1500 to more.

Larsa · Mon Mar 03, 2025 5:37 pm

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.

anav · Mon Mar 03, 2025 5:58 pm

Larsa, the only question I can think of,,,,,,,, if I rent a VPS in the cloud from one of the two or three popular vendors for about $8 a month, and buy a CHR license, would I have to worry about this?
I mean the only thing I would normally do, for example, is on client MT router ( typically for wireguard usage (CHR being server for handshake)) is make the mangle clamping rule................

rextended · Mon Mar 03, 2025 6:11 pm

Since all the internet, or at least 90% (ahem...

) transmits with MTU at 1500,
you will never have problems with MTU at 1480/1492 in PPPoE because in this regard I think that nobody connects via PPPoE to a host hosted on a cloud...

The PPPoE MTU is more related to those who play at home with RouterOS,
or some company that to save money buys toys instead of a serious RouterBOARD (and if the ISP knows how to do its job and provides an MTU of 1500...).

Larsa · Mon Mar 03, 2025 6:38 pm

@anav; afaik, all VPS providers allow you to configure lower NIC MTUs. But why would you need a lower NIC MTU in a cloud environment?

anav · Mon Mar 03, 2025 6:46 pm

Heck no, I wont touch anything LOL, I wouldnt know what I was doing!!

Larsa · Mon Mar 03, 2025 9:03 pm

Reply from Mikrotik support: "Seems like some HW limitation, try using hypervisor and install CHR, this will allow to deal with hw incompatibilities if such arise. We do not create drivers for hw, they are based on Linux kernel."

@himurae; that reply from Mikrotik support is not entirely correct.

Both ROS x86_64 and ROS CHR does require drivers for various platform NICs, including CHR hardware drivers for NICs to support SR-IOV. Although, which ones are included in each ROS version remains a big mystery due to the lack of adequate documentation (which, ironically, is a mystery too!

). In other words, which Linux kernel NIC drivers Mikrotik chooses to opt in when compiling RouterOS is unknown.

Check out my previous reply on how to change MTU in different virtual environments.

anav · Mon Mar 03, 2025 10:30 pm

Amazing, for a complete boob my logic was not far off from truth. In any case, avoid x86 is my advice. It might be cool, but seems impractical.

Larsa · Mon Mar 03, 2025 10:44 pm

Yeah, for a router like CHR, there aren't really any obvious advantages to running it x86 "bare metal." On the contrary, it's way easier to manage a virtual instance with CHR, which is also easy to move "live" between different environments if you need to perform maintenance on a host. And if you use SR-IOV, you basically get the same performance and control.

rextended · Tue Mar 04, 2025 1:57 am

which ones are included in each ROS version remains a big mystery
which Linux kernel NIC drivers Mikrotik chooses to opt in when compiling RouterOS is unknown.

viewtopic.php?t=214801#p1130469

himurae · Tue Mar 04, 2025 5:26 am

Reply from Mikrotik support: "Seems like some HW limitation, try using hypervisor and install CHR, this will allow to deal with hw incompatibilities if such arise. We do not create drivers for hw, they are based on Linux kernel."

@himurae; that reply from Mikrotik support is not entirely correct.

Both ROS x86_64 and ROS CHR does require drivers for various platform NICs, including CHR hardware drivers for NICs to support SR-IOV. Although, which ones are included in each ROS version remains a big mystery due to the lack of adequate documentation (which, ironically, is a mystery too! ). In other words, which Linux kernel NIC drivers Mikrotik chooses to opt in when compiling RouterOS is unknown.

Check out my previous reply on how to change MTU in different virtual environments.

Thanks

for replying larsa you seem like someone down to earth and who has experience with Virtual machines i heard those terms you mentioned for the first time will search online how to implement them .

himurae · Tue Mar 04, 2025 5:35 am

Since all the internet, or at least 90% (ahem... ) transmits with MTU at 1500,
you will never have problems with MTU at 1480/1492 in PPPoE because in this regard I think that nobody connects via PPPoE to a host hosted on a cloud...

The PPPoE MTU is more related to those who play at home with RouterOS,
or some company that to save money buys toys instead of a serious RouterBOARD (and if the ISP knows how to do its job and provides an MTU of 1500...).

Please read post earlier I am reattaching quotes from experienced member@CGGXANNX

"" Looking at your screenshots it looks like the server side does support RFC 4638 and it let your router know that ppp-max-payload can be 1500 bytes. According to the provided log, it looks like your router and the PPPoE server has negotiated a (for your side) MRU of 1500 and MTU of 1492 (which means for the server side, the negotiated MRU is 1492 and MTU is 1500). Your router will send packet with payload up to 1492 bytes, and the server will send packet with payload up to 1500 bytes. "

So stop saying my isp is not doing good job IT SUPPORTS MTU OF 1500 and uses RFC4638....

Also the x86 boxes are not very cheap in fact many RouterBOARDs are cheaper and imo x86 have more powerful cpu than routerboards i have cpu i5 13th generation/N5105/j4125 cpu ,they are workhorses..

https://amzn.eu/d/d29xjAH

rextended · Tue Mar 04, 2025 9:36 am

The PPPoE MTU is more related to those who play at home with RouterOS,
or some company that to save money buys toys instead of a serious RouterBOARD (and if the ISP knows how to do its job and provides an MTU of 1500...).
Please read post earlier [...]

So stop saying my isp is not doing good job IT SUPPORTS MTU OF 1500 and uses RFC4638....

I never say so, what i say is already readable.

But if you really want me to comment on this, if he supports it, why does VyOS only go to 1492 instead of 1500???

Please read post earlier : buy a MikroTik hardware or compatible device.

CGGXANNX · Tue Mar 04, 2025 10:07 am

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).

elbob2002 · Tue Mar 04, 2025 10:15 am

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

CGGXANNX · Tue Mar 04, 2025 10:27 am

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

You don't need to change/increase the MTU setting of the ethernet and VLAN interface underneath the PPPoE client interface. You only need to set Max MRU and Max MTU to 1500, and make sure that L2MTU, if available, is at least 1508 (the value is 1510 in my screenshot below). However, it's recommended to create a separate PPP profile with Change TCP MSS = no in that case, and use that profile for the PPPoE client. Otherwise RouterOS will wrongly reduce the MSS value of the TCP connections.

himurae · Tue Mar 04, 2025 11:34 am

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 Yes you are right i have never specified mtu on any of my interface but i do use "set interfaces pppoe pppoe0 ip adjust-mss ‘clamp-mss-to-pmtu’ i will this evening set mtu on pppoe/parent interface (eth0 in my case ) to 1500 and eth1 lan interface to 1508 will report my findings !!!!!!!!!!!!!!!!!!!!!!! Thanks again for your valuable insight even the Vyos guys never mention it.!!!!

himurae · Tue Mar 04, 2025 11:41 am

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

rextended · Tue Mar 04, 2025 11:52 am

I see there is still confusion between MTU and L2MTU......

But the user still doesn't understand the difference between L2 and L3 MTU,

As already written in other posts, the MTU must be 1500 everywhere, when is not needed to be changed.
PPPoE MTU and MRU 1500 (no MRRU).

The VLAN is not an L3 protocol, so the 1508 PPPoE packet (ethernet 1500 + 8) with 4 others of the VLAN reaches 1512,
and it is the L2MTU of the ethernet that must support at least 1512, while the MTU of the ethernet remains at 1500.

rextended · Tue Mar 04, 2025 11:57 am

I need all the support from each and everyone of you

As already written, either you buy a RouterBOARD or you use bare metal hardware compatible with RouterOS x32_64,
or a virtualiser (as the other user suggested, ESXi) compatible with hardware to which the virtualiser can provide direct access,
but always must be compatible with the CHR.

hasmidzul · Tue Mar 04, 2025 11:58 am

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.

himurae · Tue Mar 04, 2025 12:01 pm

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.

Thats what i was telling many people have this issue but they have just accepted and moving on ,but we must all keep trying till we suceed now strange thing is you are using a supported device still you have issues...

Go through this entire post you will find some gems which might help you to resolve your issue ,please check your pppoe logs and see a pattern there.

rextended · Tue Mar 04, 2025 12:12 pm

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 · Tue Mar 04, 2025 6:04 pm

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

himurae · Tue Mar 04, 2025 6:43 pm

mtu 1500.png

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 · Sat Mar 08, 2025 7:30 am

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 · Sat Mar 08, 2025 10:26 am

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

himurae · Sat Mar 08, 2025 10:28 am

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 · Sat Mar 08, 2025 10:32 am

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 · Sat Mar 08, 2025 5:50 pm

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

Flannels · Mon Mar 10, 2025 7:53 am

This may be useful to you:
viewtopic.php?t=215423

himurae · Mon Mar 10, 2025 8:21 am

This may be useful to you:
viewtopic.php?t=215423

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

Mon Mar 10, 2025 8:29 am

Just for the records: Mikrotik <-> Mikrotik gives 1492 with no additional settings except identity

himurae · Thu Mar 13, 2025 1:41 pm

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
viewtopic.php?t=215423

fischerdouglas · Thu Mar 13, 2025 7:23 pm

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 · Fri Mar 14, 2025 3:51 pm

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

fischerdouglas · Fri Mar 14, 2025 8:47 pm

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.

MikroTik_PacketSniffer.png

himurae · Sat Mar 15, 2025 6:08 am

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

fischerdouglas · Sat Mar 15, 2025 9:51 pm

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

himurae · Sun Mar 16, 2025 6:29 am

Ok will send you a message

himurae · Mon Mar 17, 2025 5:56 pm

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 · Mon Mar 17, 2025 6:18 pm

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).

himurae · Mon Mar 17, 2025 8:26 pm

didnt help its still exactly the same as before

himurae · Wed Mar 19, 2025 10:10 am

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

hasmidzul · Wed Mar 19, 2025 11:26 am

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 · Wed Mar 19, 2025 12:05 pm

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 · Thu Apr 03, 2025 1:32 pm

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
Code: Select all
/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 · Tue Apr 22, 2025 6:18 pm

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 · Wed Apr 23, 2025 12:18 pm

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 · Wed Apr 23, 2025 12:21 pm

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!