Each generic data link control (GDLC) provides problem determination data that can be used to isolate network problems. Four types of diagnostic information are provided:
Status information can be obtained for a service access point (SAP) or a link station (LS) using the DLC_QUERY_SAP and DLC_QUERY_LS ioctl subroutines to call the specific DLC kernel device manager in use.
The DLC_QUERY_SAP ioctl subroutine obtains individual device driver statistics from various devices:
The DLC_QUERY_LS ioctl subroutine obtains LS statistics from various DLCs. These statistics include data link protocol counters. Each counter is reset by the DLC during the DLC_START_LS ioctl subroutine, and generally runs continuously until the LS is terminated and its storage is freed. If a counter reaches the maximum count, the count is frozen and no wraparound occurs.
The suggested counters provided by a DLC device manager are listed as follows. Some DLCs can modify this set of counters based on the specific protocols supported. For example, the number of rejects or receive-not-ready packets received might be meaningful.
|Test Commands Sent||Contains a binary count of the test commands sent to the remote station by GDLC, in response to test commands issued by the user.|
|Test Command Failures||Contains a binary count of the test commands that did not complete properly due to problems such as the following:|
|Test Commands Received||Contains a binary count of valid test commands received, regardless of whether the response is completed properly.|
|Sequenced Data Packets Transmitted||Contains a binary count of the total number of normal sequenced data packets transmitted to the remote LS.|
|Sequenced Data Packets Transmitted||Contains a binary count of the total number of normal sequenced data packets retransmitted to the remote LS.|
|Maximum Contiguous Retransmissions||Contains a binary count of the maximum number of times a single data packet has been retransmitted to the remote LS before acknowledgment. This counter is reset each time a valid acknowledgment is received.|
|Sequenced Data Packets Received||Contains a binary count of the total number of normal sequenced data packets correctly received.|
|Invalid Packets Received||Contains a binary count of the number of invalid commands or responses received, including invalid control bytes, invalid I-fields, and overflowed I-fields.|
|Adapter Detected Receive Errors||Contains a binary count of the number of receive errors reported back from the device driver.|
|Adapter Detected Transmit Errors||Contains a binary count the number of transmit errors reported back from the device driver.|
|Receive Inactivity Time-outs||Contains a binary count of the number of receive time-outs that have occurred.|
|Command Polls Sent||Contains a binary count of the number of command packets sent that requested a response from the remote LS.|
|Command Repolls Sent||Contains a binary count of the total number of command packets retransmitted to the remote LS due to a lack of response.|
|Command Contiguous Repolls||Contains a binary count of the number of times a single command packet was retransmitted to the remote LS due to a lack of response. This counter is reset each time a valid response is received.|
Each DLC provides entries to the system error log whenever errors are encountered.
The user can obtain formatted errorlog data by issuing the errpt command. When used with the -N DLCName flag, the errpt command produces a summary report of all the error log entries for the resource name indicated by the DLCName parameter. Valid values for the DLCName parameter include:
|SYSXDLCE||Standard Ethernet datalink|
|SYSXDLCI||IEEE 802.3 Ethernet datalink|
The format of each required alert vector can be found in SNA Format and Protocol Reference Manual: Management Services.
For more information on the error log facility, refer to "Error Logging Overview" in AIX Problem Solving Guide and Reference.
GDLC provides optional entries to a generic system trace channel as required by the system product Reliability/Availability/Serviceability. The default is trace disabled. This provides maximum performance and reduces the number of system resources used. For information on additional ways to use trace facilities, see "Managing DLC Device Drivers" .
The operating system supports up to seven generic trace channels in operation at the same time. A user must allocate a channel before starting an LS trace, with the DLC_START_LS ioctl operation or the DLC_TRACE ioctl operation. This is accomplished with the trcstart and trcon subroutines.
Trace activity in the LS must be stopped either by halting the LS or by issuing an ioctl (DLC_TRACE, flags=0) operation to that station. Once the LS has stopped tracing, the channel is disabled with the trcoff subroutine and returned to the system with the trcstop subroutine.
The user can obtain formatted tracelog data by issuing the trcrpt command with the appropriate file name, such as:
This example produces a detailed report of all link trace entries in the /tmp/link1.log file, if a prior trcstart subroutine specified the /tmp/link1.log file as the (-o) name for the trace log.
For each trace entry, GDLC generates the trcgenkt kernel service to the kernel generic trace.
Each of the local area network data link controls (DLCETHER, DLC8023, DLCFDDI, and DLCTOKEN) provides an internal monitor trace capability that can be used to identify the execution sequence of pertinent entry points within the code. This is useful if the network is having problems that indicate the data link is not operating properly, and the sequence of events may indicate the cause of the problems. This trace is shared among the LAN data link controls, and inactive is the default.
The LAN monitor trace can be enabled by issuing the following command:
trace -j 246
where 246 is the hook ID to be traced.
Tracing can be stopped with the trcstop command and a report can be obtained with the following command:
trcrpt -d 246
where 246 is the hook ID of the trace for which you want a report.
Note: Exercise caution when enabling the monitor trace, since it directly affects the performance of the DLCs and their associates.
For information on additional ways to use trace facilities, see "Managing DLC Device Drivers" .