Sniffer Pro and

Sniffer Distributed

Expert Alarms
Reference

Release 4.7
COPYRIGHT
Copyright © 2002 Networks Associates Technology, Inc. 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
Networks Associates Technology, Inc., or its suppliers or affiliate companies. To obtain this
permission, write to the attention of the Network Associates legal department at: 3965 Freedom
Circle, Santa Clara, California 95054, or call (972) 308-9960.

TRADEMARK ATTRIBUTIONS

ActiveSecurity, ActiveHelp, ActiveShield, Antivirus Anyware (and design), Bomb Shelter, Building a
World of Trust, Certified Network Expert, CipherLink, Clean-Up, Cleanup Wizard, Cloaking, CNX,
CNX Certification Certified Network Expert (and design), Compass 7, CyberCop, CyberMedia,
CyberMedia Uninstaller, Data Security Letter (and design), N Design (logo), Design (rabbit with hat),
Discover (and design), Disk Minder, Distributed Sniffer System, Distributed Sniffer System (in
Katakana), Dr Solomon’s, Dr Solomon’s (label), Enterprise Secure Cast, EZ Setup, First Aid,
ForceField, Gauntlet, GMT, GroupShield, Guard Dog, HelpDesk, Homeguard, Hunter, IC Expert,
ISDN Tel/Scope, LAN Administration Architecture (and design), LANGuru, LANGuru (in Katakana),
LANWords, Leading Help Desk Technology, LM 1, M (and design), Magic Solutions, Magic
University, MagicSpy, MagicTree, MagicWin, MagicWord, McAfee, McAfee (in Katakana), McAfee
(and design), McAfee Associates, MoneyMagic, More Power To You, Multimedia Cloaking, NetCrypto,
NetOctopus, NetRoom, NetScan, Net Shield, NetShield, NetStalker, Net Tools, Net Tools (in
Katakana), Network Associates, Network General, Network Uptime!, NetXRay, Notesguard, Nuts &
Bolts, Oil Change, PC Medic, PC Medic 97, PCNotary, PGP, PGP (Pretty Good Privacy), PocketScope,
Pop-Up, PowerTelnet, Pretty Good Privacy, PrimeSupport, RecoverKey, RecoverKey-International,
ReportMagic, Registry Wizard, RingFence, Router PM, Safe & Sound, SalesMagic, SecureCast, Service
Level Manager, ServiceMagic, Site Meter, Smart Desk, Sniffer, Sniffer (in Hangul), SniffMaster,
SniffMaster (in Hangul), Sniffmaster (in Katakana), SniffNet, Stalker, Stalker (stylized), Statistical
Information Retrieval (SIR), SupportMagic, Switch PM, TeleSniffer, TIS, TMach, TMeg, Total
Network Security, Total Network Visibility, Total Service Desk, Total Virus Defense, T-POD, T-POD
(stylized), Trusted Mach, Trusted Mail, UnInstaller, Virex, Virex-PC, Virus Forum, ViruScan,
VirusScan, VShield, WebScan, WebShield, WebSniffer, WebStalker, WebWall, Who’s Watching your
Network, Wingauge, ZAC 2000, and Zip Manager are registered trademarks of Network
Associates, Inc. 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.

LICENSE AGREEMENT
NOTICE TO ALL USERS: FOR THE SPECIFIC TERMS OF YOUR LICENSE TO USE THE
SOFTWARE THAT THIS DOCUMENTATION DESCRIBES, CONSULT THE LICENSE.TXT
OR OTHER LICENSE DOCUMENT THAT ACCOMPANIES YOUR SOFTWARE, EITHER AS
A TEXT FILE OR AS PART OF THE SOFTWARE PACKAGING. IF YOU DO NOT AGREE TO
ALL OF THE TERMS SET FORTH THEREIN, DO NOT INSTALL THE SOFTWARE. IF
APPLICABLE, YOU MAY RETURN THE PRODUCT TO THE PLACE OF PURCHASE FOR A
FULL REFUND.

Part Number: NAI-459-0050-2 Release 4.7, March, 2002

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Contacting Network Associates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv
Getting Help with Web Site Downloads . . . . . . . . . . . . . . . . . . . . . xvi
Virus Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Sniffer University Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
International Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Chapter 1. Expert Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . 1-1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
About Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
About Expert Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Expert Alarms and Thresholds Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Service Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Slow FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Slow HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Slow Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Slow News Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Slow Oracle SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Slow POP3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Slow Sybase/Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Slow Telnet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Application Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . 1-11
Access to Resource Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Browser Election Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
DB Connect Request Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
DB Security Breach Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
DB Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
DB Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

iii
Table of Contents

DB Slow Server Response Diagnosis . . . . . . . . . . . . . . . . . . . . . 1-14

Excessive Failed Resource Login Attempts . . . . . . . . . . . . . . . . 1-15
Excessive Mailslot Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
FTP Login Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
FTP Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
FTP Slow First Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
FTP Slow Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
FTP Slow Transfer Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
HTTP Slow Server GET Response Time . . . . . . . . . . . . . . . . . . . 1-17
HTTP Slow Server POST Response Time . . . . . . . . . . . . . . . . . . 1-18
Invalid Network Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Invalid Resource User Name or Password . . . . . . . . . . . . . . . . . 1-18
Missed Browser Announcement . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
MS RAP Logon Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
NCP Server Busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
NFS Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
NNTP Slow Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
POP3 Slow Connect Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Protocol Negotiation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
SAP R3 Slow Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
SAP R3 Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
SMTP Slow Connect Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Station Not in Domain’s Computer List . . . . . . . . . . . . . . . . . . . . 1-22
Telnet Slow Response to Login . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Session Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 1-23
File Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Invalid Presentation Context ID . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
IP NETBIOS Session Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Local Limit on Defined Context Set Exceeded . . . . . . . . . . . . . . 1-23
Loops on Same Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Low Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Read/Write Overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Request Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Slow File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Temporary Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26

iv Sniffer Pro and Sniffer Distributed

 Table of Contents

The Operation Number Is Greater than the Number of

Operations in the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
The Output Parameters of the Operation Exceed
Their Declared Maximum Size . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
The RPC Client or Server Protocol Has Been Violated . . . . . . . 1-27
The Request Is Being Rejected for Unspecified Reasons . . . . . 1-27
The Server Did Not Support the Requested
Authentication Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
The Server Does Not Support the Requested Interface . . . . . . . 1-27
The Server Does Not Implement the Requested
Operation for the Type of Requested Object . . . . . . . . . . . . . 1-27
The Server Does Not Support the Interface . . . . . . . . . . . . . . . . 1-27
The Server Does Not Support the Proposed
Transfer Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
The Server Does Not Support the RPC Protocol Version . . . . . 1-27
The Server Is Too Busy To Handle the Call . . . . . . . . . . . . . . . . 1-28
The Server Manager Routine Has Not Been
Entered and Executed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
TNS Connect Refused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
TNS Security Breach Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
TNS Slow Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
TNS Slow Server Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
TNS Slow Server Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Too Many File Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Too Many Loops on Same Request . . . . . . . . . . . . . . . . . . . . . . . 1-32
Too Many Requests Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33
WINS Duplicate Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33
WINS No Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . 1-35
Ack Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Fast Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Idle Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Local Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Non-Responsive Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Repeat Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37

Expert Alarms Reference v

Table of Contents

Slow Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37

Too Many Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
UDP Bouncing Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Window Frozen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Window Size Exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Zero Window Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Station Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 1-40
Duplicate Network Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40
Duplicate PDC Name Registration . . . . . . . . . . . . . . . . . . . . . . . . 1-41
ICMP Destination Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
ICMP Host Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
ICMP Inconsistent Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
ICMP Net Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
ICMP Parameter Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
ICMP Port Unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
ICMP Redirect for Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
ICMP Redirect for Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
ICMP Source Quench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
IP Fragment Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
IP Fragment Out of Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
Misdirected Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45
Multiple Routers to Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45
Multiple Routers to Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Route Flapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Router Not Updating Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Router Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47
Router Superseded Too Frequently . . . . . . . . . . . . . . . . . . . . . . . 1-47
Server Running BDC Shutting Down . . . . . . . . . . . . . . . . . . . . . . 1-47
Server Running PDC Shutting Down . . . . . . . . . . . . . . . . . . . . . . 1-48
Server Running WINS Shutting Down . . . . . . . . . . . . . . . . . . . . . 1-48
Source Address Is Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48
Time-to-live Exceeded in Transmit . . . . . . . . . . . . . . . . . . . . . . . 1-49
Time-to-live Expiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Zero Broadcast Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
DLC Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50

vi Sniffer Pro and Sniffer Distributed

 Table of Contents

Abort Delimiter Transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50

AC Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50
Burst Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50
Collision after 64 Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50
DLC Source Address Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . 1-50
DLC Source Address Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
Duplicate Address Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
FCI and ARI Bits Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52
Frame Has Alignment Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52
Frame-Copied Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52
Frequency Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52
High Rate of Line/Burst Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52
High Rate of Physical Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
High Rate of Receiver Congestion Errors . . . . . . . . . . . . . . . . . . 1-53
High Rate of Ring Purge Diagnosis . . . . . . . . . . . . . . . . . . . . . . . 1-54
Invalid Frame Status Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-54
Line Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-54
Local Station with Route Designator . . . . . . . . . . . . . . . . . . . . . . 1-54
Lost Frame Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Multiple Local Ring Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
New Active Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Oversized Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Receiver Congestion Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Returned to Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Ring Beaconing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Ring Purge Symptom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-56
Runt Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Same Source and Destination Address . . . . . . . . . . . . . . . . . . . . 1-57
Station Internal Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Station Off Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Station Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57
Token Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58
Too Many Removes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58
Too Many Returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58
Wireless Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 1-59

Expert Alarms Reference vii

Table of Contents

ACK Frame Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59

Association Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59
Authentication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-60
CTS Frame Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-61
Deauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-61
Disassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-62
Multicast/Broadcast Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 1-62
Missing Fragment Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-63
Oversized WLAN Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Reassociation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Rogue Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Runt WLAN Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-65
Same Transmitter and Receiver Address . . . . . . . . . . . . . . . . . . 1-65
Transmitter Address Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . 1-66
Transmitter Address Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-66
WEP-ICV Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-66
WAN Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . 1-67
Backward Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
Exceeded CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
Forward Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
PVC Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67
PVC Bandwidth Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68
PVC Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68
PVC Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68
PVC Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-68
Traffic on Deleted DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69
Traffic on Inactive DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69
Traffic on Unknown DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-69
WAN Link Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . 1-70
Async Status Change of Unknown DLCI . . . . . . . . . . . . . . . . . . . 1-70
DCE Sequence Number Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-70
Delayed STATUS ENQUIRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-70
DTE Sequence Number Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-71
Irregular Full Status Report Requests . . . . . . . . . . . . . . . . . . . . . 1-71
Link Management Message Format Error . . . . . . . . . . . . . . . . . . 1-71

viii Sniffer Pro and Sniffer Distributed

 Table of Contents

Link Management Message Minor Format Error . . . . . . . . . . . . 1-72

Network Equipment Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-72
New PVC Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
No STATUS ENQUIRY When Expected . . . . . . . . . . . . . . . . . . . . 1-73
No STATUS Following STATUS ENQUIRY . . . . . . . . . . . . . . . . . 1-73
PVC Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
PVC Bandwidth Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-73
PVC Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-74
PVC Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-74
PVC Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-74
Unexpected Link Management Message . . . . . . . . . . . . . . . . . . . 1-74
Unsolicited STATUS Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
User Equipment Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-75
Wrong Report Type in STATUS Message . . . . . . . . . . . . . . . . . . 1-75
ATM Application Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . 1-76
Attempt to Bind L3 Address to Multiple MPOA Devices . . . . . . 1-76
Data Frames Detected Following Data Plane Purge . . . . . . . . . . 1-76
DDVCC Idle Period Exceeds VCC Timeout C12 . . . . . . . . . . . . . 1-76
DDVCC Not Created in Response to LE ARP . . . . . . . . . . . . . . . 1-77
Default MCFVCC Not Created in Response to LE ARP . . . . . . . 1-77
Default MCSVCC Not Created in Response to LE ARP . . . . . . . 1-77
Excessive Unknown Frames Issued by LEC . . . . . . . . . . . . . . . . 1-78
Frames Seen on Default Flow After Shortcut Active . . . . . . . . . 1-78
LANE Cfg Phase Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-78
LANE Cfg Restart Delay < Min Recfg Delay . . . . . . . . . . . . . . . . 1-79
LANE Cfg Restart Delay > Max Recfg Delay . . . . . . . . . . . . . . . . 1-79
No Resolution Request Issued After Excess Default Flow . . . . 1-80
Shortcut Create Failed After Resolution Reply . . . . . . . . . . . . . . 1-80
ATM Flow Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . 1-81
ARE or STE Frames on Data Direct VCC . . . . . . . . . . . . . . . . . . . 1-81
ARP Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-81
Attempt to Bind DLC to MPC and Non-MPOA Device . . . . . . . . 1-81
Attempt to Multiply Bind MPOA Devices to LEC . . . . . . . . . . . . 1-82
Broadcast/Multicast Data Frames on DDVCC . . . . . . . . . . . . . . . 1-82
Cache ID Set to Zero in DLL Header Ext . . . . . . . . . . . . . . . . . . . 1-82

Expert Alarms Reference ix

Table of Contents

Config Fail, Insufficient Resources . . . . . . . . . . . . . . . . . . . . . . . 1-82

Config Frag Info TLV Not Recognized by LECS . . . . . . . . . . . . . 1-83
Config Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-83
Config Request Response Timeout . . . . . . . . . . . . . . . . . . . . . . . 1-83
Config Request Retry Frame Mismatch . . . . . . . . . . . . . . . . . . . . 1-84
Config Request Retry Rate Exceeds 1 Frame/sec . . . . . . . . . . . 1-84
Control Request on DDVCC Retry Frame Mismatch . . . . . . . . . 1-84
Control Request on DDVCC Retry Rate > 1 Frame/Sec . . . . . . . 1-85
Database Summary Exchange Lockstep Failure . . . . . . . . . . . . 1-85
Database Summary Master/Slave Negotiation Timeout . . . . . . . 1-85
Denied Access to ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-86
DLL Header Extension Not Found in Frame . . . . . . . . . . . . . . . . 1-86
Duplicate ATM Destination Address Registration . . . . . . . . . . . 1-86
Duplicate LAN Destination Registration . . . . . . . . . . . . . . . . . . . 1-86
Egress Cache Tag Was Not Issued . . . . . . . . . . . . . . . . . . . . . . . 1-87
Failed to Issue Resolution Req. Following Trigger . . . . . . . . . . 1-87
Failure Reported in Reply CIE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-87
Flush Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-87
IG Tag Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-88
Insufficient Info from LEC, Service Refused . . . . . . . . . . . . . . . . 1-88
Invalid ATM Primary Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-88
Invalid CIE Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
Invalid Client ATM Primary Source Address . . . . . . . . . . . . . . . . 1-89
Invalid Client MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-89
Invalid Common Header Contents . . . . . . . . . . . . . . . . . . . . . . . . 1-89
Invalid Fixed Header Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-90
Invalid Frame Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-90
Invalid Hello Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-91
Invalid MPOA MPS MAC Address Count in Device Type TLV . . 1-91
Invalid MPOA Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-92
Invalid Tag in Data Frame Header . . . . . . . . . . . . . . . . . . . . . . . . 1-92
Join Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-92
Join Request Received from LES . . . . . . . . . . . . . . . . . . . . . . . . 1-92
Join Request Transmitted by LES . . . . . . . . . . . . . . . . . . . . . . . . 1-93
Join Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-93

x Sniffer Pro and Sniffer Distributed

 Table of Contents

Keep Alive Lifetime Set to Zero . . . . . . . . . . . . . . . . . . . . . . . . . . 1-93

Keep Alive Sequence Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-93
Keep Alive Lifetime Ext Not Found in Frame . . . . . . . . . . . . . . . 1-94
LANE Control Request Response Timeout . . . . . . . . . . . . . . . . . 1-94
LANE Control Request Retry Retry Frame Mismatch . . . . . . . . 1-94
LANE Control Request Retry Rate > 1 Frame/sec . . . . . . . . . . . 1-95
LANE Version Unsupported by ELAN . . . . . . . . . . . . . . . . . . . . . 1-95
LE ARP Request Rate Exceeds 1 Frame/Sec . . . . . . . . . . . . . . . 1-95
LE_CONFIGURE Params Conflict, Service Refused . . . . . . . . . 1-95
LEC Issued Config Response to LECS . . . . . . . . . . . . . . . . . . . . 1-96
LEC Not Recognized by LECS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-96
LEC ID in Frame Mismatch with Client LEC ID . . . . . . . . . . . . . . 1-97
LECID Is Not 0x0000 in Request Frame . . . . . . . . . . . . . . . . . . . . 1-97
LECS Issued Config Request to LES . . . . . . . . . . . . . . . . . . . . . . 1-97
Local Segment ID not in Source Routed Frame . . . . . . . . . . . . . 1-97
MAC Address bound to Multiple LECs . . . . . . . . . . . . . . . . . . . . 1-98
Max Transmission Unit Size Undefined . . . . . . . . . . . . . . . . . . . . 1-98
Missing ULIA on Outside Link . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-98
MPOA Capable LEC Did Not Issue Device TLV . . . . . . . . . . . . . 1-98
MPOA Config Parameter Invalid . . . . . . . . . . . . . . . . . . . . . . . . . . 1-99
MPOA Control Request Response Timeout . . . . . . . . . . . . . . . . 1-99
MPOA Control Request Retry Rate > 1 Frame/sec . . . . . . . . . . 1-100
MPOA Error Frame Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-100
Multiply Assigned Secondary LEC Address . . . . . . . . . . . . . . . 1-101
NARP Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-101
NARP Request Received from LES . . . . . . . . . . . . . . . . . . . . . . 1-102
No CIEs Were Present in MPOA Reply . . . . . . . . . . . . . . . . . . . 1-102
No CIEs Were Present in MPOA Request . . . . . . . . . . . . . . . . . 1-102
No Reply Flag Is Not Set in ICache Purge . . . . . . . . . . . . . . . . . 1-102
PTSE Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-102
Register Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . 1-103
Register Request Received from LES . . . . . . . . . . . . . . . . . . . . 1-103
Register Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . 1-103
Remote Address Issued by Non Proxy LEC . . . . . . . . . . . . . . . 1-104
Request Params Are Incompatible with ELAN . . . . . . . . . . . . . 1-104

Expert Alarms Reference xi

Table of Contents

TA List Resources Exhausted . . . . . . . . . . . . . . . . . . . . . . . . . . 1-105

Topology Change Request Multi Queued . . . . . . . . . . . . . . . . . 1-105
Topology Mismatch in Data Frame Types . . . . . . . . . . . . . . . . . 1-105
Unexpected DLL Header EXT in Frame . . . . . . . . . . . . . . . . . . . 1-105
Unexpected Egress Cache EXT in Frame . . . . . . . . . . . . . . . . . 1-106
Unexpected Hop Count EXT in Frame . . . . . . . . . . . . . . . . . . . . 1-106
Unexpected IG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-106
Unexpected Keepalive Lifetime EXT in Frame . . . . . . . . . . . . . 1-106
Unexpected Original Error Code EXT in Frame . . . . . . . . . . . . 1-106
Unexpected Service Category EXT in Frame . . . . . . . . . . . . . . 1-107
Unexpected TLVs Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-107
Unknown Extension in Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 1-107
Unknown IG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-107
Unknown LANE Config\Control Opcode . . . . . . . . . . . . . . . . . . 1-108
Unknown Marker/Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 1-108
Unknown/Unexpected Authenticate EXT in Frame . . . . . . . . . 1-108
Unknown/Unexpected CIE in Frame . . . . . . . . . . . . . . . . . . . . . 1-108
Unregister Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . 1-108
Unregister Request Received from LES . . . . . . . . . . . . . . . . . . 1-109
Unregister Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . 1-109
V2 TLVs Issued in V1 ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-109
Verify Request Multi Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-110
Verify Request Received from LES . . . . . . . . . . . . . . . . . . . . . . 1-110
Verify Response Issued by LEC . . . . . . . . . . . . . . . . . . . . . . . . . 1-110
ATM Connection Layer Alarms and Thresholds . . . . . . . . . . . . . . . . 1-111
AAL5 CRC Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-111
AAL5 Length Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-111
AAL5 Timeout Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-112
Abnormal Disconnect for SVC . . . . . . . . . . . . . . . . . . . . . . . . . . 1-112
CLP = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-113
Connection Too Short . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-113
Crankback Has Occurred (ATM Connection Layer) . . . . . . . . . 1-113
EFCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-114
Excessive Signaling Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 1-114
Missing DTL or Excessive DTL Size . . . . . . . . . . . . . . . . . . . . . 1-115

xii Sniffer Pro and Sniffer Distributed

 Table of Contents

MPCMPS Flow Not Allowed on this VC . . . . . . . . . . . . . . . . . . . 1-115

Possible 3.0/3.1 UNI Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . 1-116
Signaling Frame Sequence Problem . . . . . . . . . . . . . . . . . . . . . 1-116
Unexpected Data for SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-116
ATM Host Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . 1-118
Excessive Abnormal Disconnects . . . . . . . . . . . . . . . . . . . . . . . 1-118
Excessive Abnormal Frame Sequences . . . . . . . . . . . . . . . . . . 1-118
Excessive Short Connections . . . . . . . . . . . . . . . . . . . . . . . . . . 1-119
High Signaling Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-119
Host Address Cannot Be Mux’ed . . . . . . . . . . . . . . . . . . . . . . . . 1-119
Too Many Simultaneous Connections . . . . . . . . . . . . . . . . . . . . 1-120
Unexpected Data for SVC (ATM Host Layer) . . . . . . . . . . . . . . . 1-120
ATM Link Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . 1-122
Attempt to Set Up Multiple SVCC RCCs . . . . . . . . . . . . . . . . . . 1-122
Crankback Has Occurred (ATM Link Layer) . . . . . . . . . . . . . . . 1-122
Excessive Hello Frames Detected . . . . . . . . . . . . . . . . . . . . . . . 1-123
Link Inactivity Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-123
Protocol Version Support Incompatible . . . . . . . . . . . . . . . . . . 1-123
Routing Frames Detected on Outside Link . . . . . . . . . . . . . . . . 1-124
SVCC RCC Dropped . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-124
ATM Node Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . 1-125
Address Scoping Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-125
Crankback Has Occurred (ATM Node Layer) . . . . . . . . . . . . . . 1-125
Host Bound to Multiple Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 1-126
Invalid Port ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-126
Parent Node Association Change . . . . . . . . . . . . . . . . . . . . . . . 1-127
Peer Group ID Has Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-127
Peer Group Leader Has Changed . . . . . . . . . . . . . . . . . . . . . . . 1-127
PTSE Acknowledge Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-127
PTSE Request Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-128
Restricted Branching Violation . . . . . . . . . . . . . . . . . . . . . . . . . 1-128
Global Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 1-129
Bad CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-129
Broadcast/Multicast Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-129
Broadcast/Multicast Storm Diag . . . . . . . . . . . . . . . . . . . . . . . . 1-130

Expert Alarms Reference xiii

Table of Contents

Channel Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-130

Collisions Over Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-131
LAN Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-131
LAN Overload Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-131
PLCP Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-132
Spanning Tree Topology Change . . . . . . . . . . . . . . . . . . . . . . . 1-132
VLAN Not Operational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-134
VLAN Removed from Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-134
VTP Versions Different . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-135
Route Layer Alarms and Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 1-135
Nonsense Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-135
Route Metric Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-135
Route Superseded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-136
Route Validity Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-136

Appendix A. Network Associates Support Services . . . . . . . . . . . . . . A-1

Adding Value To Your Network Associates Product . . . . . . . . . . . . . . . . . . .A-1
PrimeSupport Options for Corporate Customers . . . . . . . . . . . . . . . . .A-1
The PrimeSupport KnowledgeCenter Plan . . . . . . . . . . . . . . . . . .A-1
The PrimeSupport Connect Plan . . . . . . . . . . . . . . . . . . . . . . . . . .A-2
The PrimeSupport Priority Plan . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3
The PrimeSupport Enterprise Plan . . . . . . . . . . . . . . . . . . . . . . . .A-4
Ordering a Corporate PrimeSupport Plan . . . . . . . . . . . . . . . . . . . . . . .A-5
Network Associates Consulting and Training . . . . . . . . . . . . . . . . . . . . . . . .A-7
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-7
Jumpstart Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-8
Network Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-8
Educational Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-9

Index

xiv Sniffer Pro and Sniffer Distributed

Preface

About This Manual

This manual 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 both Sniffer Pro and Sniffer Distributed. For
information about Sniffer Pro\Sniffer Distributed and how to use their
Expert features, refer to the Getting Started Guide and the online help files.

Contacting Network Associates

Customer Service
For questions, comments, or requests concerning the software or
hardware you purchased, your registration status, or similar issues,
contact the Network Associates Customer Service department. The
department hours of operation are 8:00 AM to 8:00 PM Central time,
Monday through Friday.

Table i. Contact Information for Corporate-licensed Customers

Phone (800) SNIFFER (800- 764-3337)

E-Mail [email protected]
Web http://www.nai.com
Mail Network Associates Customer Service
13465 Midway Rd.
Dallas, Texas 75244
USA

Technical Support
Network Associates is dedicated to customer satisfaction. We provide
answers to technical support issues on the following World Wide Web
site: http://www.support.nai.com

If the automated web services do not have the answers you need,
corporate-licensed customers can call 1-800-SNIFFER (1-800-764-3337)
Monday through Friday between 8:00 AM and 8:00 PM Central time to
contact Network Associates.

xv
Preface

To provide the answers you need quickly and efficiently, the Network
Associates technical support staff needs some information about your
computer and software. Please have this information ready before you
call:
• Sniffer product name and version number
• Computer brand and model
• Additional hardware or peripherals connected to your computer
• Operating system and version number(s)
• Network type and version, if applicable
• Contents of your AUTOEXEC.BAT, CONFIG.SYS, and system
LOGIN script
• Specific steps to reproduce the problem

Getting Help with Web Site Downloads

To get help with navigating or downloading files from the Network
Associates Web sites or FTP sites, call Corporate Customer Support at
1-972-308-9960.

Virus Scan Information

Sniffer Technologies scans all Sniffer Appliances and servers with McAfee
Virus Scan as part of our manufacturing process. All products are shipped
to customers virus-free.

Sniffer products are typically installed within the corporate infrastructure

where known viruses have been eliminated, therefore there is little value
in installing anti-virus software on Sniffer units. Installing such software
is not supported and may adversely affect system performance.

Sniffer Technologies continues to test released software with updates and

patches to Microsoft software. A list of supported versions is available
through Tech Support. We encourage our customers to periodically
update their units with the latest supported Microsoft patches.

Sniffer University Training

Since 1991, over 70,000 customers have completed Sniffer University
training. Our customers typically are Network Administrators, Field
Technicians, Network Managers, and Technical Support personnel for
medium to large size companies that proactively manage and
troubleshoot expanding networks.

xvi Sniffer Pro and Sniffer Distributed

 Preface

Customers find our education to be of great value in enhancing and

updating their skills as well as providing an opportunity for achieving a
Sniffer-specific certification through the Sniffer Certified Professional
Program (SCPP).

We provide complete course and registration information regarding

Sniffer University worldwide training and certification on our World
Wide Web site: http://www.sniffer.com/education/default.asp

Expert Alarms Reference xvii

Preface

International Contact Information

To contact Network Associates outside the United States, use the
addresses, phone and fax numbers listed in Table ii.

Table ii. International Offices

Location Name Address Phone and Fax

Australia Network Associates Level 1, 500 Pacific Highway Phone:

Australia St. Leonards, NSW 61-2-8425-4200
Sydney, Australia 2065 Fax:
61-2-9439-5166
Austria Network Associates Pulvermuehlstrasse 17 Phone:
Austria Linz, Austria 43-732-757-244
Postal Code A-4040 Fax:
43-732-757-244-20
Belgium Network Associates BDC Heyzel Esplanade, boîte Phone:
Belgique 43 0032-2 478.10.29
1020 Bruxelles Fax:
Belgique 0032-2 478.66.21
Brazil Network Associates Rua Geraldo Flausino Gomez Phone:
do Brasil 78 (55 11) 5505 1009
Cj. - 51 Brooklin Novo - São Fax:
Paulo (55 11) 5505 1006
SP - 04575-060 - Brasil
Canada Network Associates 139 Main Street, Suite 201 Phone:
Canada Unionville, Ontario (905) 479-4189
Canada L3R 2G6 Fax:
(905) 479-4540
China Network Associates New Century Office Tower, Phone:
People’s Republic of Room 1557 8610-6849-2650
China No. 6 Southern Road Capitol Fax:
Gym 8610-6849-2069
Beijing
People’s Republic of China
100044
Denmark Network Associates Lautruphoej 1-3 Phone:
Denmark 2750 Ballerup 45 70 277 277
Danmark Fax:
45 44 209 910
Finland NA Network Mikonkatu 9, 5. krs. Phone:
Associates Oy 00100 Helsinki 358 9 5270 70
Finland Fax:
358 9 5270 7100

xviii Sniffer Pro and Sniffer Distributed

 Preface

Table ii. International Offices

Location Name Address Phone and Fax

France Network Associates 50 Rue de Londres Phone:

France S.A. 75008 Paris 33 1 44 908 737
France Fax:
33 1 45 227 554
Germany Network Associates Ohmstraße 1 Phone:
Deutschland GmbH D-85716 Unterschleißheim 49 (0)89/3707-0
Deutschland Fax:
49 (0)89/3707-1199
Hong Kong Network Associates 19th Floor, Matheson Centre Phone:
Hong Kong 3 Matheson Way 852-2832-9525
Causeway Bay Fax:
Hong Kong 63225 852-2832-9530
Italy Network Associates Srl Centro Direzionale Summit Phone:
Palazzo D/1 39 02 92 65 01
Via Brescia, 28 Fax:
20063 - Cernusco sul Naviglio 39 02 92 14 16 44
(MI)
Italy
Japan Network Associates Shibuya Mark City West 20F Phone:
Japan, Inc. 1-12-1 Dougenzaka, 81 3 5428 1100
Shibuya-ku Fax:
Tokyo 150-0043, Japan 81 3 5428 1480
Latin America Network Associates 1200 S. Pine Island Road, Suite Phone:
Latin America 375 (954) 452-1731
Plantation, Florida 33324 Fax:
United States (954) 236-8031
Mexico Network Associates Andres Bello No. 10, 4 Piso Phone:
de Mexico 4th Floor (525) 282-9180
Col. Polanco Fax:
Mexico City, Mexico D.F. 11560 (525) 282-9183
The Network Associates Gatwickstraat 25 Phone:
Netherlands International B.V. 1043 GL Amsterdam 31 20 586 6100
The Netherlands Fax:
31 20 586 6101
Portugal Network Associates Av. da Liberdade, 114 Phone:
Portugal 1269-046 Lisboa 351 1 340 4543
Portugal Fax:
351 1 340 4575

Expert Alarms Reference xix

Preface

Table ii. International Offices

Location Name Address Phone and Fax

South Africa Net Tools Network Hawthorne House Phone:

Associates St. Andrews Business Park 27 11 700-8200
South Africa Meadowbrook Lane Fax:
Bryanston, Johannesburg 27 11 706-1569
South Africa 2021
South East Network Associates 78 Shenton Way Phone:
Asia South East Asia #29-02 65-222-7555
Singapore 079120 Fax:
65-220-7255
Spain Network Associates Orense 4, 4a Planta. Phone:
Spain Edificio Trieste 34 9141 88 500
28020 Madrid, Spain Fax:
34 9155 61 404
Sweden Network Associates Datavägen 3A Phone:
Sweden Box 596 46 (0) 8 580 88 400
S-175 26 Järfälla Fax:
Sweden 46 (0) 8 580 88 405
Switzerland Network Associates Baeulerwisenstrasse 3 Phone:
AG 8152 Glattbrugg 0041 1 808 99 66
Switzerland Fax:
0041 1 808 99 77
Taiwan Network Associates Suite 6, 11F, No. 188, Sec. 5 Phone:
Taiwan Nan King E. Rd. 886-2-27-474-8800
Taipei, Taiwan, Republic of Fax:
China 886-2-27-635-5864
United Network Associates 227 Bath Road Phone:
Kingdom International Ltd. Slough, Berkshire 44 (0)1753 217 500
SL1 5PP Fax:
United Kingdom 44 (0)1753 217 520

xx Sniffer Pro and Sniffer Distributed

Expert Alarms and Thresholds 1

1
Overview
This manual describes the Expert alarms generated by the Sniffer Pro
along with their corresponding thresholds. You can use this manual to
improve your understanding of Expert alarms, as well as how to configure
the thresholds that determine when they are generated.

Alarms in this manual 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 Sniffer Pro 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
Sniffer Pro 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, as shown in Figure 1–1.

1-1
Expert Alarms and Thresholds

Expert alarm counts

Selecting an alarm in the Summary
are provided at each
Pane lets you see detailed alarm
layer in the Overview
information in the Detail Pane
Pane of the Expert
(including a “?' link to the Expert
display.
Explain file for the alarm).

Figure 1–1. Expert Alarms in the Expert Display

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.

To change Expert thresholds, select Expert Options from the Tools menu
and click the Alarms tab. The Alarms tab lists all Expert alarms by layer,
along with their corresponding thresholds. The Alarms tab is shown in
Figure 1–2.

The default thresholds supplied with Sniffer Pro 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.

1-2 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Click to set the severity of this

Click to expand/collapse alarm. Different severities can be Click to specify whether the alarm
all Expert layers associated with different actions. should appear in the alarm log.

Click the + to open

an Expert layer and
display all
symptoms and
diagnoses (alarms) 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 Click to reset all settings for all
the factory default. layers to the factory defaults

Figure 1–2. Setting Expert Thresholds

Expert Alarms Reference 1-3

Expert Alarms and Thresholds

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–2. 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 1–5

Application Layer page 1–11
Session Layer page 1–23
Connection Layer page 1–35
Station Layer page 1–40
DLC Layer page 1–50
Wireless Layer page 1–59
WAN Cnx Layer page 1–67
WAN Link Layer page 1–70
ATM Application Layer page 1–76
ATM Flow Layer page 1–81
ATM Connection Layer page 1–111
ATM Host Layer page 1–118
ATM Link Layer page 1–122
ATM Node Layer page 1–125
Global Layer page 1–129
Route Layer page 1–135

1-4 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. There is a problem with the FTP server.
2. There is excessive network congestion.

Slow HTTP Server

The Expert generates this alarm when the average transaction time
observed for an HTTP server exceeds the Slow Internet 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 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:
1. The network is experiencing congestion.
2. The web server is overloaded.

Expert Alarms Reference 1-5

Expert Alarms and Thresholds

Slow Mail Server

The Expert generates this alarm when the average transaction time
observed for a SMTP server exceeds the Slow Mail 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 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:
1. There is a problem with the SMTP server.
2. There is excessive network congestion.

Slow News Server

The Expert generates this alarm when the average transaction time
observed for an NNTP server exceeds the Slow News 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 NNTP server). For each transaction the server
takes part in (for example, logins, ARTICLE 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 NNTP server exceeds the Slow News Server Time
threshold, the Expert generates this alarm.

Possible causes:
1. There is a problem with the NNTP server.
2. There is excessive network congestion.

Slow Oracle SQL Server

The Expert generates this alarm when the average transaction time
observed 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 tab of the Expert UI Object Properties dialog box.

1-6 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

At the Service layer, the Expert observes transactions for individual

servers (in 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:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.
b. 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.
c. Determine if your server has enough memory to support the
applications and services that have to run concurrently.
d. Install faster disk drives.
4. 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:

Expert Alarms Reference 1-7

Expert Alarms and Thresholds

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

reparsing.
b. Optimize the size of the DB_BLOCK_BUFFERS.
c. Increase the value of DML_LOCKS to allow more locks placed on
an object at one time.
d. Determine your library cache misses and set the
CURSOR_SPACE_FOR_TIME according to the recommendation
in the Oracle7 Server Administrator’s Guide.
e. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
columns.
5. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.
e. Identical query statements in your application must match
character-by-character to use the same shared pool area.

Slow POP3 Server

The Expert generates this alarm when the average transaction time
observed for a POP3 server exceeds the Slow POP 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, a POP3 server). For each transaction the server takes
part in (for example, logins, send 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 POP3 server exceeds the Slow POP Server Time
threshold, the Expert generates this alarm.

Possible causes:
1. There is a problem with the POP3 server.
2. There is excessive network congestion.

1-8 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Slow Sybase/Microsoft SQL Server

The Expert generates this alarm when the average transaction time
observed 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 tab of the Expert UI Object Properties dialog box.

At the Service layer, the Expert observes transactions for individual

servers (in 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 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 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:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.
b. 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.

Expert Alarms Reference 1-9

Expert Alarms and Thresholds

c. Determine if your server has enough memory to support the

applications and services that have to run concurrently.
d. Install faster disk drives.
4. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.
e. Identical query statements in your application must match
character-by-character to use the same shared pool area.
5. Check for runaway (orphan) processes and clean up after them. The
problem is in the database. Perform database tuning suggested by
experts in this area. For example:
a. Make sure that the shared pool is large enough to reduce
reparsing.
b. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
columns.

Slow Telnet Server

The Expert generates this alarm when the average transaction time
observed for an Telnet server exceeds the Slow Telnet 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, 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.

Possible causes:
1. There is a problem with the Telnet server.
2. There is excessive network congestion.

1-10 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Application Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Application
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. 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.

Possible causes:
1. 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.
2. 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,

Expert Alarms Reference 1-11

Expert Alarms and Thresholds

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:
1. Invalid username.
2. Invalid password.
3. 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:
1. Invalid username.
2. Invalid password.
3. 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.

Possible causes:
1. 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.
2. There is a lot of traffic on your network.
3. Other users may be trying to connect to the server at the same time,
thereby reducing the response time.
4. The DB Slow Connect Time threshold may be set too low for your
environment.

1-12 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.
b. 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.
c. Determine if your server has enough memory to support the
applications and services that have to run concurrently.
d. Install faster disk drives.
4. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.

Expert Alarms Reference 1-13

Expert Alarms and Thresholds

e. Identical query statements in your application must match

character-by-character to use the same shared pool area.
5. Check for runaway (orphan) processes and clean up after them. The
problem is in the database. Perform database tuning suggested by
experts in this area. For example:
a. Make sure that the shared pool is large enough to reduce
reparsing.
b. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
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 Sniffer Pro 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:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.

1-14 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

b. 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.
c. Determine if your server has enough memory to support the
applications and services that have to run concurrently.
d. Install faster disk drives.
4. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.
e. Identical query statements in your application must match
character-by-character to use the same shared pool area.
5. Check for runaway (orphan) processes and clean up after them. The
problem is in the database. Perform database tuning suggested by
experts in this area. For example:
a. Make sure that the shared pool is large enough to reduce
reparsing.
b. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
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:
1. A user has forgotten their password and continues to try different
dimly recalled passwords.

Expert Alarms Reference 1-15

Expert Alarms and Thresholds

2. 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:
1. 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.

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:
1. The login ID is incorrect.
2. The login password is incorrect.
3. There is excessive network congestion.

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:
1. There is a problem with the FTP server.
2. There is excessive network congestion.

1-16 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

FTP Slow Transfer Diagnosis

The Sniffer Pro 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 Sniffer Pro 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 Sniffer Pro 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:
1. The network is experiencing congestion.

Expert Alarms Reference 1-17

Expert Alarms and Thresholds

2. The web server is overloaded.

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:
1. The network is experiencing congestion.
2. The web server is overloaded.

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:
1. 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:
1. 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).

1-18 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. The node has been shut down.
2. 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:
1. The user has insufficient privileges to log in to this server. Contact the
server administrator to change the user’s privileges, if necessary.
2. An error occurred while loading or running a login script. Contact the
server administrator.
3. The login was not validated by a server. Contact the server
administrator.
4. The login server is running an older software version the client.
Because of this, the server cannot validate the login. Contact the server
administrator.
5. The user is not allowed to log in from this computer. Contact the
server administrator.
6. The user is not allowed to log in at this time. Contact the server
administrator.

Expert Alarms Reference 1-19

Expert Alarms and Thresholds

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:
1. Too many clients using the same server.
2. Server is overloaded with NCP requests.
3. Network is busy.

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:
1. 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:
1. There is a problem with the NNTP server.
2. There is excessive network congestion.

1-20 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. There is a problem with the POP3 server.
2. There is excessive network congestion.

Protocol Negotiation Failure

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

Possible cause:
1. The versions of SMB offered by the client are not supported by the
Server. Check the configurations of the SMB client and server.
2. 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:
1. There is a problem with the SAP R3 server.
2. 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:
1. There is a problem with the SAP R3 server.

Expert Alarms Reference 1-21

Expert Alarms and Thresholds

2. 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:
1. There is a problem with the SMTP server.
2. There is excessive network congestion.

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:
1. 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.
2. 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:
1. There is a problem with the Telnet server.
2. There is excessive network congestion.

1-22 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Session Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Session layer.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. The application is not using the network efficiently. Possibly, the
application was not designed to be used over networks.
2. 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:
1. The receiving node is shutting down and cannot create a new NetBIOS
connection.
2. The receiving node was too busy to accept additional connections.

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

Expert Alarms Reference 1-23

Expert Alarms and Thresholds

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:
1. 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.
2. 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.
3. Excessive repeated requests are characteristic of applications that do
not use the network efficiently, or that are not designed to be used
over networks.
4. 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 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.

1-24 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. 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.
2. 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.
3. If only one application has low throughput, then the problem is with
that application.
4. 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.

Possible causes:
1. This may be normal depending upon the application.
2. An excessive number of error responses may indicate a misconfigured
application.
3. The application may not have been designed for use over networks.
4. A password is wrong or the requester does not have the necessary
access privileges.
5. If the network is running Novell NDS, then the error response may be
an NDS verb error reply. Validate the NDS tree.

Expert Alarms Reference 1-25

Expert Alarms and Thresholds

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:
1. 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.
2. 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.
3. If only one application exhibits slow file transfer, then there is a
problem with that application.
4. 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.

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.

1-26 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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 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 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 Support the Requested Interface

The Expert generates this alarm when it detects that an RPC server does
not export an interface requested by a client.

The Server Does Not Implement the Requested Operation for the
Type of Requested Object
The Expert generates this alarm when it detects that an RPC server does
not implement an operation requested by a client for the type of requested
object.

The Server Does Not Support the Interface

The Expert generates this alarm when it detects that an RPC server does
not support a requested interface.

The Server Does Not Support the Proposed Transfer Syntaxes

The Expert generates this alarm when it detects that an RPC server does
not support the transfer syntaxes proposed by a client.

The Server Does Not Support the 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.

Expert Alarms Reference 1-27

Expert Alarms and Thresholds

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:
1. Invalid username.
2. Invalid password.
3. 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.

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.

1-28 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. The server is overloaded.
2. The MPI is too busy.
3. 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 Sniffer Pro 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 Sniffer Pro generates the TNS Slow Server Diagnosis
alarm.

Possible causes:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.

Expert Alarms Reference 1-29

Expert Alarms and Thresholds

b. 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.
c. Determine if your server has enough memory to support the
applications and services that have to run concurrently.
d. Install faster disk drives.
e. Check for runaway (orphan) processes and clean up after them.
4. The problem is in the database. Perform database tuning suggested by
Oracle and other experts in this area. For example:
a. Make sure that the shared pool is large enough to reduce
reparsing.
b. Optimize the size of the DB_BLOCK_BUFFERS.
c. Increase the value of DML_LOCKS to allow more locks placed on
an object at one time.
d. Determine your library cache misses and set the
CURSOR_SPACE_FOR_TIME according to the recommendation
in the Oracle7 Server Administrator’s Guide.
e. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
columns.
5. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.
e. Identical query statements in your application must match
character-by-character to use the same shared pool area.

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.

1-30 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. The problem is network related.
a. Determine if your network is overloaded. Increase your network’s
bandwidth.
b. Determine if your network is optimally configured. Minimize
frame fragmentation by using larger frame sizes or more efficient
protocols.
c. Reduce polling frequency of polled devices in your network.
2. The problem is in the Multiprotocol Interchange.
a. Configure your MPI for better data throughputs rather than for
connections.
b. Decrease the number of pumps per MPI.
c. Add more MPIs.
3. The problem is in the server.
a. Assess the current utilization of your server. Determine if you
have enough CPU power to support the number of users in this
server.
b. 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.
c. Determine if your server has enough memory to support the
applications and services that have to run concurrently.
d. Install faster disk drives.
4. The problem is in the client workstation.
a. Use optimized query statements. The "explain plan" command
will show the access paths to the data.
b. Remove all unnecessary "lock table" statements. Do not use "for
update" clause in select statements if there is no need to update
immediately.
c. Issue commit statements immediately after "update", "delete", and
"insert" statements to release locked resources.
d. Use explicit cursors in all of your PL/SQL blocks.
e. Identical query statements in your application must match
character-by-character to use the same shared pool area.
f. Check for runaway (orphan) processes and clean up after them.
5. The problem is in the database. Perform database tuning suggested by
Oracle and other experts in this area. For example:

Expert Alarms Reference 1-31

Expert Alarms and Thresholds

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

reparsing.
b. Optimize the size of the DB_BLOCK_BUFFERS.
c. Increase the value of DML_LOCKS to allow more locks placed on
an object at one time.
d. Determine your library cache misses and set the
CURSOR_SPACE_FOR_TIME according to the recommendation
in the Oracle7 Server Administrator’s Guide.
e. Check if indexed clusters can speed up your access to tables that
are commonly joined together on a standard set of matching
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:
1. 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.

1-32 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. 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.
2. 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.
3. Excessive repeated requests are characteristic of applications that do
not use the network efficiently, or that are not designed to be used
over networks.
4. 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:
1. The application was not designed for use over networks.
2. The application doesn’t take into account that the responding
application is on a different station.
3. 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:
1. 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.

Expert Alarms Reference 1-33

Expert Alarms and Thresholds

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:
1. The Expert did not see the WINS response because the Sniffer Pro is
connected to a switched network environment. Switches have the
effect of segmenting network traffic, preventing the Sniffer Pro from
seeing all network traffic unless port mirroring is set up effectively.
Because the Sniffer Pro never saw the response from the WINS Server,
this alarm was generated.
2. 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.
3. 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.

1-34 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Connection Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Connection
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. The recipient of the original data frame was temporarily busy, and
could not process the frame as quickly as usual.
2. The ACK arrived late because a server had to look up and/or process
data before responding with an ACK.
3. The path changed in a way that increased the time between the
request and its acknowledgement.
4. 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:
1. 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.

Expert Alarms Reference 1-35

Expert Alarms and Thresholds

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:
1. A station is inoperative.
2. A router has lost the connection.
3. The transport software has hung.
4. An application has hung.
5. 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:
1. 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.
2. The router may be used for security purposes, to control access to
particular parts of the network.
3. The router may be performing gateway type functions, such as
protocol translation at the application level.
4. 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.

Possible causes:
Retransmissions often indicate a problem with a server. Some examples
are:

1-36 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

1. Improperly configured software.

2. An overloaded server.
3. 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:
1. 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:
1. The receiving station was overloaded.
2. A router was overloaded, or there was some other propagation delay.
3. The network traffic load was very high.
4. The ACK was sent but lost.
5. Either the original packet or its ACK was damaged.
6. The ACK was transmitted via a slower path.
7. An IP fragment was lost.
8. There is a network integrity problem.

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.

Expert Alarms Reference 1-37

Expert Alarms and Thresholds

Possible cause:
1. 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.

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:
1. The receiving station was overloaded. This is particularly likely if the
receiving station was a server.
2. A router was overloaded, or there was some other source of
propagation delay.
3. The network traffic load was very high.
4. The ACKs were being transmitted via a slower path.
5. 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.

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:
1. There is a misconfigured router or routers. Examine the routing
table(s) and correct them if necessary.

1-38 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. There is insufficient buffer space, because the recipient’s memory
allocation process is not providing enough buffer memory.
2. 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:
1. This situation may occur occasionally if the window has just
decreased before the transmitter has had a chance to notice.
2. 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.

Possible causes:
1. The receiving station is very busy.
2. There are insufficient network buffers in the receiving station.
3. 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.
4. An application is very slow.

Expert Alarms Reference 1-39

Expert Alarms and Thresholds

5. A fast station is overwhelming a slow one.

Station Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Station layer.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. Someone has assigned a new network address without checking the
existing network addresses to assure that the assignment is unique.
2. 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.
3. Someone has copied another station’s configuration file, and has
neglected to change the network address.
4. 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.

1-40 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. 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:
1. This message is usually sent by a router, and may indicate a routing
table problem. Examine the RIP information.
2. If the RIP packets are not occurring at 30 second intervals, there may
be an unstable condition on the network.
3. The destination network does not exist.
4. The request is "administratively disallowed" because the requester
does not have the necessary access privileges.
5. 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:
1. The station that sent the message has received a frame with an
unknown destination address.
2. The requested service is not available from the station that sent the
message.
3. The request is "administratively disallowed" because the requester
does not have the necessary access privileges.

The situation can be investigated further by PINGing another host on the

same segment as the one that sent the ’host unreachable’ message.

Expert Alarms Reference 1-41

Expert Alarms and Thresholds

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 Sniffer Pro.

Possible causes:
1. The subnet mask is legitimate, but is not known to the Sniffer Pro.
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 Sniffer Pro.
2. 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:
1. This message is usually sent by a router, and may indicate a routing
table problem. Examine the RIP information.
2. If the RIP packets are not occurring at 30 second intervals, there may
be an unstable condition on the network.
3. The destination network does not exist.
4. The request is "administratively disallowed" because the requester
does not have the necessary access privileges.
5. 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.

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.

1-42 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. The requested service is not implemented or not active on the station
that sent the message, or is in use.
2. The request is "administratively disallowed" because the requester
does not have the necessary access privileges.

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:
1. 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).

Possible cause:
1. 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.

Expert Alarms Reference 1-43

Expert Alarms and Thresholds

ICMP Source Quench

The Expert generates the ICMP Source Quench alarm when a station
receives an ICMP source quench message.

Possible causes:
1. A congested router may have sent the message to inform this station
to reduce its rate of frame transmission.
2. The station that sent the source quench message may have a full buffer
or some other kind of processing bottleneck. Transmit more slowly.
3. The station that sent the message may be down or rebooting.
4. 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:
1. Heavy LAN traffic.
2. 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.

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.

1-44 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible cause:
1. 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:
1. This station does not know what subnet it is attached to.
2. This station is using expired or canceled routes.
3. A protocol other than RIP is being using to circulate routing
information.
4. 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.

Possible causes:
1. The router configurations may be incorrect. Resolve this by checking
the router tables.
2. The existing configuration may be legitimate. Multiple routers are
sometimes used for security purposes, or to provide fault-tolerant
network connections.
3. There may be a duplicate network address shared by one of the
routers and a local station.

Expert Alarms Reference 1-45

Expert Alarms and Thresholds

4. 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:
1. The router configurations may be incorrect. Resolve this by checking
the router tables.
2. 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:
1. 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:
1. The router has crashed or reset.
2. The router has been turned off.

1-46 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

3. The router has been disconnected from this subnet.

4. 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:
1. 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.
2. 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:
1. There is an intermittent problem with the communication line. This
causes links to fail and come back up.
2. The network topology is changing, causing the metric of several
routes to change.

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.

Expert Alarms Reference 1-47

Expert Alarms and Thresholds

Possible cause:
1. 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:
1. 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:
1. 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.

1-48 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. 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.
2. 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:
1. 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.

Expert Alarms Reference 1-49

Expert Alarms and Thresholds

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:
1. 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:
1. 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.

1-50 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. 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.
2. Source routing is being used, but the Sniffer Pro is currently
configured to disable interpretation of the RI bit.
3. 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:
1. 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.
2. The DLC address is a mistake. Examine the surrounding packets 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.

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.

Expert Alarms Reference 1-51

Expert Alarms and Thresholds

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:
1. The destination station is overloaded and is losing frames.
2. The destination station’s adapter board has a problem.

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:
1. A line hit has occurred.
2. 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.

1-52 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible cause:
1. 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:
1. A defective cable
2. An excessively long cable
3. Electrical noise on a cable
4. Crosstalk
5. A defective board (if the error is on the "out" counter)
6. 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:
1. The transport level software in the receiving station is not providing
its receive buffers fast enough.

Expert Alarms Reference 1-53

Expert Alarms and Thresholds

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:
1. A lost token is usually the result of a station entering or leaving the
ring, or some other physical configuration change.
2. 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:
1. Unless these errors are frequent, they are most likely caused by a
reconfiguration of the ring. No remedial action is required.
2. There is a hardware problem. Check the fault domain.
3. There is crosstalk from voice traffic.
4. 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.

1-54 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. 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:
1. The transport level software in the receiving station is not providing
the receive buffers fast enough.

Expert Alarms Reference 1-55

Expert Alarms and Thresholds

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:
1. There is a physical break in the ring (signal loss). Check the fault
domain.
2. A timeout has occurred during monitor contention.
3. 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
Sniffer Pro generates a symptom. The Sniffer Pro generates a diagnosis when
the Ring Purge Diag threshold is exceeded.

Possible causes:
1. A lost token is usually the result of a station entering or leaving the
ring, or some other physical configuration change.
2. Too many ring purges may indicate faulty hardware. Check the fault
domain.

1-56 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. A damaged or defective cable.
2. A bent or stapled cable that is producing reflections.
3. 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.

Expert Alarms Reference 1-57

Expert Alarms and Thresholds

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.

1-58 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Wireless Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Wireless layer.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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.

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.

Expert Alarms Reference 1-59

Expert Alarms and Thresholds

• 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:
• 1 — Unspecified failure.
• 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.

1-60 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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 alarm display includes the following information:

• 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.
• 6 — Class 2 frame received from nonauthenticated station.

Expert Alarms Reference 1-61

Expert Alarms and Thresholds

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 alarm display includes the following information:

• 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.

Multicast/Broadcast Fragmentation
The Expert generates the Multicast/Broadcast 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.

1-62 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. 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).

Expert Alarms Reference 1-63

Expert Alarms and Thresholds

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.

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:
• 1 — Unspecified failure.
• 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 entered
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.

1-64 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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 have previously entered
the MAC addresses of the known access points on the network in the
802.11 Options tab of the Expert Properties dialog box. 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 you have entered in the 802.11 Options tab. If
the discovered address has not been entered in the 802.11 Options tab, the
Expert generates the Rogue Access Point alarm. In addition, the Expert
displays will identify the 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:
1. In most cases, this is a relatively minor alarm, probably indicating
nothing more than that you neglected to enter the address of a known
access point in the 802.11 Options tab. 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.

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.

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

Expert Alarms Reference 1-65

Expert Alarms and Thresholds

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 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 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 Wireless 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 Wireless 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.

1-66 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Possible causes:
1. 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.
2. The station that sent the offending packet is configured with the
wrong WEP keys for the network. Make sure its keys are programmed
correctly.

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 corresponding thresholds (if any).

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).

Expert Alarms Reference 1-67

Expert Alarms and Thresholds

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.

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.

1-68 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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.

Expert Alarms Reference 1-69

Expert Alarms and Thresholds

WAN Link Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the WAN Link
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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

In a correctly operating Frame Relay link, connected user equipment
issues STATUS ENQUIRY messages at regular intervals (usually every 10
seconds). 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.

1-70 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

DTE Sequence Number Error

The Expert generates the DTE sequence number error alarm in either of
the following cases:
• 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

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 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:
• 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).

Expert Alarms Reference 1-71

Expert Alarms and Thresholds

• 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.

1-72 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

New PVC Configured

The Expert generates the New PVC Configured alarm when it sees a full
status report listing a previously unknown DLCI .

No STATUS ENQUIRY When Expected

In a correctly operating Frame Relay link, connected user equipment
issues STATUS ENQUIRY messages at regular intervals (usually every 10
seconds). 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.

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.

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.

Expert Alarms Reference 1-73

Expert Alarms and Thresholds

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.

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).

1-74 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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.

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).

Expert Alarms Reference 1-75

Expert Alarms and Thresholds

ATM Application Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM
Application layer. Alarms are organized alphabetically and are described
with their corresponding thresholds (if any).

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.

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.

1-76 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

• 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.

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

Expert Alarms Reference 1-77

Expert Alarms and Thresholds

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 DDVCC.

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 Cfg 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.

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:
1. There is a version incompatibility between the LEC and the LECS.
2. The LECS denied the Configure Request for security reasons.
3. The LEC supplied conflicting parameters in the Configure Request
frame.

1-78 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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

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. 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.

LANE Cfg Restart Delay > Max Recfg Delay

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. 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

Expert Alarms Reference 1-79

Expert Alarms and Thresholds

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.

1-80 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

ATM Flow Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM Flow
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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,

Expert Alarms Reference 1-81

Expert Alarms and Thresholds

an MPC cannot share its L2 DLC address with any other device (LANE or
otherwise).

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

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). 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:
1. The LES, LECS, or BUS is temporarily overloaded due to excessive
demands from LECs.

1-82 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Config Frag Info TLV Not Recognized by LECS

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. 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:
1. 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.

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.

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

Expert Alarms Reference 1-83

Expert Alarms and Thresholds

minimum value of 10 seconds for this timeout, with a default value of 30

seconds and a maximum of 300 seconds.

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:
1. The network is experiencing congestion.
2. 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 with the exception of the Transaction ID. The Transaction

1-84 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

ID must be different so that if the responding station does respond, the

requesting station can determine to which request it is responding.

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 Properties dialog box.

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.

Expert Alarms Reference 1-85

Expert Alarms and Thresholds

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.

Possible cause:
1. 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:
1. 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.

1-86 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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 .

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.

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.

Expert Alarms Reference 1-87

Expert Alarms and Thresholds

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
• 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:
1. A LEC mistakenly set the source address in a Join Request to one of its
secondary ATM addresses.

1-88 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

Possible cause:
1. 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–3 shows the fields in the common header portion of an MPOA
control message.

Expert Alarms Reference 1-89

Expert Alarms and Thresholds

Figure 1–3. Common Header of an MPOA Control Message

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–4 shows the fields in the fixed header portion of an MPOA control
message.

Figure 1–4. 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.

1-90 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

• 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:
• 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:
1. 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.
2. The Device Type TLV indicated an MPC device type (value of the first
octet is 2), but the MAC address count is non-zero.

Expert Alarms Reference 1-91

Expert Alarms and Thresholds

3. 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.

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.

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.

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

1-92 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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

Expert Alarms Reference 1-93

Expert Alarms and Thresholds

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:
• 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:
1. The network is experiencing congestion.
2. The LE Service has received a large number of simultaneous requests
from various LECs.

LANE Control Request Retry Retry Frame Mismatch

The Expert generates the LANE Control Request Retry Retry Frame
Mismatch alarm when a LEC resends a Control Request frame in which a

1-94 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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:
1. 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

Expert Alarms Reference 1-95

Expert Alarms and Thresholds

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

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.

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:
1. There is a version incompatibility between the LEC and the LECS.
2. The LECS denied the Configure Request for security reasons.
3. 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.

1-96 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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
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.

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.

Expert Alarms Reference 1-97

Expert Alarms and Thresholds

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.
• "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

1-98 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

• LE_REGISTER_RESPONSE
• LE_ARP_REQUEST
• LE_ARP_RESPONSE
• Targetless 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:
• 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).

Expert Alarms Reference 1-99

Expert Alarms and Thresholds

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:
1. The network is experiencing congestion.

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.

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.

1-100 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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.

Expert Alarms Reference 1-101

Expert Alarms and Thresholds

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.

PTSE Violation
The Expert generates the PTSE Violation alarm if it detects a PNNI
Topology State Element (PTSE) with an illegal Information Group (IG).

1-102 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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.

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

Expert Alarms Reference 1-103

Expert Alarms and Thresholds

ordinarily sent by the LES to the LEC in response to receiving the Register
Request frame.

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:
1. A LEC sent a control request frame with the REQUESTER-LED-ID
field or the SOURCE-ATM-ADDRESS field empty.
2. 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).
3. 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).
4. An 802.3 data frame was seen on an 802.5 data direct VCC.
5. 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

1-104 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

Possible cause:
1. 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.

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.

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.

Expert Alarms Reference 1-105

Expert Alarms and Thresholds

Unexpected Egress Cache EXT in Frame

Each MPOA control message has a set of extensions that can legally
appear 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.

Unexpected Hop Count EXT in Frame

Each MPOA control message has a set of extensions that can legally
appear 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.

PNNI routing frames use nested TLV known as Information Groups (IG) to
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 generates this alarm.

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

Each MPOA control message has a set of extensions that can legally
appear 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

Each MPOA control message has a set of extensions that can legally
appear 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.

1-106 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Unexpected Service Category EXT in Frame

Each MPOA control message has a set of extensions that can legally
appear 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.

Unexpected TLVs Detected

The Expert generates the Unexpected TLVs Detected alarm when it sees
TLVs 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:
1. 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.

PNNI routing frames use nested TLVs known as Information Groups (IG) to
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:
1. Two PNNI nodes are running different versions of the PNNI protocol.

Expert Alarms Reference 1-107

Expert Alarms and Thresholds

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.

Possible cause:
1. 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:
1. 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.
2. 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

Each MPOA control message has a set of extensions that can legally
appear 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.

1-108 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

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:
1. 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.

Expert Alarms Reference 1-109

Expert Alarms and Thresholds

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.

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.

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.

1-110 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

ATM Connection Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM
Connection layer. Alarms are organized alphabetically and are described
with their corresponding thresholds (if any).

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 Properties dialog box.

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.

For each VPI.VCI on the network, the Expert maintains counts of frames
with 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.
• 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.

Expert Alarms Reference 1-111

Expert Alarms and Thresholds

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 Object Properties dialog box.

For each VPI.VCI on the network, the Expert maintains counts of frames
with 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.
• 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.

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:

1-112 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

• 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.

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 tab of the Expert UI Object Properties dialog box.

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.
• 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.

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.

Expert Alarms Reference 1-113

Expert Alarms and Thresholds

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 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.

For each VPI.VCI on the network, the Expert maintains counts of frames
with 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.
• 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.

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.

1-114 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

• 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.
• 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.

Expert Alarms Reference 1-115

Expert Alarms and Thresholds

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:
• 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–5:

1-116 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Figure 1–5. 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.
• 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.

Expert Alarms Reference 1-117

Expert Alarms and Thresholds

ATM Host Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM Host
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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 tab of the Expert UI Object Properties dialog box.

The Expert considers the following to be abnormal frame sequences:

• 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

1-118 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

Expert Alarms Reference 1-119

Expert Alarms and Thresholds

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 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. 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–6:

Figure 1–6. Sample Unexpected Data for SVC Alarm Display (ATM
Host Layer)

1-120 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.
• 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.

Expert Alarms Reference 1-121

Expert Alarms and Thresholds

ATM Link Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM Link
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

Attempt to Set Up Multiple SVCC RCCs

The Expert generates the Attempt To Set Up Multiple SVCC RCCs alarm
if it detects either of the following:
• There is more than one active SVCC RCC between a pair of Logical
Group Nodes (LGNs).
• There is an attempt to set up more than one SVCC RCC between a pair
of LGNs.

Each low-layer PNNI peer group (a group of switches sharing detailed

routing information with one another) has a Logical Group Node. Logical
Group Nodes act as "parents" to a PNNI peer group. They hold the routing
information necessary for a switch in one low-layer peer group to route
calls to switches in another peer group. Logical Group Nodes for one peer
group share information with the Logical Group Nodes for other peer
groups over SVCC RCCs (Routing Control Channels). During normal
PNNI operations, there is only one SVCC RCC between LGNs unless the
Peer Group has been partitioned or the Peer Group Leader has changed.

Crankback Has Occurred (ATM Link 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 link-specific at the ATM Link layer
– the crankback occurred due to a fault on the indicated ATM Link layer
object.

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 group in the PNNI domain receives a
summary of the detailed information exchanged within the other peer

1-122 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.

Excessive Hello Frames Detected

The Expert generates the Excessive Hello Frames Detected alarm when
the interval between PNNI Hello frames detected from a given node is less
than the MinHelloInterval threshold in the Alarms tab of the Expert UI
Object Properties dialog box.

Hello frames are exchanged between PNNI-enabled switches to

determine to which PNNI peer group a switch belongs. Once a PNNI
switch has determined its peer group, it can then begin the exchange of
routing database information with the other switches in its peer group
through Database Summary packets, PTSE Request packets, and PTSP
packets.

Link Inactivity Failure

The Expert generates the Link Inactivity Failure alarm for a PNNI link if
the time observed between PNNI Hello packets on the link exceeds the
HelloInterval observed for the link multiplied by the Link Inactivity
Factor threshold in the Alarms tab of the Expert UI Object Properties
dialog box.

Hello frames are exchanged between PNNI-enabled switches to

determine to which PNNI peer group a switch belongs. Each Hello packet
includes the HelloInterval field, specifying the amount of time, in
seconds, at which the node sends out Hello packets over the link
(excepting event-triggered Hellos).

Protocol Version Support Incompatible

The Expert generates the Protocol Version Support Incompatible alarm
if the protocol versions supported by a pair of communicating PNNI
nodes cannot be reliably negotiated to an agreed-upon version.

Expert Alarms Reference 1-123

Expert Alarms and Thresholds

NOTE: This alarm is only generated for Links associated with an SVCC
RCC (the routing control channel used to signal calls between PNNI peer
groups).

Routing Frames Detected on Outside Link

The Expert generates the Routing Frames Detected on Outside Link
alarm when PNNI frames other than Hello frames are detected on outside
links.

"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. Once the determination has been made that two nodes are in
different peer groups, the only PNNI frames they can legally exchange are
Hello packets. They cannot exchange Database Summary packets.

SVCC RCC Dropped

The Expert generates the SVCC RCC Dropped alarm for an ATM Link
layer object if the link has active data connections and the associated SVCC
RCC is disconnected.

The SVCC RCC (Routing Control Channel) is used to signal calls between
PNNI peer groups. If the SVCC RCC for a particular link is dropped, this
alarm is generated.

1-124 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

ATM Node Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the ATM Node
layer. Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

Address Scoping Violation

The Expert generates the Address Scoping Violation alarm if a node is
observed advertising the accessibility of addresses lower in the PNNI
hierarchy than the level of its own peer group. This information is
gathered by decoding the Scope of advertisement field in various
Information Groups (TLVs that encode PTSE information) that carry it
(such as the Internal Reachable ATM Address IG and the Exterior
Reachable Address IG).

PNNI creates a hierarchy of nodes to ensure that nodes in the PNNI

domain know just enough to route calls out of their own peer groups, but
no more (thus reducing the burden of the database of addresses which
they have to hold). At the highest level is the PNNI Domain. The PNNI
Domain contains multiple Parent Peer Groups. Parent Peer Groups are
groups of Logical Group Nodes, each representing its own individual peer
group of switches. Each switch, in turn, represents connected ATM end
stations. End-to-end communications work by flowing up the hierarchy
and then back down to the destination address. For example, if an ATM
end station has a call to set up with another ATM end station at the other
end of the PNNI domain, it communicates with its Logical Group Node.
The Logical Group Node sets up communications with a second LGN
representing a different low-layer peer group, which eventually wends its
way through as many LGNs as necessary to make it to the LGN
representing the peer group containing the switch representing the ATM
end station for which the call is destined.

Crankback Has Occurred (ATM Node 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 node-specific at the ATM Node
layer – the crankback occurred due to a fault on the indicated node.

Expert Alarms Reference 1-125

Expert Alarms and Thresholds

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 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.

Host Bound to Multiple Nodes

The Expert generates the Host Bound to Multiple Nodes alarm when
more than one PNNI node at the same hierarchical level advertises routing
access to the same ATM End System Address (host). For example, two
PNNI-enabled switches may be advertising access to the same host
address. The ATM End System Addresses represented by PNNI nodes at
the same level must be unique.

Possible causes:
1. An operational node has changed its Node ID (illegal, but possible).
2. A node is misconfigured.

Invalid Port ID
The Expert generates the Invalid Port ID alarm when a node sends a PNNI
packet with the port ID set to either zero or 0xFFFFFFFF.

NOTE: This alarm is not generated for Logical Group Nodes sending
packets with the port ID set to 0xFFFFFFFF (this port ID is legal for Logical
Group Nodes).

1-126 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Parent Node Association Change

The Expert generates the Parent Node Association Change alarm for a
node if the ID of its parent node changes.

Peer groups are logical groups of PNNI-enabled switches (nodes) that

share detailed routing information with one another. In a PNNI domain
consisting of multiple peer groups, each peer group has a Peer Group
Leader that maintains detailed information for routing packets to other
peer groups within the PNNI domain. This information is maintained on
the Parent Node – a node that presents the routing information for an
entire peer group to the parent nodes for other peer groups in the PNNI
domain.

Peer Group ID Has Changed

The Expert generates the Peer Group ID Has Changed alarm when the
Peer Group ID for a specific node changes. This may be indicative of a Peer
Group being subdivided or the hierarchy level of the Peer Group
changing.

Peer groups are logical groups of PNNI-enabled switches that share

detailed routing information with one another. Switches belonging to a
particular peer group are identified by a common Peer Group ID. If a
particular node's Peer Group ID changes, this alarm is generated.

Peer Group Leader Has Changed

The Expert generates the Peer Group Leader Has Changed alarm when
the elected Peer Group Leader for a given PNNI peer group changes. This
can occur if a node elected as Peer Group Leader becomes inoperative or
if an attempt is made by another node to become a Peer Group Leader.

Peer groups are logical groups of PNNI-enabled switches that share

detailed routing information with one another. In a PNNI domain
consisting of multiple peer groups, each peer group has a Peer Group
Leader that maintains detailed information for routing packets to other
peer groups within the PNNI domain. If the Peer Group Leader for a given
peer group changes, this alarm is generated.

PTSE Acknowledge Timeout

The Expert generates the PTSE Acknowledge Timeout alarm when a
node sends a PTSP packet but does not receive the corresponding PTSE
ACK within the time specified by the Max Time for Response to PTSE

Expert Alarms Reference 1-127

Expert Alarms and Thresholds

ACK (secs) threshold in the Alarms tab of the Expert UI Object Properties
dialog box.

PNNI nodes send PTSE Request packets to request routing database

information from other PNNI nodes within their peer group (a logical
group of PNNI-enabled switches sharing detailed routing information).
PNNI nodes receiving PTSE Requests are required to respond with PNNI
Topology State Packets (PTSPs) containing their routing database
information encoded in multiple PTSEs (PNNI Topology State Elements).
Receiving stations examine the PTSP packet and respond to each of the
enclosed PTSEs with a separate PTSE ACK message. If the PTSE ACK is
not sent in response to the corresponding PTSP packet within the time
specified by the threshold, this alarm is generated.

PTSE Request Timeout

The Expert generates the PTSE Request Timeout alarm when a node
sends a PTSE Request packet but does not receive the corresponding
response (in the form of a PTSP packet) within the time specified by the
Max Time for Response to PTSE Request (secs) threshold in the Alarms
tab of the Expert UI Object Properties dialog box.

PNNI nodes send PTSE Request packets to request routing database

information from other PNNI nodes within their peer group (a logical
group of PNNI-enabled switches sharing detailed routing information).
PNNI nodes receiving PTSE Requests are required to respond with PNNI
Topology State Packets (PTSPs) containing their routing database
information encoded in PTSEs (PNNI Topology State Elements).

Restricted Branching Violation

The Expert generates the Restricted Branching Violation alarm when it
detects a point-to-multipoint connection originating on a node that has
been observed sending a PNNI message containing the Nodal
Information Group (a type of TLV used to encode PNNI information) with
the Restricted Branching bit set to true in the Nodal Flag (that is, no
branching allowed from this node).

1-128 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

Global Layer Alarms and Thresholds

This section describes Expert alarms and thresholds at the Global layer.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. When capturing from a wireless network, CRC errors appear
routinely because of multipath and attenuation distortions. This is a
normal part of wireless LAN operations and is not ordinarily a cause
for concern.
2. A faulty device on the network.
3. 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:
1. This could be a temporary condition resulting from a valid broadcast
or multicast operation.
2. 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.
3. 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.

Expert Alarms Reference 1-129

Expert Alarms and Thresholds

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:
1. This could be a temporary condition resulting from a valid broadcast
or multicast operation.
2. 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.
3. 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.

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

1-130 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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:
1. 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:
1. Multiple large file transfers are occurring simultaneously.
2. 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.
3. There is a defect that is causing a single station to do something
repetitive.
4. 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.

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.

Expert Alarms Reference 1-131

Expert Alarms and Thresholds

Possible causes:
1. Multiple large file transfers are occurring simultaneously.
2. 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.
3. A single station is doing something repetitive.
4. A router has been rebooted recently.
5. 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.

Possible causes:
1. A bridge has gone up or come down somewhere on the logical LAN.
2. Someone has reconfigured a port cost or the priority of a bridge
somewhere on the logical LAN.

1-132 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

3. 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.

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

Expert Alarms Reference 1-133

Expert Alarms and Thresholds

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.

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

1-134 Sniffer Pro and Sniffer Distributed

 Expert Alarms and Thresholds

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.
Alarms are organized alphabetically and are described with their
corresponding thresholds (if any).

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:
1. This router has been configured with an IP address that is not valid on
the subnet.
2. This router is inappropriately forwarding routing information frames
from other routers onto this subnet.
3. 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.

Possible cause:
1. 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.

Expert Alarms Reference 1-135

Expert Alarms and Thresholds

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:
1. The router changed the metric associated with this route, making it
now the best (or no longer the best) route.
2. 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:
1. The router advertised this route as available but later advertised that
the route was unavailable (or vice versa).
2. The router advertised this route but later failed to confirm it before it
expired.

1-136 Sniffer Pro and Sniffer Distributed

Network Associates
Support Services A
A
Adding Value To Your Network Associates Product
Sniffer Technologies network management software helps to ensure that
the critical technology you rely on functions smoothly and effectively.
Taking advantage of a Network Associates support plan extends the
protection you get from your software by giving you access to the
expertise you need to install, monitor, maintain and upgrade your system
with the latest Network Associates technology. With a support plan
tailored to your needs, you can keep your system or your network
working dependably in your computing environment for months or years
to come.

Corporate customers can choose from four levels of extended support

under the Network Associates Corporate PrimeSupport program.

PrimeSupport Options for Corporate Customers

The Corporate PrimeSupport program offers these four support plans:
• PrimeSupport KnowledgeCenter Plan
• PrimeSupport Connect Plan
• PrimeSupport Priority Plan
• PrimeSupport Enterprise Plan

Each plan has a range of features that provide you with cost-effective and
timely support geared to meet your needs. The following sections describe
each plan in detail.

The PrimeSupport KnowledgeCenter Plan

The PrimeSupport KnowledgeCenter Plan gives you access to an
extensive array of technical support information via a Network Associates
online knowledge base, and download access to product upgrades from
the Network Associates website. If you purchased your Network
Associates product with a subscription license, you receive the
PrimeSupport KnowledgeCenter Plan as part of the package, for the
length of your subscription term.

A-1
Network Associates Support Services

If you purchased a perpetual license for your Network Associates product,

you can purchase a PrimeSupport KnowledgeCenter Plan for an annual
fee.

To receive your KnowledgeCenter password or to register your

PrimeSupport agreement with Network Associates, visit:
http://www.nai.com/asp_set/support/introduction/default.asp

Your completed form will go to the Network Associates Customer Service

Center. You must submit this form before you connect to the
PrimeSupport KnowledgeCenter site.

With the PrimeSupport KnowledgeCenter Plan, you get:

• Unrestricted, 24-hour-per-day online access to technical solutions
from a searchable knowledge base within the Network Associates
website
• Electronic incident and query submission
• Technical documents, including user’s guides, FAQ lists, and release
notes
• Online data file updates and product upgrades

The PrimeSupport Connect Plan

The PrimeSupport Connect Plan gives you telephone access to essential
product assistance from experienced technical support staff members.
With this plan, you get:
• In North America, unlimited toll-free telephone access to technical
support from Monday through Friday, 8:00 AM to 8:00 PM Central
Time
• In Europe, the Middle East, and Africa, unlimited telephone access to
technical support, at standard long-distance or international rates,
Monday through Friday, from 9:00 AM to 6:00 PM local time
• In the Asia-Pacific region, unlimited toll-free, telephone access to
technical support, Monday through Friday, from 8:00 AM to 6:00 PM
AEST
• In Latin America, unlimited telephone access to technical support, at
standard long-distance or international rates, Monday through
Friday, from 9:00 AM to 5:00 PM Central Time
• Unrestricted, 24-hour-per-day online access to technical solutions
from a searchable knowledge base within the Network Associates
website
• Electronic incident and query submission

A-2 Sniffer Pro and Sniffer Distributed

 Network Associates Support Services

• Technical documents, including user’s guides, FAQ lists, and release

notes
• Data file updates and product upgrades via the Network Associates
website

The PrimeSupport Priority Plan

The PrimeSupport Priority Plan gives you round-the-clock telephone
access to essential product assistance from experienced Network
Associates technical support staff members. You can purchase the
PrimeSupport Priority Plan on an annual basis when you purchase a
Network Associates product, either with a subscription license or a
one-year license.

The PrimeSupport Priority Plan has these features:

• In North America, unlimited toll-free telephone access to technical
support from Monday through Friday, 8:00 AM to 8:00 PM Central
Time
• In Europe, the Middle East, and Africa, unlimited telephone access to
technical support, at standard long-distance or international rates,
Monday through Friday, from 9:00 AM to 6:00 PM local time
• In the Asia-Pacific region, unlimited toll-free, telephone access to
technical support, Monday through Friday, from 8:00 AM to 6:00 PM
AEST
• In Latin America, unlimited telephone access to technical support, at
standard long-distance or international rates, Monday through
Friday, from 9:00 AM to 5:00 PM Central Time
• Priority access to technical support staff members during regular
business hours
• Responses within one hour for urgent issues that happen outside
regular business hours, including those that happen during weekends
and local holidays
• Unrestricted, 24-hour-per-day online access to technical solutions
from a searchable knowledge base within the Network Associates
website
• Electronic incident and query submission
• Technical documents, including user’s guides, FAQ lists, and release
notes
• Data file updates and product upgrades via the Network Associates
website

Expert Alarms Reference A-3

Network Associates Support Services

The PrimeSupport Enterprise Plan

The PrimeSupport Enterprise Plan gives you round-the-clock,
personalized, proactive support from an assigned technical support
engineer. You’ll enjoy a relationship with a support professional who is
familiar with your Network Associates product deployment and support
history, and who will call you at an interval you designate to verify that
you have the knowledge you need to use and maintain Network
Associates products.

By calling in advance, your PrimeSupport Enterprise representative can

help to prevent problems before they occur. If, however, an emergency
arises, the PrimeSupport Enterprise Plan gives you a committed response
time that assures you that help is on the way. You may purchase the
PrimeSupport Enterprise Plan on an annual basis when you purchase a
Network Associates product, either with a subscription license or a
one-year license.

With the PrimeSupport Enterprise Plan, you get:

• Unlimited, toll-free telephone access to an assigned technical support
engineer on a 24-hour-per-day, seven-day-per-week basis, including
during weekends and local holidays.

NOTE: The availability of toll-free telephone support varies by region

and is not available in some parts of Europe, the Middle East, Africa,
and Latin America.

• Proactive support contacts from your assigned support engineer via

telephone or e-mail, at intervals you designate
• Committed response times from your support engineer, who will
respond to pages within half an hour, to voice mail within one hour,
and to e-mail within four hours
• Assignable customer contacts, which allow you to designate five
people in your organization who your support engineer can contact in
your absence
• Optional beta site status, which gives you access to the absolute latest
Network Associates products and technology
• Unrestricted, 24-hour-per-day online access to technical solutions
from a searchable knowledge base within the Network Associates
website
• Electronic incident and query submission

A-4 Sniffer Pro and Sniffer Distributed

 Network Associates Support Services

• Technical documents, including user’s guides, FAQ lists, and release

notes
• Online data file updates and product upgrades

Ordering a Corporate PrimeSupport Plan

To order any PrimeSupport Plan, contact your sales representative, or
• In North America, call Network Associates at (972) 308-9960, Monday
through Friday from 8:00 AM to 7:00 PM Central Time. Press 3 on your
telephone keypad for sales assistance.
• In Europe, the Middle East, and Africa, contact your local Network
Associates office. Contact information appears near the front of this
guide.

Expert Alarms Reference A-5

Network Associates Support Services

Table A–1. Corporate PrimeSupport Plans at a Glance

Plan Knowledge Center Connect Plan Priority Plan Enterprise Plan

Feature Plan

Technical Yes Yes Yes Yes

support via
website
Software Yes Yes Yes Yes
updates
Technical — Monday–Friday Monday–Friday, after Monday–Friday, after
support via hours emergency hours emergency
telephone access access
North America:
8 AM–8 PM CT North America: North America:
8 AM–8 PM CT 8 AM–8 PM CT
Europe, Middle East,
Africa: Europe, Middle East, Europe, Middle East,
9 AM-6 PM local time Africa: Africa:
9 AM-6 PM local time 9 AM-6 PM local time
Asia-Pacific:
8 AM-6 PM AEST Asia-Pacific: Asia-Pacific:
8 AM-6 PM AEST 8 AM-6 PM AEST
Latin America:
9 AM-5 PM CT Latin America: Latin America:
9 AM-5 PM CT 9 AM-5 PM CT
Priority call — — Yes Yes
handling
After-hours — — Yes Yes
support
Assigned — — — Yes
support
engineer
Proactive — — — Yes
support
Designated — — — At least 5
contacts
Response E-mail within one Calls answered in 3 Within 1 hour for After hours pager: 30
charter business day minutes, response in urgent issues after minutes
one business day business hours
Voicemail: 1 hour
E-mail: 4 hours

A-6 Sniffer Pro and Sniffer Distributed

 Network Associates Support Services

The PrimeSupport options described in the rest of this chapter are

available only in North America. To find out more about PrimeSupport,
Training and Consultancy options available outside North America,
contact your regional sales office. International contact information
appears in the Preface of this guide.

Table A–2. International Prime Support Information

Country or Region Phone Number* Bulletin Board System

Germany +49 (0)69 21901 300 +49 89 894 28 999

France +33 (0)1 4993 9002 +33 (0)1 4522 7601
United Kingdom +44 (0)171 5126099 +44 1344-306890
Italy +31 (0)55 538 4228 +31 (0)20 586 6128
Netherlands +31 (0)55 538 4228 +31 (0)20 586 6128
Europe +31 (0)55 538 4228 +31 (0)20 688 5521
Latin America +55-11-3794-0125 +55-11-5506-9100

* Long distance charges may apply.

Network Associates Consulting and Training

The Network Associates Total Service Solutions program provides you
with expert consulting and comprehensive education that can help you
maximize the security and performance of your network investments. The
Total Service Solutions program includes the Network Associates
Professional Consulting arm and the Educational Services program.

Professional Services
Network Associates Professional Services is ready to assist you during all
stages of your network growth, from planning and design, through
implementation, and with ongoing management. Network Associates
consultants provide an expert’s independent perspective that you can use
as a supplemental resource to resolve your problems. You’ll get help
integrating Network Associates products into your environment, along
with troubleshooting assistance or help in establishing baselines for
network performance. Network Associates consultants also develop and
deliver custom solutions to help accomplish your project goals—from
lengthy, large-scale implementations to brief problem-solving
assignments.

Expert Alarms Reference A-7

Network Associates Support Services

Jumpstart Services
For focused help with specific problem resolution or software
implementation issues, Network Associates offers a Jumpstart Service that
gives you the tools you need to manage your environment. This service
can include these elements:
• Installation and optimization. This service brings a Network
Associates consultant onsite to install, configure, and optimize your
new Network Associates product and give basic operational product
knowledge to your team.
• Selfstart knowledge. This service brings a Network Associates
consultant onsite to help prepare you to perform your new product
implementation on your own and, in some cases, to install the
product.
• Proposal Development. This service helps you to evaluate which
processes, procedures, hardware and software you need before you
roll out or upgrade Network Associates products, after which a
Network Associates consultant prepares a custom proposal for your
environment.

Network Consulting
Network Associates consultants provide expertise in protocol analysis
and offer a vendor-independent perspective to recommend unbiased
solutions for troubleshooting and optimizing your network. Consultants
can also bring their broad understanding of network management best
practices and industry relationships to speed problem escalation and
resolution through vendor support.

You can order a custom consultation to help you plan, design, implement,
and manage your network, which can enable you to assess the impact of
rolling out new applications, network operating systems, or
internetworking devices.

To learn more about the options available:

• Contact your regional sales representative.
• In North America, call Network Associates at (972) 308-9960, Monday
through Friday from 8:00 AM to 7:00 PM Central Time.
• Visit the Network Associates website at:
http://www.nai.com/asp_set/services/introduction/default.asp

A-8 Sniffer Pro and Sniffer Distributed

 Network Associates Support Services

Educational Services
Network Associates Educational Services builds and enhances the skills of
all network professionals through practical, hands-on instruction. The
Educational Services technology curriculum focuses on network fault and
performance management and teaches problem-solving at all levels.
Network Associates also offers modular product training so that you
understand the features and functionality of your new software.

You can enroll in Educational Services courses year-round at Network

Associates educational centers, or you can learn from customized courses
conducted at your location. All courses follow educational steps along a
learning path that takes you to the highest levels of expertise. Network
Associates is a founding member of the Certified Network Expert (CNX)
consortium. To learn more about these programs:
• Contact your regional sales representative.
• Call Network Associates Educational Services at (800) 395-3151 Ext.
2670 (for private course scheduling) or (888) 624-8724 (for public
course scheduling).
• Visit the Network Associates website at:
http://www.nai.com/naicommon/services/education.asp

Expert Alarms Reference A-9

Network Associates Support Services

A-10 Sniffer Pro and Sniffer Distributed

Index

A Attempt to Set Up Multiple SVCC RCCs 1-122

AAL5 CRC Errors 1-111 Authentication Failure 1-60
AAL5 Length Errors 1-111
AAL5 Timeout Errors 1-112 B
Abnormal Disconnect for SVC 1-112 Backward Congestion 1-67
Abort Delimiter Transmitted 1-50 Bad CRC 1-129
AC Errors 1-50 Broadcast/Multicast Data Frames on DDVCC
1-82
Access to Resource Denied 1-11
Broadcast/Multicast Storm 1-129
ACK Frame Timeout 1-59
Broadcast/Multicast Storm Diag 1-130
Ack Too Long 1-35
Browser Election Force 1-11
Address Scoping Violation 1-125
Burst Errors 1-50
Alarm
Expert thresholds 1-2
Application Layer Alarms and Thresholds
C
1-11 Cache ID Set to Zero in DLL Header Ext 1-82
ARE or STE Frames on Data Direct VCC 1-81 CLP = 1 1-113
ARP Request Multi Queued 1-81 Collision after 64 Bytes 1-50
Association Failure 1-59 Collisions Over Threshold 1-130
Async Status Change of Unknown DLCI 1-70 Config Fail, Insufficient Resources 1-82
ATM Application Layer Alarms and Config Frag Info TLV Not Recognized by
Thresholds 1-76 LECS 1-83
ATM Connection Layer Alarms and Config Request Multi Queued 1-83
Thresholds 1-111 Config Request Response Timeout 1-83
ATM Flow Layer Alarms and Thresholds 1-81 Config Request Retry Frame Mismatch 1-84
ATM Host Layer Alarms and Thresholds Config Request Retry Rate Exceeds 1
1-118 Frame/sec 1-84
ATM Link Layer Alarms and Thresholds 1-122 Connect Plan A-2
ATM Node Layer Alarms and Thresholds Connection Layer Alarms and Thresholds 1-35
1-125
Connection Too Short 1-113
Attempt to Bind DLC to MPC and Non-MPOA
Device 1-81 consulting services A-7
Attempt to Bind L3 Address to Multiple contacting
MPOA Devices 1-76 Customer Service xv
Attempt to Multiply Bind MPOA Devices to international NAI offices xviii
LEC 1-82 NAI Technical Support xv

Expert Alarms Reference Index-1

Index

Control Request on DDVCC Retry Frame DLL Header Extension Not Found in Frame
Mismatch 1-84 1-86
Control Request on DDVCC Retry Rate > 1 DTE Sequence Number Error 1-71
Frame/Sec 1-85 Duplicate Address Found 1-51
Crankback Has Occurred 1-113, 1-122 Duplicate ATM Destination Address
Crankback Has Occurred (ATM Node Layer) Registration 1-86
1-125 Duplicate LAN Destination Registration 1-86
CTS Frame Timeout 1-61 Duplicate Network Address 1-40
Customer Service xv Duplicate PDC Name Registration 1-41

D E
Data Frames Detected Following Data Plane educational services, description of A-9
Purge 1-76
EFCI 1-114
Database Summary Exchange Lockstep
Failure 1-85 Egress Cache Tag Was Not Issued 1-87
Database Summary Master/Slave Negotiation Enterprise Plan A-4
Timeout 1-85 Exceeded CIR 1-67
DB Connect Request Denied 1-11 Excessive Abnormal Disconnects 1-118
DB Security Breach Attempt 1-12 Excessive Abnormal Frame Sequences 1-118
DB Slow Connect 1-12 Excessive Failed Domain Logins 1-15
DB Slow Server Response 1-13 Excessive Failed Resource Login Attempts
DB Slow Server Response Diagnosis 1-14 1-15
DCE Sequence Number Error 1-70 Excessive Hello Frames Detected 1-123
DDVCC Idle Period Exceeds VCC Timeout Excessive Mailslot Broadcasts 1-16
C12 1-76 Excessive Short Connections 1-119
DDVCC Not Created in Response to LE ARP Excessive Signaling Recovery 1-114
1-77
Excessive Unknown Frames Issued by LEC
Deauthentication 1-61 1-78
Default MCFVCC Not Created in Response to Expert
LE ARP 1-77 diagnoses 1-1
Default MCSVCC Not Created in Response to symptoms 1-1
LE ARP 1-77 thresholds 1-2
Delayed STATUS ENQUIRY 1-70
Denied Access to ELAN 1-86 F
Diagnosis in Expert analysis 1-1 Failed to Issue Resolution Req. Following
Disassociation 1-62 Trigger 1-87
DLC Layer Alarms and Thresholds 1-50 Failure Reported in Reply CIE 1-87
DLC Source Address Broadcast 1-50 Fast Retransmission 1-35
DLC Source Address Multicast 1-51 FCI and ARI Bits Mismatch 1-52
File Retransmission 1-23

Index-2 Expert Alarms Reference

 Index

Flush Request Multi Queued 1-87 Idle Too Long 1-36

Forward Congestion 1-67 IG Tag Violation 1-88
Frame Has Alignment Problem 1-52 Insufficient Info from LEC, Service Refused
Frame-Copied Errors 1-52 1-88
Frames Seen on Default Flow After Shortcut Invalid ATM Primary Address 1-88
Active 1-78 Invalid CIE Contents 1-89
Frequency Errors 1-52 Invalid Client ATM Primary Source Address
FTP Login Attempts 1-16 1-89
FTP Slow Connect 1-16 Invalid Client MAC Address 1-89
FTP Slow First Response 1-17 Invalid Common Header Contents 1-89
FTP Slow Response 1-17 Invalid Fixed Header Contents 1-90
FTP Slow Transfer Diagnosis 1-17 Invalid Frame Contents 1-90
Invalid Frame Status Field 1-54
G Invalid Hello Frame 1-91
Global Layer Alarms and Thresholds 1-129 Invalid MPOA Packet Size 1-92
Invalid Network Name 1-18
H Invalid Port ID 1-126
High Rate of Line/Burst Errors 1-52 Invalid Presentation Context ID 1-23
High Rate of Physical Errors 1-53 Invalid Resource User Name or Password 1-18
High Rate of Receiver Congestion Errors 1-53 Invalid Tag in Data Frame Header 1-92
High Rate of Ring Purge Diagnosis 1-54 IP Fragment Missing 1-44
High Signaling Activity 1-119 IP Fragment Out of Order 1-44
Host Address Cannot Be Mux’ed 1-119 IP NETBIOS Session Reject 1-23
Host Bound to Multiple Nodes 1-126 Irregular Full Status Report Requests 1-71
HTTP Slow Server GET Response Time 1-17
HTTP Slow Server POST Response Time 1-18 J
Join Request Multi Queued 1-92
I Join Request Received from LES 1-92
ICMP Destination Unreachable 1-41 Join Request Transmitted by LES 1-93
ICMP Host Unreachable 1-41 Join Response Issued by LEC 1-93
ICMP Inconsistent Subnet Mask 1-42
ICMP Net Unreachable 1-42 K
ICMP Parameter Problem 1-42 Keep Alive Lifetime Ext Not Found in Frame
1-94
ICMP Port Unreachable 1-42
Keep Alive Lifetime Set to Zero 1-93
ICMP Redirect for Host 1-43
Keep Alive Sequence Failure 1-93
ICMP Redirect for Network 1-43
KnowledgeCenter A-1
ICMP Source Quench 1-44

Expert Alarms Reference Index-3

Index

L M
LAN Overload 1-131 MAC Address bound to Multiple LECs 1-98
LAN Overload Percentage 1-131 Max Transmission Unit Size Undefined 1-98
LANE Cfg Phase Failure 1-78 Misdirected Frame 1-45
LANE Cfg Restart Delay 1-79 Missed Browser Announcement 1-19
LANE Cfg Restart Delay > Max Recfg Delay Missing DTL or Excessive DTL Size 1-115
1-79 Missing Fragment Number 1-63
LANE Control Request Response Timeout Missing ULIA on Outside Link 1-98
1-94
MPCMPS Flow Not Allowed on this VC 1-115
LANE Control Request Retry Rate > 1
Frame/sec 1-95 MPOA Capable LEC Did Not Issue Device
TLV 1-98
LANE Control Request Retry Retry Frame
Mismatch 1-94 MPOA Config Parameter Invalid 1-99
LANE Version Unsupported by ELAN 1-95 MPOA Control Request Response Timeout
1-99
LE ARP Request Rate Exceeds 1 Frame/Sec
1-95 MPOA Control Request Retry Rate > 1
Frame/sec 1-100
LE_CONFIGURE Params Conflict, Service
Refused 1-95 MPOA Error Frame Detected 1-100
LEC ID in Frame Mismatch with Client LEC MS RAP Logon Failure 1-19
ID 1-97 Multicast/Broadcast Fragmentation 1-62
LEC Issued Config Response to LECS 1-96 Multiple Local Ring Definition 1-55
LEC Not Recognized by LECS 1-96 Multiple Routers to Local 1-45
LECID Is Not 0x0000 in Request Frame 1-97 Multiple Routers to Remote 1-46
LECS Issued Config Request to LES 1-97 Multiply Assigned Secondary LEC Address
Line Errors 1-54 1-101
Link Inactivity Failure 1-123
Link Management Message Format Error 1-71 N
Link Management Message Minor Format NAI Technical Support, contacting xv
Error 1-72 NARP Request Multi Queued 1-101
Local Limit on Defined Context Set Exceeded NARP Request Received from LES 1-102
1-23 NCP Server Busy 1-20
Local Routing 1-36 Network Associates
Local Segment ID not in Source Routed Frame consulting services A-7
1-97
educational services A-9
Local Station with Route Designator 1-54 international offices xviii
Loops on Same Request 1-23 Sniffer University A-7
Lost Frame Errors 1-55 Network Equipment Reset 1-72
Low Throughput 1-24 New Active Monitor 1-55
New PVC Configured 1-73

Index-4 Expert Alarms Reference

 Index

NFS Retransmission 1-20 PVC Deactivation 1-68, 1-74

NNTP Slow Response Time 1-20 PVC Deletion 1-68, 1-74
No CIEs Were Present in MPOA Reply 1-102
No CIEs Were Present in MPOA Request 1-102 R
No Reply Flag Is Not Set in ICache Purge 1-102 Read/Write Overlap 1-25
No Resolution Request Issued After Excess Reassociation Failure 1-64
Default Flow 1-80 Receiver Congestion Errors 1-55
No STATUS ENQUIRY When Expected 1-73 Register Request Multi Queued 1-103
No STATUS following STATUS ENQUIRY Register Request Received from LES 1-103
1-73
Register Response Issued by LEC 1-103
Non-Responsive Station 1-36
Remote Address Issued by Non Proxy LEC
Nonsense Route 1-135 1-104
Repeat Ack 1-37
O Request Denied 1-25
ordering PrimeSupport plans A-5 Request Params Are Incompatible with ELAN
Oversized Frame 1-55 1-104
Oversized WLAN Frame 1-64 Restricted Branching Violation 1-128
Retransmission 1-37
P Returned to Ring 1-56
Parent Node Association Change 1-127 Ring Beaconing 1-56
Peer Group ID Has Changed 1-127 Ring Purge Symptom 1-56
Peer Group Leader Has Changed 1-127 Rogue Access Point 1-64
PLCP Error 1-132 Route Flapping 1-46
POP3 Slow Connect Time 1-21 Route Layer Alarms and Thresholds 1-135
Possible 3.0/3.1 UNI Mismatch 1-116 Route Metric Changed 1-135
Prime Support A-6 Route Superseded 1-136
Priority Plan A-3 Route Validity Changed 1-136
product training Router Not Updating Routes 1-46
see Sniffer University Router Storm 1-47
Professional Consulting Services A-7 Router Superseded Too Frequently 1-47
Protocol Negotiation Failure 1-21 Routing Frames Detected on Outside Link
Protocol Version Support Incompatible 1-123 1-124
PRSE Request Timeout 1-128 Runt Frame 1-57
PTSE Acknowledge Timeout 1-127 Runt WLAN Frame 1-65
PTSE Violation 1-102
PVC Activation 1-67, 1-73 S
PVC Bandwidth Change 1-68, 1-73 Same Source and Destination Address 1-57
PVC Congestion 1-68, 1-74 Same Transmitter and Receiver Address 1-65

Expert Alarms Reference Index-5

Index

SAP R3 Slow Server Connection 1-21 The Operation Number Is Greater than the
SAP R3 Slow Server Response 1-21 Number of Operations in the Interface 1-26
SCCP - Register Reject alarm 1-23 The Output Parameters of the Operation
Exceed Their Declared Maximum Size 1-26
Server Running BDC Shutting Down 1-47
The RPC Client or Server Protocol Has Been
Server Running PDC Shutting Down 1-48 Violated 1-27
Server Running WINS Shutting Down 1-48 The Server Did Not Support the Requested
Service Layer Alarms and Thresholds 1-5 Authentication Level 1-27
Session Layer Alarms and Thresholds 1-23 The Server Does Not Implement the
Shortcut Create Failed After Resolution Reply Requested Operation for the Type of
Requested Object 1-27
1-80
Signaling Frame Sequence Problem 1-116 The Server Does Not Support the Interface
1-27
Slow File Transfer 1-26
The Server Does Not Support the Proposed
Slow FTP Server 1-5 Transfer Syntaxes 1-27
Slow HTTP Server 1-5 The Server Does Not Support the Requested
Slow Mail Server 1-6 Interface 1-27
Slow News Server 1-6 The Server Does Not Support the RPC
Protocol Version 1-27
Slow Oracle SQL Server 1-6
The Server Is Too Busy To Handle the Call 1-28
Slow POP3 Server 1-8
The Server Manager Routine Has Not Been
Slow Server 1-37
Entered and Executed 1-28
Slow Sybase/Microsoft SQL Server 1-9
Thresholds
Slow Telnet Server 1-10 Expert 1-2
SMTP Slow Connect Time 1-22 Time-to-live Exceeded in Transmit 1-49
Sniffer University xvi, A-7 Time-to-live Expiring 1-49
Source Address Is Broadcast 1-48 TNS Connect Refused 1-28
Spanning Tree Topology Change 1-132 TNS Security Breach Attempt 1-28
Station Internal Errors 1-57 TNS Slow Connect 1-28
Station Not in Domain’s Computer List 1-22 TNS Slow Server Diagnosis 1-29
Station Off Ring 1-57 TNS Slow Server Response 1-30
Station Removed 1-57 Token Errors 1-58
SVCC RCC Dropped 1-124 Too Many File Retransmissions 1-32
Symptom in Expert analysis 1-1 Too Many Loops on Same Request 1-32
Too Many Removes 1-58
T Too Many Requests Denied 1-33
TA List Resources Exhausted 1-105 Too Many Retransmissions 1-38
Technical Support xv Too Many Returns 1-58
Telnet Slow Response to Login 1-22 Too Many Simultaneous Connections 1-120
Temporary Congestion 1-26

Index-6 Expert Alarms Reference

 Index

Topology Change Request Multi Queued Unsolicited STATUS Message 1-75

1-105 User Equipment Reset 1-75
Topology Mismatch in Data Frame Types
1-105
V
Total Education Services A-7
V2 TLVs Issued in V1 ELAN 1-109
Traffic on Deleted DLCI 1-69
Verify Request Multi Queued 1-110
Traffic on Inactive DLCI 1-69
Verify Request Received from LES 1-110
Traffic on Unknown DLCI 1-69
Verify Response Issued by LEC 1-110
training
VLAN Not Operational 1-134
see Sniffer University
VLAN Removed from Domain 1-134
Transmitter Address Broadcast 1-66
Transmitter Address Multicast 1-66 VTP Versions Different 1-135

U W
UDP Bouncing Frames 1-38 WAN Connection Layer Alarms and
Thresholds 1-67
Unexpected Data for SVC 1-116
WAN Link Layer Alarms and Thresholds 1-70
Unexpected Data for SVC (ATM Host Layer)
WEP-ICV Error 1-66
1-120
Window Frozen 1-39
Unexpected DLL Header EXT in Frame 1-105
Window Size Exceeded 1-39
Unexpected Egress Cache EXT in Frame 1-106
WINS Duplicate Name 1-33
Unexpected Hop Count EXT in Frame 1-106
WINS No Response 1-34
Unexpected Keepalive Lifetime EXT in Frame
1-106 Wrong Report Type in STATUS Message 1-75
Unexpected Link Management Message 1-74
Unexpected Original Error Code EXT in Z
Frame 1-106 Zero Broadcast Address 1-49
Unexpected Service Category EXT in Frame Zero Window Too Long 1-39
1-107
Unexpected TLVs Detected 1-107
Unknown Extension in Frame 1-107
Unknown IG 1-107
Unknown LANE ConfigControl Opcode 1-108
Unknown Marker/Protocol Values 1-108
Unknown/Unexpected Authenticate EXT in
Frame 1-108
Unknown/Unexpected CIE in Frame 1-108
Unregister Request Multi Queued 1-108
Unregister Request Received from LES 1-109
Unregister Response Issued by LEC 1-109

Expert Alarms Reference Index-7

Index

Index-8 Expert Alarms Reference