EoIP MTU for pppoe server tunnel

I know may this is the asked question before but I could not get correct answer.. can you help me guys ?
I have a routed and bridged network and I’m sending customer’s pppoe_client connections to pppoe server over eoip, eoip tunnels created between AP’s and Pppoe Server.

So
Questions:

  • what is the best mtu for eoip to avoid fragmentation and get good results ? ( all interface of network both wlan and ethernet 1500 mtu)
  • what should MTU and MRU to set in pppoe server and pppoe client ?

MTU
Typically, the largest Ethernet frame that can be transmitted without fragmentation is 1500 bytes. PPPoE adds another 6 bytes of overhead and PPP field adds two more bytes, leaving 1492 bytes for IP datagram. Therefore max PPPoE MRU and MTU values must not be larger than 1492.

TCP stacks try to avoid fragmentation, so they use an MSS (Maximum Segment Size). By default MSS is chosen as MTU of the outgoing interface minus the usual size of the TCP and IP headers (40 bytes), which results in 1460 bytes for an Ethernet interface. Unfortunately there may be intermediate links with lower MTU which will cause fragmentation. In such case TCP stack performs path MTU discovery. Routers which cannot forward the datagram without fragmentation are supposed to drop packet and send ICMP-Fragmentation-Required to originating host. When host receives such ICMP packet, it tries to lower the MTU. This should work in the ideal world, however in the real world many routers do not generate fragmentation-required datagrams, also many firewalls drop all ICMP datagrams.

The workaround for this problem is to adjust MSS if it is too big. By default RouterOS adds mangle rules to intercept TCP SYN packets and silently adjust any advertised MSS option so they will be appropriate for the PPPoE link.

https://wiki.mikrotik.com/wiki/Manual:Interface/PPPoE#MTU

Close in most ways, but missing critical details.

First, MSS clamping is at best a band-aid that is commonly applied without fixing a MTU problem correctly. MSS clamping should be completely unnecessary if MTU is set correctly and firewall rules do not interfere with path MTU discovery.

Second, somewhere in 6.39 or 6.40 they added the ability to perform MSS clamping directly within the configurations of various tunnel interfaces. This was in the past traditionally done with firewall rules. Make sure you don’t have overlap. After reading the first post, disable MSS clamping and remove any rules associated with it.

Third, while the MTU values above are correct in a lot of ways the value of the transport wasn’t covered clearly.


  • Layer 2 MTU should be consistent across an Ethernet segment
  • EoIP adds overhead, 14 bytes + 4 bytes + 20 bytes (Ethernet, GRE and IP)
  • EoIP is capable of fragmenting packets to emulate an inner MTU larger than the transport MTU is capable of handling. This of course has a negative impact on performance.
  • PPP is capable of fragmenting packets to emulate an inner MTU larger than the transport MTU is capable of handing. This of course has a negative impact on performance.
  • The above two can compound and turn into fragments for fragments.

So your problem. Let’s fix it by correctly setting MTU from end to end in your network. You’ll have to think critically about the MTU on the wireless side, is a default value? Was it set higher to allow for all of the encapsulation you’re doing? After you identify that, look at the bridges that were migrated to the new setup. Are the MTU values correct? Did they migrate correctly from the older code days? After you remove the MSS settings on EoIP and PPP make sure that the MTU values are correctly set and identify if you want EoIP to fragment to service 1500 MTU, PPP to fragment via MRU to service 1500 MTU or none of the above. You are also likely seeing some hiccups with the new bridges and how they work. Depending on how you’ve terminated EoIP on the PPPoE server may help determine how you go forward on that.

You also can provide 1500 MTU to clients by bumping up the transport MTU natively, a fair number of ISPs have moved their fabric to an MTU value greater than 1500 to give themselves flexibility in these situations. Their is no reason you couldn’t do the same on either the fiber or wireless side. If you need further help understanding where a specific MTU value needs to be configured we’d need to see a diagram of your network.

Fourth, 6.3 - sigh. I get it you’re a business but do you realize your devices were all vulnerable to exploits? This process is also far more “painful” because you’ve waited so long. It is likely valuable for your business to track one of the release trains much closer. Given your apparent aversion to upgrades, bugfix might be that train.

Some useful posts I’ve done in the past:


http://forum.mikrotik.com/t/eoip-tunnel-on-lte-not-forwarding-http/108338/1
http://forum.mikrotik.com/t/gre-tunnel-setup-help/108436/2

many many thanks for all your help mohannad and idlemind…

all pppoe_server version 6.42 and above but Im still using mangle rule on pppoe server like;

chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp



all ethernet and wireless mtu default which is 1500

all bridges set as mtu auto so when eoip tunnel auto mtu and set it self 1458 mtu , bridge also become 1458mtu. I add wlan interface and eoip interface in bridge only.

you mean if I want to give clients 1500 mtu I should use mtu on all network greater than 1500, 1492 is enough for clients if i can do. for now if I would like to make clients mtu 1492 I should change EoIP mtu’s to 1500 but for this I should Make greater mtu for all network am I true ?

Yes I can prepare diagram.


I will read them carefully.

Thanks a lot.

I will probably need to see a diagram with the MTU noted along the pathing. The biggest item of concern is your statement that the EoIP and wireless are added to the same bridge. Is this happening at CPE? If so, why?

No, CPE is customer side and customer side not using eoip or bridge, CPe connecting to internet via pppoe_client.. I add wlan and eoIP in bridge at AP side only. I will try to draw a small diagram and share with you.. Thanks a lot for care and try to help.

No worries, what you are calling the “AP” I think of as the “CPE” or customer premises equipment that you own or manage. If that’s the case, I’m still a little confused why you are bridging the EoIP to a WLAN interface. I look forward to your drawing.

Hi idlemind,

I draw new diagram for better understand. on All AP_SXT’s eoip and wlan interface bridged.
Untitled.jpg
Thanks for your help

anyone ???

Hi,
any one can help me to increase mtu tunnel ? cause all mtu tunnels are at auto and 1458, I would like to give customers to full mtu

Thanks

On every lower OSI layer MTU have to have higher value than layer before for a size that depends of carrier’s protocol.

For ex:
On layer 4 we have 1452 bytes of data max(for TCP)
On layer 3 - 1472 bytes(1452+TCP(20))
On layer 2 - 1492 bytes(1472+IP(20))
On EoIP layer - 1510 bytes(1492+Ethernet(14)+GRE(4))
On layer 3 - 1530 bytes(1510+IP(20))
On PPP layer - 1538 bytes(1530 + PPPoE(8))
On layer 2 - 1552 bytes(1538+Ethernet(14))

Correct me if I’m wrong :slight_smile:

Sorry for the delay on this amt. The max MTU of different product lines is different. For most products you can go to 2026 or 2028.

CCR1036 at 10226
RB750P-PBr2 (PowerBox) at 2028
SXT at least 2028

The wireless side should be adjustable up to 65536 regardless of hardware (someone can correct me there).

You can provide 1500 MTU directly to your customers over PPPoE in 2 ways. You can use EoIP to bridge over any underlying MTU what appears to be natural Ethernet at any MTU you choose. EoIP is capable of providing fragmentation services for packets that are above the L2 MTU of the path to provide a L3 MTU of 1500 or in your case you’d want the MTU of the EoIP tunnels to be 1508 and allow fragmentation. This would allow PPP riding on top of the EoIP tunnel to be 1500 MTU.

Alternatively, you can adjust your network to use a MTU size that is larger than 1500 natively. You’d do this by ensuring each link is above and beyond 1500. Something like 2000 would be more than enough and seems to be supported by all of your hardware.

hello idlemind,
no problem for delay, thanks for still interesting with my topic.

soryy but dont understand this, on EoIP tunnel dont fragment=no, if I change it to inherit may solve my problem ?



yes as you said I checked powerbox and SXT’s mtu values and they like
on powerbox mtu:1500 and l2mtu:1598 Max l2mtu: 4074 on SXT mtu:1500 l2mtu:1600 and maxl2mtu:4076
in that case if i understand correctly I should increase mtu value on whole network and EoIP tunnel mtu will rise.

Hello,
I do some tests on lab and I increase ethernet MTU from 1500 to 1562 and now EoIP tunnels mtu came to 1520(EoIP tunnels at auto mtu) and pppoe connection is came to 1500. if I increase my whole network ethernet and wlan’s mtu to 1562 my alll EoIp tunnels mtu’s will change 1520 automatically and customers can get full mtu which is 1500. I want to learn that may I faced with any problem if I increase MTU ?

Thnxx

If all the equipment in your access network supports jumbo frames (large MTUs), then there won’t be any problem. If there’s a device, which doesn’t support jumbo frames (or is not configured appropriately), then you will hit some problems …

hello mkx
I think all they support 1562MTU , all devices are Mikrotik, NetMetal,CCR,RB1100Ahx,SXT and all of them seems support. but I could not change ISP side mtu. its 1500. Im planning to change mtu from tower to pppoe server path and I will not touch to others.
Something like this.

PPPoE_Server>>>Core Router>>RB1100Ahx>>>P2P Link>>>PowerBox>>SXTAP

planing to change this path mtu only.

Thanks