|
|
NET 226 - Designing Internetwork Solutions
Chapter 3, Characterizing the Existing Internetwork; Chapter 4, Characterizing
Network Traffic
Objectives:
This lesson discusses more definitions of how the existing network
functions. Objectives important to this lesson:
- Characterizing the network infrastructure
- Checking the health of the existing internetwork
- Characterizing traffic flow
- Network efficiency
Concepts:
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.
|
