ICMP Rate Limit and PMTU

RouterOS General
1

Hi Folks,

I upgrade from v6.30.4 to v6.36 which fixes my dhcp v6 pd problem on my pppoe server, this make me ipv6 ready. But this version contains some pppoe fixes and gives me mtu problems with ipv4.
My clients always used 1492 using routeros version belove v6.36 (example v6.27). With 6.36 as pppoe server the client gets a MTU of 1480 and MRU of 1492.
(If the client is also v6.36 I gets the expected 1492 and all MRU/MTU on server and client. )
Problem is that the client thinks its MRU is 1492 and place the TCP MSS rule. But the pppoe server uses a MTU of 1480 (!!).

Result you get a lot of refragmentation. Which should not be a big problem, but during the day I got all kind of strange complains.
And more that I would expected than random sites that have a broken PMTU.

RouterOs has a ICMP Rate Limit option, I believe it might have something to do with it.
The wiki says little about it. (http://wiki.mikrotik.com/wiki/Manual:IP/Settings)

[admin@*] /ip settings> print
ip-forward: yes
send-redirects: no
accept-source-route: no
accept-redirects: no
secure-redirects: no
rp-filter: strict
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30m
icmp-rate-limit: 10
** icmp-rate-mask: 0x1818**
route-cache: yes
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: no
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

I tried to find the linux setting and found this:

http://man7.org/linux/man-pages/man7/icmp.7.html

icmp_ratelimit(integer; default: 1000; since Linux 2.4.10)
Limit the maximum rates for sending ICMP packets whose type
matches icmp_ratemask (see below) to specific targets. 0 to
disable any limiting, otherwise the minimum space between
responses in milliseconds.

   _icmp_ratemask_ (integer; default: see below; since Linux 2.4.10)
          Mask made of ICMP types for which rates are being limited.

          Significant bits: IHGFEDCBA9876543210
          Default mask:     0000001100000011000 (0x1818)

          Bit definitions (see the Linux kernel source file
          _include/linux/icmp.h_):

               0 Echo Reply
               3 Destination Unreachable *
               4 Source Quench *
               5 Redirect
               8 Echo Request
               B Time Exceeded *
               C Parameter Problem *
               D Timestamp Request
               E Timestamp Reply
               F Info Request
               G Info Reply
               H Address Mask Request
               I Address Mask Reply

  The bits marked with an asterisk are rate limited by default (see the
   default mask above).

This says that ICMP Rate Limit with that MASK is not limiting echo reply.
And that the RATE option is not the number but a wait cycle.

I played around with hping to force the router to send icmp destination unreachable.
And changing the rate to 0, some in between and 10000000 but nothing has effect. Not sure yet put is seems to always be 20 packets a second. So a delay of 50 ms.

Who knows more about this option?
Will this options with a to low value cause pmtu issues?

Cheers,
Harry

2

It may be because of the implementation of RFC4638 earlier. It is not new in 6.36 but you see it now becuase you make
a larger version jump.
It is unclear to me why the 1480 MTU comes into play, I have seen earlier messages about that. I have only seen 1492
myself.
However, now that RFC4638 is implemented, you have the opportunity to raise the MTU to 1500 and end all problems for good!
This is of course only possible when you can raise the MTU on all equipment between your router and the customer router by 8.
I have MTU 1500 on the PPPoE connection to my internet provider, and it avoids a lot of nasty problems…

3

The non matching MTU and MRU is the problem. Doing a wrong TCP MSS makes it not working.
I agree 1500 mtu is better, but currently this is not how we build the network. We tested a couple of years ago and we could already use 1500 without the RFC.
(and MPPP is also still an option. ) But i wanted a compliant solution that would make no difference between a mikrotik endpoint and for example cisco router..

So I’m happy it got compliant, But my current situation is anonying.

But anyone some thought about the IP settings? Why is it not explaind in the wiki ?
If i change the value and test things i do not see any changes…

Cheers,
Harry