Sniffer Pro and Sniffer Distributed Referenceread.pudn.com/downloads118/ebook/499714/教程...Table...

Sniffer Pro and

Expert Alarms

Release 4.7

Reference

Sniffer Distributed

COPYRIGHT

Copyright © 2002 Networks Associates Technology, Inc. All Rights Reserved. No part of thispublication may be reproduced, transmitted, transcribed, stored in a retrieval system, ortranslated into any language in any form or by any means without the written permission ofNetworks Associates Technology, Inc., or its suppliers or affiliate companies. To obtain thispermission, write to the attention of the Network Associates legal department at: 3965 FreedomCircle, Santa Clara, California 95054, or call (972) 308-9960.

TRADEMARK ATTRIBUTIONS

ActiveSecurity, ActiveHelp, ActiveShield, Antivirus Anyware (and design), Bomb Shelter, Building aWorld 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 (inKatakana), 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, MagicUniversity, 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 (inKatakana), 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, ServiceLevel Manager, ServiceMagic, Site Meter, Smart Desk, Sniffer, Sniffer (in Hangul), SniffMaster,SniffMaster (in Hangul), Sniffmaster (in Katakana), SniffNet, Stalker, Stalker (stylized), StatisticalInformation Retrieval (SIR), SupportMagic, Switch PM, TeleSniffer, TIS, TMach, TMeg, TotalNetwork 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 yourNetwork, Wingauge, ZAC 2000, and Zip Manager are registered trademarks of NetworkAssociates, Inc. and/or its affiliates in the US and/or other countries. All other registered andunregistered 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 THESOFTWARE THAT THIS DOCUMENTATION DESCRIBES, CONSULT THE LICENSE.TXTOR OTHER LICENSE DOCUMENT THAT ACCOMPANIES YOUR SOFTWARE, EITHER ASA TEXT FILE OR AS PART OF THE SOFTWARE PACKAGING. IF YOU DO NOT AGREE TOALL OF THE TERMS SET FORTH THEREIN, DO NOT INSTALL THE SOFTWARE. IFAPPLICABLE, YOU MAY RETURN THE PRODUCT TO THE PLACE OF PURCHASE FOR AFULL REFUND.

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

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvAbout 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-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-1Adding 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 ManualThis 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 ServiceFor 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.

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

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 Service13465 Midway Rd.Dallas, Texas 75244USA

xv

http://www.nai.com

http://www.nai.com/asp_set/services/technical_support/tech_intro.asp

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 DownloadsTo 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 InformationSniffer 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 TrainingSince 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

http://www.sniffer.com/education/default.asp

http://www.sniffer.com/education/default.asp

Preface

International Contact InformationTo 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 Australia

Level 1, 500 Pacific HighwaySt. Leonards, NSWSydney, Australia 2065

Phone:61-2-8425-4200Fax:61-2-9439-5166

Austria Network Associates Austria

Pulvermuehlstrasse 17Linz, AustriaPostal Code A-4040

Phone:43-732-757-244Fax:43-732-757-244-20

Belgium Network AssociatesBelgique

BDC Heyzel Esplanade, boîte 431020 BruxellesBelgique

Phone:0032-2 478.10.29Fax:0032-2 478.66.21

Brazil Network Associatesdo Brasil

Rua Geraldo Flausino Gomez 78Cj. - 51 Brooklin Novo - São PauloSP - 04575-060 - Brasil

Phone:(55 11) 5505 1009Fax:(55 11) 5505 1006

Canada Network AssociatesCanada

139 Main Street, Suite 201Unionville, OntarioCanada L3R 2G6

Phone:(905) 479-4189Fax:(905) 479-4540

China Network AssociatesPeople’s Republic of China

New Century Office Tower, Room 1557No. 6 Southern Road Capitol GymBeijingPeople’s Republic of China 100044

Phone:8610-6849-2650Fax:8610-6849-2069

Denmark Network Associates Denmark

Lautruphoej 1-32750 BallerupDanmark

Phone:45 70 277 277Fax:45 44 209 910

Finland NA Network Associates Oy

Mikonkatu 9, 5. krs.00100 HelsinkiFinland

Phone:358 9 5270 70Fax:358 9 5270 7100

xviii Sniffer Pro and Sniffer Distributed

Preface

France Network AssociatesFrance S.A.

50 Rue de Londres75008 ParisFrance

Phone:33 1 44 908 737Fax:33 1 45 227 554

Germany Network AssociatesDeutschland GmbH

Ohmstraße 1D-85716 UnterschleißheimDeutschland

Phone:49 (0)89/3707-0Fax:49 (0)89/3707-1199

Hong Kong Network Associates Hong Kong

19th Floor, Matheson Centre3 Matheson WayCauseway BayHong Kong 63225

Phone:852-2832-9525Fax:852-2832-9530

Italy Network Associates Srl Centro Direzionale SummitPalazzo D/1Via Brescia, 2820063 - Cernusco sul Naviglio (MI)Italy

Phone:39 02 92 65 01Fax:39 02 92 14 16 44

Japan Network Associates Japan, Inc.

Shibuya Mark City West 20F1-12-1 Dougenzaka, Shibuya-kuTokyo 150-0043, Japan

Phone:81 3 5428 1100Fax:81 3 5428 1480

Latin America Network Associates Latin America

1200 S. Pine Island Road, Suite 375Plantation, Florida 33324 United States

Phone:(954) 452-1731Fax:(954) 236-8031

Mexico Network Associatesde Mexico

Andres Bello No. 10, 4 Piso4th FloorCol. PolancoMexico City, Mexico D.F. 11560

Phone:(525) 282-9180Fax:(525) 282-9183

The Netherlands

Network AssociatesInternational B.V.

Gatwickstraat 251043 GL AmsterdamThe Netherlands

Phone:31 20 586 6100Fax:31 20 586 6101

Portugal Network AssociatesPortugal

Av. da Liberdade, 1141269-046 LisboaPortugal

Phone:351 1 340 4543Fax:351 1 340 4575



Expert Alarms Reference xix

Preface

South Africa Net Tools Network AssociatesSouth Africa

Hawthorne HouseSt. Andrews Business ParkMeadowbrook LaneBryanston, JohannesburgSouth Africa 2021

Phone:27 11 700-8200Fax:27 11 706-1569

South East Asia

Network AssociatesSouth East Asia

78 Shenton Way#29-02Singapore 079120

Phone:65-222-7555Fax:65-220-7255

Spain Network AssociatesSpain

Orense 4, 4a Planta.Edificio Trieste28020 Madrid, Spain

Phone:34 9141 88 500Fax:34 9155 61 404

Sweden Network Associates Sweden

Datavägen 3ABox 596S-175 26 JärfällaSweden

Phone:46 (0) 8 580 88 400Fax:46 (0) 8 580 88 405

Switzerland Network Associates AG

Baeulerwisenstrasse 38152 GlattbruggSwitzerland

Phone:0041 1 808 99 66Fax:0041 1 808 99 77

Taiwan Network AssociatesTaiwan

Suite 6, 11F, No. 188, Sec. 5Nan King E. Rd.Taipei, Taiwan, Republic of China

Phone:886-2-27-474-8800Fax:886-2-27-635-5864

United Kingdom

Network AssociatesInternational Ltd.

227 Bath RoadSlough, BerkshireSL1 5PPUnited Kingdom

Phone:44 (0)1753 217 500Fax:44 (0)1753 217 520



xx Sniffer Pro and Sniffer Distributed

1Expert Alarms and Thresholds1

OverviewThis 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 AlarmsDuring 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

Figure 1–1. Expert Alarms in the Expert Display

About Expert ThresholdsExpert 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.

Expert alarm counts are provided at each layer in the Overview Pane of the Expert display.

Selecting an alarm in the Summary Pane lets you see detailed alarm information in the Detail Pane (including a “?' link to the Expert Explain file for the alarm).

1-2 Sniffer Pro and Sniffer Distributed


Figure 1–2. Setting Expert Thresholds

Click to expand/collapse all Expert layers

Click the + to open an Expert layer and display all symptoms and diagnoses (alarms)

Click the + to display the settings for this alarm.

Click in the Threshold Value cell and type the new threshold value

Click to reset all settings for all layers to the factory defaults

Click to reset the selected value to the factory default.

The thresholds display at the end of the settings list

Click to specify whether the alarm should appear in the alarm log.

Click to set the severity of this alarm. Different severities can be associated with different actions.

Expert Alarms Reference 1-3


Expert Alarms and Thresholds DescriptionsThis 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



Service Layer Alarms and ThresholdsThis 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 ServerThe 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 ServerThe 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.



Slow Mail ServerThe 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.


Slow News ServerThe 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.


Slow Oracle SQL ServerThe 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.



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:



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




Slow Sybase/Microsoft SQL ServerThe 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.








c. Add more MPIs.














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:


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




Application Layer Alarms and ThresholdsThis 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 DeniedThe 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 ForceThe 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 DeniedThe Expert generates the DB Connect Request Denied alarm when the number of SQL Server connect requests denied exceeds the DB Connection Failed threshold. A request to login is refused by the server,



because it is unable to satisfy the options asked for in the login record. Examine the service options in the connect packet and determine whether they are options that are allowed in the target server.

Possible causes: 1. Invalid username.

2. Invalid password.

3. Invalid server.

DB Security Breach AttemptThe Expert generates the DB Security Breach Attempt alarm when the number of login failures exceeds the DB Security Breach Attempt threshold.



3. Invalid server.

DB Slow ConnectThe 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.



DB Slow Server ResponseThe 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.








c. Add more MPIs.

















DB Slow Server Response DiagnosisThe 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.








c. Add more MPIs.

















Excessive Failed Resource Login AttemptsThe 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.



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


FTP Slow ConnectThe 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.




FTP Slow First ResponseWhen 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 ResponseWhen 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 DiagnosisThe 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 TimeThe 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.




HTTP Slow Server POST Response TimeThe 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.



Invalid Network NameThe 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 PasswordThe 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).



Missed Browser AnnouncementThe 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 FailureThe 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.



NCP Server BusyThe 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 RetransmissionThe 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 TimeThe 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.




POP3 Slow Connect TimeThe 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.


Protocol Negotiation FailureThe 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 ConnectionThe 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 ResponseThe 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.



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


Station Not in Domain’s Computer ListThe 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 LoginThe 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.




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

File RetransmissionThe 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 IDThe Expert generates this alarm when it detects an invalid presentation context ID on an RPC connection.

IP NETBIOS Session RejectThe 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 ExceededThe 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 RequestThe Expert generates the Loops on Same Request alarm when it sees the application process on one station send out the same request even though



it has already received the appropriate reply from the destination station. Only requests that are sent within the time specified by the Filter time threshold are considered “repeated.”

Possible causes: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 ThroughputThe 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.



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



Slow File TransferThe 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 CongestionThe 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.



The RPC Client or Server Protocol Has Been ViolatedThe Expert generates this alarm when it detects that the RPC client or server protocol was violated.

The Request Is Being Rejected for Unspecified ReasonsThe 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 LevelThe 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 InterfaceThe 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 InterfaceThe 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 SyntaxesThe 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 VersionThe Expert generates this alarm when it detects that a server does not support the RPC protocol version specified in the bind PDU.



The Server Is Too Busy To Handle the CallThe 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 ExecutedThe 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 RefusedThe 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.



3. Invalid server.

TNS Security Breach AttemptThe 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 ConnectThe Expert generates the TNS Slow Connect alarm when the time a server or a Multiprotocol Interchange (MPI) takes to respond to a TNS Connect Request or a login request exceeds the Oracle Slow Connect Time threshold.



This may or may not be a problem, depending upon the application environment. The Oracle Slow Connect Time threshold should be adjusted to the desired or typical connect response time in your application environment.

Possible causes:1. The server is overloaded.

2. The MPI is too busy.

3. The server or MPI is misconfigured.

TNS Slow Server DiagnosisThe 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.








c. Add more MPIs.








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:












TNS Slow Server ResponseThe 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.










c. Add more MPIs.












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:








Too Many File RetransmissionsThe 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 RequestThe Expert generates the Too Many Loops on Same Request alarm when the ratio of repeated requests (loops) to normal requests (expressed as a percentage) on a session exceeds the Loop % threshold.

This alarm is only generated after the total number of application requests seen by the analyzer exceeds the Min Appl Req threshold.

A repeated request is one that is sent out even though the proper response to the previous request has already been seen by the analyzer. The analyzer does not count certain repeated requests. For example, if a repeated request is sent after the Filter time threshold expires, the analyzer "forgets" the previous request and does not consider it to be repeated. A normal request is any request that is not considered repeated.



Possible causes: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 DeniedThe 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 NameThe 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.



WINS No ResponseThe 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.



Connection Layer Alarms and ThresholdsThis 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 LongThe 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 RetransmissionThe 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.



Idle Too LongThe 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 RoutingThe 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 StationThe 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. Improperly configured software.

2. An overloaded server.

3. Faulty hardware.

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

RetransmissionThe 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 ServerThe Expert generates the Slow Server alarm when the ratio of slow responses to total responses for a particular station exceeds the Slow Response % threshold. A slow response is one in which the time between request and response is longer than the Response Time threshold.



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



Window FrozenThe 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 ExceededThe 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 LongThe 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.



5. A fast station is overwhelming a slow one.

Station Layer Alarms and ThresholdsThis 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 AddressThe 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.



Duplicate PDC Name RegistrationThe 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 UnreachableThe 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 UnreachableThe 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.


The situation can be investigated further by PINGing another host on the same segment as the one that sent the ’host unreachable’ message.



ICMP Inconsistent Subnet MaskThe 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 UnreachableThe 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.


5. The station sending this packet may have a misconfigured netmask.

ICMP Parameter ProblemThe Expert generates the ICMP Parameter Problem alarm when it sees a station send an ICMP message indicating a parameter problem.

ICMP Port UnreachableThe Expert generates the ICMP Port Unreachable alarm when a station receives an ICMP port unreachable message. The message indicates that this station previously transmitted a frame to a port. The station that sent the port unreachable message is saying that the port cannot be accessed by the requesting station.



Possible causes: 1. The requested service is not implemented or not active on the station

that sent the message, or is in use.


ICMP Redirect for HostThe 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 NetworkThe 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.



ICMP Source QuenchThe 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 MissingThe 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 OrderThe 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.



Possible cause: 1. There may be multiple paths between the endpoint stations.

Misdirected FrameThe 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 LocalThe 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.



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 RemoteThe 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 FlappingThe 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 RoutesThe 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.



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 StormThe 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 FrequentlyThe 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 DownThe Expert generates the Server Running BDC Shutting Down alarm when it sees a node acting as a Backup Domain Controller shut down. This alarm is only generated if a WINS Release packet is seen from the node that is shutting down.



Possible cause: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 DownThe 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 DownThe 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 BroadcastThe Expert generates the Source Address Is Broadcast alarm when it detects a frame with the source address field set to a broadcast address. A source address should not be a broadcast address.



Time-to-live Exceeded in TransmitThe 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 ExpiringThe 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 AddressThe 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.



DLC Layer Alarms and ThresholdsThis 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 TransmittedThe 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 ErrorsThe 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 BytesThe 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 BroadcastThe Expert generates the DLC Source Address Broadcast alarm when it sees a frame with the source DLC address field set to a broadcast address.



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



FCI and ARI Bits MismatchThe 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 ProblemThe 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 ErrorsThe 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 ErrorsThe 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 ErrorsThe 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.



Possible cause:1. A large number of these errors may indicate a hardware problem.

Check the fault domain.

High Rate of Physical ErrorsThe 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 ErrorsThe 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.



High Rate of Ring Purge DiagnosisThe 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 FieldThe 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 ErrorsThe 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 DesignatorThe 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.



Lost Frame ErrorsThe 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 DefinitionThe 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 MonitorThe Expert generates the New Active Monitor alarm when the active monitor on the ring changes.

Oversized FrameThe Expert generates the Oversized Frame alarm when it captures an Ethernet packet whose length is greater than 1518 bytes.

Receiver Congestion ErrorsThe 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.



Returned to RingThe 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 BeaconingThe 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 SymptomThe 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.



Runt FrameThe 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 AddressThe Expert generates the Same Source and Destination Address alarm when it detects a frame with the same DLC source and destination address.

Station Internal ErrorsThe 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 RingThe 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 RemovedThe Expert generates the Station Removed alarm when the configuration report server asks a station to leave the ring.



Token ErrorsThe 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 RemovesThe 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 ReturnsThe 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.



Wireless Layer Alarms and ThresholdsThis 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 TimeoutThe 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 FailureThe 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.



• 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 FailureThe 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:


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

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

• 15 — Authentication rejected because of challenge failure.

• 16 — Authentication rejected due to timeout waiting for next frame in sequence.



CTS Frame TimeoutThe 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.

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



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



Missing Fragment NumberThe 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).



Oversized WLAN FrameThe 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 FailureThe Expert generates the Reassociation Failure alarm when it detects an 802.11 Reassociation Response frame with a value other than zero in the Status Code field. A non-zero value in the Status Code field indicates that the access point sending the Reassociation Response is denying the requested association.

Wireless stations send Reassociation Request frames to become associated with a different access point within the same network as its current access point (for example, because the station has moved and is now out of range of its old access point and within range of another). In turn, access points reply to Reassociation Requests with Reassociation Responses indicating the success or failure of the request. In this case, the access point denied the Reassociation Request. The exact reason for the denial is found in the Status Code field of the Reassociation Response. The Expert reports both the address of the access point denying the Reassociation Request, as well as the reason for the denial indicated in the Status Code field, as follows:


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

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

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

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

• 18 — Association denied due to requesting station not supporting all of the data rates in the BSSBasicRateSet parameter.

Rogue Access PointThe 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.



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 FrameThe 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 AddressThe 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



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 BroadcastThe 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 MulticastThe 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 ErrorThe 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.



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 ThresholdsThis 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 CongestionThe 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 CIRThe 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 CongestionThe 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 ActivationThe 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 ChangeOn 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 CongestionThe 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 DeactivationThe Expert generates the PVC Deactivation alarm when the PVC Status information element’s Active bit changes from true to false (1 to 0).

PVC DeletionThe Expert generates the PVC Deletion alarm in either of the following cases:

• A full status report was seen without an entry for the indicated DLCI (and there was an entry for the DLCI in the previous full status report).

In a correctly operating Frame Relay link, connected user equipment issues STATUS ENQUIRY messages at regular intervals. This can be a simple "keep alive" type of enquiry, in which the subscriber tells the WAN that it is still active, and receives a confirmation from the WAN. Alternatively, it can be a "full status" request, to which the WAN responds with a full status report giving the status of all the virtual connections attached to the local Frame Relay link.

Typically, connected user equipment issues STATUS ENQUIRY messages every ten seconds with every sixth message requesting the full status report (though the exact interval may be different on some Frame Relay links).

The Expert learns about the DLCIs on the Frame Relay link by monitoring the STATUS ENQUIRY requests and the status reports sent by the network in response to these requests and stores what it learns about the network in memory.

• A PVC Status information element for this DLCI with the Deleted bit set to true appears in a single PVC status report or UPDATE STATUS message.



Traffic on Deleted DLCIThe 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 DLCIThe 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 DLCIThe 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.



WAN Link Layer Alarms and ThresholdsThis 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 DLCIThe 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 ErrorThe 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 ENQUIRYIn 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.



DTE Sequence Number ErrorThe 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 RequestsIn 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 ErrorThe 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).



• 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 ErrorThe 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 ResetThe Expert generates the Network Equipment Reset alarm when it sees a STATUS message sent by the network side of the link with a Send Sequence Number set to 1. The sequence number of 1 indicates that this is the first STATUS message sent by the network since a reset.

Note that the Expert only generates this alarm if 1 is not the correct sequential value for this message. Sequence numbers on a Frame Relay link increment in ones from 1 to 255 and then restart again at 1.



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

No STATUS ENQUIRY When ExpectedIn 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 ENQUIRYThe 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.


PVC ActivationThe 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 ChangeOn 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 CongestionThe 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 DeactivationThe Expert generates the PVC Deactivation alarm when the PVC Status information element’s Active bit changes from true to false (1 to 0).

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


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 MessageThe Expert generates the Unexpected Link Management Message alarm when a link management message is seen emanating from the wrong side of the link (for example, a STATUS message coming from the user side of the link).



Unsolicited STATUS MessageThe 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.


User Equipment ResetThe 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 MessageThe Expert generates the Wrong Report Type in STATUS Message alarm when it sees a STATUS message sent in response to a request for a full status report that contains only sequence number exchange information (and does not include the requested full status report).



ATM Application Layer Alarms and ThresholdsThis 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 DevicesThe 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 PurgeThe 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 C12The Expert generates the DDVCC Idle Period Exceeds VCC Timeout C12 alarm when a LEC fails to release a Data Direct Virtual Circuit Connection that has been idle for longer than the time specified by its C12 VCC Time-out Period initial state parameter. The Expert uses timeout values as follows:

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



• If the Expert has not been able to learn the C12 VCC Time-out Period parameter, it uses the DDVCC VCC Timeout Period C12 threshold in the Alarms tab of the Expert UI Object Properties dialog box. By default, NAI sets this threshold to 20 minutes (the same default as the ATM Forum).

DDVCC Not Created in Response to LE ARPWhen 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 ARPThe 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 ARPThis alarm is generated when the analyzer sees a LEC send an LE_ARP to the LES for the destination MAC address FF FF FF FF (that is, broadcast) without a corresponding Multicast Send VCC being set up with the BUS within the time limit specified by the Default MCSVCC Setup in



Response to LE_ARP threshold in the Alarms tab of the Expert UI Object Properties dialog box.

The Multicast Send data flow is set up by the LEC with the BUS to carry all broadcast, multicast, and unknown data from the LEC to the BUS (and in some cases, from the BUS to the LEC). When a LAN MAC frame with a broadcast destination address arrives at the LEC, it sends it to the BUS. At least one MCS flow remains active from each LEC during its participation in the ELAN. The MCS is point-to-point and bidirectional. There are different MCS flows for both 802.3 and 802.5 networks.

Excessive Unknown Frames Issued by LECThe 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 ActiveThe 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 FailureDuring 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.



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



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



ATM Flow Layer Alarms and ThresholdsThis 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 VCCWhen 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 QueuedThe 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 DeviceThe Expert generates the Attempt to Bind DLC to MPC and Non-MPOA Device alarm when it detects an attempt to bind a DLC address to both an MPC and a non-MPOA device.

All MPOA devices have layer two (L2) DLC addresses assigned to them. Although an MPS can share its L2 DLC address with a representative LEC,



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

Attempt to Multiply Bind MPOA Devices to LECThe 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 DDVCCLAN 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 ExtThe 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 ResourcesLAN 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.



Config Frag Info TLV Not Recognized by LECSDuring 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 QueuedThe Expert generates the Config Request Multi Queued alarm when it sees a A LAN Emulation entity resend a Configure Request frame with the same Transaction ID as the Configure Request frame. This is a violation of the LAN Emulation standard.



Config Request Response TimeoutThe Expert generates the Config Request Response Timeout alarm when a LEC sends a Configure Request frame to the LECS but does not receive a Configure Response frame before the timeout value specified by the C7 Control Time-out initial state parameter. The ATM Forum specifies a



minimum value of 10 seconds for this timeout, with a default value of 30 seconds and a maximum of 300 seconds.

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.


2. The LECS has received a large number of simultaneous requests from various LECs.

Config Request Retry Frame MismatchThe 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/secThe 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 MismatchThe 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



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/SecThe 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 FailureThe 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 TimeoutThe 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.



Denied Access to ELANThe 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 FrameThe 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 RegistrationThe 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 RegistrationThe 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.



Egress Cache Tag Was Not IssuedThe 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 TriggerThe 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 CIEThe 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 QueuedThe Expert generates the Flush Request Multi Queued alarm when a LAN Emulation entity resends a Flush request with the same Transaction ID as the original Flush request. This is a violation of the LAN Emulation standard.





IG Tag ViolationThe 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 RefusedThe 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 AddressThe 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.



Invalid CIE ContentsThe 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 AddressThe 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 AddressThe 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 ContentsThe 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.



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

Invalid Fixed Header ContentsThe 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 ContentsThe Expert generates the Invalid Frame Contents alarm when it detects a PNNI frame which exhibits one or more of the following errors:

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

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

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



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

• The originating Peer Group ID or Node ID in the PNNI frame does not match that of the node issuing the frame.

Invalid Hello FrameThe 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 TLVThe 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.



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 SizeThe 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 HeaderThe 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 QueuedThe Expert generates the Join Request Multi Queued alarm when a LAN Emulation entity resends a Join request with the same Transaction ID as the original Join request. This is a violation of the LAN Emulation standard.



Join Request Received from LESThe Expert generates the Join Request Received from LES alarm when a LEC receives a Join Request frame from the LES. This is the opposite of



standard operating procedure in an ELAN. Join Request frames are ordinarily sent by the LEC to the LES to request that they be allowed to join the ELAN. The LES then responds to the LEC by sending the Join Response frame.

Join Request Transmitted by LESThe 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 LECThe 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 ZeroThe 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 FailureThe Expert generates the Keep Alive Sequence Failure alarm when an MPC receives a Keep Alive frame from an MPS with a request ID that did not increase from its previous value.

MPSs periodically send MPOA Keep Alive control messages to MPCs to keep the MPC-MPS flow active. Each time an MPS sends a Keep Alive message to a given station, it increases the request ID found in the message



by at least one (the first request ID sent to a given station is set to zero and increases from there).

Keep Alive Lifetime Ext Not Found in FrameThe 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 TimeoutThe 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 MismatchThe Expert generates the LANE Control Request Retry Retry Frame Mismatch alarm when a LEC resends a Control Request frame in which a



field was changed other than the Transaction ID. This is a violation of the LAN Emulation standard. The exact type of Control Request frame could be a Join Request, Register Request, Unregister Request, ARP Request, or a Verify Request.

Whenever a LEC needs to resend a Control Request frame (perhaps because there was no response from the LE Service), it must send the exact same original request frame with the exception of the Transaction ID. The Transaction ID must be different so that if the responding station does respond, the requesting station can determine to which request it is responding.

LANE Control Request Retry Rate > 1 Frame/secThe 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 ELANThe 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/SecThe 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 RefusedA LEC sends a Configure Request to the LECS in order to receive the address of the LES for an ELAN meeting its requested operating



parameters. The Expert generates the LE_CONFIGURE Params Conflict, Service Refused alarm when the LECS responds with a Configure Response frame with the Status field set to 21 (decimal), indicating a conflict in the parameters specified in the Configure Request frame. A status field set to 21 can also indicate that the LECS has denied a request for unspecified reasons.

LEC Issued Config Response to LECSThe 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 LECSDuring 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.



LEC ID in Frame Mismatch with Client LEC IDThe 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 FrameThe 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 LESThe 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 FrameThe Expert generates the Local Segment ID not in Source Routed Frame alarm when it sees a source routed frame with a route indicator (RI) field that does not contain a route descriptor (RD) matching the local ELAN’s segment ID.

Source routing is typically used in token ring (802.5) networks. Source routing use the RI field to identify each of the bridges that have forwarded a frame. As each bridge retransmits a frame, it appends its own RD to the RI field of the frame. As a result, the ultimate recipient has a record of all intermediate stations that forwarded the frame. Since LECs operate as bridges, they add their own RDs to the RI field. Frames seen on the network without an RD matching the local ELAN’s segment ID are considered invalid. They may be discarded by a LEC.



MAC Address bound to Multiple LECsThe 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 UndefinedThe 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 LinkThe 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 TLVThe Expert generates the MPOA Capable LEC Did Not Issue Device TLV alarm when it sees a LEC that has been configured as an MPOA device (either an MPC or an MPS) send one of the following message types without the Device Type TLV:

• LE_REGISTER_REQUEST



• LE_REGISTER_RESPONSE

• LE_ARP_REQUEST

• LE_ARP_RESPONSE

• 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 InvalidThe 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 TimeoutThe 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).



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/secThe 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 DetectedThe Expert generates the MPOA Error Frame Detected alarm when it detects an MPOA control frame with the ar$op.type fixed header field set to 0x88. A value of 0x88 in the ar$op.type fixed header field indicates an error.



Multiply Assigned Secondary LEC AddressThe 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 QueuedThe 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.





NARP Request Received from LESThe 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 ReplyThe 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 RequestThe 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 PurgeThe 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 ViolationThe Expert generates the PTSE Violation alarm if it detects a PNNI Topology State Element (PTSE) with an illegal Information Group (IG).



PNNI nodes exchange PNNI Topology State Packets (PTSPs) amongst themselves to distribute routing information throughout a peer group. Each PTSP packet contains multiple PNNI Topology State Elements (PTSEs), each with its own header. The PTSE header includes a PTSEType field indicating the restricted IGs which can legally appear in the PTSE (IGs are TLV used to encode PNNI information). The Expert generates this alarm if a restricted IG other than those indicated in the PTSEType field is found in a PTSE.

Register Request Multi QueuedThe Expert generates the Register Request Multi Queued alarm when aLAN Emulation entity resends a Register request with the same Transaction ID as the original Register request. This is a violation of the LAN Emulation standard.



Register Request Received from LESThe 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 LECThe Expert generates the Register Response Issued by LEC alarm when a LEC sends a Register Response frame to a LES. This is the opposite of standard operating procedure in an ELAN. Register Response frames are



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

Remote Address Issued by Non Proxy LECThe 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 ELANThe 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



TA List Resources ExhaustedThis 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 QueuedThe Expert generates the Topology Change Request Multi Queued alarm when LAN Emulation entity resends a Topology request with the same Transaction ID as the original Topology request. This is a violation of the LAN Emulation standard.



Topology Mismatch in Data Frame TypesThe 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 FrameEach MPOA control message has a set of extensions that can legally appear in a message. The Expert generates the Unexpected DLL Header EXT in Frame alarm when it sees the DLL Header extension in an MPOA control message for which it is not legal.



Unexpected Egress Cache EXT in FrameEach 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 FrameEach 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 IGThe 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 FrameEach 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 FrameEach 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.



Unexpected Service Category EXT in FrameEach 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 DetectedThe 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 FrameAny 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 IGThe 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.



Unknown LANE Config\Control OpcodeThe 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 ValuesThe 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 FrameEach 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 FrameEach 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 QueuedThe 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.





Unregister Request Received from LESThe 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 LECThe 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 ELANThe 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.



Verify Request Multi QueuedThe 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.



Verify Request Received from LESThe 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 LECThe 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.



ATM Connection Layer Alarms and ThresholdsThis 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 ErrorsThe 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 ErrorsThe 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.





AAL5 Timeout ErrorsThe 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.



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

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

• Alternatively, the Specific Disc Cause for Alarm threshold can be used to specify a disconnection cause code whose detection will cause this alarm to be generated. If the threshold is set to a positive integer, this alarm will be generated only if an SVC is disconnected with the specified cause code.

The alarm display shows you the exact disconnect cause code that caused the alarm.

Extra Cause Codes Used by the Expert

In addition to the standard disconnect cause codes, you can also use this additional Expert-specific cause code for the Specific Disc Cause for Alarm (conn level) threshold:



• 127 – A SETUP message using the same call reference number as this connection was detected without the analyzer having seen an intervening RELEASE message (or any other disconnection message) to drop the prior connection.

CLP = 1The 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.



Connection Too ShortThe Expert generates the Connection Too Short alarm if it detects an SVC whose duration was shorter than the Min Duration of session in msecs threshold in the Alarms tab of the Expert UI Object Properties dialog box. The analyzer detects short connections using the Q.2931 messages used on the signaling channel to set up and tear down connections.

Crankback Has Occurred (ATM Connection Layer)The Expert generates the Crankback Has Occurred alarm when the number of hops on which a PNNI connection has failed exceeds the Max number of crank backs threshold in the Alarms tab of the Expert UI Object Properties dialog box.

The PNNI system reacts to a failed hop by rerouting ("cranking back") the connection via a different path from the Peer Group preceding the failure. The Crankback Has Occurred alarm is call-specific at the ATM Connection layer – the crankback occurred due to a fault on one of the links or nodes on which the call has taken place.



PNNI is used to set up multi-hop connections (calls) between two ATM hosts connected to switches which are members of the same PNNI domain. PNNI domains consist of multiple peer groups – groups of switches that exchange detailed routing database information with one another through the exchange of PNNI Hello, Database Summary, and PTSE Request frames. Each peer 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.

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



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



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

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

• Max SSCOP Err/sec -- Alarm is generated if the number of SSCOP Error messages per second exceeds this threshold.

• 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 SizeThe 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 VCThe Expert generates the MPCMPS Flow Not Allowed on this VC alarm when it detects an attempt to attach an MPC-MPS flow to a VCC which already has an MPC-MPC flow on it (or vice-versa). It is illegal to multiplex both an MPC-MPC flow and an MPC-MPS flow onto the same VCC.



Possible 3.0/3.1 UNI MismatchThe 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 ProblemThe 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 SVCThe 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:



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.



ATM Host Layer Alarms and ThresholdsThis 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 DisconnectsThe 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 SequencesThe 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



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 ConnectionsThe 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 ActivityThe 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’edThe 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.



Too Many Simultaneous ConnectionsThe 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)



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.



ATM Link Layer Alarms and ThresholdsThis 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 RCCsThe 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



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.


Excessive Hello Frames DetectedThe 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 FailureThe 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 IncompatibleThe 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.



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



ATM Node Layer Alarms and ThresholdsThis 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 ViolationThe 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.



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.


Host Bound to Multiple NodesThe 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 IDThe 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).



Parent Node Association ChangeThe 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 ChangedThe 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 ChangedThe 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 TimeoutThe 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



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



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

Bad CRCThe 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 StormThe 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.



Broadcast/Multicast Storm DiagThe 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 MismatchThe 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



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 ThresholdThe 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 OverloadThe 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 PercentageThe Expert generates the LAN Overload Percentage alarm when during any one-minute interval, the percentage of time the LAN is in an overloaded state (the data rate was greater than the LAN Load threshold) exceeds the LAN Overload % threshold.



Possible causes: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 ErrorThe 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 ChangeThe 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.



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



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 OperationalThe 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 DomainVTP 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



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 DifferentThe 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 ThresholdsThis section describes Expert alarms and thresholds at the Route layer. Alarms are organized alphabetically and are described with their corresponding thresholds (if any).

Nonsense RouteThe 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 ChangedThe 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.



Route SupersededThe 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 ChangedThe 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.


ANetwork Associates Support Services A

Adding Value To Your Network Associates ProductSniffer 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 CustomersThe 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 PlanThe 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 PlanThe 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



A-2 Sniffer Pro and Sniffer Distributed

http://www.nai.com/asp_set/support/introduction/default.asp



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

The PrimeSupport Priority PlanThe 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




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

Expert Alarms Reference A-3


The PrimeSupport Enterprise PlanThe 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






• Online data file updates and product upgrades

Ordering a Corporate PrimeSupport PlanTo 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.



Table A–1. Corporate PrimeSupport Plans at a Glance

PlanFeature

Knowledge Center Plan

Connect Plan Priority Plan Enterprise Plan

Technical support via website

Yes Yes Yes Yes

Software updates

Yes Yes Yes Yes

Technical support via telephone

— Monday–Friday

North America:8 AM–8 PM CT

Europe, Middle East, Africa:9 AM-6 PM local time

Asia-Pacific: 8 AM-6 PM AEST

Latin America: 9 AM-5 PM CT

Monday–Friday, after hours emergency access





Monday–Friday, after hours emergency access





Priority call handling

— — Yes Yes

After-hours support

— — Yes Yes

Assigned support engineer

— — — Yes

Proactive support

— — — Yes

Designated contacts

— — — At least 5

Response charter

E-mail within one business day

Calls answered in 3 minutes, response in one business day

Within 1 hour for urgent issues after business hours

After hours pager: 30 minutes

Voicemail: 1 hourE-mail: 4 hours



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.

* Long distance charges may apply.

Network Associates Consulting and TrainingThe 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 ServicesNetwork 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.

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



Jumpstart ServicesFor 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 ConsultingNetwork 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




Educational ServicesNetwork 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



http://www.nai.com/services/education

Index

AAAL5 CRC Errors 1-111AAL5 Length Errors 1-111AAL5 Timeout Errors 1-112Abnormal Disconnect for SVC 1-112Abort Delimiter Transmitted 1-50AC Errors 1-50Access to Resource Denied 1-11ACK Frame Timeout 1-59Ack Too Long 1-35Address Scoping Violation 1-125Alarm

Expert thresholds 1-2Application Layer Alarms and Thresholds

1-11ARE or STE Frames on Data Direct VCC 1-81ARP Request Multi Queued 1-81Association Failure 1-59Async Status Change of Unknown DLCI 1-70ATM Application Layer Alarms and

Thresholds 1-76ATM Connection Layer Alarms and

Thresholds 1-111ATM Flow Layer Alarms and Thresholds 1-81ATM Host Layer Alarms and Thresholds

1-118ATM Link Layer Alarms and Thresholds 1-122ATM Node Layer Alarms and Thresholds

1-125Attempt to Bind DLC to MPC and Non-MPOA

Device 1-81Attempt to Bind L3 Address to Multiple

MPOA Devices 1-76Attempt to Multiply Bind MPOA Devices to

LEC 1-82

Attempt to Set Up Multiple SVCC RCCs 1-122Authentication Failure 1-60

BBackward Congestion 1-67Bad CRC 1-129Broadcast/Multicast Data Frames on DDVCC

1-82Broadcast/Multicast Storm 1-129Broadcast/Multicast Storm Diag 1-130Browser Election Force 1-11Burst Errors 1-50

CCache ID Set to Zero in DLL Header Ext 1-82CLP = 1 1-113Collision after 64 Bytes 1-50Collisions Over Threshold 1-130Config Fail, Insufficient Resources 1-82Config Frag Info TLV Not Recognized by

LECS 1-83Config Request Multi Queued 1-83Config Request Response Timeout 1-83Config Request Retry Frame Mismatch 1-84Config Request Retry Rate Exceeds 1

Frame/sec 1-84Connect Plan A-2Connection Layer Alarms and Thresholds 1-35Connection Too Short 1-113consulting services A-7contacting

Customer Service xvinternational NAI offices xviiiNAI Technical Support xv

Expert Alarms Reference Index-1

Index

Control Request on DDVCC Retry Frame Mismatch 1-84

Control Request on DDVCC Retry Rate > 1 Frame/Sec 1-85

Crankback Has Occurred 1-113, 1-122Crankback Has Occurred (ATM Node Layer)

1-125CTS Frame Timeout 1-61Customer Service xv

DData Frames Detected Following Data Plane

Purge 1-76Database Summary Exchange Lockstep

Failure 1-85Database Summary Master/Slave Negotiation

Timeout 1-85DB Connect Request Denied 1-11DB Security Breach Attempt 1-12DB Slow Connect 1-12DB Slow Server Response 1-13DB Slow Server Response Diagnosis 1-14DCE Sequence Number Error 1-70DDVCC Idle Period Exceeds VCC Timeout

C12 1-76DDVCC Not Created in Response to LE ARP

1-77Deauthentication 1-61Default MCFVCC Not Created in Response to

LE ARP 1-77Default MCSVCC Not Created in Response to

LE ARP 1-77Delayed STATUS ENQUIRY 1-70Denied Access to ELAN 1-86Diagnosis in Expert analysis 1-1Disassociation 1-62DLC Layer Alarms and Thresholds 1-50DLC Source Address Broadcast 1-50DLC Source Address Multicast 1-51

DLL Header Extension Not Found in Frame 1-86

DTE Sequence Number Error 1-71Duplicate Address Found 1-51Duplicate ATM Destination Address

Registration 1-86Duplicate LAN Destination Registration 1-86Duplicate Network Address 1-40Duplicate PDC Name Registration 1-41

Eeducational services, description of A-9EFCI 1-114Egress Cache Tag Was Not Issued 1-87Enterprise Plan A-4Exceeded CIR 1-67Excessive Abnormal Disconnects 1-118Excessive Abnormal Frame Sequences 1-118Excessive Failed Domain Logins 1-15Excessive Failed Resource Login Attempts

1-15Excessive Hello Frames Detected 1-123Excessive Mailslot Broadcasts 1-16Excessive Short Connections 1-119Excessive Signaling Recovery 1-114Excessive Unknown Frames Issued by LEC

1-78Expert

diagnoses 1-1symptoms 1-1thresholds 1-2

FFailed to Issue Resolution Req. Following

Trigger 1-87Failure Reported in Reply CIE 1-87Fast Retransmission 1-35FCI and ARI Bits Mismatch 1-52File Retransmission 1-23

Index-2 Expert Alarms Reference

Index

Flush Request Multi Queued 1-87Forward Congestion 1-67Frame Has Alignment Problem 1-52Frame-Copied Errors 1-52Frames Seen on Default Flow After Shortcut

Active 1-78Frequency Errors 1-52FTP Login Attempts 1-16FTP Slow Connect 1-16FTP Slow First Response 1-17FTP Slow Response 1-17FTP Slow Transfer Diagnosis 1-17

GGlobal Layer Alarms and Thresholds 1-129

HHigh Rate of Line/Burst Errors 1-52High Rate of Physical Errors 1-53High Rate of Receiver Congestion Errors 1-53High Rate of Ring Purge Diagnosis 1-54High Signaling Activity 1-119Host Address Cannot Be Mux’ed 1-119Host Bound to Multiple Nodes 1-126HTTP Slow Server GET Response Time 1-17HTTP Slow Server POST Response Time 1-18

IICMP Destination Unreachable 1-41ICMP Host Unreachable 1-41ICMP Inconsistent Subnet Mask 1-42ICMP Net Unreachable 1-42ICMP Parameter Problem 1-42ICMP Port Unreachable 1-42ICMP Redirect for Host 1-43ICMP Redirect for Network 1-43ICMP Source Quench 1-44

Idle Too Long 1-36IG Tag Violation 1-88Insufficient Info from LEC, Service Refused

1-88Invalid ATM Primary Address 1-88Invalid CIE Contents 1-89Invalid Client ATM Primary Source Address

1-89Invalid Client MAC Address 1-89Invalid Common Header Contents 1-89Invalid Fixed Header Contents 1-90Invalid Frame Contents 1-90Invalid Frame Status Field 1-54Invalid Hello Frame 1-91Invalid MPOA Packet Size 1-92Invalid Network Name 1-18Invalid Port ID 1-126Invalid Presentation Context ID 1-23Invalid Resource User Name or Password 1-18Invalid Tag in Data Frame Header 1-92IP Fragment Missing 1-44IP Fragment Out of Order 1-44IP NETBIOS Session Reject 1-23Irregular Full Status Report Requests 1-71

JJoin Request Multi Queued 1-92Join Request Received from LES 1-92Join Request Transmitted by LES 1-93Join Response Issued by LEC 1-93

KKeep Alive Lifetime Ext Not Found in Frame

1-94Keep Alive Lifetime Set to Zero 1-93Keep Alive Sequence Failure 1-93KnowledgeCenter A-1


Index

LLAN Overload 1-131LAN Overload Percentage 1-131LANE Cfg Phase Failure 1-78LANE Cfg Restart Delay 1-79LANE Cfg Restart Delay > Max Recfg Delay

1-79LANE Control Request Response Timeout

1-94LANE Control Request Retry Rate > 1

Frame/sec 1-95LANE Control Request Retry Retry Frame

Mismatch 1-94LANE Version Unsupported by ELAN 1-95LE ARP Request Rate Exceeds 1 Frame/Sec

1-95LE_CONFIGURE Params Conflict, Service

Refused 1-95LEC ID in Frame Mismatch with Client LEC

ID 1-97LEC Issued Config Response to LECS 1-96LEC Not Recognized by LECS 1-96LECID Is Not 0x0000 in Request Frame 1-97LECS Issued Config Request to LES 1-97Line Errors 1-54Link Inactivity Failure 1-123Link Management Message Format Error 1-71Link Management Message Minor Format

Error 1-72Local Limit on Defined Context Set Exceeded

1-23Local Routing 1-36Local Segment ID not in Source Routed Frame

1-97Local Station with Route Designator 1-54Loops on Same Request 1-23Lost Frame Errors 1-55Low Throughput 1-24

MMAC Address bound to Multiple LECs 1-98Max Transmission Unit Size Undefined 1-98Misdirected Frame 1-45Missed Browser Announcement 1-19Missing DTL or Excessive DTL Size 1-115Missing Fragment Number 1-63Missing ULIA on Outside Link 1-98MPCMPS Flow Not Allowed on this VC 1-115

MPOA Capable LEC Did Not Issue Device TLV 1-98

MPOA Config Parameter Invalid 1-99MPOA Control Request Response Timeout

1-99MPOA Control Request Retry Rate > 1

Frame/sec 1-100MPOA Error Frame Detected 1-100MS RAP Logon Failure 1-19Multicast/Broadcast Fragmentation 1-62Multiple Local Ring Definition 1-55Multiple Routers to Local 1-45Multiple Routers to Remote 1-46Multiply Assigned Secondary LEC Address

1-101

NNAI Technical Support, contacting xvNARP Request Multi Queued 1-101NARP Request Received from LES 1-102NCP Server Busy 1-20Network Associates

consulting services A-7educational services A-9international offices xviiiSniffer University A-7

Network Equipment Reset 1-72New Active Monitor 1-55New PVC Configured 1-73


Index

NFS Retransmission 1-20NNTP Slow Response Time 1-20No CIEs Were Present in MPOA Reply 1-102No CIEs Were Present in MPOA Request 1-102No Reply Flag Is Not Set in ICache Purge 1-102No Resolution Request Issued After Excess

Default Flow 1-80No STATUS ENQUIRY When Expected 1-73No STATUS following STATUS ENQUIRY

1-73Non-Responsive Station 1-36Nonsense Route 1-135

Oordering PrimeSupport plans A-5Oversized Frame 1-55Oversized WLAN Frame 1-64

PParent Node Association Change 1-127Peer Group ID Has Changed 1-127Peer Group Leader Has Changed 1-127PLCP Error 1-132POP3 Slow Connect Time 1-21Possible 3.0/3.1 UNI Mismatch 1-116Prime Support A-6Priority Plan A-3product training

see Sniffer UniversityProfessional Consulting Services A-7Protocol Negotiation Failure 1-21Protocol Version Support Incompatible 1-123PRSE Request Timeout 1-128PTSE Acknowledge Timeout 1-127PTSE Violation 1-102PVC Activation 1-67, 1-73PVC Bandwidth Change 1-68, 1-73PVC Congestion 1-68, 1-74

PVC Deactivation 1-68, 1-74PVC Deletion 1-68, 1-74

RRead/Write Overlap 1-25Reassociation Failure 1-64Receiver Congestion Errors 1-55Register Request Multi Queued 1-103Register Request Received from LES 1-103Register Response Issued by LEC 1-103

Remote Address Issued by Non Proxy LEC 1-104

Repeat Ack 1-37Request Denied 1-25Request Params Are Incompatible with ELAN

1-104Restricted Branching Violation 1-128Retransmission 1-37Returned to Ring 1-56Ring Beaconing 1-56Ring Purge Symptom 1-56Rogue Access Point 1-64Route Flapping 1-46Route Layer Alarms and Thresholds 1-135Route Metric Changed 1-135Route Superseded 1-136Route Validity Changed 1-136Router Not Updating Routes 1-46Router Storm 1-47Router Superseded Too Frequently 1-47Routing Frames Detected on Outside Link

1-124Runt Frame 1-57Runt WLAN Frame 1-65

SSame Source and Destination Address 1-57Same Transmitter and Receiver Address 1-65


Index

SAP R3 Slow Server Connection 1-21SAP R3 Slow Server Response 1-21SCCP - Register Reject alarm 1-23Server Running BDC Shutting Down 1-47Server Running PDC Shutting Down 1-48Server Running WINS Shutting Down 1-48Service Layer Alarms and Thresholds 1-5Session Layer Alarms and Thresholds 1-23Shortcut Create Failed After Resolution Reply

1-80Signaling Frame Sequence Problem 1-116Slow File Transfer 1-26Slow FTP Server 1-5Slow HTTP Server 1-5Slow Mail Server 1-6Slow News Server 1-6Slow Oracle SQL Server 1-6Slow POP3 Server 1-8Slow Server 1-37Slow Sybase/Microsoft SQL Server 1-9Slow Telnet Server 1-10SMTP Slow Connect Time 1-22Sniffer University xvi, A-7Source Address Is Broadcast 1-48Spanning Tree Topology Change 1-132Station Internal Errors 1-57Station Not in Domain’s Computer List 1-22Station Off Ring 1-57Station Removed 1-57SVCC RCC Dropped 1-124Symptom in Expert analysis 1-1

TTA List Resources Exhausted 1-105Technical Support xvTelnet Slow Response to Login 1-22Temporary Congestion 1-26

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 Server Did Not Support the Requested Authentication Level 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 Requested Interface 1-27

The Server Does Not Support the RPC Protocol Version 1-27

The Server Is Too Busy To Handle the Call 1-28The Server Manager Routine Has Not Been

Entered and Executed 1-28Thresholds

Expert 1-2Time-to-live Exceeded in Transmit 1-49Time-to-live Expiring 1-49TNS Connect Refused 1-28TNS Security Breach Attempt 1-28TNS Slow Connect 1-28TNS Slow Server Diagnosis 1-29TNS Slow Server Response 1-30Token Errors 1-58Too Many File Retransmissions 1-32Too Many Loops on Same Request 1-32Too Many Removes 1-58Too Many Requests Denied 1-33Too Many Retransmissions 1-38Too Many Returns 1-58Too Many Simultaneous Connections 1-120


Index

Topology Change Request Multi Queued 1-105

Topology Mismatch in Data Frame Types 1-105

Total Education Services A-7Traffic on Deleted DLCI 1-69Traffic on Inactive DLCI 1-69Traffic on Unknown DLCI 1-69training

see Sniffer UniversityTransmitter Address Broadcast 1-66Transmitter Address Multicast 1-66

UUDP Bouncing Frames 1-38Unexpected Data for SVC 1-116Unexpected Data for SVC (ATM Host Layer)

1-120Unexpected DLL Header EXT in Frame 1-105Unexpected Egress Cache EXT in Frame 1-106Unexpected Hop Count EXT in Frame 1-106Unexpected Keepalive Lifetime EXT in Frame

1-106Unexpected Link Management Message 1-74Unexpected Original Error Code EXT in

Frame 1-106Unexpected Service Category EXT in Frame

1-107Unexpected TLVs Detected 1-107Unknown Extension in Frame 1-107Unknown IG 1-107Unknown LANE ConfigControl Opcode 1-108Unknown Marker/Protocol Values 1-108Unknown/Unexpected Authenticate EXT in

Frame 1-108Unknown/Unexpected CIE in Frame 1-108Unregister Request Multi Queued 1-108Unregister Request Received from LES 1-109Unregister Response Issued by LEC 1-109

Unsolicited STATUS Message 1-75User Equipment Reset 1-75

VV2 TLVs Issued in V1 ELAN 1-109Verify Request Multi Queued 1-110Verify Request Received from LES 1-110Verify Response Issued by LEC 1-110VLAN Not Operational 1-134VLAN Removed from Domain 1-134

VTP Versions Different 1-135

WWAN Connection Layer Alarms and

Thresholds 1-67WAN Link Layer Alarms and Thresholds 1-70WEP-ICV Error 1-66Window Frozen 1-39Window Size Exceeded 1-39WINS Duplicate Name 1-33WINS No Response 1-34Wrong Report Type in STATUS Message 1-75

ZZero Broadcast Address 1-49Zero Window Too Long 1-39


Index


Sniffer Pro and Sniffer Distributed Referenceread.pudn.com/downloads118/ebook/499714/教程...Table...

Documents

Transcript of Sniffer Pro and Sniffer Distributed Referenceread.pudn.com/downloads118/ebook/499714/教程...Table...