{{ result.summaryTitle }}
{{ result.primaryDisplay }}
{{ result.secondaryText }}
{{ badge.label }}
Use 1500 for a normal Ethernet path, 1492 for PPPoE, or the measured path MTU if known.
bytes
Choose a starting stack for PPPoE, GRE, VXLAN, WireGuard, IPsec, or combined VPN handoffs.
Pick the IP family carried by the flow whose TCP MSS should be clamped.
Use rows such as GRE over IPv4,24 and PPPoE,8.
Use 0 for exact math, or 8-32 bytes when the tunnel path has unknown vendor padding.
bytes
Leave 0 for the normal MSS clamp. Use 12 for a conservative timestamp/SACK payload estimate.
bytes
Use smaller steps for smoother exports and larger steps for compact CSV output.
bytes
MetricValueDetailCopy
{{ row.label }} {{ row.value }} {{ row.detail }}
ComponentBytesRemaining MTUNoteCopy
{{ row.component }} {{ row.bytesLabel }} {{ row.remainingLabel }} {{ row.note }}
CheckRecommendationDetailCopy
{{ row.check }} {{ row.recommendation }} {{ row.detail }}
OverheadEffective MTUTCP MSSStatusCopy
{{ row.overheadLabel }} {{ row.effectiveMtuLabel }} {{ row.mssLabel }} {{ row.status }} 

        

      

    

  

                

                

                    

                        

                            Tags: Diagnostics, Networking
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


        
    

        

        

            

            
        

    


                                                                                                                                                                                                                                                        
    

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
    



    

        

  

    

    
Maximum transmission unit, or MTU, is the largest packet size a path can carry at a given layer without fragmentation. TCP maximum segment size, or MSS, is the payload part of a TCP segment after the IP and TCP headers have been accounted for. When a tunnel, carrier access method, VLAN tag, or VPN wrapper adds bytes around a packet, the usable inner packet size gets smaller even when the outside path still advertises a familiar value such as 1500 bytes.


    
That byte budget is a common cause of tunnel trouble. Small packets can work while larger web transfers, backups, database replication, file copies, or VPN flows stall because the wrapped packet no longer fits. The fix is usually not one magic MTU. The useful number is the effective IP MTU after the known overhead is subtracted, followed by the TCP MSS clamp that keeps TCP data from exceeding that space.


    

      Diagram showing path MTU reduced by overhead and reserve, then IP and TCP headers subtracted to produce a TCP MSS value.
    


    
TCP MSS clamping is a TCP-specific guardrail. It can keep TCP endpoints from sending segments that exceed the modeled tunnel budget, but it does not resize UDP, QUIC, ICMP, or other traffic. Those protocols still need working Path MTU Discovery, application packet sizing, or a deliberately conservative tunnel MTU.


    
The result is best used as an engineering estimate before making a router, firewall, VPN, or host change. It can explain why 1460-byte TCP payloads no longer fit after GRE or IPsec is added, and it can provide a starting clamp value for testing. It cannot prove that every middlebox will pass the selected size, especially when ICMP error messages are filtered or vendor encapsulation details differ from the plan.

  






  

    
Technical Details:


    
MTU planning starts with the smallest usable packet size on the outside path and subtracts the bytes that sit around or ahead of the carried packet. A normal Ethernet IP path is often modeled with a 1500-byte IP MTU. PPPoE access, VLAN tagging, GRE, VXLAN, WireGuard, IPsec ESP, NAT traversal, and nested handoffs can each consume part of that budget before the inner packet reaches the payload IP layer.


    
TCP MSS is not the full packet size. It is the TCP data portion that remains after the effective IP MTU gives room to the IP header and the fixed 20-byte base TCP header. IPv4 uses a 20-byte base IP header in this calculator, while IPv6 uses a 40-byte base IP header. Optional TCP option reserve is handled as a second payload estimate so the normal MSS clamp remains visible.


    
Formula Core:

    
The budget is a direct subtraction model. Each overhead row contributes bytes to the stack total, the safety reserve is subtracted separately, and the selected payload IP version controls the header size used for MSS.


    

      
        
          Ostack=∑Ocomponent
          Ototal=Ostack+Rsafety
          Meffective=max(0,Mpath-Ototal)
          MSS=max(0,Meffective-HIP-20)
          PDF ping=max(0,Meffective-HIP-8)
        
      
    


    

      

        
        
ItemIPv4 payloadIPv6 payloadHow it affects the result

        
          
Base IP header20 B40 BSubtracted before the TCP MSS clamp and DF ping payload are reported.

          
Base TCP header20 B20 BSubtracted after the IP header to produce the normal TCP MSS clamp.

          
ICMP echo header8 B8 BSubtracted for the displayed DF ping payload budget.

          
Planning floor checked576 B1280 BUsed for the status cue that warns when the effective MTU falls below the selected payload family's floor.

        
      

    


    
Built-In Overhead Presets:

    

      

        
        
PresetModeled bytesByte stackPlanning note

        
          
Plain Ethernet / no tunnel0 BNo overhead rowsEffective MTU equals the path MTU unless a safety reserve is added.

          
PPPoE plus one VLAN tag12 BPPPoE 8 B plus 802.1Q VLAN 4 BUseful for access paths where the entered MTU has not already absorbed those bytes.

          
GRE over IPv424 BOuter IPv4 20 B plus basic GRE 4 BDoes not include optional GRE key, checksum, or sequence fields.

          
VXLAN over IPv450 BOuter Ethernet 14 B, outer IPv4 20 B, UDP 8 B, VXLAN 8 BMatch this to how the platform reports MTU so link-layer bytes are not counted twice.

          
WireGuard over IPv4 UDP60 BOuter IPv4 20 B, UDP 8 B, WireGuard data header and tag 32 BModels data packets over IPv4 transport, not handshake packet size.

          
IPsec ESP NAT-T over IPv4 estimate76 BOuter IPv4 20 B, UDP/4500 8 B, ESP estimate 48 BESP bytes vary by transform, tag length, IV, and padding.

          
GRE over IPsec NAT-T on PPPoE108 BPPPoE 8 B, outer IPv4 plus GRE 24 B, IPsec NAT-T estimate 76 BA conservative combined handoff starting point for nested tunnel planning.

        
      

    


    
The overhead curve is generated from the same equations. It compares possible overhead byte totals against effective MTU and TCP MSS, marks the current stack, and labels rows as usable, tight, below the selected IP-family floor, or without TCP room. The calculation itself runs in the browser from the entered values; it does not perform a live path probe or packet capture.

  






  

    
Everyday Use & Decision Guide:


    
Start with the real outside path limit in Path MTU. Use 1500 for a normal Ethernet IP path, 1492 for a PPPoE path when PPPoE has already reduced the usable IP MTU, or a measured path MTU when you have one. Then choose the preset closest to the overhead that still needs to be subtracted from that path value.


    
The default shape is intentionally conservative: a 1500-byte path, GRE over IPsec NAT-T on PPPoE, IPv4 payload, and an 8-byte safety reserve. That produces a smaller clamp than a plain GRE-only path, which is useful when the exact vendor padding or carrier handoff is still being confirmed.


    
    
      
  • Use Overhead Stack to audit the byte components before trusting the headline MSS.
    • 
      
  • Choose IPv6 payload before reading an IPv6 clamp, because the IP header subtraction changes from 20 B to 40 B.
    • 
      
  • Add Safety reserve for unknown padding, platform variance, or provider tags that may not appear in the visible preset.
    • 
      
  • Leave TCP option reserve at 0 for the normal clamp. Use a value such as 12 B only when you want a separate payload estimate with room for options.
    • 
      
  • Use MSS Overhead Curve when comparing several tunnel designs or explaining why a small extra tag can push a path into a tight MSS range.
    • 
    


    
The most important mistake is double-counting. If the path MTU already reflects PPPoE, VLAN, or provider overhead, do not subtract the same bytes again in the stack. If the platform reports a tunnel interface MTU instead of the underlay path limit, translate that number back to the actual budget you are modeling before using the clamp.


    
A practical next step is to compare TCP MSS clamp, DF ping payload, and Clamp Guidance. Clamp TCP at or below the reported value, keep ICMP Fragmentation Needed or Packet Too Big messages working where policy allows, and test the path with packet sizes that match the calculated probe payload.

  






  

    
Step-by-Step Guide:


    
    
      
  1. Enter Path MTU as the smallest outside path value before the overhead stack consumes bytes.
    2. 
      
  2. Select Encapsulation preset. If the built-in stack is close but not exact, edit Overhead stack; each row is a component name, byte count, and optional note.
    3. 
      
  3. Choose Payload IP version for the carried TCP flow. The MSS formula uses a 20 B IPv4 header or a 40 B IPv6 header.
    4. 
      
  4. Set Safety reserve only for uncertainty you want to keep out of the recommendation.
    5. 
      
  5. Open Advanced if you need TCP option reserve or want to change the Curve step used by the sensitivity table and chart.
    6. 
      
  6. Read MTU Ledger first. It shows path MTU, encapsulation overhead, safety reserve, effective IP MTU, headers, TCP MSS clamp, option-aware payload, and DF ping payload.
    7. 
      
  7. Check Overhead Stack for the running remaining MTU after each component.
    8. 
      
  8. Use Clamp Guidance, Overhead Curve Data, and JSON when you need an exportable record of the assumptions and result.
    9. 
    


    
If the summary shows Check inputs, No TCP room, IPv4 floor missed, IPv6 floor missed, or Tight MSS, slow down before copying the value into a device configuration. Those cues mean the selected stack either has an input issue, leaves too little payload space, or needs a lower-overhead design.

  






  

    
Interpreting Results:


    
Effective IP MTU is the inner packet budget after the explicit overhead stack and safety reserve are removed. TCP MSS clamp is the value most often copied into firewall, router, or tunnel policy for TCP flows that cross that path. Option-aware payload is more conservative when a TCP option reserve is set, but it is not the normal MSS value advertised by the main clamp row.


    

      

        
        
Status cueTriggerMeaningAction

        
          
Clamp readyNo errors, MSS at least 1200 B, and total reduction at or below 160 BThe modeled stack leaves a usable TCP clamp.Verify the byte assumptions, then test the path.

          
Heavy encapsulationTotal overhead plus reserve exceeds 160 BThe path is spending a large share of MTU on wrappers.Confirm nested tunnels, access overhead, and reserve bytes.

          
Tight MSSTCP MSS is below 1200 BTCP may still work, but payload efficiency and application behavior deserve review.Reduce overhead, raise path MTU, or test carefully.

          
IPv4 floor missed or IPv6 floor missedEffective MTU falls below the selected planning floorThe modeled inner MTU is below the expected payload-family boundary.Raise the path MTU or reduce the overhead stack.

          
No TCP roomThe effective MTU cannot cover the selected IP and base TCP headersNo usable TCP payload remains under the current assumptions.Fix the input stack before using the result.

        
      

    


    
DF ping payload is the ICMP echo payload budget at the calculated effective MTU. For IPv4 it subtracts a 20-byte IP header and 8-byte ICMP header; for IPv6 it subtracts a 40-byte IP header and 8-byte ICMP header. Real command syntax differs by operating system, so treat this row as the payload size to translate into your platform's ping or packet test command.


    
The result does not replace Path MTU Discovery. MSS clamping can reduce TCP black-hole symptoms, but non-TCP protocols and changing paths still depend on correct ICMP feedback or their own packetization logic. A clean result should lead to a targeted test, not an assumption that every application flow is covered.

  






  

    
Worked Examples:


    
A GRE over IPv4 tunnel on a 1500-byte path uses the GRE over IPv4 preset and no safety reserve. The stack subtracts 24 B, leaving an effective IPv4 MTU of 1476 B. The IPv4 TCP MSS clamp is 1436 B, because the calculation subtracts another 20 B IPv4 header and 20 B TCP header.


    
A VXLAN over IPv4 design with a 1500-byte path and 8 B safety reserve subtracts 50 B of VXLAN stack plus the reserve. The effective MTU is 1442 B. For an IPv4 payload, the TCP MSS clamp is 1402 B, and the DF ping payload is 1414 B.


    
The default combined GRE, IPsec NAT-T, and PPPoE stack subtracts 108 B, then subtracts the default 8 B safety reserve. A 1500-byte path therefore yields an effective IPv4 MTU of 1384 B and a TCP MSS clamp of 1344 B. That is still usable, but it is close enough to justify confirming actual ESP transform and access-link bytes.


    
For IPv6 payloads, the same effective MTU produces a smaller MSS because the IPv6 base header is 40 B. With the same 1384 B effective MTU, the IPv6 TCP MSS clamp becomes 1324 B. The change is not tunnel overhead changing; it is the payload IP header changing.

  






  

    
FAQ:


    
Is MSS the same as MTU?
No. MTU is a packet-size budget. MSS is the TCP data portion after IP and TCP headers are removed from that budget.

    
Why does IPv6 produce a smaller TCP MSS than IPv4?
The IPv6 base header is 40 B, while the IPv4 base header used here is 20 B. With the same effective MTU, IPv6 leaves 20 B less room for TCP payload.

    
Should I always include a safety reserve?
Use a reserve when the exact byte stack is uncertain. Use 0 when you are auditing exact documented overhead and want the formula result without extra conservatism.

    
Does MSS clamping fix UDP or QUIC packet size problems?
No. MSS clamping changes TCP behavior only. UDP, QUIC, ICMP, and similar traffic still need Path MTU Discovery, application sizing, or a smaller configured MTU.

    
Why can the IPsec preset be only an estimate?
ESP overhead changes with transform, IV or nonce size, tag length, padding, NAT traversal, and platform behavior. The preset is a planning value that should be checked against the actual VPN configuration.

    
What does the overhead curve add?
The curve shows how TCP MSS falls as total overhead rises. It is useful when comparing tunnel options or explaining how much margin remains around the current stack.

  






  

    
Glossary:


    

      
MTU
Maximum transmission unit, the largest packet size a link or path can carry at the modeled layer without fragmentation.

      
Path MTU
The smallest MTU across the route that matters for the traffic being carried.

      
Effective IP MTU
The inner IP packet budget after the modeled encapsulation overhead and safety reserve are subtracted.

      
TCP MSS
Maximum segment size, the TCP data payload limit after IP and TCP headers are accounted for.

      
Encapsulation overhead
Extra bytes added by a wrapper such as PPPoE, GRE, VXLAN, WireGuard, or IPsec.

      
PMTUD
Path MTU Discovery, the process that learns a path's largest usable packet size through packet-too-big feedback.

      
DF ping payload
An ICMP echo payload size that corresponds to the modeled effective MTU after IP and ICMP headers are removed.

    

  






  

    
References: