Document Number: OSUP1022
Product:Observer (all versions)
Date: 3-10-2004
Title: NDIS Drivers and Observer

NDIS Drivers and Observer

Notes On NDIS Drivers and Tracking Ethernet Errors with Observer
The current state of support for NDIS error tracking within the Ethernet environment has caused a number of questions and misunderstandings. This short description of both the standard NDIS drivers included with Windows and/or a manufactures network adapters, and the modified NDIS drivers included with Observer is meant to provide a background for making a driver and card decision.

Standard Network Card Drivers
In an effort to move the burden of driver development from the operating system vendor to the network adapter card (NIC) vendor, Microsoft created the Network Driver Interface Specification (NDIS) in the early 1990s. The idea was to put forth a common application programmers interface (API) that was to be supplied by the NIC vendor for the operating system (first DOS with NDIS 2.0 then Windows with NDIS 3.0+). The NDIS environment defines a specific interface that the operating system can use to communicate with a NIC. In theory, this interface should be independent of the underlying network. In practice it is close to providing a general level of network independence for the operating system. It has also allowed the operating system vendor (Microsoft) to get out of the business of writing NIC drivers.

Today, most NIC vendors provide solid, functional NDIS drivers for all cards available within the Ethernet, Token Ring, and FDDI marketplace.

Mandatory and Optional NDIS Functions
Unfortunately, operations required for accessing a standard network are somewhat different than operations required for using a protocol analyzer. While both activities share a number of driver functions, a protocol analyzer requires a set of features and functions that the average network user will never need. Examples of these functions are promiscuous mode, error tracking, network speed reporting, etc.

Presumably, in an effort to make driver development simpler, Microsoft made a number of the less used (by “normal” network users) functions “optional”, as opposed to “mandatory” with regards to the driver functional requirements. The result has been that most vendors support all (or most) mandatory functions with the first release of the driver. As time passes, and the initial chaos of the first release of the card and driver passes, most manufactures add some or all of the optional functions, as well as fix or complete all of the mandatory functions.

Examples of mandatory functions would include functions to determine the maximum packet size, functions to verify the number of sent packets, and functions to specify or determine a packets’ protocol. Examples of optional functions include functions to determine network error statistics, and promiscuous mode. (Promiscuous mode is a mode where all packets are processed by the NIC – as opposed to only packets addressed to the receiving station (unicasts), broadcasts and multicasts.)

Different NIC vendors have better and worse records for both implementation of mandatory and optional functions, as well as the quality of the implementation.

Ethernet Error Counters
As part of the optional section of defined NDIS functions, Microsoft specified a number of counters that can be kept for Ethernet frame errors. These counters include CRC errors, Alignment errors, Packets Too Big (Jabbers), and Packets Too Small (Runts). Collisions are counted, but please see the section below to understand the limitations of NDIS collision statistics. Four important points should be considered:

1) These optional counts only provide a numerical value to the total number of errors on the segment (i.e. the number of CRC errors found), they do not specify where (which station) the error originated from.

2) Once the error packet is identified and the proper error counter is incremented, the packet is discarded, and not sent to Windows (this is the reason it is impossible to determine the source of an Ethernet error packet with standard NDIS drivers).

3) A number of vendor’s NDIS drivers will return a positive acknowledgment when the NDIS error function is queried for existence, but the error statistic is not actually kept.

4) A few vendors (3COM, for example) do not keep any error statistics whatsoever.

If a NIC driver both reports that the optional Ethernet error statistics are being kept, and actually keeps data on these errors, Observer will report these statistics in the Network Vital Sign Display.

Collisions
How collisions are counted by NDIS is a bit different than other errors, and thus a brief explanation is in order. For some reason, NDIS drivers only count the number of collisions that the actual station where the NDIS driver is running has encountered. For example, if you are running an NDIS driver on station A and there is a collision between stations B and C, A will not increment its collision counter. If a packet from station A collides with station C (or if C collides with A), then station A’s collision counter is incremented.

In an effort to provide a more realistic view of how many collisions are occurring on a LAN segment, Observer has an option (“on” by default when using the Vital Sign mode) to run the “Collision Test”. When turned on, this test sends packets onto the LAN at specific intervals, and records the number of collisions that the Observer station experiences. This test provides a good idea of what any station may see - with regards to collisions - during normal network usage. The collision statistic reported by Observer is an approximation of what any one station may be experiencing, as opposed to an aggregate statistic for the entire LAN segment (as is the case with CRC, Alignment, Jabbers and Runts).

Additionally, Observer includes the “Collision Expert Mode” that both generates packets to approximate each station’s collision potential, and reports which stations are most likely to re-send directly after a collision and which stations were sending just prior to a collision. This information is then reported in an expert dialog and is key in helping to determine the station(s) that are causing the collisions on the segment.

Observer’s Enhanced ErrorTrak™ NDIS Drivers for Errors-by-Station
While the aggregate errors that are kept by NDIS provide a general view on the health of a LAN segment, when a high level of segment errors are encountered, the immediate question becomes “Where are these errors coming from?”. This station specific error information has historically been only available from hardware based protocol analyzers. The reason was that hardware-based analyzers have not been limited by the aggregate statistics provided in NDIS. Fortunately this is no longer a limitation of Observer.

Network Instruments has worked with a number of NIC vendors and chip manufacturers to extend the standard NDIS drivers to both collect statistics on the aggregate errors on a LAN segment, but also to move the actual error packet information up the NDIS stack for further examination by Observer’s error displays. This allows Observer to report both general error statistics and error source addresses to help pinpoint troubleshooting down to the specific station with a problem.

Using the extended NDIS drivers included with Observer, administrators and technicians can see complete network errors broken down by type and (source) station. This can be done from within the standard Windows environment, without the need to re-boot, without proprietary drivers, and without sacrificing any standard network functionality. This dual functionality is achieved because the Network Instruments ErrorTrak™ NDIS driver is a highly optimized NDIS driver with the addition of a module to collect and process error packets – these drivers have all the functionality of a standard NDIS driver, plus the ability to pass error packets to Observer. The combination of the Network Instruments’ network adapter and the ErrorTrak™ drivers provide full error processing/identification and wire speed 100MB or 1000MB capture.