Recent content by kapone

The fan trays use a custom connector with the wires (from the fans) connected straight to it. The length of those wires is just right. i.e. if you flip the fan, the wire is too short. You'll have to take apart the tray, including the connector and fans (which use rubber screws that are really...

Yup. Small hands and a low power solder gun (those wires are quite thin).

The fan trays are seriously difficult to take apart and turn the fans around and so are the PSU fans. Ask me how I know.... :)

umm.....yeah......Think about a proper server case to begin with.

This machine is NOT designed to be quiet. You're trying to cool SIX deep rows of HDDs, with only the fans in the back in a pull configuration. Those fans HAVE to run serious static pressure and rpms to pull air through something that deep and with just tiny slots between the drives. I have two...

Never said that. :) Still got a bunch (I think something like 24-30) of 400GB HGST SAS 12gb/s SSDs sitting on the shelves. That's what I was using before I switched to the Sandisk. I can use them again!

I wonder what the few Sandisk SX350 6.4TB cards, I bought last year (for ~$400/ea) would sell for now! Not that I want to/can sell them (they are in production use), but hey, someone wanna offer me $1500/ea for them, I'll use something else! :D

That's an improvement from a routing perspective. Now it's routing the way we want it to route. However... That's a real slow hop. We'll have to think about what's causing that. Try the same from a different device, not the RPi. It may be something unique to it. Your "new" VLAN configuration...

Without getting into the social aspects of this... :) STH probably has the most mature community when it comes to hardware and software. Reddit - The typical answers are - BAM! got it working, and nothing else after that. "I'm rolling with xxx" in response to a completely different question...

It's not that simple. Before @Nikotine ripped up his config and started again... 1. He was getting a DHCP IP address from the wrt correctly. His L2 broadcast was working exactly as intended. 2. He had a default route on the switch - 0.0.0.0/0 pointing to 172.16.1.2 (which was the wrt) 3. In the...

Of course. My DHCP/DNS server(s) is on a completely different subnet, isolated from everything else. All it does is DHCP/DNS (and Active Directory in my case). It's on a 10.10.4.x subnet, and scopes have been created in it for the various subnets.

Do you still have the static route on the wrt? (10.25.0.0/16) Remove it.

This is most likely not going to work. - On the transit interface on the wrt we have told it that the route for 10.25.0.0/16 is over 172.16.1.1 - If the 10.25.x.x subnets are on that same interface, the static route above will kick in. - When the DHCP discovery broadcast happens on 10.25.x.x...

@Nikotine - When you defined that static route on the OpenWrt for the 10.25.0.0/16, did you define it on the transit interface? Can you show me a screenshot of how that looks on the OpenWrt?

@Nikotine - Notice in your traceroute output, that just your gateway on the Brocade (10.25.100.2) is taking almost 4ms to respond. That's WAY too long. That's the reason I'm focussing on the routing being "out of whack" even though it works for the intended purpose, but not traceroute. That...