NET 226 - Designing Internetwork Solutions

Chapter 3, Characterizing the Existing Internetwork; Chapter 4, Characterizing Network Traffic


This lesson discusses more definitions of how the existing network functions. Objectives important to this lesson:

  1. Characterizing the network infrastructure
  2. Checking the health of the existing internetwork

  3. Characterizing traffic flow
  4. Network efficiency

Chapter 3

Characterizing the network infrastructure

The chapter begins with a quote from Abraham Lincoln which is meant to advise us that we need to know where we are and where we want to be in order to make choices about how to reach our goals. That being said, the point of this chapter is to determine the current state of a network.

The text advises us to create a set of network maps that show the locations of all major network components, segments, and their names and addresses. We should compare the maps we can make with data on network usage and performance to see where the network is stressed, and where it is working well. The text goes into more detail about this on page 60.

The author informs us that we could start mapping by creating maps of each location in a large network, but she seems to prefer an expanding map that supports the top-down concept.

  • We start at a high level, creating a map that shows a general schematic of sites and WAN links.
  • Each location in the high level map is then represented with its own map, with the next logical level of detail, perhaps at the level of Metropolitan Area Networks
  • If the second level of detail was about MANs, then the next level of detail should show the LANs in each MAN.
  • If we have just shown the LANs, we then break down each LAN, showing its components and structure.
  • In sufficiently large or complex LANs, we may want maps of each floor of each building. This would be helpful for staff who are installing or moving devices.

The text describes making maps of services on the network, and lists several common network services on page 61. It is a good idea to be aware of the services that are on a network, and those that the project requires that we add to the network. Making a map of such services may not be the most useful way to track them, because users tend to move about with laptops, tablets, and other portable devices. They require the services they need wherever they might be, so a map may not help you to understand the services are needed everywhere.

Skipping ahead to an example, the author shows us high level diagrams of enterprise networks on pages 63 and 64. You can draw charts like these with a service available through your email account. Sign on to your Baker email account, then click the Google Apps icon. Click More at the bottom of the list, and select the orange icon for Lucidchart Diagrams. You can make many kinds of charts, including network diagrams with Cisco symbols.

Back to the text, the diagram on page 63 is a schematic that shows the network connections to several locations from a central office in Grants Pass, Oregon. It may be useful to look at these locations on a map so we can recognize that the diagram is not drawn geographically. It is drawn to show the equipment being used, and the connections to each of the central and distant locations. In a set of top-down diagrams, each of these locations would have another diagram of its own, which would show the structure and services at that site.

The diagram on page 64 is a little harder to read. Each block in the diagram represents a function or service. Inside the block we see icons for the kind of equipment providing the service, but we are not seeing how many devices might actually be installed. We also see connecting lines representing communication media, but none of the lines show bandwidth details that were shown in the diagram on page 63.

The next several pages present more topics you should document about the network or plan in question.

  • Addressing and naming - The text makes some suggestions about naming standards to reflect the location, device type, and/or service the device provides. IP addressing is almost universal, so a logical addressing scheme and method should be chosen that will allow scaling and subdividing as needed. The author promises more about this in a later chapter.
  • Wiring and network media - The type and grade of cable used inside and between buildings should be documented. It may be helpful to know the terms listed in the text:
    • vertical wiring runs from one floor to another
    • horizontal wiring runs from a wiring closet to a wallplate (which may be in the floor, or under it)
    • work-area wiring runs from a wall plate to a host you are connecting to a network.

      The author makes an odd observation about most wiring being assumed to be less than 100 meters long. The general rule about Unshielded Twisted Pair wiring is that it doesn't work if the total run from a host to a network connectivity device is over 100 meters long.

  • Architectural and Environmental constraints - It may not be possible to run network cable through an area that your customer does not own. It is also possible that you cannot run a cable if the site is protected by local laws, such as being a historical site. These issues may lead to considering wireless solutions for part of your network. The text also addresses supportive services that your new or expanded network will require, such as air conditioning, heating, ventilation, power, protection from EMI, and a secure space for all the equipment.
  • Wireless concerns - A wireless network solves some problems but adds concerns that a wired network does not have. The author summarizes several of them on pages 69 and 70. Note that a wireless signal will fade over distance, as will a signal in a wire, but at a much faster rate. If the signal encounters anything, the signal can be affected in several different ways.
Checking the health of the existing internetwork

The purpose of this section is to take baseline measurements of the existing network, so that you can tell whether your changes to the network introduce improvements or problems. The text cautions us that we must also make sure that improved performance is one of the customer's goals. If the main objective is to reduce costs, a performance hit may be acceptable if it is not too large.

The text offers several pages of ideas for measuring the state of the network, but not a lot of detail on how to do most of it. We can get a lot of the ideas by going through the Network Health Checklist on pages 83 and 84. Go over that list and we will discuss it on this week's discussion board.

Chapter 4

Characterizing Traffic Flow

This topic asks us to identify major traffic sources and stores. The key word, as I have indicated, may be "major". There are usually some data stores that are larger than others. The text defines a data store as any collection of data, on any device or medium, either online or offline. It may be useful to determine user communities, to ask their technicians about where data is stored for and by these groups of users. The text also suggests taking measurements about the amount of data flowing between network and internetworking devices, but use caution interpreting these numbers. Data flow may be limited by the channel bandwidth. Watch for channels that are frequently operating at their maximum, and recommend upgrading them.

The text also cautions us to watch for connections that are by nature asymmetric, such as ADSL lines. We should not measure them against symmetric bandwidth connections as though they would or could operate the same way. The text lists several common network flow types:

  • terminal/host - typically asymmetric, most traffic is from the host (a server or a mainframe) to the terminal (a dumb terminal, or a computer running terminal software)
  • client/server - may be symmetrical, but could be unbalanced in either direction
  • thin client - the server does most of the work in these cases, and lots of traffic flows from the server to the client
  • peer-to-peer - may be symmetric; the text says that it is symmetric, but this depends on the location of frequently used resources
  • server/server - the text mentions that this traffic includes servers advertising services to each other and to the network
  • distributed computing - Some situations require data to be processed on multiple machines because of the size of the data to be processed or because that is the best way to simulate the processing power needed. An example is the SETI at Home project, which shares radio telescope data with the computers of volunteers, is processed on those computers, and the results are uploaded to the central project computers. As the text explains, this situation can be unpredictable. There may be frequent or infrequent exchanges from the task manager (central location) and the distributed computers (various locations)
  • Voice over IP - the text tells us we should expect that the flows to set up and take down connections (client-server) will be separate from the flows of actual voice traffic (peer-to-peer).

The text tells us in every chapter that we should be asking what applications are being used to cause the data flows. The spin in this chapter is to estimate the bandwidth they would use if they were not restricted by any usual means. Estimating the bandwidth can be done for many applications if you can get the data the text suggests we should use:

  • number of stations using the application
  • average idle time between frames (out of the time spent using the application)
  • time to transmit a message, once access to the medium is given

The text offers some examples of the file sizes of several types of data transmissions. We cannot count on these as being applicable to all applications. Some will be larger, for example, web pages using embedded video and animated graphics.

The text also mentions sources of traffic not bound for specific devices, such as broadcasts and multicasts. Broadcasts are typically the worst offenders.

Network Efficiency
  • As the text has mentioned before, larger frames are often more efficient than smaller frames, so larger frame sizes are preferred except when protocols limit their size (e.g. ATM).
  • Windowing adds to efficiency by allowing stations to send several packets at once and to receive one acknowledgment for all of them at once. In a good connection, the window size (the number of packets sent at a time) may be adjusted up. In a bad connections, the window size may be adjusted down.
  • Quality of Service requirements can be set for a network without regard to what the network can actually do. This is a poor procedure, so you should be careful not to become a victim of it.

Week 3 Assignment: Chapters 3 and 4

  • From chapters 3 and 4:
    • Study the Network Health Checklist on pages 83-84.
    • Chapter 3: page 85, Hands-on project, Questions 1-4,
    • Chapter 4: Answer the four questions about the Design Scenario on page 115.
  • Read Chapter 5