SRX

Hi, all, I am a little confused by SRX's DF bit behavior, according to this article:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB25625&actp=METADATA

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?

 

Thanks,

Default behavior SRX dont copy the DF bit.

 

St0 MTU is 1400

Scenario 1

 

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

 

Scenario 2.

 

SRX config is "set security ipsec vpn <VPN Name> df-bit clear".

 

Behavior will be same as above, SRX fragments traffic and send 2 smaller packets out

 

 

Scenario 3.

 

SRX config is "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.

I guess your question is below.

"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?"

Let me put this as 2 questions.

1. by default any incoming packets can be fragmented regardless DF bits as long as IPsec encapsulated packet size exceeds egress IP MTU. correct?"

This is correct

2. "I should never set IP MTU size on the tunnel interface (or rather any manual IP MTU settings on st0 interface should be ignored),

This is not correct. Consider the scenario as below

(SRX)MTU (1500 or whatever default)-----------------------------------------(1400)AWS

SRX will decide to do perform fragmentation based on SRXMTU (on St0) and send it out by default. Consider SRX/ST0 MTU is 1500, then SRX will send packets as 1500 bytes + Fragments , but AWS cannot accept anything more than 1400 and it will drop it. To avoid this, you need to set the same MTU on SRX/St0.


I hope this helps.