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.

Communications Over VoIP Networks

When terminal devices like IP phones wish to communicate, call processing software like Cisco CallManager is typically involved in the process. While some calls will be between two IP phones on the same subnet, some may be on a remote IP network (for example, across a WAN link), while others will be to traditional phones connected to the PSTN. When two users with IP phones on the same subnet need to communicate, a router does not need to be involved, consistent with how IP operates. However, when the users are located on different subnets, a router (or Layer 3 switch) must be involved in order to route the IP-based voice traffic from one subnet to the other. In this case, the router used between the subnets does not need to be voice-enabled. Instead, it will simply route traffic across the network as it would any IP packets. Only the third situation requires a voice-enabled router – when a user on the IP network needs to communicate with users on the PSTN. In this scenario, a router that includes a voice module is needed to convert between IP and voice in one direction, and voice and IP in the other.

In order for a router to properly route voice traffic across an IP network or to an external user connected to the PSTN, dial peers need to be configured on the router. Remember that users using an IP phone will not be dialing the destination IP address that they wish to reach. Instead, they will be dialing a complete phone number or extension number associated with the user they wish to reach. The configuration of dial peers associates a phone number or extension number with an IP address or the voice port to which the call should be forwarded. For example, if a user wishes to reach another user on the IP network at extension “1234”, a dial peer (specifically, a VoIP peer) would be configured on the router mapping that extension to the destination IP address. Similarly, if a user needed to connect to someone on the PSTN, the phone number (usually a small portion of the number) could be configured in a dial peer (known as a plain old telephone service or “POTS” peer) to specify that the traffic should be forwarded out of a voice port on the router, which may be connected to a PBX or directly to a PSTN trunk link.

One of the advantages of configuring dial peers is that an administrator has a high degree of control over the entire call-routing process. For example, in order to reduce costs, an administrator could configure a dial peer such that when a user in the Toronto office needs to connect to PSTN user in Frankfurt, the call is first routed over the IP WAN to the Frankfurt office, where a voice-enabled router dials the (now local) call to the Frankfurt PSTN. An obvious advantage in this scenario is that the long distance changes associated with originating the call in Toronto are reduced to a local call. In the same way that both POTS and VoIP peers can be configured, so can dial peers for both VoFR and VoATM.

Outside of helping to route calls along the correct path, dial peers are also used to apply different attributes to the various “call legs” that a transmission passes over between the source and destination devices. A call leg is simply the logical path between voice gateways (such as a router) or between a gateway and destination device. Examples of attributes that might be applied to a particular call leg include the codec used, QoS settings, and so forth. You will learn more about codecs and QoS settings upcoming articles.

Ultimately, the process of routing a call from a particular source to the correct destination is somewhat similar to a traditional voice call on the PSTN. When a user picks up an IP handset, the local gateway (such as the Cisco router) provides the user with dial tone. As the user keys in the number they wish to reach, these digits are forwarded to the gateway, which collects them until the appropriate dial peer can be identified. Once identified, the call is forwarded along the call leg to the next gateway (or destination or PSTN switch). At the most basic level, this is similar to how a PSTN switch or PBX makes forwarding decisions on a traditional voice network.

H.323 and VoIP Components

In order to appreciate how VoIP networks function, it is important to have an awareness of the base protocols and components used to facilitate the communications process. The primary protocol used to enable multimedia applications like voice and video to function over packet-switched networks is known as H.323, an ITU-T recommendation. Prior to the development of H.323, different vendors used a variety of different standards and proprietary methods of managing multimedia applications on networks, which led to interoperability issues. Today, VoIP equipment and software support the H.323 standard to ensure the highest level of interoperability possible.

The main function of H.323 is not as a transport or network protocol, but rather to perform call control and management functions on a packet-switched network (H.323 is considered a session layer protocol). Within the H.323 specification, two additional signaling methods are required for the transport of voice traffic:

  • H.225. The H.225 specification uses the Q.931 protocol (the same one outlined in the ISDN section of Chapter 11) for call control signaling between two H.323 devices. This includes functions like call setup and termination.
  • H.245. The H.245 specification creates a reliable connection between H.323 devices that is used to exchange information about the codec to be used, the capabilities of the devices (which allows them to determine a common level of compatibility during a session), flow control information, the port numbers to be used, and so forth.

When two H.323 devices attempt to establish a session, H.225 is first used to establish the call (using TCP for reliable transport). H.245 then creates a TCP connection for the purpose of exchanging information about the capabilities of both devices, identify the port numbers to be used, and open a logical channel over which the VoIP traffic will ultimately be passed. Finally, the voice traffic is transferred from one endpoint to another using the appropriate upper-layer protocol (to be identified shortly), which in turn uses the connectionless UDP protocol to transport the actual voice packets across the network. Notice that in this example, TCP is the transport protocol used for call establishment and management, since it is reliable. However, UDP is used for the actual transmission of the voice traffic, since it is time-sensitive.

Note: Remember that H.323 is the primary call control and management protocol used on VoIP networks, and that voice calls are initiated and managed using H.225 and H.245 respectively. H.323 allows the software and hardware of different vendors to interoperate, providing organizations with a high degree of flexibility in developing a solution appropriate to their environment.

H.323 networks consist of four main types of components, as outlined below. Not every network will require each of the components listed, depending upon the specific needs of the organization.

  • Terminals. A terminal is an H.323-compliant end-point such as an IP telephone or a PC running software such as Microsoft NetMeeting. All H.323 terminals must support voice networking, but data capabilities like video support are optional. Two H.323 terminals can communicate directly with one another without any additional components assuming that they know how to reach each other (via IP address, for example).
  • Gateways. A gateway is an optional component on an H.323 network that provides a variety of different services depending upon the needs of an environment. For example, a gateway can be used to allow an H.323-compatible device to communicate with another device that does not support H.323, such as a traditional phone connected to the PSTN. Similarly, a gateway can be used to translate between the codecs used on different H.323 devices if necessary. On a Cisco network, a gateway would be a voice-enabled router or switch.
  • Gatekeepers. A gatekeeper in another optional component on an H.323 network, typically found on larger networks. A gatekeeper is used to register H.323 devices and gateways, allowing them to find and establish sessions with one another as necessary. A gatekeeper also performs functions like call control, bandwidth management, and authorization for H.323 components. Gatekeepers are also capable of making decisions as to how traffic should be forwarded between devices, such as routing calls over a particular WAN link, or the PSTN if necessary. Gatekeepers can also be used to simplify the management of H.323 gateways. When multiple H.323 gateways need to be configured on a large network, it can become time consuming and administratively intense. Instead, a gatekeeper can be configured for an entire zone that includes multiple gateways, and then handle call control functions for all of those gateways in a centralized manner. On a Cisco network, a gatekeeper is typically a server running third-party software, or a Cisco IOS router.
  • Multipoint control units (MCUs). An MCU is another end-point on a LAN that allows multipoint conferences to occur on an H.323 network. For example, this might be an audio conference with three or more participants. MCUs are only required in this capability is required on the H.323 network. On an H.323 network, MCU capabilities might be found on a terminal, gateway, or gatekeeper.

As mentioned previously, when two H.323 terminals are connected to the same network and need to communicate, a gateway is not required. However, when an H.323 terminal (such as an IP telephone) needs to communicate with a non-H.323 device (such as a phone connected to the PSTN), an H.323 gateway is required. In this case, the gateway is typically a voice-enabled Cisco router. A voice-enabled Cisco router is a model that includes a voice module, which uses a digital signal processor (DSP). A DSP is the hardware that translates voice to IP, and vice versa.

Voice Networking Issues and Goals

A traditional voice network relies upon 64 kbps circuit-switched connections between the originator and the recipient of a call. While this dedicated bandwidth helps to ensure the quality of a call, it is also somewhat wasteful. At many points in any conversation, voice traffic is not crossing the circuit, since natural silences occur in human speech (although it certainly depends on who you are talking to). Even so, the circuit is connected, and the bandwidth is not available for other users.

In contrast, when a voice conversation is passed across a network using packet switching, a dedicated circuit is not created. Instead, the voice “data” becomes the payload of a packet or frame, which is subsequently packet-switched across the network according to the technology or protocol used. For example, with VoIP the voice data is the payload of an IP datagram, which is subsequently switched or routed across a network just like any other IP data traffic. Unless explicitly configured to handle VoIP traffic differently (via mechanisms like queuing), routers will treat the packet in the same way as any other IP packet – routing it from the source node to the destination across the “best” possible path. The initial benefit of this method is clear – voice traffic only uses network resources as required, and does not necessarily require the “reservation” of bandwidth resources (or a dedicated circuit) when voice traffic is not being transferred. This is an advantage, but it also presents some challenges. For example, because voice traffic is time-sensitive, techniques like QoS and compression need to be considered and implemented to ensure that packets arrive at their destination in a timely manner.

Through the implementation of technologies like VoIP, companies can also reduce costs, using existing WAN links to transfer packet-based voice traffic between locations, rather than expensive tie trunks. While existing WAN links may have enough excess capacity to handle this additional traffic, it is quite likely that they will need to be upgraded to support the additional traffic that would result from adding packet-switched voice traffic to the network. Although most voice networking vendors (including Cisco) are careful to remind you of the administrative benefits of managing a single converged network rather than separate voice and data networks, the reality is that moving to a single converged network usually requires significant staff training and more importantly, proper planning.

Examples of typical organization goals associated with implementing a VoIP network solution include:

  • Reduce costs associated with traditional PSTN connections and long distance changes.
  • Lower overall total cost of ownership
  • Improve user productivity
  • Reduce reliance on a single vendor for equipment or services
  • Enable new IP-based voice applications to be deployed
  • Move towards a single managed network for voice and data

Understanding VoIP

As you learned in previous articles in this series, traditional telephony relies upon connections to the PSTN via a telecommunications carrier. While companies can implement a PBX internally to reduce the need for access to the PSTN between corporate users, this is still a costly option, and usually requires a significant capital investment and ongoing maintenance expenses for an organization. Furthermore, the addition of new services or features often results in additional costs.

As companies look towards new ways of not only reducing costs but also adding new features to their voice networks, packet-switches telephony is becoming increasingly attractive. Because most companies have already made a significant investment as part of implementing their data network, they are looking for ways to leverage the network to support additional services, such as voice traffic. In the past, the ability to use a single network to provide both data and voice services to users was not practical; not only was the technology to do so still in its infancy, but the bandwidth and quality of service (QoS) techniques necessary to provide what users would consider to be acceptable service were just not available. However, given that many companies have moved to switched high-speed connection all the way to user desktops, this is rapidly changing. Not only is the bandwidth available, but the protocols and associated technologies necessary to implement a “converged” network that handles both voice and data traffic have quickly matured to make the transmission of voice over a data network not only possible, but also a practical solution for many organizations.

To begin, it is important to understand that the transmission of voice traffic over a data network is not limited to Voice over IP (VoIP). While VoIP may be the most popular method of transferring packet-switched voice traffic, it certainly isn’t the only one. Other methods include Voice over Frame Relay (VoFR) and Voice over ATM (VoATM). VoFR does not use IP, and is not an end-to-end solution. Instead, it is typically to create a virtual or emulated tie trunk link between PBXs in remote locations, using Frame Relay PVCs for transport, rather than expensive leased lines. Similarly, voice traffic can also be encapsulated within standard 53-byte cells for transport over ATM networks. Since voice traffic is bursty, VoATM is typically implemented using ATM Adaptation Layer 2 (AAL2) encapsulation, which provides variable bit rate services.

Traditional Telephony

While long considered two separate and distinct areas of focus, telephony and data networking today tend to have more in common that not. While the explosive growth of the Internet has done much to blur the lines between network data and voice traffic, you still need to be familiar with the basic concepts surrounding voice networking in order to appreciate the benefits associated with technologies like VoIP. In this section, we’ll look at some of the core concepts that you’ll need to be familiar with from the world of traditional voice networks, otherwise known as telephony.

The telephone has become such a ubiquitous piece of equipment that we almost all take it for granted. Once a telephone line has been installed and configured, an end user simply plugs in a handset, picks up the receiver, and (hearing a dial tone) dials the number they wish to reach. Most people never give a second thought to what is happening behind the scenes, or to the technology involved. While the types of services associated with telephony (such as call waiting or caller identification) have matured in the last two decades, the basic operation of the telephone network hasn’t changed very much at all in the last 50 years.

In order to provide you with a better understanding of telephony concepts, the voice portion of this series will explore five major areas that impact not only how the public switched telephone network functions, but also the critical terms, concepts, and equipment involved in the process. The areas to be looked at in the following sections include:

  • Signaling basics
  • Switching equipment
  • Links and user equipment
  • Phone numbers
  • Network signaling
  • Value-added services

As you read through these articles, keep in mind not only the purpose of each individual element, but also how they interoperate.

Introduction to Telephony and VoIP

In its latest iteration, the Cisco CCDA exam expects that you not only be familiar with the traditional data networking concepts outlined throughout this book, but also voice networking as well. This includes a basic understanding of not only standard telephony concepts, but also an appreciation of some of the concepts and issues associated with the transfer of voice traffic over data networks, using technologies like Voice over IP (VoIP). While you are not expected to be a telephony expert for the exam by any stretch, you are required to have a basic understanding of how a traditional voice networks such as the public switched telephone network (PSTN) function, including an understanding of key terms, concepts, and equipment. Along the same lines, you will also need to be familiar with concepts relating to the transmission of voice traffic over data networks, including interoperability, planning, capacity, and equipment issues.

As you read through this section, it’s important to keep in mind that a traditional telephone connection between two users is circuit-switched. When a call is initiated, a dedicated end-to-end 64 kbps circuit is created from the originator to the recipient. Because it is circuit-switched, all of the circuit bandwidth associated with the call is reserved for the duration of the call, even if neither party is speaking. Similarly, the path over which the call travels is the same for the duration of the call. Later in this series you will learn how technologies like VoIP differ by transporting traffic across packet-switched networks.