Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Network & Systems Infrastructure
W O R K S H O P  
Escaping Token Ring Without Losing Your Shirt or Mind

  April 16, 2001
  By Jonathan Feldman

Just 24 months ago, some pundits were still arguing that token ring was not a sinking ship. Token-ring switching had finally arrived; DTR (direct token ring) kept up with the Ethernet Joneses by offering full duplex; and the High-Speed Token-Ring Alliance (HSTRA) was posturing "bigger, badder and better" with the release of 100-Mbps token ring. Token-ring shops breathed a collective sigh of relief. Nobody wanted to spend the time or the money ripping out perfectly good infrastructure simply because a bunch of so-called experts declared token ring dead.

Yet today token-ring vendors have dropped like flies. The high-speed token-ring initiatives never did garner industrywide support. Indeed, out of the original seven HSTRA members, only two remain. And modern product and driver support for token ring is scarce, or extinct, because vendors are out of business.

In a world where full-duplex, switched Fast Ethernet ports with all the accoutrements can be nabbed for less than $90, spending double for just the token-ring adapter (not even taking into account the switch port), just doesn't make sense. Nod in agreement if you're one of those who have had to deal with substandard technical support from a vendor's shrinking token-ring business or have tried to find trained technicians for in-house support. Add the fact that troubleshooting and maintenance tools for Ethernet have rocketed past their token-ring peers and, sadly, in a "grow or die" industry, token ring's days are seriously numbered.

The question becomes, How do you get off the ship before the lifeboats are gone, without losing your shirt in the process? Over the past several months in our Savannah, Ga., labs, we converted close to 500 shared token-ring nodes to fully switched Fast Ethernet. We learned a few important lessons along the way: You can avoid the expense of repulling cable by using Type 1 cable converters, but it's not foolproof; using ATM as a translation medium just complicates a simple routing issue. And having a comprehensive game plan for transitioning servers is a must.

It Ain't Broke?

A lot of arguments -- mostly cited by IBM Corp. and Madge Networks, the last bastions of token ring -- support preserving the status quo. If you're living in the Southeastern United States, the phrase you might hear most often when contemplating replacing a token-ring infrastructure is "If it ain't broke, don't fix it." But let's take a closer look at how "not broken" token ring is, accounting for issues such as maintenance and a never-ending stream of user requests for additional workstations and appliances.

The biggest argument given by folks who would rather leave well enough alone is that nothing is worth recabling your building. At a street price of several hundred dollars for a new wire pull (contractors would look at you cockeyed if you even suggested they use existing conduit), you'd have to be nuts to rip out your cable plant unless you had a really good reason. But shielded twisted-pair Type 1 cabling is capable of carrying 100 Mbps worth of signal, and inexpensive converters can drop your cabling expense to about $30 per port.

If you already have plans and funding to recable a building for Category 5, it certainly is the preferable long-term solution. Cat 5 is probably not "future proof," but it's definitely "future probable" as compared with Type 1. So, if money is no object, getting a Cat 5 cable plant is best. But if you can't sweet-talk management out of the dollars for new cable pulls, or you could use the dollars elsewhere, cable converters are a tolerable fix.

Finally, a fact of life is that stuff breaks -- and this stuff is not always a PC-and-NIC combination. What if your entire token-ring network were built on NICs from a company that is no longer in business? Where would you get new drivers?

What do you do when your out-of-warranty (or out-of-business vendor's) hardware print server breaks and you have to replace it? Finding any token-ring appliance is expensive and time-consuming; print servers are difficult enough to locate, but try finding a departmental CD-ROM or DVD server. Even worse, if your first-generation hubs or MAUs (multiple access units) break, or if you need to purchase more capacity for new nodes, you'll find yourself between a rock and a hard place.

Do you buy or find used MAUs, or purchase (much more expensive) token-ring switches? If you choose the cheaper route, you'll need to think twice about why you are spending on labor to deploy such out-of-date hardware. If you choose the more expensive route, you'll kick yourself later for buying a pricey token-ring switch instead of a less expensive, more feature-rich Ethernet switch.

Design Considerations

Three words come to mind: plain old router. On vendor advice, we initially experimented with designs involving ATM and LANE, since few folks are making routers with both Fast Ethernet and token ring these days. We concluded that having an expensive and complex system just wasn't worthwhile in light of our goal -- to build a temporary bridge between two dissimilar topologies. If everyone on your old token-ring network is comfortable with running on shared 16 Mbps (regardless of token ring's better-than-Ethernet's shared throughput), they are not going to notice when you put several rings on an older token-ring/Fast Ethernet router.

Again, however, you hit the "nobody makes token-ring equipment anymore" wall. You can consider "aftermarket" equipment. Snag a used router with both required interfaces. If you are not picky about brand, aftermarket routers tend to be priced low. Fancier stuff is easier to find: A search on Google quickly reveals sites that sell used Cisco Systems gear, such as www.msic.com/used_networking/cisco/ecisco7000.shtml.

Or, if your needs are modest and the aftermarket environment is less than kind, there's always the "grow your own" strategy with a server and operating system of your choice. Whichever path you choose, you'll want to weigh your support options. Consider whether it's better to use current operating-system support for a server/router, or whether you'd rather purchase a support contract for an aftermarket router. Depending on market conditions, it may be difficult to obtain spares for older hardware routers, so you'll want to think about purchasing spares up front. Or you can consider using a software router backup for the hardware router.

If you discover older network gear that claims "translational" switching or performs some sort of encapsulation instead of routing, do yourself a favor and don't use it. Stick to routing.

If you decide to use the older gear despite this warning, test it thoroughly before deploying; the translational switching must swap the frame's bit order, because token ring's frames are put onto the wire starting with the MSB (most significant bit) method, as opposed to Ethernet's LSB (least significant bit) method. Since the translated frames aren't inspected above Layer 2, nothing at the packet level is translated. This can break certain applications.

The translational switch must reverse the data-link addresses between the two networks. However, it does not look into the frame above Layer 2 to see if other data-link addresses also must be reversed. If an application uses a data-link address, such as DLC (data link control) and Novell's RPrinter, in its data packets, the address doesn't get reversed. The Layer 2 address doesn't match up with the address inside the packet and you have a broken application.

Once again, the "plain old router" will serve you best. You will have to intelligently move your servers over as the user community moves, so that the pipe between your two networks doesn't get oversaturated. This is easy when there are departmental servers and more difficult when there are many departments on servers. If you have done a good job of baselining your networks and have a clear idea of the traffic between subnets and servers, you won't have a problem.

Using Type 1 Converters

Naturally, even if RJ-45 is supported on many token-ring cards, you simply can't plug a token-ring hermaphrodite-to-RJ-45 cable into an Ethernet network. For one thing, the pinouts are wrong (instead of 100BASE-T's pins 1, 2, 3 and 6, token ring's RJ-45 pinout uses the inner pairs, pins 3, 4, 5 and 6). In addition, the impedance on Type 1 cable (150 ohms) is different from that on Cat 5 (100 ohms).

You will need to use either an Ethernet switch that supports both 100-ohm and 150-ohm impedance on its ports, such as Cisco's Catalyst 3500-series switches, or separate impedance matchers.

During our rollout, we used Catalysts with plain Type 1 cables, and Nortel Networks' 450-series switches for those places where we did use impedance matchers.

Impedance matchers correct both the pinout problem and the impedance problem. They build electronics between a Type 1 hermaphrodite socket and a female RJ-45 socket. (For example, Transition Networks makes an impedance-matching device, part number ICS-45-100TX-C.) Surprisingly, the devices have basically the same price as cables that merely correct the pinout problem. While we were initially enthusiastic about impedance matchers, we quickly discovered that they represent another point of failure on your network -- much more so than cables without impedance-matching functions. We had no plain-cable failures but experienced several impedance-matching failures during our testing. (IBM makes a cable without impedance matching, part number 31L3819).

We had problems using the Type 1 (150 ohm) cables on our Nortel gear, but they worked fine with the Cisco gear. We used impedance matchers on both the Nortel and the Cisco gear without a problem. Finally, when using Type 1 cabling, remember that the standard IBM-style hermaphrodite connector clicks into loopback when it's unplugged. This is true even for wall outlets. While the loopback is necessary for token-ring users (it keeps the integrity of the ring), it becomes a problem when you convert to Ethernet. This is because a looped Ethernet, without Spanning Tree, will introduce an infinite loop of frames into your environment. (See the graphic, "Type 1 Ethernet Installs Require Spanning Tree on Switches," above.)

So be sure to enable Spanning Tree on your closet switches. While it's tempting to eliminate Spanning Tree if your switches aren't hooked together in a loop, if you have a potential loopback plug on every port, you have a potential loop condition on every port of your network. Without Spanning Tree, a user can disable an entire VLAN (virtual LAN) by unplugging the converter cable from the wall.

You should test your Spanning Tree setup carefully. When we used the Catalyst 3500 switches, a particular problem we discovered was that the Spanning Tree negotiation on a client port was so time-consuming that our workstations with Novell's Client32 malfunctioned. This was fixed by using Cisco's PortFast feature (on the 3500-series switches), which substantially shortens the time before the port comes up and guards against loops.

Not every environment has this concern, but any time-sensitive application could be affected. Again, you'll want to test before deploying switches in your environment.

Jonathan Feldman is chief technical manager of the Chatham County Government in Savannah, Ga. Send your comments on this article to him at jf@feldman.org.

Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013

TechWeb Careers