Rack rails on network equipment

Sat Sep 25 20:55:59 UTC 2021

The "niceness" of equipment does factor in but it might be invisible. For
example if you like junipers cli environment, you will look at their stuff
first even if you do not have it explicitly in your requirement list.

Better rack rails will make slightly more people prefer your gear, although
it might be hard to measure exactly how much. Which is probably the
problem.

Our problem with racking switches is how vendors deliver NO rack rails and
expect us to have them hanging on just the front posts. I have a lot of
switches on rack shelfs for that reason. Does not look very professional
but neither does rack posts bent out of shape.

My personal itch is how new equipment seems to have even worse boot time
than previous generations. I am currently installing juniper acx710 and
while they are nice, they also make me wait 15 minutes to boot. This is a
tremendous waste of time during installation. I can not leave the site
without verification and typically I also have some tasks to do after boot.

Besides if you have a crash or power interruption, the customers are not
happy to wait additionally 15 minutes to get online again.

Desktop computers used to be ages to boot until Microsoft declared that you
need to be ready in 30 seconds to be certified. And suddenly everything
could boot in 30 seconds or less. There is no good reason to waste techs
time by scanning the SCSI bus in a server that does not even have the
hardware.

Regards

Baldur

lør. 25. sep. 2021 21.49 skrev Andrey Khomyakov <khomyakov.andrey at gmail.com
>:

> Well, folks, the replies have certainly been interesting. I did get my
> answer, which seems to be "no one cares", which, in turn, explains why
> network equipment manufacturers give very little to no attention to this
> problem. A point of clarification is I'm talking about the problem in the
> context of operating a data center with cabinet racks, not a telecom closet
> with 2 post racks.
>
> Let me just say from the get go that no one is making toolless rails a
> priority to the point of shutting vendors out of the evaluation process. I
> am not quite sure why that assumption was made by at least a few folks.
> With that said, when all things being equal or fairly equal, which they
> rarely are, that's when the rails come in as a factor.
>
> We operate over 1000 switches in our data centers, and hardware failures
> that require a switch swap are common enough where the speed of swap starts
> to matter to some extent. We probably swap a switch or two a month.
> Furthermore, those switches several of you referenced, which run for 5+
> years are not the ones we use. I think you are thinking of the legacy days
> where you pay $20k plus for a top of rack switch from Cisco, and then sweat
> that switch until it dies of old age. I used to operate exactly like that
> in my earlier days. This does not work for us for a number of reasons, and
> so we don't go down that path.
>
> We use Force10 family Dell switches which are basically Broadcom TD2+/TD3
> based switches (ON4000 and ON5200 series) and we run Cumulus Linux on
> those, so swapping hardware without swapping the operating system for us is
> quite plausible and very much possible. We just haven't had the need to
> switch away from Dell until recently after Cumulus Networks (now Nvidia)
> had a falling out with Broadcom and effectively will cease support for
> Broadcom ASICs in the near future. We have loads of network config
> automation rolled out and very little of it is tied to anything Cumulus
> Linux specific, so there is a fair chance to switch over to Sonic with low
> to medium effort on our part, thus returning to the state where we can
> switch hardware vendors with fairly low effort. We are looking at Nvidia
> (former Mellanox) switches which hardly have any toolless rails, and we are
> also looking at all the other usual suspects in the "white box" world,
> which is why I asked how many of you care about the rail kit and I got my
> answer: "very little to not at all". In my opinion, if you never ask,
> you'll never get it, so I am asking my vendors for toolless rails, even if
> most of them will likely never get there, since I'm probably one of the
> very few who even brights that question up to them. I'd say network
> equipment has always been in a sad state of being compared to, well, just
> about any other equipment and for some reason we are all more or less
> content with it. May I suggest you all at least raise that question to your
> suppliers even if you know full well the answer is "no". At least it will
> start showing the vendors there is demand for this feature.
>
> On the subject of new builds. Over the course of my career I have hired
> contractors to rack/stack large build-outs and a good number of them treat
> your equipment the same way they treat their 2x4s. They torque all the
> screws to such a degree that when you have to undo that, you are sweating
> like a pig trying to undo one screw, eventually stripping it, so you have
> to drill that out, etc, etc. How is that acceptable? I'm not trying to say
> that _every_ contractor does that, but a lot do to the point that that
> matters. I have no interest in discussing how to babysit contractors so
> they don't screw up your equipment.
>
> I will also concede that operating 10 switches in a colo cage probably
> doesn't warrant considerations for toolless rails. Operating 500 switches
> and growing per site?... It slowly starts to matter. And when your outlook
> is expansion, then it starts to matter even more.
>
> Thanks to all of you for your contribution. It definitely shows the
> perspective I was looking for.
>
> Special thanks to Jason How-Kow, who linked the Arista toolless rails
> (ironically we have Arista evals in the pipeline and I didn't know they do
> toolless, so it's super helpful)
>
> --Andrey
>
>
> On Fri, Sep 24, 2021 at 9:37 AM Andrey Khomyakov <
> khomyakov.andrey at gmail.com> wrote:
>
>> Hi folks,
>> Happy Friday!
>>
>> Would you, please, share your thoughts on the following matter?
>>
>> Back some 5 years ago we pulled the trigger and started phasing out Cisco
>> and Juniper switching products out of our data centers (reasons for that
>> are not quite relevant to the topic). We selected Dell switches in part due
>> to Dell using "quick rails'' (sometimes known as speed rails or toolless
>> rails).  This is where both the switch side rail and the rack side rail
>> just snap in, thus not requiring a screwdriver and hands of the size no
>> bigger than a hamster paw to hold those stupid proprietary screws (lookin
>> at your, cisco) to attach those rails.
>> We went from taking 16hrs to build a row of compute (from just network
>> equipment racking pov) to maybe 1hr... (we estimated that on average it
>> took us 30 min to rack a switch from cut open the box with Juniper switches
>> to 5 min with Dell switches)
>> Interesting tidbit is that we actually used to manufacture custom rails
>> for our Juniper EX4500 switches so the switch can be actually inserted from
>> the back of the rack (you know, where most of your server ports are...) and
>> not be blocked by the zero-U PDUs and all the cabling in the rack. Stock
>> rails didn't work at all for us unless we used wider racks, which then, in
>> turn, reduced floor capacity.
>>
>> As far as I know, Dell is the only switch vendor doing toolless rails so
>> it's a bit of a hardware lock-in from that point of view.
>>
>> *So ultimately my question to you all is how much do you care about the
>> speed of racking and unracking equipment and do you tell your suppliers
>> that you care? How much does the time it takes to install or replace a
>> switch impact you?*
>>
>> I was having a conversation with a vendor and was pushing hard on the
>> fact that their switches will end up being actually costlier for me long
>> term just because my switch replacement time quadruples at least, thus
>> requiring me to staff more remote hands. Am I overthinking this and
>> artificially limiting myself by excluding vendors who don't ship with
>> toolless rails (which is all of them now except Dell)?
>>
>> Thanks for your time in advance!
>> --Andrey
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210925/d5f50e90/attachment.html>