One critical drawback that I have found in researching managed-switches, and one that I have some past experience with is that anything with "lots" of firmware is going to have lots of issues associated with that firmware.
We are in the middle of researching rackmount gigabit switches (48 port). It looks like for 48 ports, our only choice is managed switches (Dell, Cisco/Linksys,HP, etc). What I want to know, that I can not find out much about is the boot-time for various managed switches.
If you own one, can you please answer with the model number, and the cold boot time in seconds. I have read online that Linksys (now Cisco) SRW series sometimes take almost 5 minutes before they are fully booted up, and that is an unacceptable cost for us.
I particularly want to know about Dell PowerConnect managed switch bootup time (model 3548 and 5448), and would like to confirm the 5-minute boot time on the SRW2048 or similar model, and any HP ProCurve boot up times.
The composite of all those figures ought to form an interesting overall picture of boot-up times on managed switches.
[UPDATE: Further to those who think I am asking about boot-up time because I am silly enough to think that has anything to do with the actual operational performance, I have updated the above, to make it more clear that I'm interested in understanding the norms of this hardware type, not in forming an overall impression on switch performance based on one edge-case of boot time. Thanks for your time.]
[UPDATE2: I'm going to add my own answer for the managed SRW switch that we bought yesterday, a Cisco (former-linksys) model ... Is there anything wrong with not accepting AN ANSWER On this? I'd like to keep this question open to collect data points which might be useful to others, as well as to myself. In general, the longest time is 5 minutes, and the shortest are 1-2 minutes, with a nifty exception for the one HP ProCurve mentioned, which is super fast. ].
-
I can't imagine a reason why you would be rebooting switches often enough in any environment to even worry about this. Any reboot of a switch should be done in a maintenance window and then a few minutes isn't going to be a big deal.
I'm not sure how you think that booting time reflects the switch performance. Switches, like most embedded devices, will have an underpowered CPU of some sort which is responsible for the booting process and maybe a few functions such as running the cli or web interface. But almost all of the networking functions are going to be handled by purpose built ASICs and won't involve the CPU at all.
Zypher : +1 started writing the same thing, then got distractedDan : +1 I agree, why is switch boot time so important? Any/all planned downtime is just that, planned.Warren P : Unplanned happens all the time. We had switch failures here last week. You just need one day where you have multiple switch problems, and you have to re-route the whole office network, and you start to care about little things like this. Because it's 5 minutes PER cold boot. And on a day when you had 10 of them, it's annoying.3dinfluence : Fair enough but it's been my experience that outages due to a switch failure is very rare, but it does happen. If you had to reboot a switch 10 times in a day then boot time isn't going to change the disruption drastically. The end result is going to be an up and down network resulting in lost productivity if we're talking end users. Would you rather a switch that takes 5 minutes to boot but would have fixed the problem in 1 reboot or a switch that takes 3 minutes to boot but took 5 reboots to work out your issues. I'm just saying that boot time may not be the win you're looking for.Farseeker : Agree with everything you wrote, but -1 cos it's not what the OP asked for (don't worry I gave you a +1 on your other answer so you're still 8 rep ahead!)From 3dinfluence -
SRW2048 from a cold start running 1.2.1, 97 seconds
tsavo:~ mcd$ date Mon Apr 12 14:04:48 EDT 2010 tsavo:~ mcd$ ping 192.168.24.70 PING 192.168.24.70 (192.168.24.70): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 ... snipped ... Request timeout for icmp_seq 85 64 bytes from 192.168.24.70: icmp_seq=86 ttl=64 time=45.284 ms ^C tsavo:~ mcd$ date Mon Apr 12 14:06:25 EDT 2010Warren P : Thanks for providing what I asked for. Lots of people can't understand why measuring performance is even important. An unmanaged switch is back online in very little time. The time it takes a managed switch to boot up is something that the network admins need to take into account. It may not happen that often, but when you have people asking "when will the system be back up", it's unexpected to have to say "well the server takes 3 minutes to boot, but our switch takes 5 minutes".kmarsh : +1 for actually answering the question, instead of questioning the question. While I initially had the same "why" reaction, I suddenly realized that there are many systems that have contractual uptime requirements and penalties.3dinfluence : @kmarsh If there are uptime requirements such as a SLA then the network needs to be designed with that in mind. That's not always possible at the edge of a corporate network but if you keep the edge switches to 24 ports the risk on affecting productivity can be minimized. The chassis based switches that you'll find at the core of most larger networks deal with this type of stuff quite well. With multiple hotswap PSU's and controller modules. But like you said in your comment you can also do things at the network layer w/ RSTP/PVST, dynamic routing protocols, and ethernet bonding. -
Ok here's another data point for you from a PowerConnect 5324. Which is a few generations behind the models you're looking at. So take it for what it's worth.
So the ping command below was sending 1 ping per second to you can see from the output below that it took 108 seconds from the point where it went down from the
reloadcommand to the point that it started replying again.PowerConnect 5324 reboot 108 seconds
date && ping 192.168.0.2 && date Thu Apr 15 00:06:45 EDT 2010 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=2.53 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=2.54 ms 64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=2.55 ms 64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=2.60 ms 64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=2.55 ms 64 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=2.76 ms 64 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=2.50 ms 64 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=2.63 ms 64 bytes from 192.168.0.2: icmp_seq=9 ttl=64 time=3.51 ms .... 64 bytes from 192.168.0.2: icmp_seq=117 ttl=64 time=2026 ms 64 bytes from 192.168.0.2: icmp_seq=118 ttl=64 time=1028 ms 64 bytes from 192.168.0.2: icmp_seq=119 ttl=64 time=30.1 ms 64 bytes from 192.168.0.2: icmp_seq=120 ttl=64 time=3.80 ms ^C --- 192.168.0.2 ping statistics --- 120 packets transmitted, 13 received, +45 errors, 89% packet loss, time 119202ms rtt min/avg/max/mdev = 2.502/239.520/2026.970/583.213 ms, pipe 4 Thu Apr 15 00:08:45 EDT 2010Warren P : That's good to know. If the older generations are under 2 minutes, surely the latest power connects are also under 2 minutes.From 3dinfluence -
I don't have the exact times on hand, but we have both Cisco (3750) and HP switches (2524 & 2510G). The Cisco ones indeed take several minutes to start up. The HP ones take about 30 seconds. The HP ones are 24 port, and it tests each port (does about 4 ports per second), so a 48 port would take slightly longer.
Warren P : Thanks. The Cisco 3750 is a catalyst/ios series right? The ones I was originally asking about are the former Linksys now rebranded as "cisco" small business switches and are non-ios non-catalyst.Chris S : Yeah, the 3750 is a IOS based device. I think all the Catalyst devices have been phased out now, but I'm no expert.From Chris S
0 comments:
Post a Comment