Won't work. The RPMs of the fans have to be within range of "what's expected", otherwise the switch throws up.
Edit: On the 6610 that is.
Yeah, I gave no indication about using a 6610, I only use 6450s here. Different animal. I also implicitly assume someone swapping fans will be doing his homework and verifying that the thermal conditions of the switch are similar before and after the swap. Or that he adequately calculates or verifies that different workloads won't vastly affect thermal (ex. 48P with full PoE I could see a lot of heat being generated from the wasted power wherever conversion isn't 100% efficient... which is nowhere, so a watt or two times 48 will add up very, very quickly). Your average 10-13 watt 10G NIC (SFP+, 10GBASE-T is worse) gets up to 70C or more without good airflow. Imagine that in 1U, several times over.
Anyhow, once we establish we aren't doing something retarded, we can do the following:
- Spoof PWM signal with a small MCU that simply fools the RPM reading into thinking everything is peachy. Because the switches only have two modes afaik, and I don't see much in the way of fine tuning of the speed, we could have two or three speeds, that translate to slower ones from the "OK" assumed speeds of the switch.
- Simply wire PWM and GND to the headers, and supply voltage straight out of a 12V source. The readings will report a constant speed but this won't cause the PWM value-designed drivers to whine. A small board for this can be prototyped easily.
There are some PWM controllers off Aliexpress and eBay and other internet dollar stores that take 12V in. You would just need to solder some fan headers that expose the PWM/GND pins and connect those. I have one so I might give it a go. They also have PWM control via temperature, but it seems without altering the fw or caps/resistors the temp values are fixed.
@fohdeesha, since this is a mildly annoying trait of our beloved switches, do you want to work with me on whipping out something people can put together on their own? (possibly under a non commercial license to avoid earthworm tactics). This could also help with other switches.
Oh, did I say don't f*ck up the thermal by putting fans unable to exhaust enough air volume for your particular environment? Good news is, these switches have thermal cutoff safeguards. You can't bake them. They cut off way before reaching any temperatures dangerous to the ICs.
Is it possible to have the management port plugged into the switch itself for remote administration? I've been doing everything via the console and it's a pain.
Unless you have a dedicated management network not connected to anything else, with no conflicts with the rest, I suggest you use the mgmt port as a fallback/emergency port when you have lost access to the switch somehow, and can combine that with serial access for fixing things, and also for firmware updates. I use the mgmt for initial config and bootstrapping, and leave it assigned with an IP in the range of 10.90.250.x, so I can just configure a laptop with static IP and get TFTP up and running.
You can create a virtual interface in a management VLAN if you are so inclined and have unlimited/near unlimited IPs bound to the switch per VLAN for management if you need to. Honestly, if someone has a protocol level vulnerability in your network gear, you are SOL no matter what containment measures you have taken. I had a conversation in that juvenile labbing community we all have heard of, with someone claiming he could protect Cisco IOS via policy and blah blah. Before he ran out of arguments (that were compsci and OS design 101: if someone executes code at ring 0 you are screwed, end of the game, nothing further beyond, even with a security coprocessor it would still need to be able to authenticate whatever code you are running, on realtime) and claimed that his company "controlled CPU execution in IOS" (LOL hmmkay!), I commented on how IOS mitigations have been bypassed throughout the years (as late as past year there is a public talk in CCC showcasing a type of ROP against IOS_.
FastIron has no mitigations of any kind. It's a barebones ARM based Linux under the hood. Leave your management facilities out of band if paranoid. Be conservative with SNMP and that's that. Console access also yields password override: bootloader can disable password checks in the image.
Hopefully this clears out any questions with "mom and pops" "hardening" ideas.