networkingtoolbox.net

Enter an IPv4 address with its prefix or mask (for example 192.168.1.10/24) into an IPv4 subnet calculator, and it returns the network address, broadcast address, subnet mask, wildcard mask, and usable host range in one step. This works for any IPv4 subnet you can express in CIDR or dotted-decimal form. You only need the address and either the prefix length or the mask — no binary math required.

What to enter

Most calculators accept either format, so pick whichever you already have:

• CIDR notation: 192.168.1.10/24 — the /24 is the prefix length.
• Address plus mask: 192.168.1.10 with 255.255.255.0.

If the tool has separate fields, put the host address in the IP field and the prefix or mask in its own field. The Networking Toolbox IPv4 Subnet Calculator is described as calculating "subnet masks, network addresses, broadcast addresses, and host ranges," so those are the outputs to expect.

A quick sanity check before you trust the result: the address you type is usually a host address inside the subnet, not the network address itself. If you enter the network address by mistake, the output still computes, but the "usable host range" may look off by one at the start.

Reading the output fields

The two boundary addresses — network and broadcast — are not assignable to hosts in a standard subnet. That is why a /24 gives 256 total addresses but only 254 usable ones.

How the prefix decides the range

The prefix length is the number of leading bits fixed as the network portion. The remaining bits are host bits, and usable hosts follow 2^(host bits) − 2.

So 192.168.1.10/25 sits in 192.168.1.0 – 192.168.1.127, with usable hosts 192.168.1.1 – 192.168.1.126 and broadcast 192.168.1.127. The same address under /24 lands in a different subnet — the prefix, not the address alone, defines the boundary.

Verify with a CIDR-to-mask conversion

Cross-check the calculator by converting the prefix to a mask and back:

1. Take the prefix (e.g. /26).
2. Convert it to dotted decimal (255.255.255.192) using a CIDR → Mask tool.
3. Re-enter the address with the mask form and confirm the network, broadcast, and host range match the CIDR result.

If the two disagree, you likely mistyped the prefix or mask. This check also catches the common error of using a mask that does not align to a valid prefix boundary (for example 255.255.255.100).

Common pitfalls

• Treating the network or broadcast address as a host. Assigning 192.168.1.0 or 192.168.1.255 to a device causes conflicts or unreachable hosts.
• Assuming the address defines the subnet. 10.0.0.5 is a host in 10.0.0.0/24 but also in 10.0.0.0/8 — the prefix decides.
• Forgetting /31 and /32 are special. They have no usable host range in the usual sense; /31 is for point-to-point links and /32 for a single host.
• Mixing up mask and wildcard mask. The wildcard is the bitwise inverse; use it only where the platform expects it (ACLs, OSPF, some firewalls).

Once you can read the network, broadcast, and host-range fields, you can size a subnet, pick an address for a device, or confirm whether two addresses share a subnet — all without hand-converting to binary.

Enter an address in CIDR form (for example 192.168.1.10/24) and an IPv4 subnet calculator returns four values you actually need: the network address, the broadcast address, the usable host range, and the subnet mask. On Networking Toolbox this is the IPv4 Subnet Calculator under the Subnetting section. The result is only valid if the prefix length matches the mask you intend to deploy — a /24 and a /25 on the same address produce different networks, so confirm the prefix before you copy anything into a device config.

What the calculator returns

The network and broadcast addresses are not assignable to hosts. A /24 holds 256 addresses, but only 254 are usable. Forgetting this is the most common reason a "free" address turns out to be taken.

Step by step

1. Get the address and prefix. Note the IP and the CIDR prefix, e.g. 10.0.5.37/26. If you only have a mask like 255.255.255.192, convert it first — the CIDR → Mask tool does this in both directions.
2. Enter them into the IPv4 Subnet Calculator. Input the address and prefix as one string.
3. Read the four outputs. Network address, broadcast address, host range, mask.
4. Verify before using. Check that the address you typed falls inside the returned host range. If it doesn't, you either mistyped the prefix or the address belongs to a different subnet.
5. Reuse the mask. Apply the returned mask to every device in that subnet; a mismatched mask between two hosts on the same wire causes intermittent, hard-to-diagnose failures.

CIDR prefix to mask, and back

The prefix is the count of leading 1 bits in the mask. Each octet is 8 bits, so the mapping is mechanical:

Usable hosts = total addresses − 2 (network + broadcast). This holds for every prefix except /31 and /32, which are special cases used for point-to-point links and single hosts.

Choosing a prefix from a host count

Work backwards from the number of devices you need to address:

• Need 50 hosts → the smallest block with ≥ 50 usable is /26 (62 usable). A /27 gives only 30, so it fails.
• Need 2 hosts on a router-to-router link → /30 is the standard fit.
• Need 200 hosts → /24 (254 usable).

Round up to the next larger block, never down. If you expect growth, size for the future count now — resizing a live subnet means re-addressing every host in it.

Splitting one range into several

When a single large block must serve multiple segments of different sizes, use the VLSM Calculator or Subnet Planner rather than splitting by hand. VLSM lets each sub-subnet take a different prefix length, so a /24 can become a /26 for a 50-host LAN, a /27 for a 30-host segment, and /30s for the links between them — without wasting a full /24 on each.

Related tools in the same section handle the rest of the workflow:

• Supernet Calculator — combine adjacent subnets into one summary route.
• IP Range to CIDR — turn a start/end pair into the CIDR blocks that cover it.
• CIDR Summarizer — collapse a list of prefixes into the fewest possible entries.
• Next Available Subnet / Free Space Finder — locate the next unallocated block in an existing plan.

When the result looks wrong

• Address not in the host range. You likely used the wrong prefix. Recheck whether the mask is /24 or /25 — one bit changes the whole block boundary.
• Two hosts can't reach each other. Compare their masks. Same-looking addresses with different prefixes can sit in different subnets.
• IPv4 vs IPv6 confusion. A /64 in IPv6 is not comparable to a /24 in IPv4. Use the IPv6 Subnet Calculator for v6 addresses; the host-count math is entirely different.
• "Usable" count off by two. You're counting the network and broadcast addresses. They are reserved.

Once the four outputs are confirmed, the mask and host range can be copied straight into your addressing plan or device configuration.

A CIDR prefix length such as /24 converts to a subnet mask by writing that many 1 bits, padding the rest with 0 bits, then splitting the 32-bit result into four 8-bit octets and converting each to decimal. /24 becomes 11111111.11111111.11111111.00000000, or 255.255.255.0. The same rule works for any prefix from /0 to /32, and you can verify a hand calculation with the CIDR → Mask converter on Networking Toolbox, which is described as converting CIDR notation (e.g. /24) to subnet mask format (255.255.255.0).

The conversion rule in one line

An IPv4 address is 32 bits. The CIDR prefix tells you how many of those bits are the network portion:

• First N bits = 1 (the network mask)
• Remaining 32 − N bits = 0 (the host portion)
• Group the 32 bits into four octets of 8 and convert each octet to decimal

For /26: 26 ones followed by 6 zeros → 11111111.11111111.11111111.11000000 → 255.255.255.192.

Step-by-step for /26

1. Write 26 ones: 11111111111111111111111111
2. Pad to 32 bits with zeros: 11111111111111111111111111000000
3. Split into octets: 11111111 .11111111 .11111111 .11000000
4. Convert each octet: 255 . 255 . 255 . 192
5. Result: 255.255.255.192

Common CIDR-to-mask reference

*Usable hosts = 2^(32−prefix) − 2, except /31 and /32, which are treated as special cases rather than following the −2 rule.

The pattern to memorize: each step past /24 halves the block and adds a bit to the last octet — 128, 192, 224, 240, 248, 252, 254, 255.

From mask to network, broadcast, and host range

Once you have the mask, you can derive the rest of the subnet with bitwise AND:

• Network address = IP AND mask
• Broadcast address = network address with all host bits set to 1
• Host range = network address + 1 through broadcast address − 1

Worked example: 192.168.10.130/26

1. Mask for /26 = 255.255.255.192
2. AND the IP with the mask:
   • 130 in binary = 10000010
   • 192 in binary = 11000000
   • AND = 10000000 = 128
3. Network address = 192.168.10.128
4. Host bits (6 of them) all set to 1 → last octet 10111111 = 191
5. Broadcast address = 192.168.10.191
6. Usable hosts = 192.168.10.129 – 192.168.10.190

Reverse: mask back to CIDR

To go the other way, count the consecutive 1 bits in the mask from left to right:

• 255.255.255.0 → 8 + 8 + 8 + 0 = /24
• 255.255.255.192 → 8 + 8 + 8 + 2 = /26
• 255.255.240.0 → 8 + 8 + 4 + 0 = /20

If the 1 bits are not contiguous — for example 255.255.255.1 or 255.0.255.0 — the mask is invalid and has no CIDR equivalent. This is a common typo to watch for when reading a mask from a device config.

Verifying with an online converter

The Networking Toolbox CIDR → Mask tool takes a prefix like /24 and returns the dotted-decimal mask, which is useful when you want a fast cross-check against your own arithmetic. The site also lists related subnetting tools — IPv4 Subnet Calculator, IPv6 Subnet Calculator, VLSM Calculator, Supernet Calculator, and Subnet Planner — plus CIDR utilities such as IP Range to CIDR, CIDR Summarizer, CIDR Split, and Wildcard Mask Converter, so you can move between prefix, mask, and range formats without redoing the math by hand.

A practical workflow:

1. Convert /N to a mask manually using the 1-bit rule.
2. Run the same prefix through the converter.
3. If the two disagree, recheck your octet grouping — the error is almost always in the last non-zero octet.

Common mistakes to avoid

• Counting from the wrong end. The 1 bits always start at the leftmost bit of the address, never the right.
• Assuming /31 and /32 follow the −2 rule. They don't; /31 is used for point-to-point links and /32 for a single host.
• Accepting a non-contiguous mask. If the ones aren't continuous, it isn't a valid subnet mask.
• Confusing the mask with the network address. The mask defines the boundary; the network address is the result of ANDing the mask with an IP.

DHCP tools are utilities that generate, convert, or validate the values you plug into a DHCP server — most commonly DHCP options such as the default gateway (Option 3) or vendor-specific data (Option 43). You use them when you need a correctly formatted option value before touching a live scope, or when a client isn't getting what it should and you want to rule out a syntax error. Networking Toolbox, for example, exposes a DHCP section with Option 3 (Default Gateway) and Option 43 (Vendor Specific) generators, alongside a broader set of IP, subnet, and DNS utilities. The steps below apply to any equivalent tool; the specific option names are standard across vendors.

What DHCP tools actually do

A DHCP server hands out more than an IP address. Each extra piece of configuration — gateway, DNS servers, boot file, vendor data — travels as a numbered option inside the DHCP reply. The option number and its data format are fixed by RFC, but the value is often vendor- or site-specific, which is where mistakes happen.

DHCP tools reduce that risk in three ways:

• Generation — build a correctly encoded value (for example, a hex string for Option 43) from human-readable input.
• Conversion — translate between formats, such as an IP list into the byte layout an option expects.
• Validation — check that a value parses before you commit it to a scope.

They do not configure your server for you. You still copy the output into your DHCP management interface.

The two options you'll reach for most

Option 3 — Default Gateway

Option 3 carries the router address a client should use for off-subnet traffic. It takes one or more IPv4 addresses in order of preference.

Use it when:

• You're building a scope and need the gateway value in the exact format your server expects.
• You have multiple routers and want to confirm the order clients will receive.

The tool's job is small but useful: it confirms the address is valid and formats it consistently, so a typo doesn't silently send clients to a dead gateway.

Option 43 — Vendor Specific

Option 43 is the standard container for vendor-defined data. It's most often used for wireless controller discovery: an access point boots, gets an IP via DHCP, reads Option 43, and learns which controller to join.

The catch is that every vendor encodes the controller address differently. Networking Toolbox's Option 43 generator lists Cisco, Aruba, Ruckus, and UniFi as supported targets — you pick the vendor, supply the controller IP (or addresses), and it produces the vendor-specific value.

Use it when:

• You're deploying APs that discover controllers via DHCP rather than DNS or broadcast.
• You're migrating controllers and need to update the advertised address.
• APs are stuck in a discovery loop and you suspect the option is malformed.

How to generate and apply a DHCP option

The workflow is the same whether you're doing Option 3 or Option 43.

1. Collect the input. For Option 3, the gateway IP. For Option 43, the controller IP(s) and the vendor/platform.
2. Run the generator. Enter the values and produce the output. For Option 43 this is typically a hex or vendor-formatted string; for Option 3 it's the address list.
3. Validate before applying. Re-read the output against your intended value — check digit groupings, address order, and that the vendor matches your hardware.
4. Apply to the scope. In your DHCP server, add or edit the option on the relevant scope (or globally, if all subnets share it). Paste the generated value.
5. Verify with a client. Renew the lease on a test client (ipconfig /renew on Windows, dhclient or nmcli on Linux) and confirm it received the option. For Option 43, the real test is whether the AP finds its controller.

A worked example: Option 43 for a controller

Say you have Cisco APs that need to find a controller at 10.20.30.40.

• Enter the controller IP and select Cisco as the vendor.
• The generator returns the vendor-specific value (Cisco encodes the controller IP as a hex string inside Option 43).
• Paste that value into the Option 43 field of the APs' DHCP scope.
• Reboot or re-lease an AP and watch whether it registers with the controller.

If the AP still can't find the controller, the option value is the first thing to re-check — a single wrong byte breaks discovery silently.

Troubleshooting with DHCP tools

When a client has an address but the wrong behavior, work through the option layer:

Two habits prevent most of these:

• Change one option at a time and test, so you know which edit caused a regression.
• Keep existing leases in mind. Clients that already hold a lease won't pick up a new option until they renew. If you need the change to take effect immediately, force a renew on the affected clients rather than assuming the edit propagated.

Where DHCP tools fit in a wider toolkit

DHCP options rarely exist in isolation. The addresses inside them come from subnets you've already planned, and the DNS servers you advertise are often the same ones you're testing elsewhere. Networking Toolbox groups these together: a Subnetting section (IPv4/IPv6 subnet calculators, VLSM, supernet), a DNS Tools section (record builders, SPF/DMARC policy builders, DNSSEC helpers), and a CIDR section (range-to-CIDR, summarizer, splitter). If you're building a scope from scratch, plan the subnet first, then generate the DHCP options that point clients at the right gateway and services.

Choosing a DHCP tool

Any tool that produces a standards-correct option value will do. Pick one that:

• Names the vendors it supports for Option 43 — generic hex output is easy to get wrong.
• Shows you the value it will emit so you can sanity-check it.
• Covers the options you actually use — Option 3 and 43 are the common ones, but boot-related and DNS options matter in some networks.

Networking Toolbox's DHCP section is small (Option 3 and Option 43) but sits next to the subnet and DNS utilities you'll need to fill in the rest of a scope. For a one-off Option 43 conversion, it's enough; for a full scope design, treat it as one part of the workflow rather than the whole thing.

Network tools are small, single-purpose utilities that answer one question at a time: what subnet does this IP belong to, does this DNS record resolve correctly, what TLS certificate is this server presenting. Networking Toolbox groups them into five working categories — subnetting and CIDR, DNS and lookups, DHCP option builders, TLS/HTTP diagnostics, and record generators. Pick the category that matches your task, not the tool with the most features.

The five categories and what each one answers

The distinction that matters most: calculators and builders produce a value you will use, while lookup and diagnostic tools report what already exists. If you need a number to type into a config, you want the first kind. If you need to know whether something is broken, you want the second.

Matching a task to a tool

"I have an IP and a prefix, and I need the host range"

Use the IPv4 Subnet Calculator. It returns the subnet mask, network address, broadcast address, and usable host range in one pass. This is the right tool when you are planning an allocation or checking whether two addresses can talk to each other without a router.

"I have CIDR notation and need dotted-decimal"

Use the CIDR → Mask converter. It takes /24 and returns 255.255.255.0. Do not confuse this with a wildcard mask — /24 becomes 255.255.255.0 as a subnet mask but 0.0.0.255 as a wildcard. The Wildcard Mask Converter handles the second case, and mixing the two up is one of the most common configuration errors in ACLs and routing statements.

"I need to know if a DNS change has taken effect"

Use the DNS Propagation Checker, then confirm with the DNS Lookup tool against a specific resolver. A propagation checker shows you what different resolvers currently return; it does not tell you what should be returned. If the record is wrong everywhere, the problem is in your zone, not in propagation.

"I'm configuring a wireless controller to find its management platform"

Use Option 43 – Vendor Specific. It generates the vendor-specific DHCP option for Cisco, Aruba, Ruckus, and UniFi controllers. This is a builder, not a lookup — you take the output and paste it into your DHCP server.

"I need to check whether a certificate or port is behaving"

Use the TLS Certificate Analyzer for chain and expiry details, the TLS Handshake Analyzer for negotiation behavior, and the TCP Port Checker for reachability. These are read-only diagnostics: they tell you the current state and leave the fix to you.

Lookup tool or configuration builder?

Ask one question: am I discovering something or producing something?

• Discovering → DNS Lookup, Reverse DNS Lookup, RDAP Lookup, BGP Route Lookup, ASN & Geolocation Lookup, CT Log Search, Service Banner Grabber.
• Producing → SPF Policy Builder, DKIM Key Generator, DMARC Policy Builder, CAA Record Builder, TLSA Generator, SSHFP Generator, SVCB/HTTPS Builder, Reverse Zone Generator.

A builder's output still needs verification. After generating an SPF record, run it through the SPF Record Evaluator to confirm it parses and stays under the lookup limit. After generating a DKIM key, check the DNS record with the DNS Record Validator. The generator gives you syntax; the validator tells you whether the syntax works.

Verifying results

Cross-check anything you plan to commit to a config. Two habits cover most cases:

1. Confirm with a second tool in a different category. A subnet calculator's host range can be checked against the IP Range to CIDR tool run in reverse, or against ipcalc on the command line.
2. Confirm with a resolver or server you control. A DNS Lookup against your own resolver is more authoritative for your environment than a public propagation checker.

For DNS specifically, the DNSSEC Validation Chain and DNSSEC AD Flag Checker answer different questions — the first shows the chain of trust, the second shows whether a validating resolver actually set the authenticated-data flag. A record can have a complete chain and still fail validation at the resolver.

Common pitfalls

• CIDR mask vs. wildcard mask. /24 is 255.255.255.0 as a subnet mask and 0.0.0.255 as a wildcard. Check which one your platform expects before pasting.
• Reading propagation as truth. A propagation checker shows cached answers from many resolvers. Old answers are expected during a TTL window; they are not evidence of a misconfiguration.
• Trusting a generator's output without validating. Builders produce syntactically plausible records. Zone Linter and DNS Record Validator catch the cases where plausible is not correct.
• Using a lookup tool to plan. RDAP and BGP lookups describe current allocation and routing. They are not planning tools — for allocation planning, use the Subnet Planner or CIDR Allocator.

Where to start

If you are new to the toolbox, start with the IPv4 Subnet Calculator and the CIDR → Mask converter — they cover the most frequent day-to-day questions and build the vocabulary the rest of the tools assume. Move to the DNS Lookup and DNS Propagation Checker once you are working with records, and to the TLS and HTTP analyzers when you are debugging a live service. The DHCP option builders and record generators are best used once you already know which option or record type you need.