Re: load balanced nic
PÁSZTOR György wrote:
"Nate Duehr" <firstname.lastname@example.org> í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
Thats nice in theory. The only issue is that, I never seen this nice
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
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