How to Manage Your Network with SPECTRUM. Document 1909

Transcription

1 How to Manage Your Network with

2 Notice This documentation (the "Documentation") and related computer software program (the "Software") (hereinafter collectively referred to as the "Product") is for the end user's informational purposes only and is subject to change or withdrawal by CA at any time. This Product may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Product is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties. Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for their own internal use, and may make one copy of the Software as reasonably required for back-up and disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the Software are permitted to have access to such copies. The right to print copies of the Documentation and to make a copy of the Software is limited to the period during which the license for the Product remains in full force and effect. Should the license terminate for any reason, it shall be the user's responsibility to certify in writing to CA that all copies and partial copies of the Product have been returned to CA or destroyed. EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS PRODUCT "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS PRODUCT, INCLUDING WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE. The use of this Product and any product referenced in the Documentation is governed by the end user's applicable license agreement. The manufacturer of this Product is CA. This Product is provided with "Restricted Rights." Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections , , and (c)(1) - (2) and DFARS Section (c)(1)(ii), as applicable, or their successors. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies. Copyright 2006 CA. All rights reserved.

3 Contents Preface... 9 Intended Audience... 9 Text Conventions... 9 Document Feedback...10 Online Documents...10 Introduction Core and Network Management...12 Additional Network Management...12 Your Network Model Before You Begin...13 Optimizing Your Network Model...14 Understanding Your Network Model...14 Port Connection Representation...16 Completing Your Network Model...17 Generating an Inventory Report of Your Modeled Devices...18 Comparing the Inventory Report to Your Inventory List...21 Modeling Devices Manually...22 Customizing Interface Model Names...22 Resolving Port Connections...24 Discovering Connections in Container Models...27 Locked Connections...27 Rearranging Your Network Model...28 Adjusting Management Capacity...32 The LogPollAnalyzer Utility...33 Staggering Polling Intervals...35 Disabling Polling for a Model or a Model Type...37 Polling Devices that are Down...38 Customizing Your Network Model...39 Using the Annotation Toolbox...39 Page 3

4 Using the Change Background Option...40 Using Organizational Views...43 Creating a Network Model that Shows the Business Impact of Services on Administrative Structure...44 Creating a Network Model that Shows Administrative Responsibilities...46 Maintaining Your Network Model...48 Adding and Removing Device Models...49 To add a device model to your network model:...49 To remove a device model from your network model:...50 Saving and Restoring the Database...50 Creating a Backup...50 Restoring a Database...51 Scheduling Backups...51 Configuring for Fault Management Setting Thresholds...53 Alarm Thresholds...54 Rollup Condition Thresholds and Significance Levels...54 Configuring Traps...55 Creating New Traps...56 Checking Devices for Trap Configuration...56 Configuring Alarms...56 Clearing Old Alarms Automatically...56 Alarm Policies for Specific Interfaces...57 Alarm Management on DLCI Ports...58 False Management Lost or Contact Lost Alarms...59 Using SpectroWATCH...60 Configuring for Fault Isolation...61 Configuring General Fault Isolation Parameters...61 Configuring Management Neighbors...64 Configuring Maintenance Mode...68 Maintenance Mode for Devices...68 Maintenance Mode for Ports...69 Page 4

5 Configuring Cross-Landscape Fault Correlation...70 Cross-Landscape Fault Correlation Example...71 Configuring Port Fault Correlation...72 Port Fault Correlation Options...72 Port Fault Correlation Criteria...73 Port Fault Correlation Caveats...74 Port Fault Correlation Examples...74 Known Port Fault Correlation Anomalies...80 Configuring Port Status Monitoring...80 Port Status Polling Criteria...82 Port Status Events and Alarms...83 Link Trap Handling...83 Interface Trap Configuration View...85 PollPortStatus Feature...86 Wide Area Link Monitoring...87 Link Fault Disposition...88 Wide Area Link Monitoring Scenarios...89 Port Layer Alarm Suppression...90 Port Criticality...90 Live Pipes...91 Enabling or Disabling Live Pipes System-Wide...91 Enabling or Disabling Live Pipes on Individual Links...91 Receiving Port Alarms...92 Automatic Port Status Alarm Clearing...93 Suggested Port Fault Settings for Optimal Fault Notification...94 Other Fault Management View Settings...94 Device Model Settings...94 Port Model Settings...95 Configuring Fault Management for Pingables...95 Connecting Two Pingable Models...96 Connecting a Pingable Model to a Device s Port Model...96 Fault Management Page 5

6 Fault Isolation Overview...97 Fault Detection Device Condition Colors Blue (Initial) Green (Normal) Yellow (Minor Alarm) Orange (Major Alarm) Red (Lost Contact) Gray (Unknown) Rollup Condition Colors How Is a Rollup Condition Detected? Fault Isolation Enterprise Alarm Manager Accessing the Enterprise Alarm Manager Using the Enterprise Alarm Manager Audible Alarms Isolating a Fault Through Navigation Point and Click Navigate In Chassis Device View Accessing the Chassis Device View Device Topology View Accessing the Device Topology View Using the Device Topology View Performance View Accessing the Performance View Using the Performance View Beyond the Performance View Intelligence Static Configuration of Device Models Dynamic Configuration of Device Models The Pulled Board List Page 6

7 Router Reconfiguration Events Condition vs. Rollup Condition Attributes Determining Condition and Rollup Condition Condition and Rollup Condition Sensitivity Rollup Condition Flow Example of Rollup Condition Propagation Organization Models Fault Isolation How Model Category Affects Contact Status Examples Duplicate Addresses Automatic Naming and Addressing in Monitor Points Monitor Point Statistics Composite Monitor Point Statistics Discrete Monitor Point Statistics Monitor Point Calculations in SpectroWATCH Detection of Firmware Problems Device Threshold Events Redundancy Redundant SpectroSERVERs (Fault Tolerance) Redundant Paths Configuring Device Redundancy Editing the Redundancy Preferred Addresses list Device Redundancy Events Alternate Path Repeater Management Device Lost and Found Device Type Verification Device Type Mismatch In-Band Configuration of Device Alarms Interface Intelligence Interface Alarms Interface Events Page 7

8 Index Page 8

9 Preface In This Section Intended Audience [page 9] Text Conventions [page 9] Document Feedback [page 10] Online Documents [page 10] Intended Audience This guide is intended for system administrators who are using to manage their networks. Text Conventions The following text conventions are used in this document: Element Convention Used Example Variables (The user supplies a value for the variable.) The directory where you installed (The user supplies a value for the variable.) Courier and Italic in angle brackets (<>) <$SPECROOT> Type the following: DISPLAY=<workstation name>:0.0 export display Navigate to: <$SPECROOT>/app-defaults Solaris and Windows directory paths Unless otherwise noted, directory paths are common to both operating systems, with the exception that slashes (/) should be used in Solaris paths, and backslashes (\) should be used in Windows paths. <$SPECROOT>/app-defaults on Solaris is equivalent to <$SPECROOT>\app-defaults on Windows. On-screen text Courier The following line displays: path= /audit User-typed text Courier Type the following path name: C:\ABC\lib\db Page 9

10 Element Convention Used Example Cross-references References to documents (title and number) Underlined and hypertextblue Italic See Document Feedback [page 10]. OneClick Console User Guide (5130) Document Feedback Please send feedback regarding documents to the following address: Thank you for helping us improve our documentation. Online Documents documents are available online at: Check this site for the latest updates and additions. Page 10

11 Introduction is a powerful and flexible network management software program that provides a network administrator with effective and reliable network management tools. Reliable network management has become a necessity to maintain a competitive edge in today s market place. s diversity of features and functionality can seem intimidating to an administrator just beginning to use the product. Not only does the core* product provide a wide variety of features and functionality, but an additional array of separately purchasable Aprisma or third-party add-on components offers the means for further customizing or extending. Given these extensive management capabilities, the need for a book describing the use of these network management tools has become increasingly important. This document is an attempt to address the need for a how to approach in using to effectively manage a network. The focus will be on the management features included with the core product and how to use them. * Core product refers to those components included in the basic package. Page 11

12 Core and Network Management Using to successfully manage your network involves reducing network downtime, improving network performance, and maintaining a clear and up-to-date model of your network. functionality allows you to optimize your network model, supports proactive fault management and fault isolation, and provides network performance enhancement capabilities. The flexibility of allows an administrator to: Customize the network model to optimize ease-of-use, performance, and fault management. Keep the network model up-to-date as devices or subnets are added or removed. Identify and isolate network faults down to a port level. Additional Network Management Ethernet IEEE is the network management standard that is used in the management examples described in this document. Additional separately purchasable network management products provide management of other networking standards. Some of these products are: Frame Relay Manager ATM Circuit Manager VLAN Fault Isolation Non-Persistent Connections Manager RMON Contact Aprisma for more information about these products. Page 12

13 Your Network Model This section describes how to refine an auto discovered network model to improve management capabilities. In This Section Before You Begin [page 13] Optimizing Your Network Model [page 14] Customizing Your Network Model [page 39] Maintaining Your Network Model [page 48] Before You Begin In order to properly model your network and facilitate the management techniques described in this document, it is important that the following prerequisites are met: Your network design meets all established Ethernet specifications (as outlined by the IEEE group). You have an accurate network diagram mapping the physical placement of your devices, nodes, and cable. (This network diagram and list will be used to verify that Autodiscovery has modeled all the devices and properly resolved all port connections.) You have an inventory list of all the devices in your network. Your network has been auto discovered initially to allow to identify and communicate with all the devices on your network. When AutoDiscovery is run, may not be able to identify devices that are temporarily off the network or not allowing management communication. Completing your network model will require some subsequent manual modeling. Page 13

14 Optimizing Your Network Model Once your network has been auto discovered, you may want to perform the tasks described in this section to complete your network model as well as optimize management capabilities. Understanding Your Network Model s network representation is based on logical relationships and rules and may not look exactly like your network diagram. AutoDiscovery uses address tables and ICMP pings to identify subnet address ranges and devices within those ranges. Once discovered, those devices and subnets are modeled by. Figure 1 and Figure 2 illustrate the relationship between the actual devices, the network diagram, and s network model. These figures show how your network is represented by. Page 14

15 Figure 1: Your Actual Network Router WanLink IPClassBLAN EMM-E6 EMM-E6 LAN Fanout A LAN Your Actual Network Page 15

16 Figure 2: Representation of Your Network SpectroGRAPH: Topology: LAN SpectroGRAPH: Topology: Universe File View Tools Bookmarks Help File View Tools Bookmarks Help EMM-E6 VNM LAN_802_3 LAN_802_3 EMM-E LAN_802_3 LAN_802_3 SpectroGRAPH: Topology: File View Tools Bookmarks SpectroGRAPH: Topology: File View Tools Bookmarks Workstation Workstation Workstation Workstation Bridge CSIRptr Workstation Bridge CSiRptr Workstation CSI Repeater CSIRepeater Workstation Workstation Fanout A Port Connection Representation represents port level connections between devices in the Device Topology views. The Device Topology view shows you the devices that are connected to each port for the selected device. Figure 3 provides an example of a Device Topology view for the EMM-E6 device. Page 16

17 Figure 3: Device Topology View for the EMME/EMM-E6 SpectroGRAPH: Device Topology: EMM_E6 File View Tools Bookmarks Help M I M I M I M F u n k n o F O R M I M E M M l E 6 BRtrCSIEMM-E6 LAN LAN LAN Network A Network B Network C CSIRptr CSIRptr CSIRptr 1 FWD 2 FWD 3 FWD ETHERNET ETHERNET ETHERNET A:BC A:BC A:BC If does not understand which port a device is connected to, the device model will appear in the Off-Page Reference panel. AutoDiscovery should correctly place all of these connections; if it does not, you will need to refer to Resolving Port Connections [page 24] to resolve the connections and allow to properly monitor the device. Completing Your Network Model When AutoDiscovery is initially run, may not be able to identify devices that are temporarily off the network or not allowing management Page 17

18 communication. Although you may have run AutoDiscovery twice during a 48-hour period as recommended, some devices may not have been identified by. To identify and properly locate any undiscovered devices or unresolved port connections, you must analyze your network diagram. The process of completing your network entails the following: Generating an Inventory Report of Your Modeled Devices [page 18] Comparing the Inventory Report to Your Inventory List [page 21] Modeling Devices Manually [page 22] Resolving Port Connections [page 24] Generating an Inventory Report of Your Modeled Devices Devices that were not contacted during the Autodiscovery process need to be identified and discovered individually or within a range. To determine what devices have been modeled, generate an Inventory Report as follows: 1. Select Reports then Generate from the Tools menu. The Report Generator view will appear Figure 4. Figure 4: Report Generator View Report Generator File Applications Help Report Type Alarm Statistical Inventory Event Up/Down Time Landscapes... Report Format... banshee Models Event Filters Output File... Date Range Day Post Generate Script Site Name Report Depth General Graphical Output Format Tabular Display (.GRF) ASCII (.TAB) Postscript (.ps) GIF (.gif) pace/spectrum/report.config/default.rptrc pace/spectrum/report.config/default.rptrc Postscript (.ps) Page 18

19 2. In the Report Type panel of the Report Generator view, select Inventory. 3. Select ASCII (.TAB) under Tabular for the output format. 4. If applicable, deselect any Graphical selections. 5. To select the models to be included in the inventory list, click on the Model Types button to open the Model Selection dialog box (Figure 5). Figure 5: Model Selection Dialog Box SRG: Model Types Scope: Under Landscape Under Model Landscapes Model Types catapult 2E253_49R 2E253_49R_Mdul 2E42_27 2E42_27_Module 2E43_47 2E43_47_Module 2E43_51 2E43_51_Module 2E48_27 2E48_27_Module 2E49_27 2E49_27_Module 2E50_28 2E50_28_Module Select All Deselect All Case Sensitive Search OK Cancel 6. For the purpose of identifying undiscovered devices, highlight your landscape in the left-hand panel, and click on Select All at the bottom of the right-hand panel to include all models within that landscape. 7. Click OK. SpectroGRAPH displays the Report Generator view. 8. Select Detailed using the Report Depth button. 9. Click the Report Format button to open the SRG:Report Format dialog box (Figure 6). Page 19

20 Figure 6: Report Format Dialog Box Srg: Report Format Filter Spectrum/sg-support/csrib/*.rib* Directories Files.. 3comgenbdgapp 3omnetbld 3comnetbld2 3comsrcrteapp Atmifport Atm_network Selection Ace/spectrum/sg-support/csrib/* Ok Filter Cancel 10. Select Invt_Det.rib as the format under Files. This report information block file, located in the <$SPECROOT>/SG -Support/ CsRib/Inventory directory, provides a standard format for a detailed inventory report. (You can customize these reports with the Format option. See the Report Generator User s Guide (0881).) 11. Click OK. SpectroGRAPH displays the Report Generator view. 12. Click the Output File button to open the SRG:Output File dialog box. 13. Select an output file directory (the default directory is report.output). Enter an output file name in the Selections field and click OK. 14. Select Generate from the File menu of the Report Generator view. 15. Click OK in the Report Generation Invoked information box. 16. Another information box displays when the report process has completed successfully. Click OK. 17. Print the file located in the <$SPECROOT>output.report/<your file name.tab>. Page 20

21 Figure 7 provides an example of an inventory report. Date: 06/10/96 8:52:00 LandscapeID: 0x User Name: arlo_admin Site Name: Headquarters Figure 7: Example Inventory Report Network Inventory Report Page: 1 Model Type Model Name IP Address MAC Address Create Date Contact Last Contacted Vendor Object ID BdgCSINB30 Bridge # D.3.4A.74 06/09/94 ESTB 06/10/94 08: GnSNMPDev tutor B.8B.56 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # D 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # /09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # AC 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # CC.AA.BB 06/09/94 LOST 06/10/94 08: GnSNMPDev Workstation # B /09/94 ESTB 06/10/94 08: IPClassB Automapped LAN - 06/09/94 ESTB Undefined - LAN Automapped LAN - 06/09/94 ESTB Undefined - LAN_802_3 Automapped LAN - 06/09/94 ESTB Undefined - Hub_CSI_IRM3 Hub # D.1B /09/94 ESTB 08/20/93 08: Hub_CSI_IRM3 Hub # D A 06/09/94 ESTB 06/10/94 08: Hub_CSI_MRXi Hub # D.B.8B.56 06/09/94 ESTB 06/10/94 08: Pingable PsPrinter # /09/94 ESTB 06/10/94 08: Rtr_Cisco Router # C /09/94 ESTB 06/10/94 08: WS_SGI Workstation # B.8B.56 06/09/94 ESTB 06/10/94 08: WS_SGI Workstation # B.8B.56 06/09/94 ESTB 06/10/94 08: Comparing the Inventory Report to Your Inventory List The Inventory Report lists all models that have been discovered. This includes LANs, applications, and device models. Compare this list to your inventory list to determine if any devices within your network were not discovered. The applications that are listed in the report are not represented in a Topology view. For the purpose of completing your network, the applications are not needed for the comparison process. However, you may need the inventory of application models if you wish to ensure they will be polled by (see the Note on [page 37]). Note the IP address or range of any missing device(s). This information will be used in Modeling Devices Manually [page 22] to discover additional devices if necessary. If the initial Inventory Report contains LANs or Fanout models, you may have to run inventory reports for each LAN or fanout to determine which models are contained within them. The inventory report provides the information shown in Figure 8. Page 21

22 The unique name of the device or LAN. Figure 8: Using the Inventory Report The IP address for that device or LAN. Date: 06/10/96 8:52:00 LandscapeID: 0x User Name: arlo_admin Site Name: Headquarters Network Inventory Report Page: 1 Model Type Model Name IP Address MAC Address Create Date Contact Last Contacted Vendor Object ID BdgCSINB30 Bridge # D.3.4A.74 06/09/94 ESTB 06/10/94 08: GnSNMPDev tutor B.8B.56 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # D 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # /09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # AC 06/09/94 ESTB 06/10/94 08: GnSNMPDev Workstation # CC.AA.BB 06/09/94 LOST 06/10/94 08: GnSNMPDev Workstation # B /09/94 ESTB 06/10/94 08: The Model Type Name for that device or LAN. Modeling Devices Manually If you have identified any devices that need to be modeled to complete your network model, they should be modeled manually. The following are examples of devices that require some manual modeling to complete your network: MMAC-Plus and its associated modules FDM Module ForeRunner ATM Switch Module Refer to the specific management module guide for modeling instructions. Customizing Interface Model Names Note: All changes to the interface naming suffix configuration are done at the device model level rather than at the interface model level. By default, when an interface is modeled, its model name is created using both the device model name and the interface s value for ifindex as a suffix. For example, a device model named might contain interface models named _1, _2, and so on. Page 22

23 Using the Interface Model Name Suffix option available in the Device tab of s Global Attribute Editor for a given device model, you can select the attribute value to be used as an interface model name suffix. The following attributes can be chosen as suffixes: ifindex, ifdescr, ifalias, or ifname. These alternative interface model naming schemes can provide valuable information about a given interface. For example, some devices store board and port information in the value of ifname, which can be useful to have on hand when viewing an interface alarm in an alarm console. Configuration of the Interface Model Name Suffix option can be done either on a device model by device model basis, or by device model type. For example, you may want to set all Enterasys device model types to use ifdescr for an interface naming suffix, but for Rtr_Cisco device model types, you may want to set one subset of models to use ifname and another subset to use ifalias (see Example: Configuring Interface Model Name Suffix [page 23]). This will depend on what the particular device settings for these attributes are in your network environment. In Search Manager, the interface name suffix can be set for a device model or models by selecting the model(s) from Search Manager search results and choosing Management > Set Attribute Values... and setting the Interface Model Name Suffix option on the Device tab. Note: Selecting Management > Rename Interface Models in Search Manager recalculates interface model names. This only needs to be used to update when new values for interface suffix attributes have been set on the device. For more information, see the Search Manager User s Guide (2383). Example: Configuring Interface Model Name Suffix Follow these steps to configure the Interface Model Name Suffix option for two subsets of Rtr_Cisco device models, setting one subset to ifname and the other subset to ifalias: 1. In Search Manager, search for and select the subset of Rtr_Cisco device models you want to set to have interface models named with a suffix of ifname. 2. Choose Management > Set Attribute Values Select the Device tab in the Global Attribute Editor and set the Interface Model Name Suffix option to ifname. Page 23

24 4. Click Apply to name this subset with a suffix of ifname. 5. Click Close in the Operation Results dialog box and the Global Attribute Editor window. 6. In Search Manager, search for and select the subset of Rtr_Cisco device models you want to set to have interface models named with a suffix of ifalias. 7. Choose Management > Set Attribute Values Select the Device tab in the Global Attribute Editor and set the Interface Model Name Suffix option to ifalias. 9. Click Apply to name this subset with a suffix of ifalias. 10. Click Close in the Operation Results dialog box and the Global Attribute Editor window. Resolving Port Connections AutoDiscovery automatically identifies and resolves port connections between devices. It may be necessary to resolve some port connections manually to allow to properly manage all devices on your network. To resolve port connections the following must be done: Systematically go through all the Device Topology views to determine if you have any unresolved port connections. Resolve each unresolved port connection. The Device Topology View The Device Topology view represents a device in terms of its ports and port connections. You can use the Device Topology view to: Examine existing connections to a device. Make new connections to other devices. Navigate to other views via the icons displayed in the Device Topology view. Access other views (Performance, Application, etc.) through the Device Icon panel and the menu. Select which board s ports are shown in the Connections Panel for a multi-slot device, such as a hub (Figure 9). Page 24

25 Resolve any undefined device connections represented by Off-Page Reference icons shown in the Unresolved Off-Page Reference Icon Panel. Add, copy, erase, cut, paste, and destroy icons. You can access the Device Topology view using one of the following methods: Highlight the icon and select DevTop from the Icon Subviews menu. Double-click on the Device Topology down arrow on the icon. Place the mouse pointer over the icon, click and hold the right mouse button and select DevTop from the pop-up Icon Subviews menu. Figure 9 provides an example of a Device Topology view. Figure 9: Example Device Topology View SpectroGRAPH: Device Topolog File View Tools Bookmarks Unresolved Off-Page Reference Icon Network Icon that contains the device connected to this port Icons for models that are connected to a specific port LAN LAN Network A Network B N Port Connections CSIRptr CSIRptr Interface Icons 1 FWD 2 FWD ETHERNET ETHERNET A:BC A:BC 0 0 Page 25

26 Using the Device Topology View to Identify and Resolve Port Connections The Device Topology view indicates unresolved port connections between devices as Off-Page Reference icons in the Off-Page Reference Panel. Resolve the port connections as follows: 1. Open the Device Topology view for the device. If no Off-Page Reference icons appear in the Off-Page Reference Panel, continue to the next device. 2. If an Off-Page Reference icon appears for the device, use your network map to verify the physical connections between devices to ensure proper port connections. 3. Select File > Edit in the Device Topology view. 4. Highlight the Off-Page Reference icon (Figure 10) and drag it to the proper port. You may have to scroll the Port Connections Panel to view all the port connections. Release the mouse button when the icon is placed over the correct port. Figure 10: Resolving a Port Connection SpectroGRAPH : Device Topology : File View Tools Bookmarks Help Highlight C A Y M A N C R M 2 R E 1 0 B T I M I M R I M I M C M I M - EMM-E6 E M M - E Drag Release A ON B OFF C OFF D ETHERNET ETHERNET ETHERNET ETHE 0:0:1D:19:AC:52 0:0:1D:19:AC:53 0:0:1D:19:AC:54 0:0:1D: :0:0:0 0:0:0:0 0:0:0: Page 26

27 5. Repeat step 4 for each Off-Page Reference icon in this view. 6. Choose File > Close Edit to exit edit mode. 7. Repeat step 2 through step 6 for each device with unresolved port connections. Discovering Connections in Container Models The Discover LANs functionality uses the parameters you have chosen in the AutoDiscovery Model Information view to discover and map the connections within the selected container model. See the Distributed SpectroSERVER (2770) guide for complete information on these parameters and their impact on how the connections will be modeled. Note: When you run this discovery, maps connections for both layer 2 and layer 3 devices. To access the Container Discover Connections view, highlight the Container and choose Discover Connections from the Edit > Icon Subviews menu. Figure 11: Container Discover Connections View Locked Connections Any ports used in device connections that are manually resolved have their LockConnection attribute (0x000129f1) set to 1, the locked state. This is Page 27

28 true of any manually configured connection, whether it is created by copying and pasting in a Topology view, through the CLI, or using the method described in the preceding procedure. The locked state preserves manually configured connections when AutoDiscovery is subsequently run on the devices. will not remove such connections. All connections resolved by AutoDiscovery will have the LockConnection attribute set to 0, the unlocked state. Note: Links modeled in earlier versions of (whether by AutoDiscovery or manual configuration) and migrated into 7.0 and later during the upgrade process will also be locked by default. The network administrator may have a need to change this link setting in, which effectively changes the state of the LockConnection attribute on the ports at either end of the link. To lock or unlock a connection: 1. Select the link in the Topology view, then choose View > Lock Connection... to open the Connection Lockdown dialog box. 2. In the Connection Lockdown dialog box, set the toggle button to the desired position and click OK. raised button is unlocked recessed button is locked Rearranging Your Network Model allows you to group devices at any level to reduce the complexity of your Topology views. This is done by creating container models, such as LAN, Fanout, Network, FDDI, etc., and placing groups of modeled devices within them. intelligence functions, such as rollup conditions, still apply and enable you to effectively manage those devices. In the following example, a LAN_802_3 Topology view displays a hub and its connected workstations, as shown in Figure 12. We will create a Fanout icon to represent the devices at the LAN_802_3 Topology level, then cut Page 28

29 and paste the workstation icons into the Fanout model. The procedure below can be used for all container models. Figure 12: Example Network Topology View SpectroGRAPH : Primary Landscape File View Tools Bookmarks Help Router #1 Hub # 2 Hub_CSI_IRM3 1. Review your network and identify groups of devices that could logically be placed in a group model. Note the Hub and connected workstations in this example. 2. Select Edit from the File menu of the LAN_802_3 Topology view. 3. Select New Model... from the Edit menu. 4. Select Fanout from the Select Model Type dialog box and click OK. 5. Enter the name of the Fanout (TechPubs in Figure 13) and click OK in the Creation dialog box. 6. Select Close Edit from the File menu to exit Edit mode. 7. Open the Fanout Cablewalk view by double-clicking on the down arrow shown in Figure 13. Page 29

30 Figure 13: Creating a Fanout Model SpectroGRAPH : Primary Landscape File View Tools Bookmarks Help Router #1 Hub # 2 Hub_CSI_IRM3 TechPubs Down arrow 8. Select Edit from the File menu for the Fanout Cablewalk view (Figure 14) and for the LAN_802_3 Topology view (Figure 12). Figure 14: Fanout Cablewalk SpectroGRAPH : Cable Walk : Fanout File View Tools Bookmarks Help TechPubs 9. In the LAN_802_3 Topology view, hold down the shift key and use the mouse pointer to highlight each workstation icon connected to the hub (Figure 15). Page 30

31 Figure 15: Selecting the Models to be Grouped SpectroGRAPH : Primary Landscape File View Tools Bookmarks Help Router #1 Hub # 2 Hub_CSI_IRM3 TechPubs 10. Select Cut from the Edit menu in the LAN_802_3 Topology view. 11. Click OK in the Confirm dialog box. 12. Select Paste from the Edit menu in the Fanout Cablewalk view. 13. Select Close Edit from the File menu in the Fanout Cablewalk view and LAN_802_3 Topology views. These two views will appear as shown in Figure 16. Page 31

32 Figure 16: New Grouped Views SpectroGRAPH : SpectroGRAPH : Cable Walk : Fanout File View Tools Bookmarks Help File View Tools Bookmarks Help TechPubs Router #1 Hub # 2 Hub_CSI_IRM3 TechPubs Adjusting Management Capacity polls devices at regular intervals to access the management information that s intelligence uses to perform fault isolation. However, this polling activity consumes considerable bandwidth and host system resources. A key part of optimizing your network model is to selectively adjust this trade-off between bandwidth use and management capacity so that resources are deployed where they are needed most. provides two main ways of doing this: Staggering Polling Intervals [page 35] Disabling Polling for a Model or a Model Type [page 37] Before you implement one of these methods, you may want to assess how polling is currently configured for models in your database. The The LogPollAnalyzer Utility [page 33] can provide you with this information. Page 32

33 The LogPollAnalyzer Utility The LogPollAnalyzer utility displays information on the attributes being logged or polled by models in the database. Results are broken down by model type. The utility is located in the <$SPECROOT>/SS-Tools directory and can be run from this directory on the command line using the following syntax. LogPollAnalyzer -l <landscape handle> -c -i Where: -l <landscape handle>: Specifies the landscape that you want the LogPollAnalyzer to report on. This is a required parameter. -c: specifies that models will not be listed under the same entry unless they log and poll the same attributes. This only affects models that log and poll. This is an optional parameter. -i: specifies that models will not be listed under the same entry unless their logging and polling intervals match. Note that the logging and polling intervals will not be displayed at all unless this parameter is specified. This is an optional parameter. The -c and the -i parameters can be used at the same time. Sample Output The following sample shows output generated without using the -c or -i parameter. 1 models of type 2H22_08R (0x1c80014) are polling the following attributes: conttypephysicalchanges (0x2309c9) conttypelogicalchanges (0x2309ca) ifnumber (0x100c3) sysuptime (0x10245) 431 models of type SSR_PortIf (0x2c60006) are logging the following attributes: Load (0x220042) Packet_Rate (0x220093) Contact_Status (0x10004) Error_Rate (0x220054) Discard_Rate (0x220055) Page 33

34 1 models of type 2H252_25R (0x1c8001e) are logging the following attributes: Load (0x10019) PacketRate (0x1001a) SoftErrorRate (0x1001b) Contact_Status (0x10004) HardErrorCount (0x1001c) 1 models of type 2H252_25R (0x1c8001e) are polling the following attributes: conttypephysicalchanges (0x2309c9) conttypelogicalchanges (0x2309ca) ifnumber (0x100c3) sysuptime (0x10245) 1 models of type JnprRedundRtr (0x3b1000e) are logging the following attributes: Contact_Status (0x10004) 1 models of type JnprRedundRtr (0x3b1000e) are polling the following attributes: ifnumber (0x100c3) ifstacklastchange (0x11f7c) iftablelastchange (0x11f7d) 3 models of type 8H02_16 (0x1c80007) are polling the following attributes: conttypephysicalchanges (0x2309c9) conttypelogicalchanges (0x2309ca) ifnumber (0x100c3) sysuptime (0x10245) 1 models of type Dialer_IF_Port (0x22002f) are logging the following attributes: Load (0x220042) Packet_Rate (0x220093) Contact_Status (0x10004) Error_Rate (0x220054) Discard_Rate (0x220055) Page 34

35 Staggering Polling Intervals Most device models are polled every 60 seconds by default. You can change the default polling interval for an individual device model or for all models of particular model type. But keep in mind the above-mentioned trade-off between bandwidth use and management capacity, which applies as follows: If you increase the time between polls, you will use less bandwidth for management traffic, but you will receive device status updates less frequently. If you decrease the time between polls, you will have more frequent updates of device status. However, you will use more bandwidth for management traffic. One way to achieve both goals (i.e., reduce network management traffic and enhance fault management) is to stagger polling intervals as shown in Figure 17. If all the devices in this example were using the default polling interval of 60 seconds, they would all be using bandwidth every 60 seconds. However, by leaving the polling interval for the router at the default of 60 seconds and changing the polling interval of all the other devices to 600 seconds, the SpectroSERVER resource utilization is reduced. Moreover, you will not lose management capabilities because if anything happens to the devices downstream from the router, polling will be interrupted and an alarm will be generated. Figure 17: Staggering Polling Intervals Polling Interval=60 Router WanLink Polling Intervals=600 Polling Interval=600 Polling Interval=600 Page 35

36 How To Change the Polling Interval You can change the polling interval for any device by entering a new value in the Poll Interval field in the device model s Model Information view (be sure to select File > Save All Changes after you enter the new value). or You can also use a Command Line Interface (CLI) script called update_mtype to change the polling interval either for a specific model or for all models of a specific model type. The script requires you to supply three arguments: the model type name, the polling interval attribute ID (which is 0x10071), and the polling interval value in seconds. To run this script, do the following: 1. Navigate to the following location in your top-level directory: /vnmsh/sample_scripts 2. Enter the following command:./update_mtype <model type name> 0x10071 <new polling interval in seconds> For example, to set the polling interval to 600 seconds for one or more models of type Host_Sun, you would enter:./update_mtype Host_Sun 0x This will display a list of all models of the specified type, showing for each one the model handle, the model name, the model type handle, and the model type name, as in the following example: 0x workstation1 0x60000 Host_Sun 0x workstation2 0x60000 Host_Sun 0x workstation3 0x60000 Host_Sun 3. To apply the new polling interval to a specific model in the list, enter the model handle (e.g., 0x100001) or the model name (e.g., workstation1). To apply the new polling interval to all models of the specified type, enter the model type handle (e.g., 0x60000) or the model type name (e.g., Host_Sun). 4. The system will indicate success or failure and disconnect you from CLI. Page 36

37 Note: Polling intervals also apply to application models, many of which have an initial setting of zero, which in effect disables polling (although the preferred method for disabling polling for any model is to set the Polling Status attribute to FALSE as explained in Disabling Polling for a Model or a Model Type [page 37]). You can reset the polling interval for application models using the same methods described above for device models. Indeed, it is recommended that you check your inventory report (see Generating an Inventory Report of Your Modeled Devices [page 18]) for application models and run the update_mtype script on each global application model type to set a polling interval of 60 seconds. Disabling Polling for a Model or a Model Type In addition to the strategy of increasing default polling intervals for selected models to conserve bandwidth, you may decide that the status of certain devices is not worth the bandwidth that polling them requires, even at longer intervals. For example, some network administrators may choose not to model endpoint devices such as workstations so that they do not have to deal with the alarms that occur each time these devices are powered down. If you wish to have the endpoints modeled, but do not wish to expend bandwidth with network polling traffic, you can disable polling to these models (or to any models) by changing the value of the Polling Status attribute to FALSE as described below. How To Change the Polling Status You can change the polling status for any model by toggling the Polling Status selector button in the model s Model Information view (be sure to select File > Save All Changes after you change the setting). You can also use the Command Line Interface (CLI) script called update_mtype to change the polling status either for a specific model or for all models of a specific model type. The script requires you to supply three arguments: the model type name, the polling status attribute ID (which is 0x1154f), and the polling status value (TRUE or FALSE). To run this script, do the following: 1. Navigate to the following location in your top-level directory: /vnmsh/sample_scripts 2. Enter the following command: Page 37

38 update_mtype <model type name> 0x1154f <new polling status value> For example, to disable polling for one or more models of type Host_Sun, enter: update_mtype Host_Sun 0x1154f false. This will display a list of all models of the specified type, showing for each one the model handle, the model name, the model type handle, and the model type name, as in the following example: 0x workstation1 0x60000 Host_Sun 0x workstation2 0x60000 Host_Sun 0x workstation3 0x60000 Host_Sun 3. To apply the new polling status setting to a specific model in the list, enter the model handle (e.g., 0x100001) or the model name (e.g., workstation1). To apply the new polling interval to all models of the specified type, enter the model type handle (e.g., 0x60000) or the model type name (e.g., Host_Sun). 4. The system will indicate success or failure and disconnect you from CLI. Note: The Polling Status value takes precedence over the Polling Interval value in terms of enabling/disabling various periodic external requests to a model. Even though setting the Polling Interval to zero will automatically change the Polling Status to FALSE, if you then reset the Polling Status to TRUE, requests generated by inference handlers could still occur, regardless of the fact that the Polling Interval is still set to zero. However, to enable normal polling for fault isolation purposes, the Polling Interval would have to be manually reset to a non-zero value. Polling Devices that are Down When contact with a device has been lost, will continue to poll the device to see if the contact status has changed. By default, will poll devices that are down once every third polling interval. For Page 38

39 example, if the device s polling interval is set to 60 seconds, when the device is down, will poll the device once every 180 seconds. To change the interval at which will poll a device that is down, you can insert the following syntax into the <$SPECROOT>/SS/.vnmrc file: down_device_poll_interval_multiplier=<user_defined_multiplier> For example, if the <user_defined_multiplier>=2 and the device s polling interval is 60 seconds, then the down device will be polled once every 120 seconds (2*60=120). Customizing Your Network Model provides network model customization tools that enable you to enhance your management capabilities. The Annotation Toolbox provides a set of graphic and text tools that you can use to annotate your views. For example, you could use the Annotation Toolbox to label certain devices in a view. The Change Background feature lets you adjust the background color and window size for views, or custom select an image to be used as the background. Organizational and Location Views allow you to copy device models into views that help you administer your network from a location or administrative responsibility perspective, for ease of management. Using the Annotation Toolbox The Annotation toolbox gives you access to a color palette and drawing tools (line, circle, box, and text). There are also a variety of options for changing fonts, line width, and colors. The Annotation Options window is described in more detail in Annotation Toolbox (2520). Figure 18 provides an example of how you might annotate a Topology view to help understand s representation of your network. Page 39

40 Figure 18: Annotation of a Topology View SpectroGRAPH: Topology File View Tools Bookmarks Help Wiring Closet 45-2nd EMM-E LAN_802_3 Technical Documentation Building 45 2nd LAN_802_3 Manufacturing Building 45 1st LAN_802_3 Using the Change Background Option This option allows you to change background color or select a background image for views, and to set the maximum size of the window for the current GIB View. The Background Color button accesses the Select Color Index palette, from which you can select an appropriate color for your background. The Background Raster button opens the Select File dialog box, from which you can choose a background raster image file. The image you select becomes the background for the view. The window size will change to accommodate the size of the raster image you select. Page 40

41 Figure 19: Change Background Dialog Box Change Background Background Min Width = Width = Min Height = Height 757 Screen Width = 1258 Screen Height = 985 Background Raster OK Cancel Help To change the Background Color 1. While looking at a view in edit mode, choose Edit > Change Background to open the Change Background dialog box (Figure 19). 2. Enter the desired window dimensions, in pixels, into the Height and Width fields of the Change Background dialog box. These entries define the maximum window size; you cannot resize the window beyond the selected size dimensions. 3. If you know the index number for the desired background color from the color palette, you can enter the index number directly into the Background Color field. Otherwise, click on the Background Color button to open the Select Color Index dialog box (Figure 20). displays color index numbers 77 through 255 within the individual color blocks of the Color Palette. (Only these colors are used by.) 4. Select a color, then click OK. Click OK again in the Change Background dialog box to see the change take effect. Page 41

42 Figure 20: Select Color Index Dialog Box Select Color Index Color Palette with Associated Index Numbers Click the left mouse button on the desired color and click OK to apply a color to the view. or Double-click on any color in the palette to select that color and close the palette dialog box. Selected Color: 247 OK Cancel To change the background image 1. While looking at a view in edit mode, choose Edit > Change Background to open the Change Background dialog box. 2. Click the Background Raster button to open the Select File dialog box (Figure 21). Figure 21: Select File Dialog Box Select File Filter /space/spectrum/sg-support/csimage/background/* Directories /Spectrum/SG-Support/CsImage/Background/. /Spectrum/SG-Support/CsImage/Background/. Selection /space/spectrum/sg-support/csimage/background/ Files Bd_Genbd1.csi Bd_Genbd2.csi Bd_Genbd3.csi Bk_DkBlue.csi Bk_Oat.csi Bk_LtOat.csi Bk_MdBlue.csi Default.csi OK Filter Cancel Help Page 42