Slashdot Mirror
Linux Token Ring Support Bringing Down Corporate Nets?
"My company runs Token Ring at the office (puke!) I got drivers from the card manufacturer (Madge), and I'd been happily churning along. Then last week, we started seeing a bunch of errors on the network. These errors would bring everyone on the ring down. After a week of this kinda stuff, they eventually isolated it to me.
Reboot the laptop into Windows and the network card works just fine and they don't see any ring errors. Reboot into linux, and suddenly they start seeing ring errors. I don't really grok token ring, so I'm not entirely certain that I know exactly what the problem is. But, whenever I brought the token ring on line under linux, they saw ring errors, which eventually (as I understand it) would bring down the entire ring. Switch cards (same model) and it continues to happen. It looked to me (and the network analysts) that the Linux driver was causing the problem.
I tried switching to an IBM token ring card, but there's a bug and I hadn't patched for this. The people with the fluke would not wait around while I tried to figure this out. I didn't have any other token ring cards that I could try.
In the end, I agreed not to boot into Linux unless I went into the conference room (which is one of the only rooms in the building with ethernet ports). How should I have done this differently so that using Linux would have been a more positive experience for my company?"
I have heard the same story of a certain linux box bringing down a certain subnet of a certain university.
of this I am certain
With the number of developers on linux, it amazes me that this wasn't caught.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
... are slow/old/out of date technology
No excuse. If you say you support something and that support is stable... it should be so.
Fix it... don't say its not worth having anyway. Or if its not worth having strip token ring support out and save a few kB.
The thing is called a Token Ring, it isn't a real Ring.
I have a Linux box that's been on my company's token ring for nearly three years (I work for IBM), using an Olicom card. Not only do the sysadmins not bug me about it, they use it on a regular basis. It's my team's development server, but the network admins come to me quite frequently with some little thing they'd like to try or some temporary service they need to provide and they find that my box is the simplest and most reliable place to do those things (the other local servers are NT and OS/2; there are plenty of AIX boxes around, but they're not at my location and the local sysadmins don't really have access to them).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
The token is falling out, and getting caught in the ether net? You'd better go looking for it on the floor around you... :)
If you already have ethernet in a conference room it might not be too hard to just have the port you use added to whatever hub they use for the conference room.
It seems that you are running on a laptop since you can move you computer to the conference room. Another option is to insist that they put up an 802.11b network. You could then wander freely and have wireless ethernet. Even better!
Lasers Controlled Games!
Before we gutted the remainder at my work place, we had a couple of linux machines running token ring. A webserver with a IBM Lanstreamer card, and a couple of old old OLD ISA tropic chipset cards. They all worked great with no problems. The lanstreamer was a 16mb one, the tropics were 4mb. IBM - hardware that's built like a tank.
The same way you test any new solution you're going to bring in to the company, slowly, under controlled circumstances. You sould have asked your boss for a loaner PC and token ring lobe (hope that's the right terminology for the technology) and made sure that your setup wouldn't screw up the network. For testing, try pure torture - try huge pings, small pings, flood pings, stack ssh sessions so they zip back and forth between the two machines a couple dozen times, just make sure that any failures happen where you don't have to incur the wrath of your co-workers.
Don't just throw things on a corporate network, 'cuz that's where trouble starts.
If god had intended you to be naked, you would have been born that way.
Well, first, debug the whole thing beforehand. By then, you'll find out about it and will be able to accomidate.
Now, I'm unsure on Token Ring. I'm taking that it runs on coax cabling and you have to be in a loop for every computer to work. UGH! I'm unsure of the protocalls used with it, but if it can run TCP/IP on it, you may be able to get away with a gateway computer (which does TokenRing <==> Ethernet.)
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
At one time I ran a token ring network that had grown like cancer... It was about 1.5 miles long... way out of spec... Depending on the card if the ring beakoned to much the comuther would lock up and keep the ring dead... ith happend on various boxes.. diffrent kernels... and all sorts of cards... but then again... token ring can be brought down by one blue screen of death on diffrent cards....
Imagine if it was Microsoft which had the buggy Token Ring drivers. We would have
1. Posts complaining that micro$oft can't do anything right because it is closed source, and if it was open source they wouldn't have these problems.
2. Posts arguing that Microsoft deliberately sabotaged the drivers because they want to force people to stop using Token Ring.
3. Posts asking why anyone is still using Windows since it is obviously inferior to Linux.
Slashdot... Open Source, Closed Minds indeed.
Tarsnap: Online backups for the truly paranoid
Real simple. Don't run Linux.
I once installed a firewall with a madge card. After the installation I never heard from the client so I assume it still works)
Anyway token ring is obsolete and you should try to avoid it...
If you have a reproducable problem that causes the entire network to fall over, the only thing you can do is pull the machine. On the other hand, you should really get in touch with the developer of the driver you were using. It's possible that this bug is known and a fixed version of the driver exists, or it's possible that nobody's ever seen it before. Either way, doing what you can to help the developer get this fixed will help prevent other people from having the same problems in the future. You should be able to find out who's responsible for the driver by looking at either /usr/src/linux/MAINTAINERS or the source for the driver itself (it'll probably be under /usr/src/linux/drivers/net/tokenring).
Sorry. I always wanted to say that...
Karma...what's that? I just speak my mind.
Token Ring is horribly sensitive to timing issues, especially when using Cat5 in a physical bus instead of a physical coax ring.
I have seen a TR network where a single machine could develop a problem, and this would cause a group of 8 machines to all lose the net. Any one of those machines could bring them all down, and the only thing that would get them back up was shutting them all off (completely power-down, even rebooting didn't do it) and then bringing them back up one by one. Something as simple as shutting down Windows NT to the "click to reboot" prompt was enough to cause the problem to develop; eventually one of them would lose it's mind, and they'd all go.
Throw into that mix, the fact that Linux Token Ring drivers are bastard stepchildren that get 1/1,000th of the use of the Ethernet drivers (if that much) and you end up with real problems.
Bottom line; come in a weekend and try that other NIC out, maybe it's drivers are more mature. But other than that, don't dick with the company network, Token Ring is too damn sensitive.
You might try putting a few NT boxes into the "click to reboot" state, and see if they screw up the company network too. Works best with 3COM TR NICs, which is ironic since they also seem to recover the best to having their cable pulled and replaced while live.
If they see the problem is Token Ring specific, and just exacerbated by a bad Linux driver, perhaps they'll switch to Ethernet. If they trade their TR NICs in to somebody like CablExpress, they might break even or make a small profit on the switchover, and they'll certainly recover the costs in a short period of buying Ethernet NICs instead of new TR ones; they're horribly expensive, and the infrastructure gear (CAUs, LAMs, MAUs, switches, routers, etc.) is even worse.
An even better suggestion might be to find a job in a shop that prefers the more-manageable problems of Ethernet to the problems of Token Ring.
...don't use Token Ring. It is such an astounding brain-damaged protocal its a wonder anyone ever started using it, and its blasphemous that anyone uses it today. Not to be rude, but your management must be full of complete morons if they are still using token ring.
---- I made the Kessel Run in under 11 parsecs.
Everyone that's whining how token ring is so old, well if it's so old linux should support it by now.
We all know linux doesn't support any new hardware.
If linux can't even support old hardware what can it support?
Actually since your clueless, Token Ring is more expensive but that is its only draw back. It has collision avoidence built in, ethernet just collides killing speed. There is Gigabyte Token Ring now also. So if you don't know shit, don't say shit.
come on sort it
thats the sort of FUD that gets alot of people angry
LOTS of people (and by this I mean end users) have used token ring drivers with complete success
the poster knew this
so what are they looking for ?
help with their card and hardware ?
(which it seems is the problem)
info needed
kernel version
card ID
machine ID
and maybe a trace of the network
to say IT DONT WORK is cave man like in the extream even kids as young as 7 know that to fix something that you cant see you need to have it described
regards
john jones
p.s. what kind of editor runs this ?
Setting aside for a moment that the linux driver is faulty, what kind of an idiot (windows or linux) developer doesn't write code to handle errors on the network? I don't see how one lone NIC can bring down an entire network... even if it is flooding it, it can slow it down at most. I have written many network drivers for windows in my time, and never, ever have I ever released a driver that would not be able to accept garbage data and still work.
I can see this linux driver causing problems on the corporate network, but I don't understand how it could bring it down. Windows, Linux, or any other OS's drivers should be able to handle crap on the network... Any network protocol design book will have that in bold letters on the first page...
yeesh... Whatever happend to good NIC drivers (independent of OS)?
---
Programming is like sex... Make one mistake and support it the rest of your life.
Last time I had a problem with my Tolkien Ring it was a Nazgul. Fortunately I had a CSU/DSU handy to whack it upside the head with (made by Gandalf, of course - wouldn't have worked otherwise).
Yeah, I know, jokes like this are a bad Hobbit...
We have used Linux and Token Ring for years in our company network. Biggest problem has been to find a reliable drivers. We settled for Olicom adapters and their driver. The driver works under kernel version 2.2.19. We used it on our central CVS server with more than 50 users. Olicom has been bought by Madge the other non-IBM-producer of Token-Ring-Adapters.
/ ol icom/
/
We switched the whole network to 100 MBit Ethernet, so we will not look into the issue in the future.
The drivers in the kernel have some problems, particular for PCMCIA.
Here some useful links:
Linux Token-Ring page, with updated drivers, but a discouraging news entry from 9/14/2001:
http://www.linuxtr.net/
Linux-Software for Olicom-Drivers(recommended):
http://www.madge.com/connect/downloads/software
Linux-Software for Madge-Adapters on:
http://www.madge.com/Connect/Downloads/Software
Tell that to IBM.
Anyone who knows anything about ethernet though will be running a switch when contention reaches a point. After that, the problems with ethernet are completely eliminated and Token Ring has absolutely no advantages.
There's a reason everyone's ditching TR whenever they get the chance...
are to blame. oh, you said "token". Nevermind.
It's not that uncommon at all to find some application that conflicts with some other application and floods the network with crap. Ditto for hardware.
Yes, in this case, Linux did get a bad rep, and it may have been deserved. It's a fairly safe bet that very few people use Linux with Token Ring, so the drivers probably haven't been very well tested.
If you're truly paranoid, do what another poster did and test in a limited environment. Unfortunately, doing this for every new piece of hardware and software added to the network (not just Linux stuff) would take *forever* so you need to trust that things will work at some point.
of course there are Token Ring switches. But really now, does IBM, the "inventor" of TR even support it anymore?
Isn't it obvious that this person is on the Microsoft payroll? This is clearly another astroturf campaign. (It's also a damn pathetic attempt at karma whoring.)
While this is a large issue for those involved, a good network design should not allow this to happen in the first place. If a client is sending incorrect commands to the network or is eating up the token, etc, the router should cut off that node's access to the network and the node should display an error like:
"Your system is sending inproper commands to the network and as a result, your network interface has been shut down. Please contact your system administrator for details."
Imagine how much havoc one could reek if they walked into a business with a small "network tool" that would bring down the network, plugged it into a nearby jack, and left.
When writing CGI programs for the web, the first thing you learn after how to work the #! ling is that you should NEVER TRUST THE USER. Networks need to work the same way. If the node says that it is supposted to speak now because it has the token, the router should check that the node really has the token and make adjustments to avoid bringing down the network if it does not.
Short of charging the network lines with a 5,000 volt current (and surge protecters were invented to stop even this), there should be no way that I can bring down the network from a point on the network. (Well, excluding using SNMP to shutdown the router, which assumes that I have the password, etc.)
You want me to suck your oick? What exactly is an oick?
are you're office running? Token ring is fragile stuff, but much faster than a half duplex 10mbit/s ethernett. I've read that TR has been released in a 100mbit/s version too, but I have only experience with the 4/16 mbit/s versions. It's been a while since the last time.
:) . Check out their knowlegde base and/or mail them.
.lars
Obvious the hardware is working fine. You say nothing about what speed you brought the TR-NIC up at, but you're probably aware of that bringing up a NIC at 4mbit/s in a 16mbit/s network will beakon the ring and bring the network down.
Anyway, to work out the problem, simply ask the network people to lend you a MAU. Hook up one or more of the other pc's that works fine in the ring and do some labbing with your own little ring until you locate the problem.
A quick look at the Madge website it seems like they actually SUPPORTS their linux drivers
#find
I ran Token Ring on my personal desktop and a server at work for over two years without any incidents requiring sysadmin intervention.
Here's how I did it:
So, it worked for me, as I said, for a couple of years. But then I moved to a new site with pure Ethernet, and I have to admit that life is much simpler now.
A few lives ago I installed a couple of Sun's running Nuclear core simulator software. The company in question required Token Ring. So I've got these two multi-processor Sun servers running their software talking back and forth to each other, when all of a sudden a very frantic man came onto the floor shouting if anyone has recently added two machines to the ring. My customer stood up and said us over here. The frantic man ran to the cube and disconnected the two Sun servers. He then placed a call asked how everything looked, the color than started to return to his face. It seems that my two happy Sun's had completely overloaded the ring, so badly in fact that they almost had to declare some short of NRC emergency. Turns out I was the first person to use the Sun Token Ring card and driver. Even though I configured the software correctly the driver was sending all the information as broadcast packets, oops driver bug. We got a patch in one day, but for some reason the client isolated the Sun's for two months before letting them back on the Ring
The last I heard, IBM-Norway were running 100mbit/s TR at their head office. Don't know if that's the case anymore. At high utilization cheap 100mb switches will slow down due to cpu utilization. However, anyone updated on if IBM has done something about the single point of failure problems with TR in the 100/1000 mbit/s versions?
#find
How much Linux sucks and has no place in a coporate environment.
What I see here is that a lot of People no longer have a clue about Token ring - am I getting realy old (I am 25) ?
This is generally bad, because TR is realy a cool Technology (except that it was always to expensive and proprietary)
But superior technology was never the point.
(see also: Donalds Becker s comment on NE2000 clones)
The Network card is not the only possible error source. Token Ring is an active Network, where a lot of the logic is within the NIC and the Cabling (e.g. M(S)AU = Multi Station access unit)
All Stations are assembled in a physical double ring. Even though the Cabling is a star topology.
If you connect your station to a MAU (= TR hub)
your plug is connected to the MAU, but you are not yet connected to the ring. If you turn on your computer, the network driver opens a relay in the MAU (signaled via the adabter cable) to switch you into the ring.
If you turn off the computer you get discinnected.
All data on the ring passes all the NICs in the ring (exception: Early Token Release). The NC acts as a Bridge (it amplifies the signal to the next ring segment).
Since the unamplified distance between to NCs is limited this can lead to the "Token Ring Sleeps at Night" Problem, where the token Ring refused to work at night (simply because too many employes turn off there PC after work)
This can simply be overcome by replacing passive MAUs with active TR Switches.
One should also have in mind, that the cable to the network card is a part of the ring after activation of the card. A faulty cable can disturbe the ring (even though it should be automaticaly removed from the ring)
I would try your laptop directly on a TR switch.
Thís way you can eliminate driver/TR component interaction (a driver which agressivly tries to connect to a ring with a faulty cable)
I personaly implemented many Linux Servers with linux and never had problems with disturbing ring operation. I used IBM and Olicom Adabters and they always worked well.
Oh please.
And then an informed reader would point out that the driver was provided by the manufactorer, not Microsoft. Thus, Microsoft itself would have little direct involvement in this case.
A more reasonable Open Source advocate might chip in that an open source driver would provide a faster path to hunting down and fixing the problem (Source is available for this driver, though I don't know what the license is - so that point may or may not be tested in this case).
There is mindless zealotry all over the tech industry, media, and public forumns. It goes far beyond Slashdot and Linux. Please try to refrain from adding to it.
You do have a way out: use the IBM card. It was working a few years ago, and I imagine it's still working today. Yes, you do have to patch the kernel--what's the problem with that?
If that's not to your liking, you can throw money at the problem and buy a TokenRing/Ethernet bridge and use an Ethernet card on the Linux machine. Maybe your managers will see the light and convert more of your network to Ethernet.
In general, TokenRing is dead technology. Many operating systems just don't support it at all anymore. How long should Linux carry the burden of supporting outdated and flaky technologies?
On Monday everyone buy stuff! Spread the word on IRC, on Instant Message, on the phone, on Usenet, on any other newsgroups. Spread the word by phone, by word of mouth. EVERYONE buy stuff tomorrow. Buy a book, buy computer equipment, buy stuff!!!
-- "You used your dictaphone to post, didn't you?"
I work with broken... sorry, Token Ring every day. I work for a state agency with near 5,000 nodes (server, workstation, printer, etc) which until just last year were all on TR. The switch has only just started to Ethernet and going office by office as budget allows.
/.'ers out there?)
I came from an all Ethernet environment prior to the this job and have had some experience with ARCNet as well. (Hows that for you old
Token Ring is a logical ring topology, ususally implemented in a physical star or bus topology. Some of our rings have upward of 200 nodes with thousands of feet of cabling connecting them. We have MAU's (Multiple Access Units - a hub) connected to each other with copper and fiber. Most of the cabling that runs to the workstations is type I - 4 conductor, big gauge stuff that comes to large data connectors at the wall. If you haven't seen these, you'd love them, about 1 1/4" square and 2 1/2" long. Then a lobe cable goes to a db-9 connector on the NIC card.
TR works by passing a token (electrically) to each node in sequence. When a node has data to be transmitted, it hangs the data on the token and sends it on it's way. All subsequent cards check to see if the data is for them and then pass it all on if it's not. The intended recipient strips the data and sends the token on it's way. In a 4Mb ring, there is one token and on a 16 Mb ring there are two, 180 deg. to each other (timing-wise) on the ring. I don't know how the 100 Mb version does it, but almost nobody uses that.
This has an advantage in that there are no such things as collisions like on Ethernet. This allows for the massive number of nodes per ring and high efficiency in data transfer - perhaps 80 - 90% For comparison, Ethernet starts having problems due to collisions at 40% or so - depending on the number of nodes.
It also has the disadvantage that a single break at any point in the ring breaks the whole ring. (Think Christmas lights in series rather than parallel.) Another disadvantage is exactly the problem the poster reports - timing errors. I don't know if the problem was just timing errors, but the other problem - beaconing - would have brought the whole ring down right away and he said that it was was just noise with the potential to bring the ring down.
Indeed, timing is critical. Beacon errors are worse as the NIC put out spurious signal that doesn't allow any node to hear the token as they attempt to pass it around.
Early in my employment, I attempted to put a linux box on the ring, but couldn't get the TR drivers to work with a Madge or old IBM card. About a year in, they got all tight-assed and concerned about security and prohibited all alternate OS's. We're an all M$ house, how's that for irony. Security, what security? At least we're behind a pretty good firewall.
As far as the problem with this particular installation, I agree with other posters who have said that the author of the driver needs to be contacted to report the bug and maybe get a fix. It would be good to set up a separate ring with just the two nodes (and the fluke) to try to ID the problem. But he may also be facing administrative/political issues as well. Those are hard to overcome, especially in a large organization, and even more in a government agency - as I have found.
I'm not karma whoring, I just thought that since this technology (TR) is so ancient and in use by so few places, readers unfamiliar with it might like a little info.
BTW, the aforementioned ARCNet is also a token passing design that runs on a bus or a star and runs at 2 Mb. It can run on UTP or 93 ohm coax (RG-62) It's relatively robust, if slow. A boss of mine went to a Novell Admin class where the instructor hooked a server and workstation together on ARCNet with BNC connectors crimped to a piece of barbed wire. It passed data acceptably.
Hope this all helps a bit.
War is Peace. Freedom is Slavery. Ignorance is Strength. - George Orwell or George Bush?
You ignoramus - obviously you have never read Mr Tolkein's classic series or you would not speak in such a derogatory manner!
This 3com NIC is guarenteed to bring down your network. Great April Fools joke for the poorly paid network technician.
P.S. I really do have a 3com card that will do this. It just sits there and transmits garbage.
This is off-topic as all hell... but hey, if I have to buy a fistful of videogames and CDs on Monday to Help The Economy, well... I guess a man's gotta do what a man's gotta do.
Token Ring gets another "Check" on the Chalkboard for being bad and mischevious during class!!!
"The best laid plans of mice and men gang oft agley..." - ROBERT BURNS
The promised reliability never materialized. In the early days, the TR connector was the same as that for DB9 serial ports and EGA (pre-VGA) video. L-users would frequently connect the cables incorrectly, taking down the entire LAN. In the later days, 10BaseT Ethernet replaced coax, and became slightly more reliable than Token Ring. These days, we used switched Ethernet, which is infinitely more reliable than Token Ring.
Keeping Token Ring networks running has become like voodoo management. Stories like yours are common. Nobody knows exactly WHY things are going wrong, so they are quick to point the finger at oddball stuff. There is so little support for Token Ring that nobody can figure out how to solve even basic problems. The only solution is to remove the offending products from the network.
Here is some background for what might be going wrong. First of all, your card has its own microprocessor. As a kid in the early 1980s I owned a TI-99/4a home computer/game-console: it is roughly the same CPU in your card. It runs its own embedded OS. This means that under normal conditions, your card will run fine, regardless of the driver: all the intelligence is on the adapter, not in the driver.
I point this out because you never specified exactly the types of errors you are receiving. In theory, all such errors are related to the hardware, and there is nothing the driver can do to cause them. Specifically, I don't know how it can be possible for something to "cause ring errors that eventually bring down the entire net". There are really no progressive failures like this in Token Ring.
If you mentioned the precise ring error and/or the method in which the ring goes down, it might be helpful. Here are some possible ring erors.
A burst-error is caused when an adapter inserts itself into or removes itself from the ring. This might be caused because, for some reason, Linux might be re-initializing the card. For example, you may have DHCP set to renew the lease every minute which may cause this to happen. I have no knowledge of how Linux deals with Token Ring, but if the problem is "Burst Errors", then it is because of some higher-layer interaction like this.
A "receiver congestion" error is caused when the Linux driver doesn't remove packets from the card's buffers fast enough. In theory, they are suppose to indicate that packets are coming in too fast for the machine to handle. In practice, you see this happen when machines "hang" and fail to empty their queues. You might be running some sort of libpcap packet-sniffer on the system or have the adapter running in promiscuous mode (do an ifconfig to check) that is having some sort of pathelogical condition.
Maybe you are getting "FC errors" which indicate that somebody has the same MAC address as you. This won't happen if you use the standard MAC address built into the card, but it could happen if the Linux driver has a bug setting a locally administered address. Maybe it's setting it to all zeroes, causing a conflict with some other card that has a similar bug.
None of these errors really cause problems. Burst errors will nuke a frame as it passes by (maybe one out of a thousand) -- the hardware auto-retransmits, so it doesn't cause performance problems. Receiver congestion errors only cause problems for YOU and nobody else on the ring. A duplicate address will only cause problems with the other machine that shares your MAC address.
My guess is that your admins are just getting testy over the fact that your Linux box re-inserts itself more often than Windows boxen, causing a higher number of relatively harmless burst-errors. When they diagnose problems with the ring, they notice that your machine causes the highest number of errors, and therefore blamr any ring failure on you.
If your machine is truly causing a problem, the only thing I can think of is that your port on the hub gets "stuck" (this happens a lot). The process of re-inserting has a small chance of getting stuck, so if your Linux box re-inserts 100 times more often than Windows, you'd see this.
BTW, Token Ring is a good lesson in Zen. A burst-error is defined as 5 half-bit times without a transition. What this really means is that a station has entered or left the ring. I point this out because if you try to debug this problem yourself, you'll have to hunt down Token Ring references. Go quickly to the definition of burst-errors: if it has the "technical" definition, discard the reference and move on. If it has the "practical" definition, then you'll be in luck.
One ring to rule them all, One ring to find them.
One ring to bring them all and in the darkness bind them.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Um, how about posting the actual "ring errors" that your lan admins were seeing. Also, did you try contacting Madge, since they supply the card and drivers? I'm still not really sure why this is an Ask Slashdot. While I'm sure it's within the realm of possibility that an errant (or improper configuration of a) driver hosed the network (an ex-admin of ours hosed our network with the linux box after he was let go), there isn't much detail here, there are many mailing lists devoted to this kind of thing, and your hardware vendor does support your card under linux. From their website:
yada yada. The fact that you posted this as an Ask Slashdot (and the complete lack of details), make me question the veracity of this report. Regardless, if this did happen, it is too bad. People at your work will undoubtedly have a bad impression of linux from this. Such is life.-no broken link
Prolly you have NT boxxes hanging on the TR, add a NIC to one Set IP routing on and Use Ethernet to get on The Network...one Cross Cabel will do..
Yes it costs you an extra box, but it could be just some old p166 or something..
Have Fun..
... a management full of complete morons. :)
:-)
Token Ring is cool because it can allow one bad node to bring down the whole network?
Mac OS X and Windows XP working side by side to fight back the night.
Linux does token ring really well if you use the right adapters.
We have token ring adapters of all types. I've found the newer IBM PCI TR adapters to work best. They use the "olympic" driver included with the kernel. I have 6 Linux machines at work using these drivers and they've performed flawlessly... except when someone unplugs the cable. In that case, the box needs a reboot, but the rest of the network is fine.
I first tried the IBM PCI LanStreamer but couldn't get it to last more than a few minutes. I'm guessing there's a problem with the buffers that freezes up the interface. I tried one of the newer Olympic cards on a whim, and haven't looked back.
If you have REALLY ancient equipment, the Tropic-based 16/4 TR Adapter/A (long and short version) is known to work on Microchannel machines. I've put together one of these and had it running as a TR-to-ethernet router for a while.
All this stuff can be gotten on eBay or elsewhere for dirt cheap.
I haven't tried the Madge or Olicom cards, but we have plenty of IBM cards, so I've stuck with those.
+++
NO CARRIER
Believe it or not, I used to work for a company that manufactured "1-hour photolab" equipment, and many of those systems STILL use ARCNet internally for all the different components to talk to each other.
It may sound arcane, but it's robust, interference resistant, cheap (I guess), and reliable. If you're not passing tons of data, it works just fine.
MadCow.
I used to have a sig, but I set it free and it never came back.
Perhaps you ought to choose reading material that doesn't use so many long words.
Deploying Sun's with Token ring were sheer headaches. Though the problems rarely affected the rest of the ring, the servers themselves were frequently wrapped out of the ring, subject to random beaconing, mysteriously off the net, and sometimes just plain hard locked up.
After about two years of trying to get the SunOS / Solaris Token Ring drivers to work correctly with our network, we gave up. Ultimately the Sun servers were deployed on Ethernet or FDDI.
The point here is that Token Ring is HARD to get right if you arent IBM. Even Sun, which would be considered to have a high priority of getting their servers to interop with IBM SNA/Mainframe/AS400s to sell into large shops, was not able to reliably get Token Ring for a long time.
At this point, the Linux situation is even less promising due to:
Little commercial support for the drivers
Less investment in token ring in the industry
What I would suggest is contacting IBM's Linux efforts. They should have a vested interest in seeing Linux systems interop with IBM infrastructure in IBM shops. Undoubtedly, the IBM shops are where the highest concentrations of Token Ring still exist...
A token ring card costs more than an 8 port ethernet switch.
You can buy 8 ethernet cards, an 8 port switch, and you'd barely scratch the price of 2 or 3 token ring cards, but you have 0 collisions. Hell, the price of a token ring hub isn't even similar to the price of the ethernet switch.
If you're shits' from the 80's, don't spew it in the 21st century.
>There is Gigabyte Token Ring now also
BFD. There's 144 mbit arcnet too, but you don't see anyone with a clue boasting about it.
for a LARGE company that is predominatly Token Ring. We've got various flavours of Linux running and there is a debian developer in my group, I will ask him. One thing I do know is that the network techs are always on the lookout for TR cards in Promiscious Mode. They come down like a ton of bricks on those users. Good luck
errr....umm...*whooosh* *whoosh* Is this thing on ?
I don't see the problem? Is the conference room that bad? It's probably got a better view, better chairs and about 10 times as much space as your cubicle.
"Yes, this is mjh in the conference room, we'll be up here all day again so can I get some coffee, sandwiches and maybe a few pastries sent up, Thanks."
-- Huh, what?
No. I'll qualify that. It's vile.
Theoretically, TokenRing is wise, clever, fault-tolerant and the *only* way to get your LAN running close to ultimate bandwidth.
I *like* TokenRing. In theory.
In practise, it sucks. Specifically, it sucks *all* the bandwidth out of your network.
A healthy TR network *will* use all the bandwidth that it needs. Collisions are impossible.
Then, a node fails (which is what happened to you). Gradually, the overhead of regenerating tokens becomed an issue. Remember, a node will *never* regenerate a token unless it is convinced that it's up-ring node is dead or bonkers. However, if the upstream node has gone totally doolally, the one downstream will regenerate.
Regeneration is *good*. except that the upring node is spewing filth onto the ring. So, the regenerated token is lost in garbage. Guess what happens next?
Yes! the next node tries to regenerate.....
Identifying this is easy. Find the node that is still operating. Then, find the nearest axe, and apply it with enthusiasm. Amazingly, the LAN recovers within seconds.
I still bear the scars of a TR network that failed. We split it every way we could. Eventually, we we took the server with the borked ISA bus (feeding the NIC) out of the loop.
All I can say is *GET THAT BOX OFF THE LAN* You are pissing people off with it. That is *not* good for Linux.
I would say "rewrite the network drivers", but that's pointless. Say sorry (repeatedly) and advocate Ethernet. I'd rather have collisions than catastrophes...
so that the humour is more readily apparent.
Lasers Controlled Games!
Token ring was often more reliable than Real Ethernet Thick-wire with Vampire Taps - the mechanical connectors were better than just chomping your way into a coax cable with the possible risk of trashing the code enough to get reflections. I'm not sure if it was better than connectorized thinwire or not, and it certainly wasn't better than Cat5 10baseT, at least if you used genuine Cat5 and didn't cheat with Cat3 (or didn't use cable-TV coax instead of proper thinwire :-) Back when I used to deal with this awful stuff, I had one customer for whom the original Ugly Shielded Twisted Pair token-ring really did make sense - they were a city's Department of Water and Power, and they had lots of Really Big Electric Motors which were a really bad electrically noisy environment, and their network needed all the help if could get. These days I hope they're using fiber.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Get a Cisco 2513 - one token ring DB9, one ethernet AUI - have them give you your own subnet. Should cost you about $650 on ebay. You'll have to twist arms with a hydraulic press though
Are you sure the LAN trolls aren't making you get off linux by pointing a finger every time the network is dorked up? I put up with that sort of crap endlessly at a large (4k employees) company. One day I ceremoniously unplugged the linux box with my boss watching and left it down. Sure enough, that afternoon, the corporate creeps were on the phone demanding we turn off the 'linux problem'.
Diane's head would spin around and she'd spit nails when upset
I am very easy to get along with, but I don't have time to waste being nice to people who are being stupid. -Theo
I've ran into the same same thing... Ended up upgrading completely to FreeBSD and OpenBSD where applicable, now everything works like a charm and NEVER any down time whatsoever.
Oh fergawdsakes, will this urban legend ever die!
It simply isn't true.
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
He deliberately broke the driver so that people stop using braindamaged technology. In the end everyone wins.
Like when they went out to get wood for the fire, they were "collecting faggots" (getting wood.. huh huh huh)
Or "there are queer folk out in the night"
One Linux box vs an entire network of Windows boxen would a killer pay-per-view. Put my money on the Linux box anyday.
Hello,
i tg_v1/tr1906.htm
I used to work as a network engineer at T.Rowe Price and associates. Before our ethernet conversion I was responsible for over 400 PC's on a token ring network.
To understand how this happens, you need to understand how the token ring topology works. Token ring avoids data collisions by sending data based on a token passing scheme. Only one computer, the one with the token, is allowed to send data at a time. This prevents collisions and actually speeds a large network up.
Ethernet, on a large flat shared media network, would go extremely slow because of collisions. At the time, token ring was the best solution for a very large network. Ethernet switching has fixed this problem with ethernet, but that is another subject.
When your network card beacons, it does not let go of the token. Therefore no other computers can transmit data.
My advise is to first check every inch of wire between you and the MAU (where you are plugged into the network in the closet). If the wiring is good(you can plug a different pc in and it, or a tester, works... the only way to be sure.) try another network card in a lab(so you don't shut the network down), if that does not fix it, then try a different kind of card (or a known good card taken out of a working PC, only way to be sure). If your setup worked at one time, it is definitely a NIC (network card) hardware failure or port problem. Most likely it is the card. Try re installing the drivers (make sure they are really deleted before re-installing) and get the latest linux drivers for the card. If you compiled your kernel, do a make clean and a make dep. Find the correct module and copy it over the existing one.
They were probably pissed because it takes forever to find a beaconing problem. I mean hours. There is no easy way to do it (or at least there did not used to be.). They blamed the OS because they don't know linux: ). Sounds like you need a linux admin (and a switched ethernet network) in your camp.
This problem is totally OS independant and the primary hazard of using the token ring topology.
Don't let them shut you down. Simply point them at http://www.cisco.com/univercd/cc/td/doc/cisintwk/
And search for "beacon" in the page. Under "Fault Management Mechanisms" There is a piece of equipment you can put on the network to prevent this but it does not always work. This explains beaconing.
Oh fergawdsakes, will this urban legend ever die!
It simply isn't true.
Actually, it is true... Under ethernet, the more nodes you put in a collision domain (this is layer 2, not to be confused with a layer 3 _broadcast_ domain), the more likely a collision, the more time is spent recovering from collisions. The exact 40% depends on how many nodes are on the segment and how much info they have to send and how often, but 40% is in the ballpark for when problems start to appear
There is a very simple (and not very expensive nowadays) way to get around this problem: use switches in place of hubs. A switch creates a two node collision domain (the switch and the end node). In fact, when full duplex is enabled (only possible with switches for an obvious reason) the collision detection is turned off.
The result: no collisions and thus you can get even more efficient than token ring (no token to wait for).
Do you actually have any stats to the contrary? My numbers show about 30% actually.
I've never had a 10/T segment with more than 5 computers active get any more than 2-3Mbps in backplane bandwidth.
With a switched hub, yes, you get full bandwidth between each port (assuming the hub has sufficient backplane bandwidth to deal with all the inter-port traffic), but with normal "old-fashioned" ethernet hubs, no, you don't.
- Michael T. Babcock (Yes, I blog)
Perhaps the reason it won't die is because to those of us untrained people who through a network together using hubs rather than switches, it looks to be true. When the network load meter gets to about 60%, the col. LED stays on almost permenantly.
I'm an working at piecing together the gear to run FDDI. It is a 100mbit token ring design. It probably isn't quite as good as full duplex fast ethernet fully switched, but it is cheaper, especially when looking at hooking up older machines from SGI and Sun.
I'm a loser baby, so why don't you kill me.
Not greater truth has been written about Token Ring!
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
Why on earth would you boot into windows to view ppt's??? StarOffice handles them brilliantly..
On a half-duplex network of hubs, it certainly is true. The (old) Interpath office was living proof -- 10base2 (coax) ethernet. And when the office moved to Spring Forest Rd. it got a little better, but too many things still lived on hubs. I got tired of it and moved my desk (and most the sysadmin "wing") to a switch... atop the mini-fridge at my desk :-)
(Of course, my desk was a mini-server farm anyway.)
i know of a number of larger credit card processing/data centers that will be stuck with them for some time
It sounds very much like you're trying to insert into the ring at 4mbps on a 16mbps ring or vice versa. That will freak out other things on the ring pretty badly. I know of successful Olicom usage, but I always used an IBM PCMCIA Token Ring 16/4 card. Check your ring speeds.
Check the speed on your Token ring adaptor and make sure it's set to the same speed as the ring. If that's wrong you will beacon the ring and it will cease operating. Yep - gotta love Token ring.
There is Lotus Notes for Linux, you don't have to run it on wine.
Some how I do not think this is an ideal solution. A cisco 2513 is designed to be an access router, not for not for switching between its 2 lan interfaces. They are merely a convenience on that particular model. I searched through the product literature but can't find its bus speed. Considering its designed for a maximum bandwidth of 2 2.038mbps E1's, I doubt it's anywhere near the 533Mbps & 1 Gbps 7000 & 7500 series routers which are actually designed for this. Coincidently, they also cost a lot more. But I doubt you'd get anywhere near wire speed (16mbps) switching between the ethernet & token ring ports on a 2513 (please correct me if I'm wrong).
You'd be just as well of assembling a 486 with an ethernet and token ring card, and one of the tiny Linux distributions that do routing. This still isolates you into your own segment however. I'd be interested in knowing whether linux can bridge the interfaces rather than route..
Token ring's big problem is that it's an expensive solution whose time has come and gone. Unfortunately, the existing infrastructure will make it hard to move away from legacy token ring solutions on to better solutions such as gigabit ethernet.
Probably the best solution for you, is to find a few willing terrorists to crash an airline or two into your building, and then when you are rebuilding, you can redesign your network all over again.
HTH. HAND. YHBT. GOAT.
(Please rate my troll on a scale from 0 to 10, it will help me target future trolls appropriately. Thank you for your support!)
Token Ring has a lot of features that Ethernet doesn't, such as Layer 2 load balancing. Ethernet is just as susceptable to problems as Token Ring, but most large corporates using either have moved to switching technology by now which tends to isolate problems to single machines. It's not as easy for many large corporates to switch technologies as some people suggest, they probably have significant investments in staff training, spares stock and network infrastructure as well as just the workstation NICs. If they are an IBM house, they may also rely heavily on Source Route Bridging to access servers and switching to Ethernet would require all new software on servers and clients and possibly a major reengineer of their main network.
On the topic of the "Ring errors", more information is needed. Exactly what errors were being seen, and is the end station connected to a dumb MAU or a modern TR switch. I suspect for some reason the Linux workstation is connected to an old MAU (Like an ethernet hub or even old 10Base-2 cabling) rather than a switch and for some reason the card is repeatedly resetting or dropping the token, which is probably a driver fault given the fact it works in Windows. There's not necessarily a lot that could have been done to pick this up, because it doesn't immediately bring the ring down and very few corporates really stress-test every possible piece of hardware, software and driver before deploying it unless it's part of a major rollout of a new technology. Had the same problem occured in the Windows driver as part of an update, I doubt it would have been picked up before deployment unless part of a major rollout for example.
This looks like something that happened a few years ago where I was working.
If the driver sets the card to 4MBits (The token ring cards have different speeds) the whole ring will pop into 4 Mb/s and the ring will crash as a result.
It was at a
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
My last company used to have a Token Ring network. THey had the same problem if an IBM PS/2 was brought up on the network at 4Mbps and not 16Mbps. In short it would bring down the entire network.
I did not view this as a PC problem, but an inherrent problem with Token Ring, so I moved that the company should migrate to Fast Ethernet, and low and behold they did.
That was the end of that particular problem.
I used to have an IBM Token Ring card in my laptop while working for Toshiba.
In fact all of us used Linux on their PC and we never had any trouble.
Greetings
Poohbaer
I used to work for the major AS400 software house in the UK and had a lot of dealings with token ring (and Twinax!!) and we found the major cause of network issues was the type of card.
Madge cards do not like working in an environment with IBM cards (okay they have sorted things out a wee bit, but it still isn't perfect) because IBM token ring cards run to lower timing tolerances. This is fine where all other cards on the ring accept this, but Madge cards are designed to much higher specifications and easily start beaconing if the previous/next card round the ring is off on its timing.
Your best bet is to get hold of those IBM drivers and use an IBM card - and go for a test environment for a wee while too:)
We NEVER run any prehysteric crud at ScaredCity(?tm?)
Take a chance, roll the dyce, maybe you'll be the ones to post a fix to this whoreabull duhlemming, at this somewhat descriptive URL.
fud is unamerican/dead. long live the hobbyist whiners.
i'm guessing the card defaults to 4mb/s and your token ring net is 16mb/s. fucking broken ring.
The canonical reference is: Measured Capacity of an Ethernet: Myths and Reality.
Note particularly that Van Jacobson was able to obtain measured TCP throughput of 8Mb/s in the 80's.
There is a good review of the area in the O'Reilly book on Ethernet too.
The limit of five Tolkien rings can be a problem for large corporate empires. And adding a new ring can be quite a quest.
Thats why
A. it didnt work when windows did
B. to fix it you would have to patch and recompile the kernel
C. nobody cares
what kind of fucked up advice is this?
what the hell is wrong with you slashdot people?
In other words, if you haven't adopted the 100baseT it's 'cause you been too busy passing the dutchie on the right hand side.
AC's cheerfully ignored
I bet your world circles around "getting laid" and not much else. Let's hope you reincarnate into something little more intelligent next time around.
I have been using a Madge token card in Linux servers running Red Hat 6.2, kernel version 2.2 and also client workstations running Red Hat 7.1, kernel 2.4 without any problems. I complied the driver on both 2.2 and 2.4 using the source downloaded from http://www.madge.com/Connect/Downloads/Software and have had few to no problems with it since. Are you sure the Madge card is what's causing the problem?
A small correction. It is common fallacy that ethernet maxes out at 40% of nominal capacity. This non-fact was started by a very old paper by Matcalf etc. that used a pretty crude model that came up with that ~40% figure. Actual tests show that ethernet is effecient up into the 90% range on collision domains with hundreds of nodes. See the O'Reilly ethernet book for details. Note that this is not talking about switched/full-duplex ethernet which is better still.
The world is full of people whose notion of a satisfactory future is, in fact, a return to an idealised past. -R. Davie
I was involved as a consultant some years ago (ca 1996) with the decision of a college to migrate from TR to ethernet. At the time the situation was very cloudy; TR was clearly on the way out, but there was some question as to whether we should go FDDI or CDDI or perhaps ATM for the network backbone. I recommended the use of Ethernet throughout the system. Ethernet,in its most primitive an naive implementations, has a number of problems when used as a basis for a large network. The answer, of course, is not to use it primitively or naively.
Ethernet evolved from networking schemes used for packet radio. The original idea was you had a single medium (a long cable) that was shared by a number of hosts. As in radio, they were supposed to listen before talking (Carrier Sense Multiple Access/Collision Detection or CSMA/CD) so they didn't garble each others' messages (collisions).
CSMA/CD networks have two problems: (1) throughput begins to collapse somewhere between 40% and 50% of the nominal speed due to collisions and retransmissions and (2) packets delivery cannot be guaranteed within a fixed time (although at low loads latencies tend to be very low).
However, Ethernet switching technology has taken care of the througput problem by reducing the number of machines sharing a medium for purpose of collision detection, to the point where a single workstation on a full duplex switched port can never have a collision. A combination of switches with huge backplane capacity, spanning tree, trunking, VLAN and powerful routers give the administrator great flexibility in delivering network capacity to every port on his network, along with excellent scalability.
The only thing that remains is guaranteed delivery times for packets; although stations needn't worry about collisions, there is still queuing time within the switches to consider. This might affect people attempting to stream broadcast quality video over their network to several workstations, who might choose to go with 100Mbit token ring. In theory QoS is supposed to address this, but I haven't seen it used much. Most streaming media applications are Internet centric, and buffer their data to prevent problems due to the much more random nature of the Internet. It is possible to contrive scenarios where you need QoS or isochrounous packet delivery (e.g. high quality video conferencing over a LAN) but these haven't proved to be very important. If they were, then ATM would probably be a better choice than TR.
Of course TR still has to be supported for places that have too much human inertia to switch, but I don't think there is any technology that is superior to Ethernet in its cost effectiveness for the widest range of corporate applications.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Then you have to do translation bridging, which basically sucks, and is not working under Linux. With a cisco box it does but still sucks.
Warning: Kludge fix
Get some sort of cheap, but compliant, ethernet to token ring switch/router. Plug ethernet in on your side of the thing and plug token ring into the other.
Theoretically, it should work. However, I am not aware of any specific products. I have a friend with similar ATM problems and they grouped the people on one side of a router that seperated and translated from ethernet to ATM. Fixed the problem at a moderate cost.
Hope this helps
You can build a pretty decent 92 ohm transmission line with barbed wire -- Its the inductance and capacitance of the ( the geometry for non-fields thinkers ) that sets the characteristic impedance. Read here a good article from Howard Johnson @ EDM magazine.
what are you talking about, VAXen RULE! Especially when running OpenBSD
Ethernet QoS is rarely deployed, but that's largely because there is less need for QoS in the LAN - most switches and links have more capacity than they really need, so as you point out only videoconferencing, VoIP and other non-streaming multimedia really need QoS.
Many Ethernet switches support 802.1p (a priority field within the 802.1Q VLAN header), allowing basic prioritisation. The larger L3-aware switches also support IP Precedence or even DiffServ (e.g. the Catalyst 6500). In the longer term, as policy-based management becomes more widely deployed, it's likely that switches will have 802.1p turned on, largely to support VoIP (since that is actually being deployed on some networks).
That's not true. I'm also interested in getting drunk and burping as often and as loudly as possible. Log off and try it sometime.
This, of course, is more of a LAN than a WAN point.
I've run token ring on linux with no problems. I've had some problems with hubs that messed up the token ring network, but that is another story.
While I was contracting at IBM a number of people were using linux on the token ring. (IBM is switching to ethernet at the NC location btw)
You should really provide more information on this problem. It might be a configuration issue of some sort.
All in all, token ring is a bad standard, even IBM has come to realize this. If one little laptop can bring down the network just by booting, you've got problems.
The important thing to remember about Token Ring is that the adapter and driver tend to be fairly stateful. By this I mean that the adapter is either in the ring or out of it. 90% of all problems then proceed from being in Limbo.
We used to have all kinds of problems whenever a desktop was warm booted. The adapter never got a power reset, and never got a software command to exit the ring. If the desktop software then didn't rejoin the ring (i.e. reinitialized the card from software reset to being OPEN), then the adapter was in the ring, but the driver wasn't. Eventually the adapter/driver receive buffers fill up since nothing is emptying them, and the adapter spews RECEIVE CONGESTION errors. This will trash your Novell servers (does anyone still use these?). I imagine that your problem is similar to this. Errors in ring speed would cause BEACONS, not errors. Are you dual booting, or anything similar? Does your PC go to sleep or low power mode? Anything that might interfere with draining the receive buffers will eventually cause problems.
I know the easiest way to bring a token ring network down is to put a card set for 4mb/sec on a 16mb/sec network or vice vera.
Until now why the CCIEs at my last company called it "Broken Ring".
Linux Token Ring bringing down corporate nets?
How about this: Two Linux machines, each pingflooding the network as fast as they can. ping -f -b 255.255.255.255
Another computer on the same LAN, still was able to browse the Internet and communicate as if nothing was happening!
Try that with Ethernet...!
Dr. Demento On The 'Net!
Halal says: Linux is santa and must be deployed.
Oh, and why you post anonymously?
anarcho-roboticist [lopster incomplete: 6.5% of 2.5GB]
I certainly did not ask it to generate ring errors when I put the card into promiscuous mode.
Back In The Day, when only IBM, Proteon, and Novell were building Token Ring hardware, getting your hands on a NIC that would do promiscuous mode was not easy. It was specifically intended that stations not be able to turn into packet sniffers, because the stations of the time weren't up to the workload of recording every packet that flew by. And unlike promiscuous Ethernet NICs (which we all used with the good old MIT PC-TCP package), when the TR NIC doesn't keep up, don't nobody keep up.
I remember once when one of the teachers was having problems with her telephone and decided to pull out the RJ-11 patch cable since it looked the same and use it as a phone line to see if that was the problem (it wasn't).
A guy I used to work with had something he called "Ron's Rule of Connectors":
He started seriously ranting when keyboards started coming out with RJ-11 plugs. A guy in the electrical shop responded by wiring up a 3-prong 120VAC power cord with an RJ-11 jack for him!The point, of course, is that there's a reason the National Electrical Code specifies a different kind of connector for every different use. The big honking Type 1 Token Ring plugs are never mistaken for anything else, and never wind up being plugged into the wrong place. Anybody who ever fried a laptop modem by jacking into a hotel's digital phone system understands the issue.
Of course, then IBM went and screwed it all up by creating 16Mb TR and the resulting problems from having 4Mb and 16Mb stations on the same ring!
If you're having a problem with the Madge adapter, try the IBM Token Ring 2 cards, which use the olympic driver. These seem to be the most stable and reliable card/driver combo at the moment and the source for the driver comes with the kernel.
---
Kent Yoder - yoder1(at)us.ibm.com
IBM Linux Device Driver Development