The Windows NT Network Monitor and I had our first tentative meeting several months ago. I was logged on to my Internet Service Provider (ISP) and noticed the Remote Access Service (RAS) monitor's transmit and receive lights blinking. The traffic appeared to be originating at my server, although I wasn't running a Web browser. Curious about the source of this activity, I started the Network Monitor and smugly told it to log network activity. After the transmit and receive pattern reoccurred several times in a 3-minute period, I stopped the logging and asked Network Monitor to display the results. To my surprise, I saw absolutely nothing.
Thus began my long and sometimes frustrating adventure with network monitoring. Read along as I retrace my steps: choosing and installing the "right" Network Monitor, setting it up to capture network packets by populating the Address Database, learning how to log activity for my local network and RAS connection, and figuring out how to include or exclude specific protocols from the capture file. I also show how to customize a capture file display and interpret the individual frames.
Installing Network Monitor
The version of Network Monitor that ships with NT Server is a trimmed-down version of the
Network Monitor that ships with Systems Management Server (SMS). The NT version captures packets
only on the machine it's installed on, and the SMS version captures packets from any system the
Network Monitor Agent software is installed on. This configuration is a security measure to keep
users from watching network traffic (although most users I know would rather be reading War and
Peace). Thus, if you want to monitor network activity on a local system only, install the NT
version; to monitor remote systems, install the SMS version.
You install the Network Monitor that ships with NT as a service in Network Properties. In the Network Properties display, select the Services tab. If the Network Monitor Tools and Agent entry is not on the list of installed services, choose Add and select the entry from the Select Network Service scroll list shown in Screen 1. Press OK to start the installation. The Agent collects packet information on the local machine, and the Tools portion captures, filters, and displays the results. After you install Network Monitor, you see a Monitoring Agent applet in Control Panel and Network Monitor in Administrative Tools.
To install Network Monitor from the SMS distribution kit, find the top-level directory--SMSnn (e.g., SMS12). The Network Monitor files are in subdirectory nmext. Run setup.exe on DISK1 (e.g., sms12\disk1\setup.exe). The SMS version places Network Monitor in a common group called Network Analysis Tools and places the Monitor Agent in Control Panel.
During installation, you're prompted to specify passwords to view captured log files and capture and display network packets in realtime. If you are in a lab or test environment, you can select No Password to disable security. However, if you're installing the monitor for enterprise troubleshooting, take advantage of the password controls, which provide a safety net for keeping unauthorized users from watching network traffic and possibly picking up clear-text passwords. (If you later decide to place password controls on the capture or display functions or change from no password to passwords, start the Monitoring Agent from Control Panel, click Password, and enter passwords as needed.)
During the last portion of Network Monitor installation, both versions prompt you to install the Monitoring Agent for this machine. The setup program finishes by starting the Network configuration applet, so you can then install the Network Agent. After you install the Agent, reboot to complete the installation. You must install the Monitor Agent service on all systems you might want to monitor in the future.
The Address Database
The next step is adding media access control (MAC) and IP addresses to the capture file and
associating them with real names to make the capture file more self-documenting. Because logging
network packets is fairly complicated, Network Monitor has many defaults established to help newbies
get started. To add addresses to the capture file, open the Address Database, shown in Screen 2, via
the Addresses entry on the Capture drop-down list. Network Monitor creates broadcast, NetBIOS, IP,
IPX, Token-Ring MAC, and Ethernet MAC addresses for the local machine automatically.
To add other system addresses to the database, start a capture from Network Monitor's Capture menu; let it run for a few minutes or a long time, depending on the number of systems in your network; and stop the capture. Then select Find all Names from the Capture drop-down menu to associate computer names with their MAC and IP addresses. This step adds entries only for systems active during the capture; addresses for systems that are powered off or are not generating any network activity aren't included.
You can also create address entries manually for systems you want to monitor. I created three pairs of entries--an Ethernet and IP record for each of the three systems I was monitoring--by entering the MAC or IP address, the corresponding machine name, and a comment for each via the Address Database dialog box.
The initial address database file is stored as default.adr in winnt\system32\netmon. You can customize address files (e.g., by subnet) and load a specific address database to watch different portions of the network. If you expect to monitor the network from several different systems or locations, you can store your custom address files in a shared network directory. You can load an address database only from within the Address Database dialog box--select Load and then the address file of your choice.
Logging Network Activity
When I started capturing RAS traffic, I assumed Network Monitor would automatically snag all
frames, regardless of their origin or destination. To figure out why my capture log came up empty, I
selected the Networks option on the Capture menu to look at the capture log. From the list of
connections on this screen, I identified two potential sources of the unknown traffic: the NIC,
which Network Monitor labeled NET1, or the remote connection NET2 (I identified this entry as my RAS
link because it was flagged as a 28800 connection). Then, I selected NET2, started the capture,
generated some RAS traffic, and stopped and displayed the results. Once again, the capture log was
empty. I decided to explore the remaining Capture menu items.
Including or Excluding Protocols to Capture
I worked with the Capture menu's Filter menu item next. When I selected Filter, I saw that the
filter was set up to capture address packets for Ethernet, not the RAS IP connection. Although I
selected the RAS network, the capture looked for Ethernet frames, which of course don't exist on the
dial-up connection. To reset the capture for IP address packets, I double-clicked Address Pairs,
which displayed Screen 3. On the right side, you see three entries for VAIL, the NT server
on which Network Monitor is running (i.e., the local system). The first entry is for the server's
LAN connection (TCP/IP address 209.38.26.1), the second lists a MAC address, and the third shows the
fixed IP address 166.93.17.126 that my ISP assigned. I selected the second entry, used the default
two-way direction (i.e., capture packets sent to and from the RAS), and asked to see all frames from
any address directed to the RAS network. I then restarted the capture.
Notice the Include and Exclude buttons at the top of Screen 3. These buttons let you fine-tune the frames you plan to collect. If, for example, I want to see only traffic from VAIL to ASPEN on the LAN, I select the VAIL entries on the left and the ASPEN entries on the right. I can further reduce the frames to only those originating in one direction or the other, rather than monitor all packets between VAIL and ASPEN. This feature is great for troubleshooting problems with a specific machine. It's also a useful way to see the network traffic generated after a reboot when a system registers itself on the network.
Once I set the capture for IP packets, I started a new capture, dialed the ISP, logged RAS activity for 3 minutes, and examined the results, hoping to end the search for the random RAS chatter that started this adventure.
Screens 4a through 4d show the capture that finally worked in several sections. Notice I color-coded the frames to make the display easier to read and patterns of repeat activity easier to identify. To color-code or otherwise fine-tune the capture view, when the capture window is open, select Display and then Font, Color, or Options. If you're new to reading network frames, you'll find that the last columns of the display, Source and Destination, help you identify and understand which system is sending and which is receiving each frame. To see a frame broken down into its constituent parts, rather than the summary view shown in these examples, double-click the frame you're interested in.
Screen 4a shows the Point-to-Point Protocol (PPP) negotiation between RAS and the ISP to establish the Internet connection. (For a list of protocols you often see in captures, see the sidebar, "Common Network Protocols Glossary,".) Link Control Protocol (LCP) requests are sent to my server with no return acknowledgment because LCP is disabled for this RAS connection. A PPP Password Authentication Protocol (PAP) request is sent and acknowledged. After the connection is successfully established, both sides exchange a series of control frames (Internet Control Message Protocol--ICMP, and IP Control Protocol--IPCP).
Screen 4b shows the results of a ping to slate.mines.edu, the Colorado School of Mines network. In frames 32 and 33, my server (VAIL) sends two Domain Name System (DNS) requests (Std Qry), one to the ISP name server 166.93.1.3 and one to a root server at 128.63.2.53. In frame 34, the ISP name server returns the address of slate.mines.edu as 138.67.01.03 (Std Qry Resp). Next, we see four echo/echo-reply pairs in frames 35 through 45 between the RAS address 166.93.17.126 and slate at 138.67.01.03. These frames correspond to the four echos you see from ping on the command line.
Screen 4c shows that I issued an FTP request from another system on my LAN (ASPEN) through the server with the RAS connection (VAIL and RAS connection) to a UNIX system at 166.93.8.14. Frame 160 shows me logged on as anonymous, and frame 162 contains the response Guest login ok, send your complete e-mail address. In frame 164, I enter the password, "password," which the UNIX system denies in frame 165. This incorrect password stops the logon procedure, so I restart the logon in frame 172. This time, I enter the password, "[email protected]," in frame 176, and because my response is in the proper format for an email address, I successfully establish the FTP session. The UNIX system responds in frame 178 with Guest login ok, access restrictions apply, and in frame 180, I issue the bye command, which closes the connection in frame 181. This capture is a great example of why we need to use anonymous user names for FTP sessions and is also strong encouragement for network administrators to implement password controls for capturing and viewing Network Monitor files.
The Ghost in RAS
Remember, my original reason for using Network Monitor was to identify random network traffic
over my dial-up connection. Color-coding DNS queries red helped to instantly identify the source of
the traffic, shown in Screen 4d. As frames 416 through 433 show, DNS queries are issued every two
minutes for the name JSPNRMPTGSBSSDIR. In the full version of the capture, this name repeats through
frame 479. Every second or third frame, one or another of the 12 DNS servers queried responds that
the name does not exist. (You can't see this part of the frame because I shortened the columns to
fit the screen on the page.) This pattern repeated every couple of minutes as long as the server was
connected to the ISP. As soon as I disconnected, the queries disappeared, something I proved by
another capture with the Network Monitor. Thus, I concluded that RAS, or the dial-up networking
module, is responsible for these DNS queries.
Now, because I set up my own DNS server I know that absolutely no references to this name appear anywhere on my LAN. Furthermore, queries to 12 different InterNIC root name servers all return with the name does not exist message. I searched the Microsoft Knowledge Base for the string JSPNRMPTGSBSSDIR and found a match. My exact problem is described in article Q150820 (July 2, 1996), which, for some mysterious reason, has been removed from the Knowledge Base. The article states, "The name JSPNRMPTGSBSSDIR is announced regularly and is a normal occurrence from a Windows NT server or workstation running the Windows NT Remote Access Service." Apparently, there is no way to disable this query and no description of its purpose. Now we all know about the ghost in RAS, and the ghost's name is JSPNRMPTGSBSSDIR. More important, we have demystified the network-monitoring process.
