Previous Table of Contents Next Broken Ring Consider the case we talked about earlier this hour: The Windows NT rollout onto a Token-Ring network using Novell servers. Although there were hundreds of Windows 95 PCs that were working just fine, the first pilot test of a Windows NT workstation revealed connectivity problems with the servers-that is, none of the new workstations could see any of the new Novell servers, but they could see some of the older servers. However, all of them could connect to all UNIX and NT servers using TCP/IP. Take a look at Figure 21.7 for a diagram of the scenario: All workstations were on Token-Ring, new servers were on Fast Ethernet, and older servers were connected to Token-Ring. The newer servers were NetWare 4.11; the older ones, 3.x. [21-07t.jpg] Figure 21.7 A problem requiring a capture on two segments simultaneously. Because the pilot test was on one segment, we tried moving one of the workstations to a different segment. Oddly enough, we could now communicate with different Novell 3.x servers. Apparently, we could only see Novell servers attached directly to the ring that we were on. This led us to believe that there was a switch problem. In order to see whether the switch was passing data properly, we connected two analyzers to the network: one to a segment that the workstation was on (point A) and another to a segment that a "problem server" was on (point B). Each packet that passed through the switch should have had a corresponding packet coming out on the other side. In the spirit of keeping the trace files small, we set point A up to capture packets from the test workstation. Because the packets at point B would not appear to be coming from the MAC address of the test workstation (instead, they'd appear to be coming from the switch), we purposely had the workstation connect to a low-use test server and captured all data going to that server. We booted up the NT workstation and attempted to log in to the test server. As soon as the login failed, we stopped both analyzers. The analyzers revealed that the switch was, in fact, dropping packets (it was not that "bad" packets were getting to the server and being misunderstood). Great. So what was happening? We did the same test with a Windows 95 machine and compared the results. Ah ha! The Windows NT machines were using "source routing," a Token-Ring link layer protocol, whereas the Windows 95 machines were not. (We don't need to know what source routing is to troubleshoot this problem; it's enough to know that this was the difference between the two traces.) Because the switch was not configured to allow Token-Ring source routing, it was dropping the packets. We had two possible solutions: configure the switch to allow source routing or configure the NT workstations without source routing. Either option was fairly easy and quick. Case closed! Limitations and Solutions As you can see, using an analyzer can be as much of a time sink as you're willing to let it be. If you were the kid in elementary school who had a good time reading the dictionary, you'll have a great time poring over protocol decodes. If, however, you need to get a lot of work done, you might have to sigh and save the protocol decodes for a less busy time-and employ your black box troubleshooting skills to isolate if and where you need to use your analyzer. As far as physical limitations go, remember that an analyzer can only listen in on a party line. You cannot listen to a station that has a point-to-point connection to a switch, because there's no hub to connect to and listen in on. What to do? ______________________________________________________________ Look in your switch documentation for a feature called port mirroring. This allows you to specify which port of the switch you want to listen in to. Just plug your analyzer in on another switch port, and the switch will do its own wiretap on the port and tell your analyzer all about it. Cool! If your switch doesn't support port mirroring, you can always "roll your own" wire tap, as illustrated in Figure 21.8. Simply do the following: 1. Obtain a mini-hub (Ethernet) or a "node doubler" (Token-Ring). 2. Unplug the network cable from the station you wish to "wire tap." 3. Plug that station's cable into the mini-hub's cascade port or node doubler's "lobe." 4. Connect a network cable from the mini-hub or node doubler to your analyzer. 5. Connect a network cable from the mini-hub or node doubler to the target station. This has the effect of creating a shared segment on the switch port, and you can now listen in. ______________________________________________________________ [21-08t.jpg] Figure 21.8 You can roll your own wire tap for a switch port simply by getting a "mini-hub" and creating a segment between the switch and the end station. Many analyzers are starting to offer remote monitoring agents (or probes) that allow you to monitor several different segments using one analyzer. These "agents" are merely small programs that run on a workstation or a server and have the collection function of an analyzer without the decodes or the statistical analysis functions. The agents then pass on the collection data to the master analyzer, which is located anywhere on the network you want it. Of course, this only works if the network and the workstations with the probes are up, but it's a great solution for multiple segment problems and ongoing monitoring, because you can do this from your desk. Previous Table of Contents Next