Sniffer Portable

Transcription

Sniffer Portable

EXPERT ALARMS REFERENCE GUIDE
Sniffer ® Portable
VERSION 4.8
COPYRIGHT
© 2005 Network General Corporation. All Rights Reserved. No part of this publication may be
reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any
language in any form or by any means without the written permission of Network General
Corporation or its suppliers or affiliate companies.
TRADEMARK ATTRIBUTIONS
Appera, InfiniStream, Know The Network, Netasyst, Network General, Network Performance
Orchestrator, nPO, PrimeSupport, and Sniffer are registered trademarks or trademarks of
Network General Corporation and/or its affiliates in the US and/or other countries. All other
registered and unregistered trademarks in this document are the sole property of their
respective owners. © 2005 Network General Corporation. All Rights Reserved.
LICENSE AGREEMENT
NOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT
CORRESPONDING TO THE LICENSE YOU PURCHASED, WHICH SETS FORTH THE GENERAL
TERMS AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW
WHICH TYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE CONSULT THE SALES AND OTHER
RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT ACCOMPANIES YOUR
SOFTWARE PACKAGING OR THAT YOU HAVE RECEIVED SEPARATELY AS PART OF THE
PURCHASE (AS A BOOKLET, A FILE ON THE PRODUCT CD, OR A FILE AVAILABLE ON THE WEB
SITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOU DO NOT AGREE TO
ALL OF THE TERMS SET FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF
APPLICABLE, YOU MAY RETURN THE PRODUCT TO NETWORK GENERAL OR THE PLACE OF
PURCHASE FOR A FULL REFUND.
March, 2005 / 100421
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Getting More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Contacting Network General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
1 Expert Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Information Reported with Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
About Expert Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Setting Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Expert Alarms and Thresholds Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Service Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Slow FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Slow HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Slow Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Slow News Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Slow Oracle SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Slow POP3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Slow Sybase/Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Slow Telnet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Application Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[VOIP] H323 - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[VOIP] H323 - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[VOIP] SCCP - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[VOIP] SCCP - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
[VOIP] SIP - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
[VOIP] SIP - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Access to Resource Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Browser Election Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
DB Connect Request Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DB Security Breach Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DB Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Expert Alarms Reference Guide
iii
Contents
DB Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
DB Slow Server Response Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Excessive Failed Resource Login Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Excessive Mailslot Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
FCIP Special Frame Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
FCIP Invalid Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
FCIP Repeat Special Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
FCIP Special Frame Echo Has Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
FCIP Special Frame Delayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
FCIP Too Many Special Frame Echoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
FCIP Transmission Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
FTP Login Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FTP Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FTP Slow First Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FTP Slow Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FTP Slow Transfer Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
HTTP Slow Server GET Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
HTTP Slow Server POST Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Invalid Network Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Invalid Resource User Name or Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iSCSI: Authorization Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iSCSI: Can Not Generate Target Transfer Tag - Out of Resources . . . . . . . . . . 25
iSCSI: Command Not Supported in this Session Type . . . . . . . . . . . . . . . . . . . . 26
iSCSI: Command Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iSCSI: Data Digest Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iSCSI: Data or Status again Requested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iSCSI: Function Authorization Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iSCSI: Function Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iSCSI: Immediate Command Reject (Too Many Immediate Commands) . . . . . . 27
iSCSI: Initiator Authentication Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iSCSI: Invalid Data Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iSCSI: Invalid PDU field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iSCSI: Invalid During Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iSCSI: LUN Does Not Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iSCSI: Miscellaneous Initiator Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iSCSI: Missing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iSCSI: Service Unavailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iSCSI: Session Does Not Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iv
Sniffer Technologies
Contents
iSCSI: Target Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iSCSI: Target Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iSCSI: Target Out of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iSCSI: Target Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iSCSI: Task Does Not Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iSCSI: Task Management Function Not Supported . . . . . . . . . . . . . . . . . . . . . . 30
iSCSI: Too Many Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
iSCSI: Unsupported Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Missed Browser Announcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
MS RAP Logon Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
NCP Server Busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
NFS Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
NNTP Slow Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
POP3 Slow Connect Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Protocol Negotiation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SAP R3 Slow Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SAP R3 Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SMTP Slow Connect Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Station Not in Domain’s Computer List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Telnet Slow Response to Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Session Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[VOIP] H225 - Abnormal Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[VOIP] H245 - Open Logical Channel Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
[VOIP] H245 - Terminal Capability Set Reject . . . . . . . . . . . . . . . . . . . . . . . . . . 36
[VOIP] RAS - Admission Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
[VOIP] RAS - Bandwidth Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[VOIP] RAS - Disengage Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[VOIP] RAS - Gatekeeper Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[VOIP] RAS - Location Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
[VOIP] RAS - Registration Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
[VOIP] RAS - Unregistration Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
[VOIP] RTCP - Report High Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
[VOIP] RTP - High Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Decreasing the Frequency of High Jitter Alarms . . . . . . . . . . . . . . . . . . . . . . . . 44
Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
[VOIP] RTP - High Variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[VOIP] RTP - Too Many Dropped Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
[VOIP] RTP - Too Many Out of Sequence Packets . . . . . . . . . . . . . . . . . . . . . . 47
v
Contents
[VOIP] SCCP - Register Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
[VOIP] SCCP - Station Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
[VOIP] SIP - Client Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
[VOIP] SIP - Global Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
[VOIP] SIP - Server Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
[VOIP] SIP - Server Slow Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
File Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Invalid Presentation Context ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
IP NETBIOS Session Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Local Limit on Defined Context Set Exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Loops on Same Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Low Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Read/Write Overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Request Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Slow File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Temporary Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
The Operation Number Is Greater than the Number of Operations in the Interface .
57
The Output Parameters of the Operation Exceed Their Declared Maximum Size 57
The Request Is Being Rejected for Unspecified Reasons . . . . . . . . . . . . . . . . . 57
The RPC Client or Server Protocol Has Been Violated . . . . . . . . . . . . . . . . . . . 57
The Server Did Not Support the Requested Authentication Level . . . . . . . . . . . 57
The Server Does Not Export the Requested Interface . . . . . . . . . . . . . . . . . . . . 57
The Server Does Not Implement the Requested Operation for the Type of Requested
Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
The Server Does Not Support the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
The Server Does Not Support the Proposed Transfer Syntax . . . . . . . . . . . . . . 58
The Server Does Not Support RPC Protocol Version . . . . . . . . . . . . . . . . . . . . . 58
The Server Is Too Busy To Handle the Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
The Server Manager Routine Has Not Been Entered and Executed . . . . . . . . . 58
TNS Connect Refused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
TNS Security Breach Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
TNS Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
TNS Slow Server Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
TNS Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Too Many File Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Too Many Loops on Same Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Too Many Requests Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
WINS Duplicate Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
vi
Contents
WINS No Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Ack Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Fast Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Idle Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Local Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Non-Responsive Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Repeat Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Slow Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
TCP Fast Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Too Many Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
UDP Bouncing Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Window Frozen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Window Size Exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Zero Window Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Station Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Duplicate Network Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Duplicate PDC Name Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ICMP Destination Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ICMP Host Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ICMP Inconsistent Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ICMP Net Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ICMP Parameter Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ICMP Port Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ICMP Redirect for Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ICMP Redirect for Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ICMP Source Quench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
IP Fragment Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
IP Fragment Out of Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Misdirected Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Multiple Routers to Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Multiple Routers to Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Route Flapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Router Not Updating Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Router Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Router Superseded Too Frequently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Server Running BDC Shutting Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
vii
Contents
Server Running PDC Shutting Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Server Running WINS Shutting Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Source Address Is Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Time-to-live Exceeded in Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Time-to-live Expiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Zero Broadcast Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
DLC Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Abort Delimiter Transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
AC Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Burst Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Collision after 64 Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
DLC Source Address Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
DLC Source Address Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Duplicate Address Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
FCI and ARI Bits Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
FDDI Ring Wrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Frame Has Alignment Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Frame-Copied Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Frequency Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
High Rate of Line/Burst Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
High Rate of Physical Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
High Rate of Receiver Congestion Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
High Rate of Ring Purge Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Invalid Frame Status Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Line Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Local Station with Route Designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Lost Frame Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Multiple Local Ring Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
New Active Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Oversized Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Receiver Congestion Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Returned to Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Ring Beaconing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Ring Purge Symptom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Runt Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Same Source and Destination Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Station Internal Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Station Off Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
viii
Contents
Station Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Token Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Too Many Removes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Too Many Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Zero MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
WAN Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Backward Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Exceeded CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Forward Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
PVC Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
PVC Bandwidth Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
PVC Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
PVC Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
PVC Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Traffic on Deleted DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Traffic on Inactive DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Traffic on Unknown DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
WAN Link Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Async Status Change of Unknown DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
DCE Sequence Number Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Delayed STATUS ENQUIRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
DTE Sequence Number Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Irregular Full Status Report Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Link Management Message Format Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Link Management Message Minor Format Error . . . . . . . . . . . . . . . . . . . . . . . . 97
Network Equipment Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
New PVC Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
No STATUS ENQUIRY When Expected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
No STATUS Following STATUS ENQUIRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
PVC Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
PVC Bandwidth Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
PVC Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
PVC Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
PVC Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Unexpected Link Management Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Unsolicited STATUS Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
User Equipment Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Wrong Report Type in STATUS Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ix
Contents
ATM Application Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Attempt to Bind L3 Address to Multiple MPOA Devices . . . . . . . . . . . . . . . . . . 100
Data Frames Detected Following Data Plane Purge . . . . . . . . . . . . . . . . . . . . 100
DDVCC Idle Period Exceeds VCC Timeout C12 . . . . . . . . . . . . . . . . . . . . . . . 101
DDVCC Not Created in Response to LE ARP . . . . . . . . . . . . . . . . . . . . . . . . . 101
Default MCFVCC Not Created in Response to LE ARP . . . . . . . . . . . . . . . . . . 101
Default MCSVCC Not Created in Response to LE ARP . . . . . . . . . . . . . . . . . . 102
Excessive Unknown Frames Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Frames Seen on Default Flow After Shortcut Active . . . . . . . . . . . . . . . . . . . . . 102
LANE Config Phase Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
LANE Cfg Restart Delay < Min Recfg Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
LANE Cfg Restart Delay > Max Recfg Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 104
No Resolution Request Issued After Excess Default Flow . . . . . . . . . . . . . . . . 104
Shortcut Create Failed After Resolution Reply . . . . . . . . . . . . . . . . . . . . . . . . . 104
ATM Flow Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
ARE or STE Frames on Data Direct VCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
ARP Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Attempt to Bind DLC to MPC and Non-MPOA Device . . . . . . . . . . . . . . . . . . . 105
Attempt to Multiply Bind MPOA Devices to LEC . . . . . . . . . . . . . . . . . . . . . . . . 106
Broadcast/Multicast Data Frames on DDVCC . . . . . . . . . . . . . . . . . . . . . . . . . 106
Cache ID Set to Zero in DLL Header Ext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Config Fail, Insufficient Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Config Frag Info TLV Not Recognized by LECS . . . . . . . . . . . . . . . . . . . . . . . . 107
Config Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Config Request Response Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Config Request Retry Frame Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Config Request Retry Rate Exceeds 1 Frame/sec . . . . . . . . . . . . . . . . . . . . . . 108
Control Request on DDVCC Retry Frame Mismatch . . . . . . . . . . . . . . . . . . . . 108
Control Request on DDVCC Retry Rate > 1 Frame/Sec . . . . . . . . . . . . . . . . . 109
Database Summary Exchange Lockstep Failure . . . . . . . . . . . . . . . . . . . . . . . 109
Database Summary Master/Slave Negotiation Timeout . . . . . . . . . . . . . . . . . . 109
Denied Access to ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
DLL Header Extension Not Found in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Duplicate ATM Destination Address Registration . . . . . . . . . . . . . . . . . . . . . . . 110
Duplicate LAN Destination Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Egress Cache Tag Was Not Issued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Failed to Issue Resolution Req. Following Trigger . . . . . . . . . . . . . . . . . . . . . . 111
Failure Reported in Reply CIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
x
Contents
Flush Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
IG Tag Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Insufficient Info from LEC, Service Refused . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Invalid ATM Primary Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Invalid CIE Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Invalid Client ATM Primary Source Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Invalid Client MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Invalid Common Header Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Invalid Fixed Header Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Invalid Frame Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Invalid Hello Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Invalid MPOA MPS MAC Address Count in Device Type TLV . . . . . . . . . . . . . 115
Invalid MPOA Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Invalid Tag in Data Frame Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Join Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Join Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Join Request Transmitted by LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Join Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Keep Alive Lifetime Set to Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Keep Alive Sequence Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Keep Alive Lifetime Ext Not Found in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 117
LANE Control Request Response Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
LANE Control Request Retry Frame Mismatch . . . . . . . . . . . . . . . . . . . . . . . . 118
LANE Control Request Retry Rate > 1 Frame/sec . . . . . . . . . . . . . . . . . . . . . . 118
LANE Version Unsupported by ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
LE ARP Request Rate Exceeds 1 Frame/Sec . . . . . . . . . . . . . . . . . . . . . . . . . 119
LE_CONFIGURE Params Conflict, Service Refused . . . . . . . . . . . . . . . . . . . . 119
LEC Issued Config Response to LECS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
LEC Not Recognized by LECS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
LEC ID in Frame Mismatch with Client LEC ID . . . . . . . . . . . . . . . . . . . . . . . . . 120
LECID Is Not 0x0000 in Request Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
LECS Issued Config Request to LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Local Segment ID not in Source Routed Frame . . . . . . . . . . . . . . . . . . . . . . . . 121
MAC Address bound to Multiple LECs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Max Transmission Unit Size Undefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Missing ULIA on Outside Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
MPOA Capable LEC Did Not Issue Device TLV . . . . . . . . . . . . . . . . . . . . . . . . 122
MPOA Config Parameter Invalid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
xi
Contents
MPOA Control Request Response Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
MPOA Control Request Retry Rate > 1 Frame/sec . . . . . . . . . . . . . . . . . . . . . 123
MPOA Error Frame Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Multiply Assigned Secondary LEC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
NARP Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
NARP Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
No CIEs Were Present in MPOA Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
No CIEs Were Present in MPOA Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
No Reply Flag Is Not Set in ICache Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
PTSE Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Register Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Register Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Register Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Remote Address Issued by Non Proxy LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Request Params Are Incompatible with ELAN . . . . . . . . . . . . . . . . . . . . . . . . . 127
TA List Resources Exhausted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Topology Change Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Topology Mismatch in Data Frame Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Unexpected DLL Header EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Unexpected Egress Cache EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Unexpected Hop Count EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Unexpected IG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Unexpected Keepalive Lifetime EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . . 129
Unexpected Original Error Code EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . 129
Unexpected Service Category EXT in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Unexpected TLVs Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Unknown Extension in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Unknown IG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Unknown LANE Config/Control Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Unknown Marker/Protocol Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Unknown/Unexpected Authenticate EXT in Frame . . . . . . . . . . . . . . . . . . . . . . 131
Unknown/Unexpected CIE in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Unregister Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Unregister Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Unregister Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
V2 TLVs Issued in V1 ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Verify Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Verify Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
xii
Contents
Verify Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
ATM Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
AAL5 CRC Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
AAL5 Length Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
AAL5 Timeout Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Abnormal Disconnect for SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
CLP = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Connection Too Short . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Crankback Has Occurred (ATM Connection Layer) . . . . . . . . . . . . . . . . . . . . . 136
EFCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Excessive Signaling Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Missing DTL or Excessive DTL Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
MPCMPS Flow Not Allowed on this VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Possible 3.0/3.1 UNI Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Signaling Frame Sequence Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Unexpected Data for SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
ATM Host Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Excessive Abnormal Disconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Excessive Abnormal Frame Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Excessive Short Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
High Signaling Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Host Address Cannot Be Mux’ed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Too Many Simultaneous Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Unexpected Data for SVC (ATM Host Layer) . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Wireless Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ACK Frame Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Association Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Authentication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
CTS Frame Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Deauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Disassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Mcast/Bcast Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Missing Fragment Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Oversized WLAN Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Reassociation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Rogue Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Rogue Mobile Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Runt WLAN Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
xiii
Contents
Same Transmitter and Receiver Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Transmitter Address Is Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Transmitter Address Is Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
WEP-ICV Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Global Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Bad CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Broadcast/Multicast Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Broadcast/Multicast Storm Diag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Channel Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Collisions Over Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
LAN Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
LAN Overload Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
PLCP Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Spanning Tree Topology Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
VLAN Not Operational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
VLAN Removed from Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
VTP Versions Different . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Route Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Nonsense Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Route Metric Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Route Superseded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Route Validity Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
xiv
Preface
This guide describes the alarms generated by the Expert analyzer, as well as
the thresholds used to generate them. The Expert analyzer is included as part
of Sniffer® Portable. For information about your Sniffer application and how to
use its Expert features, refer to the product User’s Guide and the online help
files.
Audience
This guide is designed and produced for Network Administrators, Network
Engineers, and Information Technology Managers who are responsible for
monitoring, capturing, and analyzing data from their corporate networks.
Getting More Information
Source
Contents
Sniffer Portable Installation
Guide
Provides the system requirements and installation
instructions for Sniffer Portable and Sniffer Portable
enhanced drivers.
Sniffer Portable User’s
Guide
Provides a comprehensive overview of all Sniffer
Portable features.
Sniffer Portable Expert
Alarms Reference Guide
Describes each of the alarms generated by Sniffer
Portable’s Expert analyzer, along with their related
thresholds.
Switch Expert Guide
Describes how to connect and configure Sniffer
Portable to use Switch Expert features.
Sniffer Mobile Operations
Guide
Provides information specific to configuring, and
operating Sniffer Mobile. Sniffer Mobile provides
decodes and Expert Analysis for Mobile IP
protocols.
Sniffer Reporter
Describes how to install and configure Sniffer
Reporter to generate a wide variety of reports based
on data collected by Sniffer network analysis and
monitoring products.
xv
Preface
xvi
Source
Contents
Sniffer Tool Collection’s
Sniffer Focused Analysis
Guide
Describes how to use Sniffer Focused Analysis to
leverage existing Sniffer trace files for additional
analysis and troubleshooting.
Sniffer Tool Collection’s
Sniffer Capture Format
Converter
Describes how to use Sniffer Capture Format
Converter to convert existing third-party trace files
to .cap format.
Sniffer Wireless Guide
Describes how to install, configure, and operate
Sniffer Portable with a supported wireless network
adapter.
Sniffer Voice Operations
Guide
Provides information specific to configuring and
operating Sniffer Voice. Sniffer Voice provides
decodes and Expert analysis for Voice over IP
(VoIP) protocols.
ATM Adapter Reference
Guide
Describes how to install, connect, and configure
Sniffer Portable when using ATM hardware.
Describes ATM interface pods.
ATMbook Reference Guide
Describes how to install, connect, and configure the
ATMbook to capture and generate packets using
Sniffer Portable.
Full Duplex 10/100 Ethernet
Reference Guide
Sniffer Portable when using the Full Duplex
Ethernet PCI adapter.
Upgrading the Full Duplex
10/100 Ethernet PCI Adapter
Guide
Describes how to use the FlashUpd utility provided
with Sniffer Portable to upgrade the FPGA firmware
used on the FDX 10/100 Ethernet PCI adapter.
Gigabit Ethernet Reference
Guide
Sniffer Portable when using the Gigabit Ethernet
PCI adapter.
WAN Adapter Cards
Reference Guide
Sniffer Portable when using the LM2000 or HSSI
adapter.
Snifferbook Ultra Reference
Guide
Describes how to install and configure the
Snifferbook Ultra unit and optional Phys.
Snifferbook Reference
Guide
Sniffer Portable when using the Snifferbook.
Preface
Source
Contents
Help
Product information that is accessed from within the
application.
Release Notes
•
The Help system provides high-level and
detailed information. Access from either the
Help menu option or the Help button in the
application.
•
Context-sensitive (also called What’s This?)
Help provides brief descriptions of the
selections in the application. Access by
right-clicking an option, pressing the [F1] control
key, or dragging the question icon to an option.
README file. Product information, system
requirements, resolved issues, any known issues,
and last-minute additions or changes to the product
or its documentation.
xvii
Preface
Contacting Network General
Customer Service
Get help with license entitlement, registrations, grant
number inquiries, tech support validation and more by
contacting the Network General Customer Service
department at:
North America phone: 1-800-764-3337
(1-800-SNIFFER)
Email:
[email protected]
Web:
http://www.networkgeneral.com/ContactUs.aspx
The department's hours of operation are 7:00 AM to
7:00 PM Central time, Monday through Friday.
International phone numbers:
http://www.networkgeneral.com/ContactUs.aspx
Latin America: +55 (11) 5180-6643
Europe: +44 (0) 1753 217500
Australia/New Zealand: +61 (2) 9761 4200
Asia: +65 6222 7555
Japan: +81 3-5219-1221
Mail:
Network General Corporation (North America)
Customer Service Department
Mail Stop 2S362
5000 Headquarters Drive
Plano, TX 75024
USA
xviii
Preface
Customer Service
International
Address
Network General International BV (EMEA)
Customer Service Department
PO Box 58326
1040 HH Amsterdam
The Netherlands
Technical Support
Visit Network General Technical Support at:
•
Sniffer University
http://www.networkgeneral.com/TechnicalSupport.aspx
Sniffer University is a comprehensive educational resource for
building and enhancing all network professionals' skills in fault
and performance management. Sniffer University has trained
over 70,000 network professionals worldwide. The Sniffer
Certified Professional Program provides network
professionals industry-recognized accreditation as experts in
their field.
For more information:
Consulting
Services
•
Toll-free: 866-764-3337
•
Email: [email protected]
•
Web:
http://www.networkgeneral.com/SnifferUniversity.aspx
Our consultants provide an expert supplemental resource and
independent perspective to resolve your problems. They are
ready to assist you during all stages of network growth, from
planning and design, through implementation, and with
ongoing management. They will help integrate our products
into your environment and troubleshoot or baseline network
performance. Our consultants also develop and deliver
custom solutions to help accomplish your project goals.
Currently, custom and product consulting are available.
For more information:
•
http://www.networkgeneral.com/Consulting.aspx
xix
Preface
xx
Exper t Alarms and
Thresholds
1
This section describes the alarms generated by the Expert analyzer along with
their corresponding thresholds. You can use this section to improve your
understanding of Expert alarms, as well as how to configure the thresholds that
determine when they are generated.
Alarms in this section are organized by the network layer at which they occur.
Within each network layer, alarms are organized alphabetically. Each alarm is
described along with its corresponding thresholds (if any).
About Expert Alarms
During Expert analysis, the Expert constructs a database of network objects
from the traffic it sees. The Expert protocol interpreters learn all about the
network stations, routing nodes, subnetworks, and connections related to the
frames in the capture buffer. Using this information, the Expert detects and
alerts you to potential problems that may exist on the network by generating
Expert alarms and reporting them in the Expert display as either symptoms or
diagnoses (depending on their severity).

A symptom indicates that a threshold has been exceeded and may
indicate a problem on your network.

A diagnosis can be several symptoms analyzed together, high rates of
recurrence of specific symptoms, or single instances of particular
network events that cause the Expert to conclude that the network has
a real problem. A diagnosis should be investigated immediately.
Expert alarms are reported in the Expert display. An example is shown in
Figure 1-1.
1
Chapter 1
Selecting an alarm in the Summary Pane
lets you see detailed alarm information in
the Detail Pane (including a “?' link to the
Expert Explain file for the alarm).
Expert alarm counts are
provided at each layer in
the Overview Pane of the
Expert display.
Figure 1-1. Expert Alarms in the Expert Display
Information Reported with Expert Alarms
Applications supporting Sniffer Reporter can be configured to report Expert
alarms:

In the Alarm Log

To a third party SNMP Console (as SNMP traps)
Sniffer Portable enhances and extends the information included with each
reported Expert alarm. Expert alarms are reported with the following
information:
2

Name of the alarm

Client IP address and port number

Server IP address and port number

IP address of the Sniffer Portable installation reporting the alarm

Name of the adapter on the Sniffer Portable installation reporting the
alarm

Time and date when the alarm was detected
Expert Alarms and Thresholds
Figure 1-2 shows an example of an enhanced Expert alarm entry in the Alarm
Manager.
Expert alarms are
reported by name
with addresses,
ports, timestamps,
and identifying
information for the
reporting
Appliance.
Figure 1-2. Enhanced Information in Reported Expert Alarms (Alarm Manager
Shown)
About Expert Thresholds
Expert thresholds determine whether the Expert generates a symptom or a
diagnosis (also called an alarm) based on a given network event.
The default thresholds supplied with the Expert have been carefully calculated
to ensure accurate and informative symptom and diagnosis detection.
Although this manual will provide you with valuable information on
understanding Expert thresholds, you should be sure to understand your
network before changing any of the thresholds.
Setting Thresholds
To set Expert thresholds:
1
Select Expert Options from the Tools menu.
2
Click the Alarms tab.
The Alarms tab lists all Expert alarms by layer, along with their
corresponding thresholds. The Alarms tab and further instructions are
shown in Figure 1-3.
3
Chapter 1
Click to expand/collapse
all Expert layers.
Click to set the severity of this
alarm. Different severities can be
associated with different actions.
Click the + to open
an Expert layer and
display all
symptoms and
diagnoses (alarms).
Click to specify whether the alarm
should appear in the alarm log.
Click in the
Threshold
Value cell and
type the new
threshold
value.
Click the + to
display the
settings for
this alarm.
The
thresholds
display at the
end of the
settings list.
Click to reset the selected value to
the factory default.
Figure 1-3. Setting Expert Thresholds
4
Click to reset all settings for all
layers to the factory defaults.
Expert Alarms and Thresholds Descriptions
This section describes each Expert alarm generated by the Expert analyzer,
along with its corresponding threshold (if any). Alarms are organized by Expert
layer, from the highest layer (Service) to the lowest (Route). Within each layer,
alarms are organized alphabetically. This follows the same organization
shown in the Alarms tab of the Expert UI Object Properties dialog box shown
in Figure 1-5. Table 1-1 summarizes this organization
Table 1-1. Location of Alarm Descriptions at each Layer
Alarms At This Layer...
...Are Described Starting Here
Service Layer
page 6
Application Layer
page 12
Session Layer
page 34
Connection Layer
page 65
Station Layer
page 72
DLC Layer
page 82
WAN Cnx Layer
page 92
WAN Link Layer
page 95
ATM Application Layer
page 100
ATM Flow Layer
page 105
ATM Connection Layer
page 134
ATM Host Layer
page 140
Wireless Layer
page 143
Global Layer
page 152
Route Layer
page 158
5
Chapter 1
Service Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Service layer.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).
Slow FTP Server
The Expert generates this alarm when the average transaction time observed
for an FTP server exceeds the Slow FTP Server Time threshold in the Alarms
tab of the Expert UI Object Properties dialog box.
At the Service layer, the Expert observes transactions for individual servers (in
this case, an FTP server). For each transaction the server takes part in (for
example, logins, file requests, and so on), the Expert measures the time it
takes to complete the transaction. Transactions are measured from the first
frame of a request to the last frame of the corresponding response. When the
average time of all such transactions observed for a single FTP server
exceeds the Slow FTP Server Time threshold, the Expert generates this
alarm.
Possible causes:

There is a problem with the FTP server.

There is excessive network congestion.
Slow HTTP Server
for an HTTP server exceeds the Slow Internet Server Time threshold in the
Alarms tab of the Expert UI Object Properties dialog box.
this case, an HTTP server). For each transaction the server takes part in (for
example, GETs, POSTs, and so on), the Expert measures the time it takes to
complete the transaction. Transactions are measured from the first frame of a
request to the last frame of the corresponding response. When the average
time of all such transactions observed for a single HTTP server exceeds the
Slow Internet Server Time threshold, the Expert generates this alarm.
Possible causes:
6

The network is experiencing congestion.

The web server is overloaded.
Slow Mail Server
for a SMTP server exceeds the Slow Mail Server Time threshold in the
this case, an SMTP server). For each transaction the server takes part in (for
example, logins, get mail commands, and so on), the Expert measures the
time it takes to complete the transaction. Transactions are measured from the
first frame of a request to the last frame of the corresponding response. When
the average time of all such transactions observed for a single SMTP server
exceeds the Slow Mail Server Time threshold, the Expert generates this
alarm.
Possible causes:

There is a problem with the SMTP server.

Slow News Server
for an NNTP server exceeds the Slow News Server Time threshold in the
this case, an NNTP server). For each transaction the server takes part in (for
example, logins, ARTICLE commands, and so on), the Expert measures the
the average time of all such transactions observed for a single NNTP server
exceeds the Slow News Server Time threshold, the Expert generates this
alarm.
Possible causes:

There is a problem with the NNTP server.

Slow Oracle SQL Server
for an Oracle SQL server exceeds either the Slow Oracle Server Time
w/Cursors threshold (for transactions using cursors) or the Slow Oracle
Server Time threshold (for transactions that do not use cursors) in the Alarms
7
Chapter 1
this case, an Oracle SQL server). For each transaction the server takes part
in, the Expert measures the time it takes to complete the transaction.
Transactions using cursors are measured from the start of an Open Cursor
statement to the cursor's close. Transactions that do not use cursors are
measured from the first frame of a request to the last frame of the
corresponding response. When the average time of either type of transaction
observed for a single Oracle SQL server exceeds the corresponding threshold
(Slow Oracle Server Time w/Cursors for transactions using cursors; Slow
Oracle Server Time for transactions that do not use cursors), the Expert
generates this alarm.
Possible causes:

8
The problem is network related.

Determine if your network is overloaded. Increase your network's
bandwidth.

Determine if your network is optimally configured. Minimize frame
fragmentation by using larger frame sizes or more efficient
protocols.

Reduce polling frequency of polled devices in your network.
The problem is in the Multiprotocol Interchange.

Configure your MPI for better data throughputs rather than for
connections.

Decrease the number of pumps per MPI.

Add more MPIs.
The problem is in the server.

Assess the current utilization of your server. Determine if you have
enough CPU power to support the number of users in this server.

Optimize the file distribution of your database. Place the tables
and their associated indexes in separate disk drives. Tables that
are most frequently referenced should be placed in separate disk
drives.

Determine if your server has enough memory to support the
applications and services that have to run concurrently.

Install faster disk drives.
Check for runaway (orphan) processes and clean up after them. The
problem is in the database. Perform database tuning suggested by
Oracle and other experts in this area. For example:

Make sure that the shared pool is large enough to reduce
reparsing.

Optimize the size of the DB_BLOCK_BUFFERS.

Increase the value of DML_LOCKS to allow more locks placed on
an object at one time.

Determine your library cache misses and set the
CURSOR_SPACE_FOR_TIME according to the recommendation
in the Oracle7 Server Administrator's Guide.

Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
columns.
The problem is in the client workstation.

Use optimized query statements. The “explain plan” command will
show the access paths to the data.

Remove all unnecessary “lock table” statements. Do not use “for
update” clause in select statements if there is no need to update
immediately.

Issue commit statements immediately after “update”, “delete”, and
“insert” statements to release locked resources.

Use explicit cursors in all of your PL/SQL blocks.

Identical query statements in your application must match
character-by-character to use the same shared pool area.
Slow POP3 Server
for a POP3 server exceeds the Slow POP Server Time threshold in the
this case, a POP3 server). For each transaction the server takes part in (for
example, logins, send mail commands, and so on), the Expert measures the
the average time of all such transactions observed for a single POP3 server
exceeds the Slow POP Server Time threshold, the Expert generates this
alarm.
Possible causes:

There is a problem with the POP3 server.
9
Chapter 1

Slow Sybase/Microsoft SQL Server
for a Sybase or Microsoft TDS server exceeds either the Slow TDS Server
Time w/Cursors threshold (for transactions using cursors) or the Slow TDS
Server Time threshold (for transactions that do not use cursors) in the Alarms
this case, a TDS server). For each transaction the server takes part in, the
Expert measures the time it takes to complete the transaction. Transactions
using cursors are measured from the start of an Open Cursor statement to the
cursor's close. Transactions that do not use cursors are measured from the
the average time of either type of transaction observed for a single TDS server
exceeds the corresponding threshold (Slow TDS Server Time w/Cursors for
transactions using cursors; Slow TDS Server Time for transactions that do
not use cursors), the Expert generates this alarm.
Possible causes:

bandwidth.

protocols.

connections.

Add more MPIs.

10

drives.

immediately.

experts in this area. For example:

reparsing.

columns.
Slow Telnet Server
for an Telnet server exceeds the Slow Telnet Server Time threshold in the
this case, a Telnet server). For each transaction the server takes part in (for
example, logins, file requests, and so on), the Expert measures the time it
takes to complete the transaction. Transactions are measured from the first
frame of a request to the last frame of the corresponding response. When the
average time of all such transactions observed for a single Telnet server
exceeds the Slow Telnet Server Time threshold, the Expert generates this
alarm.
11
Chapter 1
Possible causes:

There is a problem with the Telnet server.

Application Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Application layer.
[VOIP] H323 - High Call Volume
The Expert generates the H323 – High Call Volume alarm when the number
of simultaneous H.323 calls on the network exceeds the Max concurrent
calls threshold. This threshold is found under the [VOIP] H323 – High call
volume alarm entry in the Alarms tab of the Expert UI Object Properties dialog
box (accessed by selecting Expert Options from the Tools menu).
During capture, the Expert maintains a counter of the number of H.323 calls
currently open. Each time a new H.323 call is opened, the Expert increments
the counter. Each time a call is released (that is, the Expert sees the H.225
Release Complete message for the call), the counter is decremented. Every
fifteen seconds, the Expert checks this counter to see if it exceeds the value
specified in the Expert UI Object Properties dialog box for the Max concurrent
calls threshold. If the number of open H.323 calls exceeds the threshold, the
Expert generates the H323 – High Call Volume alarm.
NOTE: Be sure to set the Max concurrent calls threshold to a value that
makes sense for your network. If the Expert is generating multiple instances
of this alarm but your network is not experiencing any other difficulties, you
may want to increase the value of the threshold so that the alarm is only
generated when the call volume becomes problematic for your network.
[VOIP] H323 - Too Many Incomplete Calls
The Expert generates the H323 – Too Many Incomplete Calls alarm when
the number of incomplete H.323 calls observed by the Expert exceeds the Max
incomplete calls threshold. This threshold is found under the [VOIP] H323 –
Too many incomplete calls alarm entry in the Alarms tab of the Expert UI
Object Properties dialog box (accessed by selecting Tools > Expert Options).
12
The Expert considers an H.323 call to be incomplete if more than three
minutes elapses after the last frame observed for the call and it doesn't see a
call termination message (H.225 Release Complete) for the call. The Expert
keeps a counter of these incomplete calls. Every fifteen seconds, the Expert
checks the incomplete calls counter to see if it exceeds the value specified in
the Expert UI Object Properties dialog box for the Max incomplete calls
threshold. If the number of incomplete H.323 calls exceeds the threshold, the
Expert generates the H323 – Too Many Incomplete Calls alarm.
Possible cause:

Incomplete calls can be caused by unexpected shutdowns of network
equipment (for example, because a device was turned off), abnormal
channel disconnections, or other network problems.
[VOIP] SCCP - High Call Volume
The Expert generates the SCCP – High Call Volume alarm when the number
of simultaneous calls on the network using Cisco's Skinny Client Control
Protocol (SCCP) exceeds the Max concurrent calls threshold. This threshold
is found under the [VOIP] SCCP – High call volume alarm entry in the
Alarms tab of the Expert UI Object Properties dialog box (accessed by
selecting Tools > Expert Options).
During capture, the Expert maintains a counter of the number of SCCP calls
currently open. Each time a new SCCP call is opened, the Expert increments
the counter. Each time a call is released (that is, the Expert sees the SCCP
StationStopMediaTransmission message for the call), the counter is
decremented. Every fifteen seconds, the Expert checks this counter to see if it
exceeds the value specified in the Expert UI Object Properties dialog box for
the Max concurrent calls threshold. If the number of open SCCP calls
exceeds the threshold, the Expert generates the SCCP – High Call Volume
alarm.
generated when the number of calls becomes problematic for your network.
13
Chapter 1
[VOIP] SCCP - Too Many Incomplete Calls
The Expert generates the SCCP – Too Many Incomplete Calls alarm when
the number of incomplete calls using Cisco's Skinny Client Control Protocol
(SCCP) observed by the Expert exceeds the Max incomplete calls threshold.
This threshold is found under the [VOIP] SCCP – Too many incomplete calls
alarm entry in the Alarms tab of the Expert UI Object Properties dialog box
(accessed by selecting Tools > Expert Options).
The Expert considers an SCCP call to be incomplete if more than three
minutes elapses after the last frame observed for the call and it doesn't see a
call termination message (SCCP StationStopMediaTransmission) for the
call. The Expert keeps a counter of these incomplete calls. Every fifteen
seconds, the Expert checks the incomplete calls counter to see if it exceeds
the value specified in the Expert UI Object Properties dialog box for the Max
incomplete calls threshold. If the number of incomplete SCCP calls exceeds
the threshold, the Expert generates the SCCP – Too Many Incomplete Calls
alarm.
Possible cause:

[VOIP] SIP - High Call Volume
The Expert generates the SIP – High Call Volume alarm when the number of
simultaneous SIP calls on the network exceeds the Max concurrent calls
threshold. This threshold is found under the [VOIP] SIP – High call volume
(accessed by selecting Tools > Expert Options).
During capture, the Expert maintains a counter of the number of SIP calls
currently open. Each time a new SIP call is opened, the Expert increments the
counter. Each time a call is released (that is, the Expert sees the SIP BYE
message for the call), the counter is decremented. Every fifteen seconds, the
Expert checks this counter to see if it exceeds the value specified in the Expert
UI Object Properties dialog box for the Max concurrent calls threshold. If the
number of open SIP calls exceeds the threshold, the Expert generates the SIP
– High Call Volume alarm.
generated when the number of calls becomes problematic for your network.
14
[VOIP] SIP - Too Many Incomplete Calls
The Expert generates the SIP – Too Many Incomplete Calls alarm when the
number of incomplete SIP calls observed by the Expert exceeds the Max
incomplete calls threshold. This threshold is found under the [VOIP] SIP –
Too many incomplete calls alarm entry in the Alarms tab of the Expert UI
Object Properties dialog box (accessed by selecting Tools > Expert Options).
The Expert considers a SIP call to be incomplete if more than three minutes
elapses after the last frame observed for the call and it doesn't see a call
termination message (SIP BYE) for the call. The Expert keeps a counter of
these incomplete calls. Every fifteen seconds, the Expert checks the
incomplete calls counter to see if it exceeds the value specified in the Expert
UI Object Properties dialog box for the Max incomplete calls threshold. If the
number of incomplete SIP calls exceeds the threshold, the Expert generates
the SIP – Too Many Incomplete Calls alarm.
Possible cause:

Access to Resource Denied
The Expert generates the Access to Resource Denied alarm when a station
fails to establish an SMB session due to access restrictions. The name of the
station is listed in the corresponding summary row.
Possible cause:

The station has attempted to connect to a system resource that is either
not sharable or that has reached its limit of simultaneously sharing
users. Check with the user/administrator of the resource to gain access
rights. A typical situation in which this alarm might occur is when a user
is scanning the Network Neighborhood, attempting to see what
resources outside of their domain they might be able to access.
Browser Election Force
The Expert generates the Browser Election Force alarm when a node sends
a Browser Force Election request. Periodic election forces are normal in
Microsoft networks. The node has not seen a local master browser and is
initiating the process to become one itself. The name of the station is listed in
the corresponding summary row.
15
Chapter 1
Possible causes:

The listed node's local network currently has no master browser to
service its browser requests. Check the current settings for the node's
subnet mask, IP address, and source-level routing to ensure that its
network interface is properly configured.

No other nodes running the browser service are configured to run as a
master browser. In this case, the node sending the Browser Force
Election request should become the local Master Browser. Some
nodes (such as LINUX boxes running SAMBA) can configure Browser
Roles.
DB Connect Request Denied
The Expert generates the DB Connect Request Denied alarm when the
number of SQL Server connect requests denied exceeds the DB Connection
Failed threshold. A request to login is refused by the server, because it is
unable to satisfy the options asked for in the login record. Examine the service
options in the connect packet and determine whether they are options that are
allowed in the target server.
Possible causes:

Invalid username.

Invalid password.

Invalid server.
DB Security Breach Attempt
The Expert generates the DB Security Breach Attempt alarm when the
number of login failures exceeds the DB Security Breach Attempt threshold.
Possible causes:

Invalid username.

Invalid password.

Invalid server.
DB Slow Connect
The Expert generates the DB Slow Connect alarm when the time it takes a
SQL Server to respond to a request to login to a SQL Server exceeds the DB
Slow Connect Time threshold. This may or may not be normal, depending
upon the application and the setting of the DB Slow Connect Time threshold.
16
Possible causes:

The server is too busy. If this occurs frequently in a server with several
users already active, consider taking performance tuning steps to
improve the server response.

There is a lot of traffic on your network.

Other users may be trying to connect to the server at the same time,
thereby reducing the response time.

The DB Slow Connect Time threshold may be set too low for your
environment.
DB Slow Server Response
The Expert generates the DB Slow Server Response alarm when the time it
takes for a server to respond to one or more SQL commands exceeds the DB
Slow Server Response Time threshold.
Possible causes:

bandwidth.

protocols.

connections.

Add more MPIs.

drives.
17
Chapter 1

immediately.

reparsing.

columns.
DB Slow Server Response Diagnosis
The Expert considers a server's response to an SQL request to be slow when
the time between request and response is longer than the DB Slow Server
Connect Time threshold. The Expert counts these slow responses. When the
total number of slow responses seen during the time period specified by the
DB Slow Server Response Interval threshold exceeds the DB Slow Server
Response Count threshold, the Expert generates the DB Slow Server
Response Diagnosis.
Possible causes:

18
bandwidth.

protocols.

connections.

Add more MPIs.

drives.

immediately.

reparsing.
19
Chapter 1

columns.
Excessive Failed Resource Login Attempts
The Expert generates the Excessive Failed Resource Login Attempts
alarm when the number of consecutive login attempts with an incorrect
password or user name for the listed station exceeds the Excessive Failed
Resource Login Attempts threshold. The address of the offending station is
listed in the Summary row.
Possible causes:

A user has forgotten their password and continues to try different dimly
recalled passwords.

An attempt to guess passwords for a given user ID has occurred.
Repeated alarms may indicate an attempted security breach (for
example, a program that tries to guess user names and passwords for
a given node may be running).
Excessive Mailslot Broadcasts
The Expert generates the Excessive Mailslot Broadcasts alarm when the
number of mailslot broadcast messages sent by a station in the last second
exceeds the Excessive Mailslot Broadcasts threshold. The address of the
offending station is listed in the Summary row. Excessive mailslot broadcasts
can indicate poorly-written software and should be investigated.
Possible causes:

Faulty software resulting in a burst of broadcast messages. Typically,
there should be a delay between consecutive broadcasts so the
network is not flooded with mostly useless information. Excessive
broadcasts to networks reachable through a router can cause the
router to drop packets.
FCIP Special Frame Discovery
The Expert generates the FCIP Special Frame Discovery alarm when it
detects an FCIP Special Frame (FSF) with the field for the destination entity's
World Wide name set to zero. Source FCIP entities send FSF frames such as
this to discover the World Wide name of the destination FCIP entity.
This is not a serious alarm. However, you should keep in mind that FCIP
connections cannot be set up in response to the receipt of an FSF with the
destination entity's World Wide name field set to zero.
20
Possible causes:

The source entity does not know the destination entity's World Wide
Name.
FCIP Invalid Encapsulation
The Expert generates the FCIP Invalid Encapsulation alarm when it detects
an FCIP frame with errors in its encapsulation. The Expert detects
encapsulation errors by examining the 1's Complement fields in FCIP frames.
Any FCIP frame with errors in any of the 1's complement fields will be dropped
by the receiving FCIP entity. In an FCIP frame, the 1's complement values are
used to ensure the consistency of the data being transmitted. This is
irrespective of whether a CRC is present or not.
Possible causes:

There were transmission errors.

The packet was encoded incorrectly in duplicated or 1’s Complement
fields.
FCIP Repeat Special Frame
The Expert generates the FCIP Repeat Special Frame alarm when it detects
more than one FCIP Special Frame (FSF) sent in either direction on an FCIP
connection.
Typically, an FSF is transmitted only once for each successful FCIP
connection established. A repeated FSF may cause the connection setup
between the two FCIP entities to fail or the connection to flap.
Possible causes:

The FCIP source entity may be doing discovery using the FCIP Special
Frame.

This may be a Replay Attack to disrupt the FCIP connection.
FCIP Special Frame Echo Has Changed
The Expert generates the FCIP Special Frame Echo Has Changed alarm
when it detects that an FCIP entity echoed back an FCIP Special Frame (FSF)
that was different than the FSF it originally received.
In FCIP, for a connection to be set up correctly, the FCIP destination entity has
to echo back the FSF to the source entity without any changes. A changed
Echo sent in response to an FSF will cause the FCIP connection to break.
21
Chapter 1
Possible causes:

The FCIP destination entity cannot accept any more connections.

The connection parameters in the FSF are not acceptable to the FCIP
destination entity.

This is a reply to FCIP Special Frame Discovery for the destination
entity’s World Wide Name.
FCIP Special Frame Delayed
The Expert generates the FCIP Special Frame Echo Delayed alarm when the
FCIP Special frame echo has not been received within the amount of time
specified by the Special Echo Frame Delayed threshold.
Possible causes:

The FCIP destination Entity is too busy.

The echo FCIP SF has been dropped somewhere in the network.
FCIP Too Many Special Frame Echoes
The Expert generates the FCIP Too Many Special Frame Echoes alarm
when the number of FCIP Special Frame (FSF) echoes transmitted by the
FCIP Destination entity exceeds the Frames Contain Errors threshold. The
presence of more than one FSF echo will cause immediate tear down of the
FCIP connection.
Possible causes:

The destination FCIP entity needs to close the FCIP connection.

This may be caused by a replay attack.
FCIP Transmission Errors
The Expert generates the FCIP Transmission Errors alarm when the number
of transmission errors detected for an FCIP connection exceeds the Frames
Contain Errors threshold. Too many transmission errors on an FCIP
connection will cause loss of throughput for the connection.
Possible causes:

22
Causes will depend on the physical media. For example, on a wireless
network, this can be caused by signal attenuation.
FTP Login Attempts
The Expert generates the FTP Login Attempts alarm when the number of
FTP login attempts for a station exceeds the FTP Connect Tries threshold.
Possible causes:

The login ID is incorrect.

The login password is incorrect.

FTP Slow Connect
The Expert generates the FTP Slow Connect alarm when the amount of time
it takes an FTP server to acknowledge a login request exceeds the FTP
Connect Time threshold.
Possible causes:

There is a problem with the FTP server.

FTP Slow First Response
When an FTP session is established between a server and client, the server's
first response to an FTP command is usually the slowest. This is because the
server typically has to open or create files in response to the first command.
Subsequent responses typically do not take as much time. The FTP Slow
First Response alarm is generated when a response to a client's first
command exceeds the FTP Login Time threshold.
FTP Slow Response
When an FTP session is established between a server and client, the server's
first response to an FTP command is usually the slowest. This is because the
server typically has to open or create files in response to the first command.
Subsequent responses typically do not take as much time. The FTP Slow
Response alarm is generated when a response to a command after the first
one exceeds the FTP Interframe Time threshold.
23
Chapter 1
FTP Slow Transfer Diagnosis
The Expert considers an FTP server's response to an FTP request to be slow
when the time between request and response is longer than either the FTP
Login Time threshold (for the response to the first request in the session) or
the FTP Interframe Time threshold (for responses to all subsequent requests
during the session). The Expert counts these slow responses. When the total
number of slow responses seen during the time period specified by the FTP
Interframe Interval threshold exceeds the FTP Interframe Count threshold,
the Expert generates the FTP Slow Transfer Diagnosis.
HTTP Slow Server GET Response Time
The Expert generates the HTTP Slow Server GET Response Time alarm
when an HTTP server's response to a GET request takes longer than the
HTTP Slow Server GET Response Time threshold to reach the requesting
station.
When a station sends an HTTP GET request, the Expert starts a counter. If the
counter exceeds the HTTP Slow Server GET Response Time threshold
before the HTTP server returns a response, the Expert generates the alarm.
This alarm can be useful when measuring the responsiveness of a web server.
Possible causes:

HTTP Slow Server POST Response Time
The Expert generates the HTTP Slow Server POST Response Time alarm
when an HTTP server's response to a POST message takes longer than the
HTTP Slow Server POST Response Time threshold to reach the sending
station.
When a station sends an HTTP POST message, the Expert starts a counter.
If the counter exceeds the HTTP Slow Server POST Response Time threshold
before the HTTP server returns a response, the Expert generates the alarm.
This alarm can be useful when measuring the responsiveness of a web server.
Possible causes:
24

Invalid Network Name
The Expert generates the Invalid Network Name alarm when a station fails to
establish an SMB session because it is specifying a network resource name
that does not exist on the station with which it is attempting to communicate.
Possible cause:

The client has specified a network resource name that does not exist
on the server.
Invalid Resource User Name or Password
The Expert generates the Invalid Resource User Name or Password alarm
when a station has fails to establish an SMB session due to an incorrect user
name or password.
Possible cause:

A client running Windows 95 or Windows 98 attempted to connect to a
resource using an invalid user name or password. In this case, the
client found the resource and attempted to connect to it using an invalid
password or user ID. Repeated alarms may indicate an attempted
security breach (for example, a program which tries to guess user
names and passwords for a given node may be running).
iSCSI: Authorization Failure
The Expert generates the iSCSI: Authorization Failure alarm when it detects
an iSCSI Login Response message with the Status Code set to 0202 Authorization Failure. This status code indicates that the initiator is not
allowed access to the target (the initiator’s login request has been rejected by
the target).
Possible cause:

The initiator does not have sufficient privileges to access the target.
iSCSI: Can Not Generate Target Transfer Tag - Out of Resources
The Expert generates the iSCSI: Can Not Generate Target Transfer Tag
(Out of Resources) alarm when it detects an iSCSI Reject message with the
Reason Code set to 0x0a - Can’t Generate Target Transfer Tab - Out of
Resources. This Reason Code indicates that the target is out of resources
and cannot generate a new Target Transfer Tag. Because of this, the target
rejects the command from the initiator.
25
Chapter 1
iSCSI: Command Not Supported in this Session Type
The Expert generates the iSCSI: Command Not Supported in this Session
Type alarm when it detects an iSCSI Reject message with the Reason Code
set to 0x05 - Command Not Supported. This Reason Code indicates that the
SCSI command from the initiator is not supported by the target for the specified
session type of the connection. Because of this, the target has rejected the
initiator command request.
iSCSI: Command Retransmission
The Expert generates the iSCSI: Command Retransmission alarm when it
detects an initiator resending the same iSCSI command PDU (“retry”) in the
absence of a command acknowledgement (by way of an ExpCmdSN update)
or a response. As described in RFC 3720, this is normal iSCSI behavior when
an initiator tries to patch what it thinks are discontinuities in CmdSN ordering
on the target end of the connection. This is an informational alarm and does
not indicate an error condition.
iSCSI: Data Digest Error
The Expert generates the iSCSI: Data Digest Error alarm when it detects an
iSCSI Reject message with the Reason Code set to 0x02 - Data Digest Error.
Data digest errors indicate that data integrity has been compromised. The data
(payload) digest protects the integrity of the data.
iSCSI: Data or Status again Requested
The Expert generates the iSCSI: Data or Status again Requested alarm
when it detects an initiator requesting the retransmission of either data or
status using a SNACK request. For this to occur successfully, the
implementation must support an ErrorRecoveryLevel greater that zero. This
is an informational alarm and does not indicate an error condition.
iSCSI: Function Authorization Failed
The Expert generates the iSCSI: Function Authentication Failed alarm
when it detects an iSCSI Task Management Function Response with a
response code set to 6 - Function Authorization Failed. This response code
may appear if the initiator does not have sufficient privileges to request the
specified task management function on the target.
26
iSCSI: Function Rejected
The Expert generates the iSCSI: Function Rejected alarm when it detects an
iSCSI Task Management Function Response with a response code set to 255
- Function rejected. This response code indicates that the requested task
management function can not be executed on the target and has therefore
been rejected.
iSCSI: Immediate Command Reject (Too Many Immediate
Commands)
The Expert generates the iSCSI: Immediate Command Reject (Too Many
Immediate Commands) alarm when it detects an iSCSI Reject message with
the Reason Code set to 0x06 - Immediate Command Reject. This reason
code indicates that the initiator has marked a command as immediate but the
target cannot process it immediately because it already has too many
immediate commands waiting in the queue to be processed.
iSCSI: Initiator Authentication Failed
The Expert generates the iSCSI: Initiator Authentication Failed alarm when
it detects an iSCSI Login Response message with the Status Code set to 0201
- Authentication Failure. This status code indicates that the initiator could not
be successfully authenticated or that target authentication is not supported.
Possible causes:

Wrong login parameters given by the initiator in login request PDU.

Authentication not supported at target.
iSCSI: Invalid Data Ack
The Expert generates the iSCSI: Invalid Data Ack alarm when it detects an
iSCSI Reject message with the Reason Code set to 0x08 - Invalid Data ACK.
Rejects with this reason code can occur when an initiator replies to a target’s
request for positive acknowledgement of received data with a SNACK using a
DataAck type that is invalid for sessions with an ErrorRecoveryLevel of 1 or
higher.
iSCSI: Invalid PDU field
The Expert generates the iSCSI: Invalid PDU field alarm when it detects an
iSCSI Reject message with the Reason Code set to 0x09 - Invalid PDU Field.
Rejects with this reason code indicate that a request PDU contained wrong or
invalid values for fields that are meant to describe a task, a response, or a data
transfer (for example, a Buffer offset or a Target Transfer Tag value).
27
Chapter 1
iSCSI: Invalid During Login
The Expert generates the iSCSI: Invalid During Login alarm when it detects
an iSCSI Login Response message with the Status Code set to 020b - Invalid
Request Type During Login. This status code indicates that the target is
rejecting the login request from the initiator because it is invalid in the
negotiation phase (that is, it can only be valid after entering the full feature
phase). Because of this, the Login Request has been rejected by the target.
iSCSI: LUN Does Not Exist
The Expert generates the iSCSI: LUN Does Not Exist alarm when it detects
an iSCSI Task Management Function Response with a response code set to
2 - LUN does not exist. This response code indicates that the LUN on which
the task management function has been requested does not exist.
iSCSI: Miscellaneous Initiator Error
The Expert generates the iSCSI: Miscellaneous Initiator Error alarm when it
detects an iSCSI Login Response message with the Status Code set to 0200
- Miscellaneous iSCSI initiator error.
iSCSI: Missing Parameter
The Expert generates the iSCSI: Missing Parameter alarm when it detects
an iSCSI Login Response message with the Status Code set to 0207 Missing Parameter. This status code indicates that the target is rejecting the
login request from the initiator because some parameter is missing from the
initiator login request PDU (for example, the iSCSI Initiator or Target Name).
Because of this, the target cannot process the Login Request.
iSCSI: Service Unavailable
The Expert generates the iSCSI: Service Unavailable alarm when it detects
an iSCSI Login Response message with the Status Code set to 0301 - Service
Unavailable. This status code indicates that the target is rejecting the login
request from the initiator because the iSCSI service or target requested by the
initiator command PDU is not available to service the request. This is a target
side error.
iSCSI: Session Does Not Exist
The Expert generates the iSCSI: Session Does Not Exist alarm when it
detects an iSCSI Login Response message with the Status Code set to 020a
- Session Does Not Exist. This status code indicates that the initiator has
requested login to a non-existent session.
28
iSCSI: Target Error
The Expert generates the iSCSI: Target Error alarm when it detects an iSCSI
Login Response message with the Status Code set to 0300 - Target Error.
This status code indicates that the target is rejecting the login request from the
initiator because either a hardware or software error has occurred on the target
side of the connection making it impossible for the target to accept
connections.
iSCSI: Target Failure
The Expert generates the iSCSI: Target Failure alarm when it detects an
iSCSI Service Response Code set to 0x01 - Target Failure in a SCSI
Response. This response code can indicate that there is a SCSI service failure
and the target is not able to proceed with the processing of initiator commands.
This can occur if the SCSI response PDU does not arrive before the session
is terminated.
iSCSI: Target Out of Resources
The Expert generates the iSCSI: Target Out of Resources alarm when it
- Out of Resources. This status code indicates that the target is rejecting the
login request from the initiator because it has insufficient resources to service
any new request from the initiator. This is a target side error.
iSCSI: Target Removed
The Expert generates the iSCSI: Target Removed alarm when it detects an
iSCSI Login Response message with the Status Code set to 0204 - Target
removed. This status code indicates that the target is rejecting the login
request from the initiator because the requested iSCSI Target Name has been
removed and no forwarding address was provided.
iSCSI: Task Does Not Exist
The Expert generates the iSCSI: Task Does Not Exist alarm when it detects
an iSCSI Task Management Function Response with a response code set to
1 - Task Does Not Exist. This response code indicates that the task
management function has been requested by the initiator on a task which does
not exist on the target. The Task Management functions provide an initiator
with a way to explicitly control the execution of one or more tasks (SCSI and
iSCSI tasks).
29
Chapter 1
iSCSI: Task Management Function Not Supported
The Expert generates the iSCSI: Task Management Function Not
Supported alarm when it detects an iSCSI Task Management Function
Response with a response code set to 5 - Task management function not
supported. This response code indicates that the task management function
requested by the initiator is not supported by the target.
iSCSI: Too Many Connections
The Expert generates the iSCSI: Too Many Connections alarm when it
- Too Many Connection. This status code indicates that the target is rejecting
the login request from the initiator because the maximum number of
connections possible on the requested Session ID has been reached; no more
connections are possible on this Session ID.
iSCSI: Unsupported Version
The Expert generates the iSCSI: Target Moved alarm when it detects an
iSCSI Login Response message with the Status Code set to 0205 Unsupported Version. This status code indicates that the target is rejecting
the login request from the initiator because the iSCSI version range in the login
request PDU is not supported by the target.
Missed Browser Announcement
The Expert generates the Missed Browser Announcement alarm when a
node has not sent a browser announcement frame within its stated interval
multiplied by the Missed Browser Announcement threshold (by default,
three). The offending station is listed in the Object column of the summary
row.
Client systems on a Microsoft network send browser announcement frames at
regular intervals. These frames announce that the client system is still on the
network and identify the announcing system's resources. One field in the
announcement frame specifies the number of milliseconds that will elapse
before the system will send the next announcement frame. If the next
announcement frame does not reach the Master Browser within the stated
number of seconds multiplied by the Missed Browser Announcement
threshold, the Expert generates the Missed Browser Announcement alarm.
Possible causes:
30

The node has been shut down.

The local network is very busy, resulting in a high loss of frames.
MS RAP Logon Failure
The Expert generates the MS RAP Logon Failure alarm when a Microsoft
station fails to log in to a server.
Possible causes:

The user has insufficient privileges to log in to this server. Contact the
server administrator to change the user's privileges, if necessary.

An error occurred while loading or running a login script. Contact the
server administrator.

The login was not validated by a server. Contact the server
administrator.

The login server is running an older software version the client.
Because of this, the server cannot validate the login. Contact the server
administrator.

The user is not allowed to log in from this computer. Contact the server
administrator.

The user is not allowed to log in at this time. Contact the server
administrator.
NCP Server Busy
The Expert generates the NCP Server Busy alarm when the total of the
following types of frames seen by the analyzer exceeds the Server Busy
Count threshold:

NCP 0x9999 (server busy) frames

Novell Burst Mode frames with the communication control flag bit set
for server busy.
Possible causes:

Too many clients using the same server.

Server is overloaded with NCP requests.

Network is busy.
31
Chapter 1
NFS Retransmission
The Expert generates the NFS Retransmission alarm when it sees a
retransmitted NFS request. NFS retransmissions are detected by comparing
the current RPC Transaction Identifier with the previous value for a
connection. The summary row for this alarm will have identifying information
for the offending application.
An NFS retransmission may result in the retransmission of multiple frames,
because many NFS transactions involve up to 8K of data spanning several
frames.
Possible cause:

NFS retransmissions are often due to missing IP fragments. Check the
network symptoms to see if there are any IP fragment problems.
NNTP Slow Response Time
The Expert generates the NNTP Slow Response Time alarm when the time
it takes for a server's first response to an NNTP ARTICLE command exceeds
the NNTP Slow Connect Time threshold.
Possible causes:

There is a problem with the NNTP server.

POP3 Slow Connect Time
The Expert generates the POP3 Slow Connect Time alarm when the time it
takes to connect to a POP3 server exceeds the POP3 Slow Connect Time
threshold.
Possible causes:

There is a problem with the POP3 server.

Protocol Negotiation Failure
The Expert generates the Protocol Negotiation Failure alarm when a station
fails to negotiate a SMB protocol.
32
Possible cause:

The versions of SMB offered by the client are not supported by the
Server. Check the configurations of the SMB client and server.

This could be an attempt by the client to circumvent security
improvements in the SMB protocol by attempting to negotiate an older,
“weaker” dialect.
SAP R3 Slow Server Connection
The amount of time it took a SAP R3 server to acknowledge a login request
exceeded the SAP Slow Server Connection Time threshold.
Possible causes:

There is a problem with the SAP R3 server.

There is excessive network congestion. Since SAP R3 servers are
primarily used for e-business automation, this alarm may occur during
periods of high business activity, such as an end of quarter close, or a
holiday sales peak.
SAP R3 Slow Server Response
The time it took for a SAP R3 server's first response to a request other than a
login request exceeded the SAP Slow Server Response Time threshold.
Possible causes:

There is a problem with the SAP R3 server.

There is excessive network congestion. Since SAP R3 servers are
primarily used for e-business automation, this alarm may occur during
periods of high business activity, such as an end of quarter close, or a
holiday sales peak.
SMTP Slow Connect Time
The Expert generates the SMTP Slow Connect Time alarm when the time it
takes for a server's first response to an SMTP request exceeds the SMTP
Slow Connect Time threshold.
Possible causes:

There is a problem with the SMTP server.

33
Chapter 1
Station Not in Domain’s Computer List
The Expert generates the Station not in Domain’s Computer List alarm when
it sees a station that is not a member of the computer list maintained on a
particular domain controller/server. This can cause problems if the node is a
local domain controller used by clients for pass-through authentication to
remotely-maintained domains. It can also prevent a client from being able to
log on to a domain and access domain resources.
Possible causes:

The computer list on the remote domain controller does not contain the
station listed in the alarm. If you need to, add the node to the remotely
located domain controller's computer list. This will allow that node to
communicate with the domain and its resources.

A new computer has been added to the network and it has not yet been
added to the domain's computer list. This node will not be allowed to
log in to that domain and access domain resources.
Telnet Slow Response to Login
The Expert generates the Telnet Slow Response to Login alarm when the
time it takes for a server to respond to a Telnet login exceeds the Telnet
Connect threshold.
Possible causes:

There is a problem with the Telnet server.

Session Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Session layer.
[VOIP] H225 - Abnormal Disconnect
The Expert generates the [VOIP] H225 – Abnormal Disconnect alarm when
it observes an H.225 Release Complete message with either the
ReleaseCompleteReason or Cause information element set to one of the
following:
34

noBandwidth — Bandwidth taken away or ARQ denied

gatekeeperResources — Gatekeeper exhausted

gatewayResources — Switching equipment congestion

adaptiveBusy — Call is dropping due to LAN crowding
[VOIP] H245 - Open Logical Channel Reject
The Expert generates the [VOIP] H245 – Open Logical Channel Reject
alarm when it observes an H.245 Open Logical Channel Reject message.
One of the purposes of H.245 is to govern the opening and closing of logical
channels and ensure that receiving stations have the capability to decode the
data to be sent to them before they actually receive any data. H.245 Open
Logical Channel messages include an indication of the type of data to be sent
over the proposed logical channel (as well as the speed at which it will be
sent). If a receiving station will be unable to receive and decode the proposed
data properly, it sends an Open Logical Channel Reject message rejecting
the request to open a logical channel.
The Open Logical Channel Reject message includes a cause field indicating
the reason why the request was rejected. The possible values for the cause
field are as follows:

unspecified – No cause for rejection was specified.

unsuitableReverseParameters – The requested reverse logical
channel parameters for a bi-directional logical channel request were
not appropriate.

dataTypeNotSupported – The data type indicated in the Open Logical
Channel message was not supported by the receiving station.

dataTypeNotAvailable – The receiving station is incapable of
supporting the data type indicated in the Open Logical Channel
message in combination with data types already in use on other open
logical channels.

unknownDataType – The receiving station did not understand the data
type indicated in the Open Logical Channel message.

dataTypeALCombinationNotSupported – The receiving station is
incapable of supporting the data type indicated in the Open Logical
Channel message in combination with the Adaptation Layer type
indicated in the H223 Logical Channel Parameters field.

multicastChannelNotAllowed – A multicast channel could not be
opened.

insuffientBandwdith – A channel could not be opened because
permission to use the bandwidth requested in the Open Logical
Channel message was not granted.
35
Chapter 1

separateStackEstablishmentFailed – It was not possible to run the
data portion of a call on a separate stack.

invalidSessionID – The slave attempted to set the Session ID when
opening the logical channel to the master.

masterSlaveConflict – The slave attempted to open a logical channel
on which the master has identified a possible conflict.

waitForCommunicationMode – There was an attempt to open the
logical channel before the Multipoint Control Entity transmitted the
Communication Mode Command.

invalidDependentChannel – An invalid dependent channel was
specified for the attempted logical channel.

replacementForRejected – The type of logical channel attempted can
not be opened with the replacementFor parameter.
[VOIP] H245 - Terminal Capability Set Reject
The Expert generates the [VOIP] H245 – Terminal Capability Set Reject
alarm when it observes an H.245 Terminal Capability Set Reject message.
H.245-capable terminals exchange H.245 terminal capability messages to
determine the different transmit and receive modes of which each is capable
(for example, CIF H.263 video, G.723.1 audio, and so on). H.245 Terminal
Capability Set messages include a capability table listing these transmit and
receive modes. H.245-capable stations reject Terminal Capability Set
messages by sending the Terminal Capability Set Reject message. The
reject message includes a cause field indicating the reason for the rejection.
The possible values for the cause field are as follows:

undefinedTableEntryUsed – One of the capability descriptors in the
Terminal Capability Set message referred to an undefined capability
table entry.

descriptorCapacityExceeded – The receiving station could not store
all the information in the Terminal Capability Set message.

tableEntryCapacityExceeded – Either the receiving station could not
store more capability table entries than indicated in the
highestEntryNumberProcessed field or could not store any entries at
all.
[VOIP] RAS - Admission Reject
The Expert generates the [VOIP] RAS – Admission Reject alarm when it
observes a RAS Admission Reject (ARJ) message.
36
In the H.323 protocol stack, the Registration, Admission, and Status (RAS)
protocol provides H.225 terminal to gatekeeper signalling services. H.225
terminals send RAS Admission Request messages (ARQs) to request
access to a packet-based network from the gatekeeper. In turn, gatekeepers
respond to ARQs with either an Admission Confirm (ACF) message granting
the request or an Admission Reject (ARJ) message denying the request.
The ARJ message includes a rejectReason field indicating the reason why the
ARQ was denied. The possible values for the rejectReason field for an ARJ are
as follows:

Called Party not Registered (address cannot be translated)

Invalid Permission (permission expired)

Request Denied (no bandwidth available)

Undefined Reason

Caller not Registered

Route Call to Gatekeeper

Invalid Endpoint Identifier

Resource Unavailable

Security Denial

QOS Control Not Supported

Incomplete Address

Aliases Inconsistent (there are multiple aliases in the request)

Route Call to SCN (the ARJ will include a list of alternate telephone
numbers to which the gateway can redirect the call, if supported by the
gateway).

Exceeds Call Capacity (the destination does not have the capacity to
accept the call at this time).

Collect Destination (gatekeeper requests that the gateway collect the
final destination address).

Collect PIN (gatekeeper requests that the gateway collect an
authorization code or PIN).

Generic Data Reason (there may be additional information in the
genericData field of the ARJ message; examine the Decode display for
details)

Needed Feature Not Supported
37
Chapter 1
[VOIP] RAS - Bandwidth Reject
The Expert generates the [VOIP] RAS – Bandwidth Reject alarm when it
observes a RAS Bandwidth Reject (BRJ) message.
terminals and gatekeepers send RAS Bandwidth Request messages (BRQ) to
request changes in allocated bandwidth from one another. When a terminal or
gatekeeper receives a BRQ, it can respond with either a Bandwidth Confirm
(BCF) message granting the request or a Bandwidth Reject (BRJ) message
denying the request.
The BRJ message includes a rejectReason field indicating the reason why the
BRQ was denied. The possible values for the rejectReason field for a BRJ are
as follows:

Not Bound (discovery permission aged out)

Invalid Conference ID (possible revision)

Invalid Permission (true permission violation)

Insufficient Resources

Invalid Revision

Undefined Reason

Security Denial
[VOIP] RAS - Disengage Reject
The Expert generates the [VOIP] RAS – Disengage Reject alarm when it
observes a RAS Disengage Reject (DRJ) message.
gatekeepers send RAS Disengage Reject messages (DRJs) to reject
Disengage Requests (DRQs) from unregistered endpoints.
[VOIP] RAS - Gatekeeper Reject
The Expert generates the [VOIP] RAS – Gatekeeper Reject alarm when it
observes a RAS Gatekeeper Reject (GRJ) message.
38
terminals send RAS Gatekeeper Request messages (GRQs) to request
permission to register with any gatekeeper receiving the message. In turn,
gatekeepers respond to GRQs with either a Gatekeeper Confirm (GCF)
message granting the request or a Gatekeeper Reject (GRJ) message denying
the request. RAS GRJ messages are an indication that the H.225 terminal
should look for another gatekeeper with which to register.
The GRJ message includes a rejectReason field indicating the reason why the
GRQ was denied. The possible values for the rejectReason field for a GRJ are
as follows:

Terminal Excluded (permission failure; not a resource failure)

Invalid Revision

Undefined Reason

Security Denial

genericData field of the GRJ message; examine the Decode display
for details)

[VOIP] RAS - Location Reject
The Expert generates the [VOIP] RAS – Location Reject alarm when it
observes a RAS Location Reject (LRJ) message.
terminals send RAS Location Request messages (LRQs) to request address
translation services from the gatekeeper. In turn, gatekeepers respond to
LRQs with either a Location Confirm (LCF) message containing the transport
address of the requested destination or a Location Reject (LRJ) message
denying the request.
The LRJ message includes a rejectReason field indicating the reason why the
LRQ was denied. The possible values for the rejectReason field for an LRJ are
as follows:

Not Registered (requesting terminal is not registered with gatekeeper)

Invalid Permission (exclusion by an administrator or feature)

Request Denied (location cannot be found)

Undefined Reason
39
Chapter 1

Security Denial

Aliases Inconsistent (there are multiple aliases in the request)

Route Call to SCN (the LRJ will include a list of alternate telephone
numbers to which the gateway can redirect the call, if supported by the
gateway)

genericData field of the LRJ message; examine the Decode display for
details)

[VOIP] RAS - Registration Reject
The Expert generates the [VOIP] RAS – Registration Reject alarm when it
observes a RAS Registration Reject (RRJ) message.
terminals send RAS Registration Request messages (RRQs) to gatekeepers to
request permission to register. In turn, gatekeepers respond to RRQs with
either a Registration Confirm (RCF) message granting registration or a
Registration Reject (RRJ) message denying registration. If the terminal
receives an RCF, it uses the responding gatekeeper for its calls; if it receives
an RRJ, it must find a different gatekeeper with which to register.
The RRJ message includes a rejectReason field indicating the reason why the
RRQ was denied. The possible values for the rejectReason field for an RRJ are
as follows:
40

Discovery Required

Invalid Revision

Invalid Call Signal Address

Invalid RAS Address (the supplied address is invalid)

Duplicate Alias (the provided alias is registered to another terminal)

Invalid Terminal Type

Undefined Reason

Transport not Supported

Transport Quality of Service (QOS) not Supported (the endpoint's
QOS is not supported)

Resource Unavailable (gatekeeper resources are exhausted)

Invalid Alias (the provided alias is not consistent with gatekeeper
rules)

Security Denial

Full Registration Required (registration permission expired)

Additive Registration Not Supported

Invalid Terminal Aliases

Generic Data Reason

[VOIP] RAS - Unregistration Reject
The Expert generates the [VOIP] RAS – Unregistration Reject alarm when it
observes a RAS Unregistration Reject (URJ) message.
terminals send RAS Unregistration Request messages (URQs) to gatekeepers
to request that they no longer be associated with the gatekeeper. In turn,
gatekeepers respond to URQs with either an Unregistration Confirm (UCF)
message granting registration or an Unregistration Reject (URJ) message
denying unregistration. The Expert generates this alarm when it sees that a
URQ has been rejected with a URJ.
[VOIP] RTCP - Report High Jitter
The Expert generates the [VOIP] RTCP – Report High Jitter alarm when the
interarrival jitter reported in either an RTCP Sender Report or Receiver Report
packet exceeds the Max jitter threshold. This threshold is found under the
[VOIP] RTCP – Report high jitter alarm entry in the Alarms tab of the Expert
UI Object Properties dialog box (accessed by selecting Tools > Expert
Options).
The Real-Time Transport Control Protocol (RTCP) is used to monitor and
report statistics on the quality of an ongoing RTP transaction between two or
more endpoints. Each of the endpoints in an RTP transaction periodically
issues RTCP report packets providing various statistics measuring the quality
of the RTP data stream it is receiving. RTCP report packets (both Sender
Reports and Receiver Reports) always include an interarrival jitter statistic.
Essentially, interarrival jitter measures the mean difference in interpacket
spacing between a sending station and a receiving station. For example, if
Station A sends packets x and y at a spacing of 50 milliseconds and Station B
receives the same packets x and y at a spacing of 80 milliseconds, interarrival
jitter for this pair of packets is 30 milliseconds (the difference in packet spacing
from sender to receiver). The exact calculation performed by an RTP endpoint
41
Chapter 1
is somewhat more complicated than this since packets are continuously
arriving. Each RTP endpoint maintains an ongoing calculation of interarrival
jitter so that the value becomes a statistically smoothed mean for all packets
received (see Annex A of ITU-T Recommendation H.225 for complete details).
Whenever an RTCP Report packet is issued, the RTP endpoint includes its
current value for interarrival jitter.
The Expert captures all RTCP Report packets. If the value reported for
interarrival jitter in one of these Report packets exceeds the Max jitter
threshold (expressed in milliseconds), the Expert generates the RTCP –
Report High Jitter alarm for the RTP session. The alarm display provides a
breakdown of the individual jitter alarms for a given connection, indicating for
which side of the connection different alarms have been generated, as well as
the source of the last RTCP Report packet the Expert has seen for this RTP
connection.
The alarm display provides the following information:
42

Last Report Source – The source of the last RTCP Report packet for
this RTP connection. In addition to the source's address, the type of
report is also indicated (Sender Report or Receiver Report).

Threshold – The value of the Max jitter threshold when this alarm was
generated.

Reported Jitter – The value indicated for interarrival jitter in the last
received RTCP Report packet for this RTP connection.

# of Net Station 1 Send Jitter Alarms – The number of jitter alarms
indicated in Sender Reports issued by Net Station 1 on this RTP
session.

# of Net Station 1 Recv Jitter Alarms – The number of jitter alarms
indicated in Receiver Reports issued by Net Station 1 on this RTP
session.

# of Net Station 2 Send Jitter Alarms – The number of jitter alarms
indicated in Sender Reports issued by Net Station 2 on this RTP
session.

# of Net Station 2 Recv Jitter Alarms – The number of jitter alarms
indicated in Receiver Reports issued by Net Station 2 on this RTP
session.
[VOIP] RTP - High Jitter
The Expert generates the [VOIP] RTP –High Jitter alarm when the jitter
measured by the Expert for an RTP session exceeds the Max jitter (ms)
threshold at least once during the interval specified by the Period (ms)
threshold. These thresholds are found under the [VOIP] RTP – High jitter
(accessed by selecting Expert Options from the Tools menu).
NOTE: By default, the Period (ms) threshold is set to zero – High Jitter
alarms are generated each time the ongoing jitter value calculated by the
Expert for an RTP stream exceeds the threshold. However, if you find that
you are receiving too many RTP - High Jitter alarms, you can enable the
Period threshold to decrease the number of alarms generated. With the
Period threshold enabled, the Expert will only generate one alarm per Period.
Keep in mind, however, that if you do enable a Period, flags in the Decode
display for this Expert alarm will not correspond to the exact packet that
caused the alarm to be generated. Instead, they will correspond to the end of
the Period window in which the alarm was generated.
NOTE: Essentially, jitter measures the mean difference in inter-packet
spacing between a sending station and a receiving station. For example, if
Station A sends packets x and y at a spacing of 50 milliseconds and the
Expert captures the same packets x and y at a spacing of 80 milliseconds,
the Expert calculates jitter for this pair of packets as 30 milliseconds (the
difference in packet spacing from the sending station to the Expert). The
exact calculation performed by the Expert is somewhat more complicated
than this since packets are continuously arriving. See the Sniffer Voice
Operations manual for details.
The Expert maintains an ongoing measurement of jitter for each detected RTP
session on the network so that the value becomes a statistically smoothed
mean for all packets received. If the measured value for jitter exceeds the Max
jitter threshold (expressed in milliseconds) over the specified period, the
Expert generates the RTP – High Jitter alarm for the offending RTP session.
NOTE: This alarm is only generated if the Enable Calculation option for
RTP Inter-Packet Variation is disabled in the Tools > Expert Options >
VoIP Options tab. Otherwise, the RTP – High Variation alarm is used.
43
Chapter 1
How the "RTP – High Jitter" Alarm Differs from the "RTP – High
Variation" Alarm
Both the RTP – High Jitter and the RTP – High Variation alarms measure
essentially the same thing – the mean difference in inter-packet spacing
between a sending station and a receiving station. The crucial difference lies
in how jitter is calculated for the two alarms. The RTP – High Jitter alarm relies
on the timestamps in the RTP packets themselves to calculate inter-packet
spacing. In contrast, the RTP – High Variation alarm uses a custom Codec
Packet Interval specified in the Tools > Expert Options > VoIP Options tab
for RTP packets in the equations used to calculate and average the deviation
from the expected inter-packet spacing. See the Sniffer Voice Operations
manual for details.
How the "RTP – High Jitter" Alarm Differs from the "RTCP – Report
High Jitter" Alarm
Because the RTP – High Jitter alarm is based on the difference in inter-packet
spacing between a sending station and the Expert, the frequency of these
alarms will depend in part on how far physically the Expert PC is from the
sending station. This is also why the Expert generates the RTCP – Report
High Jitter and the RTP – High Jitter alarms differently. The RTCP – Report
High Rate alarm is based on RTCP Report packets issued by the endpoints
of an RTP connection. RTCP Report packets report the jitter seen between the
endpoints of the RTP connection. In contrast, the RTP – High Jitter alarm is
based on the jitter measured by the Expert between the sending station and
itself – a distance shorter than that between the two endpoints of the RTP
connection. For example, suppose the Expert PC is placed halfway between
RTP Station A and RTP Station B. Theoretically, the jitter measured for an
RTP session between these two stations will be less at the Expert PC than at
either of the endpoints (since the distance is less).
Decreasing the Frequency of High Jitter Alarms
In addition to setting the Max jitter (ms) and Period (ms) thresholds
differently, you can also prevent false positive High Jitter alarms by setting the
RTP Packet Gap (ms) option in the Tools > Expert Options > VoIP Options
tab to a lower value. This option tells the Expert to ignore inter-packet
variations that exceed the stated value when making jitter calculations. This
way, statistical anomalies are ignored, resulting in fewer false positives.
Alarm Display

44
Direction – The direction of the connection on which the high jitter was
observed (for example, [168.34.123.1] -> [168.34.123.2].

Threshold – The value of the Max jitter threshold when this alarm was
generated.

RTP Jitter – The last value measured for jitter by the Expert for this
RTP connection.

# of Net Station 1 -> Net Station 2 Alarms – The number of High
Jitter alarms generated for traffic from Net Station 1 to Net Station 2.

Jitter alarms generated for traffic from Net Station 2 to Net Station 1.
[VOIP] RTP - High Variation
The Expert generates the [VOIP] RTP – High Variation alarm when the jitter
measured by the Expert for an RTP session exceeds the Max variation (ms)
threshold at least once during the interval specified by the Period (ms)
threshold. These thresholds are found under the [VOIP] RTP – High variation
NOTE: By default, the Period (ms) threshold is set to zero – High Variation
alarms are generated each time the ongoing jitter value calculated by the
Expert for an RTP stream exceeds the threshold. However, if you find that
you are receiving too many RTP - High Variation alarms, you can enable the
Period threshold to decrease the number of alarms generated. With the
Period threshold enabled, the Expert will only generate one alarm per Period.
NOTE: The Expert maintains an ongoing measurement of variation for each
detected RTP session on the network. If the measured value for inter-packet
variation exceeds the Max variation threshold (expressed in milliseconds)
over the specified interval, the Expert generates the RTP – High Variation
alarm for the offending RTP session.
How the "RTP – High Variation" Alarm Differs from the "RTP – High
Jitter" Alarm
Both the RTP – High Variation and the RTP – High Jitter alarms measure
essentially the same thing – the mean difference in inter-packet spacing
between a sending station and a receiving station. The crucial difference lies
in how jitter is calculated for the two alarms. The RTP – High Variation alarm
uses a custom Codec Packet Interval specified in the Tools > Expert
45
Chapter 1
Options > VoIP Options tab for RTP packets in the equations used to
calculate and average the deviation from the expected inter-packet spacing. In
contrast, the RTP – High Jitter alarm relies on the timestamps in the RTP
packets themselves to calculate inter-packet spacing. See the Sniffer Voice
Operations manual for details.
NOTE: This alarm is only generated if the Enable Calculation option for
RTP Inter-Packet Variation is enabled in the Tools > Expert Options >
VoIP Options tab. Otherwise, the RTP – High Jitter alarm is used.

Direction – The direction of the connection on which the high
percentage of dropped frames was observed (for example,
[168.34.123.1] -> [168.34.123.2].

Threshold – The value of the Percentage of dropped packets
threshold when this alarm was generated.

RTP Variation (ms) – The measured variation that caused this alarm
to be generated. Because an alarm was generated, this value will be
higher than the Threshold value.

Variation alarms generated for traffic from Net Station 1 to Net Station
2.

Variation alarms generated for traffic from Net Station 2 to Net Station
1.
[VOIP] RTP - Too Many Dropped Packets
The Expert generates the [VOIP] RTP – Too Many Dropped Packets alarm
when the percentage of dropped packets in either direction on an RTP
connection exceeds the Percentage of dropped packets threshold at least
once during the interval specified by the Period (ms) threshold. These
thresholds are found under the [VOIP] RTP – Too Many Dropped Packets
NOTE: By default, the Period (ms) threshold is set to zero – Too Many
Dropped Packets alarms are generated each time the dropped packet
percentage calculated by the Expert for an RTP stream exceeds the
threshold. However, if you find that you are receiving too many RTP - Too
Many Dropped Packets alarms, you can enable the Period threshold to
decrease the number of alarms generated. With the Period threshold
enabled, the Expert will only generate one alarm per Period.
46
NOTE: The Real-Time Transport Protocol (RTP) provides end-to-end
delivery services for time-sensitive data, such as interactive audio and video.
A high number of dropped packets on an RTP connection can indicate
congestion and may negatively affect end-user performance of audio or
video applications.

Direction – The direction of the connection on which the high
percentage of dropped packets was observed (for example,
[192.168.1.1] -> [192.168.1.2].

Threshold – The value of the Percentage of dropped packets

Percentage of Drop Packets Count – The percentage of dropped
packets measured by the Expert for this session. Because an alarm
was generated, this value will be higher than the Threshold value.

# of Net Station 1 -> Net Station 2 Alarms – The number of Too Many
Dropped Packets alarms generated for traffic from Net Station 1 to Net
Station 2.

Dropped Packets alarms generated for traffic from Net Station 2 to Net
Station 1.
[VOIP] RTP - Too Many Out of Sequence Packets
The Expert generates the [VOIP] RTP – Too Many Out of Sequence Packets
alarm when the number of out of sequence packets in either direction on an
RTP connection exceeds the Max # of out of sequence packets threshold at
least once during the interval specified by the Period (ms) threshold. These
thresholds are found under the [VOIP] RTP – Too Many Out of Sequence
Packets alarm entry in the Alarms tab of the Expert UI Object Properties
dialog box (accessed by selecting Expert Options from the Tools menu).
NOTE: By default, the Period (ms) threshold is set to zero – Too Many Out
of Sequence Packets alarms are generated each time the number of out of
sequence packets seen by the Expert for an RTP stream exceeds the
threshold. However, if you find that you are receiving too many RTP - Too
47
Chapter 1
Many Out of Sequence Packets alarms, you can enable the Period threshold
to decrease the number of alarms generated. With the Period threshold
enabled, the Expert will only generate one alarm per Period.
NOTE: The Real-Time Transport Protocol (RTP) provides end-to-end
delivery services for time-sensitive data, such as interactive audio and video.
However, it does not guarantee delivery of packets in the same order as they
were sent. Instead, each RTP packet includes a sequence number so that a
receiving station can reconstruct the sender's sequence of packets, if
necessary. The Expert examines the sequence numbers of all packets on a
given RTP connection. If it detects that the number of out of sequence RTP
packets on a given connection (packets without consecutive sequence
numbers) exceeds the Max # of out of sequence packets threshold, it
Since RTP typically relies on UDP for its efficient transport, you may want to
examine the underlying UDP packets to understand why RTP packets are
being delivered out of sequence.
48

Direction – The direction of the connection on which the offending out
of sequence packets were observed (for example, [168.34.123.1] ->
[168.34.123.2].

Threshold – The value of the Max # of out of sequence packets

Out of Seq. Frame Count – The number of out of sequence packets
measured by the Expert for this session. Because an alarm was
generated, this value will be higher than the Threshold value.

Out of Sequence Packets alarms generated for traffic from Net Station
1 to Net Station 2.

Out of Sequence Packets alarms generated for traffic from Net Station
2 to Net Station 1.
[VOIP] SCCP - Register Reject
The Expert generates the [VOIP] SCCP – Register Reject alarm when it
observes a Skinny Client Control Protocol (SCCP) Station Register Reject
message.
The SCCP protocol allows simple IP telephony devices to operate without
implementing the entire H.323 specification. Instead, they can operate as
SCCP “skinny” clients and communicate with H.323 proxies (called Call
Managers in SCCP) to interact with H.323-compliant devices. When an SCCP
skinny client comes online, it sends a registration message (StationRegister)
to the Call Manager to announce its existence. The Call Manager can reject
the client's registration attempt with a Station Register Reject message.
When the Expert observes an SCCP Station Register Reject message, it
Possible cause:

The Station Register Reject message includes a short textual
description (up to 33 bytes) indicating both the reason the Call Manager
rejected the registration attempt and the ID of the requesting station.
[VOIP] SCCP - Station Alarm
The Expert generates the [VOIP] SCCP – Station Alarm alarm when it
observes a Skinny Client Control Protocol (SCCP) Station Alarm message.
The SCCP protocol allows simple IP telephony devices to operate without
implementing the entire H.323 specification. Instead, they can operate as
SCCP “skinny” clients and communicate with H.323 proxies (called Call
Managers in SCCP) to interact with H.323-compliant devices. When a skinny
client has an error condition to report to the Call Manager, it does so using the
SCCP Station Alarm message. The Station Alarm message includes a text
string of up to 80 characters indicating the nature of the error condition on the
skinny client.
Possible cause:

The Station Alarm message includes a short textual description (up to
80 characters) indicating the nature of the error condition being
reported to the Call Manager.
[VOIP] SIP - Client Error
The Expert generates the [VOIP] SIP – Client Error alarm when it detects a
failure response from a SIP server to a SIP client's request with a 4xx error
code. 4xx error codes indicate that the client should not retry the same request
without modification.
49
Chapter 1
The exact 4xx error code causing the alarm was one of the following:
50

(400) Bad Request – The request was not understood because of bad
syntax.

(401) Unauthorized – The request requires authentication.

(402) Payment Required – (Reserved for future use.)

(403) Forbidden – The server understood the request but refuses to
fulfill it, regardless of authentication.

(404) Not Found – The server does not believe that the user exists in
the domain specified in the Request-URI.

(405) Method Not Allowed – The specified method is not allowed for
the specified address.

(406) Not Acceptable – The resource identified in the request can only
generate responses unacceptable to the requester.

(407) Proxy Authentication Required – The request requires prior
authentication with a proxy.

(408) Request Timeout – The server could not provide a response
before the expiration indicated in the request.

(409) Conflict – The request could not be processed because of a
conflict with the requested resource.

(410) Gone – The requested resource is no longer available on the
server.

(411) Length Required – The server requires a length field for the
request.

(413) Request Entity Too Large – The request entity is larger than the
server will process.

(414) Request-URI Too Large – The Request-URI is larger than the
server will process.

(415) Unsupported Media Type – The server is refusing the request
because it is in a format not supported by the request resource.

(420) Bad Extension – The server did not understand a protocol
extension in the request.

(480) Temporarily Not Available – The called party's end system was
contacted but the called party is not currently available.

(481) Call Leg/Transaction Does Not Exist – Either the server
received a BYE request not matching any existing call leg or the server
received a CANCEL request not matching any existing transaction.

(482) Loop Detected – The request included a Via path containing
itself (that is, a loop).

(483) Too Many Hops – The request contained more hops than
allowed by the Max-Forwards field in the request header.

(484) Address Incomplete – The request contained an incomplete To
address or Request-URI.

(485) Ambiguous – The called party address indicated in the request
was ambiguous.

(486) Busy Here – The called party's end system was contacted but the
called party is not currently accepting additional calls.
The alarm display indicates the exact error code that caused the alarm.
[VOIP] SIP - Global Error
The Expert generates the [VOIP] SIP – Global Error alarm when it detects a
global failure response from a SIP server. Global failure responses include 6xx
error codes. SIP servers send global failure responses to indicate that they
have authoritative information that a particular user cannot be located or
contacted.

(600) Busy Everywhere – The called party's end system was contacted
but the called party is busy and will not take the call now. This response
is returned only if the client knows that no other endpoint will answer
the request. Otherwise (486) Busy Here is returned (causing the Expert
to generate the SIP – Client Error alarm).

(603) Decline – The called party's machine was contacted
successfully, but the user is explicitly declining participation.

(604) Does Not Exist Anywhere – The server has definitive information
that the called party does not exist anywhere.

(606) Not Acceptable – The called party's machine was contacted
successfully but some aspects of the session description were not
acceptable (for example, the requested media or bandwidth).
51
Chapter 1
[VOIP] SIP - Server Error
The Expert generates the [VOIP] SIP – Server Error alarm when it detects a
server failure response from a SIP server. Server failure responses include
5xx error codes. SIP servers send server failure responses to indicate that
they have experienced some sort of error. Client's receiving SIP server failure
responses typically reissue their requests to other SIP servers.

(500) Internal Server Error – The server experienced an internal error
that prevented it from servicing the request.

(501) Not Implemented – The server can not fulfill the request because
it does not provide the requisite functionality.

(502) Bad Gateway – The server received an invalid response from a
downstream server while attempting to service the request.

(503) Service Unavailable – The server is unable to service the
request due to temporary overloading or maintenance on the server.

(504) Gateway Timeout – The server did not receive a timely response
from a downstream server it accessed while attempting to service the
request.

(505) SIP Version not Supported – The server does not support the
version of SIP indicated in the request.
[VOIP] SIP - Server Slow Response
The Expert generates the [VOIP] SIP – Server Slow Response alarm when
the time it takes for a SIP server to respond to a client's request exceeds the
SIP Slow response time threshold. This threshold is found under the [VOIP]
SIP – Server Slow Response alarm entry in the Alarms tab of the Expert UI
Object Properties dialog box (accessed by selecting Expert Options from the
Tools menu).
Because all responses to a SIP request must use the same values in the
Call-ID, CSeq, To, and From fields, the Expert is able to match responses
from a SIP server to the corresponding request from a SIP client. When the
Expert sees a SIP request, it stores the timestamp when it captured the frame.
Then, when the Expert sees a corresponding response from the SIP server, it
calculates the delay between the last request from the client and the first
response from the server. If the value for this delay is greater than the SIP
Slow response time threshold (expressed in milliseconds), the Expert
generates the SIP – Server Slow Response alarm.
The alarm display includes the following information:
52

Threshold – The value of the SIP Slow response time threshold when
this alarm was generated.

Response Time – The response time measured by the Expert that
caused this alarm to be generated. This value will be higher than the
Threshold value.

Command – The type of SIP client request to which the server was
slow in responding. For example, INVITE.

Response code – The numerical response code returned by the SIP
server to the client's request. For description of all SIP response codes,
see RFC 2543 describing the SIP protocol.

Description – A short textual description of the response code
returned by the SIP server to the client's request.
File Retransmission
The Expert generates the File Retransmission alarm when it detects that an
entire file, or a subset of a file has been retransmitted. This differs from a
transport layer retransmission because the application is purposely
retransmitting the file. Each retransmission is counted as a separate alarm.
Possible causes:

The application is not using the network efficiently. Possibly, the
application was not designed to be used over networks.

It is possible that different data was written by the application with each
transmission. The data within the file is not checked.
Invalid Presentation Context ID
The Expert generates this alarm when it detects an invalid presentation
context ID on an RPC connection.
IP NETBIOS Session Reject
The Expert generates the IP NETBIOS Session Reject alarm when an
attempt to initiate a NETBIOS Session is rejected by the other half of the
connection.
Possible causes:

The receiving node is shutting down and cannot create a new NetBIOS
connection.

The receiving node was too busy to accept additional connections.
53
Chapter 1
Local Limit on Defined Context Set Exceeded
The Expert generates this alarm when it detects that the local limit on a defined
context set has been exceeded on an RPC connection.
Loops on Same Request
The Expert generates the Loops on Same Request alarm when it sees the
application process on one station send out the same request even though it
has already received the appropriate reply from the destination station. Only
requests that are sent within the time specified by the Filter time threshold are
considered “repeated.”
Possible causes:

This may be legitimate, depending upon the application. For example,
some print servers check for print requests every few seconds,
resulting in many repetitions of the same request. You can eliminate
this situation by lowering the Filter time threshold.

Particular applications may be inefficient. For example, some X
Windows applications continually check the location of the mouse
cursor, which can cause network traffic of this type.

Excessive repeated requests are characteristic of applications that do
not use the network efficiently, or that are not designed to be used over
networks.

If the request is a Novell NDS verb request, it may indicate the need to
partition the NDS tree among more servers. However, the verbs
DSV_Resolve_Name, DSV_Read, and DSV_Get_Server_Address are
often sent out as part of the NDS protocol.
Low Throughput
The Expert generates the Low Throughput alarm when the rate of throughput
(in KBytes/s) on a session is less than the minimum rate specified by the Local
Xfer threshold (for local transfers) or Remote Xfer threshold (for remote
transfers).
The expert system assumes that a transfer is local unless it has received a
Routing Information Protocol (RIP) packet indicating a non-zero hop count.
Some transfers that are indeed remote may be tentatively labeled as local,
because no RIP packets have been received by the analyzer since the
beginning of the current capture. Under these conditions the expert system will
use the Local xfer rather than the Remote xfer threshold. Since the Local
xfer threshold is characteristically set to a faster rate than the Remote xfer
54
threshold, it will be possible for a remote transfer to trigger this symptom
falsely. If you suspect that this is the case, then notice whether the symptom
has occurred within 30 seconds of the start of capture. RIP packets are sent at
30 second intervals, and therefore such false symptoms will not generally
occur after 30 seconds of capture.
Occasional instances of low throughput are generally not considered to be a
problem. When low throughput occurs often, you should try to determine the
cause.
Possible causes:

If more than one application has low throughput, and if this symptom
occurs for exchanges between different pairs of stations, then there is
a network problem, such as heavy traffic going through a router.

If more than one application has low throughput, and if this symptom
occurs primarily for exchanges between a particular pair of stations,
then there is a connection problem – the transport level communication
software is not properly configured.

If only one application has low throughput, then the problem is with that
application.

An excessive number of slow file transfers may be due to an
overloaded server. You should examine the traffic to your server to see
if the traffic is justified. If so, you should consider getting a faster server
or distributing the load across multiple servers.
Read/Write Overlap
The Expert generates the Read/Write Overlap alarm when read or write
requests to a file overlap each other. For example, if an application first wrote
bytes 50 through 700 and then wrote bytes 200 through 800, there would be a
write overlap because bytes 200-700 were written twice.
Request Denied
The Expert generates the Request denied alarm when the number of denied
requests on a session exceeds the Denied Count threshold. A request is only
counted as denied if it occurs within the time specified by the Filter time
threshold.
NOTE: The Filter Time threshold is located under the Alarm entry for Loops
on same request at the Session Layer. These alarms share the same
threshold.
55
Chapter 1
Possible causes:

This may be normal depending upon the application.

An excessive number of error responses may indicate a misconfigured
application.

The application may not have been designed for use over networks.

A password is wrong or the requester does not have the necessary
access privileges.

If the network is running Novell NDS, then the error response may be
an NDS verb error reply. Validate the NDS tree.
Slow File Transfer
The Expert generates the Slow File Transfer alarm when the percentage of
slow file transfers on a given session is greater than the Slow File Xfer %
threshold and the number of requests has exceeded the Min appl req
threshold.
Occasional instances of slow file transfer are generally not considered to be a
problem. If slow file transfers occur often, the cause should be determined.
Possible causes:

If more than one application exhibits slow file transfer and if this
symptom occurs for exchanges between different pairs of stations, then
there is a network problem, such as heavy traffic through a router.

If more than one application exhibits slow file transfer and if this
symptom occurs primarily in exchanges between a particular pair of
stations, then there is a problem with the connection – the transport
level communication software is not properly configured.

If only one application exhibits slow file transfer, then there is a problem
with that application.

An excessive number of slow file transfers may be due to an
overloaded server. You should examine the traffic to your server to see
if the traffic is justified. If so, you should consider getting a faster server
or distributing the load across multiple servers.
Temporary Congestion
The Expert generates this alarm when it detects that an RPC server is
experiencing temporary congestion.
56
The Operation Number Is Greater than the Number of Operations
in the Interface
The Expert generates this alarm when it detects that operation number passed
in the request PDU on an RPC connection is greater than or equal to the
number of operations in the interface.
The Output Parameters of the Operation Exceed Their Declared
Maximum Size
The Expert generates this alarm when it detects that the output parameters of
an RPC operation exceed their declared maximum size.
The Request Is Being Rejected for Unspecified Reasons
The Expert generates this alarm when it detects that a request on an RPC
connection was rejected for unspecified reasons.
The RPC Client or Server Protocol Has Been Violated
The Expert generates this alarm when it detects that the RPC client or server
protocol was violated.
The Server Did Not Support the Requested Authentication Level
The Expert generates this alarm when it detects an RPC server does not
support the authentication level requested by an RPC client.
The Server Does Not Export the Requested Interface
The Expert generates this alarm when it detects that an RPC server does not
support a requested interface.
The Server Does Not Implement the Requested Operation for the
Type of Requested Object
implement an operation requested by a client for the type of requested object.
The Server Does Not Support the Interface
support a requested interface.
57
Chapter 1
The Server Does Not Support the Proposed Transfer Syntax
support the transfer syntax proposed by a client.
The Server Does Not Support RPC Protocol Version
The Expert generates this alarm when it detects that a server does not support
the RPC protocol version specified in the bind PDU.
The Server Is Too Busy To Handle the Call
The Expert generates this alarm when it detects that an RPC server rejects a
request because it is too busy to handle the call.
The Server Manager Routine Has Not Been Entered and Executed
The Expert generates this alarm when it detects that the server manager
routine on an RPC server is not entered and executed when it should be.
TNS Connect Refused
The Expert generates the TNS Connect Refused alarm when the number
connect requests refused by an Oracle server exceeds the Oracle
Connection Failed threshold. A request to connect is refused by the server
because it is unable to satisfy the options asked for in the connect packet.
Examine the service options in the connect packet and determine whether
they are options that are allowed in the target server.
Check the data in the refuse packet and look for the error code given.
Refer to the Oracle manual containing the SQL*Net error codes.
Possible causes:

Invalid username.

Invalid password.

Invalid server.
TNS Security Breach Attempt
The Expert generates the TNS Security Breach Attempt alarm when the
number of failed login attempts exceeds the Oracle Security Breach Attempt
threshold. This may not be a problem if it does not continue.
58
An Oracle7 application usually terminates when it gets three occurrences of
this error type. However, this may not apply to user-written applications. Two
or more occurrences of this alarm should be investigated.
TNS Slow Connect
The Expert generates the TNS Slow Connect alarm when the time a server
or a Multiprotocol Interchange (MPI) takes to respond to a TNS Connect
Request or a login request exceeds the Oracle Slow Connect Time
threshold.
This may or may not be a problem, depending upon the application
environment. The Oracle Slow Connect Time threshold should be adjusted
to the desired or typical connect response time in your application
environment.
Possible causes:

The server is overloaded.

The MPI is too busy.

The server or MPI is misconfigured.
TNS Slow Server Diagnosis
The Expert considers an Oracle server's response to an SQL request to be
slow when the time between request and response is longer than the Oracle
Slow Server Response Time threshold. The Expert counts these slow
responses. When the total number of slow responses seen during the time
period specified by the Oracle Slow Server Response Interval threshold
exceeds the Oracle Slow Server Response Count threshold, the Expert
generates the TNS Slow Server Diagnosis alarm.
Possible causes:

bandwidth.

protocols.

59
Chapter 1

60

connections.

Add more MPIs.

drives.

Check for runaway (orphan) processes and clean up after them.
The problem is in the database. Perform database tuning suggested by

reparsing.

columns.

immediately.

TNS Slow Server Response
The Expert generates the TNS Slow Server Response alarm when the time
it takes for a server to respond to one or more SQL commands exceeds the
Oracle Slow Server Response Time threshold.
Possible causes:

bandwidth.

protocols.

connections.

Add more MPIs.

drives.

61
Chapter 1

immediately.

Check for runaway (orphan) processes and clean up after them.
The problem is in the database. Perform database tuning suggested by

reparsing.

columns.
Too Many File Retransmissions
The Expert generates the Too Many File Retransmissions alarm when the
percentage of file transfers that are retransmissions on a session exceeds the
File Retrans % threshold.
Possible cause:

62
This alarm indicates excessive retransmissions of the same file
request, or overlap between two file requests. This usually means that
the application is not using the network efficiently. If possible, the
application should be reconfigured (or rewritten) to make it more
efficient.
Too Many Loops on Same Request
The Expert generates the Too Many Loops on Same Request alarm when
the ratio of repeated requests (loops) to normal requests (expressed as a
percentage) on a session exceeds the Loop % threshold.
This alarm is only generated after the total number of application requests
seen by the analyzer exceeds the Min Appl Req threshold.
A repeated request is one that is sent out even though the proper response to
the previous request has already been seen by the analyzer. The analyzer
does not count certain repeated requests. For example, if a repeated request
is sent after the Filter time threshold expires, the analyzer “forgets” the
previous request and does not consider it to be repeated. A normal request is
any request that is not considered repeated.
Possible causes:

This may be legitimate, depending upon the application. For example,
some print servers check for print requests every few seconds,
resulting in many repetitions of the same request. You can eliminate
this situation by lowering the Filter time threshold.

Particular applications may be inefficient. For example, some X
Windows applications continually check the location of the mouse
cursor, which can cause network traffic of this type.

Excessive repeated requests are characteristic of applications that do
not use the network efficiently, or that are not designed to be used over
networks.

If the request is a Novell NDS verb request, it may indicate the need to
partition the NDS tree among more servers. However, the verbs
DSV_Resolve_Name, DSV_Read, and DSV_Get_Server_Address are
often sent out as part of the NDS protocol.
Too Many Requests Denied
The Expert generates the Too Many Requests Denied alarm when the
percentage of denied versus successful application requests on a session
object exceeds the Denied request %threshold.
This alarm is only generated after the total number of application requests
seen by the analyzer exceeds the Min Appl Req threshold.
Possible causes:

The application was not designed for use over networks.
63
Chapter 1

The application doesn't take into account that the responding
application is on a different station.

The application is waiting for a semaphore on a server that has not
been released.
WINS Duplicate Name
The Expert generates the WINS Duplicate Name alarm when it detects a
node attempting to register a duplicate node name with the WINS Server. Only
unique names can exist at a time on any given network.
Possible cause:

An existing machine's name has been changed or a new machine has
been added with a conflicting computer name. Use the Network control
panel to change one of the conflicting stations' computer name.
WINS No Response
The Expert generates the WINS No Response alarm when a station does not
respond to a WINS Request within the time specified by the WINS No
Response threshold.
Possible causes:
64

The Expert did not see the WINS response because the Expert is
connected to a switched network environment. Switches have the
effect of segmenting network traffic, preventing the Expert from seeing
all network traffic unless port mirroring is set up effectively. Because
the Expert never saw the response from the WINS Server, this alarm
was generated.

Connectivity to the WINS Server (the recipient of the WINS Request)
has temporarily been lost, or the WINS Server has shut down. WINS
packets use UDP as a transport. During periods of high network
activity, UDP packets can be lost. If there are multiple alarms naming
the same WINS Server, check the named WINS Server to make sure it
is properly connected to the network. Then, check the state of the
WINS Service by running WINS Manager.

The WINS configuration on the requesting client specifies an invalid
address for the WINS Server. Check the TCP/IP Settings in the
requesting client's Network control panel and correct them, if
necessary.
Connection Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Connection layer.
Ack Too Long
The Expert generates the Ack Too Long alarm when the time that it has taken
to acknowledge data on a connection exceeds the Long Ack Time threshold
plus three times the average acknowledgment time for this connection.
Possible causes:

The recipient of the original data frame was temporarily busy, and could
not process the frame as quickly as usual.

The ACK arrived late because a server had to look up and/or process
data before responding with an ACK.

The path changed in a way that increased the time between the request
and its acknowledgement.

There were multiple paths between the two stations, and the time to
acknowledgement was longer for some paths than for others.
Fast Retransmission
The Expert generates the Fast Retransmission alarm when both of the
following conditions for a connection are true:

The TCP sequence number is less than or equal to its previous value,
indicating that this frame contains data that has already been
transmitted.

The time between the duplicate transmissions is less than the Fast
retransmission time threshold.
Possible cause:

If the total amount of data to be retransmitted is relatively small, some
TCP applications will retransmit data that has not yet been
acknowledged. If this happens frequently, network bandwidth is being
wasted, and you should change to software that does not perform
unnecessary retransmissions.
65
Chapter 1
Idle Too Long
The Expert generates the Idle Too Long alarm when it sees a TCP or NFS
connection has been idle (no frames in either direction) for longer than the Idle
Time threshold. If the idle connection is still alive, it is reserving system
resources at both ends of the connection without using them.
Possible causes:

A station is inoperative.

A router has lost the connection.

The transport software has hung.

An application has hung.

An application is open but not in use.
Local Routing
The Expert generates the Local Routing alarm when it detects two DLC
stations on the same segment communicating via a router (packets are being
transmitted via the router rather than directly from one DLC station to the
other).
Possible causes:

The router table may be improperly configured. If this is the case,
reconfigure the router table so that the stations can communicate with
each other directly.

The router may be used for security purposes, to control access to
particular parts of the network.

The router may be performing gateway type functions, such as protocol
translation at the application level.

A device that is new to the network is sending frames through a router
because it has not yet become aware of the direct route to a local
station, or because it is configured to use that router.
Non-Responsive Station
The Expert generates the Non-Responsive Station alarm when the number
of consecutive retransmissions without a response on a connection exceeds
the No Response Count threshold.
66
Possible causes:
Retransmissions often indicate a problem with a server. Some examples are:

Improperly configured software.

An overloaded server.

Faulty hardware.
Repeat Ack
The Expert generates the Repeat Ack alarm when it sees a station send a
frame on a connection with the acknowledgment number less than its previous
value.
Possible cause:

Some implementations do this purposely to keep the circuit “alive”.
However, this is not good practice because it causes unnecessary
network traffic.
Retransmission
The Expert generates the Retransmission alarm when it sees a frame with a
TCP sequence number less than or equal to its previous value, indicating that
it contains data that has already been transmitted. The retransmission
occurred because the transmitting station did not receive an acknowledgment
(ACK) from the receiving station, and therefore retransmitted the frame.
Possible causes:

The receiving station was overloaded.

A router was overloaded, or there was some other propagation delay.

The network traffic load was very high.

The ACK was sent but lost.

Either the original packet or its ACK was damaged.

The ACK was transmitted via a slower path.

An IP fragment was lost.

There is a network integrity problem.
67
Chapter 1
Slow Server
The Expert generates the Slow Server alarm when the ratio of slow responses
to total responses for a particular station exceeds the Slow Response %
threshold. A slow response is one in which the time between request and
response is longer than the Response Time threshold.
Possible cause:

This usually means that your server is overloaded. You should examine
the traffic to your server to see if the traffic is justified. If so, you should
consider getting a faster server or distributing the load across multiple
servers.
TCP Fast Keepalive
The Expert generates the TCP Fast Keep-Alive alarm when the delta time
between the last packet seen on a TCP connection and a subsequent
keepalive is less than the TCP Fast Keep-Alive (msec) threshold.
In some legacy TCP implementations, stations send keepalives to the
opposite end of a connection when the connection has been idle for a set
amount of time. The purpose of sending a keepalive is to elicit a response from
the opposite end of the connection, thereby ensuring that the connection stays
alive. This alarm can help detect stations that are sending keepalives too
quickly, resulting in an inefficient use of network bandwidth. However, per RFC
1122, if you are still using a legacy implementation of TCP, you may want to
consider updating it because of the following drawbacks associated with
keepalives:

Established connections can break during short-lived network failures
(for example, due to temporary congestion) if a keepalive is sent during
the problematic period and the sending station receives no response.

Bandwidth can be consumed unnecessarily by keepalives.

On network paths that charge by the packet, excessive keepalives can
result in increased costs.
Most modern implementations of TCP do not use keepalives to keep
connections open. Instead, connections are closed when they are idle and
re-opened when data needs to be sent.
68
How The Expert Detects Keepalives
There is no explicit way to detect a TCP keepalive – they carry no telltale flag
or message ID. Instead, the Expert assumes that a TCP packet with a payload
of 0 or 1 bytes and the same sequence number as the last packet seen on the
connection (that is, a retransmission) is a keepalive. In earlier versions of the
Expert, the Expert flagged keepalives as retransmission alarms. In this
version, keepalives will not cause retransmission alarms, but they may result
in Fast Keep-Alive alarms, depending on their timing.
Disabling the TCP Fast Keep-Alive Alarm
If you find that too many TCP Fast Keep-Alive alarms are being generated on
your network, you can either increase the TCP Fast Keep-Alive (msec)
threshold to a value that makes more sense for your network or disable the
alarm entirely by setting the threshold to zero.
Too Many Retransmissions
The Expert generates the Too Many Retransmissions alarm when the number
of retransmissions on a connection (expressed as a percentage of good
transmissions versus retransmissions on the connection) exceeds the
Retransmission % threshold. Excessive retransmissions can result in a
noticeable reduction in response time.
Retransmissions occur when the transmitting station does not receive an
acknowledgment (ACK) from the receiving station, and therefore retransmits
the frame.
Possible causes:

The receiving station was overloaded. This is particularly likely if the
receiving station was a server.

A router was overloaded, or there was some other source of
propagation delay.

The network traffic load was very high.

The ACKs were being transmitted via a slower path.

There is a network integrity problem.
UDP Bouncing Frames
The Expert generates the UDP Bouncing Frames alarm when it detects UDP
bouncing frames on a connection. A bouncing frame is one in which the IP
layer's time-to-live field has decreased by one from its previous value. It
usually indicates that a frame has entered the local network through a router,
but the intended recipient of the frame cannot be found.
69
Chapter 1
If this happens very often, the cause should be discovered and eliminated. The
intended recipient, probably on another network, may not be operating
properly as a result of this routing error.
Possible cause:

There is a misconfigured router or routers. Examine the routing table(s)
and correct them if necessary.
Window Frozen
The Expert generates the Window Frozen alarm when it sees a connection
using a windowing protocol (such as DECnet or TCP) for which the window
size has been stuck at some number of bytes for longer than the Window
Frozen Time threshold.
When a window is stuck, data flow will not be as efficient because the
transmitter will not send data in excess of the current window size.
Possible causes:

There is insufficient buffer space, because the recipient's memory
allocation process is not providing enough buffer memory.

There is insufficient buffer space, because there are new open
connections, so that the buffer space must be shared.
Window Size Exceeded
The Expert generates the Window Size Exceeded alarm when it sees a frame
whose TCP data size exceeds the current TCP window size of the receiving
end of this connection. Most TCP implementations will ignore this frame.
However, if this happens very often, network bandwidth is being wasted.
Possible causes:

This situation may occur occasionally if the window has just decreased
before the transmitter has had a chance to notice.

An incorrect implementation may be ignoring the window size or the
maximum segment size.
Zero Window Too Long
The Expert generates the Zero Window Too Long alarm when it detects a
connection using a windowing protocol (such as DECnet or TCP) where the
window size for a station has been zero longer than the time specified by the
Zero Window Time threshold.
70
Possible causes:

The receiving station is very busy.

There are insufficient network buffers in the receiving station.

This is an indirect result of an application program behavior. For
example, the application may be waiting for some other event to
happen, or the application might not be releasing the frame buffer.

An application is very slow.

A fast station is overwhelming a slow one.
71
Chapter 1
Station Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Station layer.
Duplicate Network Address
The Expert generates the Duplicate Network Address alarm when it frames
from more than one DLC address with the same network address.
If the DLC source addresses are not routers, there is a serious error condition
that could cause unpredictable and potentially destructive results. Check the
configuration of the network stations and change one of the network
addresses.
Possible causes:

Someone has assigned a new network address without checking the
existing network addresses to assure that the assignment is unique.

The network addresses are being dynamically allocated, or in some
other way are being chosen by software, and the software is not
assigning them properly.

Someone has copied another station's configuration file, and has
neglected to change the network address.

If the DLC addresses differ in only one or two bit positions, and the
number of frames associated with one of the DLC address is very
small, then there may be a defective network adapter.
If the DLC addresses are routers, this is not a problem. This alarm was
triggered because the expert system has not yet identified the duplicate
addresses as routers.
The expert system learns about routers with the help of Routing Information
Protocol (RIP) packets. If the expert system has not seen any RIP packets
from a given DLC address since the beginning of the capture, it will assume
that the address is that of an ordinary station rather than a router. RIP packets
occur at 30 second intervals. If a RIP packet is not detected, it is either
because 30 seconds have not elapsed, or because this segment of the
network does not broadcast RIP packets.
72
Duplicate PDC Name Registration
The Expert generates the Duplicate PDC Name Registration alarm when it
detects a node attempting to initialize using the name of a Primary Domain
Controller that is already running. Microsoft networks can have only a single
Primary Domain Controller in a given domain. However, there can be multiple
Backup Domain Controllers in a single domain.
Possible cause:

A PC has been added to the network that was configured offline or that
was cloned from an existing PC. Change the listed PC to become a
BDC for the domain or a PDC for another domain.
ICMP Destination Unreachable
The Expert generates the ICMP Destination Unreachable alarm when a
station receives an ICMP destination unreachable message.
Possible causes:

This message is usually sent by a router, and may indicate a routing
table problem. Examine the RIP information.

If the RIP packets are not occurring at 30 second intervals, there may
be an unstable condition on the network.

The destination network does not exist.

The request is “administratively disallowed” because the requester
does not have the necessary access privileges.

The station sending this packet may have a misconfigured netmask.
ICMP Host Unreachable
The Expert generates the ICMP Host Unreachable alarm when a station
receives an ICMP host unreachable message.
Possible causes:

The station that sent the message has received a frame with an
unknown destination address.

The requested service is not available from the station that sent the
message.

73
Chapter 1
The situation can be investigated further by PINGing another host on the same
segment as the one that sent the 'host unreachable' message.
ICMP Inconsistent Subnet Mask
The Expert generates the ICMP Inconsistent Subnet Mask alarm when the
subnet mask in an ICMP address mask reply message does not match any of
the subnet masks known to the Expert.
Possible causes:

The subnet mask is legitimate, but is not known to the Expert. Select
the Expert Options command from the Tools menu. In the dialog box
that appears, use the Subnet Masks tab to add known subnet masks
to the Expert.

The mask is not legitimate. This problem should be resolved
immediately. Otherwise serious routing problems can result.
ICMP Net Unreachable
The Expert generates the ICMP Net Unreachable alarm when a station
receives an ICMP network unreachable message.
Possible causes:

This message is usually sent by a router, and may indicate a routing
table problem. Examine the RIP information.

If the RIP packets are not occurring at 30 second intervals, there may
be an unstable condition on the network.

The destination network does not exist.

The station sending this packet may have a misconfigured netmask.
ICMP Parameter Problem
The Expert generates the ICMP Parameter Problem alarm when it sees a
station send an ICMP message indicating a parameter problem.
74
ICMP Port Unreachable
The Expert generates the ICMP Port Unreachable alarm when a station
receives an ICMP port unreachable message. The message indicates that this
station previously transmitted a frame to a port. The station that sent the port
unreachable message is saying that the port cannot be accessed by the
requesting station.
Possible causes:

The requested service is not implemented or not active on the station
that sent the message, or is in use.

ICMP Redirect for Host
The Expert generates the ICMP Redirect for Host alarm when a station
receives an ICMP redirect message with the Code value set to 1 (redirect
datagrams for the host). The Code value specifies to which datagrams this
redirect message replies. The value of 1 indicates that datagrams sent to this
host in the future should use the new route suggested by the router in the
redirect message.
Possible cause:

A router may have sent the message to inform this station that a better
route exists to its intended destination. This is not usually a problem,
but it might be helpful to understand why one route is better than
another.
ICMP Redirect for Network
The Expert generates the ICMP Redirect for Network alarm when station
receives an ICMP redirect message with the Code value set to 0 (redirect
datagrams for the network). The Code value specifies to which datagrams this
redirect message replies. The value of 0 indicates that datagrams sent to this
network in the future should use the new route suggested by the router in the
redirect message.
NOTE: Because subnets are extensively used in most networks today, code
0 is not often used anymore (subnets create an ambiguity about the subnet
mask to be used to interpret a redirect for network message). Most hosts
receiving an ICMP redirect with the Code value set to 0 simply treat the
redirect as if it included the Code value 1 (redirect datagrams for host).
75
Chapter 1
Possible cause:

A router may have sent the message to inform this station that a better
route exists to its intended destination. This is not usually a problem,
but it might be helpful to understand why one route is better than
another.
ICMP Source Quench
The Expert generates the ICMP Source Quench alarm when a station
receives an ICMP source quench message.
Possible causes:

A congested router may have sent the message to inform this station
to reduce its rate of frame transmission.

The station that sent the source quench message may have a full buffer
or some other kind of processing bottleneck. Transmit more slowly.

The station that sent the message may be down or rebooting.

The station that sent the message may have received an excessive
number of bad frames.
IP Fragment Missing
The Expert generates the IP Fragment Missing alarm when it sees that an IP
fragment on an NFS connection has been lost. This will usually result in an
NFS layer retransmission.
When the maximum transmission size (MTS) on one side of a router is
different from the MTS on the other side, the router sometimes has to break
the frame up into fragments. In such a case, the router assigns sequential
numbers to the fragments – for example, 1 of 3, 2 of 3, 3 of 3. The “IP fragment
missing” alarm is generated when one or more of these fragments fails to
arrive at its destination.
Possible causes:

Heavy LAN traffic.

Multiple paths between the endpoint stations.
IP Fragment Out of Order
The Expert generates the IP Fragment Out of Order alarm when it sees an
IP layer fragment on an NFS connection that is not in sequential order.
76
When the maximum transmission size (MTS) on one side of a router is
different from the MTS on the other side, the router sometimes has to break
the frame up into fragments. In such a case, the router assigns sequential
numbers to the fragments – for example, 1 of 3, 2 of 3, 3 of 3. The “IP fragment
out of order” symptom is generated when one or more of these fragments
arrive at their destination in a different sequence.
This is not necessarily a problem, but it does indicate a condition that could
become a problem under heavy LAN traffic conditions.
Possible cause:

There may be multiple paths between the endpoint stations.
Misdirected Frame
The Expert generates the Misdirected Frame alarm when it sees a station
send a large number of frames in which the IP destination address is not on
the local subnet and the DLC destination address is not that of a router
advertising a route to the IP destination.
Possible causes:

This station does not know what subnet it is attached to.

This station is using expired or canceled routes.

A protocol other than RIP is being using to circulate routing information.

The analyzer has not been configured properly to know its own subnet
address or addresses, and the automatic mechanism that the analyzer
uses to find these addresses has not been able to correct the problem.
Multiple Routers to Local
The Expert generates the Multiple Routers to Local alarm when the number
of routers used to access a local station exceeds the Multiple Local Routers
threshold.
NOTE: The characterization of the network station as local is tentative. The
expert system assumes that a station is local unless it has received a
Routing Information Protocol (RIP) packet indicating a non-zero hop count to
that station.
77
Chapter 1
Possible causes:

The router configurations may be incorrect. Resolve this by checking
the router tables.

The existing configuration may be legitimate. Multiple routers are
sometimes used for security purposes, or to provide fault-tolerant
network connections.

There may be a duplicate network address shared by one of the routers
and a local station.

For VINES-IP networks this is not a problem. This symptom can help
you see just how many paths are being used to reach a local node. If,
after running the analyzer for several hours, the number of routers
suddenly increases, then the network could be reacting to change.
Multiple Routers to Remote
The Expert generates the Multiple Routers to Remote alarm when the
number of routers used to access a remote station exceeds the Multiple
Remote Routers threshold.
Possible causes:

The router configurations may be incorrect. Resolve this by checking
the router tables.

The existing configuration may be legitimate. The redundant paths may
have been set up deliberately to increase fault tolerance or to improve
response time.
NOTE: For VINES-IP networks this is not a problem. This alarm can help you
see just how many paths are being used to reach a remote node. If, after
running the analyzer for several hours, the number of routers suddenly
increases, then the network could be reacting to change.
Route Flapping
The Expert generates the Route Flapping alarm when it sees a router change
one or more routes from valid to invalid and back too frequently. This alarm is
generated if more than four such changes are made to any route in one
minute.
Possible cause:

78
There is an intermittent problem with the communication line. This
causes links to fail and come back up.
Router Not Updating Routes
The Expert generates the Router Not Updating Routes alarm when it sees a
router let more than half of its advertised routes expire without confirmation.
Possible causes:

The router has crashed or reset.

The router has been turned off.

The router has been disconnected from this subnet.

This router was reconfigured and no longer knows about its connection
to this subnet.
Router Storm
The Expert generates the Router Storm alarm when it sees a router
reconfirming one or more of its routes more frequently than the Router Storm
threshold.
Possible causes:

The router software is sending its routing table more often than it
should, possibly in response to external changes in the topology of the
network.

The routing updates are legitimate, but the routing software happened
to pick several random update times that were at the minimum end of
the range. This cause is likely if this diagnosis is isolated and of short
duration.
Router Superseded Too Frequently
The Expert generates the Router Superseded Too Frequently alarm when it
sees a router changing the metrics on one or more routes too frequently. The
analyzer generates this alarm if any route changes between being the best
route to its destination and not being the best route too frequently.
Possible causes:

There is an intermittent problem with the communication line. This
causes links to fail and come back up.

The network topology is changing, causing the metric of several routes
to change.
79
Chapter 1
Server Running BDC Shutting Down
The Expert generates the Server Running BDC Shutting Down alarm when
it sees a node acting as a Backup Domain Controller shut down. This alarm is
only generated if a WINS Release packet is seen from the node that is shutting
down.
Possible cause:

The server operating as the BDC was shut down. This can affect the
ability of clients to log in to the network using accounts managed by this
controller. Both accounts in the local domain and accounts in remote
domains managed by the controller using Pass-Through Authentication
could be affected.
Server Running PDC Shutting Down
The Expert generates the Server Running PDC Shutting Down alarm when
it sees a node acting as a Primary Domain Controller shut down.
Possible cause:

The server operating as the PDC was shut down. If there is no other
local Domain Controller (for example, a backup domain controller), the
ability of clients to log in to the network using accounts managed by this
controller could be affected. Both accounts in the local domain and
accounts in remote domains managed by the controller using
Pass-Through Authentication could be affected.
Server Running WINS Shutting Down
The Expert generates the Server Running WINS Shutting Down alarm when
it sees a WINS Server shut down. This alarm is only generated if a WINS
Release packet is seen from the node that is shutting down.
WINS service for clients will be disrupted as they transition from the named
WINS Server to an optionally configured backup. Backup WINS Servers for
clients are configured using the properties sheet for the TCP/IP protocol in the
Network Control Panel. This alarm is only generated if a WINS Release packet
is seen from the node that is shutting down.
It is normal to see a burst of WINS No Response alarms after this alarm.
Possible cause:

80
The server running the WINS Service shut down.
Source Address Is Broadcast
The Expert generates the Source Address Is Broadcast alarm when it
detects a frame with the source address field set to a broadcast address. A
source address should not be a broadcast address.
Time-to-live Exceeded in Transmit
The Expert generates the Time-to-live Exceeded in Transmit alarm when a
station receives an ICMP Time Exceeded message. The time-to-live field of
the IP layer has reached zero (or the fragmentation reassembly time has been
exceeded). Therefore, the frame has been discarded.
Possible cause:

If the time-to-live field has reached zero, it usually indicates that there
is a routing table error somewhere in the network, but not necessarily
on this local network. Try to locate the source of the original frame.

If the fragmentation reassembly time has been exceeded, it usually
indicates that a frame has been lost.
Time-to-live Expiring
The Expert generates the Time-to-live expiring alarm when it sees an IP
frame with a time-to-live field set to 0 or 1, indicating that the frame is about to
expire.
Possible cause:
If the time-to-live field has reached zero, it usually indicates that there is a
routing table error somewhere in the network, but not necessarily on this local
network. Try to locate the source of the original frame.
Zero Broadcast Address
The Expert generates the Zero Broadcast Address alarm when it sees an IP
frame with an all-zero broadcast address sent.
Possible cause:

This is an obsolete form of TCP/IP broadcast address. It should not be
used, because it can cause compatibility problems with stations that
use all-ones broadcast addressing.
81
Chapter 1
DLC Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the DLC layer. Alarms
are organized alphabetically and are described with their corresponding
thresholds (if any).
Abort Delimiter Transmitted
The Expert generates the Abort Delimiter Transmitted alarm when it detects
an “Abort delimiter transmitted” MAC condition.
Possible cause:

This alarm can be caused by a faulty adapter. If this occurs frequently,
check the adapter on the reporting station.
AC Errors
The Expert generates the AC Errors alarm when the NAUN (Nearest Active
Upstream Neighbor) is unable to set the FCI (frame copied indicator) and ARI
(address recognized indicator) bits in a frame it has copied.
Burst Errors
The Expert generates the Burst Errors alarm when it detects a signaling error
in the cable. Note that this error is not caused by a station entering or leaving
the ring – although the MAC protocol reports burst errors that occur when a
station enters or leaves the ring, such errors are filtered by the Expert system,
and do not trigger this alarm.
Possible cause:

There is probably a cabling problem. Check the fault domain.
Collision after 64 Bytes
The Expert generates the Collision after 64 Bytes alarm when it sees a
collision taking place after 64 bytes of a frame have already been received.
DLC Source Address Broadcast
The Expert generates the DLC Source Address Broadcast alarm when it
sees a frame with the source DLC address field set to a broadcast address.
82
Possible causes:

The frame has been corrupted, possibly as a result of a collision or a
malfunctioning station. If the problem recurs, look for a defective cable,
transceiver, or network interface board.

Source routing is being used, but the Expert is currently configured to
disable interpretation of the RI bit.

The DLC address is a mistake. Examine the surrounding frames for
clues as to which DLC station sent this frame. Isolate the offending
station by eliminating other known stations. When you have located the
offending station, change the DLC address or remove that station from
the network. Changing the DLC address may require replacing the
network adapter.
DLC Source Address Multicast
The Expert generates the DLC Source Address Multicast alarm when it sees
a frame with the source DLC address field set to a multicast address.
Possible causes:

The frame has been badly garbled, possibly as a result of a collision or
a malfunctioning station. If the problem recurs, look for a defective
cable, transceiver, or network adapter board.

The DLC address is a mistake. Examine the surrounding packets for
network adapter.
Duplicate Address Found
The Expert generates the Duplicate Address Found alarm when it sees an
affirmative response to the Duplicate Address Test MAC frame (another
station on the ring has the same address). This is a token ring alarm.
When the DLC address of the station trying to enter the ring is the same as the
DLC address of a station already in the ring, the station trying to enter is
automatically disconnected. That station should change its DLC address, and
then try again to enter the ring. Changing the DLC address may require
changing the network adapter.
83
Chapter 1
FCI and ARI Bits Mismatch
The Expert generates the FCI and ARI Bits Mismatch alarm when it sees a
frame whose FCI (frame copied indicator) and ARI (address recognized
indicator) bits have contradictory values. They should both be either 0 or 1.
Possible cause:

The destination station is overloaded and is losing frames.

The destination station's adapter board has a problem.
FDDI Ring Wrap
The Expert generates the FDDI Ring Wrap alarm when it sees an SMT
Neighbor Information Frame (NIF) with both the Rooted Station and the Peer
Wrap bits in the Station State parameter set to true.
All nodes on an FDDI ring transmit NIF frames to their downstream neighbors
at regular intervals, enabling all nodes to determine the MAC addresses of
their upstream and downstream neighbors. NIF frames include various
parameters identifying the sending station, including the Station State
parameter. This parameter includes two bits crucial to the generation of the
FDDI Ring Wrap alarm, as follows:

Rooted Station – If the Rooted Station bit is set to true, the sending
station is a dual-attached part of the main FDDI ring and not a
single-attached branch of a tree topology connected via a concentrator.

Peer Wrap – If the Peer Wrap bit is set to true, the sending station is
currently wrapping the primary and secondary rings due to a fault in the
network.
FDDI networks use two counter-rotating rings (called primary and secondary).
This design increases reliability by providing a certain amount of fault
tolerance. Dual-attached nodes connect to both rings. The primary ring carries
the data traffic while the secondary ring serves as the redundant path. When
a dual-attached station detects a fault on the primary ring, it attempts to route
the data around the fault by wrapping the primary and secondary rings. This
provides a way to get packets to a destination beyond the point of the fault by
sending them in the reverse direction. The Expert generates the FDDI Ring
Wrap alarm when this condition is detected.
Possible causes:

84
The adjacent station is off.
The station adjacent to the wrapped station was previously active, but
now the status is “Removed.” Check the adjacent station to verify that
it has been powered off. If the station is on, then it is possibly a link
problem (see below).

The adjacent link is down.
If the station adjacent to the wrapped station is active, the problem is
probably with the link. If the adjacent station is functioning normally,
check both ends of the link for problems. It may be necessary to replace
the link with a known good cable.

SMT reporting incorrect information.
Although the station is reporting that it is wrapped, if the adjacent
station and the link are operating normally, then it may be an SMT
problem on the station. You may have a faulty SMT implementation.
Frame Has Alignment Problem
The Expert generates the Frame Has Alignment Problem alarm when it
captures a frame with an alignment error. A frame has an alignment error when
its length is not a multiple of 8 bits, and therefore cannot be unambiguously
resolved into bytes.
Frame-Copied Errors
The Expert generates the Frame-Copied Errors alarm each time the token
ring adapter (while in receive/repeat mode) receives a frame addressed to it
with the address recognized bits (ARI) not set equal to 00.
Possible causes:

A line hit has occurred.

There may be a duplicate address on the network.
Frequency Errors
The Expert generates the Frequency Errors alarm when a station on the ring
detects a frequency error. Frequency errors occur when the token ring adapter
detects that its ring clock and the crystal clock differ by an excessive amount.
The error causes the adapter to enter the monitor contention process.
High Rate of Line/Burst Errors
The Expert generates the High Rate of Line/Burst Errors alarm when the
number of ring line errors plus burst errors (reported by the MAC protocol) for
a particular station exceeds the Line/Burst Errors Count threshold.
85
Chapter 1
Possible cause:

A large number of these errors may indicate a hardware problem.
Check the fault domain.
High Rate of Physical Errors
The Expert generates the High Rate of Physical Errors alarm when the rate
of physical errors per second detected for a particular station exceeds the rate
specified by the Physical Errors threshold.
Physical level errors can include:

Short frames (runts)

Bad CRCs

Lost frames

Oversize frames
Possible causes:

A defective cable

An excessively long cable

Electrical noise on a cable

Crosstalk

A defective board (if the error is on the “out” counter)

A faulty router, repeater, or gateway device.
Examine the detail screen and look for patterns. Make notes as to which DLC
stations are involved, and how frequently the errors occur. Compare this data
with previous records if any are available.
High Rate of Receiver Congestion Errors
The Expert generates the High Rate of Receiver Congestion Errors alarm
when the number of Receiver Congestion MAC frames sent in one minute (as
reported by the MAC protocol) exceeds the Receiver Congestion Error
Count threshold.
Possible cause:

86
The transport level software in the receiving station is not providing its
receive buffers fast enough.
High Rate of Ring Purge Diagnosis
The Expert generates the High Rate of Ring Purge Diagnosis alarm when
the rate of physical ring purges per minute detected exceeds the rate specified
by the Ring Purge Diag Count threshold.
Possible causes:

A lost token is usually the result of a station entering or leaving the ring,
or some other physical configuration change.

Too many ring purges may indicate faulty hardware. Check the fault
domain.
Invalid Frame Status Field
The Expert generates the Invalid Frame Status Field alarm when the FCI
(frame copied indicator) and ARI (address recognized indicator) bits occur
twice in the Frame Status field (because this field is not protected by the frame
check sequence). This alarm occurs when 2 ARI or 2 FCI bits are not equal.
An alarm is also generated when the FCI is set to 1 and the ARI to 0 because
this combination indicates that no ring station recognized the address but the
frame was copied.
Line Errors
The Expert generates the Line Errors alarm when it detects an invalid
character in a frame or token, or a Frame Check Sequence (FCS) error in a
frame.
Possible causes:

Unless these errors are frequent, they are most likely caused by a
reconfiguration of the ring. No remedial action is required.

There is a hardware problem. Check the fault domain.

There is crosstalk from voice traffic.

A bridge copied the data incorrectly.
Local Station with Route Designator
The Expert generates the Local Station with Route Designator alarm when
it detects a frame that indicates source routing is being used, but the source
and destination stations are both on the same local ring.
87
Chapter 1
Lost Frame Errors
The Expert generates the Lost Frame Errors alarm each time the token ring
adapter (while in transmit/stripping mode) transmits a frame and fails to
receive the end of the transmitted frame before the physical trailer timer
expires. As a result, the active monitor issues a new token.
If this error occurs, there should be Soft Error MAC frames from the other
station indicating Line errors, Burst errors, or Lost frame errors
Multiple Local Ring Definition
The Expert generates the Multiple Local Ring Definition alarm when it
detects that source routing is being used. The routing information in two or
more frames is contradictory – that is, two frames have different definitions of
the local ring number.
Possible cause:

There is a configuration problem. For example, a device may have
assumed that the local ring number is 1, rather than asking the ring
parameter server.
New Active Monitor
The Expert generates the New Active Monitor alarm when the active monitor
on the ring changes.
Oversized Frame
The Expert generates the Oversized Frame alarm when it captures an
Ethernet packet whose length is greater than 1518 bytes.
Receiver Congestion Errors
The Expert generates the Receiver Congestion Errors each time it sees a
Receiver Congestion MAC frame. Receiver congestion occurs when a station
does not have enough room in its buffer to copy a frame for which it is the
destination.
Possible cause:

88
The transport level software in the receiving station is not providing the
receive buffers fast enough.
Returned to Ring
The Expert generates the Returned to Ring alarm when it sees a station
reenter the ring after having left the ring. A new alarm is generated each time
the station returns to the ring.
Ring Beaconing
The Expert generates the Ring Beaconing alarm when it sees a station
transmit a Beacon MAC frame in an attempt to bring the ring back into normal
operation.
Possible causes:

There is a physical break in the ring (signal loss). Check the fault
domain.

A timeout has occurred during monitor contention.

A station with a card set to the wrong data rate has attempted to enter
the ring.
Ring Purge Symptom
The Expert generates the Ring Purge Symptom alarm when the rate of
physical ring purges per minute detected exceeds the rate specified by the
Ring Purge Symptom Count threshold.
The active monitor sends a ring purge frame when it detects that the token has
been lost. They are part of normal token ring behavior. However, an excessive
amount of ring purge frames on the network can indicate potential hardware
problems.
NOTE: When the Ring Purge Symptom Count threshold is exceeded, the
Expert generates a symptom. The Expert generates a diagnosis when the
Ring Purge Diag threshold is exceeded.
Possible causes:

A lost token is usually the result of a station entering or leaving the ring,
or some other physical configuration change.

Too many ring purges may indicate faulty hardware. Check the fault
domain.
89
Chapter 1
Runt Frame
The Expert generates the Runt Frame alarm when it detects a frame that ends
short of the DLC address fields.
A short frame can propagate through concentrators and produce more short
frames through collisions. If you see a lot of short frames, all without source
addresses, try to isolate the source. It may be necessary to physically unplug
stations that you suspect are giving rise to these short frames.
Possible causes:

A damaged or defective cable.

A bent or stapled cable that is producing reflections.

Electrical interference. For example, a cable may be lying on a
fluorescent fixture or close to an electrical motor.
Same Source and Destination Address
The Expert generates the Same Source and Destination Address alarm
when it detects a frame with the same DLC source and destination address.
Station Internal Errors
The Expert generates the Station Internal Errors alarm when a station
experiences a recoverable internal error. If the station is reporting multiple
internal errors, the station is marginal.
Station Off Ring
The Expert generates the Station Off Ring alarm when it sees a station leave
the ring, either purposely or due to a ring problem. If it is due to a ring problem,
there will be other ring errors. This symptom is most significant if it occurs for
a highly utilized station. A new symptom is generated each time the station
leaves the ring.
Station Removed
The Expert generates the Station Removed alarm when the configuration
report server asks a station to leave the ring.
90
Token Errors
The Expert generates the Token Errors alarm when the token has been lost.
This error should only be generated by the active monitor when it recognizes
the need to create a new token. If this error occurs, there should be Soft Error
MAC frames from the other station indicating Line errors, Burst errors, or Lost
frame errors.
Too Many Removes
The Expert generates the Too Many Removes alarm when the number of
“remove ring station” requests made by the configuration report server
(reported by the MAC protocol) exceeds the Station Removed Request
Count threshold.
Too Many Returns
The Expert generates the Too Many Returns alarm when the number of ring
reentries for a particular station in a minute exceeds the Station Ring Entry
Count threshold.
Zero MAC Address
The Expert generates the Zero MAC Address alarm when it detects a frame
with a MAC address of all zeroes in either the source or destination address
field. Examine the Decode display to determine whether the offending address
was in the source or destination field.
Possible causes:

There is a hardware problem, possibly related to an adapter whose
flash memory has been zeroed.

There is a device driver defect.

Some PC card drivers allow the MAC addresses of their adapters to be
customized. A user may have replaced the original MAC address of the
offending adapter with a custom address of all zeroes.

The frame containing the offending address has been corrupted,
possibly as a result of a collision or a malfunctioning station. If the
problem recurs, look for a defective cable, transceiver, or network
interface board.
91
Chapter 1

The DLC address is a mistake. Examine the surrounding frames for
network adapter.
WAN Connection Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the WAN Connection
layer. Alarms are organized alphabetically and are described with their
Backward Congestion
The Expert generates the Backward Congestion alarm when the percentage
of the total bytes sent from the network to the user in the last second in frames
with the BECN bit set to true exceeds the FR Backward Congestion %
threshold in the Expert UI Object Properties dialog box.
Exceeded CIR
The Expert generates the Exceeded CIR alarm when the number of bits
transmitted from the user to the network within the last second exceeds the
Committed Information Rate (CIR) for this PVC.
This alarm is only generated if the CIR for the PVC is known and is not set to
zero.
Forward Congestion
The Expert generates the Forward Congestion alarm when the percentage
of the total bytes sent from the network to the user in the last second in frames
with the FECN bit set to true exceeds the FR Forward Congestion %
threshold in the Expert UI Object Properties dialog box.
PVC Activation
The Expert generates the PVC Activation alarm when the PVC Status
information element's Active bit changes from false to true (0 to 1).
PVC Bandwidth Change
On some Frame Relay networks, the bandwidth assigned to each PVC is
reported in the PVC Status information element. The Expert generates the
PVC Bandwidth Change alarm when this reported value changes.
92
PVC Congestion
The Expert generates the PVC Congestion alarm when it sees a PVC Status
Information element sent by the network with the Receiver Not Ready bit set
to true. Some Frame Relay networks do this to inform the user side of
congestion.
PVC Deactivation
The Expert generates the PVC Deactivation alarm when the PVC Status
information element's Active bit changes from true to false (1 to 0).
PVC Deletion
The Expert generates the PVC Deletion alarm in either of the following cases:

A full status report was seen without an entry for the indicated DLCI
(and there was an entry for the DLCI in the previous full status report).
In a correctly operating Frame Relay link, connected user equipment
issues STATUS ENQUIRY messages at regular intervals. This can be
a simple “keep alive” type of enquiry, in which the subscriber tells the
WAN that it is still active, and receives a confirmation from the WAN.
Alternatively, it can be a “full status” request, to which the WAN
responds with a full status report giving the status of all the virtual
connections attached to the local Frame Relay link.
Typically, connected user equipment issues STATUS ENQUIRY
messages every ten seconds with every sixth message requesting the
full status report (though the exact interval may be different on some
Frame Relay links).
The Expert learns about the DLCIs on the Frame Relay link by
monitoring the STATUS ENQUIRY requests and the status reports sent
by the network in response to these requests and stores what it learns
about the network in memory.

A PVC Status information element for this DLCI with the Deleted bit set
to true appears in a single PVC status report or UPDATE STATUS
message.
Traffic on Deleted DLCI
The Expert generates the Traffic on Deleted DLCI alarm when it sees a frame
with a header containing a DLCI that the link management protocol has
reported as deleted.
93
Chapter 1
Traffic on Inactive DLCI
The Expert generates the Traffic on Inactive DLCI alarm when it sees a frame
with a header containing a DLCI that the link management protocol has
reported as inactive.
Traffic on Unknown DLCI
The Expert generates the Traffic on Unknown DLCI alarm when it sees a
frame with a header containing a DLCI not known to the Expert.
In a correctly operating Frame Relay link, connected user equipment issues
STATUS ENQUIRY messages at regular intervals (usually every 10 seconds).
Typically, every sixth STATUS ENQUIRY message from user equipment
requests a full status report from the network (though the exact interval may
be different on some Frame Relay links). The Expert learns about the DLCIs
on the Frame Relay link by monitoring the full status reports sent by the
network in response to these requests and stores what it learns about the
network in memory.
94
WAN Link Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the WAN Link layer.
Async Status Change of Unknown DLCI
The Expert generates the Async Status Change of Unknown DLCI alarm
when it sees a Single PVC status report or an UPDATE STATUS message
with a PVC Status information element that refers to an unknown DLCI. These
report/message types should only be used with existing (non-new) PVCs
(PVCs which would also be known to the Expert from full status reports).
DCE Sequence Number Error
The Expert generates the DCE Sequence Number Error alarm in either of the
following cases:

The Send Sequence Number generated by the network equipment is
not next in sequence after the previous Send Sequence Number.
Sequence numbers on a Frame Relay link increment in ones from 1 to
255 and then restart again at 1.

The Receive Sequence Number sent by the network equipment is not
equal to the last Send Sequence Number sent by the user equipment.
Delayed STATUS ENQUIRY
At the beginning of capture, the Expert discovers this interval. Thereafter, if a
STATUS ENQUIRY message is sent after the regular interval plus the time
specified by the FR Status Enquiry Delay threshold expires, the Expert
generates the Delayed STATUS ENQUIRY alarm.
For example, if the Expert discovers the regular interval between STATUS
ENQUIRY messages to be 10 seconds and the FR Status Enquiry Delay
threshold is set to 1000ms (that is, one second), the Expert will generate the
Delayed STATUS ENQUIRY alarm after 11 seconds have passed between
STATUS ENQUIRY messages.
DTE Sequence Number Error
The Expert generates the DTE sequence number error alarm in either of the
following cases:
95
Chapter 1

The Send Sequence Number generated by the user equipment is not
next in sequence after the previous Send Sequence Number.
Sequence numbers on a Frame Relay link increment in ones from 1 to
255 and then restart again at 1.

The Receive Sequence Number sent by the user equipment is not
equal to the last Send Sequence Number sent by the network
equipment.
Irregular Full Status Report Requests
Typically, every sixth STATUS ENQUIRY message from user equipment
requests a full status report from the network (though the exact interval may
be different on some Frame Relay links).
The Expert learns the interval for the connected link at the beginning of
capture. Thereafter, the Expert monitors the frequency of full status report
requests and generates the Irregular full status report requests alarm when
the number of STATUS ENQUIRY messages between full status requests is
different from the learned interval. The Expert also generates this alarm if a
STATUS ENQUIRY does not contain a full status report request when
expected.
Link Management Message Format Error
The Expert generates the Link Management Message Format Error alarm
when it detects any of the following problems in a link management message:
96

The Unnumbered Information byte (03 hex) contains incorrect
information.

There is a change in the value of the protocol discriminator.

There is an unknown protocol discriminator.

The Dummy Call Reference byte (00 hex) contains incorrect
information.

The Locking Shift information element is missing (this applies only to
the ANSI link management protocol).

An unsupported message type is seen (that is, a message type other
than STATUS ENQUIRY, STATUS, or UPDATE STATUS).

An unknown information element is seen (that is, an information
element not used in Frame Relay link management messages).

An information element is seen that is incompatible with the type of
message containing it or with the current link management protocol.

An information element is seen in incorrect order.

A known information element is seen with an incorrect length.

A report type which is unknown or unsupported by the current link
management protocol is seen.

An information element incompatible with the report type containing it
is seen.

A STATUS message containing a full status report lists DLCIs in the
wrong order (DLCIs should be listed from the least to the greatest).

The same DLCI is listed more than once in a STATUS message
containing a full status report.

More than one PVC Status information element appears in a STATUS
message carrying a Single PVC Status report type.
Link Management Message Minor Format Error
The Expert generates the Link Management Message Minor Format Error
(minor) alarm when it detects either of the following problems in a link
management message:

A full status report was seen with a PVC Status information element
whose Deleted bit was set to true, indicating the PVC was deleted. This
indicates a minor error since if a PVC is deleted, it should not be listed
at all in the full status report.

A Single PVC status report or an UPDATE STATUS message was
seen with a PVC Status information element whose New bit was set to
true. This indicates a minor error since these report/message types
should only be used with existing (non-new) PVCs.
Network Equipment Reset
The Expert generates the Network Equipment Reset alarm when it sees a
STATUS message sent by the network side of the link with a Send Sequence
Number set to 1. The sequence number of 1 indicates that this is the first
STATUS message sent by the network since a reset.
Note that the Expert only generates this alarm if 1 is not the correct sequential
value for this message. Sequence numbers on a Frame Relay link increment
in ones from 1 to 255 and then restart again at 1.
New PVC Configured
The Expert generates the New PVC Configured alarm when it sees a full
status report listing a previously unknown DLCI.
97
Chapter 1
No STATUS ENQUIRY When Expected
At the beginning of capture, the Expert discovers this interval. Thereafter, if a
STATUS ENQUIRY message is sent after the regular interval plus the time
specified by the FR Status Enquiry Waiting Time threshold expires, the
Expert generates the No STATUS ENQUIRY When Expected alarm.
For example, if the Expert discovers the regular interval between STATUS
ENQUIRY messages to be 10 seconds and the FR Status Enquiry Waiting
Time threshold is set to 5000ms (that is, five seconds), the Expert will generate
the No STATUS ENQUIRY When Expected alarm after 15 seconds have
passed between STATUS ENQUIRY messages.
No STATUS Following STATUS ENQUIRY
The Expert generates the No STATUS Following STATUS ENQUIRY alarm
when the network side of the link does not respond to a STATUS ENQUIRY
request with a STATUS message before the user side of the link sends the
next STATUS ENQUIRY message.
STATUS ENQUIRY messages at regular intervals. This can be a simple “keep
alive” type of enquiry, in which the subscriber tells the WAN that it is still active,
and receives a confirmation from the WAN. Alternatively, it can be a “full
status” request, to which the WAN responds with a full status report giving the
status of all the virtual connections attached to the local Frame Relay link.
PVC Activation
The Expert generates the PVC Activation alarm when the PVC Status
information element's Active bit changes from false to true (0 to 1).
PVC Bandwidth Change
On some Frame Relay networks, the bandwidth assigned to each PVC is
reported in the PVC Status information element. The Expert generates the
PVC Bandwidth Change alarm when this reported value changes.
PVC Congestion
The Expert generates the PVC Congestion alarm when it sees a PVC Status
Information element sent by the network with the Receiver Not Ready bit set
to true. Some Frame Relay networks do this to inform the user side of
congestion.
98
PVC Deactivation
The Expert generates the PVC Deactivation alarm when the PVC Status
information element's Active bit changes from true to false (1 to 0).
PVC Deletion
The Expert generates the PVC Deletion alarm in either of the following cases:

A full status report was seen without an entry for the indicated DLCI
(and there was an entry for the DLCI in the previous full status report).
In a correctly operating Frame Relay link, connected user equipment
issues STATUS ENQUIRY messages at regular intervals. This can be
a simple “keep alive” type of enquiry, in which the subscriber tells the
WAN that it is still active, and receives a confirmation from the WAN.
Alternatively, it can be a “full status” request, to which the WAN
responds with a full status report giving the status of all the virtual
connections attached to the local Frame Relay link.
Typically, connected user equipment issues STATUS ENQUIRY
messages every ten seconds with every sixth message requesting the
full status report (though the exact interval may be different on some
Frame Relay links).
The Expert learns about the DLCIs on the Frame Relay link by
monitoring the STATUS ENQUIRY requests and the status reports sent
by the network in response to these requests and stores what it learns
about the network in memory.

A PVC Status information element for this DLCI with the Deleted bit set
to true appears in a single PVC status report or UPDATE STATUS
message.
Unexpected Link Management Message
The Expert generates the Unexpected Link Management Message alarm
when a link management message is seen emanating from the wrong side of
the link (for example, a STATUS message coming from the user side of the
link).
Unsolicited STATUS Message
The Expert generates the Unsolicited STATUS Message alarm when it sees
a STATUS message sent from the network without a corresponding STATUS
ENQUIRY message sent from the user. Note that this alarm is not generated
when an unsolicited STATUS messages containing a Single PVC Status
report is seen.
99
Chapter 1
STATUS ENQUIRY messages at regular intervals. This can be a simple “keep
alive” type of enquiry, in which the subscriber tells the WAN that it is still active,
and receives a confirmation from the WAN. Alternatively, it can be a “full
status” request, to which the WAN responds with a full status report giving the
status of all the virtual connections attached to the local Frame Relay link.
User Equipment Reset
The Expert generates the User Equipment Reset alarm when it sees a
STATUS ENQUIRY message sent by the user side of the link with a Send
Sequence Number set to 1 and a Receive Sequence Number set to 0. These
sequence numbers indicate that this is the first STATUS ENQUIRY message
sent since the link was reset.
Wrong Report Type in STATUS Message
The Expert generates the Wrong Report Type in STATUS Message alarm
when it sees a STATUS message sent in response to a request for a full status
report that contains only sequence number exchange information (and does
not include the requested full status report).
ATM Application Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the ATM Application
Attempt to Bind L3 Address to Multiple MPOA Devices
The Expert generates the Attempt to Bind L3 Address to Multiple MPOA
Devices alarm when it detects an attempt to bind a single Layer Three address
to more than one MPOA device.
MPOA devices (that is MPCs and MPSs) serve Layer Three address. Because
of this, it is a violation of the MPOA specification for a single L3 address to be
bound to more than one MPOA device.
Data Frames Detected Following Data Plane Purge
The Expert generates the Data Frames Detected Following Data Plane
Purge alarm when it detects data frames on an MPC-MPC data flow after a
data plane purge was sent. Data frames should not be sent across an
MPC-MPC data flow following a data plane purge. This connection should be
dropped.
100
Egress MPCs send data plane purge messages to Ingress MPCs to purge
ingress cache entries (that is, to tell the Ingress MPC that a previously-cached
shortcuts are no longer valid). Because these ingress cache entries are no
longer valid, there should not be data frames on them.
DDVCC Idle Period Exceeds VCC Timeout C12
The Expert generates the DDVCC Idle Period Exceeds VCC Timeout C12
alarm when a LEC fails to release a Data Direct Virtual Circuit Connection that
has been idle for longer than the time specified by its C12 VCC Time-out
Period initial state parameter. The Expert uses timeout values as follows:

The Expert uses the timeout value specified by the C12 VCC Time-out
Period initial state parameter if it has been able to learn it from network
traffic. The ATM Forum specifies a default value of 20 minutes for this
timeout, with unlimited minimum and maximum values.

If the Expert has not been able to learn the C12 VCC Time-out Period
parameter, it uses the DDVCC VCC Timeout Period C12 threshold in
the Alarms tab of the Expert UI Object Properties dialog box. By default,
NAI sets this threshold to 20 minutes (the same default as the ATM
Forum).
DDVCC Not Created in Response to LE ARP
When a data frame arrives at the LEC, it sends an LE_ARP request to the LES
to get the ATM address of the LEC representing the destination LAN MAC
address. Once it receives the ATM address of the destination LEC, it sets up
the data direct VCC to the destination LEC to carry the unicast data between
the LAN MAC address pair.
The Expert generates the DDVCC Not Created in Response to LE ARP
alarm when it sees an LE_ARP sent to the LES without a corresponding data
direct VCC being set up within the time limit specified by the DDVCC Setup in
Response to LE ARP threshold in the Alarms tab of the Expert UI Object
Properties dialog box.
Default MCFVCC Not Created in Response to LE ARP
The Expert generates the Default MCFVCC Not Created in Response to LE
ARP alarm when the analyzer sees a LEC send an LE_ARP to the LES for the
destination MAC address FF FF FF FF (that is, broadcast) without a
corresponding Multicast Forward VCC being set up by the BUS within the time
limit specified by the Default MCFVCC Setup in Response to LE_ARP
threshold in the Alarms tab of the Expert UI Object Properties dialog box.
101
Chapter 1
The Multicast Forward flow is set up by the BUS with the LEC once the LEC
has established the MCS with the BUS. The MCF is used to carry all
broadcast, multicast, and unknown data from the BUS to the connected LECs.
At least one MCF flow remains active for each LEC during its participation in
the ELAN. The MCS is unidirectional and can be either point-to-point or
point-to-multipoint. There are different MCF flows for both 802.3 and 802.5
networks.
Default MCSVCC Not Created in Response to LE ARP
This alarm is generated when the analyzer sees a LEC send an LE_ARP to
the LES for the destination MAC address FF FF FF FF (that is, broadcast)
without a corresponding multicast send VCC being set up with the BUS within
the time limit specified by the Default MCSVCC Setup in Response to
LE_ARP threshold in the Alarms tab of the Expert UI Object Properties dialog
box.
The Multicast Send data flow is set up by the LEC with the BUS to carry all
broadcast, multicast, and unknown data from the LEC to the BUS (and in some
cases, from the BUS to the LEC). When a LAN MAC frame with a broadcast
destination address arrives at the LEC, it sends it to the BUS. At least one
MCS flow remains active from each LEC during its participation in the ELAN.
The MCS is point-to-point and bidirectional. There are different MCS flows for
both 802.3 and 802.5 networks.
Excessive Unknown Frames Issued by LEC
The Expert generates the Excessive Unknown Frames Issued by LEC
alarm when it sees a LEC send too many unknown frames without sending an
LE_ARP to the LES. The LEC should issue an LE_ARP when unknown frames
(with unicast MAC addresses) do not have a data direct VCC.
Frames Seen on Default Flow After Shortcut Active
The Expert generates the Frames Seen on Default Flow After Shortcut
Active alarm when it detects traffic on a default flow for which an MPOA
shortcut has already been created. Once a shortcut for a flow has been
created, its traffic must be sent over the shortcut.
LANE Config Phase Failure
During the Configuration phase of LAN Emulation communications, a LEC
sends a Configure Request frame to the LECS in order to obtain configuration
information, including the address of a LES for an ELAN that meets the LEC’s
needs. In response, the LECS sends the Configure Response frame indicating
whether the candidate LEC will be allowed to attempt the Join phase with a
LES.
102
The Expert generates this alarm when the Configure Response frame sent
from the LECS to the LEC indicates failure (that is, the LEC will not be allowed
to attempt the Join phase).
Possible causes:

There is a version incompatibility between the LEC and the LECS.

The LECS denied the Configure Request for security reasons.

The LEC supplied conflicting parameters in the Configure Request
frame.
Look for instances of alarms related to this failure – for example,
Configuration Fail, Insufficient Resources, Denied Access to ELAN,
Insufficient Info from LEC, LANE Protocol Version Unsupported by
ELAN, and so on. The data provided for these alarms will help you understand
the reasons for the Configuration Phase Failure.
LANE Cfg Restart Delay < Min Recfg Delay
information, including the address of a LES for an ELAN that meets the LEC’s
needs. If the Configure Request is denied (or if no response is returned at all),
the LEC must wait for an interval before restarting the Configuration process.
This interval can be any random value between the two LEC initial state
parameters C38 (Maximum Reconfigure Delay) and C37 (Minimum
Reconfigure Delay).
Unfortunately, these two initial state parameters are not carried in the data
stream, so the Expert cannot learn them from analyzing traffic. Because of this,
it uses the Minimum Reconfigure Delay C37 threshold in the Expert Options
dialog box to specify when the LANE Config Restart Delay < Minimum
Reconfig Delay C37 alarm should be generated. If a LEC restarts the
configuration phase before the Minimum Reconfigure Delay C37 timer has
expired, the Expert will generate this alarm. By default, the Minimum
Reconfigure Delay C37 threshold is set to the standard value for C37
specified by the ATM Forum – one millisecond.
103
Chapter 1
LANE Cfg Restart Delay > Max Recfg Delay
information, including the address of a LES for an ELAN that meets the LEC's
needs. If the Configure Request is denied (or if no response is returned at all),
the LEC must wait for an interval before restarting the Configuration process.
This interval can be any random value between the two LEC initial state
parameters C38 (Maximum Reconfigure Delay) and C37 (Minimum
Reconfigure Delay).
Unfortunately, these two initial state parameters are not carried in the data
stream, so the Expert cannot learn them from analyzing traffic. Because of this,
it uses the Maximum Reconfigure Delay C38 threshold in the Expert UI
Object Properties dialog box to specify when the LANE Config Restart Delay
> Max Reconfig Delay C38 alarm should be generated. If a LEC waits longer
than the time specified by this threshold, the Expert will generate the LANE
Cfg Restart Delay > Max Recfg Delay alarm. By default, the Maximum
Reconfigure Delay C38 threshold is set to the standard value for C38
specified by the ATM Forum – five seconds.
No Resolution Request Issued After Excess Default Flow
The Expert generates the No Resolution Request Issued After Excess
Default Flow alarm when the number of data frames sent by an MPC on a
default flow without sending a Resolution Request exceeds its Shortcut Setup
Frame Count (MPC-p1) initial state parameter within the time specified by the
Shortcut Setup Frame Time (MPC-p2) initial state parameter.
The MPC-p1 and MPC-p2 initial state parameters are used to ensure that an
MPC attempts to create a shortcut (by sending a Resolution Request) if a large
amount of traffic is being sent from an MPC to an MPS (that is, on a default
flow; a default flow is any LANE flow whose target L2 address is bound to an
MPS).
Shortcut Create Failed After Resolution Reply
The Expert generates the Shortcut Create Failed After Resolution Reply
alarm when it detects that an MPC has received an MPOA Resolution Reply
from the MPS but has not attempted to send data over a corresponding
MPC-MPC shortcut within the time specified by the Shortcut-Setup following
Res Reply Time threshold in the Alarms tab of the Expert UI Object Properties
dialog box. A shortcut must be attempted following the receipt of a successful
MPOA Resolution Reply.
104
ATM Flow Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the ATM Flow layer.
ARE or STE Frames on Data Direct VCC
When a LEC is emulating a token ring (that is, an 802.5 LEC) that uses source
routing, it will occasionally need to send Token Ring All Routes Explorer (ARE)
and Spanning Tree Explorer (STE) frames. Since these frames typically need
to be sent to more than one destination, LAN Emulation requires that they be
sent to the ELAN via the BUS (over a multicast send VCC). The Expert
generates the ARE or STE Frames on Data Direct VCC alarm when it sees
an ARE or STE frame on a data direct VCC (a violation of the LAN Emulation
standard).
ARP Request Multi Queued
The Expert generates the ARP Request Multi Queued alarm when it sees a
LAN Emulation entity resend an ARP request with the same Transaction ID as
the original ARP request. This is a violation of the LAN Emulation standard.
LAN Emulation communications are established and managed using a set of
standard request and response control frames (such as Configure, Join,
Register, Unregister, ARP, Flush, and Verify, among others). Each of these
requests has a Transaction ID field. When the station receiving the request
returns its response, it preserves this Transaction ID. This way, the requesting
station can tell which responses correspond to which of its requests (by
matching the Transaction IDs).
Whenever a LAN Emulation entity needs to resend a request (perhaps
because there was no response), it must send the exact same original request
with the exception of the Transaction ID. The Transaction ID must be different
so that if the responding station does respond, the requesting station can
determine to which request it is responding.
Attempt to Bind DLC to MPC and Non-MPOA Device
The Expert generates the Attempt to Bind DLC to MPC and Non-MPOA
Device alarm when it detects an attempt to bind a DLC address to both an
MPC and a non-MPOA device.
All MPOA devices have layer two (L2) DLC addresses assigned to them.
Although an MPS can share its L2 DLC address with a representative LEC, an
MPC cannot share its L2 DLC address with any other device (LANE or
otherwise).
105
Chapter 1
Attempt to Multiply Bind MPOA Devices to LEC
The Expert generates the Attempt to Multiply Bind MPOA Devices to LEC
alarm when it detects one of the following situations:

An attempt to bind a LEC to both an MPC and an MPS.

An attempt to bind a LEC to more than one MPC or MPS. A LEC can
only be bound to a single MPC or MPS.
Broadcast/Multicast Data Frames on DDVCC
LAN Emulation requires that all broadcast and multicast frames be sent to the
ELAN via the BUS (over a multicast send VCC). The Expert generates the
Broadcast/Multicast Data Frames on DDVCC alarm when it sees a
broadcast or multicast frame on a data direct VCC (a violation of the LAN
Emulation standard).
Cache ID Set to Zero in DLL Header Ext
The Expert generates the Cache ID Set to Zero in DLL Header Ext alarm
when it detects an MPOA Egress Cache Purge Request control frame sent
from an MPC without the Cache ID included in the DLL Header extension. The
MPOA specification requires that the Cache ID field be included in the DLL
Header extension of an Egress Cache Purge Request so that the MPS knows
which egress cache entry to invalidate.
Config Fail, Insufficient Resources
Register, Unregister, ARP, Flush, and Verify, among others). The Expert
generates the Config Fail, Insufficient Resources alarm when either a
Configure, Join, or Register request was made to a LAN Emulation entity that
was unable to grant the request due to a lack of resources (for example, an
inability to create new VCCs or a lack of table space).
Possible cause:

106
The LES, LECS, or BUS is temporarily overloaded due to excessive
demands from LECs.
Config Frag Info TLV Not Recognized by LECS
needs. The Configure Request frame can optionally contain the Config Frag
Info TLV. The Config Frag Info TLV tells the LECS that it can send TLV data
to this LEC that will not fit into a single frame over multiple frames (that is, the
LECS can fragment the TLV data). The Expert generates the Config Frag Info
TLV Not Recognized by LECS alarm when the LECS sends a Configure
Response frame with the Status field set to 24 (decimal), indicating that it does
not recognize the Config Frag Info TLV sent by the LEC.
Possible cause:

A Version 2.0 LEC sent a Configure Response frame to a Version 1.0
LECS with the Config Frag Info TLV present. The Config Frag Info TLV
is only supported in Version 2.0.
Config Request Multi Queued
The Expert generates the Config Request Multi Queued alarm when it sees
a A LAN Emulation entity resend a Configure Request frame with the same
Transaction ID as the Configure Request frame. This is a violation of the LAN
Emulation standard.
Config Request Response Timeout
The Expert generates the Config Request Response Timeout alarm when a
LEC sends a Configure Request frame to the LECS but does not receive a
Configure Response frame before the timeout value specified by the C7
Control Time-out initial state parameter. The ATM Forum specifies a
minimum value of 10 seconds for this timeout, with a default value of 30
seconds and a maximum of 300 seconds.
107
Chapter 1
The C7 Control Time-out is sent by the LEC as part of the Configure Request
frame. The Expert watches for the timeout value and then uses it to measure
the responses to the Configure Request.
Possible causes:

The LECS has received a large number of simultaneous requests from
various LECs.
Config Request Retry Frame Mismatch
The Expert generates the Config Request Retry Frame Mismatch alarm
when a LEC resends a Configure Request frame with a field changed other
than the Transaction ID. This is a violation of the LAN Emulation standard.
Whenever a LEC needs to resend a Configure Request frame (perhaps
because there was no response from the LECS), it must send the exact same
original request frame with the exception of the Transaction ID. The
Transaction ID must be different so that if the responding station does
respond, the requesting station can determine to which request it is
responding.
Config Request Retry Rate Exceeds 1 Frame/sec
The Expert generates the Config Request Retry Rate Exceeds 1 Frame/sec
alarm when it detects a LEC resending the same Configure Request frame
more than once per second.
Control Request on DDVCC Retry Frame Mismatch
The Expert generates the Control Request on DDVCC Retry Frame
Mismatch alarm when a LEC resends a Control Request frame on a data
direct VCC with a field changed other than the Transaction ID. This is a
violation of the LAN Emulation standard. The exact type of Control Request
frame could have been Flush Request, Ready Indication, or Ready Query.
Whenever a LEC needs to resend a Control Request frame (perhaps because
there was no response), it must send the exact same original request frame
108
Control Request on DDVCC Retry Rate > 1 Frame/Sec
The Expert generates the Control Request on DDVCC Retry Rate > 1
Frame/Sec alarm when it detects a LEC resending the same Control Request
frame more than once per second on a data direct VCC.
The exact type of Control Request frame resent could have been Flush
Request, Ready Indication, or Ready Query.
Database Summary Exchange Lockstep Failure
The Expert generates the Database Summary Exchange Lockstep Failure
alarm if the rules governing the request \ response sequence between two
PNNI nodes exchanging Database Summary packets are violated.
Neighboring peers in a PNNI domain exchange database information through
a precisely governed sequence of Database Summary packets. During the
initial sequence (called the “Negotiation State”), the two nodes establish
master and slave roles. Following this sequence, the “Exchanging State”
begins. During the Exchanging State, only a single Database Summary packet
can be outstanding at one time. A Database Summary packet is considered to
be outstanding until the corresponding acknowledgment is sent from the
receiving node, or the DsRxmtInterval timer in the packet expires (at which
point a new Database Summary packet can be sent). The Expert generates
this alarm if the master sends the same Database Summary packet more than
once (as determined by the packet's sequence number), or if the slave fails to
acknowledge a packet.
Database Summary Master/Slave Negotiation Timeout
The Expert generates the Database Summary Master/Slave Negotiation
Timeout alarm when the time it takes for the initial master/slave negotiation
between two PNNI nodes exceeds the Max time for DB Summary
Master/Slave Negotiation threshold in the Alarms tab of the Expert UI Object
PNNI nodes exchange information from their routing databases to determine
which switches belong to the same peer group and to allow efficient routing of
packets outside the peer group. During the initial Database Summary
exchange between two PNNI nodes, the node pair must determine which is the
master and which is the slave. If this negotiation sequence takes longer than
the threshold, the Expert generates the alarm.
Denied Access to ELAN
The Expert generates the Denied Access to ELAN alarm when either a
Configure Request control frame or a Join Request control frame is sent to the
ELAN by the LEC and is denied for security reasons.
109
Chapter 1
Possible cause:

The Configure Request control frame is sent over a Configuration
Direct VCC. The ATM address used by the requesting station to
establish this VCC may be unknown to the ELAN and therefore
considered a security risk.
DLL Header Extension Not Found in Frame
The Expert generates the DLL Header Extension Not Found in Frame alarm
when it detects either an MPOA Resolution Reply or MPOA Egress Cache
Purge Request control frame that does not include the DLL Header extension.
The MPOA specification requires that both of these control frame types include
this extension.
Duplicate ATM Destination Address Registration
The Expert generates the Duplicate ATM Destination Address Registration
alarm when a LEC attempts to register an ATM address with the LES that is
already in the LES' cache of addresses. The registration attempt could be in
either a Join Request message or a Registration Request message.
Duplicate LAN Destination Registration
The Expert generates the Duplicate LAN Destination Registration alarm
when it sees a Join Response or Register Response frame sent from the LES
to the LEC with the Status Code 4 (decimal). This status code indicates that
the LAN destination address that the LEC attempted to register with the LEC
was already in the LES's cache of addresses.LEC
Possible cause:

A LEC attempted to register a LAN address with the LES that was
already in the LES' cache of addresses with a mapping to a different
LEC. The registration attempt could be in either a Join Request
message or a Registration Request message. In either case, the
duplication may cause the Register Request or Join Request to fail.
Egress Cache Tag Was Not Issued
The Expert generates the Egress Cache Tag Was Not Issued alarm when it
detects an MPOA Resolution Request control frame that does not include the
Egress Cache Tag extension. The MPOA specification requires that the
MPOA Resolution Request control frame include the Egress Cache Tag
extension.
110
Failed to Issue Resolution Req. Following Trigger
The Expert generates the Failed to Issue Resolution Req. Following
Trigger alarm when an MPC fails to issue an MPOA Resolution Request in
response to an MPOA Trigger message sent to it by an MPS.
Ingress MPSs send MPOA Triggers to Ingress MPCs to cause them to send
Resolution Requests. Failure on the part of the MPC to respond with a
Resolution Request is a violation of the specification.
Failure Reported in Reply CIE
The Expert generates the Failure Reported in Reply CIE alarm when it
detects an MPOA control response frame with the client information element
(CIE) code (the first octet of the CIE) set to something other than 0x00,
indicating a failure (0x00 is the only CIE code value indicating success).
Flush Request Multi Queued
The Expert generates the Flush Request Multi Queued alarm when a LAN
Emulation entity resends a Flush request with the same Transaction ID as the
original Flush request. This is a violation of the LAN Emulation standard.
IG Tag Violation
The Expert generates the IG Tag Violation alarm if the Information Group (IG)
Tag bits are set to a non-legal value.
PNNI routing frames use nested TLVs known as Information Groups (IG) to
encode PNNI information. When a PNNI frame is sent, all IGs must be set to
one of the legal values. These values are:

Optional

Summarizable
111
Chapter 1

Non-transitive
The Expert generates this alarm if a PNNI 1.0 frame is seen with an IG set to
something other than one of these values.
The exception to this rule is the Transit Network IG. The legal values for this
IG are:

Optional

Summarizable

Transitive
The Expert generates this alarm for a Transit Network IG if its value is set to
something other than the preceding three values.
Insufficient Info from LEC, Service Refused
The Expert generates the Insufficient Info from LEC, Service Refused
alarm when a LEC sends a Configure Request frame to the LECS in order to
be assigned to an ELAN. However, the LECS was unable to assign the LEC
to an ELAN because the LEC did not provide sufficient information in its
Configure Request frame.
Invalid ATM Primary Address
The Expert generates the Invalid ATM Primary Address alarm when it sees
a Control Request frame that is only supposed to be sent with the source
address set to the LEC's primary source address (for example, a Join
Request) sent with some other non-zero value.
Possible cause:

A LEC mistakenly set the source address in a Join Request to one of
its secondary ATM addresses.
Invalid CIE Contents
The Expert generates the Invalid CIE Contents alarm when it sees an MPOA
control message with one of the fields in the client information element not
filled in as defined in section 5.3 of the MPOA specification.
Invalid Client ATM Primary Source Address
The Expert generates the Invalid Client ATM Primary Source Address
alarm when the LE Service sends a control response frame with the Status
field set to 10 (decimal), indicating that the source ATM address was invalid.
112
Possible cause:

A LEC sent a Configure, Join, Register, ARP, Flush, or Verify Request
with an invalid value in the SOURCE-ATM-ADDRESS field. The format
of the ATM address was not recognizable or was invalid for some other
reason.
Invalid Client MAC Address
The Expert generates the Invalid Client MAC Address alarm when the LE
Service sends a control response frame with the Status field set to 9 (decimal),
indicating one of the following problems:

A LEC sent a Configure, Join, or Flush Request that indicated a
multicast address in the SOURCE-LAN-DESTINATION field. This field
is used to list unicast MAC addresses represented by the LEC. It is a
violation of the LAN Emulation standard for multicast addresses to be
listed there.

A LEC that indicated an ELAN type of 802.3\Ethernet sent a Configure,
Join, Register, ARP, or Flush Request with a Route Descriptor in the
SOURCE-LAN-DESTINATION field. Route Descriptors are only used
in 802.5\Token Ring ELANs.

A LEC sent an ARP Request to resolve multicast MAC addresses.
Invalid Common Header Contents
The Expert generates the Invalid Common Header Contents alarm if it sees
an MPOA control message with an illegal value in one of the fields of the
common header portion of the message.
Figure 1-4 shows the fields in the common header portion of an MPOA control
message.
Figure 1-4. Common Header of an MPOA Control Message
113
Chapter 1
Invalid Fixed Header Contents
The Expert generates the Invalid Fixed Header Contents alarm if it sees an
MPOA control message with an illegal value in one of the fields of the fixed
header portion of the message.
Figure 1-5 shows the fields in the fixed header portion of an MPOA control
message.
Figure 1-5. Fixed Header of an MPOA Control Message
Invalid Frame Contents
The Expert generates the Invalid Frame Contents alarm when it detects a
PNNI frame which exhibits one or more of the following errors:

The packet length in the PNNI header exceeds the received frame
length.

The version indicated in the Protocol Version field of the PNNI header
is unsupported.

One or more parameters in the PNNI frame were outside of the valid
range.

Invalid frame type. This occurs when the value of the Packet Type field
in the PNNI packet header is not set to one of the five valid PNNI frame
types (Hello, PTSP, PTSE Acknowledgment, Database Summary,
or PTSE Request).

The originating Peer Group ID or Node ID in the PNNI frame does not
match that of the node issuing the frame.
Invalid Hello Frame
The Expert generates the Invalid Hello Frame alarm when it detects a PNNI
Hello Frame exhibiting one or more of the following problems:
114

A “top level unknown TLV” with its mandatory bit set to true. As
described in Section 5.6.2.3 of Version 1.0 of the ATM Forum's PNNI
specification, such Hello frames must be discarded by the receiving
station.

The “Hello Interval” value is set to zero

The Port ID is set to zero

The Peer Group ID, if known, does not match that of the other nodes
on the link. This is only true for Hello packets seen on SVCC RCCs
(routing control channels set up at the parent level of the PNNI
hierarchy between Logical Group Nodes).
Invalid MPOA MPS MAC Address Count in Device Type TLV
The Expert generates the Invalid MPOA MPS MAC Address Count in
Device Type TLV alarm when the MAC Address Count in a Device Type TLV
indicates a violation of the MPOA specification.
MPOA uses the Device Type TLV to enable MPOA entities (MPCs and MPSs)
to discover one another. Its transmission is required with LANE control
messages, including LE_REGISTER and LE_ARP requests and responses.
The first octet of every Device Type TLV indicates the type of device that sent
it (for example, an MPC, an MPS, and so on). Depending on the value of this
first octet, the second octet of the TLV (which indicates the number of MAC
addresses) must be a certain value. If the detected value of the second octet
is not valid given the value of the first octet, this alarm is generated.
Possible causes:

The Device Type TLV indicated a Non-MPOA device type (value of the
first octet is 0), but the MAC address counts is non-zero.

The Device Type TLV indicated an MPC device type (value of the first
octet is 2), but the MAC address count is non-zero.

The Device Type TLV indicated an MPS and MPC device type (value
of the first octet is 3), but the MAC address count is zero. A non-zero
MPS MAC address count for device types including Non MPOA (0) or
MPC (2)
Invalid MPOA Packet Size
The Expert generates the Invalid MPOA Packet Size alarm when it detects
an MPOA packet whose advertised size does not match the actual size of the
captured packet.
115
Chapter 1
Invalid Tag in Data Frame Header
The Expert generates the Invalid Tag in Data Frame Header alarm when it
detects a data frame using MPOA tagged encapsulation without a valid,
non-zero tag in the frame.
MPOA can use either LLC encapsulation or MPOA tagged encapsulation for
data frames. A valid, non-zero tag must be included as part of each data frame
that uses MPOA tagged encapsulation.
Join Request Multi Queued
The Expert generates the Join Request Multi Queued alarm when a LAN
Emulation entity resends a Join request with the same Transaction ID as the
original Join request. This is a violation of the LAN Emulation standard.
Join Request Received from LES
The Expert generates the Join Request Received from LES alarm when a
LEC receives a Join Request frame from the LES. This is the opposite of
standard operating procedure in an ELAN. Join Request frames are ordinarily
sent by the LEC to the LES to request that they be allowed to join the ELAN.
The LES then responds to the LEC by sending the Join Response frame.
Join Request Transmitted by LES
The Expert generates the Join Request Transmitted by LES alarm when a
LES sends a Join Request frame to a LEC. This is the opposite of standard
operating procedure in an ELAN. Join Request frames are ordinarily sent by
the LEC to the LES to request that they be allowed to join the ELAN. The LES
then responds to the LEC by sending the Join Response frame.
116
Join Response Issued by LEC
The Expert generates the Join Response Issued by LEC alarm when a LEC
sends a Join Response frame to the LES. This is the opposite of standard
operating procedure in an ELAN. Join Response frames are ordinarily sent by
the LES to the LEC in response to receiving the Join Request frame.
Keep Alive Lifetime Set to Zero
The Expert generates the Keep Alive Lifetime Set to Zero alarm when the
value of the Keep Alive Lifetime field in the Keep Alive Lifetime Extension
contained in an MPOA Keep Alive control message is zero.
MPSs periodically send MPOA Keep Alive control messages to MPCs to keep
the MPC-MPS flow active. The MPOA Keep Alive control message includes
the Keep Alive Lifetime extension. The Keep Alive Lifetime extension includes
a Keep Alive Lifetime field that indicates the amount of time that its Keep Alive
message can be considered valid. When this field reaches zero, the keep alive
message expires before it can be acknowledged and the Expert generates this
alarm.
Keep Alive Sequence Failure
The Expert generates the Keep Alive Sequence Failure alarm when an MPC
receives a Keep Alive frame from an MPS with a request ID that did not
increase from its previous value.
MPSs periodically send MPOA Keep Alive control messages to MPCs to keep
the MPC-MPS flow active. Each time an MPS sends a Keep Alive message to
a given station, it increases the request ID found in the message by at least
one (the first request ID sent to a given station is set to zero and increases from
there).
Keep Alive Lifetime Ext Not Found in Frame
The Expert generates the Keep Alive Lifetime Ext Not Found in Frame
alarm when it detects an MPOA control message that is required to include the
Keep Alive Lifetime Extension but does not have it.
MPOA Keep Alive messages are required to include the Keep Alive Lifetime
EXT.
LANE Control Request Response Timeout
The Expert generates the LANE Control Request Response Timeout alarm
when a LEC sends a Control Request frame to the LE Service, but does not
receive a corresponding response frame before the timeout value expires. The
Expert uses timeout values as follows:
117
Chapter 1

The Expert uses the timeout value specified by the LEC's C7 Control
Time-out initial state parameter if it has been able to learn it from
network traffic. The C7 Control Time-out is sent by the LEC as part of
the Configuration or Join phase of LAN Emulation communications.
The ATM Forum specifies a minimum value of 10 seconds for this
timeout, with a default value of 30 seconds and a maximum of 300
seconds.

If the Expert has not been able to learn the C7 Control Time-out
parameter, it uses the Control Timeout C7 threshold in the Alarms tab
of the Expert UI Object Properties dialog box. By default, NAI sets this
threshold to 30 seconds (the same default as the ATM Forum).
The exact type of Control Request frame resent could have been a Join
Request, Register Request, Register Request, ARP Request, Flush Request,
or a Verify Request. The alarm display will indicate the exact request type(s).
Possible Cause:

The LE Service has received a large number of simultaneous requests
from various LECs.
LANE Control Request Retry Frame Mismatch
The Expert generates the LANE Control Request Retry Frame Mismatch
alarm when a LEC resends a Control Request frame in which a field was
changed other than the Transaction ID. This is a violation of the LAN Emulation
standard. The exact type of Control Request frame could be a Join Request,
Register Request, Unregister Request, ARP Request, or a Verify Request.
Whenever a LEC needs to resend a Control Request frame (perhaps because
there was no response from the LE Service), it must send the exact same
original request frame with the exception of the Transaction ID. The
Transaction ID must be different so that if the responding station does
respond, the requesting station can determine to which request it is
responding.
LANE Control Request Retry Rate > 1 Frame/sec
The Expert generates the LANE Control Request Retry Rate Exceeds 1
Frame/sec alarm when it detects a LEC resending the same Control Request
frame more than once per second.
The exact type of Control Request frame resent could have been a Join
Request, Register Request, Register Request, ARP Request, Flush Request,
or a Verify Request.
118
LANE Version Unsupported by ELAN
The Expert generates the LANE Version Unsupported by ELAN alarm when
a requesting station sends a control frame to the ELAN with a VERSION field
indicating a higher value than that supported by the ELAN. Possible control
frame types sent by the requesting station include Configure Request, Join
Request, Register Request, Unregister Request, ARP Request, Flush
Request, and Verify Request.
Possible Cause:

A Version 2.0 LANE client is attempting to operate on a Version 1.0
ELAN.
LE ARP Request Rate Exceeds 1 Frame/Sec
The Expert generates the LE ARP Request Rate Exceeds 1 Frame/Sec
alarm when it detects a LEC sending LE_ARP requests more than once per
second.
LE_CONFIGURE Params Conflict, Service Refused
A LEC sends a Configure Request to the LECS in order to receive the address
of the LES for an ELAN meeting its requested operating parameters. The
Expert generates the LE_CONFIGURE Params Conflict, Service Refused
alarm when the LECS responds with a Configure Response frame with the
Status field set to 21 (decimal), indicating a conflict in the parameters specified
in the Configure Request frame. A status field set to 21 can also indicate that
the LECS has denied a request for unspecified reasons.
LEC Issued Config Response to LECS
The Expert generates the LEC Issued Config Response to LECS alarm
when a LEC sends a Configure Response frame to a LECS. This the opposite
of standard operating procedure in an ELAN. Configure Response frames are
ordinarily sent by the LECS to the LEC in response to receiving the Configure
Request frame. They indicate whether the candidate LEC will be allowed to
attempt the Join phase with a LES.
LEC Not Recognized by LECS
LES.
119
Chapter 1
The Expert generates the LEC Not Recognized by LECS alarm when the
Configure Response frame sent from the LECS to the LEC indicates failure
(that is, the LEC will not be allowed to attempt the Join phase) with a Status
code of 20 (decimal). This status code indicates that the LEC is not recognized
by the LECS.
Possible causes:

There is a version incompatibility between the LEC and the LECS.

The LECS denied the Configure Request for security reasons.

The LEC supplied conflicting parameters in the Configure Request
frame.
Look for instances of alarms related to this failure – for example, Configuration
Fail, Insufficient Resources, Denied Access to ELAN, Insufficient Info from
LEC, LANE Protocol Version unsupported by ELAN, and so on. The data
provided for these alarms will help you understand the reasons for the failure.
LEC ID in Frame Mismatch with Client LEC ID
The Expert generates the LEC ID in Frame Mismatch with Client LEC ID
alarm when a LEC sends a Register, Unregister, or ARP request with the
LECID field set to something other than the LEC's ID.
LECID Is Not 0x0000 in Request Frame
The Expert generates the LECID Is Not 0x0000 in Request Frame alarm
when a LEC sends a Register Request or a Join Request to the LE Service
with the LECID field set to something other than zero. LAN Emulation requires
that Register and Join requests be sent with the LECID field set to zero. This
is because one of the purposes of the Register and Join phases of LAN
Emulation communications is for the LEC to get its LECID from the LES.
LECS Issued Config Request to LES
The Expert generates the LECS Issued Config Request to LES alarm when
a LECS sends a Configure Request frame to a LEC. This the opposite of
standard operating procedure in an ELAN. Configure Request frames are
ordinarily sent by the LEC to the LECS in order to obtain configuration
LES.
120
Local Segment ID not in Source Routed Frame
The Expert generates the Local Segment ID not in Source Routed Frame
alarm when it sees a source routed frame with a route indicator (RI) field that
does not contain a route descriptor (RD) matching the local ELAN's segment
ID.
Source routing is typically used in token ring (802.5) networks. Source routing
use the RI field to identify each of the bridges that have forwarded a frame. As
each bridge retransmits a frame, it appends its own RD to the RI field of the
frame. As a result, the ultimate recipient has a record of all intermediate
stations that forwarded the frame. Since LECs operate as bridges, they add
their own RDs to the RI field. Frames seen on the network without an RD
matching the local ELAN's segment ID are considered invalid. They may be
discarded by a LEC.
MAC Address bound to Multiple LECs
The Expert generates the MAC Address bound to Multiple LECs alarm
when it sees the same LAN MAC address bound to multiple LECs. During
capture, the Expert examines the control request and response messages
sent by LAN Emulation entities and keeps track of the pairings of MAC
addresses with LECs it has been able to learn from these messages. Each
time the Expert sees a control message with a MAC address/LEC address
pairing, it compares the pairing against the pairings it has already stored in its
buffer. The Expert generates this alarm when this comparison reveals a MAC
address bound to multiple LECs.
Max Transmission Unit Size Undefined
The Expert generates the Max Transmission Unit Size Undefined alarm
when the maximum transmission unit (MTU) field in the Client Information
Element (CIE) of an MPOA Cache Imposition Request or Cache Imposition
Reply control frame is not defined. This is a violation of the MPOA
specification.
Missing ULIA on Outside Link
The Expert generates the Missing ULIA on Outside Link alarm when it
detects a border node sending a PNNI Hello packet to a border node in
another peer group without including the Uplink Information Attribute (ULIA)
Information Group (IG), even though the sending station was in a Hello state
that required the inclusion of the ULIA with the packet.

Information Groups are a form of TLV used to encode PNNI
information.
121
Chapter 1

“Outside links” are links between PNNI nodes belonging to different
peer groups (border nodes). PNNI nodes determine that they are in
different peer groups from one another through the exchange of PNNI
Hello packets.

The ULIA provides complete information to the receiving station on the
resources it must advertise in the uplink advertisement that it sends in
response.
MPOA Capable LEC Did Not Issue Device TLV
The Expert generates the MPOA Capable LEC Did Not Issue Device TLV
alarm when it sees a LEC that has been configured as an MPOA device (either
an MPC or an MPS) send one of the following message types without the
Device Type TLV:

LE_REGISTER_REQUEST

LE_REGISTER_RESPONSE

LE_ARP_REQUEST

LE_ARP_RESPONSE

Tragedies LE_ARP_REQUEST
MPOA uses the Device Type TLV to enable MPOA entities (MPCs and MPSs)
to discover one another. Its transmission is required with the LANE control
messages listed above.
MPOA Config Parameter Invalid
The Expert generates the MPOA Config Parameter Invalid alarm when it
detects a configuration parameter that is outside of the valid ranges found in
the MPOA specification. The Expert learns this information from the frames
exchanged between an MPOA device and the LECS to obtain configuration
information for the MPOA device.
The valid ranges for MPC and MPS configuration parameters are found in
sections 4.1.1.1 and 4.1.2.1 of the MPOA specification.
MPOA Control Request Response Timeout
The Expert generates the MPOA Control Request Response Timeout
alarm when An MPOA entity (either an MPC or an MPS) sends a Control
Request frame, but does not receive a corresponding response frame before
the timeout value expires. The Expert uses timeout values as follows:
122

The Expert uses the timeout values specified by the sending entity's
MPC Initial Retry Time (MPC-p4) and MPC Retry Time Maximum
(MPC-p5) initial state parameters if it has been able to learn them from
network traffic. The ATM Forum specifies a minimum value of 1
second, a default value of 5 seconds, and a maximum of 300 seconds
for the MPC Initial Retry Time (MPC-p4) parameter. The values for the
MPC Retry Time Maximum (MPC-p5) parameter are 10 (minimum), 40
(default), and 300 (maximum).

If the Expert has not been able to learn the initial state parameters, it
uses the MPC Initial Retry Time-p4 threshold and the MPC Retry
Time Maximum-p5 threshold in the Alarms tab of the Expert UI Object
Properties dialog box. By default, NAI sets these thresholds to 5
seconds and 40 seconds, respectively (the same defaults as the ATM
Forum).
How MPOA Times Out Requests Using These Values
MPOA uses both the Initial Retry Time and the Retry Time Maximum values,
in addition to the Retry Time Multiplier (MPS-c1) to time out requests. The
Retry Time Multiplier is a constant and has a value of 2.
When an entity sends its first request, it must wait MPC-p4 seconds (the initial
retry time) before resending the request. Each time the entity resends the
request, the sending entity multiplies the prior retry time by the Retry Time
Multiplier and waits that long for a response. When the retry time exceeds the
Retry Time Maximum (MPC-p5), the request is considered to have timed out.
For example, suppose an MPC has an Initial Retry Time of 5 seconds and a
Retry Time Maximum of 39 seconds. On the first sending of a control
message, the MPC will wait five seconds for a response. If it doesn't receive
one, it multiplies the prior retry time (5 seconds) by the multiplier (2) and waits
that long (10 seconds) for a response to its next attempt at sending the
message. If it doesn't receive a response, it does the same thing again,
multiplying 10 (the current retry timer) by 2 and waiting that long for the
response to its third message. When the retry timer multiplied by 2 finally
exceeds the Retry Time Maximum, it times out the message. In this example,
that will happen after the third attempt when the retry timer reaches 40 (one
more than the Retry Time Maximum).
Possible Cause:

MPOA Control Request Retry Rate > 1 Frame/sec
The Expert generates the MPOA Control Request Retry Rate > 1
Frame/Sec alarm when it detects an MPOA entity (either an MPC or an MPS)
resending the same Control Request message more than once per second.
123
Chapter 1
The exact type of Control Request frame resent could have been Resolution
Request, Cache Imposition Request, Egress Cache Purge Request, or an
NHRP Purge Request.
MPOA Error Frame Detected
The Expert generates the MPOA Error Frame Detected alarm when it detects
an MPOA control frame with the ar$op.type fixed header field set to 0x88. A
value of 0x88 in the ar$op.type fixed header field indicates an error.
Multiply Assigned Secondary LEC Address
The Expert generates the Multiply Assigned Secondary LEC Address
alarm when it sees more than one LEC using the same secondary ATM
address.
A LEC can have multiple ATM addresses in addition to its primary ATM
address. The primary ATM address is used for connections to the LES and
BUS. It is used for all exchanges during the Configuration and Join phases of
LANE communications. However, a LEC can also have secondary ATM
addresses that can be used for Data Direct VCCs. ATM addresses are
reported in the C1n variable for the LEC. The first address in the C1n variable
is the primary ATM address. Following addresses are considered secondary.
During capture, the Expert examines the control request and response
messages sent by LAN Emulation entities and keeps track of the secondary
LEC addresses used by each LEC. Each time the Expert sees a control
message with a secondary LEC address, it compares the address against the
addresses used by other LECs it has already stored in its buffer. The Expert
generates this alarm when this comparison reveals a secondary LEC address
used by multiple LECs
NARP Request Multi Queued
The Expert generates the NARP Request Multi Queued alarm when a LAN
Emulation entity resends a NARP request with the same Transaction ID as the
original Join request. This is a violation of the LAN Emulation standard.
124
NARP Request Received from LES
The Expert generates the NARP Request Received from LES alarm when a
LES sends a NARP Request frame. This is the opposite of standard operating
procedure in an ELAN. NARP Request frames are ordinarily sent by the LEC
to inform the LE Service of changes in the bindings of remote addresses.
No CIEs Were Present in MPOA Reply
The Expert generates the No CIEs Were Present in MPOA Reply alarm when
it detects an MPOA response frame that is missing a mandatory Client
Information Element (CIE). The exact MPOA reply can be any one of the
following MPOA reply control frame types:

MPOA Resolution Reply

MPOA Cache Imposition Reply

MPOA Egress Cache Purge Reply
No CIEs Were Present in MPOA Request
The Expert generates the No CIEs Were Present in MPOA Request alarm
when it detects an MPOA request frame that is missing a mandatory Client
Information Element (CIE). The exact MPOA request can be any one of the
following MPOA request control frame types:

MPOA Cache Imposition Request

MPOA Egress Cache Purge Request

NHRP Purge Request
No Reply Flag Is Not Set in ICache Purge
The Expert generates the No Reply Flag Is Not Set in ICache Purge alarm
when it detects an NHRP Ingress Cache Purge Request control message with
the No Reply flag in the common header portion of the message set to
something other than one. The MPOA specification requires that the No Reply
flag in an NHRP Ingress Cache Purge Request control message must be set
to one.
125
Chapter 1
PTSE Violation
The Expert generates the PTSE Violation alarm if it detects a PNNI Topology
State Element (PTSE) with an illegal Information Group (IG).
PNNI nodes exchange PNNI Topology State Packets (PTSPs) amongst
themselves to distribute routing information throughout a peer group. Each
PTSP packet contains multiple PNNI Topology State Elements (PTSEs), each
with its own header. The PTSE header includes a PTSEType field indicating
the restricted IGs which can legally appear in the PTSE (IGs are TLV used to
encode PNNI information). The Expert generates this alarm if a restricted IG
other than those indicated in the PTSEType field is found in a PTSE.
Register Request Multi Queued
The Expert generates the Register Request Multi Queued alarm when aLAN
Emulation entity resends a Register request with the same Transaction ID as
the original Register request. This is a violation of the LAN Emulation standard.
Register Request Received from LES
The Expert generates the Register Request Received from LES alarm when
a LES sends a Register Request frame to a LEC. This is the opposite of
standard operating procedure in an ELAN. Register Request frames are
ordinarily sent by the LEC to the LES in order to register a LAN
destination\ATM address pair. The LES responds by sending the Register
Response frame.
Register Response Issued by LEC
The Expert generates the Register Response Issued by LEC alarm when a
LEC sends a Register Response frame to a LES. This is the opposite of
standard operating procedure in an ELAN. Register Response frames are
ordinarily sent by the LES to the LEC in response to receiving the Register
Request frame.
126
Remote Address Issued by Non Proxy LEC
The Expert generates the Remote Address Issued by Non Proxy LEC alarm
when it sees a LEC that is known not to be a proxy sending an ARP Response
with a flag indicating that the ATM address represents a remote (proxied) MAC
address.
The Expert uses the C4 Proxy variable sent in Configure Request messages
to learn whether a given station is a proxy. When the Expert sees a Configure
Request message with the C4 Proxy variable set to false, it records the
sending station as a non-proxy station. If a non-proxy station subsequently
sends an ARP Response with a flag indicating that the ATM address
represents a remote (proxied) MAC address, the Expert generates this alarm.
Request Params Are Incompatible with ELAN
The Expert generates the Request Parameters Are Incompatible with
ELAN alarm when the LE Service sends a control response frame with the
Status field set to 2 (decimal), indicating that the parameters in a control
request frame sent by a LEC were incompatible with the parameters supported
by the ELAN.
Possible causes:

A LEC sent a control request frame with the REQUESTER-LED-ID field
or the SOURCE-ATM-ADDRESS field empty.

A LEC sent a Join Request to the LES that was missing some of the
required parameters (for example, C1 LE Client's Non-Multiplexed
ATM Addresses, C2 LAN Type, C3 Maximum Data Frame Size, C4
Proxy, or C5 ELAN Name).

A LES sent a Join Response to a LEC that was missing some of the
required parameters (for example, C2 LAN Type, C3 Maximum Data
Frame Size, or C5 ELAN Name).

An 802.3 data frame was seen on an 802.5 data direct VCC.

Source routed frames were seen with an invalid RI (route indicator)
field. An RI field is invalid if it is of an odd length or has a Route
Descriptor that does not match the ELAN's Segment ID
TA List Resources Exhausted
This is an internal alarm generated by the Expert when there is no longer
enough buffer space to store an incoming Control Frame.
127
Chapter 1
Possible cause:

The Expert is running out of memory. You may want to save and then
restart your capture.
Topology Change Request Multi Queued
The Expert generates the Topology Change Request Multi Queued alarm
when LAN Emulation entity resends a Topology request with the same
Transaction ID as the original Topology request. This is a violation of the LAN
Emulation standard.
Topology Mismatch in Data Frame Types
The Expert generates the Topology Mismatch in Data Frame Types alarm
when it detects either of the following:

An 802.3 frame on a data direct VCC in an 802.5 ELAN.

An 802.5 frame on a data direct VCC in an 802.3 ELAN.
Unexpected DLL Header EXT in Frame
Each MPOA control message has a set of extensions that can legally appear
in a message. The Expert generates the Unexpected DLL Header EXT in
Frame alarm when it sees the DLL Header extension in an MPOA control
message for which it is not legal.
Unexpected Egress Cache EXT in Frame
in a message. The Expert generates the Unexpected Egress Cache EXT in
Frame alarm when it sees the Egress Cache Tag extension in an MPOA
control message for which it is not legal.
128
Unexpected Hop Count EXT in Frame
in a message. The Expert generates the Unexpected Hop Count EXT in
Frame alarm when it sees the Hop Count extension in an MPOA control
message for which it is not legal.
Unexpected IG
The Expert generates the Unexpected IG alarm if it detects a PNNI frame
containing a legal but unexpected IG.
encode PNNI information. Different IGs are expected in different PNNI packet
types. If an IG appears in a packet for which it is non-standard, the Expert
For example, a PNNI PTSE ACK packet can legally contain the Nodal PTSE
ACK IG or the System capabilities IG. If a PTSE ACK packet is detected with
an IG other than these two (for example, the Nodal Hierarchy List IG), the
Expert would generate the Unexpected IG alarm.
The mapping of valid IGs to PNNI packet types is found in Table 5-19 of
Version 1.0 of the ATM Forum's PNNI specification.
Unexpected Keepalive Lifetime EXT in Frame
in a message. The Expert generates the Unexpected Keepalive Lifetime
EXT in Frame alarm when it sees the Keep Alive Lifetime extension in an
MPOA control message for which it is not legal.
Unexpected Original Error Code EXT in Frame
in a message. The Expert generates the Unexpected Original Error Code
EXT in Frame alarm when it sees the Original Error Code extension in an
MPOA control message for which it is not legal.
Unexpected Service Category EXT in Frame
in a message. The Expert generates the Unexpected Service Category EXT
in Frame alarm when it sees the ATM Service Category extension in an MPOA
control message for which it is not legal.
129
Chapter 1
Unexpected TLVs Detected
The Expert generates the Unexpected TLVs Detected alarm when it sees a
TLV it does not expect in a frame.
Each LAN Emulation control frame type supports a different subset of the total
set of LANE TLVs. The Expert compares the TLVs seen in each detected
control frame against the TLVs that are actually supported by that frame type.
When an unsupported TLV is detected, the Expert generates this alarm. An
example is provided in the Possible Cause section, below.
Possible cause:

A Configuration Request was seen with the LLC-Muxed-ATM-Address
TLV. This TLV is not supported for Configuration Requests.
Unknown Extension in Frame
Any MPOA control frame can use one of a set of valid MPOA Extensions.
These MPOA Extensions range in value from 0x1000 to 0x1006. The Expert
generates the Unknown Extension in Frame alarm when it detects the
presence of an extension in a control frame whose value does not fall within
this range.
Unknown IG
The Expert generates the Unknown IG alarm if it detects a PNNI frame
containing an unknown IG.
encode PNNI information. Different versions of the PNNI protocol support
different sets of IGs. This alarm is likely to be generated when a PNNI node
receives an IG from a second node running a newer version of the PNNI
protocol.
Possible cause:

Two PNNI nodes are running different versions of the PNNI protocol.
Unknown LANE Config/Control Opcode
The Expert generates the Unknown LANE Config/Control Opcode alarm
when it detects the presence of an opcode that is unknown or unassigned by
the ATM Forum.
130
Possible cause:

Some manufacturers of ATM networking equipment have implemented
their own proprietary opcodes
Unknown Marker/Protocol Values
The Expert generates the Unknown Marker/Protocol Values alarm when it
detects invalid values in a frame.
Possible causes:

An unused field in a control frame is set to an invalid value. Backward
compatibility with the LAN Emulation Version 1 specification requires
that unused fields in control messages be set to a known value.

The OP-CODE identifying a control frame is not valid for the type of flow
on which the frame is seen.
Unknown/Unexpected Authenticate EXT in Frame
in a message. The Expert generates the Unknown/Unexpected
Authenticate EXT in Frame alarm when it sees the Authentication extension
in an MPOA control message for which it is not legal.
Unknown/Unexpected CIE in Frame
Each type of MPOA control frame has a set of Client Information Elements that
can legally be found within it. The Expert generates the
Unknown/Unexpected CIE in Frame alarm when it detects the presence of
one or more CIEs that are not valid for the detected control frame type.
Unregister Request Multi Queued
The Expert generates the Unregister Request Multi Queued alarm when a
LAN Emulation entity resends an Unregister request with the same
Transaction ID as the original Unregister request. This is a violation of the LAN
Emulation standard.
131
Chapter 1
Unregister Request Received from LES
The Expert generates the Unregister Request Received from LES alarm
when a LES sends an Unregister Request frame to a LEC. This is the opposite
of standard operating procedure in an ELAN. Unregister Request frames are
ordinarily sent by the LEC to the LES in order to remove a registered LAN
destination\ATM address pair from the LES' cache of registered addresses.
The LES responds by sending the Unregister Response frame.
Unregister Response Issued by LEC
The Expert generates the Unregister Response Issued by LEC alarm when
a LEC sends an Unregister Response frame to a LES. This is the opposite of
standard operating procedure in an ELAN. Unregister Response frames are
ordinarily sent by the LES to the LEC in response to receiving the Unregister
Request frame.
V2 TLVs Issued in V1 ELAN
The Expert generates the V2 TLVs Issued in V1 ELAN alarm when a control
frame with TLVs supported only in LANE Version 2.0 is seen on a Version 1.0
ELAN.
Possible cause:

A Version 2.0 LEC sent a Configure Request frame including the
Config-Frag-Info TLV. This TLV (used so a LECS can use multiple
frames to return TLV information that will not fit into a single frame) is
supported only in LANE Version 2.0.
Verify Request Multi Queued
The Expert generates the Verify Request Multi Queued alarm when a LAN
Emulation entity resends a Verify request with the same Transaction ID as the
original ARP request. This is a violation of the LAN Emulation standard.
132
Verify Request Received from LES
The Expert generates the Verify Request Received from LES alarm when a
LES sends a Verify Request frame to a LEC. This is the opposite of standard
operating procedure in an ELAN. Verify Request frames are ordinarily sent by
the LEC to the LES in order to verify the ATM address of the BUS for the ELAN
of which the LEC is a member. The LES responds by sending the Verify
Response frame.
Verify Response Issued by LEC
The Expert generates the Verify Response Issued by LEC alarm when a
LEC sends a Verify Response frame to a LES. This is the opposite of standard
operating procedure in an ELAN. Verify Response frames are ordinarily sent
by the LES to the LEC in response to receiving the Verify Request frame.
133
Chapter 1
ATM Connection Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the ATM Connection
AAL5 CRC Errors
The Expert generates the AAL5 CRC Errors alarm when the percentage of
frames on a VPI.VCI with CRC errors exceeds the Max Percentage of
Frames with CRC Errors threshold in the Alarms tab of the Expert UI Object
For each VPI.VCI on the network, the Expert maintains counts of frames with
CRC errors and frames without CRC errors. When the percentage of frames
with CRC errors first exceeds the threshold, the Expert generates this alarm.
Each time the percentage of frames with CRC errors on the VPI.VCI
re-exceeds the threshold, the Expert either reopens the previous alarm or
creates a new one depending on how much time has elapsed between alarms.

If the previous alarm occurred less than an hour ago, the Expert
reopens the previous alarm with updated frame counts.

If the previous alarm occurred more than an hour ago, the Expert
creates a new alarm.
AAL5 Length Errors
The Expert generates the AAL5 Length Errors alarm when the percentage of
frames on a VPI.VCI with length errors exceeds the Max Percentage of
Frames with Length Errors threshold in the Alarms tab of the Expert UI
Object Properties dialog box.
length errors and frames without length errors. When the percentage of frames
with length errors first exceeds the threshold, the Expert generates this alarm.
Each time the percentage of frames with length errors on the VPI.VCI
re-exceeds the threshold, the Expert either reopens the previous alarm or
creates a new one depending on how much time has elapsed between alarms.
134

AAL5 Timeout Errors
The Expert generates the AAL5 Timeout Errors alarm when the percentage
of frames on a VPI.VCI with timeout errors exceeds the Max Percentage of
Frames with Timeout Errors threshold in the Alarms tab of the Expert UI
timeout errors and frames without timeout errors. When the percentage of
frames with timeout errors first exceeds the threshold, the Expert generates
this alarm. Each time the percentage of frames with timeout errors on the
VPI.VCI re-exceeds the threshold, the Expert either reopens the previous
alarm or creates a new one depending on how much time has elapsed
between alarms.

Abnormal Disconnect for SVC
The Expert generates the Abnormal Disconnect for SVC alarm when it
detects an SVC that was disconnected for one of the following reasons:

If the Specific Disc Cause for Alarm threshold in the Alarms tab of the
Expert UI Object Properties dialog box is set to 0, the Expert will
generate this alarm for any disconnect cause code other than 16 or 31
(normal disconnects).

Alternatively, the Specific Disc Cause for Alarm threshold can be
used to specify a disconnection cause code whose detection will cause
this alarm to be generated. If the threshold is set to a positive integer,
this alarm will be generated only if an SVC is disconnected with the
specified cause code.
The alarm display shows you the exact disconnect cause code that caused the
alarm.
Extra Cause Codes Used by the Expert
In addition to the standard disconnect cause codes, you can also use this
additional Expert-specific cause code for the Specific Disc Cause for Alarm
(conn level) threshold:

127 – A SETUP message using the same call reference number as this
connection was detected without the analyzer having seen an
intervening RELEASE message (or any other disconnection message)
to drop the prior connection.
135
Chapter 1
CLP = 1
The Expert generates the CLP = 1 alarm when the percentage of frames on a
VPI.VCI with at least one cell's Cell Loss Priority bit set to true (CLP=1)
exceeds the Max Percentage of Frames with CLP=1 threshold in the Alarms
For each VPI.VCI on the network, the Expert maintains counts of frames
containing at least one cell with the CLP bit set to true and frames without any
cells with the CLP bit set to true. When the percentage of CLP=1 frames first
exceeds the threshold, the Expert generates this alarm. Each time the
percentage of CLP=1 frames on the VPI.VCI re-exceeds the threshold, the
Expert either reopens the previous alarm or creates a new one depending on
how much time has elapsed between alarms.

Connection Too Short
The Expert generates the Connection Too Short alarm if it detects an SVC
whose duration was shorter than the Min Duration of session in msecs
threshold in the Alarms tab of the Expert UI Object Properties dialog box. The
analyzer detects short connections using the Q.2931 messages used on the
signaling channel to set up and tear down connections.
Crankback Has Occurred (ATM Connection Layer)
The Expert generates the Crankback Has Occurred alarm when the number
of hops on which a PNNI connection has failed exceeds the Max number of
crank backs threshold in the Alarms tab of the Expert UI Object Properties
dialog box.
The PNNI system reacts to a failed hop by rerouting (“cranking back”) the
connection via a different path from the Peer Group preceding the failure. The
Crankback Has Occurred alarm is call-specific at the ATM Connection layer
– the crankback occurred due to a fault on one of the links or nodes on which
the call has taken place.
PNNI is used to set up multi-hop connections (calls) between two ATM hosts
connected to switches which are members of the same PNNI domain. PNNI
domains consist of multiple peer groups – groups of switches that exchange
detailed routing database information with one another through the exchange
of PNNI Hello, Database Summary, and PTSE Request frames. Each peer
136
group in the PNNI domain receives a summary of the detailed information
exchanged within the other peer groups. In this way, each switch within a peer
group can set up and route calls destined for a different peer group without
needing to know the detailed information from that peer group – the routing
within a destination peer group is taken care of by that peer group.
Because of this, a call spanning several peer groups can fail at any peer group
border along the way. The crankback mechanism is used to reroute calls
around a failed node or link and is indicated in Q.2931 Release, Release
Complete, or Drop Party frames. Crankback occurs gradually – one link at a
time. In the worst case, it is possible for a call to “crank back” all the way to the
originating node for the call.
EFCI
The Expert generates the EFCI alarm when the percentage of frames on a
VPI.VCI with congestion (EFCI) indicated in at least one cell exceeds the Max
Percentage of Frames with EFCI threshold in the Alarms tab of the Expert UI
Object Properties dialog box. Congestion is indicated in the three bit payload
type identifier (PTI) in cell headers.
EFCI indicated and frames without EFCI indicated. When the percentage of
EFCI frames first exceeds the threshold, the Expert generates this alarm. Each
time the percentage of EFCI frames on the VPI.VCI re-exceeds the threshold,
the Expert either reopens the previous alarm or creates a new one depending
on how much time has elapsed between alarms.

Excessive Signaling Recovery
The Expert generates the Excessive Signaling Recovery alarm if the
number of one of the following signaling messages seen per second on the
signaling channel(s) exceeds the corresponding threshold in the Alarms tab of
the Expert UI Object Properties dialog box.

Max Q2931 STATs/sec – Alarm is generated if the number of Q.2931
STATUS and STATUS ENQUIRY messages per second exceeds this
threshold.

Max SSCOP Begin/sec – Alarm is generated if the number of SSCOP
Begin messages per second exceeds this threshold.

Max SSCOP Err/sec – Alarm is generated if the number of SSCOP
Error messages per second exceeds this threshold.
137
Chapter 1

Max SSCOP RS/sec – Alarm is generated if the number of SSCOP
Resynch messages per second exceeds this threshold.

Max SSCOP retrns/sec. – Alarm is generated if the number of SSCOP
retransmissions per second exceeds this threshold. Retransmissions
are counted when a receiving SSCOP entity sends a “long” status
message including list elements indicating that it did not receive all
messages from a sending station. When the sending station receives
this message, it is supposed to retransmit the unreceived messages.
The alarm display shows you the number of each type of message detected.
Missing DTL or Excessive DTL Size
The Expert generates the Missing DTL or Excessive DTL Size alarm if a
PNNI Call Setup message is detected which violates the PNNI standards.
Examples of this include:

Missing DTL

The DTL exceeds the maximum legal length of 20 node/port pairs.
The DTL is the Designated Transit List. It provides a complete path across
a PNNI peer group (a group of PNNI-enabled switches which have exchanged
detailed routing information) in the form of an ordered list of node/port pairs
across the peer group. Its presence is required in a PNNI Call Setup message.
MPCMPS Flow Not Allowed on this VC
The Expert generates the MPCMPS Flow Not Allowed on this VC alarm
when it detects an attempt to attach an MPC-MPS flow to a VCC which already
has an MPC-MPC flow on it (or vice-versa). It is illegal to multiplex both an
MPC-MPC flow and an MPC-MPS flow onto the same VCC.
Possible 3.0/3.1 UNI Mismatch
The Expert generates the Possible 3.0/3.1 UNI Mismatch alarm when it
detects a possible mismatch in signaling versions being used on the UNI.
Version 3.0 of the UNI specification does not provide explicit support for the
use of the N(SQ) field in the SSCOP BEGIN message, whereas Version 3.1
does. When SSCOP BEGIN messages are seen both using and not using this
field, the Expert generates this alarm.
Signaling Frame Sequence Problem
The Expert generates the Signaling Frame Sequence alarm in the following
situations:
138

A sequence of signaling frames was detected that did not match the
standard signaling rules (for example, a station receives a Call Setup
message and responds with the Connect Acknowledge message
instead of the Call Proceed or Call Connect message).

A sequence of signaling messages was not completed before a
timeout.
The alarm display provides a suspected sequence of messages leading up to
the alarm.
Unexpected Data for SVC
The Expert generates the Unexpected Data for SVC alarm when the number
of unexpected data packets seen for an SVC exceeds the Number of
unexpected data packets between alarms threshold in the ATM Connection
section of the Alarms tab of the Expert UI Object Properties dialog box.
The Expert considers a data packet to be unexpected when it is seen on an
SVC before the requisite signaling information for the SVC has been
exchanged. The analyzer counts these unexpected packets. When the total for
a given SVC exceeds the corresponding threshold, it generates the
Unexpected Data for SVC alarm.
The Expert displays the protocol sequence leading up to the unexpected data
packets so you can see what was missing. Consider the example shown in
Figure 1-6:
Figure 1-6. Sample Unexpected Data for SVC Alarm Display
In this example, an unexpected data packet was seen on the 0.216 SVC. The
Alarm Display shows the sequence of events that led up to the unexpected
data.

First, the Call Setup message was sent from the DCE side to initiate a
call.

The DTE side responded with the Call Proceed message, indicating
that call establishment had been initiated.

Then, the DTE sent the Call Connect message, indicating that the call
from the DCE had been accepted.
139
Chapter 1

Unfortunately, as the display shows, the DCE side went ahead and sent
data frames without first sending the Connect Acknowledge frame. The
analyzer considered this data to be unexpected since the Connect
Acknowledge message had not yet been sent. Accordingly, the alarm
was generated.
ATM Host Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the ATM Host layer.
Excessive Abnormal Disconnects
The Expert generates the Excessive Abnormal Disconnects alarm when the
number of connections disconnected abnormally for a host (either as a source
or as a destination) exceeds the Number of Disconnections between
Alarms (host level) threshold in the Alarms tab of the Expert UI Object
Properties dialog box. A connection is considered to have been disconnected
abnormally if it is disconnected with any disconnect cause code other than 16
or 31 (normal disconnects).
Each time a host experiences an abnormal disconnect, the Expert increments
a counter. When this counter exceeds the Number of Disconnections
between Alarms (host level) threshold, the Expert generates the Excessive
Abnormal Disconnects alarm for this host and resets the counter to 0 so that
counting can begin anew.
The Expert display shows you the disconnection that caused the alarm to be
generated (that is, the disconnection that put the counter over the threshold).
Excessive Abnormal Frame Sequences
The Expert generates the Excessive Abnormal Frame Sequences alarm
when the number of abnormal frame sequences for a given host (either as a
source or as a destination) exceeds the Number of Protocol Problems
between Alarms (host level) threshold in the ATM Host section of the Alarms
The Expert considers the following to be abnormal frame sequences:
140

A sequence of signaling frames was detected that did not match the
standard signaling rules (for example, a station receives a Call Setup
message and responds with the Connect Acknowledge message
instead of the Call Proceed or Call Connect message).

A sequence of signaling messages was not completed before a
timeout.
The analyzer counts these abnormal frame sequences. Each time the number
of sequences for a given host exceeds the threshold, the Expert generates the
Excessive Abnormal Frame Sequences alarm and resets the counter to
zero.
The alarm display lists each abnormal sequence of messages that caused the
alarm to be generated.
Excessive Short Connections
The Expert generates the Excessive Short Connections alarm for any host
(either as a source or as a destination) involved in a connection whose
duration is shorter than the Min Duration of session in msecs (host level)
threshold in the Alarms tab of the Expert UI Object Properties dialog box. The
analyzer detects short connections using the Q.2931 messages used on the
signaling channel to set up and tear down connections.
The alarm display provides the name (if known) and ATM address of the
source and destination hosts involved in the connection, as well as the
duration of the offending connection.
High Signaling Activity
The Expert generates the High Signaling Activity alarm if the number of one
of the following signaling messages seen per second for a particular host
(either as a source or as a destination) exceeds the corresponding threshold
in the Alarms tab of the Expert UI Object Properties dialog box.

Max Setups/sec (host level) – Alarm is generated if the number of
Q.2931 SETUP messages per second exceeds this threshold.

Max Q2931 STATs/sec – Alarm is generated if the number of Q.2931
STATUS messages per second exceeds this threshold.

Max Q2931 STAT ENQs/sec – Alarm is generated if the number of
Q.2931 STATUS ENQUIRY messages per second exceeds this
threshold.
The alarm display shows you the number (and rate) of each type of message
detected.
Host Address Cannot Be Mux’ed
The Expert generates the Host Address Cannot Be Multiplexed (“Mux’ed”)
alarm when it detects a LEC sharing an ATM address with some other LANE
entity (either a LES, a BUS, a LECS, or another LEC). This is a violation of the
LAN Emulation specification. The LES and the BUS can share the same ATM
address (along with the LECS), but the LEC cannot.
141
Chapter 1
Too Many Simultaneous Connections
The Expert generates the Too Many Simultaneous Connections alarm
when the number of simultaneous connections for a given host (either as a
source or as a destination) exceeds the Max simultaneous sessions (host
level) threshold in the Alarms tab of the Expert UI Object Properties dialog
box.
This alarm is a useful reminder when keeping tabs on stations that may
potentially be overloaded.
Unexpected Data for SVC (ATM Host Layer)
The Expert generates the Unexpected Data for SVC alarm when the number
of unexpected data packets for a given host (either as a source or as a
destination) exceeds the Number of unexpected data packets between
alarms threshold in the ATM Host section of the Alarms tab of the Expert UI
The Expert considers a data packet to be unexpected when it is seen on an
SVC before the requisite signaling information for the SVC has been
exchanged. Each time the analyzer sees such a packet, it increments a
separate counter for the source and the destination host on the connection.
When the total for a given host exceeds the corresponding threshold, the
analyzer generates the Unexpected Data for SVC alarm at the host level. It
also resets the counter for the named host so that counting can begin anew.
The Expert displays the protocol sequence leading up to the last unexpected
data packet that caused the alarm to be generated (for example, if the
threshold is set to 5, the sequence leading up to the fifth detected unexpected
data packet is shown). Consider the example shown in Figure 1-7:
Figure 1-7. Sample Unexpected Data for SVC Alarm Display (ATM Host Layer)
In this example, an unexpected data packet was seen on an SVC set up
between the named Source and Destination Hosts. The Alarm Display shows
the sequence of events that led up to the unexpected data.

142
First, the Call Setup message was sent from the DCE side to initiate a
call.

The DTE side responded with the Call Proceed message, indicating
that call establishment had been initiated.

Then, the DTE sent the Call Connect message, indicating that the call
from the DCE had been accepted.

Unfortunately, as the display shows, the DCE side went ahead and sent
data frames without first sending the Connect Acknowledge frame. The
analyzer considered this data to be unexpected since the Connect
Acknowledge message had not yet been sent. Accordingly, the alarm
was generated.
Wireless Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Wireless layer.
ACK Frame Timeout
The Expert generates the ACK Frame Timeout alarm when it does not see an
acknowledgment to a unicast management or data frame within the time
specified in the Duration field of the original management or data frame. When
this happens, the sending station will resend the original frame and wait for
another ACK.
Unicast management and data frames include a Duration field indicating the
amount of time within which a receiving station should return an ACK frame.
The value of this field is typically equal to the amount of time required to send
an ACK frame plus one short interframe space (SIFS). The Duration field lets
other stations on the network know that during this period, the medium is
reserved for the response to the frame.
The Expert stores the value specified in the Duration field in a buffer. If it does
not see the corresponding ACK to the frame (identified by matching sequence
numbers) within the value specified by the Duration field, it generates this
alarm.
Association Failure
The Expert generates the Association Failure alarm when it detects an
802.11 Association Response frame with a value other than zero in the Status
Code field. A non-zero value in the Status Code field indicates that the access
point sending the Association Response is denying the requested association.
143
Chapter 1
To be a member of an infrastructure 802.11 wireless network, wireless stations
must be associated with an access point. Wireless stations send Association
Request frames to become associated with an access point. In turn, access
points reply to Association Requests with Association Responses indicating
the success or failure of the request. In this case, the access point denied the
association request. The exact reason for the denial is found in the Status
Code field of the Association Response. The Expert reports both the address
of the access point denying the Association Request, as well as the reason for
the denial indicated in the Status Code field, as follows:

1 — Unspecified failure.

10 — Cannot support all requested capabilities in the Capability
Information field.

12 — Association denied due to reason outside the scope of the 802.11
standard.

17 — Association denied because the access point is unable to handle
additional associated stations.

18 — Association denied due to requesting station not supporting all of
the data rates in the BSSBasicRateSet parameter.
Authentication Failure
The Expert generates the Authentication Failure alarm when it detects an
802.11 Authentication frame with a value other than zero in the Status Code
field. A non-zero value in the Status Code field indicates that the access point
sending the Authentication frame is denying the requested authentication.
Wireless stations exchange Authentication frames with access points to
authenticate themselves with the network, thereby providing security and
privacy. The authentication sequence for 802.11 networks consists of the
exchange of either two authentication frames (for open system authentication)
or four authentication frames (for shared key authentication), each identified
by a transaction sequence number. The extra two authentication frames for
shared key authentication are for the exchange of a string of challenge text,
first sent in the clear by the access point and then returned in encrypted format
by the wireless station.
The Expert generates this alarm when the access point refuses to authenticate
the requesting wireless station. The exact reason for the denial is found in the
Status Code field of the Authentication frame. The Expert reports both the
address of the access point denying the Authentication, as well as the reason
for the denial indicated in the Status Code field, as follows:
144

13 — Responding station does not support the specified authentication
algorithm.

14 — Received an Authentication frame with authentication transaction
sequence number out of expected sequence.

15 — Authentication rejected because of challenge failure.

16 — Authentication rejected due to timeout waiting for next frame in
sequence.
CTS Frame Timeout
The Expert generates the CTS Frame Timeout alarm when it does not see a
clear to send (CTS) frame sent in response to a request to send (RTS) frame
within the time specified in the Duration field of the original RTS frame.
RTS frames include a Duration field indicating the amount of time within which
a receiving station should return a CTS frame. The value of this field is typically
equal to the amount of time required to send the CTS frame, one ACK frame,
and three short interframe spaces (SIFS). The Duration field lets other stations
on the network know that during this period, the medium is reserved.
When the Expert sees an RTS frame, it stores the value specified in the
Duration field in a buffer. If it does not see the corresponding CTS frame within
the value specified by the Duration field, it generates this alarm.
Deauthentication
The Expert generates the Deauthentication alarm when it detects an 802.11
Deauthentication frame. Occasionally, wireless stations need to terminate
secure communications with one another or with an access point. To do so,
they send Deauthentication frames.
Deauthentication frames are a part of normal 802.11 network operations. A
relatively small number of these alarms is no cause for concern. However, a
large number of Deauthentication frames may indicate a potential
authentication denial attack on the wireless network.

The destination address of the Deauthentication frame (that is, the
station with which the sending station want to terminate secure
communications).

The Reason Code indicating the reason the Deauthentication frame
was sent. Possible values for the Reason Code field are as follows:

1 — Unspecified reason.

2 — Previous authentication no longer valid.

3 — Deauthenticated because sending station is leaving (or has
left) the network.
145
Chapter 1

6 — Class 2 frame received from nonauthenticated station.
Disassociation
The Expert generates the Disassociation alarm when it detects an 802.11
Disassociation frame. Wireless stations and access points send
Disassociation frames to terminate associations with one another. For
example, an access point may terminate an association with a station because
it is unable to handle any more associations. Similarly, a wireless station may
terminate an association if it is leaving the network.
Disassociation frames are a part of normal 802.11 network operations. A
relatively small number of these alarms is no cause for concern. However, a
large number of Disassociation frames may indicate a potential denial of
service attack on the wireless network.

The destination address of the Disassociation frame (that is, the station
with which the sending station want to terminate its association).

The Reason Code indicating the reason the Disassociation frame was
sent. Possible values for the Reason Code field are as follows:

1 — Unspecified reason.

4 — Disassociated due to inactivity.

5 — Disassociated because the access point is unable to handle
all currently associated stations.

7 — Class 3 frame received from nonassociated station.

8 — Disassociated because sending station is leaving (or has left)
the network.

9 — Station requesting (re)association is not authenticated with
responding station.
Mcast/Bcast Fragmentation
The Expert generates the Mcast/Bcast Fragmentation alarm when it detects
an 802.11 frame with a multicast or broadcast destination address and
fragmentation indicated in the MAC header. This is a violation of the 802.11
specification.
Wireless networks commonly implement the fragmentation and
defragmentation services provided by the 802.11 MAC layer to increase
transmission reliability. However, the 802.11 specification does not allow
fragmentation for broadcast or multicast frames because of the overhead this
would cause for the network as a whole.
146
Missing Fragment Number
The Expert generates the Missing Fragment Number alarm when it detects
a jump in the fragment number of an 802.11 frame, indicating that a portion of
a fragmented data unit is at least temporarily missing.
Wireless networks commonly implement the fragmentation and
defragmentation services provided by the 802.11 MAC layer to increase
transmission reliability. When a unicast frame’s length exceeds an internal
threshold in the MAC’s MIB, the MAC will break up the frame into smaller
constituent frames — fragments — with the same sequence number.
Each fragment of a larger data unit is identified with a fragment number
indicating its intended ordered position within the reassembled data unit at the
receiving station. The Expert observes each transmitted fragment and stores
the fragment numbers. If it observes a jump in the fragment number for the
transmission of fragments with the same sequence number, it generates this
alarm.
Possible cause:

A relatively small number of these alarms is no cause for concern.
802.11 guarantees the sequential arrival of fragments at a receiving
station, but occasionally fragments may be missing due to interference
or other network problems. This is why the fragment number exists —
so that receiving stations can reassemble data units in the intended
order regardless of the sequence in which they arrive.
Because each fragment must be positively acknowledged by the
receiving station, 802.11 provides a mechanism to ensure that all
fragments eventually do arrive. If a sending station does not receive the
ACK for a fragment, it simply resends the fragment after an internal
timer expires. If the receiving station receives multiple copies of the
same fragment, it discards the excess copies of the fragment.
With this in mind, you can see that a large number of Missing
Fragment Number alarms may indicate significant interference on the
network. You should check the Dashboard to see if there are also a
large number of CRC errors on the network. If this is true, you may want
to adjust the fragment size used by the MAC to use smaller fragments
and see if this reduces the number of CRC errors on the network (and,
correspondingly, the amount of Missing Fragment Number alarms
generated).
Oversized WLAN Frame
The Expert generates the Oversized WLAN Frame alarm when it detects an
802.11 MAC frame longer than the maximum acceptable length dictated by the
802.11 specification.
147
Chapter 1
The maximum acceptable length for an 802.11 MAC frame is 2346 bytes.
Reassociation Failure
The Expert generates the Reassociation Failure alarm when it detects an
802.11 Reassociation Response frame with a value other than zero in the
Status Code field. A non-zero value in the Status Code field indicates that the
access point sending the Reassociation Response is denying the requested
association.
Wireless stations send Reassociation Request frames to become associated
with a different access point within the same network as its current access
point (for example, because the station has moved and is now out of range of
its old access point and within range of another). In turn, access points reply
to Reassociation Requests with Reassociation Responses indicating the
success or failure of the request. In this case, the access point denied the
Reassociation Request. The exact reason for the denial is found in the Status
Code field of the Reassociation Response. The Expert reports both the
address of the access point denying the Reassociation Request, as well as the
reason for the denial indicated in the Status Code field, as follows:

10 — Cannot support all requested capabilities in the Capability
Information field.

11 — Reassociation denied due to inability to confirm that association
exists.

12 — Association denied due to reason outside the scope of the 802.11
standard.

17 — Association denied because the access point is unable to handle
additional associated stations.

18 — Association denied due to requesting station not supporting all of
the data rates in the BSSBasicRateSet parameter.
Rogue Access Point
The Expert generates the Rogue Access Point alarm when it detects a
wireless access point on the network whose MAC address is not found in its
list of known access points. You can view the Expert's list of known access
points in the Known Access Points in the Network listbox in the 802.11
Options tab of the Expert Properties dialog box. You access this tab by
selecting Expert Options from the Tools menu and clicking on the 802.11
Options tab in the dialog box that appears.
148
The Rogue Access Point alarm provides you with a convenient means of
detecting access points on the network of which you were previously unaware.
To use this alarm effectively, you must add the MAC addresses of the known
access points on the network to the Expert's list. You can add access points to
the Expert's list in any of the following ways:

Automatically in the real-time Host Table by selecting entries in the
table, right-clicking, and selecting the Add to Known Mobile Unit List
command.

Automatically in the postcapture display's Expert tab by clicking the
Wireless Unit List button and using the options in the dialog box that
appears.

Automatically in the Address Book by clicking the Export AP button.

Manually in the Tools > Expert Options > 802.11 Options tab.
In addition, you must also have enabled the Enable Rogue AP Lookup option
on the 802.11 Options tab. When the Enable Rogue AP Lookup option is
enabled, each time the Expert discovers a new access point, it will compare its
MAC address to those in its list of known access points. If the discovered
address is not found, the Expert generates the Rogue Access Point alarm. In
addition, the Expert displays will identify the offending access point as a rogue
(the word “Rogue” will appear in parentheses following the station's entries in
Expert Summary and Detail displays).
Possible Cause:

In most cases, this is a relatively minor alarm, probably indicating
nothing more than that you neglected to add the address of a known
access point to the Expert's list. However, you may want to examine the
address of the access point indicated in the alarm to make sure that it
is not an intruder.
Rogue Mobile Unit
The Expert generates the Rogue Mobile Unit alarm when it detects a mobile
unit on the wireless network whose MAC address is not found in its list of
known mobile units. You can view the Expert's list of known mobile units in the
Known Mobile Units in the Network listbox in the 802.11 Options tab of the
Expert Properties dialog box. You access this tab by selecting Expert Options
from the Tools menu and clicking on the 802.11 Options tab in the dialog box
that appears.
The Rogue Mobile Unit alarm provides you with a convenient means of
detecting mobile units on the network of which you were previously unaware.
To use this alarm effectively, you must add the MAC addresses of the known
mobile units on the network to the Expert's list. You can add mobile units to the
Expert's list in any of the following ways:
149
Chapter 1

Automatically in the real-time Host Table by selecting entries in the
table, right-clicking, and selecting the Add to Known Mobile Unit List
command.

Automatically in the postcapture display's Expert tab by clicking the
Wireless Unit List button and using the options in the dialog box that
appears.

Manually in the Tools > Expert Options > 802.11 Options tab.
In addition, you must also have enabled the Enable Rogue Mobile Unit
Lookup option on the 802.11 Options tab. When the Enable Rogue Mobile
Unit Lookup option is enabled, each time the Expert discovers a new mobile
unit, it will compare its MAC address to those in its list of known mobile units.
If the discovered mobile unit is not found, the Expert generates the Rogue
Mobile Unit Detected alarm. In addition, the Expert displays will identify the
offending mobile unit as a rogue (the word “Rogue” will appear in parentheses
following the station's entries in Expert Summary and Detail displays).
Possible Cause
In most cases, this is a relatively minor alarm, probably indicating nothing more
than that you neglected to add the address of a known mobile unit to the
Expert's list. However, you may want to examine the address of the mobile unit
indicated in the alarm to make sure that it is not an intruder.
Runt WLAN Frame
The Expert generates the Runt WLAN Frame alarm when it detects an 802.11
MAC frame shorter than the minimum acceptable length dictated by the
802.11 specification.
The minimum acceptable length for an 802.11 MAC frame is 34 bytes.
However, some control and management frames are inherently smaller than
34 bytes. The Expert does not generate alarms for these frames.
Same Transmitter and Receiver Address
The Expert generates the Same Transmitter and Receiver Address alarm
when it detects an 802.11 MAC frame in which the transmitter and receiver
addresses indicated in the frame are the same.
150
Wireless LAN frames include up to four addresses in the standard 802.11 MAC
format depending on the type of frame. In addition to the Source and
Destination addresses (which refer to the original source of and the final
destination for the protocol data in the frame body field), 802.11 MAC frames
include Transmitter and Receiver addresses. These addresses are those of
the wireless stations responsible for transmitting the frame onto the wireless
medium (transmitter address) and the next recipient of the frame on the
wireless medium (receiver address).
The Expert generates this alarm if the transmitter and receiver addresses
within the frame are the same. If, however, the source and destination
addresses within the same frame are also the same, the Expert will also
generate the Same Source and Destination Address alarm at the Expert
DLC layer.
Transmitter Address Is Broadcast
The Expert generates the Transmitter Address Is Broadcast alarm when it
detects an 802.11 MAC frame with a broadcast address (all 1s) indicated in the
Transmitter Address field.
Transmitter Address Is Multicast
The Expert generates the Transmitter Address Is Multicast alarm when it
detects an 802.11 MAC frame with a multicast address indicated in the
Transmitter Address field.
WEP-ICV Error
The Expert generates the WEP-ICV Error alarm when it detects a
WEP-encrypted packet with an Integrity Check Value (ICV) which does not
match the ICV calculated by the Expert using its own WEP keys. This usually
happens when Sniffer® Technologies is configured with an incorrect set of
WEP keys.
In a wireless network using shared key authentication, each station on the
network is programmed with the same four WEP keys (1-4). Wireless stations
send WEP-encrypted packets with header fields indicating which of the four
shared WEP keys was used to encrypt the data. Receiving stations use the
shared key indicated in the packet’s header (1-4) for decryption and calculate
an expected Integrity Check Value (like a checksum for the encrypted data) to
compare against the ICV included in the received packet.
When Sniffer® Technologies detects a WEP-encrypted packet, it attempts to
decrypt the data using its own shared WEP keys specified on the 802.11 tab
of the Options dialog box (accessed from the Tools > Options menu). If the
ICV it calculates using its WEP keys does not match the ICV included in the
packet, the Expert generates this alarm.
151
Chapter 1
Possible causes:

The Expert is configured with WEP keys which do not match those in
use on the wireless network being analyzed. Go to the 802.11 tab of the
Options dialog box (accessed from the Tools > Options menu), and
make sure that the WEP keys specified there match those in use on the
network.

The station that sent the offending packet is configured with the wrong
WEP keys for the network. Make sure its keys are programmed
correctly.
Global Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Global layer.
Bad CRC
The Expert generates the Bad CRC alarm when a frame with a bad Cyclic
Redundancy Check (CRC) is detected. The CRC is a checksum calculated
from the contents of a packet. A CRC value is calculated at the source node
and appended to the packet. It is then recalculated from the received packet
by the destination node. If the two values are different, it indicates an error.
Possible causes:

When capturing from a wireless network, CRC errors appear routinely
because of multipass and attenuation distortions. This is a normal part
of wireless LAN operations and is not ordinarily a cause for concern.

A faulty device on the network.

A bad network interface card in a machine on the network.
Broadcast/Multicast Storm
The Expert generates the Broadcast/Multicast Storm alarm when the
number of broadcast or multicast frames per second exceeds the Broadcast
Frames/sec threshold under the Broadcast/Multicast Storm entry in the
Alarms tab of the Expert UI Object Properties dialog box, indicating that a
broadcast storm has been detected.
Possible causes:

152
This could be a temporary condition resulting from a valid broadcast or
multicast operation.

A workstation that does not have an adequate host table is sending
repeated RWHO packets. Change the workstation to assure that it
maintains a host table and stops sending RWHO packets.

The broadcast storm indicates some other underlying configuration
problem. If broadcast storms occur frequently, their causes should be
determined. A network can slow down considerably during such
storms.
Broadcast/Multicast Storm Diag
The Expert generates the Broadcast/Multicast Storm Diag alarm when the
number of broadcast or multicast frames per second exceeds the Broadcast
Frames/sec threshold under the Broadcast/Multicast Storm Diag entry in
the Alarms tab of the Expert UI Object Properties dialog box, indicating that a
severe broadcast storm has been detected.
If a broadcast storm diagnosis occurs, then a broadcast storm symptom will
also have occurred. Refer to the detailed information for that symptom.
Possible causes:

This could be a temporary condition resulting from a valid broadcast or
multicast operation.

A workstation that does not have an adequate host table is sending
repeated RWHO packets. Change the workstation to assure that it
maintains a host table and stops sending RWHO packets.

The broadcast storm indicates some other underlying configuration
problem. If broadcast storms occur frequently, their causes should be
determined. A network can slow down considerably during such
storms.
Channel Mismatch
The Expert generates the Channel Mismatch alarm in the following
situations:

In an infrastructure wireless network (a wireless network with access to
a distribution system), the Expert generates this alarm when it receives
beacon and/or probe response frames from an access point on a
channel other than the channel on which the access point is configured
to operate.

In an ad hoc wireless network (a wireless network with no access to a
distribution system), the Expert generates this alarm when it receives
beacon and/or probe response frames from a wireless station on a
channel other than the channel on which the station is operating.
153
Chapter 1
In an 802.11 infrastructure wireless network, access points send beacon
frames at a regular interval. In addition, they send probe response frames in
response to probe request frames sent from wireless stations wanting to join
the network. In an ad hoc network, the stations themselves send beacon and
probe request frames.
Among other parameters, beacon frames and probe requests specify the
wireless channel on which the basic service set (BSS) is operating. The
wireless stations in a single BSS can only operate on one channel at a time —
the channel on which the BSS is operating. However, due to adjacent channel
interference, wireless stations can occasionally receive frames from stations
operating on a different channel. The Expert generates the Channel
Mismatch alarm when this happens.
Collisions Over Threshold
The Expert generates the Collisions Over Threshold alarm when the number
of collisions detected exceeds the Collision Count threshold. A collision is the
result of two or more nodes attempting to use the medium at the same time.
Collisions are part of normal Ethernet behavior. However, a large number of
collisions can indicate a problem.
Possible cause:

Too many devices on the segment.
LAN Overload
The Expert generates the LAN Overload alarm when the data rate observed
on the network exceeds the percentage of available network bandwidth
specified by the LAN Load threshold.
Possible causes:

Multiple large file transfers are occurring simultaneously.

Many users are doing high volume work at the same time. This is
especially likely if it occurs at about the same time each day.

There is a defect that is causing a single station to do something
repetitive.

A router has recently been rebooted.
The remedy is approximately the same for all of these causes. Investigate
which devices are involved, and try to surmise whether the overload has
resulted from normal activity or from an error condition. Interpret this symptom
on a case-by-case basis.
154
LAN Overload Percentage
The Expert generates the LAN Overload Percentage alarm when during any
one-minute interval, the percentage of time the LAN is in an overloaded state
(the data rate was greater than the LAN Load threshold) exceeds the LAN
Overload % threshold.
Possible causes:

Multiple large file transfers are occurring simultaneously.

Many users are doing high volume work over the network at the same
time. This is especially likely if it occurs at about the same time each
day.

A single station is doing something repetitive.

A router has been rebooted recently.

There is a repeater, bridge, or router loop. This condition causes
severe LAN overload (for example, LAN utilization exceeding 80% of
bandwidth for more than 10 seconds).
The remedy is similar for all of these causes. Investigate which devices are
involved, and try to surmise whether the overload resulted from normal activity
or from an error condition. Interpret this diagnosis on a case-by-case basis.
If the network is chronically overloaded, and if this overload condition results
in unacceptable delay times, split your network into segments, or take other
measures to reduce network traffic.
PLCP Error
The Expert generates the PLCP Error alarm when a wireless station receives
a Physical Layer Convergence Protocol header with an invalid checksum.
Before frames are sent between wireless stations, the physical layer (PHY)
sends a PLCP header to a receiving station to negotiate the size of the frames
to be sent, the speed at which they should be sent, and so on. This PLCP
header includes a checksum that the receiving station uses to validate that the
received PLCP header is not corrupt. The Expert generates this alarm if it
detects that a station has received a PLCP header in which the checksum is
corrupt.
Spanning Tree Topology Change
The Expert generates the Spanning Tree Topology Change alarm when it
sees that a spanning tree bridge calculation has been done.
155
Chapter 1
Possible causes:

A bridge has gone up or come down somewhere on the logical LAN.

Someone has reconfigured a port cost or the priority of a bridge
somewhere on the logical LAN.

If changes are occurring at regular intervals, there is probably a
misconfigured bridge on the logical LAN.
Spanning tree bridges are also called “transparent” or “learning” bridges
because they take responsibility for learning where to forward traffic. Stations
on the network can be completely unaware of the bridges that connect several
physical segments into one logical LAN, yet everything still works.
The bridges also communicate among themselves, with BPDU messages.
These messages ensure that no disastrous “routing loops” exist, through
which bridges would endlessly forward the same frame from segment to
segment on the logical LAN. The bridges preclude such loop formation by
shutting off some of the ports on some of the bridges, as necessary, to
eliminate loops, while still maintaining full connectivity.
The bridges select one “root bridge” for the entire logical LAN, as a point of
reference, and one “local designated bridge” for each physical segment.
Typically, the root bridge is chosen on the basis of priority. The bridge
configured with the highest priority becomes the root. Ties are broken by
bridge id.
A local designated bridge is chosen based on the lowest “root path cost” – the
“cost” of sending a frame from that bridge to the root. A transmission cost is
associated with each port on each bridge. A high cost normally means a slow
link (for example, a 56 Kbps WAN connection inside the bridge to that port).
Conversely, a low cost usually means a fast link. These costs are typically
configurable. The “root path cost” for any bridge is the cost for that bridge to
send a frame from that bridge toward the root, plus the sum of the costs to
forward the frame for all the bridges between that bridge and the root bridge.
A root path cost of 0 implies that a bridge is the root.
Once a spanning tree has been done, the network settles into a steady state
in which the only BPDU messages being sent are “hello” messages advertising
the current spanning topology. These are sent periodically by each local
designated bridge (the root bridge specifies the “hello time” parameter, which
determines how often the hello messages are sent). These hellos are for the
benefit of any bridges that might be added to the network. Also, if the local
designated bridge goes down, the absence of hellos will enable the other
bridges on the segment to detect it. They would then initiate a new spanning
tree calculation, which would have the effect of working “around” the failed
bridge.
156
Once in the steady state only the local designated bridge will be sending BPDU
messages. Also, BPDU messages are never forwarded beyond the local
segment. Therefore, the analyzer will normally be aware of only one bridge –
the designated bridge on the segment to which it is attached – even if there are
other bridges on that segment.
However, if any significant bridge activities take place (such as a bridge being
added or going down) anywhere on the logical LAN (even if outside the local
segment), the Expert system will be aware of it. This is because the LAN-wide
spanning tree calculation must be done. The Expert analyzer presents a
complete record of these changes under the Alarms display at the Global
layer.
The “local initiator” of a change is the sender of the packet on the local
segment that first made the Expert system aware that a spanning calculation
was being done. This could be:

A CHANGE type BPDU message.

A hello packet containing new topology information.

A hello packet sent by someone other than the local designated bridge.
This may or may not be the actual bridge that caused the spanning tree
calculation, because the calculation itself may have been initiated
outside the local segment.
VLAN Not Operational
The Expert generates the VLAN Not Operational alarm when it sees a VTP
frame with a Status field set to 1, 2, or 3, indicating that the VLAN is not
operational. The meanings of these status fields are as follows:
1 – Suspended
2 – MTU (Maximum Transmission Unit) Too Big For Device
3 – MTU (Maximum Transmission Unit) Too Big For Trunk
The alarm display shows the value of the Status field that caused the alarm.
VLAN Removed from Domain
VTP advertisements announce the presence of all VLANs in a domain. The
Expert uses the information in these packets to maintain a list of VLANs it has
seen advertised in each domain. If a subsequent VTP advertisement includes
only a subset of the previously advertised VLANs, the Expert generates the
VLAN Removed from Domain alarm, indicating that a VLAN has been
removed from the domain.
157
Chapter 1
For example, suppose the Expert sees a VTP advertisement indicating the
presence of VLAN 1, VLAN 2, VLAN 3, and VLAN 4 in the Domain named
Perignon. If the Expert sees a subsequent VTP advertisement for Domain
Perignon with only VLAN 1 and VLAN 2, it will generate the VLAN Removed
from Domain alarm, indicating that VLAN 3 and VLAN 4 are no longer seen in
the domain.
The alarm display provides the VLAN ID of the VLAN that was removed.
VTP Versions Different
The Expert generates the VTP Versions Different alarm when it sees two
stations on the same VLAN send VTP frames with different VTP version fields.
To ensure proper operation, all stations on the same VLAN should use the
same version of VTP.
Route Layer Alarms and Thresholds
This section describes Expert alarms and thresholds at the Route layer.
Nonsense Route
The Expert generates the Nonsense Route alarm when a router advertises a
route that requires sending frames to a next hop address that is not on the local
subnet.
Possible causes:

This router has been configured with an IP address that is not valid on
the subnet.

This router is inappropriately forwarding routing information frames
from other routers onto this subnet.

The analyzer has not been configured properly to know its own subnet
address or addresses, and the automatic mechanism that the analyzer
uses to find these addresses has not been able to correct the problem.
Route Metric Changed
The Expert generates the Route Metric Changed alarm when it sees a router
broadcast a route indicating a metric change.
158
Possible cause:

A previously operating router or link in the path has failed, or a
previously failed router or link in the path has come back on line.
Route Superseded
The Expert generates the Route Superseded alarm when it sees a route
become the best route to a given destination or be superseded by another,
better route.
Possible causes:

The router changed the metric associated with this route, making it now
the best (or no longer the best) route.

The metric associated with another route to the same location changed,
making this route now the best (or not longer the best) route. Note that
if this is the case, then the entry on the history screen will indicate that
the change in this route's status was “dynamic.”
Route Validity Changed
The Expert generates the Route Validity Changed alarm when it sees a route
change from valid to invalid or vice versa.
Possible causes:

The router advertised this route as available but later advertised that
the route was unavailable (or vice versa).
The router advertised this route but later failed to confirm it before it expired.
159
Chapter 1
160
Index
A
AAL5 CRC Errors, 134
AAL5 Length Errors, 134
AAL5 Timeout Errors, 135
Abnormal Disconnect for SVC, 135
Abort Delimiter Transmitted, 82
AC Errors, 82
Access to Resource Denied, 15
ACK Frame Timeout, 143
Ack Too Long, 65
Alarm
Expert thresholds, 3
ALM_ApplicationH323IncompleteCall, 12
ALM_ApplicationSCCPIncompleteCall, 14
ALM_ApplicationSCCPTooManyCalls, 13
ALM_ApplicationSIPIncompleteCall, 15
ALM_ApplicationSIPTooManyCalls, 14
ALM_SesSlowFileTransfer, 56
ALM_SessTempCongestion, 56
Application Layer Alarms and Thresholds, 12
ARE or STE Frames on Data Direct VCC, 105
ARP Request Multi Queued, 105
Association Failure, 143
Async Status Change of Unknown DLCI, 95
ATM Application Layer Alarms and Thresholds, 100
ATM Connection Layer Alarms and Thresholds, 134
ATM Flow Layer Alarms and Thresholds, 105
ATM Host Layer Alarms and Thresholds, 140
Attempt to Bind DLC to MPC and Non-MPOA
Device, 105
Attempt to Bind L3 Address to Multiple MPOA
Devices, 100
Attempt to Multiply Bind MPOA Devices to LEC, 106
audience for this manual, xv
Authentication Failure, 144
B
Backward Congestion,
92
Bad CRC, 152
Broadcast/Multicast Data Frames on DDVCC,
Broadcast/Multicast Storm, 152
Broadcast/Multicast Storm Diag, 153
Browser Election Force, 15
Burst Errors, 82
106
C
Cache ID Set to Zero in DLL Header Ext, 106
CLP = 1, 136
Collision after 64 Bytes, 82
Collisions Over Threshold, 153
Config Fail, Insufficient Resources, 106
Config Frag Info TLV Not Recognized by LECS,
Config Request Multi Queued, 107
Config Request Response Timeout, 107
Config Request Retry Frame Mismatch, 108
Config Request Retry Rate Exceeds 1
Frame/sec, 108
Connection Layer Alarms and Thresholds, 65
Connection Too Short, 136
contacting Network General, xv
Control Request on DDVCC Retry Frame
Mismatch, 108
Control Request on DDVCC Retry Rate > 1
Frame/Sec, 109
Crankback Has Occurred, 136
CTS Frame Timeout, 145
107
D
Data Frames Detected Following Data Plane
Purge, 100
Database Summary Exchange Lockstep
Failure, 109
Database Summary Master/Slave Negotiation
Timeout, 109
DB Connect Request Denied, 16
DB Security Breach Attempt, 16
DB Slow Connect, 16
161
Index
DB Slow Server Response, 17
DB Slow Server Response Diagnosis, 18
DCE Sequence Number Error, 95
DDVCC Idle Period Exceeds VCC Timeout
C12, 101
DDVCC Not Created in Response to LE ARP, 101
Deauthentication, 145
Default MCFVCC Not Created in Response to LE
ARP, 101
Default MCSVCC Not Created in Response to LE
ARP, 102
Delayed STATUS ENQUIRY, 95
Denied Access to ELAN, 109
Diagnosis in Expert analysis, 1
Disassociation, 146
DLC Layer Alarms and Thresholds, 82
DLC Source Address Broadcast, 82
DLC Source Address Multicast, 83
DLL Header Extension Not Found in Frame, 110
DTE Sequence Number Error, 95
Duplicate Address Found, 83
Duplicate ATM Destination Address
Registration, 110
Duplicate LAN Destination Registration, 110
Duplicate Network Address, 72
Duplicate PDC Name Registration, 73
E
EFCI, 137
Egress Cache Tag Was Not Issued, 110
Exceeded CIR, 92
Excessive Abnormal Disconnects, 140
Excessive Abnormal Frame Sequences, 140
Excessive Failed Resource Login Attempts, 20
Excessive Mailslot Broadcasts, 20
Excessive Short Connections, 141
Excessive Signaling Recovery, 137
Excessive Unknown Frames Issued by LEC, 102
Expert
diagnoses, 1
symptoms, 1
thresholds, 3
162
F
Failed to Issue Resolution Req. Following
Trigger, 111
Failure Reported in Reply CIE, 111
Fast Retransmission, 65
FCI and ARI Bits Mismatch, 84
FCIP Invalid Encapsulation, 21
FCIP Repeat Special Frame, 21
FCIP Special Frame Delayed, 22
FCIP Special Frame Discovery, 20
FCIP Special Frame Echo Has Changed, 21
FCIP Too Many Special Frame Echoes, 22
FCIP Transmission Errors, 22
FDDI Ring Wrap, 84
File Retransmission, 53
Flush Request Multi Queued, 111
Forward Congestion, 92
Frame Has Alignment Problem, 85
Frame-Copied Errors, 85
Frames Seen on Default Flow After Shortcut
Active, 102
Frequency Errors, 85
FTP Login Attempts, 23
FTP Slow Connect, 23
FTP Slow First Response, 23
FTP Slow Response, 23
FTP Slow Transfer Diagnosis, 24
G
Global Layer Alarms and Thresholds,
152
H
H225 - Abnormal Disconnect, 34
H245 - Open Logical Channel Reject, 35
H245 - Terminal Capability Set Reject, 36
H323 - High Call Volume, 12
H323 - Too Many Incomplete Calls, 12
High Rate of Line/Burst Errors, 85
High Rate of Physical Errors, 86
High Rate of Receiver Congestion Errors, 86
High Rate of Ring Purge Diagnosis, 87
High Signaling Activity, 141
Host Address Cannot Be Mux’ed, 141
Index
HTTP Slow Server GET Response Time, 24
HTTP Slow Server POST Response Time, 24
Function Rejected, 27
Immediate Command Reject (Too Many
Immediate Commands), 27
Initiator Authentication Failed, 27
Invalid Data Ack, 27
Invalid During Login, 28
Invalid PDU field, 27
LUN Does Not Exist, 28
Miscellaneous Initiator Error, 28
Missing Parameter, 28
Service Unavailable, 28
Session Does Not Exist, 28
Target Error, 29
Target Failure, 29
Target Out of Resources, 29
Target Removed, 29
Task Does Not Exist, 29
Task Management Function Not Supported,
Too Many Connections, 30
Unsupported Version, 30
I
ICMP Destination Unreachable, 73
ICMP Host Unreachable, 73
ICMP Inconsistent Subnet Mask, 74
ICMP Net Unreachable, 74
ICMP Parameter Problem, 74
ICMP Port Unreachable, 75
ICMP Redirect for Host, 75
ICMP Redirect for Network, 75
ICMP Source Quench, 76
Idle Too Long, 66
IG Tag Violation, 111
Insufficient Info from LEC, Service Refused, 112
Invalid ATM Primary Address, 112
Invalid CIE Contents, 112
Invalid Client ATM Primary Source Address, 112
Invalid Client MAC Address, 113
Invalid Common Header Contents, 113
Invalid Fixed Header Contents, 114
Invalid Frame Contents, 114
Invalid Frame Status Field, 87
Invalid Hello Frame, 114
Invalid MPOA Packet Size, 115
Invalid Network Name, 25
Invalid Presentation Context ID, 53
Invalid Resource User Name or Password, 25
Invalid Tag in Data Frame Header, 116
IP Fragment Missing, 76
IP Fragment Out of Order, 76
IP NETBIOS Session Reject, 53
Irregular Full Status Report Requests, 96
iSCSI
Authorization Failure, 25
Can Not Generate Target Transfer Tag - Out of
Resources, 25
Command Not Supported in this Session
Type, 26
Command Retransmission, 26
Data Digest Error, 26
Data or Status again Requested, 26
Function Authorization Failed, 26
30
J
Join Request Multi Queued, 116
Join Request Received from LES, 116
Join Request Transmitted by LES, 116
Join Response Issued by LEC, 117
K
Keep Alive Lifetime Ext Not Found in Frame,
Keep Alive Lifetime Set to Zero, 117
Keep Alive Sequence Failure, 117
117
L
LAN Overload, 154
LAN Overload Percentage, 155
LANE Cfg Phase Failure, 102
LANE Cfg Restart Delay, 103
LANE Cfg Restart Delay > Max Recfg Delay, 104
LANE Control Request Response Timeout, 117
LANE Control Request Retry Rate > 1
Frame/sec, 118
LANE Control Request Retry Retry Frame
Mismatch, 118
LANE Version Unsupported by ELAN, 119
163
Index
LE ARP Request Rate Exceeds 1 Frame/Sec, 119
LE_CONFIGURE Params Conflict, Service
Refused, 119
LEC ID in Frame Mismatch with Client LEC ID, 120
LEC Issued Config Response to LECS, 119
LEC Not Recognized by LECS, 119
LECID Is Not 0x0000 in Request Frame, 120
LECS Issued Config Request to LES, 120
Line Errors, 87
Link Management Message Format Error, 96
Link Management Message Minor Format Error, 97
Local Limit on Defined Context Set Exceeded, 54
Local Routing, 66
Local Segment ID not in Source Routed Frame, 121
Local Station with Route Designator, 87
Loops on Same Request, 54
Lost Frame Errors, 88
Low Throughput, 54
NCP Server Busy, 31
Network Equipment Reset, 97
New Active Monitor, 88
New PVC Configured, 97
NFS Retransmission, 32
NNTP Slow Response Time, 32
No CIEs Were Present in MPOA Reply, 125
No CIEs Were Present in MPOA Request, 125
No Reply Flag Is Not Set in ICache Purge, 125
No Resolution Request Issued After Excess Default
Flow, 104
No STATUS ENQUIRY When Expected, 98
No STATUS following STATUS ENQUIRY, 98
Non-Responsive Station, 66
Nonsense Route, 158
O
Oversized Frame, 88
Oversized WLAN Frame,
147
M
MAC Address bound to Multiple LECs, 121
Max Transmission Unit Size Undefined, 121
Mcast/Bcast Fragmentation, 146
Misdirected Frame, 77
Missed Browser Announcement, 30
Missing DTL or Excessive DTL Size, 138
Missing Fragment Number, 147
Missing ULIA on Outside Link, 121
MPCMPS Flow Not Allowed on this VC, 138
MPOA Capable LEC Did Not Issue Device TLV, 122
MPOA Config Parameter Invalid, 122
MPOA Control Request Response Timeout, 122
MPOA Control Request Retry Rate > 1
Frame/sec, 123
MPOA Error Frame Detected, 124
MS RAP Logon Failure, 31
Multiple Local Ring Definition, 88
Multiple Routers to Local, 77
Multiple Routers to Remote, 78
Multiply Assigned Secondary LEC Address, 124
N
NARP Request Multi Queued, 124
NARP Request Received from LES,
164
125
P
PLCP Error, 155
POP3 Slow Connect Time, 32
Possible 3.0/3.1 UNI Mismatch, 138
Protocol Negotiation Failure, 32
PTSE Violation, 126
PVC Activation, 92, 98
PVC Bandwidth Change, 92, 98
PVC Congestion, 93, 98
PVC Deactivation, 93, 99
PVC Deletion, 93, 99
R
RAS - Admission Reject, 36
RAS - Bandwidth Reject, 38
RAS - Disengage Reject alarm, 38
RAS - Gatekeeper Reject, 38
RAS - Location Reject, 39
RAS - Registration Reject, 40
RAS - Unregistration Reject alarm, 41
Read/Write Overlap, 55
Reassociation Failure, 148
Receiver Congestion Errors, 88
Index
Register Request Multi Queued, 126
Register Request Received from LES, 126
Register Response Issued by LEC, 126
Remote Address Issued by Non Proxy LEC, 127
Repeat Ack, 67
Request Denied, 55
Request Params Are Incompatible with ELAN, 127
Retransmission, 67
Returned to Ring, 89
Ring Beaconing, 89
Ring Purge Symptom, 89
Rogue Access Point, 148
Rogue Mobile Unit, 149
Route Flapping, 78
Route Layer Alarms and Thresholds, 158
Route Metric Changed, 158
Route Superseded, 159
Route Validity Changed, 159
Router Not Updating Routes, 79
Router Storm, 79
Router Superseded Too Frequently, 79
RTCP - Report High Jitter, 41
RTP - High Jitter, 43
RTP - High Variation, 45
RTP - Too Many Dropped Frames, 46
RTP - Too Many Out of Sequence Frames, 47
Runt Frame, 90
Runt WLAN Frame, 150
Session Layer Alarms and Thresholds, 34
Shortcut Create Failed After Resolution Reply,
Signaling Frame Sequence Problem, 138
SIP - Client Error, 49
SIP - Global Error, 51
SIP - High Call Volume, 14
SIP - Server Error, 52
SIP - Server Slow Response, 52
SIP - Too Many Incomplete Calls, 15
Slow File Transfer, 56
Slow FTP Server, 6
Slow HTTP Server, 6
Slow Mail Server, 7
Slow News Server, 7
Slow Oracle SQL Server, 7
Slow POP3 Server, 9
Slow Server, 68
Slow Sybase/Microsoft SQL Server, 10
Slow Telnet Server, 11
SMTP Slow Connect Time, 33
Source Address Is Broadcast, 81
Spanning Tree Topology Change, 155
Station Internal Errors, 90
Station Not in Domain’s Computer List, 34
Station Off Ring, 90
Station Removed, 90
Symptom in Expert analysis, 1
104
T
S
Same Source and Destination Address, 90
Same Transmitter and Receiver Address, 150
SAP R3 Slow Server Connection, 33
SAP R3 Slow Server Response, 33
SCCP - High Call Volume, 13
SCCP - Register Reject, 49
SCCP - Register Reject alarm, 53
SCCP - Station Alarm, 49
SCCP - Too Many Incomplete Calls, 14
Server Running BDC Shutting Down, 80
Server Running PDC Shutting Down, 80
Server Running WINS Shutting Down, 80
Service Layer Alarms and Thresholds, 6
TA List Resources Exhausted, 127
TCP Fast Keepalive, 68
Telnet Slow Response to Login, 34
Temporary Congestion, 56
The Operation Number Is Greater than the Number of
Operations in the Interface, 57
The Output Parameters of the Operation Exceed
Their Declared Maximum Size, 57
The Request Is Being Rejected for Unspecified
Reasons, 57
The RPC Client or Server Protocol Has Been
Violated, 57
The Server Did Not Support the Requested
Authentication Level, 57
165
Index
The Server Does Not Implement the Requested
Operation for the Type of Requested Object, 57
The Server Does Not Support RPC Protocol
Version, 58
The Server Does Not Support the Interface, 57
The Server Does Not Support the Proposed Transfer
Syntax, 58
The Server Does Not Support the Requested
Interface, 57
The Server Is Too Busy To Handle the Call, 58
The Server Manager Routine Has Not Been Entered
and Executed, 58
Thresholds
Expert, 3
Time-to-live Exceeded in Transmit, 81
Time-to-live Expiring, 81
TNS Connect Refused, 58
TNS Security Breach Attempt, 58
TNS Slow Connect, 59
TNS Slow Server Diagnosis, 59
TNS Slow Server Response, 61
Token Errors, 91
Too Many File Retransmissions, 62
Too Many Loops on Same Request, 63
Too Many Removes, 91
Too Many Requests Denied, 63
Too Many Retransmissions, 69
Too Many Returns, 91
Too Many Simultaneous Connections, 142
Topology Change Request Multi Queued, 128
Topology Mismatch in Data Frame Types, 128
Traffic on Deleted DLCI, 93
Traffic on Inactive DLCI, 94
Traffic on Unknown DLCI, 94
Transmitter Address Is Broadcast, 151
Transmitter Address Is Multicast, 151
U
UDP Bouncing Frames, 69
Unexpected Data for SVC, 139
Unexpected Data for SVC (ATM Host Layer), 142
Unexpected DLL Header EXT in Frame, 128
Unexpected Egress Cache EXT in Frame, 128
Unexpected Hop Count EXT in Frame, 129
166
Unexpected Keepalive Lifetime EXT in Frame, 129
Unexpected Link Management Message, 99
Unexpected Original Error Code EXT in Frame, 129
Unexpected Service Category EXT in Frame, 129
Unexpected TLVs Detected, 130
Unknown Extension in Frame, 130
Unknown IG, 130
Unknown LANE ConfigControl Opcode, 130
Unknown Marker/Protocol Values, 131
Unknown/Unexpected Authenticate EXT in
Frame, 131
Unknown/Unexpected CIE in Frame, 131
Unregister Request Multi Queued, 131
Unregister Request Received from LES, 132
Unregister Response Issued by LEC, 132
Unsolicited STATUS Message, 99
User Equipment Reset, 100
V
V2 TLVs Issued in V1 ELAN, 132
Verify Request Multi Queued, 132
Verify Request Received from LES, 133
Verify Response Issued by LEC, 133
VLAN Not Operational, 157
VLAN Removed from Domain, 157
, 12 to 15, 34 to 36, 38 to 41, 43, 45 to 47, 49,
51 to 52
VTP Versions Different, 158
W
WAN Connection Layer Alarms and Thresholds,
WAN Link Layer Alarms and Thresholds, 95
WEP-ICV Error, 151
Window Frozen, 70
Window Size Exceeded, 70
WINS Duplicate Name, 64
WINS No Response, 64
Wireless Layer Alarms and Thresholds, 143
Wrong Report Type in STATUS Message, 100
Z
Zero Broadcast Address, 81
Zero MAC Address, 91
Zero Window Too Long, 70
92