Docs

MTU configuration

This page lets you verify that the customer network can carry a maximum-size service datagram without avoidable fragmentation.

Before you start

Know the receiver interface, destination UDP port, and any tunnel or overlay in the path.
Have permission to inspect interface configuration and packet captures.
Allow UDP from 64.130.40.90 so live packets can reach the observation point.

Start from the UDP payload maximum

The documented maximum service payload is ${WIRE.maxPacketBytes} bytes. Size the path from that maximum, not from the 1,216 byte measured mean.

For IPv4 without options, add 8 bytes for the UDP header and 20 bytes for the IPv4 header. A maximum service payload therefore produces a 1,256 byte IPv4 packet before link-layer framing. A link IP MTU of at least 1,256 bytes carries that packet without IP fragmentation under those conditions.

The documented service source is IPv4 address ${SOURCE_IP}. Supported customer destination address families are not currently specified. If an IPv6 delivery path becomes supported, its normal 40 byte IP header would produce 1,276 bytes before link-layer framing for the same UDP payload.

Keep the size layers distinct

Application payload, UDP datagram, IP packet, and link frame are different sizes. The service maximum applies to the bytes returned as the UDP payload. Packet-capture tools can display an IP length or full frame length instead.

Use these unencapsulated calculations:

text

service UDP payload: 1228 bytes
UDP header:             8 bytes
IPv4 header:           20 bytes without options
IPv4 packet:         1256 bytes

Ethernet adds framing outside the IP MTU and is not included in the 1,256 byte result. VLANs, tunnels, VPNs, overlays, IPv4 options, and other encapsulation add their own overhead or reduce the inner MTU available to the service packet.

Inspect the receiving host

List interface MTUs on Linux:

bash

ip -br link

Identify the interface or tunnel that receives the translated destination. A displayed MTU of 1,500 bytes is larger than the 1,256 byte unencapsulated IPv4 requirement. A displayed inner MTU below 1,256 bytes cannot carry the maximum service payload as one unfragmented IPv4 packet.

Inspect the route selected toward the documented source:

bash

ip route get 64.130.40.90

This command shows the host's outbound route toward the source and can identify the local interface, but it does not prove the inbound internet path is symmetric. Use it to find local policy and tunnel choices, not as an end-to-end delivery guarantee.

Observe live packet sizes

Replace 9000 with the registered port and capture packet metadata:

bash

sudo tcpdump -n -i any -vv -c 100 'src host 64.130.40.90 and udp dst port 9000'

Read the IP and UDP lengths reported by the installed tcpdump version. Confirm which layer each displayed length describes before comparing it with ${WIRE.maxPacketBytes}. Do not print binary payloads for this check.

Look for IPv4 fragmentation indicators in a focused capture:

bash

sudo tcpdump -n -i any -vv -c 100 'src host 64.130.40.90 and (ip[6:2] & 0x3fff > 0)'

This classic BPF expression matches IPv4 packets with the more-fragments flag or a nonzero fragment offset. It is intentionally limited to the documented IPv4 source. An empty sample does not prove fragmentation never occurs; it shows none matched during that bounded observation.

Account for tunnels and overlays

Calculate the inner MTU exposed to the receiver after every encapsulation layer. Do not subtract an assumed tunnel overhead without checking the deployed mode. Overhead for WireGuard, IPsec, GRE, VXLAN, cloud overlays, and VLAN combinations depends on address family and options.

The product does not currently specify supported tunnel types, required tunnel settings, a path-MTU discovery method, or a fragmentation policy. The service's setting of the IPv4 don't-fragment flag is not currently specified.

When the inner interface reports at least 1,256 bytes, the documented maximum fits under normal IPv4 header conditions. When the inner MTU is lower, raise it if the full outer path permits, reduce encapsulation overhead, or change the customer network design. The sender's payload size is not customer-configurable under the documented product facts.

Avoid invalid active tests

A local ping or outbound UDP probe tests a customer-to-remote direction. It does not reproduce a datagram sent from ${SOURCE_IP} through the actual delivery path. ICMP handling, route symmetry, and endpoint behavior can differ.

Do not spoof ${SOURCE_IP} to test the firewall or MTU. Use the real verification challenge and live feed as the authoritative inbound traffic. Request a challenge resend when activation testing needs one new packet.

Do not lower a production interface MTU merely to provoke fragmentation without an approved change plan. That mutation can affect unrelated traffic and is not required for diagnosis.

Monitor symptoms at each layer

Count received UDP payload lengths in the application. Count fragmented IP packets at the capture point. Count reassembly failures and UDP receive errors from the operating system. Compare the counters over the same UTC interval.

A packet visible as fragments at the edge but absent after reassembly points to the customer network or host reassembly path. A complete packet visible to tcpdump but absent from the process points to firewall, socket, namespace, or receive-queue behavior instead.

The maximum payload is a contract boundary, not a statement that every datagram reaches that length. Retain support for all observed lengths up to ${WIRE.maxPacketBytes}. Minimum payload size and packet-size distribution are not currently specified.

Record the deployed MTU design

Record the public interface MTU, tunnel outer MTU, tunnel inner MTU, encapsulation type, destination port, capture result, and fragmentation counter. Recheck these values after changing a VPN, overlay, cloud interface, NAT gateway, or host network.

A required MTU monitoring interval and alert threshold are not currently specified. Select them according to the customer's loss tolerance and network-change process.

Parameters

Name	Type	Default	Notes
maximum service payload	bytes	1228	Use this value for receive and MTU sizing.
unencapsulated IPv4 packet size	bytes	1256	Assumes an 8 byte UDP header and a 20 byte IPv4 header without options.
inner path MTU	bytes	not currently specified	Customer-configured value that must account for deployed encapsulation.
destination port	UDP port	none	Use the registered port in packet-capture filters.

When it goes wrong

Large datagrams disappear while smaller ones arrive. Example error: `IP reassembly failed`.

Cause. The effective inner MTU is too small or the path drops IPv4 fragments.

Fix. Inspect fragmentation, raise the inner MTU when the outer path permits, or reduce customer tunnel overhead.

The application reports truncation. Example error: `MSG_TRUNC: 1228 bytes`.

Cause. The application receive buffer is too small, which is separate from network MTU.

Fix. Allocate at least 1228 bytes for each UDP receive and retain the returned length.

An MTU probe succeeds but delivery still fails. Example error: `receiver idle: 0 datagrams`.

Cause. The outbound probe did not test the actual inbound route, source filter, or verified destination.

Fix. Capture real inbound traffic from 64.130.40.90 and inspect the dashboard pair, firewall, NAT, and socket.

Questions

What MTU carries the largest IPv4 service datagram?: An unencapsulated IPv4 path needs an IP MTU of at least 1,256 bytes for a ${WIRE.maxPacketBytes} byte UDP payload, assuming an 8 byte UDP header and 20 byte IPv4 header without options. Tunnels and overlays reduce available inner MTU or add outer overhead, so inspect the deployed interfaces.
Is a 1,500 byte Ethernet MTU sufficient?: It is larger than the 1,256 byte unencapsulated IPv4 packet calculated for the documented maximum payload. That comparison does not account for an inner tunnel interface with a lower MTU, unusual IP headers, or other encapsulation. Inspect the effective receiver path and capture real datagrams from ${SOURCE_IP}.
Does shredstream.sh guarantee no IP fragmentation?: A fragmentation policy and don't-fragment setting are not currently specified. The documented maximum lets customers calculate the normal unencapsulated requirement. Observe real inbound IPv4 fragments, reassembly errors, and UDP payload lengths, especially when the path includes a VPN, overlay, or other encapsulation with a reduced inner MTU.