Network Uptime

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

====
Starting Delimiter
- Back to School -
====

The more I know, the more I realize that I don't know anything. It's a trite saying, but it's painfully accurate in my case. It seems that my quest for network knowledge has seasonal tendencies. I can exist for months without performing any level of research or studies towards a goal, and then I'll spend months consuming myself with information from every possible angle in a quest for personal growth, certification studies, or job-related training.

I'm currently working towards my updated MCSE, researching wireless and Voice over IP topics for the day job, working on my Sniffer Certified Expert qualifications, and sleeping in the remaining available time. It's amazing how well a body can operate on lack of sleep - I'm starting to get really GOOD at it!

My saving grace is that I know I'll be back in 'maintenance mode' in a few months. Once I get some smarts in my head, I like to let them sit there and stew for awhile. I'm a Crock Pot of networking knowledge (http://www.crock-pot.com).

I have mixed emotions about training classes. I'm all for education, but if I spend any extended period in a classroom I want to have a good instructor AND a good group of students. Have you ever been in a five-day training course where the students were uninterested and no one asked questions? Even with great course material and a talented instructor, a training class can become a test of survival against the clock.

Most of the time, I try to sponge as much information as possible from technical books and internet sites. It's easy to grab and book and read the information, but it has taken a number of years to find a group of authors that I can rely upon for really GOOD material. One example is this month's Surf Report which features the transcript of a speaking engagement from Rich Seifert, one of the creators and an ongoing editor of the 802.3 Ethernet standard.

Just like the web, it's all about the _content_. Looks count for something, but when the cover is lifted there'd better be good stuff in the middle. You know, just like a Crock Pot.

- James 'Professor' Messer
Editor, Network Uptime
James@NetworkUptime.com

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

====
Q and A
- What is Utilization? -
====

Our question this month asks about the use of 'utilization' in network statistical reporting:

"My question seems simple enough - it's about what exactly is the %Utilization dial on network analyzers (ie Sniffer) measuring? I've read it to be measuring the %utilization of the "pipe" in use. What is this 'pipe'? Is it the backplane of the switch? Is it the 100mb/s port that the sniffer is plugged into? What if you have a vlan spanned to the monitor port? Then what is this 'pipe'?"

Most protocol analyzers define 'Utilization Percentage' as a percentage of the total use of bandwidth for a link based on a sampling period. Using Ethernet as an example, we know there are only two utilization values in Ethernet; zero percent, and one-hundred percent. Ethernet is either used, or it's not used.

A single chart showing two points alternating between 0 and 100 wouldn't be very helpful, so most utilization measurements are constructed by acquiring a large number of utilization samples over time to provide a more normalized perspective of utilization.

The 'pipe' is the maximum bandwidth available on the link that is physically connected to the analyzer. If the connected link is 100 megabits, then the utilization percentage is based on that theoretical maximum of 100 million bits per second. If you're plugged into a WAN link, the 'pipe' may only be 64,000 kilobits and the utilization percentage will be based on this slower bandwidth. Network analyzers don't have a way to determine switch backplane bandwidth capacities, or the number of ports that might be mirrored to a single port (at least, not yet). The utilization percentage is always based on the maximum bandwidth capacity of the port that's physically connected to the analyzer.

"So what does it mean when the business managers want to see a study of overall network utilization? How can I get utilization information of every switched port in my network? Does it makes sense to gather utilization information in this fashion?"

In most cases, it's impractical (and very tedious!) to gather any type of statistical information on EVERY port on a switched network. Of course, this information is usually available, but most networks have so many switched ports that reporting on every available connection would be difficult to accomplish. For those of us from the 'old school,' we have to become more comfortable with the fact that it's no longer possible to view every bit of data from every device on the network. There's too much data and it's all going too fast!

Most people aren't concerned about every port on the network, and instead they analyze only the most IMPORTANT ports. The business side of the organization knows that there are certain servers, stations, switches, routers, or other devices that are critical to accomplishing the goals of the organization. It's these critical stations and network connections that need to be monitored.

It's not enough to have a technical diagram of the network, the network team should also be aware of the important applications running on the network and the flow of data that occurs within these applications. Without both the map and the route, there's no way to keep track of the race!

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

====
Network Uptime Surf Report
- Why the @#$%! Would You Want To Do That? -
- http://www1.fatbrain.com/interviews/seifert_rich.html -
====

If you're a reader of the comp.dcom.lans.ethernet newsgroup, then you've probably seen Rich Seifert provide knowledgeable retorts to the inquiries from around the globe. Even if you didn't realize that the original 10 megabit design of Ethernet was his, or that he helped created the Digital VAX, or he was a major contributor of the Gigabit Ethernet specification, you can appreciate his technical knowledge from his newsgroup posts.

As an aside, it's also fun to watch those unfamiliar with Rich Seifert's work refute one of his technical responses regarding the Ethernet specification. Someone else usually steps in and reminds the dissenting voice that he helped _create_ Ethernet!

Although Rich Seifert's technical knowledge is difficult to dispute, his personal opinions regarding technology are free game for everyone. This transcript from a Fatbrain-sponsored speaking engagement has some enlightening information and opinions about Ethernet, networking, and the integration of voice, data, and video into the same technology:

http://www1.fatbrain.com/interviews/seifert_rich.html

This transcript is a Network Uptime 'must-read.' For most of us, I've also included another link for some additional assistance:

http://www.m-w.com/cgi-bin/dictionary?va=idempotent

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

====
Network Uptime Tutorial
- Troubleshooting WINS Broadcasts -
====

"I get a lot of WINS NO RESPONSE on my trace files. These are commands that are being broadcasted from a bunch of clients on the network even though they have WINS servers configured in their protocols. Why would PCs broadcast for WINS services if they are configured with 2 possible WINS servers to query?"

The message 'WINS NO RESPONSE" is a common one in switched networks, especially since the WINS request is seen during a network broadcast and the directed response isn't sent through all ports like the broadcast. This causes the network analyzer to report that a WINS response wasn't received; in fact, it may have been received through a separate communications channel. Or, perhaps it never was! On a switched network, there's no way to definitively determine the actual disposition of the WINS request (unless, of course, you happen to be analyzing the connection that contains the station sending the original WINS request).

The issue of stations broadcasting for WINS services when configured WINS servers exist is a common question. To better understand the WINS resolution process, reference RFC 1001 - "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods."

This RFC defines four node types for NetBIOS (WINS) resolutions; broadcast node (b-node), point-to-point node (p-node), mixed nodes (m-node), and hybrid node (h-node). A station can be configured as any of these node types, although b-node and h-node types are the most common. Each node type uses a different process for resolving NetBIOS names.

B-Nodes
-------
A station that does not have a WINS server configured is a broadcast node (b-node) by default. The b-node resolves NetBIOS names in this order:

1) The station looks in the NetBIOS name cache to determine if the host has been resolved previously.

2) If the name is not in the cache, the station sends a broadcast.

3) If the broadcast isn't answered, the station checks the local LMHOSTS file for name resolution.

4) After checking LMHOSTS, the station will check the local HOSTS file.

5) Finally, the host will perform a name lookup on the configured DNS server.

The default b-node configuration will always create broadcasts on the network, and never queries a WINS server. Obviously, this would not be an efficient node configuration on a large network! Since routers restrict broadcasts, this type of configuration would only be useful on local subnets (although I know many large networks that are a single VLAN!).

P-Nodes
-------
Point-to-point nodes (p-nodes) take care of the broadcast problem, because p-nodes don't broadcast to resolve a NetBIOS name. Here's the p-node process:

1) NetBIOS Name Cache

2) WINS Server

3) LMHOSTS File

4) HOSTS File

5) DNS Server

Look, no broadcasts! Unfortunately, there is a lot of reliance on the WINS and DNS servers. If those are inaccessible, then the station can't communicate to a NetBIOS-named device. Also, notice that a local WINS server becoming unavailable may create network traffic to a remote DNS server!

M-Nodes
-------
Mixed node (m-node) stations will use both broadcasts and WINS servers for name resolution, and the broadcasts are the preferable option:

1) NetBIOS Name Cache

2) Broadcast

3) WINS Server

4) LMHOSTS File

5) HOSTS file

6) DNS Server

Some organizations use m-node configurations in their smaller remote offices in situations where there is mostly local traffic and there is no local WINS server. Since local broadcasts are acceptable verses the use of the slower WAN link, an m-node configuration makes sense for these locations.

H-Nodes
-------
A station configured with a WINS server is a hybrid-node (h-node) by default. A h-node will request name resolutions from local WINS servers initially, and then will broadcast as a last-ditch effort:

1) NetBIOS Name Cache

2) WINS Server

3) Broadcast

4) LMHOSTS

5) HOSTS

6) DNS Server

The node type can be automatically determined based on the WINS server configuration. If a station does not have a WINS server defined, then the station is a b-node by default. If a WINS server is defined, then the station uses the default of a h-node. More information on the default node types can be found here:

>Default Node Type for Microsoft Clients
>http://support.microsoft.com/support/kb/articles/Q160/1/77.asp

The node type can also be determined or changed by a registry entry at

HKLM\System\CurrentControlSet\Services\NetBT\Parameters

The Entry is called 'NodeType' and it's type REG_DWORD. The applicable
values are:

0x1 = b-node
0x2 = p-node
0x4 = m-node
0x8 = h-node

In large environments, most node types are configured through DHCP. DHCP Information Options are documented here:

>DHCP Options Supported by Clients
>http://support.microsoft.com/support/kb/articles/Q121/0/05.ASP

Since the h-node configuration is the default for stations with a configured WINS server, why are broadcasts still traversing the network (we're finally answering the original question!)?

* If the station is configured as a h-node, the WINS servers may not be operational or may be inaccessible. Even if the WINS servers are up and running, the network connectivity to those servers may be unavailable.

* The requesting station may have a misconfigured WINS server address. The station cannot resolve names through WINS because the WINS server IP address is incorrect! Since the client station is configured as a h-node by default, it then sends a broadcast to help provide the resolution.

This issue isn't seen in most DHCP environments, since the WINS server is configured automatically (and hopefully the DHCP record has the correct WINS configuration!).

* The DHCP server may be misconfigured to assign stations a node type other than h-node. Check those DHCP configurations, and make sure they correspond to the appropriate node type!

* When a device starts, it registers its name with the primary WINS server. If the device has an incorrect WINS address, this name registration never occurs. Obviously, the requesting h-node station will not find the registered name on the WINS server, and it must send a broadcast to attempt a resolution. This can also occur if the NetBIOS name to resolve has been misspelled!

* The requesting device may have a WINS server configured, but the requestED device may not! Occasionally, devices (especially servers) can be configured with an IP address but no WINS server. With no configured WINS server a station will never register with the WINS database, and workstations requiring name resolution will be forced to send a broadcast to resolve the name (unless the device is permanently registered on the WINS server).

Here's some additional Microsoft articles that discuss WINS, DHCP and name resolution:

>How WINS Lookup Works from Windows NT DNS
>http://support.microsoft.com/support/kb/articles/Q173/1/61.ASP

>DHCP (Dynamic Host Configuration Protocol) Basics
>http://support.microsoft.com/support/kb/articles/Q169/2/89.ASP

>TCP/IP & NBT Configuration Parameters for Windows NT and Windows 2000
>http://support.microsoft.com/support/kb/articles/Q120/6/42.ASP

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

====
Network Uptime Analysis Tip
- Traffic Jams -
====

Have you ever used the traffic generation feature on your analyzer? There are some helpful functions relating to the traffic generator that can assist when observing a network.

* Traffic generation can add a lot of additonal traffic to an existing network segment. Some applications or stations may have problems when large bursts of traffic are present, and the traffic generator can simulate these large traffic patterns and put the test application server through the ringer.

* Networking hardware is usually evaluated on throughput; the faster the packets move, the better the box. The packet generator can send thousands of frames through a device, and another analyzer can capture the data on the other side. If 1,000 frames are sent, then 1,000 frames should be received!

* When troubleshooting a network, the captured data tells the story. Sometimes, the story isn't the same plot line repeated over and over in every chapter. Instead, the evil villain jumps out in the middle of the book and the rest of the novel describes how the rest of the world is dealing with the shambled pieces of their lives. Stay with me, I'm going somewhere with this.

Most traffic generation functions allow you to replay a trace file while re-capturing the file simultaneously. Think of this capability as TiVo for your network analyzer (http://www.TiVo.com). In the replay, you can freeze-frame the evil villain, and watch the details of his tortuous plan for world domination occur in slow motion. You can even pause the traffic generation in mid-packet if the phone rings.

When replaying the trace, it's sometimes helpful to watch the network fall to pieces in 'real time.' The network outage may be sudden and apparent, or the problem may slowly occur over time. This replay option provides some perspective that may not otherwise be visible in a static protocol decode.

There are numerous other uses for a traffic generator, but these should get you started. Remember that traffic generation can add unnecessary and unwanted data to your network! Use extra care when operating a traffic generator, and take precautions against network outages!

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ==== Ending Delimiter ====

If you're reading a forwarded copy of Network Uptime, sign up for your own IEEE subscription:

http://www.NetworkUptime.com/newsletter/

To unsubscribe from Network Uptime, use the above URL, or email majordomo@NetworkUptime.com with the following text in the body of the message:

unsubscribe NetworkUptime

For questions or comments, email us at James@NetworkUptime.com or visit the Network Uptime web page at http://www.NetworkUptime.com!

==== End of Network Uptime ISSN: 1529-6938 Issue 02 00 00 01 00 08 00 01 (c)2001, NetworkUptime.com, Inc. http://www.NetworkUptime.com ====