Community discussions

MikroTik App
 
romihg
newbie
Topic Author
Posts: 45
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

Netflix and IPv6

Wed Jan 06, 2021 6:10 pm

I can not reach the Netflix if i have IPv6 enabled. Or on every 10th try i get netflix to work. I find the solution but i need translatin to Mikrotik talk.

https://www.reddit.com/r/ipv6/comments/ ... d_netflix/


----snip from reddit--------
MSS clamping of 1432, or interface MTU of 1508 with PPPoE MTU of 1500 (note that the config tree in Edgerouter tries to set an MTU of 1412 if it's blank and you make changes to something unrelated)

Since I enabled IPv6 in my house, Netflix has basically not worked - the website doesn't even load. I contacted Netflix support who told me "IPv6 doesn't work with IPv4 tunneling". Now, I'm not expert, but I'm pretty sure I am not tunneling. My ISP provides a /56 prefix, and my router and devices use SLACC to get a public facing IP. Tracert to netflix.com shows a straight IPv6 connection the whole way.

If I disable IPv4 on my PC, I still have connection to IPv6 enabled sites, but Netflix completely refuses to load unless I disable IPv6. Netflix themselves told me I should "disable IPv6" if I want to use Netflix.

I personally would rather not use it, but I have family members in the house who watch Netflix a lot, and it's getting frustrating when casting to Chromecast takes 3+ attempts before it kicks in.

Has anyone else experienced problems?

Edit: Thanks for everyone willing to offer help with my problem. I will be trying connecting with the stock ISP router when I can, but unfortunately living in a house with other people, I can't just start booting everyone offline.

Netflix does occasionally work with Chromecast, just takes a few goes, which is a pain, but I will look into what I can do. I don't think there's any way of limiting certain devices to NATed IPv4, so looks like I'll have to live with the problem for now. Maybe start shoving a WiFi point through an IPv4 only VPN and see if it fixes things
------snip from reddit--------


My isp give me /56 subnet so no VPN is in play here.

My config

https://pastebin.com/7p3gZ3iP


Edit: corrected reddit link
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Wed Jan 06, 2021 7:46 pm

Set underlying ethernet interface actual MTU to 1520 (value is this high because MikroTik seems to require undocumented padding for PPPoE on layer 2.5, in normal cases of course 1508 is sufficient) and L2 value must be greater than that to ensure VLANs works well, 1598 is good enough.

Now in the PPPoE client, leave MRU and MTU as null, RouterOS will auto-detect the appropriate MTU and MRU that will be negotiated between your ethernet's interface and then passed through the PON link (if it's PON) or DSL link etc (some ONTs and modems do not support baby jumbo frames auto-negotiation on their ethernet interface) and finally hit the access concentrator.

I'm 1000% sure your ISP is not RFC4638 compliant. With the above, your IPv6 and IPv4 MTU/MRU issues will be resolved.

Source: I have two uplink providers, once is RFC4638 compliant, the other is not. We solved this MTU issue with the above methods. TCP clamping is no longer required with proper MTU.
 
romihg
newbie
Topic Author
Posts: 45
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

Re: Netflix and IPv6

Wed Jan 06, 2021 8:49 pm

Connection to ISP is fibre. It is not GPON. It is plain FTTH.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Wed Jan 06, 2021 10:30 pm

What is you PPPoE interface Actual MTU?
Anyway, take a look on this topic too: viewtopic.php?f=2&t=169757&p=832247#p831447
 
romihg
newbie
Topic Author
Posts: 45
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

Re: Netflix and IPv6

Thu Jan 07, 2021 2:28 am

What is you PPPoE interface Actual MTU?
Anyway, take a look on this topic too: viewtopic.php?f=2&t=169757&p=832247#p831447
Thank you for right direction. MTU for IPv6 worked.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 11:09 am

Connection to ISP is fibre. It is not GPON. It is plain FTTH.
Bruh, FTTH is Fibre to the home, what in the world is "plain" FTTH? Unless you live right next to AT&T's NOCs, it is a PON, no way your ISP can afford AON to millions of customers.
It can be GPON or EPON or XG-PON or XGS-PON or 10G-EPON.

Forcing 1280 IPv6 MTU is a poor solution. I don't know why you're resistant to fix the actual MTU on the underlying ethernet's interface like I described and ensuring sufficient padding for any future RFC4638 from your ISP.

Underlying EthernetImage

Leave RouterOS to auto-negotiate with the access concentrator based on the new ethernet MTU + jumbo frame negotiation on the PON linkImage

Having proper MRU of 1500 even if ISP caps MTU due to no RFC4638 ensures incoming traffic is unfragmented and therefore full potential performance excluding choking etc on ISP/Local link.
Last edited by DarkNate on Thu Jan 07, 2021 1:17 pm, edited 2 times in total.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 11:51 am

How do you know that he forced 1280?
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 12:22 pm

How do you know that he forced 1280?
This is how: viewtopic.php?f=2&t=171390#p838047

Updated my post with screenshots: viewtopic.php?f=2&t=171390&p=838089#p838089

Anyone with basic knowledge and fundamental understanding of MTU and MTU negotiation should be able to comprehend. And RFC4638 of course.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 12:33 pm

Your magic orb is probably better than mine, maybe he set it to the MTU negotiated by the PPPoE interface, like I wrote on the other topic :)
PS: your screenshots kinda proove that your ISP has RFC4638 implemented, otherwise it wouldn't negotiate 1500 MTU on your PPPoE interface.
Why do you state that it doesn't (on the other topic)?
 
romihg
newbie
Topic Author
Posts: 45
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

Re: Netflix and IPv6

Thu Jan 07, 2021 1:10 pm

My english is not so good so i wiil try to explain my plain FTTH. I plug in my fibre direct in SFP in modem.No GPON interface in front of my modem. In our contry was deployed FTTH at first but then started GPON deployment beacuse of price.

SFP is BiDi 1310/1550
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 1:16 pm

Your magic orb is probably better than mine, maybe he set it to the MTU negotiated by the PPPoE interface, like I wrote on the other topic :)
PS: your screenshots kinda proove that your ISP has RFC4638 implemented, otherwise it wouldn't negotiate 1500 MTU on your PPPoE interface.
Why do you state that it doesn't (on the other topic)?
I have two ISPs. Can't you see ethernet1/2, pppoe1/2? One is RFC4638 complaint, the other is not. My screenshot of the MTU config will be helpful for users of either type of ISPs.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 1:25 pm

My english is not so good so i wiil try to explain my plain FTTH. I plug in my fibre direct in SFP in modem.No GPON interface in front of my modem. In our contry was deployed FTTH at first but then started GPON deployment beacuse of price.

SFP is BiDi 1310/1550
That SFP module is your ISP's method of handoff, from there you are likely connected by ethernet to the ONU/ONT (modem doesn't exist in fibre optics), and since that SFP model is rated for 1G, your FTTH is using EPON technology. And the ONT by default is bridged which is great.

Change the ethernet interface MTU and PPPoE client like my screenshots. Your problem will disappear.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:14 pm

Ah, you had another post above explaining the two ISP's, I've missed it, sorry.
Did some tests here, is this realy a MikroTik PPPoE implementation bug?
I'll post some logs with stripped irelevant (I hope) stuff.
Ethernet MTU 1500:
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x20 
13:20:05 pppoe,ppp,debug,packet    <mru 1480> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480> 
Ethernet MTU 1508:
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x28 
13:29:52 pppoe,ppp,debug,packet    <mru 1488> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488> 
Ethernet MTU 1512, there is a new "ppp-max-payload" packet showing up in the packets before the ones posted above, (it doesn't show up with 1500 or 1508).
 
13:20:32 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:32 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADS from 1C:20:DB:XX:XX:XX 

13:20:33 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x23 
13:20:33 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
And after all of the above, this is also new:
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP EchoReq id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484> 
[..IPCP / IPV6CP Conf Stuff..]
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP EchoRep id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484> 
Going further with Ethernet MTU of 1520 changes only the new packet shown above (ppp-max-payload) changing from 1492 to 1500, but sadly (for me) only that. The rest is the same as the above, resulting PPPoE interface MTU of 1492.
 
13:20:50 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:50 pppoe,debug,packet     ppp-max-payload=1500 
13:20:51 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:51 pppoe,debug,packet     ppp-max-payload=1500 
13:20:52 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet     ppp-max-payload=1500 
Why is RouterOS acting this way? requiring Ethernet MTU to be set to 1512 for proper detection of MTU 1492 for the PPPoE interface? (or like you've said, 1520 for 1500 PPPoE).
I was setting PPPoE MTU/MRU to 1492 manually until now because of this (with no issues, it worked, actual MTU resulted in 1492).
Thanks.
Worth filing up a bug report?
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:37 pm

Ah, you had another post above explaining the two ISP's, I've missed it, sorry.
Did some tests here, is this realy a MikroTik PPPoE implementation bug?
I'll post some logs with stripped irelevant (I hope) stuff.
Ethernet MTU 1500:
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x20 
13:20:05 pppoe,ppp,debug,packet    <mru 1480> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480> 
Ethernet MTU 1508:
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x28 
13:29:52 pppoe,ppp,debug,packet    <mru 1488> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488> 
Ethernet MTU 1512, there is a new "ppp-max-payload" packet showing up in the packets before the ones posted above, (it doesn't show up with 1500 or 1508).
 
13:20:32 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:32 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADS from 1C:20:DB:XX:XX:XX 

13:20:33 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x23 
13:20:33 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
And after all of the above, this is also new:
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP EchoReq id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484> 
[..IPCP / IPV6CP Conf Stuff..]
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP EchoRep id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484> 
Going further with Ethernet MTU of 1520 changes only the new packet shown above (ppp-max-payload) changing from 1492 to 1500, but sadly (for me) only that. The rest is the same as the above, resulting PPPoE interface MTU of 1492.
 
13:20:50 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:50 pppoe,debug,packet     ppp-max-payload=1500 
13:20:51 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:51 pppoe,debug,packet     ppp-max-payload=1500 
13:20:52 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet     ppp-max-payload=1500 
Why is RouterOS acting this way? requiring Ethernet MTU to be set to 1512 for proper detection of MTU 1492 for the PPPoE interface? (or like you've said, 1520 for 1500 PPPoE).
I was setting PPPoE MTU/MRU to 1492 manually until now because of this (with no issues, it worked, actual MTU resulted in 1492).
Thanks.
Worth filing up a bug report?
That's not a bug: https://www.cisco.com/c/en/us/td/docs/i ... mpiwf.html

The actual potential bug is, why do we need 1520 ethernet MTU to achieve 1500+8 PPPoE overhead? Extra 12 bytes go somewhere, right? My theory is, those extra bytes are negotiated with the PON link itself, Fibre optics encapsulates ethernet inside the PON, so that itself will take overhead and likely adds the extra 12 bytes.

Stick with 1520 though, your PPPoE client will then have true 1500 MRU with zero packet fragmentation for incoming traffic, better download bandwidth performance basically.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:42 pm

That's the one I was reffering to, how and why are those 12 (apparently invisible since it works just fine with 1500 and manualy setting 1492 for the PPPoE client interface) bytes getting in the picture.
I wasn't referring to the max-payload packet, I was just underlining the differences there.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:45 pm

That's the one I was reffering to, how and why are those 12 (apparently invisible since it works just fine with 1500 and manualy setting 1492 for the PPPoE client interface) bytes getting in the picture.
I wasn't referring to the max-payload packet, I was just underlining the differences there.
MikroTik support is garbage, so good luck trying to figure out why those extra 12 bytes are required. The only reason I'm on MikroTik is due to PCC and Nth which is crucial for my load balancing setup, else I'd be out of this vendor. In theory, 1508 ethernet MTU is the correct value to achieve 1500 MTU/MRU on PPPoE client for sure.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:52 pm

Regarding the MRU, no, here it shows only 1492 (max-mtu/mru both unset / auto) but I'll stay with 1520 in case the ISP decides to implement RFC4638 anyway.
ppp-mtu.PNG
You do not have the required permissions to view the files attached to this post.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 2:56 pm

Regarding the MRU, no, here it shows only 1492 (max-mtu/mru both unset / auto) but I'll stay with 1520 in case the ISP decides to implement RFC4638 anyway.
ppp-mtu.PNG
So MRU is not always going to be supported @1500. We found here in my country that about 20+ different OLT/ONT brands have broken MTU negotiation mechanisms on layer 2, so even if the MikroTik router is set for 1520 MTU, the underlying layer 2 link between the ONT and the router is capped at 1500 MTU.

We have tested three different brands and confirmed they support jumbo frames, namely:
TP-Link GPON ONTs
Genexis ONT/ONUs
Huawei (basically all the models)
A few models of Nokia's

Long Story short, those in the know about this in my country ends up purchasing ONT/ONU models individually from the above brands. I usually recommend GX Earth 1000R as it's XPON and supports both GPON and EPON.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 3:26 pm

I wrote to support about this anyway, I had good results with support in the past, the issues reported were fixed.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Thu Jan 07, 2021 7:28 pm

I wrote to support about this anyway, I had good results with support in the past, the issues reported were fixed.
Let us know, 12 bytes going to thin air isn't possible. Someone suggested it's "padding" exclusive to MikroTik which happens to be undocumented.

Perhaps you can help this gentleman realise my solution to broken MTU is the most effective and works for UDP, not just TCP via MSS clamping: viewtopic.php?f=2&t=169757&p=838156#p838148
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Fri Jan 08, 2021 6:25 pm

Ok, I think I've figured it out where the bug might be, hope support confirms / fixes this.
I've took some captures from the ethernet interface while connecting the pppoe-client and while watching them in Wireshark I saw something in an area to which I didn't pay much attention earlier (protocol req / ip addr etc).
Parts that I considered irelevant in the logs above, lol. But I've sent the full logs to MikroTik anyway.
Anyway, this pair is interesting:
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: sent MPLSCP ConfReq id=0xd 
[...]
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ProtRej id=0x2 
13:20:06 pppoe,ppp,debug,packet      82 81 01 0d 00 04 
The last part translates to: Rejected Protocol: MPLS Control Protocol (0x8281). (!!)
Now on the MikroTik wiki we have this: https://wiki.mikrotik.com/wiki/Manual:MPLS_over_PPPoE
When running MPLS over PPPoE or other tunnels you have to deal with MTU issues. Tunnels add more overhead (in our case PPPoE adds 8 more bytes). To be able to forward 1500 byte IP packet without fragmentation we will need interface that supports
1500 (IP frame)
+ 8 (PPPoE header)
+ 4 (MPLS header)
= 1512bytes
12 bytes? anyone?
And a note:
Note: Since v5.0 is added proper support for MPLS over PPP. Now by default MPLS is disabled, to enable it go to
/ppp profile menu and set use-mpls=yes
I've checked that setting in profile and it is set to "default" which defauts to "yes" as it seems since there is a request for it.
I've tried to set it to "no" to see if any magic happens but sadly, no -> no request, no reject, but those 12 bytes still get counted.
But, could this be it or is it unrelated? And if it is, would a proper "fix" just be that simple? if "use-mpls=no" -> don't require the 12 extra bytes on the ethernet interface? And setting the default to "no" maybe.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Sat Jan 09, 2021 9:47 am

Ok, I think I've figured it out where the bug might be, hope support confirms / fixes this.
I've took some captures from the ethernet interface while connecting the pppoe-client and while watching them in Wireshark I saw something in an area to which I didn't pay much attention earlier (protocol req / ip addr etc).
Parts that I considered irelevant in the logs above, lol. But I've sent the full logs to MikroTik anyway.
Anyway, this pair is interesting:
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: sent MPLSCP ConfReq id=0xd 
[...]
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ProtRej id=0x2 
13:20:06 pppoe,ppp,debug,packet      82 81 01 0d 00 04 
The last part translates to: Rejected Protocol: MPLS Control Protocol (0x8281). (!!)
Now on the MikroTik wiki we have this: https://wiki.mikrotik.com/wiki/Manual:MPLS_over_PPPoE
When running MPLS over PPPoE or other tunnels you have to deal with MTU issues. Tunnels add more overhead (in our case PPPoE adds 8 more bytes). To be able to forward 1500 byte IP packet without fragmentation we will need interface that supports
1500 (IP frame)
+ 8 (PPPoE header)
+ 4 (MPLS header)
= 1512bytes
12 bytes? anyone?
And a note:
Note: Since v5.0 is added proper support for MPLS over PPP. Now by default MPLS is disabled, to enable it go to
/ppp profile menu and set use-mpls=yes
I've checked that setting in profile and it is set to "default" which defauts to "yes" as it seems since there is a request for it.
I've tried to set it to "no" to see if any magic happens but sadly, no -> no request, no reject, but those 12 bytes still get counted.
But, could this be it or is it unrelated? And if it is, would a proper "fix" just be that simple? if "use-mpls=no" -> don't require the 12 extra bytes on the ethernet interface? And setting the default to "no" maybe.
With this new info, I have a new theory. This may not be a bug, at all. MikroTik may have made the decision to account for the MPLS header + whatever else by default no matter what, therefore ensuring admins wouldn't need to change from 1508 to 1512 or 1520 more than once, it is smarter to just set 1520 one time across a network and use that value, which is future-proof enough even if you do use the MPLS header as the docs stated.

Makes sense, right? I guess this "12 bytes" is solved then, credit goes to you man.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Sat Jan 09, 2021 11:25 am

I'll wait from support, the behaviour ain't quite right.
Any user that has a pppoe-client as WAN out there is using a 12 bytes lower MTU than his provider supports, if everything is left to auto/defaults that is.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Sat Jan 09, 2021 12:39 pm

I'll wait from support, the behaviour ain't quite right.
Any user that has a pppoe-client as WAN out there is using a 12 bytes lower MTU than his provider supports, if everything is left to auto/defaults that is.
That is also correct. Do keep us updated.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Mon Jan 11, 2021 2:06 pm

Ok, support response is:
"RouterOS simply allocates 20 bytes headers. You can manually set the MTU and MRU values for the interface if other values are suitable. There is no need to increase the MTU on the ethernet interface."
So they won't do anything about it.
"What about the users that leave it to auto?" "- they won't feel the difference". (They won't feel it maybe because in MikroTiks eyes people that like to leave stuff to auto aren't "professionals")? BUT I'd like my damn client to negotiate whatever it can support to whatever the ISP is giving me without undocumented 20 bytes of extra room for ghosts.
Rubbish, for short. Meh.
Where do we go from here? Either set 1520 for Ethernet like you've said above and leave MTU/MRU to auto so they can negotiate whatever they want without the 20 bytes allocated by RouterOS OR set MTU/MRU manually to whatever the ISP supports and leave the Ethernet MTU alone.
Quick search on the forum .. ain't the first talk about this:
viewtopic.php?t=132547
Might be others.
PS: I wonder if other vendors treat PPPoE like this too.
PS2: In a country where one of the largest ISPs is using PPPoE this sucks. For IPv6 it sucks even more. Not every user of MikroTik likes to play with knobs they don't know what they do exactly.
Good thing this ISP doesn't use MikroTiks for their networking stuff, 12 bytes from me, 12 bytes from x, 12 bytes from y add up on those Routers (in the more fragments on the routers -> more packets to send kind of way).
The ISP that IS using MikroTiks is giving me 1480 MTU and 1500 MRU. Guess they like to keep stuff to auto/defaults too.
But hey! who cares! it's only 12 bytes.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Mon Jan 11, 2021 2:56 pm

Ok, support response is:
"RouterOS simply allocates 20 bytes headers. You can manually set the MTU and MRU values for the interface if other values are suitable. There is no need to increase the MTU on the ethernet interface."
So they won't do anything about it.
"What about the users that leave it to auto?" "- they won't feel the difference". (They won't feel it maybe because in MikroTiks eyes people that like to leave stuff to auto aren't "professionals")? BUT I'd like my damn client to negotiate whatever it can support to whatever the ISP is giving me without undocumented 20 bytes of extra room for ghosts.
Rubbish, for short. Meh.
Where do we go from here? Either set 1520 for Ethernet like you've said above and leave MTU/MRU to auto so they can negotiate whatever they want without the 20 bytes allocated by RouterOS OR set MTU/MRU manually to whatever the ISP supports and leave the Ethernet MTU alone.
Quick search on the forum .. ain't the first talk about this:
viewtopic.php?t=132547
Might be others.
PS: I wonder if other vendors treat PPPoE like this too.
PS2: In a country where one of the largest ISPs is using PPPoE this sucks. For IPv6 it sucks even more. Not every user of MikroTik likes to play with knobs they don't know what they do exactly.
Good thing this ISP doesn't use MikroTiks for their networking stuff, 12 bytes from me, 12 bytes from x, 12 bytes from y add up on those Routers (in the more fragments on the routers -> more packets to send kind of way).
The ISP that IS using MikroTiks is giving me 1480 MTU and 1500 MRU. Guess they like to keep stuff to auto/defaults too.
But hey! who cares! it's only 12 bytes.
What did I tell you about MikroTik support? They are garbage. Which is why they will never dominate the networking world and remains a DIY/Niche-type of the market for them.

So 20 Bytes is allocated as some kind of future-proof headroom, and that's not documented, perfect. I mean it's fine for DHCP/IP-to-IP networking, but this secret 20Bytes messes with any tunnelling protocol.

Setting the MTU manually on PPPoE for most end users will just create problems, many wouldn't know how to test with DF flag in ping as not all ISPs defaults to 1492 anyhow. Settings 1520 ethernet MTU fixes that problem and enables true auto-negotiation.
 
User avatar
Znevna
Member
Member
Posts: 345
Joined: Mon Sep 23, 2019 1:04 pm

Re: Netflix and IPv6

Mon Jan 11, 2021 3:06 pm

It's the last time I wrote about some quirks in the configs. An "Oh yeah we forgot about this since we set it like this ages ago, we'll maybe take a look on this to improve the behaviour since it might have not been the best call back then" would've been a little better than "set it yourself".
I'll only write to them again if there's something completely broken that I need for my current job.
Oh yeah, and I'll stay on the 6.46 branch for as long as I can.
Cheers!
LE: Nope, pppoe-client with auto mru/mtu and 1520 MTU for Ethernet is a no go, (1520 to be future proof in this way of thinking) atleast not on the ISP that uses MikroTiks (I end up with 1480 MTU / 1500 MRU) because that 1500 MRU is wrong, pinging from outside results that MRU is actualy 1480 too, no more. Why is it giving me higher than the ISP supports beats me! Back to manual for that one.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: Netflix and IPv6

Sat Jan 30, 2021 9:30 am

It's the last time I wrote about some quirks in the configs. An "Oh yeah we forgot about this since we set it like this ages ago, we'll maybe take a look on this to improve the behaviour since it might have not been the best call back then" would've been a little better than "set it yourself".
I'll only write to them again if there's something completely broken that I need for my current job.
Oh yeah, and I'll stay on the 6.46 branch for as long as I can.
Cheers!
LE: Nope, pppoe-client with auto mru/mtu and 1520 MTU for Ethernet is a no go, (1520 to be future proof in this way of thinking) atleast not on the ISP that uses MikroTiks (I end up with 1480 MTU / 1500 MRU) because that 1500 MRU is wrong, pinging from outside results that MRU is actualy 1480 too, no more. Why is it giving me higher than the ISP supports beats me! Back to manual for that one.
1520MTU is safe. For 1500MRU to work, the access concentrator needs to have that enabled or simply set to auto. Both my ISPs have MRU set to auto so I get true 1500 MRU.

Who is online

Users browsing this forum: Bing [Bot], JohnTRIVOLTA, plp71, sindy and 38 guests