SRX

Expand all | Collapse all

SRX st0 interface IP MTU settings

  • 1.  SRX st0 interface IP MTU settings

    Posted 07-25-2017 14:03

    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,



  • 2.  RE: SRX st0 interface IP MTU settings

     
    Posted 07-26-2017 02:43

    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.



  • 3.  RE: SRX st0 interface IP MTU settings

    Posted 07-26-2017 11:38

    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?



  • 4.  RE: SRX st0 interface IP MTU settings

     
    Posted 07-27-2017 00:18

    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"

     

     



  • 5.  RE: SRX st0 interface IP MTU settings

    Posted 07-27-2017 11:01

    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.



  • 6.  RE: SRX st0 interface IP MTU settings

     
    Posted 07-27-2017 23:11
    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.