|
Choosing routers and switches for enterprise.Studying for the CCNA as usual I started to wonder how I would choose routers & switches if I was in a job role which required making these purchases. |
|
|
ladino
Member
2013-Aug-11 11:14 am
Some of the questions that need to be answered before making purchasing decisions are..
What is the overall goal of getting the said equipment? What is the budget? Does RIO study warrant the purchase? Is this proprietary technology/equipment that only one ressellor/manufacturer supports? Will you lock yourself to this one manufacturer if that is the case? What is the thru-put of the hardware? Doe this equipment have room for future growth/needs? Does your company have IT staff competent enough to maintain/support the said equipment?
|
|
|
|
ladino, thank you for your fast reply. Your questions have narrowed down my question.
One of your questions that I would focus on for now would be, 'What is the thru-put of the hardware?'
How could I determine which router I would need - what would the metric / formula be?
If I had x users at main campus - x users at off site - x users at small office. How could I translate number of users in the best hardware selection.
Starting small - if I had to select a router for one of our small offices. Employees being 20 to 30.
Would I select something like the Cisco 800 Series ISR, 1900 Series ISR, Cisco 2900 Series ISR, or something completely different.
For the sake of this discussion, my company only purchases Cisco equipment. |
|
|
to hellohello5
The below link shows H/W thruput comparison chart » www.cisco.com/web/partne ··· ance.pdfYou will also have to go thru the Cisco router comparison pages to see which platform fits your bill » www.cisco.com/en/US/part ··· Featured |
|
|
ladino,
Thank you for the fast reply. I was able to look at the H/W thruput comparison chart, but received the following message when trying to view the Cisco router comparison pages:
Forbidden File or Application
The file or application you are trying to access may require additional entitlement or you are trying to access a file with an invalid name. Additional entitlement levels are granted based on a users relationship with Cisco on a per-application basis.
If you feel you have reached this page in error, please try one of the following methods to locate your document:
If you are manually entering the URL into your browser location bar, be sure to include the file name of the page you are trying to access (file names typically end in .htm, .html or .shtml). Use the Search feature located in the upper right section of this page. Return to the Cisco.com Home or select a primary site area from the top navigation bar. Consult with your Cisco Account Manager to confirm you have the appropriate entitlement to access this page. If you would like to contact someone about this problem, please click on the Contacts & Feedback link below. |
|
|
to hellohello5
Do a search for 'Portable Product Sheets Routing Performance' on Google or Cisco's website. It should be the first link |
|
|
ladino,
Still a little confused with how per pps and Mbps breaks down per end user.
thx, |
|
|
to hellohello5
Try those URLs again, just remove "partners" from the links.
One way to look at it is to break down the various "blocks" by function. One way is this :
From a user end - how many users will you be supporting? - do the users need GigE connectivity? Or will 100Mbps be sufficient? - what are the typical traffic pattern(s) users will be using? - if 100Mbps is enough for a user, will a GigE uplink be sufficient, or will more be needed?
From a server farm perspective - how many servers will there be total? - do the users need GigE connectivity? Or will 100Mbps be sufficient? - what are the typical traffic patterns of the servers? - will there be loadbalancing, and what method? - will virtualization / partitioning be needed?
etc, etc, etc.
For all of these, one overarching thing to keep in mind is a) where will this be in 3 to 5 years, and b) is it scalable if there is an unexpected growth spurt?
If you want to dig more into this from a Cisco perspective, look into the CCDx track and materials.
Regards |
|
|
aryoba
MVM
2013-Aug-12 7:18 am
How many users using the network is less relevant compared to how much bandwidth and/or throughput expectation is. To illustrate, there is a 7-person company that uses 10 GigE connectivity to data centers and HQ due to bandwidth/throughput requirement. |
|
|
20 - 30 users making Citrix connections back to the main campus / doing medical charting. |
|
|
aryoba
MVM
2013-Aug-12 11:27 am
You may want to reach out to Citrix in order to get the precise bandwidth/throughput requirement.
That aside, you should recommend at least 1 GigE for medical campus environment since those charting and imaging can quickly consume a lot. If I were you, I would recommend 10 GigE for growth anticipation.
If you like Cisco, you can go with Nexus 7000 series. Depending on your security zone requirement, a firewall such Juniper SRX 650 or larger model is recommended. |
|
jester121 Premium Member join:2003-08-09 Lake Zurich, IL |
to hellohello5
Then again, for a Citrix app environment you might not need much bandwidth at all for a remote site -- just sending over screen refreshes and key strokes is very efficient, especially with Citrix's optimization and compression technology. For that a Nexus could be ridiculous overkill...
What kind of WAN connectivity is in place now? That would help ballpark a router/switch choice. I don't know about your environment but in most places throwing down a switch with 1000x the capacity and 20x the cost of what you actually need doesn't go over very well. |
|
|
to hellohello5
Citrix is more latency than bandwidth sensitive, from my personal (networking) experience.
I get more tickets about "citrix slowness" for sites with big pipes to the Citrix backend (T3 / OC3 class), but I STILL can't get a straight answer from the inhouse Citrix support guys "is x latency within expected specs or not? Can you get Citrix to answer that, please?!"
citrix guys : [collective blank stare]
Regards |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK |
to hellohello5
Throughput is not the be-all-end-all thing you need to worry about when it comes to switching.
Sure it is one thing to consider, but theres something that might be even more important: buffers
Buffers are the hidden rake in the pile of leaves that will spring up and smack you in the face if you dont tread carefully. They could make you regret spending tens of thousands of dollars on shiney new switches if you get the wrong ones.
For example. If youre doing a lot of bandwidth intensive work, say video production, sure you want throughput to move stuff around quickly, but youre probably going to need a switch with deep buffers to handle the large amounts of data being pumped in to the network.
Likewise, in a datacentre where traffic is likely to be more intense, deep buffered switches will likely be necessary to minimise packet drops etc.
Then again, if you have a typical office environment with people opening up spreadsheets and documents from a file server, the occasional email etc, then a switch with shallow buffers would probably be fine.
Getting details of the buffering scheme can sometimes be tricky, but do your research and talk to your sales reps and see what you can find out. If youre dealing primarily with Cisco gear, mailing lists like cisco-nsp are a gold mine.
But I would worry less about throughput. These days, with most mid to high end switches being based on silicon and ASICs, pretty much every port will do line rate.
Read up about buffering mechanisms and techniques, and examine your short list of switch candidates side by side and work out which one will perform the best. |
|
|
to HELLFIRE
Talk about hitting the nail on the head Hellfire can you be more descriptive and detail any solutions you have implemented regarding the Citrix latency issue. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to TomS_
said by TomS_:For example. If youre doing a lot of bandwidth intensive work, say video production, sure you want throughput to move stuff around quickly, but youre probably going to need a switch with deep buffers to handle the large amounts of data being pumped in to the network.
Likewise, in a datacentre where traffic is likely to be more intense, deep buffered switches will likely be necessary to minimise packet drops etc. correct -- but just as important as buffering, is how the switch is actually forwarding traffic. i don't need deep queues if i'm dealing with switches that perform cut-through switching (a la cisco nexus line). i keep my buffers small at the edge and only queue/buffer when i need to move to store-and-forward (usually when i'm performing classification and queueing at my distro layer). knowing how a switch behaves, and more importantly, when traffic flows will prompt a given forwarding behaviour -- is just as important as knowing queue depth and oversubscription. q. |
|
TomS_Git-r-done MVM join:2002-07-19 London, UK |
TomS_
MVM
2013-Aug-15 3:25 pm
Thats kind of why I closed off my post with said by TomS_:Read up about buffering mechanisms and techniques, and examine your short list of switch candidates side by side and work out which one will perform the best. Cause even buffers arent the be-all-end-all. |
|
DarkLogixTexan and Proud Premium Member join:2008-10-23 Baytown, TX |
to hellohello5
Also consider how much are they willing to pay for features that can provide more potential uptime.
for instance do you want/need dual powersupplies, or fan trays that can be swapped without powering it off.
these can be premium features that might or might not be worth it.
for instance say a 3945e vs 2 2951's, with the 3945e you get dual powersupplies and its possible to change the fan tray while powered on, with the 2951 you could have 2 complete routers and do HSRP (or some variant) on the wan and use a routing protocol on the lan (or even HSRP on both lan and wan)
so then in the case of the 3945e you get redundant features and more throughput, with the 2951's you could have a whole other unit for failover. |
|
DarkLogix |
to TomS_
said by TomS_:Thats kind of why I closed off my post with said by TomS_:Read up about buffering mechanisms and techniques, and examine your short list of switch candidates side by side and work out which one will perform the best. Cause even buffers arent the be-all-end-all. And then on asymmetric links large buffers can actually cause latency issues, but if your working with your lan and switches then its not relevant. |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to TomS_
said by TomS_:Thats kind of why I closed off my post with said by TomS_:Read up about buffering mechanisms and techniques, and examine your short list of switch candidates side by side and work out which one will perform the best. Cause even buffers arent the be-all-end-all. i guess i should learn to read better. ;-P hours of con-calls make the mind into butter..... q. |
|