9

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. ].

Warren P
  • 1,195
  • 7
  • 20
  • 35
  • 3
    How often do you find yourself rebooting switches? – tomjedrz Apr 12 '10 at 17:59
  • 1
    Can you expand on why 5 minutes to boot a switch up is unacceptable in your environment? – James Apr 12 '10 at 18:00
  • Booting is one thing - having a set of stack switches recover from a master failure is another potentially important timing measure. – Helvick Apr 12 '10 at 21:41
  • When I read complaints online, second only to the thing dying after six weeks or six days of uptime requiring a reboot, the second most common complaint is boot up time figures commonly are the chief complaint of those reviewing managed switches. Since we should assume the former is a fault that should be fixed by f/w upgrade, the latter however will be considered a "thing you just live with". I like to know what I'm going to live with before I consign myself to living with it. The SRW figure of 97 seconds below is within what I can live with. – Warren P Apr 14 '10 at 13:13
  • I hope you gather some useful data. Instead of just questioning why you need this data, I would like to point out that you can run the more advanced switches in parallel and let PVST+ or other mechanisms allow parallel switches to take over from rebooting switches during their downtime. This is one way large data centers handle the slow boot time issue. – kmarsh Apr 14 '10 at 13:47
  • If I remember I'll time a reboot of my PowerConnect 5324 that I have at home. It's a few generations older than the PowerConnect switches you're looking at but it will be another data point. – 3dinfluence Apr 14 '10 at 16:32
  • Nothing I've ever used has taken more than a couple of minutes. Certainly less than three minutes. As they normally stay up for anything from a year upwards at a stretch I don't consider it an issue to be concerned about. Regardless, they have always come up faster than the servers, which is all that really matters to me. – John Gardeniers Apr 15 '10 at 05:11

4 Answers4

14

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.

3dinfluence
  • 12,409
  • 2
  • 27
  • 41
  • 1
    +1 started writing the same thing, then got distracted – Zypher Apr 12 '10 at 18:02
  • +1 I agree, why is switch boot time so important? Any/all planned downtime is just that, planned. – DanBig Apr 12 '10 at 20:00
  • 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. – Warren P Apr 14 '10 at 11:31
  • 2
    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. – 3dinfluence Apr 14 '10 at 13:53
  • 1
    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!) – Mark Henderson Apr 15 '10 at 04:19
4

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 2010
  • 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". – Warren P Apr 14 '10 at 11:31
  • +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. – kmarsh Apr 14 '10 at 13:45
  • 1
    @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. – 3dinfluence Apr 14 '10 at 16:27
2

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 reload command 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 2010
3dinfluence
  • 12,409
  • 2
  • 27
  • 41
  • That's good to know. If the older generations are under 2 minutes, surely the latest power connects are also under 2 minutes. – Warren P Apr 16 '10 at 11:33
1

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.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 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. – Warren P Apr 16 '10 at 11:32
  • Yeah, the 3750 is a IOS based device. I think all the Catalyst devices have been phased out now, but I'm no expert. – Chris S Apr 16 '10 at 22:15