user@netcalc ~/calc $
ipv4_calculator
Calculate network, broadcast, mask, hosts, class and binary for any IPv4 address
ip:
mask:
✓ stdout — ipv4_calculator
Enter runs the calculation · Shift+Enter inserts a new line
user@netcalc ~/calc $
ipv6_calculator
Calculate network info for IPv6 addresses in CIDR notation
ipv6:
pfx:
✓ stdout — ipv6_calculator
user@netcalc ~/calc $
vlsm_calculator
Variable Length Subnet Mask — assigns optimal blocks for each network segment
net:
pfx:
// Subnets required
name:
hosts:
name:
hosts:
name:
hosts:
✓ stdout — vlsm_calculator
| # | Name | Hosts Req | Hosts Avail | Prefix | Network | First Host | Last Host | Broadcast | Mask |
|---|
user@netcalc ~/calc $
usable_ip_range
Shows the exact usable host range for a given network
ip:
mask:
✓ stdout — usable_ip_range
user@netcalc ~/calc $
binary_ip_calc
Convert IP addresses to binary and vice versa, with per-octet visualization
dec:
bin:
✓ stdout — binary_ip_calc
user@netcalc ~/network $
cidr_converter
Convert between CIDR, decimal mask and wildcard. Includes full /1–/32 reference table.
in:
✓ stdout — cidr_converter
📋 CIDR Reference Table
| CIDR | Subnet Mask | Wildcard | Hosts | /24 subnets | Block |
|---|
user@netcalc ~/network $
wildcard_mask_calc
Calculate the wildcard (inverse) mask for Cisco ACLs, OSPF and firewall rules
mask:
✓ stdout — wildcard_mask_calc
user@netcalc ~/network $
supernet_calculator
Find the minimum supernet containing all specified networks (route summarization)
nets:
✓ stdout — supernet_calculator
user@netcalc ~/network $
subnet_splitter
Split a network into equal subnets by specifying a new prefix
net:
mask:
new:
✓ stdout — subnet_splitter
| # | Network | First Host | Last Host | Broadcast | Hosts | Mask |
|---|
user@netcalc ~/network $
range_to_cidr
Convert an IP range (start–end) to the minimum set of CIDR blocks
start:
end:
✓ stdout — range_to_cidr
| # | CIDR Block | Network | Broadcast | Hosts |
|---|
user@netcalc ~/network $
ip_to_integer
Convert IPv4/IPv6 addresses to integer and vice versa
ip:
int:
✓ stdout — ip_to_integer
user@netcalc ~/network $
ipv6_normalize
Expand and compress IPv6 addresses — normalize any valid format
ipv6:
✓ stdout — ipv6_normalize
user@netcalc ~/network $
hex_ip_converter
Convert between hexadecimal and IP address — useful for Windows route tables and Cisco logs
ip:
0x:
✓ stdout — hex_ip_converter
user@netcalc ~/network $
vlan_calculator
802.1Q VLAN info: tag encoding, PCP, DEI, VID, range and compatibility
vlan:
pcp:
dei:
✓ stdout — vlan_calculator
user@netcalc ~/dns $
reverse_dns_generator
Generate the PTR in-addr.arpa zone for an IPv4 network
net:
pfx:
dom:
✓ stdout — reverse_dns_generator
user@netcalc ~/dns $
ipv6_ptr_generator
Generate the PTR ip6.arpa record for an IPv6 address
ipv6:
host:
✓ stdout — ipv6_ptr_generator
user@netcalc ~/dns $
ip_geolocation
Locate a public IP or resolve a domain and geolocate its public address
Domains are resolved through DNS first; geolocation is based on the resulting public IP.
geo:
✓ stdout — ip_geolocation
user@netcalc ~/dns $
ip_address_planner
Interactive IP address space planner — click cells to edit, export to CSV
📋 IP Address Plan
| # | Name | Network | Mask/CIDR | Gateway | VLAN | Location | Notes |
|---|
user@netcalc ~/legal $
Privacy
Data stored in your browser
Theme, language, promotion dismissal and calculation history are stored in localStorage on this device.
Calculations
Calculations are sent through this site's same-origin Worker proxy to the private calculation service.
Performance metrics
LCP, CLS and INP may be stored as aggregate performance measurements by tool and language. Calculation inputs and persistent user identifiers are not included.
GeoIP
Only GeoIP lookups are processed by an external provider. The requested IP address is sent for that lookup.
Issue reports via Telegram
A report link opens the public Telegram bot and includes only the current page slug in the bot start parameter. Calculator inputs and report text are not sent by this website. Text you choose to send inside Telegram is handled by Telegram and the bot.
Cookies and advertising
Advertising is controlled by the production configuration. When Google AdSense is enabled, consent is handled through a certified CMP before personalized advertising is used where required.
Delete local data
Use the button below to clear calculation history. To remove every local preference, clear this site's data in your browser settings.
This page provides operational information; it is not a legal-compliance certification.
MTU for PPPoE, GRE, WireGuard and tunnels
Work out effective MTU for common encapsulation stacks and avoid fragmentation or hidden throughput problems.
01
Start with the real layer-3 ceiling
MTU planning starts with the actual IP packet size the lower layer can carry, not with a memorized number. Ethernet is commonly 1500 bytes, while PPPoE consumes 8 bytes before adding any tunnel overhead. GRE, IPsec, WireGuard and other encapsulations then reduce the payload ceiling further.
02
Add overhead once, in the right order
Write the encapsulation stack from outermost transport to innermost payload and account for each header only once. A tunnel running across PPPoE inherits the PPPoE reduction first; the tunnel does not magically restore the lost bytes. The safest design is to verify the platform’s exact header sizes and then test with packets that set DF.
03
Relate MTU to TCP MSS
TCP MSS describes TCP payload, not the complete IP packet. A common IPv4 estimate subtracts 20 bytes for the IPv4 header and 20 for TCP from the effective MTU; IPv6 has a larger base header. Options can change the final number, so MSS clamping should be treated as an interoperability tool rather than a substitute for understanding the path MTU.
04
Validate the path after calculation
A calculated value is a starting point. Confirm that large packets cross the real path, watch for ICMP Packet Too Big / Fragmentation Needed messages, and check application behavior such as HTTPS, VPN and large uploads.
05
Account for variable overhead and protocol details
Header overhead is not always a single fixed constant. IPv4 versus IPv6, GRE options, UDP versus TCP, encryption tags, padding and tunnel implementation choices can change the effective packet size. Treat calculator values as a model of the selected stack, then confirm the exact encapsulation used by the devices at both ends.
06
Recognize black-hole MTU and asymmetric paths
A broken path often passes small pings and DNS while HTTPS, uploads or VPN sessions stall when packets grow. Asymmetric routing can make the problem one-directional: the forward path may carry 1492 bytes while the return path crosses a lower-MTU tunnel. Troubleshooting therefore needs packet-size tests in both directions.
07
Turn the result into an operational baseline
Record the underlay MTU, tunnel MTU, expected TCP MSS and the test command that proves the path. Keeping these values beside the tunnel configuration makes later changes safer, especially when a new encapsulation layer, provider handoff or VPN is introduced.
EX
Worked example
- Start from an Ethernet underlay of 1500 bytes and add PPPoE, leaving 1492 bytes for IP.
- Place a tunnel on top and subtract its real outer headers; for a WireGuard-style path the effective inner MTU may land around the low 1400s depending on IP version.
- For IPv4 TCP, subtract the IP and TCP headers from the effective MTU to estimate the advertised MSS.
- Probe the real path with DF / Packet Too Big feedback and repeat the test in the reverse direction.
✓
Operational checklist
- Confirm underlay MTU at every routed boundary.
- Write down each encapsulation layer once and only once.
- Test TCP and at least one non-TCP flow.
- Monitor ICMP PTB / Fragmentation Needed instead of filtering it blindly.
Tools to apply it
Standards and references
🕐 History