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]