[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: load balanced nic



PÁSZTOR György wrote:
Hi,

"Nate Duehr" <nate@natetech.com> írta 2008-09-29 01:35-kor:
Sure seems a lot easier to built a proper Spanning-Tree hierarchy that blocks only when necessary and unblocks automatically when the condition clears (no "err-disabled" if the problem has cleared itself)?
I want to know if someone do sg. like this, and I want to talk with.
If it clears itself, the problem just "disappears", and stronger the beleif
that the network is unreliable.

That's why you monitor and you go find root-cause.

As far as "hacks" on the network. All comments regarding hard-coding a port ASSUME that the network admin actually knows how to keep and use proper documentation techniques, and is also MONITORING such things via SNMP from the switches, to note inappropriate speed/rate changes.
Thats nice in theory. The only issue is that, I never seen this nice
practice.

So you're saying your practice is bad?  Time to get control of it.

In a properly documented network, hard-setting or autonegotiation aren't "hacks" they're just another setting in the documentation and monitoring systems.
It's true in a case where you have no choice about incorporating a
device which doesn't complain standards. But as I said: If a networking
device doesn't complain so obvious standard, like autonegoiation, it will
mess up other things too.

That's not a logical argument.  Code isn't that way.

That's like saying if there's bugs in Apache for one module, there will certainly be bugs in another. Non-logical assumption.

People try too hard to associate patterns of "behavior" of a piece of gear to real bugs. Bugs are bugs. You either have them or you don't.

You can't extrapolate a bug rate from a whole product because a particular device has a single bug.

What you CAN logically say is that ALL devices have some sort of bug somewhere in their code. That one's pretty solid, unless you've tied bugs to money somewhere, and for every bug your vendor has to pay you.

That hasn't happened in computer technology yet. (It has in other professions, in the form of malpractice lawsuits and insurance. Doctors, Lawyers, Civil Engineers... when we start having LAWSUITS over bad code, life will be far more interesting and quality levels will go up.)

I glanced at your other mail, and I saw, that you wrote about cisco-sun
difficulties. I think thats a good example: If you have no other working
solution, It can be the right way. But I have to repeat myself: Only if you
have proper documentation about those hardcodings/hacks/whatever.

Yes, we agree here. Documentation and monitoring are the network admin's job.

Nate


Reply to: