Several of my clients have Token Ring problems -- both technological and political.
The technology has held up remarkably well for a long time; only now are some of these networks beginning to experience congestion problems. The political problems are just as significant; senior managers are reading industry trade publications and pressuring IT staffers to migrate away from obsolete technology. The stark reality is that IBM itself has walked away from Token Ring and has lost interest in High Speed Token Ring and Gigabit Token Ring. With Olicom gone and its networking group acquired by Intel this past year, only Madge still actively supports Token Ring. Though Madge sees a migration path toward higher speed Token Ring, a market with one major vendor is no longer a real market.
Many Token Ring networks contain thousands of nodes. There's no way that these networks can be migrated overnight without completely disrupting business. So what should you do if you find yourself in the unenviable position of having to make such a move?
If you have an ATM backbone, you're in luck. You can add switched Ethernet and run it via LAN Emulation; at the same time, you can build a Gigabit Ethernet backbone that operates in parallel until you switch over. This gives you redundancy while the Gigabit backbone is being tested, though supporting two dissimilar technologies and adding more protocols to the network is never fun.
Another option is to migrate the rings that carry the most traffic to switched Ethernet, then use routers or encapsulation schemes to permit the two protocols to coexist. A variation of this approach is to migrate by workgroup or department. This approach allows you to have your most demanding users test the new environment, but could result in significant latency for some traffic when the number of hops is increased.
Companies with multilayer switches are gradually replacing Token Ring modules by adding Ethernet and Gigabit Ethernet modules to them. This is a nice strategy, but since multilayer switches are not really popular today, we're talking about a small number of sites, generally with IBM or Alcatel switches.
Overall, migration by department or workgroup usually makes the most sense because it limits the pain, and latency issues can be addressed by geographic area of the network.
