FAQs: Planning a network infrastructure design project.

What is the purpose of the network being designed?

FAQ - Before beginning any network infrastructure design project for a client, the first
question to ask is what the purpose of the network is. Knowing the answer to this
question is vital as you scope out the project.
This is the question that you should use to probe what kind of applications the client is going to
be using on the network. By knowing the applications, you determine what speeds and other
qualities you need in the network. Customers often don't know the exact amount of bandwidth
they need, or other features, but bandwidth is usually the overriding one.
One should measure application requirements from real-world examples, so if you can spend
time monitoring the network to determine average bandwidth used by certain applications, you're
going to be able to do a much better job.
Latency is another quality that you should investigate. Some applications require low-latency
networking, like NFS, [which] really requires less than two milliseconds of latency, while other
things, like FTP, can work on very high-latency networks.

Why change a customer's network configuration?
FAQ - Before beginning a network redesign project, it's important to understand the
client's current network configuration. Learn why you need to know how the network is
configured and why you're likely to have to work with ad hoc networks.
Get the client to talk about their current network [configuration]. Usually we're not so lucky that
it's a [new] deployment and then we can build something from scratch. There's usually some
kind of pre-existing network. You want to identify what sort of problems the [IT] person has,
because a new network [configuration] should alleviate some kind of pain.
Sometimes customers have an ad hoc network. Maybe a couple of smaller companies have
merged and things haven't been cleaned up, or maybe you're just a really small company --
initially the network was ad hoc and the request is to build a supported and consistent network.
Sometimes it's a growth issue -- you have a company that had a great [network] design, but
they've grown such that the old design isn't working anymore and they need to upgrade.
Sometimes it's speed and lack of reliability -- in these cases it's important to determine what are
the bottlenecks. Certain applications that are bandwidth hogs need to be adjusted for [as] part of
the design

What service-level agreement does your networking client expect?
FAQ - A service-level agreement (SLA) determines how much network downtime is
acceptable to a client. Learn why 100% uptime is unrealistic, and discover why the SLA
will dictate a number of important network design decisions.
What is the client's IT budget for the network design project?
FAQ - While all clients have expectations for their network design projects, not all have
allocated the money needed to accomplish their objectives. Learn why asking about IT
budget will help you and your customers get more clarity about what can and can't be...
The [IT budget] probably is the most important question [to ask clients], and not for reasons of
greed or commission, but because it's about setting expectations. You don't want to be in an
environment where someone wants a billion-dollar network for $50, but you also want to make
sure their budget is in sync with their expectations. There are certain design patterns that fit
different budgets.
For WANs, if they want to go on the cheap, [they can use] VPNs over the Internet to connect
buildings. This is very inexpensive, but it's not very reliable or very manageable.
A little bit more expansive, but more reliable, is using a multiprotocol label switching (MPLS)
provider. These providers can run your WAN for you -- they've run a global or regional WAN,
and you're sort of renting a chunk of it. Some MPLS providers are more high-end -- they do less
oversubscription (how have they allocated how much bandwidth is going to be used on a certain
link). So if you have a [MPLS] link that's a 10-Gigabit link, have [they] sold 10 Gigabits of that
capacity, or have [they] sold 100 Gigabits of that capacity and are hoping that nobody is going to
use their full capacity at any one moment? And then there are custom solutions because some
customers just have the need for dedicated links, either for security reasons or because they just
need that much bandwidth. On the LAN side, there are also different design patterns that match
different costs levels, like with a network where a single fault can take down the network or
disrupt users versus N+1 designs.


What networking skills does your client's in-house IT staff have?
FAQ - Learn why the level of networking skills your client's in-house IT staff has will
determine the nature of your engagement with the client.
Finding out what skills the client has in-house is important because it determines [at] what
technical level you'll be able to have your conversation, but also what technical involvement [the
client] wants after the installation is done.
Are they highly technical and just want assistance designing and spec-ing out the details of a
network design, and then they're going to run the network after that? Maybe they want project
management help, or the nontechnical process of making sure you're coordinating all the vendors
and making sure everything gets done.
Are they just somewhat technical? Maybe they can handle add/move/change requests, but [are]
not technical enough to configure new VLANs or add new connections to new buildings.
Or maybe they're not technical at all and need a fully managed solution where you're monitoring
remotely and you're contacting them about periodic maintenance and that kind of thing.
Often clients want some kind of hybrid. Their requirements or their skill level for the LAN is
different from the WAN. Typically [these] users can support their own LAN, ports and
add/move/change requests themselves but want a more managed solution for the WAN because
that's often dealing with vendors and telecoms and a whole different set of terminology.
---------------------------------------------------------------------------------------------------------------------
Calculating network bandwidth
There are two basic steps to calculating bandwidth:
Determine the amount of available network bandwidth.
Determine the average utilization required by the specific application.
Both of these figures should be in bps. If the client's network is GbE that would give you
125,000,000 bytes per second. This is computed by taking the 1000 Mbps (for a Gigabit
network); which is 1000 million (or one billion) bits per second and dividing it by 8, to come up
with the bytes.
After ascertaining the client's network bandwidth, you'll have to determine how much bandwidth
each application is using. Use a network analyzer to detect the amount of bytes per second that
the application sends across the network. To do this, you'll need to enable the Cumulative Bytes
column of your network analyzer. After you have enabled this, then you have to:
Capture traffic to and from a test workstation running the application.
In your decode summary window, mark the packets at the beginning of the file transfer.
Follow the timestamp down to one second later and then look at the cumulative byte
field.
If you determine that your application is transferring data at 200,000 bytes per second, then you
have the information to perform the calculation: 125,000,000 / 200,000 = 625. In this case, the
network will be fine even if there are several hundred concurrent users. Look what would
happen, though, if you had a 100 mbps network. You would then have a network that could not
support more than approximately 60 users running the application concurrently. Bandwidth is
indeed very important!
I like to capture data in 10-second spurts and then do the division. I also like to check multiple
workstations to make sure that the number is reflective of the general population. You will also
have to determine how many concurrent users you will have. Obviously there will be a
bandwidth difference between two concurrent users and 20.
What are the physical network considerations?
There are many physical [network] considerations to take into account. Specifically to LANs,
what kind of copper you are going to run to the desk is one of the first considerations. There are
different categories of copper cabling: CAT 5, CAT 5E, CAT 6 and so on. The better [cables]
can run higher-speed networking, but they cost more. I believe that wiring is usually a 30-year
investment in a building, so I usually tend toward the higher-quality cabling, because even
though we might be doing 100-Megabit [speeds] to the desktop today, Gigabit to the desktop is
becoming the bare standard now, and [speeds will be] even faster in the future.
If there's new construction, what I find is that the cost of running wiring is dominated by the cost
of construction. If the walls are going to be opened up because it's new construction, it doesn't
matter if you're running CAT 5 or 6 -- the walls are open, that's the expensive part, so run the
best stuff you can.
Network design checklist: Six factors to consider when designing LANs


You finally have the consulting project you've been waiting for: A customer is building a new
office and has asked you to design their entire local area network (LAN), as their present
infrastructure is outdated and has ports failing by the day. This is a consultant's dream! However,
it can become a nightmare for you and your company if you design the network improperly. Let's
look at some big network design issues to consider when designing a new LAN for your
customers.
Plan the network's complexity to be in line with the customer's IT expertise.
Switches and routers come with hundreds of features and functions. However, engineering too
many bells and whistles into the network can create support problems in the future, if the
customer's IT staff does not have some basic understanding of the features and functions you
implement. Recognize the business's needs without making the network overly complex.
To PoE, or not to PoE?
More and more customers are deploying wireless LAN technology and IP telephony. Wireless
LAN access points are easiest to install when Power over Ethernet (PoE) is available. IP
telephony utilizes phones that connect to and draw power from the LAN. The days of the
traditional PBX system are numbered; every vendor out there is moving towards IP PBX systems
and handsets. Many customers will tell you "We are not using wireless," or "We will never move
to IP telephony." They may not now (at least as far as their manager knows), but if you do a
good job on this project, your customer will keep their equipment for at least three to five years.
You'll do a great service to your customer if you can convince them to purchase PoE switches
now. Then, when the CIO decides to move to WLAN or IP telephony in 18 months, the non-PoE
switches won't have to be replaced.
10 Gigabit Ethernet? 100 Gigabit? Do I need that?
Just because 10 Gigabit Ethernet is here today and higher speeds are coming does not mean that
you need those ports all over the LAN. All too often customers purchase the fastest equipment
possible thinking they need it, even though their existing 100 Mbps network is only running at
5% capacity. While it is definitely prudent to ensure that core switches can support these higher
speeds, you may be advising the customer to waste a lot of money if you tell them that 10
Gigabit switches are needed everywhere.
Redundancy.
Network uptime becomes more critical every year. Spend time planning a design that provides
network redundancy from a physical and logical perspective. For example, utilize dual fiber-
optic uplinks from the wiring closets to the core switches. Ensure that chassis-based core
switches have dual CPU cards. Be sure to think about items like default gateway redundancy.
You can design the most redundant physical network in the world, but if it's not properly
configured to provide Layer 3 IP Default Gateway redundancy and a failure occurs, your
customer's network will grind to a screeching halt and you can be sure they will call you to ask
why.
Standards and maintenance.
When designing a corporate network, try to standardize on a few different types of devices, as
opposed to using a different type of switch in every wiring closet, even if all your equipment is
from the same manufacturer. Standardizing on a few different types of hardware simplifies
configuration and troubleshooting. It also allows the customer to keep cold spares of each device
with next-business-day maintenance, allowing for more rapid and cost-effective responses to
device failures.
Network management tools.
While these always seem to be left off purchase orders, network management tools are
invaluable in providing maximum network uptime. Software that periodically backs up all device
configurations to a share on the network is simple but extremely useful. Also, think about the
following scenario: Two switches provide IP Default Gateway redundancy on your customer's
network. One of them fails, but you don't realize it because the network is redundant. When the
other one fails, the customer experiences a total network outage. This can be easily avoided by
using a simple tool to ping all network devices and report on their status.
There are many more items to think about when designing a local area network for your
customer. These are some of the big ones that will hopefully get you pointed in the right
direction and, more importantly, provide you with a happy (and returning) customer.


















Calculating bandwidth on customer networks
By Ken Milberg
SearchNetworkingChannel.com
ContentSyndication
Digg This
Stumble
Delicious
Google Fusion
Service provider takeaway: By calculating bandwidth when designing a network for customers,
network service providers can ensure that the network can handle the workload users are putting
on it. Determining how many bits per second travel across the network and the amount of
bandwidth each application uses are key calculations that are vital to building and maintaining
a fast, functional network.

As most network administrators can attest, network bandwidth is one of the more important
factors in the design and maintenance of a functional LAN or WAN. Unlike a server, which can
be configured and reconfigured throughout the life of the network, bandwidth is one of those
elements of network design that is usually optimized best by configuring the network correctly
from the outset. As a service provider, how can you determine the bandwidth your customer
needs when designing the network? What specific considerations apply and how can you put
yourself in the best position to help your clients? These are some of the questions that we'll
answer in this tip.
Bandwidth refers to the data rate that is supported by the network connection or the interfaces
that connect to the network. It is usually expressed in terms of bytes per second (bps). Network
bandwidth represents the capacity of the network connection, though it's important to understand
the distinction between theoretical throughput and real-world results. For example, a 1000BASE-
T (which uses unshielded twisted-pair cables) Gigabit Ethernet (GbE) network can theoretically
support 1,000 megabits per second (Mbit/s), but this level can never really be achieved in
practice because of hardware and systems software overhead. It is this very point that makes
calculating bandwidth a challenge.
So how do you determine how much bandwidth your customer needs? The process begins with
asking the right questions -- What applications are they running, and what is the performance
service-level agreement (SLA) for these applications? I know some network managers that are
only concerned with how many users are on a VLAN. What you really need to know is what the
users will be doing on the network. It's possible that 200 users will cause less of a bottleneck
than a group of three users that really beat the heck out of the network because of some funky
client server application.
Calculating network bandwidth
There are two basic steps to calculating bandwidth:
Determine the amount of available network bandwidth.
Determine the average utilization required by the specific application.
Both of these figures should be in bps. If the client's network is GbE that would give you
125,000,000 bytes per second. This is computed by taking the 1000 Mbps (for a Gigabit
network); which is 1000 million (or one billion) bits per second and dividing it by 8, to come up
with the bytes.
After ascertaining the client's network bandwidth, you'll have to determine how much bandwidth
each application is using. Use a network analyzer to detect the amount of bytes per second that
the application sends across the network. To do this, you'll need to enable the Cumulative Bytes
column of your network analyzer. After you have enabled this, then you have to:
Capture traffic to and from a test workstation running the application.
In your decode summary window, mark the packets at the beginning of the file transfer.
Follow the timestamp down to one second later and then look at the cumulative byte field.
If you determine that your application is transferring data at 200,000 bytes per second, then you
have the information to perform the calculation: 125,000,000 / 200,000 = 625. In this case, the
network will be fine even if there are several hundred concurrent users. Look what would
happen, though, if you had a 100 mbps network. You would then have a network that could not
support more than approximately 60 users running the application concurrently. Bandwidth is
indeed very important!
I like to capture data in 10-second spurts and then do the division. I also like to check multiple
workstations to make sure that the number is reflective of the general population. You will also
have to determine how many concurrent users you will have. Obviously there will be a
bandwidth difference between two concurrent users and 20.