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 para PPPoE, GRE, WireGuard y túneles
Calcula la MTU efectiva de encapsulaciones habituales y evita fragmentación o problemas de rendimiento difíciles de detectar.
01
Empieza por el techo real de capa 3
La planificación de MTU parte del tamaño real de paquete IP que puede transportar la capa inferior, no de un número memorizado. Ethernet suele usar 1500 bytes, mientras que PPPoE consume 8 bytes antes de añadir overhead de túneles. GRE, IPsec, WireGuard y otras encapsulaciones reducen todavía más el payload disponible.
02
Suma el overhead una sola vez y en el orden correcto
Escribe la pila de encapsulación desde el transporte exterior hasta el payload interior y contabiliza cada cabecera una sola vez. Un túnel que viaja sobre PPPoE hereda primero la reducción de PPPoE; el túnel no recupera esos bytes. Lo más seguro es verificar los tamaños exactos de cabecera de la plataforma y después probar paquetes con DF.
03
Relaciona MTU y TCP MSS
TCP MSS describe el payload TCP, no el paquete IP completo. Una estimación IPv4 habitual resta 20 bytes de cabecera IPv4 y 20 de TCP a la MTU efectiva; IPv6 tiene una cabecera base mayor. Las opciones pueden cambiar el número final, por lo que el MSS clamping debe verse como herramienta de interoperabilidad y no como sustituto de entender la MTU del camino.
04
Valida el camino después del cálculo
El resultado calculado es un punto de partida. Confirma que los paquetes grandes atraviesan el camino real, observa mensajes ICMP Packet Too Big / Fragmentation Needed y prueba comportamientos de aplicación como HTTPS, VPN y subidas grandes.
05
Ten en cuenta overhead variable y detalles de protocolo
El overhead no siempre es una constante única. IPv4 frente a IPv6, opciones GRE, UDP frente a TCP, etiquetas de cifrado, padding y decisiones de implementación pueden cambiar el tamaño efectivo. Usa el cálculo como modelo de la pila seleccionada y confirma la encapsulación real de ambos extremos.
06
Reconoce black-hole MTU y caminos asimétricos
Un camino roto suele permitir pings pequeños y DNS mientras HTTPS, subidas o VPN se bloquean cuando crece el paquete. El routing asimétrico puede hacerlo unidireccional: la ida puede admitir 1492 bytes y la vuelta atravesar un túnel con menor MTU. Hay que probar tamaños en ambos sentidos.
07
Convierte el resultado en una referencia operativa
Documenta MTU del underlay, MTU del túnel, MSS TCP esperado y el comando de prueba que demuestra el camino. Guardar estos valores junto a la configuración reduce riesgos cuando se añade otra encapsulación, cambia el proveedor o aparece una nueva VPN.
EX
Ejemplo trabajado
- Parte de un underlay Ethernet de 1500 bytes y añade PPPoE, quedando 1492 bytes para IP.
- Coloca el túnel encima y resta sus cabeceras externas reales; en un camino tipo WireGuard la MTU interior puede quedar en la zona baja de 1400 según la versión IP.
- Para TCP sobre IPv4 resta las cabeceras IP y TCP a la MTU efectiva para estimar el MSS anunciado.
- Prueba el camino real con DF / Packet Too Big y repite el test en sentido inverso.
✓
Checklist operativo
- Confirma la MTU del underlay en cada frontera enrutada.
- Anota cada capa de encapsulación una sola vez.
- Prueba TCP y al menos un flujo no TCP.
- Monitoriza ICMP PTB / Fragmentation Needed en lugar de filtrarlo sin criterio.
Herramientas para ponerlo en práctica
Estándares y referencias
🕐 History