Welcome

The networking tools on this site are intended to help you become a more effective network engineer. They provide quick and easy insights into the subnet data structures engineers work with every day. Common tasks such as identifying overlapping address space, determing what prefix is common between two subnets, or how many possible routes a prefix-list could potentially permit from a BGP neighbor are simplified. We hope you find the tools useful and invite your feedback.
Check back often. New tools are in the works, and the existing ones are constantly improved.

Subnet Like a Champ

Check out our new How to Subnet page to take you from zero to hero

IP Subnet Tools

A graphical subnet calculator that displays information such as size, mask and wildcards. The tool plots the subnet's relationship to other subnets, including summary networks, adjacent networks that share the same mask, and child subnets. Each subnet is clickable, allowing users to navigate through subnet relationships. The tool answers questions like, "What are all the possible summary routes this subnet could have?" or "What are all of the subnets that belong to this CIDR block?" The calculator supports both IPv4 and IPv6 subnets.

A bit map is also included, with the mask presented as a bar over the subnet bits. Host bits are shown in grey. Users may select "clasful" information that will provide additional information such as the class bits, borrowed bits.

List of subnets and prefixes show up frequently in networking. This tool helps manage these lists by providing four useful features.

• Sorting: Listing subnets in their natural order makes it easier to find a specific subnet. Sorted lists also make it easier to compare two lists.


• Overlapping Subnets: Identify where two elements in the list may cover the same subnet. Overlapping and adjacent subnets are also shown as a prefix list element. Consider the list of subnets:
  
  192.168.0.0/24
  192.168.1.0/24
  192.168.1.128/25
  
  This list is already sorted. From here, we can tell that 192.168.0.0/24 and 192.168.1.0/24 share the 23 bits and can be summarized as 192.168.0.0/23. This will also cover the more specific 192.168.1.128/25. In a prefix list, this can be represented as:
  192.168.0.0/23 le 25
  If you were trying to use an access-list to cover these three prefixes, you would write:
  192.168.0.0 0.0.1.255
  The advantage that a prefix list has over an access-list is that the access list will permit all masks more specific than the 23. Only the prefix list can explicitly limit the mask size between /23 and /25


• Translate formats: Convert a list of subnets between various formats such as CIDR, mask or wildcard format.
  Let's say you had an existing Cisco access-list that your are using as an inbound route filter on a BGP peer and wanted to convert into a prefix-list. At first glance, you may not notice two adjacent subnets that can be combined, and one overlapping subnet that can be removed.
   

  Tool Input text

  ip access-list standard bgp-inbound
  

  permit 10.81.68.0 0.0.3.255

  permit 10.81.102.0 0.0.1.255

  permit 10.81.111.0 0.0.0.255

  permit 10.81.117.0 0.0.0.255

  permit 10.81.121.88 0.0.0.3

  permit 10.81.103.0 0.0.0.255

  permit 10.81.122.0 0.0.1.255

  permit 10.115.136.0 0.0.3.255

  permit 10.122.120.0 0.0.3.255

  permit 10.225.192.0 0.0.3.255

  permit 10.225.200.64 0.0.0.63

  permit 10.225.201.0 0.0.0.255

  permit 10.225.202.0 0.0.1.255

  permit 10.225.196.0 0.0.3.255
  You can copy and paste the complete output into the tool. The tool will "grep" out the address from the other text, providing the following three columns:
   

  Tool Output text

  Covered IPs: 7492

  
  

  Prefixes (12)

  10.81.68.0/22
  10.81.102.0/23 le 24
  10.81.111.0/24
  10.81.117.0/24
  10.81.121.88/30
  10.81.122.0/23
  10.115.136.0/22
  10.122.120.0/22
  10.225.192.0/21 le 22
  10.225.200.64/26
  10.225.201.0/24
  10.225.202.0/23

   

  
  

  Summaries (12)

  10.81.68.0 255.255.252.0
  10.81.102.0 255.255.254.0
  10.81.111.0 255.255.255.0
  10.81.117.0 255.255.255.0
  10.81.121.88 255.255.255.252
  10.81.122.0 255.255.254.0
  10.115.136.0 255.255.252.0
  10.122.120.0 255.255.252.0
  10.225.192.0 255.255.248.0
  10.225.200.64 255.255.255.192
  10.225.201.0 255.255.255.0
  10.225.202.0 255.255.254.0

   

  
  

  Subnets (14)

  10.81.68.0/22
  10.81.102.0/23
    ∟‐10.81.103.0/24
  10.81.111.0/24
  10.81.117.0/24
  10.81.121.88/30
  10.81.122.0/23
  10.115.136.0/22
  10.122.120.0/22
  10.225.192.0/22
  10.225.196.0/22
  10.225.200.64/26
  10.225.201.0/24
  10.225.202.0/23

  Column 1: will provide the prefix list elements that would cover the ACL. In this case, one overlapped subnet (10.81.103.0/24) was combined with the parent (10.81.102.0/23) resulting in a prefix element (10.81.102.0/23 le 24)
  
  
  Column 2: translates the wildcards into subnets that could be used to define summary routes. Overlapping subnets are removed. Adjacent subnets are combined into a summary
  
  
  Column 3: returns all of the original subnets, sorted. Overlapping routes are shown under their parents. This could be more than one level deep. For example, if (10.81.103.192/26) had been in the input list, it would appear as a child subnet of 10.81.103.0/24 and of course, the prefix element shown in column 1 would become 10.81.102.0/23 le 26. Also note this column has 14 subnets, versus 12 prefixes in column 1 due to the optimization of the list.
  
  
  You can also convert subnets into wildcards by choosing the wildcard format. In the next example, we take EIGRP summary routes that we'd like to convert into an ACL format. We select the column 2 output to be in a wildcard format.
  Sumaries as wildcards (IPv4)
  Then we input the snippet of the configuration that we includes the subnets we are going to convert. In this case, the subnet have the mask in dot notation.

  Tool Input text

  ip summary-address eigrp 1 10.81.68.0 255.255.252.0

  ip summary-address eigrp 1 10.81.102.0 255.255.254.0

  ip summary-address eigrp 1 10.81.111.0 255.255.255.0
   

  Tool Output text

  Covered IPs: 1792

   

  Prefixes (3)

  10.81.68.0/22
  10.81.102.0/23
  10.81.111.0/24

  Summaries (3)

  10.81.68.0 0.0.3.255
  10.81.102.0 0.0.1.255
  10.81.111.0 0.0.0.255

  Subnets (3)

  10.81.68.0/22
  10.81.102.0/23
  10.81.111.0/24

Many networks attempt to standardize the number of unique branch topologies, or models. This tool imagines three possible branch models; small, medium and large. Although the naming is a convience and arbritary since the tool doesn't check that a small branch actually holds less address space than a large branch. Define how many of each branch type there are, and create a model that declares the amount of address space that each type of branch requires. The model describes how many point to point links need address space. For IPv4, cross-link subnets are allocated with a /30 which provides 2 usable IP addresses. Although it is possible to assign /31 subnets, the initial release of the tool prefers /30s. For IPv6, all assignments are /64. VLANs are then defined for each branch model. You can add as many VLANs as required to each model. Typical VLAN examples might be Data, Voice, IoT, or Guest. Each VLAN will be of a specific size based on the expect host count for that model. The tool will determine the correct subnet to cover that size for IPv4. Again, a /64 is used for all IPv6 assignments.

Although three different profiles are provided, you don't have to use all three. You can leave unused templates blank.

You must also provide an IPv4 or IPv6 anchor block that can be used as a pool for address assignments. For dual stack networks, both can be defined. The allocation will include aggregate addresses for each branch, and each branch will also have an aggregate address for the /30 subnets. This can help keep infrastructure address space distinguishable from service assigned address space.

There is also a pattern tool that provide greater flexibility in distributing address space

Subnets are sized to cover a number of IP addresses. Because subnets are on bit boundaries, their sizes are oriented around powers of 2. Common sizes are 64, 128, 256, 512. Sizing subnets can be a bit of an art. It's easy enough if you need about 250 addresses. But what about if you need 260 addresses. The next bit boundary results in an allocation of 510 useable addresses. This tool will give you an exact breakdown of the subnets needed to cover a specific number of addresses. Another common question is "what mask would I need to cover 42 addresses?" To answer this question set the largest subnet to a mask of 1. Then adjust the mask of the smallest mask until the efficiency exceeds 50% without creating two allocations.

The subnet allocation can be given in either CIDR to dotted mask notation depending on the required format.

This tool can also generate subnets and populated configuration templates. This can be useful if you need to quickly create a configuration with many static routes, or loopback interfaces. For the static route example, using Cisco command syntax, the template would be:

Then as an example, you could create 10 static routes by setting the ip count at 2560 and setting both the min an max mask size to 24 and selecting both the Mask and use template options. If you wanted 20 routes, set the min and max mask to 25.

You can also create interface templates, for example:

To keep things interesting, the min and max mask are set to 27 to give subnets of 32 IPs each since 2^(32-27) = 32, and we will allocate for 160 IPs in total giving us 5 loopback interfaces.

Its not uncommon to use NAT as a go-between for IPv4 and IPv6 domains. For example, if an IPv6 only device needs to reach an IPv4 only server. RFC6052 recommends a standard way to embed the IPv4 address inside an IPv6 address from various bit positions, and offers a well-known IPv6 prefix 64:ff9b::/96. Network administrators may also use assigned IPv6 space. This tools supports either.

Another novel use includes creating a mapping schema between IPv4 and IPv6 subnets to help maintain alignement between L3 defined policy such as ACLs or prefix-filters. Because IPv6 is 128 bits, and IPv4 is 32 bits, it is possible to create an address scheme where some portion of the address plan is directly mapped by imbedding the relevant IPv4 bits into the IPv6 address. It's not necessary a complete mapping. But it can make sense on user segments where there is an applied security. Mapping, along with some automation, can allow an IPv4 and IPv6 ACL to be compared. The embedding tool makes it easy to look at this bit mapping. For example, you may want to explore only mapping /24 bits into the IPv6 address, starting at an offset of 40.

Use the IPv6 subnet imbedder tool

When designing networks, there are common patterns that show up in the topology. For example, a small branch might have a single WAN router that services one or two vlans. A large branch might have two wan gateways, a service aggregation layer, and many vlans. These are design patterns that are repeated through the network. The address plan likely allocates address space around these patterns. There are campus patterns, datacenter patterns, etc. These patterns are stitched together to form the complete network. An ansible playbook could be leveraged. This tool allows a yaml data model to describe a specific pattern, and then allocates address space over this pattern.

There are occasions where one list of subnets needs to be compared to another list of subnets. For example, comparing a routes in a route table against the aggregate assigned in the IPAM. This tool allows that comparison to be made and will identify missing unique and conflicting space. The top row will include subnets as they were provided to the tool. The second row will include subnets that are the result of subtracting one subnet from another. For example, 10.20.30.0/24 minus 10.20.30.0/25 results in a difference of 10.20.30.128/25

This tool attempts to place subnets into folders that could serve as summaries. It can then list the other subnets in the folder that are currently unassigned. It can be useful for understanding data structures that live within the address space.
As a simple example, Any two subnets can be placed into a common summary that shares the same network bits. If no bits are common, then the summary is effectively the 0.0.0.0/0 subnet. The process can repeat over a list of subnets, where subnets are placed into existing summaries or new summaries are created. The end result is a folder tree structure organized around subnet bit boundaries. This should roughly align to the topology of the network, or the services if running fabrics.

The route table can reveal a lot about the condition of the network. This early-release tool is still in development but already provides some insight into summaries that leak specific routes, network path dependencies where metrics tend to update synchronously, or opportunities for better summarization.
Currently there are four distinct functions:

• Routes per next hop: For each next hop, a tree is generated with possible block folders and the density if a summary was created for that node. High-density folders are good candidates for better route summarization.
• Leaked Summaries: This section identifies the condition where a summary is learned via one interface and more specifics are learned via a different interface. This may not be a problem if the summary flows back into the summarized portion of the network. However, a large number of leaked summaries could indicate that the address plan is not well-structured, potentially leading to routing issues. Analyzing the metrics on the summary and the specifics can provide clues. Be on the lookout for multi-layered summaries, where a folder may have multiple layers of overlapping specifics.
• Interface Map: This tool is still under construction, but can help identify where subnet blocks are distributed over the topology. Please revist this tool in the near future.
• Age vs Metric plot: This displays the route entries on a polar plot, where the radius corresponds to the metric and the angle to the last metric update. Sliders are available to adjust the displayed range along either dimension. Routes with common metrics tend to be at a similar distance. The larger the metric, the further away the route. This might vary for external routes redistributed from an external route source, shown in green, while internal metrics are in blue. The boldness of the circle indicates how many routes share a particular metric at a certain age. As routes originate from farther away, they are more susceptible to topology changes resulting in a new age. The circles become more distributed around the graph. Moving closer to the metric, timestamp changes tend to result from topology changes nearby, affecting all downstream routes along that path simultaneously. This is indicated by a radial populated with routes distributed over a range of metrics. This information can help explore areas where the network seems to be experiencing instability due to topology changes.

Practice your subnetting skills with the subnet challege. Hook together subnets shown in a trace route such that the sum of the subnet's size along the path equals the goal. You may need to divide subnets, or join subnets to get the right size for that hop.

Some miscellaneous notes

• Most tools support both IPv4 and IPv6. The allocation tool is an exception since sizing subnets around host counts is not meaningful with IPv6.
• Input is scrapped for addresses. They may be imbedded in other text. Only the first address on each line is parsed
• Submitted data is limited to 256KB of text
• Subnets can be parsed in dotted mask or CIDR format.

Subnetting Overview

Subnets are used in networking to group together IP addresses. There are two components, the address portion and a bit mask that is used for grouping. The address is a 32 or 128 bit number. The mask is a sequence of bits that define a boundary within the address and are used to distinguish between the subnet and host values. Typically hosts that are grouped together onto a network can communicate with each other directly. Consider this example, 192.168.30.44 255.255.255.224. The IP address and mask are converted to binary and stacked, these values are:

In this case, 192.168.30.44 is the 12th host (01100) on the network 192.168.30.32 /27. The 27 indicates the number of sequential 1 bits in the mask and is an alternate way to describe the mask. This is referred to as CIDR notation

Creating Summary Networks

You can create a summary network if two subnets are on the same bit boundary. But what does this mean? Lets consider again 192.168.30.32/27

We can create summary by sliding the mask bits one place to the left, so now the /27 becomes a /26

In the position marked with an X, the summarized subnet could have either a 1 or 0 in that position. When we write the summary address, bits not covered by the summary mask are zero'ed. Therefore the summary address is 192.168.30.0/26 which 'covers' both 192.168.30.0/27 and 192.168.30.32/27. Note however, that 192.168.30.32/27 can not be combined with 192.168.30.64/27 because they do not share the same bits under they summary mask. This is the limitation placed by the bit boundary. In fact, we need to move the mask one more place to catch the .64/27, ie 192.168.30.0/25. This is where this tool can help avoid summary mistakes

You can determine how many subnets fit under a summary by raising 2 to the power of the difference between the subnet mask by the summary mask. For example, 192.168.30.0/24 can hold (8) /27 networks because 2^(27-24) = 8

Lets look at this subnet with the calculator tool:

IPv6 has the same behavior, although the large address size of 128 bits makes them more difficult to chart without a tool. Note that the tool allows the address to be entered in short or long form and displays both in the output. This allows easy conversions. Short form IPv6 replaces any consecutive 0 bits with a :: notation. For example:

A common convention is to use the top 64 bits as the network number and the lower 64 bits as the host number. So it's not uncommon to route this subnet via a summary: 2000:120:1:43A0::/64

Allocating IPv6 address space

Its not uncommon for network administrators to focus only on the 2nd set of 32 bits of the IPv6 address space within the enterprise. The first 32 bits are typically fixed by the assignment. Even if the full the assignment wasn't a clean /32, things are simplified by design the address space around the bits shown with Y's below:

IPv6 Compression

IPv6 addresses are 128 bits wide, represented by 32 hex characters. The address is organized into 8 groups, each 4 hex characters seperated by a colon. For example

There are some rules to shorten how address is writen. Within a group, any leading zeros can be ommited.

Only the leading zeros are ommited. Trailing zeros are not.

The next rule allows two or more consecutive groups of 0's to be replaced by ::

The :: replacement can ony happen once. If it were to occur twice, the address would become amiguous. 2000::34::56 is invalid because it could mean 2000:0:0:34:0:0:0:56 or 2000:0:0:0:34:0:0:56. Its not possible to know where the 34 is located, exactly.

The rfc is not explict about what to do in this situation. However, this tool will replace the first occurance and follows the IPv6 compression guidance set out in RFC5952. You can enter subnets in either compressed or expanded format and the tool will report both formats in the response.

The beauty of the bit boundary

There are some conditions to keep in mind. Subnets under summaries are organized by bit boundaries, and one subnet can never extend beyond the summary. A bit is a boolean meaning it can have a true, or false condition. All subnets on a summary share this same bit pattern. As you move up the bit pattern, you have a hierarchy of boolean conditions. In a properly summarized route table, this is used to explain the topology. The first so many bits are the region, then a hub, then an aggregation point. But as networks move into overlays common with public clouds, the bits can take on new meaning because they are not constrained to the underlying physical aggregation layer. Subnets are mapped into a mix of topology and services.