At 9:52 PM +0000 1/5/03, The Long and Winding Road wrote:
>This one came up at the water cooler the other day.
>
>When going through the design process, what factors are useful for
>determining router and switch equipment requirements. In other words, how do
>I know when it is time to upgrade my router? Not numbers and types of ports,
>but what factors should be considered when determining if a router or switch
>will have sufficient horsepower to serve an organization's need for the
>purpose and time frame required.
To start with, there are two kinds of horsepower: control and
forwarding. If, for example, you are forwarding-limited, a 7500 might
be better than a 7200, and vice versa (simplified example).
Sometimes putting in several smaller routers, intelligently coupled,
is better for both performance and availability than One Big Box.
General management, however, tends to love One Big Box solutions, and
the vendors know it.
There are going to be times where you need to trade off something
that could be tuned to save you an upgrade, versus the reality of
whether you have in-house staff that understand how to do that
tuning. Even more than how to tune, that staff has to be committed
to collecting long-term statistics.
>
>For example, if I were to determine that my requirement is ATM DS3, simple
>QoS ( for voice prioritization ) my non voice data will flow at 10 megabits
>peak on the WAN and typical flow of 3 megabits, and that my voice traffic
>will use G729 and end up with about 1 megabit average and 3 megabit peak.
Why DS3 rather than fractional DS3? Big operational cost distance in
having the connector that can handle the pipe, buying a full pipe.
In fact, you might very consciously get a DS3 interface even though
you know your router can't handle full DS3 throughput, because you
know that you have enough traffic to get DS3 economies of scale. A
rough rule of thumb is that DS3 tends to be cheaper per bit once you
have 6 or 7 DS1's of traffic, not the 28 it _could_ handle.
>
>I can look at things like Cisco's published numbers on PPS, I can set up a
>test lab, simulate traffic flow, and check out CPU usage. I suppose if I
>were very sophisticated, I could measure throughput, latency, etc.
>
>I understand that as with all things networked, the answer is "it depends".
>things like access-lists, process switching, policy routing, etc can effect
>things.
You really have three alternatives:
Modeling and simulation, which covers a wide range of tools of different
complexity and cost,
Benchmarking, if you have confidence you can scale what you find out,
External review, which may or may not be a one-shot deal. Good
architectural consultants do as much as they can to teach you do it
yourself, but will warn there are times that you are going to need
an expert to look at certain specifics.
I cannot emphasize strongly enough that a regular
performance/capacity program, so either internal or external staff
can look at trends, is vital. You also may need functional guidance
from top management, so you can consider major new functionality such
as encryption, QoS-sensitive traffic, high availability, call centers
and other intelligent telephony applications, et.
>
>Some of us are just debating whether or not CPU utilization is the "best"
>measure. Over what period? What other factors might be best brought into the
>mix of factors to consider?
Especially with higher-end routers, CPU utilization doesn't help with
bandwidth, because the separation between control and data planes
gets more and more explicit. CPU utilization does tell you something
about filtering, traffic shaping, etc.
There are an assortment of RFCs and I-D's that talk in
vendor-independent terms, mostly about forwarding but several now on
the control plane. Go to the IETF Working Groups page and look
through the BMWG and IPPM group document lists,and even join their
mailing list. RFC2544 is a key to forwarding.
To understand the concept of control vs. data plane separation,
although, frankly, on a fairly fundamental basis with respect to what
people are doing privately in research lab, check out the FORCES
working group.
As far as processor load from routing, there's a big difference in
approaches between internal and external control load. Frankly, I
sometimes think that before investing in new hardware, unless you are
SURE your network is optimally designed, you might well save money by
getting a good architectural consultant to review your topology, use
of defaults, aggregation, etc.
Sometimes, faster hardware is simply a way of getting the wrong answer
faster.
>
>Just wondering.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=60373&t=60373
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
