The Super-Handy Subnetting Shortcut Table

If you’ve been watching closely, you may have noticed the very clear pattern that develops when attempting to determine address ranges. Now that we have the long method out of the way, we can take a look at a quick shortcut. With any given subnet mask value, there is always an associated multiple at which new subnets will start. For example, if you are using the network ID, and a subnet mask of, subnetting is clearly taking place in the third octet. When a custom value of 252 is used in a mask, new address ranges always move in multiples of 4 in the third octet. For example, the first three ranges of addresses in this example would be:

  • –
  • –
  • –

Of course, we could calculate these the old fashioned way, breaking everything down to binary and then working from there. However, the pattern that exists can easily be put into a table to help you recall mask values and address range multiples quickly and easily, as illustrated in this subnetting shortcut table:

Bit 1 1 1 1 1 1 1 1
Mask 128 192 224 240 248 252 254 255
Range Multiples 128 64 32 16 8 4 2 1

So what does this table tell you? Well, imagine that you were given the network ID with a subnet mask of If you used the table above, you could quickly determine the multiples at which new address ranges start. Simply look for the value associated with the custom mask in the Mask row – in this case 224. Now look in the Range Multiples row directly below 224, and you’ll notice the number 32. When a custom subnet mask of 224 is used, new ranges always start at multiples of 32 in the second octet. So, in our example, the first three ranges of addresses would be:

  • –
  • –
  • –

While the table above works perfectly for Class A and B address ranges, it does present a small issue for Class C address subnetting. Recall that Class C addresses use only the last octet for subnetting. The table can still be used for these addresses, but with one small adjustment – you’ll need to add 1 to the beginning of every range and subtract one from the end to account for the network ID and broadcast address.

For example, imagine the address with a subnet mask of In this case, according to our table, the ranges should begin at multiples of 16. This is still true, and the first three subnet IDs would be:


However, calculating the ranges means remembering that simple rule I just outlined. Add one to find the beginning of the range, and subtract one from what you might normally consider the end of the range. For example, the first range would go from up to This is because the “normal” end of the range ( is actually the broadcast address for that subnet, where the host ID is set to all binary 1s. Altogether, the first three ranges in this example would be:

  • –
  • –
  • –

All thing considered, the shortcut table provides a simple and effective way of recalling the address range starting points associated with a given custom subnet mask. It should be helpful as a quick reminder if jotted down before you write your exams. Just remember that when in doubt, always go back to the binary method.

Subnetting Challenge

To make things interesting, let’s go through what I consider to be a tough subnetting question. To be honest, if you can follow this question and understand what you’re doing, there isn’t a subnetting question I can ask that you can’t answer. We’re going to go through it step-by-step, just to be sure that you’re clear on determining the correct subnet mask, and the ranges of hosts on the first, second, and last subnets.

In this scenario, we’re going to assume a network ID of You should already be familiar with its default mask. Our requirement is to have at least 4000 subnets. Our goal is to determine both the custom subnet mask, as well as the first, second, and last ranges of host IDs.

Let’s start with the custom subnet mask. Since we need 4000 subnets minimum, we need to determine how many bits are required. It should already be obvious that we’ll need to move beyond a single octet, since 8 bits will only provide a maximum of 256 subnets. If we try 10 bits, we come up with a value of 210-2 or 1022 subnets, obviously not enough. 11 bits provides 2046 subnets and 12 bits 4094 (212-2). Obviously 12 bits meets out requirement, so that’s what we’ll use.

Recall that the default subnet mask for the private network address is If we add an additional 12 bits, the mask becomes, as shown in the figure below.

Figure: Network, subnet, and host portions based on the custom subnet mask

Now that we know our custom mask, let’s determine how many hosts we can support per subnet. From the diagram above, we have 12 host bits remaining, giving us a maximum of 212-2, or 4094 hosts per subnet.

Our next goal is determining the first valid range of IP addresses. Don’t get thrown off by the fact that the subnet portion of the address spans one and a half octets. If we simply follow the same rules as before, we’ll be fine. In this case, set all 12 subnet bits the lowest non-zero value, and determine the first and last valid host addresses, as shown in the figure below.

Figure: Defining the IP address range for the first subnet.

Notice that the first valid range of IP addresses on subnet goes from up to The second subnet will start when we set the 12 bits of the subnet ID to 00000000 0010.

Figure: Defining the IP address range for the second subnet.

The second valid range of addresses becomes to The broadcast ID for this subnet is

The subnet IDs will continue to increase until the last range is reached – remember that this occurs when the subnet ID is set to the highest value that is not all binary 1 values – in this case, 11111111 1110.

Figure: Defining the IP address range for the last subnet.

As such, our last valid subnet is subnet ID, with an address range from up to Remember that in between the three subnets that we’ve looked at, another 4091 subnets exist.

TCP/IP and the OSI Model – The Application (Process) Layer

The Application/Process Layer is where TCP/IP applications and services reside. You’re more than likely familiar with many of these, since you probably interact with many TCP/IP applications on a daily basis – a web browser using HTTP, or your email client connecting to a POP3 server are but two simple examples.

The list below outlines some of the more common Application layer protocols that you should be familiar with.

  • Telnet. Telnet is used to create a terminal session with a remote host, providing command-line access to the target system running a telnet server (daemon).
  • FTP. The File Transfer Protocol is used to reliably transfer files between an FTP client and server using TCP.
  • SMTP. The Simple Mail Transfer Protocol is used for the exchange of email between systems.
  • DNS. The Domain Name Service is a distributed database that is queried to resolve (or translate) names such as to an IP address.
  • SNMP. The Simple Network Management Protocol is a lightweight network protocol that allows information to be gathered about network devices. Examples include information about utilization, hardware configuration, and so forth.
  • TFTP. The Trivial File Transfer Protocol is used to transfer files between a client and a TFTP server over UDP. You’ll learn more about TFTP later, since it’s the protocol used to transfer files to and from a Cisco router.

Transmission Control Protocol (TCP)

TCP is the connection-oriented transport protocol in the TCP/IP protocol suite. TCP attempts to make connections reliable through the use of positive acknowledgement with retransmission – a system where acknowledgements are required for all data sent. If the sending host does not receive these acknowledgements, retransmission eventually occurs. Sequence numbers are assigned to segments to be sure that they are assembled in the correct order at the receiving system. Flow control is handled through buffering techniques such as the use of sliding windows.

When two systems wish to communicate via TCP, they first establish a session (remember the 3-way handshake?), also known as a connection or virtual circuit. Once data has been transmitted and the session is complete, it is closed via a modified 3-way handshake – the difference is that the connection needs to be closed (and acknowledged) independently by both systems. The figure below outlines the 4 steps required to close a TCP session. Closing a session involves sending FIN (no more data to send) and ACK messages. Notice that the extra step involved – the system that originated the end of the connection acknowledges that the other system is now closing the connection as well.

Figure: Ending a TCP session.

There can be a delay between the time when one system attempts to close a connection and the time that the entire connection is actually closed. This occurs because one end may close the connection, while the application on the other end might still be running. A good example is when a user accesses a website – the user may keep their browser running long after the web server has finished sending the requested data as has attempted to close the connection.

TCP communicates with upper-layer applications and protocols through the use of port numbers. When combined with an IP address, a port number defines a unique endpoint for communication. There are 65,536 port numbers available to TCP. How they are chosen requires a bit of discussion.

For the most part, server-side applications are defined by what are considered to be well-known port numbers. These port numbers are defined in RFC 1700 and fall into the 0-1023 range. For example, when a client opens a web browser and types in, that name will be translated into an IP address using DNS, and then a connection will be made to port 80 on that IP address. TCP port 80 is the default port on which a web server waits for a connection. But what about the client side of the connection? Well, the client needs to specify a port on which it will send and receive data as well. These port numbers are usually in the range above 1024, and are dynamically assigned by the source host.

Internet Control Message Protocol (ICMP)

ICMP is yet another protocol at the Internet layer. Internet Control Message Protocol is used as an error reporting protocol in the TCP/IP suite. It is important to begin by noting that ICMP does nothing to make IP reliable. Instead, it simply reports on error situations that exist or occur. ICMP only sends error messages back to the originating host, and not intermediary devices. A good example of a type of error message sent by ICMP is a Source Quench message. These are used when a router receives more data than it can handle. Once its buffers finally fill, the router will send the source host a Source Quench message, effectively letting the source know that it should send data at reduced rate. Note that the message doesn’t include any information on packets that may have been lost. Instead, it simply makes the sender aware that a situation exists. It is still the responsibility of upper-layer protocols to ensure that data arrives at its destination.

You are probably more familiar with ICMP than you realize. Have you ever used the ping utility? If so, what you’ve actually done is sent out ICMP echo messages, and if the address that you attempted to ping was reachable, you received back ICMP echo replies. Ping is an example of a simple ICMP utility that provides information on whether or not hosts can be reached. If the host you’re attempting to ping can’t be reached, you’ll receive an ICMP Destination Unreachable message. ICMP is also used to send messages that notify the sender that the Time to Live (TTL) on a packet has expired.

Consider the example below, which shows a capture of an ICMP echo reply. Note that only the ICMP portion of the frame is expanded.

Ethernet II
Internet Protocol, Src Addr: (, Dst Addr: (
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x3b5c (correct)
Identifier: 0x0200
Sequence number: 18:00
Data (32 bytes)

Remember that ICMP is simply a reporting protocol – it does nothing to actually remedy any errors that occur.

Tip: For more information on Internet Control Message Protocol, see RFC 792

Address Resolution Protocol (ARP)

ARP is another protocol found at the Internet layer of the TCP/IP model. As the name suggests, ARP is a protocol used to resolve addresses – in this case, finding the MAC address that corresponds to an IP address. Remember that data is encapsulated before being sent over the network. Even though a system may know the IP address it wants to ultimately send data to, it may not know the MAC address. On an Ethernet LAN, systems communicate directly using CSMA/CD, and as such must know the MAC address of the system that data must be sent to next.

Recall that MAC addresses are fixed. IP addresses, on the other hand, are not. Systems can be manually configured with an IP address, or they can obtain one using the Dynamic Host Configuration Protocol (DHCP). As such, it doesn’t make much sense to have a static mapping between the two, since IP addresses may change. Instead, when a system needs to obtain the MAC address associated with an IP address, it sends out a broadcast message asking that the system with the specified IP address reply with its MAC address. Once it receives a reply, the answer is cached for a limited period of time (typically between 2 and 20 minutes) in the system’s ARP table. Caching helps to ensure that ARP broadcasts don’t get out of hand and overwhelm the network.

Since an ARP request is a broadcast, it will be seen by every system in the same broadcast domain. When a system comes across an ARP request, it will check to see if it is the intended recipient. If it is, the system will process the frame. If not, the frame is ignored.

When a system wishes to communicate with another system in a different broadcast domain, recall that the packets must be sent to a router. In this case, the ARP request isn’t looking for the MAC address of the destination host (since the broadcast would never reach it), but instead the MAC address of the router interface to which the frame must first be forwarded.

Internet Protocol (IP)

IP is a connectionless protocol. As such, it doesn’t request acknowledgements for data sent. Instead, it relies on upper-layer protocols (like TCP) to handle reliability functions. IP addresses are probably something that you’re already familiar with. More likely than not, you’ve assigned an IP address to a computer for the purpose of connecting it to the Internet, your office, or something similar. An IP address is most often displayed in what is referred to as dotted-decimal notation, for example IP addresses are made up of two main parts – the first uniquely identifies a network, and the second uniquely identifies a host on that network. Think of this as being similar to a street address. Your house (the host) has a unique address on your road (the network).

You may also be familiar with the fact that IP uses 32-bit addresses. But what does this mean? Simple, computers do just about everything in binary, representing information as a series of 0’s and 1’s. Since an IP address is 32 bits long, it can also be represented as a series of 32 1’s and 0’s. For example, the IP address can also be represented as:

11000000 10101000 00000000 00000001

Don’t worry just yet about how those numbers are generated. By the time you get through Chapter 5, I promise it will seem like the easiest thing in the world.

You’re probably also familiar with something called a subnet mask. The purpose of a subnet mask is to define which portion of an IP address represents the network, and which portion represents the host. For example, if I have an IP address of and a subnet mask of, it means that the first eight bits (referred to as the first octet) represent the network, while the last 24 bits represent a host. In this case, the network ID is 10, while the Host ID is 1.1.1. In Chapter 5 we’ll delve much further into how masks work and how they’re created. For now, it’s important that you simply understand that every IP address requires a subnet mask to be able to distinguish between the network and host portions.

Every IP network requires a unique network ID, and each host on a network requires a unique host ID. That should be simple enough for now – an IP address simply gives us information as to the network on which a unique host can be found.

In order to communicate with a host on a different network, communication requires the use of routing. IP is what is referred to as a routed or routable protocol. That simply means that if a network is configured correctly, a host on one network will be able to communicate with a host on another, with routers acting as intermediaries deciding where a packet should be sent next. We’ll take a look at routing protocols in detail in Chapter 8.

TCP/IP and the OSI Model – The Network (Internet) Layer

If you recall, the Internet layer’s primary responsibilities are determining a path between networks (routing), as well as network addressing. The addressing that takes place at the Internet layer is often referred to as logical addressing. These addresses aren’t “burned-in” like Ethernet MAC addresses, but instead are assigned by an administrator. The addressing protocol of the TCP/IP stack is the Internet Protocol (IP).

Note that TCP/IP routing protocols such as RIP, OSPF, and others also exist at the Internet layer. These will be looked at in Chapter 8, when routing is covered in detail.


The Transmission Control Protocol/Internet Protocol is by far the most popular protocol suite in use today, thanks to the growth of the Internet. TCP/IP has changed a great deal over the years, as different protocols were created or adapted to address different needs. For example, TCP was originally developed back in 1974, while TCP and IP came together in 1978. It wasn’t until January 1st, 1983 that all systems on the Internet (then known as the ARPANET) officially had to use TCP/IP. The groups who set the direction for the Internet (and decide what will become a standard) are the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG).

Before we go any further, you should be aware of what are known as Requests For Comments (RFCs). Before anything becomes an Internet standard, it has to go through the RFC process. While all Internet standards are defined in RFCs, not all RFCs become standards. If you take the time to read RFC 1149 or 1438, you’ll understand what I mean. It’s also worth noting that RFCs can be superceded by newer versions. If a standard is changed, a new RFC document is created, and a new number is associated with it. An RFC contains the definitive information for any Internet standard. If you’re just starting out in the world of networking, get in the habit of using RFCs when you need clarification. You can be sure that the information they provide outlines the facts and they are a freely available resource, too. Just make certain that you’re reading the most current version.

Tip: One of the best resources for searching RFCs is The results supplied by this page outline RFC status information, as well as whether a particular RFC has been updated or is now obsolete.

A number of key protocols make up the TCP/IP suite, some of which we looked at briefly in Chapter 1. In this chapter we’ll go into more detail on each. A solid understanding of the protocols that make up the TCP/IP protocol stack is not only imperative for the exams, but also in real life. Troubleshooting any network is relatively simple when you truly understand how communication processes take place

TCP/IP and the OSI Model

The TCP/IP protocol stack is comprised of protocols that exist at the upper three layers of the TCP/IP model (the lower layer is the Network Interface layer, and is responsible for network technologies that we’ve already looked at such as Ethernet, Token Ring, and so forth). The main protocols that can be found at each layer have different roles and responsibilities, and having an appreciation of how they work (and their purposes) is imperative. The figure below outlines the protocols that we’re going to look at in this section, and how they map to the OSI model.

Figure: TCP/IP protocols and the OSI model.