didnt help its still exactly the same as before
Update !!! mikrotik is working on a implementation to disable RFC4638 test they emailed me the same..
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
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
Hi, does anyone know if MikroTik has released a definitive fix for this issue?
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! 
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!!!
Thank you very very much for your perseverance and persistence even when others tried to shut you down.
I shared your frustration, where things would work normally on other routers, but not the Mikrotik
This problem, I can confirm, existed with ALL my Mikrotik routers.
This problem, I can confirm, has been fixed on at least 2 of them, that I have tested, with this release.
It is also, not just a cosmetic fix, I can ping websites with the appropriate packet size proving MTU is finally 1492.
Yes this issue was on all mikrotik devices(since i bought a rb5009 also) and x86 i know only those affected understand the importance but i must thank also the support of @CGGXANNX ,@Flannels,@anav @Anime4000 and team at mikrotik particularly Oskars he was patient receiving multiple emails from me.
Hi himurae, congrats buddy.
Can you explain in simple terms what the fix is..... and how it changes what you do on the config.
Simply put,
for providers unable to provide their customers with a correctly set MTU of 1500, but limited to 1492,
if the PPPoE server is not compliant with RFC protocols, the keepalive packet cause MTU reduction from 1492 to 1480.
MikroTik programmers have added the option, when disabled keepalive, to not do that, so that the line remains at 1492.
This, however, does NOT solve the problem that the client can't have a full 1500 packet,
but still has to limit TCP to 1492 and the rest accordingly.
So, whether the packet is 1492 or 1480, it makes absolutely no difference;
to send 1500, you still need 2 packets + the overhead of the second packet...
How incredibly kind of MT do make non-standard code changes to help a few people with BAD ISPs.
Nothing to do with any RFC........
Meanwhile, the number of people that could make use of amnezia wireguard continues to grow LOL and both versions are backwards compatible with regular wireguard.
The standard mtu for a PPPoE connection is 1492 bytes for ages not all isp design according to rfc 4638 ,mikrotik routers are supposed to work with all isp not only some!!!
This is because my ISP uses Huawei’s Broadband Remote Access Server
Affected peer equipment models: ME60, NE40, NE9000, VNE9000, etc.
Here is an explanation of the this issue:
a.Huawei has launched the vBRAS structure, which splits the traditional BRAS into the User Plane and the Control Plane.
b.The Control Plane name is VNE9000, which is an X86 virtual machine deployed on the ISP’s cloud.
c.The User Plane consists of an X86 virtual machine or or an ARM physical machine or a traditional BRAS (such as ME60, NE40, etc.), there are deployed at sites near subscribers.
d.The User Plane is incorporated into the control plane and managed using OpenFlow.
e.The User Plane and Control Plane are connected using VXLAN, they may be hundreds of kilometers apart, with a delay of about 2 to 8 ms
f.Subscriber’s PPPoE dial-up request will first reach the User Plane. If it is a packet of 0x8863 or 0x8864, the subscriber information will be injected and forwarded to the Control Plane through VXLAN. Then, after the Control Plane completes PPP authentication, it will send the flow table to the User Plane through OpenFlow. If it’s a normal PPPoE Session packet, it will be fast forward on the user plane.
g.RouterOS and most network equipment implement PPPoE in compliance with RFC4638.
h.Therefore, when the RouterOS’s PPPoE Client dial-up, if you set the MTU>1488, it will send an Echo Request packet with a length equal to the MTU to the other end during the LCP negotiation phase.
i.Yes, you have found the issue now. The size of your Echo Request packet has exceeded the VXLAN MTU between the User Plane and the Control Plane. At this time, the Control Plane will never receive your Echo Request or reply to your Echo Request. Therefore, when your PPPoE Client fails to get an Echo Reply after three attempts, MK adjusts its MTU to 1480 in disappointment.
Now what mk has done is it created a option to disable rfc test and it works ,the whole middle east ,india still works with pppoe mtu 1492 and honestly i dont see much of a difference honestly compared to a lan connection with mtu1500.
Respectfully disagree, the purpose of standards is such that ICDs between every vendor are not required and to ensure designs and code can be made to ensure the standards are met and most important to ensure security of the information being transmitted.
The problem is vendors being allowed to manufacture products that do not meet the RFC. Who let them do that and who bought their products etc.........
I think that accommodating bad design is a fact of life.
What I disagree with quite strongly in lumping this in with keepalive. Yes, strictly keepalive messages are sent, but this is not about whether the connection is alive (for one, because on failure, the connection is not killed) but about mtu. This should be a separate option.
What I really don't understand (maybe I'm thick?) is why this matters so much. 1492 is still not 1500, and from then on certain workarounds are required. What in those additional magical 12 bytes make this easier or better?
If PMTU results in correct connection properties (and that's not always true) and in certain use cases (e.g. large file transfer), having MTU of 1492 instead of 1480 means 0.9% less packets needed and that means 0.9% less overhead overall and that means 0.9% higher throughput.
I'm as thick as you are so IMO the difference is negligible ... but it seems like some people's lives depend on it. And we have to respect that, don't you think?