Hello,

After some investigations with L2TP+IPSEC i found, that RB do not inherit "Don't fragment" bit from inner header!

This strange behavior causes fragmentation issues - you cannot find problems with ping -f inside tunnel!

My suggestion: this should be changed, or should be added manual selection for inheritance behavior.

I understand the issue, but have you tried lowering the MTU of the inner-tunnel interface so that the outer packet will not require fragmentation?

After some investigations with L2TP+IPSEC i found, that RB do not inherit "Don't fragment" bit from inner header!

Shoud it? I've just checked both the L2TP and ESP specifications, and neither seem to require copying the DF flag from inner packet into the outer packet. More over, for ESP such copying sounds like a potential security problem (may be thought of as an aid in cryptanalysis).

Please provide some normative references if you still think the current behavior should be changed.

Its citation from Mikrotik support answer:

"Make sure there is no fragmentation, L2TP + IpSec can make up to 70B of overhead.
You can run packet sniffer on the interface to detect packet fragmentation when doing file transfer. You can also try to ping using do-not-fragment and size parameters."

very strange recommendation, considering that the DF-bit is not inherited...

Its citation from Mikrotik support answer:

"Make sure there is no fragmentation, L2TP + IpSec can make up to 70B of overhead.
You can run packet sniffer on the interface to detect packet fragmentation when doing file transfer. You can also try to ping using do-not-fragment and size parameters."

very strange recommendation, considering that the DF-bit is not inherited...

Packets with the DF bit that are too large to pass, will not get passed and therefore no encapsulating packet to set the bit on.

Its citation from Mikrotik support answer:

"Make sure there is no fragmentation, L2TP + IpSec can make up to 70B of overhead.
You can run packet sniffer on the interface to detect packet fragmentation when doing file transfer. You can also try to ping using do-not-fragment and size parameters."

very strange recommendation, considering that the DF-bit is not inherited...

Packets with the DF bit that are too large to pass, will not get passed and therefore no encapsulating packet to set the bit on.

You do not understand.
Packets pass the internal interface, but after the encapsulation (without DF bits inheritance), fragmented on the external interface!

Why ESP should inherit DF bit?
Support recommendation works without inheriting DF bit. When you send ping to internal interface with DF, interface cannot send such packet and sends back response that packet is too large.

Support recommendation works without inheriting DF bit. When you send ping to internal interface with DF, interface cannot send such packet and sends back response that packet is too large.

You are wrong.
When I send a packet with DF-bit (ping -f .....), it passes the internal interface, and fragmented on external interface! (i see it with sniffer).

Support recommendation works without inheriting DF bit. When you send ping to internal interface with DF, interface cannot send such packet and sends back response that packet is too large.

You are wrong.
When I send a packet with DF-bit (ping -f .....), it passes the internal interface, and fragmented on external interface! (i see it with sniffer).

This is because the packet is below the inner MTU, thus it is neither discarded nor dropped. The resulting encrypted tunnel packet may exceed the physical interface's MTU, and since the IPSec session is technically not the inner traffic, it is eligible for fragmentation. There's no way around this fact - even if DF was inherited, PMTUD would fail, and here's why:
Hosts A and Z communicate via an encrypted tunnel between routers B and Y.
A sends a DF packet via B, and the packet is larger than the tunnel interface MTU at router B, and router B can send ICMP fragmentation needed message to A, and A can reduce the packet size and retransmit properly.
If A sends a DF packet via B which is small enough to fit the MTU of the tunnel interface, then B doesn't send a message to A because the packet fits. However, when the encrypted packet is built and B then finds that the resulting packet is too large for the physical interface MTU, then B must fragment the tunnel packet - and technically, B could possibly have some stateful information enough to send an ICMP fragmentation required message to A - but this is unlikely already since the IP stack of the physical host will see the crypto engine as the source of the packets, not host A - but let's suppose that it's doable - okay so B can still notify A.
Now let's assume that the inner payload + crypto overhead does not exceed the physical egress interface MTU at router B. Router B will forward the packet to the Internet. Suppose somewhere in the middle of the internet at a link between routers P and Q, the MTU is lower than the B->C link. Even if the DF bit were inherited, router P will see B as the source, not A, so the ICMP message would not reach A for A to lower its MTU.
Even if you were to propose that B should receive these ICMP fragmentation required messages from router P, and figure out which packet caused it and which internal host needs the message, and to adjust the message's reported next-hop MTU from P accounting for the encapsulation overhead, it wouldn't require DF inheritance. It would be easier for B and Y to always use DF on the outer packets and do their own PMTUD and then dynamically adjust the MTU of the tunnel interface.
Thus - if you know the PMTU between your B and Y routers, you should set the MTU of the tunnel to be low enough to not require fragmentation.