Hi, all, I am a little confused by SRX's DF bit behavior, according to this article:
DF bits of the inner IP packets is always cleared.
So if I have incoming Ethernet interface IP MTU set to 1500bytes, outgoing st0 interface MTU set to 1400 bytes (which is manditory by a 3rd party), when I have an incoming packet on Ethernet interface with IP size 1401 bytes, DF bit set, SRX will send out "Fragmentation needed" back with suggested MTU 1400 bytes back to the source, all good ... now if the above article is accurate, I should never set IP MTU size on the tunnel interface (or rather any manual IP MTU settings on st0 interface should be ignored), because by default any incoming packets can be fragmented regardless DF bits as long as IPsec encapsulated packet size exceeds egress IP MTU. correct?
If my argument is not correct, then what are my options to clear the DF bit so 1401 bytes packets can be processed?
Default behavior SRX dont copy the DF bit.
St0 MTU is 1400
Packet comes to SRX with DF bit and size is 1401
SRX encrypts the packet and then fragment it into 2 and transmit via tunnel interface
SRX config is "set security ipsec vpn <VPN Name> df-bit clear".
set security ipsec vpn <VPN Name> df-bit clear
Behavior will be same as above, SRX fragments traffic and send 2 smaller packets out
SRX config is "set security ipsec vpn <VPN Name> df-bit copy".
set security ipsec vpn <VPN Name> df-bit copy
If packet is coming with DF bit, and size of more than 1400 SRX sends ICMP packet stating frgmentation needed
If packet is coming without DF bit, and size of more than 1400 SRX fragments traffic and send 2 smaller packets out
Points to note, lets say you recive a packet of 1380, and the encryption over head is 21 bytes, in that case also we will need to consider fragmentation.
So scenario1 and scenario 2 are the same, the reality is 1401 bytes IP packeets are being rejected, SRX is sending "Fragmentation needed" ICMP back to source.
My question was, in both scenaio, according to you and the KB book, the packets will be fragmented any way, why explicit MTU settings on st0.x interface would matter? and why the packet was rejected?
I thought you set the MTU to match with remote side MTU.
Packet will be rejected only if there is DF bit on incoming packet and SRX has config staing "copy"
st0 interface MTU is being set to the value specified by AWS, presumebably to match their side tunnel MTU. Again, I don't have DF-bit "copy" configured, I have a case open with JTAC, JTAC can not give me a clear answer either. Either KB book is wrong or we have a bug in Junos.