Communication Across a Simple Routed Network

Take a look at Figure 8-1, where a single router connects to networks 192.168.0.0/16 and 10.0.0.0/8. By this point, you should recognize these network addresses as two of the private IP address ranges that are not valid on the public Internet. The router is a simple 2-port Ethernet router, with interface E0 connected to the 192.168.0.0 network, and interface E1 connected to the 10.0.0.0 network. Both interfaces on the router have already been assigned their IP addresses, 192.168.0.1 and 10.0.0.1 respectively. Using an IP address that ends in “.1” for router interfaces is fairly common. It is not a rule, but rather a convention. You may or may not choose to follow this convention, but it does make the IP address of a router interface easier to remember.

Figure: A simple routed internetwork.

Believe it or not, without configuring anything else on this router, it is already capable of routing data between network 192.168.0.0 and network 10.0.0.0. How is this possible? Well, the first thing you need to understand is that after assigning a Cisco router IP addresses, it knows about the networks that it is directly connected to, and the command ip routing is enabled by default. In other words, the router is aware that interface E0 is connected to the 192.168.0.0 network, and that interface E1 is connected to network 10.0.0.0. A router will automatically add both of these networks to its routing table. If our router receives a packet destined for the 192.168.0.0 network on interface E1, it will know to forward it out interface E0. In the same way, interface E0 knows that any traffic destined for network 10.0.0.0 should be forwarded out interface E1. A router always knows how to get to the networks to which it is directly connected, without any additional configuration. Things get a little more complex when a router needs to get to networks that are not directly connected.

Each network in this example also has a single host configured, as shown in Figure 8-2. Notice that each host has an IP address, subnet mask, and default gateway value assigned. The default gateway IP address is that of the local router interface on the host’s network. Hosts will forward traffic to the router when they calculate that the destination host is not on their local network.

Figure: Simple routed network with 1 host on each network.

In this example, each network is a Layer 2 broadcast domain, running Ethernet. Both networks are also unique Layer 3 IP networks, as shown by their logical layout. On most (but not necessarily all) networks, each broadcast domain will be associated with a unique IP network (or subnet) address.

There are cases, however, where the preceding statement is not necessarily true. For example, a company may run out of IP addresses and choose to map two subnets to a single broadcast domain. Making things work would then involve adding a second IP address to the local router interface. Even through hosts will be in the same broadcast domain, the router will still need to route packets between the different subnets. I didn’t say it was efficient, but it is something that you may come across.

For the purpose of illustration, I’m going to assume that Host A wishes to communicate with Host B. In order for these two hosts to communicate, our router will obviously need to be involved. Let’s take a look at how the communication process occurs when Host A attempts to create an HTTP session with Host B.

  1. The first step in the process is the creation of an HTTP request at the Application Layer. In this case, Host A is requesting a web page from Host B. After formatting the HTTP request, the data is passed down to the Transport layer. Remember, our interaction is happening over TCP/IP.
  2. Once the Transport Layer on Host A receives the data, it will add header information that will include the source and destination TCP ports. In this case, the destination TCP port will be 80, and the source port some number above 1024. Once this is complete, the segment will be passed to the Network Layer.
  3. At the Network Layer, the IP header will be added. This header will include a variety of information, but most importantly the source and destination IP addresses. The source address is 192.168.0.99, and the destination address is 10.0.0.100. The next step is passing the packet down to the Data Link layer.
  4. Recall the ANDing process looked at in Chapter 5. This is the process that a host uses to determine whether a destination host is local or remote. In this case, the ANDing results will be different, which means that the destination is on a remote network. When a destination is remote, the packet cannot be sent directly to that host. Instead, it must be first sent to a router.
  5. Pay particular attention to this step. Host A knows that it needs to send this packet to its local router, but the router is not the ultimate destination IP address – 10.0.0.100 (Host B) is. In order to get this data to the router, our host must frame the packet with the destination MAC address – in this case, the MAC address associated with the router’s E0 interface. To obtain this MAC address, it will send out an ARP request looking for the MAC address associated with 192.168.0.1. Once the router responds, Host A will frame the packet. In this case, the source address is the MAC address of Host A, and the destination address is the MAC address of the router’s E0 interface.
  6. Ultimately, this frame will reach interface E0 on the router. The router will notice that the frame is destined for its MAC address, and as such it will process the frame. After calculating the frame’s CRC, it will strip off the frame header and pass the resulting packet up to the Network layer At this point, the router will notice that the destination IP address is not it’s own. When a router receives a packet that is not destined for it specifically, it looks in its routing table to see whether it has a route defined to the destination network. In this case, the router sees that it is directly connected to network 10.0.0.0/8, and also determines that it should forward the packet via interface E1. Before it can forward the packet, however, it has to pass it back down to the Data Link Layer for re-framing.
  7. At the Data Link layer, the router will re-frame the packet with a new header, meaning that source and destination MAC addresses will need to be added. In this case, the source MAC address is now the MAC address of interface E1 on the router. The destination MAC address will be obtained via an ARP request to IP address 10.0.0.100. Once Host B replies with its MAC address, this will be added to the frame as the destination MAC address. The router will then calculate a new CRC for the frame, and forward it through interface E1 as a series of bits.
  8. Eventually the frame will arrive at Host B. By inspecting the destination MAC address, Host B will recognize that the frame is meant for it, calculate the CRC, strip off the framing, and pass it up to the Network Layer.
  9. At the Network Layer, Host B will also recognize its IP address as the destination. This means that it has to process the packet further. In the IP header, it will see that the data should be passed to TCP at the Transport layer.
  10. At the Transport Layer, Host B will look at the destination TCP port, and recognize that the data contained in the segment should be sent to TCP port 80. This is the port on which the web server application is listening for connections.
  11. The web server on Host B will process the HTTP request contained in the data. Ultimately it will need to send a reply, where the whole process happens again, in reverse.

If those twelve steps seem like an awful lot of work to pass data between two hosts, you’re right. However, this is the way things work when you want to communicate between hosts on a routed network. Think of it this way – we are effectively using a Layer 3 protocol (IP) to communicate between different Layer 2 networks. In this case, both of those networks were Ethernet, but that won’t always be the case. For example, what if Host B had resided on a Token Ring network? In that case, our router would require one Ethernet interface and one Token Ring interface. When the data was sent to the router from Host A, it would have been framed for Ethernet. After the router stripped off the framing and passed the data up to the Network layer, it would determine that the packet needed to be forwarded out the Token Ring interface, where it would need to be framed for Token Ring. As even this very basic example suggests, a router is doing a great deal of work to every packet it encounters – not only does it have to make a forwarding decision based on the destination IP address, but it also has to reframe every single packet that it forwards on its way. By this point, you should be recognizing some of the reasons as to why routing is typically much slower than switching.

You should also recognize that although packets are re-framed at the router, the actual source and destination IP addresses never change. In fact, the only thing that the router touches for certain in the IP header is the time-to-live (TTL) value. Recall that a router will always decrement the TTL on an IP packet that it forwards by one, which ultimately ensures that packets don’t end up being forwarded around a network forever. Once its TTL expires, a packet is discarded.

A router may further alter an IP packet under special circumstances, such as when the maximum transmission unit (MTU) of connected networks is different. For example, imagine that the networks connected were Ethernet and Token Ring. Token Ring has a much larger maximum frame size than Ethernet. When a frame is received on a Token Ring interface, the packet it contains may be much larger than what Ethernet can handle (recall that the MTU of an Ethernet frame is only 1518 bytes). In this case, the router will “chop up” or fragment the packet into a number of smaller packets, then reframe each and send them on their way. Again, it becomes clear that there is more to what a router does than initially meets the eye.

Network Communications in Routed Environments

In order to appreciate the role of a router, we need to take a look at how communication happens between hosts on different networks in a routed environment. For the purpose of these illustrations, I’m going to assume that our network is running the most popular routed protocol suite, TCP/IP. We’ll begin with a look at a simple internetwork consisting of two networks, both connected to a single router. This will be followed by a look at a larger internetwork, where multiple networks are connected via many routers.

The Ping Diagnostic Utility

You are probably familiar with the ping utility from Windows or Linux. The version included with the Cisco IOS provides significantly enhanced functionality, and can be used to test connectivity for a variety of different protocols including IP, IPX, AppleTalk and more. To get a sense of the functions provided by ping, issue the ping command followed by the question mark.

cisco2501#ping ?
WORD Ping destination address or hostname
appletalk Appletalk echo
decnet DECnet echo
ip IP echo
ipx Novell/IPX echo
tag Tag encapsulated IP echo

Notice the range of protocols that ping can work with. In fact, the list can be even longer depending on the protocols supported by your IOS version. At the most basic level, ping sends out echo request messages and expects to receive back echo replies. It is important to be clear about the information that a ping provides. For example, if you can ping an IP host on a different network, it suggests that both hosts have TCP/IP correctly initialized and configured, and that routing between the networks is also configured correctly. In cases where you cannot ping a remote host, don’t jump to the conclusion that the remote host is unavailable or misconfigured – though it might be, the problem may also be a configuration issue with the source host, or potentially some routing-related (or physical connectivity) issue between the two. As a general rule, use the following steps to determine the source of connectivity issues between your PC and a remote system:

  1. Assuming that your IP address, subnet mask, and default gateway are correct, attempt to ping a host on a different subnet. If this fails, one possibility is that routing is not configured correctly.
  2. If pinging a remote host fails, attempt to ping your default gateway. If this fails, it may indicate that TCP/IP is not configured correctly on your local router interface, on your host PC, or that the router interface has not been enabled with the no shutdown command.
  3. If pinging your default gateway fails, try pinging your host’s configured IP address. If this fails, it can may mean that you have configured your host PC’s IP address incorrectly, or that TCP/IP is not properly installed or initialized on the host system.
  4. If pinging the host’s IP address fails, try pinging the loopback address – 127.0.0.1. If this fails, it generally indicates that TCP/IP is not properly installed or initialized on your host system.

To test IP connectivity, use the ping command followed by a hostname or IP address.

cisco2501#ping accra
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.209, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

The ping was successful in this case, as illustrated by the five exclamation points and the final statement. In cases where a ping fails, you’ll see a message similar to the one shown below.

cisco2501#ping 192.168.1.234
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.234, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

When the exclamation points are replaces by dots, it means that for whatever reason, the destination host did not respond successfully. Again, this could suggest a range of issues including misconfiguration, physical network issues, routing problems, and so forth.

An extended ping allows a higher degree of control than the default ping settings, including the ability to change the repeat count, size of the datagrams, and so forth. The example below outlines an IPX ping using the extended ping interface.

cisco2501#ping
Protocol [ip]: ipx
Target IPX address: 101A.0060.5cc4.f41b
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPXcisco Echoes to 101A.0060.5cc4.f41b, timeout is 2 seconds
:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Although generally a TCP/IP utility, ping works with a number of protocols beyond IP and IPX. For a complete list of the protocols that ping supports on your router, issue the command ping ?.

Understanding Variable Length Subnet Masks (VLSMs) Part 3

This article is the final installment in a series of tutorials about VLSM. It all begins here.

Recall that from this table, many IP address ranges are still available on our network – everything from 192.168.10.0 through 192.168.29.0 for North America. For that reason, we can again subnet the address range further to account for the smaller offices. For these smaller offices, we’ll use a /24 subnet mask – this meets our requirement of supporting up to 150 hosts on each of the small LANs. In this case, we can support 254 (28) hosts on each. This table outlines the 13 subnets for the small offices, along with a few defined for additional growth.

Notice that even after dividing up the address space for our small offices, we still have additional address space left over – in this cases, everything from 192.168.26.0 up to 192.168.29.0 is still unassigned. This space could be used to assign additional large or small subnets in North America, as need dictates. However, we still have one last requirement – WAN links.

Remember that a point-to-point WAN link still counts as a subnet, even if it is limited to only 2 hosts. In order to account for our WAN links, let’s use the use the range 192.168.29.0/24, and subnet it further. In this way, we have left the entire address space between 192.168.24.0 and 192.168.28.0 for defining additional North America LANs if required.

Since we only require 2 addresses for each WAN link, we only need 2 host bits – 22-2 is 2, which meets our requirements. If we make all the remaining bits subnet IDs, we can support up to 26-2 or 62 WAN subnets within North America alone. This will easily meet our needs. Based on this scenario, our WAN links will use a subnet mask of 255.255.255.252. This table outlines only the first 4 WAN links, since listing all 62 would serve little purpose.

Obviously VLSM gives us better control of the size of our subnets, allowing us to allocate addresses in our chosen space more efficiently. But what other benefits does this scenario bring? Well, one is certainly smaller routing tables. For example, all networks in North America can now be reached from any other geographic region via a single routing table entry – 192.168.0.0/19. Once any data for North America is sent to this router, it then decides where the data needs to be forwarded next. If we weren’t using CIDR and VLSM in this example, each router’s routing table would need entries for every network in North America. By aggregating all the entries behind a single entry, routing performance will be greatly increased – especially on very large networks.

Understanding Variable Length Subnet Masks (VLSMs) Part 2

Let’s start off by breaking our 192.168.0.0/16 network into 6 large subnets, since using the required 4 would only account for current regions, and would not allow for future growth. Doing this is not in any way different that what we’ve done in the past. To get 6 large subnets, we’ll need to steal 3 bits, since 23-2 gives us 6 subnets. In this case, our new mask becomes 255.255.224.0, or /19. Each of the new subnet IDs is listed in this table, including the location that it will be used for.

Since we’ve used a /19 subnet mask, each of these ranges supports up to 213-2 or 8190 hosts as things presently stand. However, we’re not done. Our next goal is to take one of the areas and further divide it into a number of smaller networks. For example, let’s say that North America includes 16 offices. Of these, 3 are large, and need to support up to 400 hosts. 13 are smaller, and need to support 150 hosts maximum. In the future, it is possible that more large and small offices will be added.

In order to deal with these requirements, we need to subnet the North America network further. The easiest way to deal with this is to consider 192.168.0.0/19 to be just another network ID, and our starting point. To begin, we know that we need to immediately support 3 large offices, each with up to 400 hosts. For this example, I’m going to have us define one additional large office, in order to account for future growth. That gives us a requirement of 4 networks, and 400 hosts per network. Using the host portion, we would need 9 host bits in order to support our requirement, which would give us 29-2 or 510 hosts per subnet. In doing so, we are left with 4 bits to define subnets, as shown. Remember that our starting subnet mask is 255.255.224.0 or /19 in this case.

Using the first 4 available ranges to define our four large LANs, we would allocate the subnet IDs as shown in this table.

Understanding Variable Length Subnet Masks (VLSMs) Part 1

At the most basic level, VLSM represents a hierarchical network addressing scheme. Think of it as subnetting multiple times within the same address range. For example, we can take the network 192.168.0.0 and subnet it into a number of large subnets. In our case, these will be used to define large geographic regions. Next, we look at those regions (or large subnets) individually, subnetting them further. This allows us to break up a region for the purpose of defining custom subnets that meet our size requirements. This additional subnetting can continue until you run out of subnets within a given range. A properly designed hierarchical addressing scheme both makes better use of the address space, and also provides for more optimized routing tables, as we’ll see shortly. This figure outlines the basic idea behind a hierarchical addressing arrangement. Note that I have only shown the breakdown of a single large subnet rather than both large subnets, in order to keep things clear.

Using VLSM addressing on a network is slightly more involved that using the same subnet mask throughout. You again need to properly characterize your network, defining how many WAN links, subnets, and hosts per subnet you are dealing with. The easiest way for us to begin is with a single network address. In this case we’ll use the private address 192.168.0.0/16. I’m going to assume that our company has four main geographic regions, and that each region includes many smaller offices.

Introduction to Subnetting with VLSMs

One thing that you may have noticed during our look at subnetting was that each and every subnet defined was exactly the same size, based on a single subnet mask value. While this is simple, it is again very wasteful. In most organizations, LANs are not all the same size. While some subnets may have hundreds of hosts, others may have a very small number, perhaps 10 or 20. More obvious still is a WAN link connecting two locations, which only requires 2 addresses. In cases where you have subnetted a Class B network using a /20 mask, that leaves you with a fixed 4094 hosts per subnet. On a WAN link, that alone would mean wasting 4092 addresses!

While you may have plenty of subnets and address space for your smaller network, on very large networks proper address management can be crucial. Using Variable Length Subnet Masks (VLSM), this problem can be solved. VLSM allows you to use different subnet mask values throughout a network, in order to better account for how many hosts you have on each subnet. Like all classless addressing, VLSM relies on the associated subnet mask (prefix) information to be explicitly provided in order to determine the network portion of an address. While VLSM provides some very useful addressing capabilities, it also requires some careful planning.

Classless Inter-Domain Routing (CIDR) aka Supernetting

Recall that classful addresses are decidedly wasteful in the way they allocate addresses –even an entire Class B address range is too large for most companies. To make matters worse, a Class C block is so small that many companies would require many Class C ranges as a viable alternative. On the public Internet, routing tables were becoming extremely large, which in turn was affecting routing performance. A new solution was required to deal with the public address space more efficiently, and came about via a method referred to as Classless Inter-Domain Routing (CIDR).

CIDR is sometimes referred to as supernetting. While subnetting involves taking an address space and breaking it up into a number of smaller networks, supernetting is first and foremost a network aggregation scheme. For example, by supernetting four network addresses together, you can actually make them appear to be one network, as opposed to four. Again, this is all accomplished by playing with the subnet mask values.

CIDR has its own notation for dealing with subnet masks, and you may already be familiar with it. Instead of taking the time to say network 131.107.0.0 with a subnet mask of 255.255.0.0, CIDR notation truncates the subnet mask to what is known as “slash” notation. In this example, the network would be identified as 131.107.0.0/16. The “/16” value refers to the fact that the first 16 bits in the subnet mask are all set to values of binary 1.

Figure: Determining CIDR notation based on a subnet mask.

This really is a more efficient way of referring to a network. For example, if we had a network address of 192.168.0.0 with a mask of 255.255.255.128, in CIDR notation it becomes 192.168.0.0/25. Again, the /25 means that the first 25 bits of the subnet mask are set to binary 1.

But what is supernetting really? Well, imagine a routing table on a large Internet backbone router. This router needs to know how to get to all public networks. If a certain company has been given many different network IDs (for example, an ISP might have 8 Class B network IDs), a minimum of 8 routing table entries would be required, just to be sure that these 8 networks could be reached. As routing tables get larger and larger, routing performance is definitely impacted. Supernetting provides a way to “collapse” or “summarize” those 8 entries into a single entry, by altering the subnet mask value.

Tip: Supernetting allows contiguous network addresses to be summarized into a single routing table entry through the use of a custom subnet mask.
The first requirement to supernet addresses together is that network addresses must be contiguous. For example, you could supernet together networks 131.107.0.0 and 131.108.0.0, but not networks 131.107.0.0 and 145.36.0.0.

Classless IP Addressing

By now you’re familiar with the concept of classful addresses, where the default network and host portions of a network address can be easily identified by the value found in the first octet. While the classful system is simple and convenient, the scheme brings about some problems – mainly inefficiently large routing tables, and a wasteful use of the available 32-bit address space. In order to compensate for this, the idea of classless addressing was developed.

A classless address is just that – addressing without the common Class A, B, or C designations. Instead, classless addressing doesn’t assume any class – it always includes the associated subnet mask (also referred to as the network “prefix”) in order to determine the network portion of an address. Recall how classful addresses have a default subnet mask associated with them. In the classful world, routers could just assume the class of an address based on the network ID. In the classless world, subnet mask information must always be provided when routers exchange information with each other. Some routing protocols, such as the Border Gateway Protocol (BGPv4) and OSPF, support classless addressing. Others, like RIP version 1, do not. In Chapter 8 we’ll look at routing protocols and their support for classless addressing in more detail.

Determining if Network Hosts are Local or Remote (ANDing)

We spent time determining the valid ranges of addresses on a given subnet for a reason. Recall from our earlier look at TCP/IP communication that when a host wishes to communicate with another host, it must first determine whether the destination is local (on the same subnet) or remote (on a different subnet). In cases where hosts are local, they can communicate directly. In cases where the destination host is on a different network, the packets must be sent to a router, who will then forward them along on their journey to the destination network.

In order to determine whether a destination host is local or remote, a computer will perform a simple mathematical computation referred to as an AND operation. While the sending host does this operation internally, understanding what takes place is the key to understanding how an IP-based system knows whether to send packets directly to a host or to a router.

An AND operation is very simple – two binary digits are compared, and the based on their combination, a resultant value is formed. It is neither adding nor subtracting, so do not consider it as such. In the most simple terms, there are only three possibilities when ANDing two binary digits. The list below outlines these operations and their results.

0 AND 0 = 0

0 AND 1 = 0

1 AND 1 = 1

Notice that when the binary digits 1 and 1 are ANDed, the result is 1, and that any other combination produces a result of 0.

The question now becomes how this is actually used. When a host wishes to figure out whether a destination host is local or remote, it goes through the following steps.

  1. The host takes its own IP address and ANDs it with its own subnet mask, producing a result.
  2. The host then takes the destination IP address and ANDs it with its own subnet mask, producing another result.
  3. Finally, the host compares the two results. In cases where the ANDing results are identical, it means that the hosts reside on the same subnet. In cases where the results are different, it means that the destination host is remote.

Consider this example. Computer A has an IP address of 192.168.62.14 with a subnet mask of 255.255.248.0. It wishes to communicate with host 192.168.65.1. In order to determine whether this destination is local or remote, it will go through the ANDing process. Its IP address and subnet mask are lined up in binary, and then vertically compared to find the AND result. The same is then done for the destination address, again using the subnet mask of the source host. This is illustrated in the figure below.

Figure: The ANDing process.

Notice that when the resulting AND values are converted back to binary, it becomes clear that the two hosts are on different networks. Computer A is on subnet 192.168.56.0, while the destination host is on subnet 192.168.64.0, which means that Computer A will next be sending the data to a router. Without ANDing, determining local and remote hosts can be difficult. Once you’re very familiar with subnetting and calculating ranges of addresses, recognizing local and remote hosts will become much more intuitive.
Whenever you’re in doubt as to whether hosts are local or remote, use the ANDing process. You should also notice that the ANDing process always produces the subnet ID of a given host.