>> I want the lurkers to speak up.
>
> I'm an inveterate lurker ...
> I have never been to a meeting as, generally, they are too far away ..
> I'm a lurker (well for a while), but mainly can't make meetings ...
Me too. But once spoken up, we've broken cover and are no longer lurkers.
However, we must occasionally pop up to thank the active people for all
their advice and comments. I've been lurking here (and in many other
places) for a few years and it's all been very useful even if am often
forced by other pressures to skim or delete the digests I get. This list
is very useful to me and, I am sure, to many of the other 200 inactive
subscribers. Please keep it going and when we can we'll contribute.
A minor reason I lurk is that we are here entirely FreeBSD based. Not
Linux, but the same in most respects. Another is that I feel too busy (I
know that applies to everyone). A third is that I am on the southern
fringe of your geographical area.
Anyway, I post now because I have just made what I feel is a critical,
though non-Linux, discovery: see last half of message.
> Send out an annual resubscribe to non-posters, with two monthly
> reminders before removal?
Too much effort, unless the copies are costing you money.
> One or two may be lost, but are they benefitting anyway?
Yes, most of us lurkers are benefitting.
> Don't want to accidentaly unsubscribe people if we can help it.
Good.
> My thanks to Brett and Adam on this one. I don't care what the group calls
> itself if I can get such instant, high-quality advice at a moment's notice.
Hear, hear.
> It's a hard life for a bear of little brain.
Exactly.
================= here's the meat =================
Discovery:
I don't know how many of you run a network of machines. Five, ten, fifty
or the five hundred we have here? Well, we have things called hubs, and
things called switches, and things called routers (which are based on
FreeBSD boxes with multiple interfaces). Some of our switches are
intelligent or managed, but we don't manage them, being half a dozen makes
(whichever was cheapest at the time) it's difficult keeping track of all
the different management methods, and anyway most of that sort came with
CDs that don't run on FreeBSD so they sit on the shelf.
Anyway, consider our switches. Each has one incoming port, maybe seven or
fifteen or twenty-three outgoing ones. Feeding rows of RJ45 outlets
through miles of Cat-5 cabling. These feed client machines through drop
leads. The RJ-45 outlets are often arranged in pairs, as a pair fits
nicely in a single-outlet box.
You have the picture? Fairly common, I think.
It all works very well. Very much more resistant to lightning than our
Econet system was (we still run Econet, BTW). Doesn't work when the mains
power is off, common in this country environment (indeed, we've had eleven
power cuts in eleven months) and there's also trip switches that go off
from time to time. But that's not the problem. The system works well on a
24/365 basis.
But - there's a problem. Suppose you see a drop lead hanging from an
outlet cos the user has gone off with his or her portable, isn't it nice
and tidy to plug the free end into the adjacent outlet?
It is, and it generally causes no trouble.
But they now make better switches. Remember the old ones - you press the
little button for the input lead, cos to connect two of these hubs or
switches together you need a reversed lead or a reversed port? The new
ones have auto MDX/MDIX on them, so you don't need reversed leads any
more. Just plug them together with straight leads, and they'll work. Very
convenient, although in practice you rarely needed reversed leads anyway.
So - have you tried shorting any two outlets together, as in the
"tidy-the-lead" scenario above?
No?
Try it.
If your network has no broadcasts on it, you may be OK.
But if there's a broadcast, it'll go out one port and in the other, then
out again, and again, and again.
This broadcast storm will feed its way up your network till it all comes
to a glutinous halt, until blocked by am intelligent switch or router.
We've had a few of these halts. We eliminated the switch responsible. But
we've now determined that there was nothing wrong with the switch. It was
just too intelligent, in that it had auto MDX/MDIX. But not intelligent
enough, in that it caused broadcast storms if two ports were shorted.
We never had the problem before (that is, before 13 months ago), because
with the older switches you needed a crossover lead to do the damage.
With the newer ones, all you need is a normal drop lead and a yen for
tidiness.
===== well, that's the discovery. Now for the rant =========
The entire Base-T Cat-5 RJ45 system is powerful, flexible and convenient.
But how could they possibly have designed it so that it can be brought
down so easily by any tidy end-user?
============= OK, OK =======================================
I know we can sort it out in various ways. I am told that configuring
DEVICE_POLLING in the kernels will protect our routers and servers by
polling the network cards instead of allowing them to interrupt. But my
immediate reaction is to source simpler switches, those without
auto-MDX/MDIX. Unfortunately, these are becoming rare beasts now.
And to ask you who else has come across the danger to corporate networks
posed by the convenience of auto-crossover ports.
--
Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG
01371-822698, mobile 07816 821659 cchd(a)felsted.essex.sch.uk