Non-Persistent Connections Manager

Transcription

1

2 Notice Copyright Notice Copyright present by Aprisma Management Technologies, Inc. All rights reserved worldwide. Use, duplication, or disclosure by the United States government is subject to the restrictions set forth in DFARS (c)(1)(ii) and FAR Liability Disclaimer Aprisma Management Technologies, Inc. ( Aprisma ) reserves the right to make changes in specifications and other information contained in this document without prior notice. In all cases, the reader should contact Aprisma to inquire if any changes have been made. The hardware, firmware, or software described in this manual is subject to change without notice. IN NO EVENT SHALL APRISMA, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, OR AFFILIATES BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION CONTAINED IN IT, EVEN IF APRISMA HAS BEEN ADVISED OF, HAS KNOWN, OR SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES. Trademark, Service Mark, and Logo Information SPECTRUM, IMT, and the SPECTRUM IMT/VNM logo are registered trademarks of Aprisma Management Technologies, Inc., or its affiliates. APRISMA, APRISMA MANAGEMENT TECHNOLOGIES, the APRISMA MANAGEMENT TECHNOLOGIES logo, MANAGE WHAT MATTERS, DCM, VNM, SpectroGRAPH, SpectroSERVER, Inductive Modeling Technology, Device Communications Manager, SPECTRUM Security Manager, and Virtual Network Machine are unregistered trademarks of Aprisma Management Technologies, Inc., or its affiliates. For a complete list of Aprisma trademarks, service marks, and trade names, go to: All referenced trademarks, service marks, and trade names identified in this document, whether registered or unregistered, are the intellectual property of their respective owners. No rights are granted by Aprisma Management Technologies, Inc., to use such marks, whether by implication, estoppel, or otherwise. If you have comments or concerns about trademark or copyright references, please send an to spectrum-docs@aprisma.com; we will do our best to help. Restricted Rights Notice (Applicable to licenses to the United States government only.) This software and/or user documentation is/are provided with RESTRICTED AND LIMITED RIGHTS. Use, duplication, or disclosure by the government is subject to restrictions as set forth in FAR (June 1987) Alternate III(g)(3) (June 1987), FAR (June 1987), or DFARS (c)(1)(ii) (June 1988), and/or in similar or successor clauses in the FAR or DFARS, or in the DOD or NASA FAR Supplement, as applicable. Contractor/manufacturer is Aprisma Management Technologies, Inc. In the event the government seeks to obtain the software pursuant to standard commercial practice, this software agreement, instead of the noted regulatory clauses, shall control the terms of the government's license. Virus Disclaimer Aprisma makes no representations or warranties to the effect that the licensed software is virus-free. Aprisma has tested its software with current virus-checking technologies. However, because no antivirus system is 100-percent effective, we strongly recommend that you write protect the licensed software and verify (with an antivirus system with which you have confidence) that the licensed software, prior to installation, is virus-free. Contact Information Aprisma Management Technologies, Inc., 273 Corporate Drive, Portsmouth, NH USA Phone: U.S. toll-free: Web site: Page 2

3 Contents Notice... 2 Preface... 5 Intended Audience... 5 Text Conventions... 5 Document Feedback... 6 Online Documents... 6 Introduction... 7 Creating Dialup_Link Models... 8 Types of Links Supported... 8 Dial Backup Link (DBL)... 8 Bandwidth on Demand Link (BODL)... 8 Primary on Demand Link (PODL)... 9 Model Creation... 9 Configuring A Connection Overview...12 Dial Backup Links and Bandwidth on Demand Links...13 Primary on Demand Links...13 Configuring Secondary Interfaces on the Remote Router...13 Configuring Primary Interfaces on the Remote Router...14 Configuring Secondary Interfaces on the Host Router...15 Viewing the Dialup_Link in the Topology View...16 DDR Configurations that are Dialer Map-Based Overview...17 Modeling the Connection...17 Creating Dialup_Link Models...17 Configuring the Connection...18 Page 3

4 DDR Map-Based Connections with Multilink Secondary Interfaces on a Remote Router Overview...19 Modeling the Connection...21 DDR Configurations that use Dialer Profiles Overview...22 Representing a Dialer Interface with SPECTRUM...23 Modeling the Connection...23 Creating Dialup_Link Models...23 Configuring the Connection...24 Monitoring the Connection...24 Multiple Dial Backup Links Overview...26 Multiple Remote Routers to a Common Host Router...27 Single Remote Router to Multiple Host Routers or Host Router Interfaces...28 Monitoring Connections Dialup_Link Information View...32 The Active NPC Summary View...32 Connected Devices View...35 Determining the Status of Multiple Primary or Secondary Links...36 Dialup_Link Condition Color...36 Alarm Configuration View...38 Alarms...40 Index Page 4

5 Preface In This Section Intended Audience [page 5] Text Conventions [page 5] Document Feedback [page 6] Online Documents [page 6] Intended Audience This guide is intended for system administrators who are using SPECTRUM to monitor non-persistent connections. 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 SPECTRUM (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 5

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

7 Introduction This section provides an overview of SPECTRUM s Non- Persistent and describes the types of links it allows you to manage. SPECTRUM s allows you to manage transient communications links. These non-persistent connections generally remain in an inactive state and are activated only under certain conditions. They can be activated manually as needed to serve as normal dialup type communications links, or they can be configured to activate automatically in either of the following two scenarios: To serve as a backup when failure of a primary connection occurs. To provide load balancing or extra bandwidth for another overloaded communications link. The gives you quick access to three key pieces of information, namely: When a link is activated. Whether a link has failed to activate. How long a particular link has been active. Events and alarm conditions are generated and logged to maintain accurate link usage statistics. There is also a graphical representation (icon) of the link so that you can differentiate between normal connections and non-persistent connections and determine a connection s current status by merely looking at it. The Dialup_Link model type provides this important functionality. The following chapters discuss how to create Dialup_Link models to represent non-persistent connections, how to configure these models, and how to monitor them for information about the non-persistent connection. Instructions are given for various Dial on Demand Routing (DDR) configurations as well as multiple dial backup link configurations. Page 7

8 Creating Dialup_Link Models This section explains how to create a Dialup_Link model to represent a non-persistent connection. In This Section Types of Links Supported [page 8] Model Creation [page 9] Types of Links Supported The Dialup_Link model type provides functionality for three distinct types of non-persistent connections: Dial Backup Link (DBL) Bandwidth on Demand Link (BODL) Primary on Demand Link (PODL) When you create a Dialup_Link model, you will choose the type of connection that best suits your needs. Dial Backup Link (DBL) A Dial Backup Link (DBL) provides a redundant link if a primary link fails. Not only does this type of link provide monitoring support for a one-to-one relationship between primary and secondary links, it also provides support for multiple primary and secondary link configurations. Each DBL model can provide monitoring capabilities for multiple primary links using a common secondary interface. This feature is useful when many remote sites use one phone number at a central site (common interface) to support a non-persistent connection. Bandwidth on Demand Link (BODL) A Bandwidth on Demand Link (BODL) provides extra bandwidth for connections experiencing congestion problems. Links of this type may or may not be active in conjunction with the primary link. BODLs provide the same redundant capabilities as Dial Backup Links. Page 8

9 Primary on Demand Link (PODL) The Primary on Demand Link (PODL) is not a redundant connection of any type. These links are activated manually when needed and function as a primary connection. There is no primary-secondary relationship involved. Model Creation You should create one Dialup_Link model for each phone number that the remote router(s) could dial to create the non-persistent connection. If the remote router(s) can dial one number that can be picked up by one of several host routers or host router interfaces, one Dial_Up link model is used to represent this connection. The Dialup_Link model must be created manually. To create a Dialup_Link model from within a SPECTRUM Topology view, follow the instructions below. 1. Select File > Edit > New Model to display the Select Model Type dialog box. 2. In the Select Model Type dialog, select the Dialup_Link model type and click OK to display the Dialup_Link Creation View (Figure 1). 3. In the Dialup_Link Creation View, enter or adjust the following values/settings: a. Model Name: The name of the Dialup_Link model (1 to 16 ASCII characters). b. Security String: Assign a SPECTRUM Security String to the Dialup_Link model. (Refer to Security and User Maintenance(2602) for details on setting up security in SPECTRUM.) c. Dialup Type: The functional type of the Dialup_Link. Possible types are Backup (DBL), Primary (PODL), and Bandwidth (BODL). (Refer to Types of Links Supported [page 8]). d. Dialup Protocol Type: The protocol type that will be used on the Dialup_Link. Possible protocol types are: Analog, Switch_56, ISDN, and Frame Relay. Page 9

10 Figure 1: The Dialup_Link Creation View e. Activation Grace Period (Minutes): This field allows you to specify the time allowed, in minutes, for the secondary link to become active after a primary link failure. If this grace period expires before the secondary link is active, then a red alarm is generated. This field is only used by DBL-type link models. The default setting is 3 minutes. The value for this field can also be specified when in the Alarm Configuration view (see Alarm Configuration View [page 38]). f. Deactivation Grace Period (Minutes): This field allows you to specify the time allowed, in minutes, for an active secondary link to deactivate after the failed primary link reactivates. If the secondary link is still active after this grace period expires, then a yellow alarm is generated. This field is only used by DBL-type link models. The default setting is 3 minutes.the value for this field can also be specified when in the Alarm Configuration view (see Alarm Configuration View [page 38]). g. Active Time Until Yellow (Hours): This field allows you to specify the number of hours a backup link can be active before a Page 10

11 yellow alarm is generated. The value for this field can also be specified when in the Alarm Configuration view (see Alarm Configuration View [page 38]). h. Active Time Until Orange (Hours): This field allows you to specify the number of hours a backup link can be active before an orange alarm is generated. The value for this field can also be specified when in the Alarm Configuration view (see Alarm Configuration View [page 38]). i. Active Time Until Red (Hours): This field allows you to specify the number of hours a backup link can be active before a red alarm is generated. The value for this field can also be specified when in the Alarm Configuration view (see Alarm Configuration View [page 38]). 4. After the Creation view is completed, click OK. This will cause a Dialup_Link model to appear in the Topology view. When first created, the model will be in a normal inactive state and will have a brown condition. Figure 2: Dialup _Link Model Model Name Protocol Type Page 11

12 Configuring A Connection This section provides the information necessary to configure a basic non-persistent connection once you have created the Dialup_Link model as described in the previous section. In This Section Overview [page 12] Dial Backup Links and Bandwidth on Demand Links [page 13] Primary on Demand Links [page 13] Configuring Secondary Interfaces on the Remote Router [page 13] Configuring Primary Interfaces on the Remote Router [page 14] Configuring Secondary Interfaces on the Host Router [page 15] Viewing the Dialup_Link in the Topology View [page 16] Overview Configuring non-persistent connections involves designating primary and secondary interfaces on a remote router and a host router. Remote routers initiate dialup links. Host routers answer dialup calls from remote routers to establish the link. Management information is obtained by monitoring the remote router. There are a few different configurations that can be used to model the nonpersistent connections on your network. The steps in this chapter are designed to give you an overview of the configuration process and form the basis of the technology specific configurations that are discussed in the following chapters: DDR Configurations that are Dialer Map-Based [page 17] DDR Map-Based Connections with Multilink Secondary Interfaces on a Remote Router [page 19] DDR Configurations that use Dialer Profiles [page 22] Multiple Dial Backup Links [page 26] Page 12

13 Dial Backup Links and Bandwidth on Demand Links Dial Backup Links (DBLs) and Bandwidth on Demand Links (BODLs) involve the redundant relationship between a primary link and a secondary link. The Dialup_Link model representing a DBL or a BODL monitors a primary link for a possible failure; it also monitors a related secondary link to verify its activation in a backup or supporting role if the primary link fails. In general, the following three tasks are required to configure these types of links. As described below, the secondary interface must be configured before the primary interface. 1. Configure the secondary interface. This is the interface on the remote router that will serve as the dialing end of the dialup connection. 2. Configure the primary interface on the remote router. This is the interface that serves as the connection to the primary link and is monitored by the Dialup_Link model. If this interface goes down, the dialup connection is used. 3. Configure the connection on the host router that will serve as the receiving end of the dialup connection. Primary on Demand Links Primary on Demand Links (PODLs) are non-persistent connections that are used as transient primary links. You configure these links using the same procedure described above; however, since this type of link model does not need to monitor a primary interface, you can skip step 2. Configuring Secondary Interfaces on the Remote Router When configuring the non-persistent connection, the first task is the configuration of a fixed secondary interface on the remote router. Doing this resolves the Dialup_Link model to the secondary interface in the Device Topology view. This must be done manually as described below, since there is no information within any MIB that would denote a specific interface or link as acting in a redundant or secondary capacity. 1. Select File > Edit. 2. Highlight the Dialup_Link model that needs to be resolved. Page 13

14 3. Select Edit > Copy. 4. Select File > Close Edit. 5. Navigate into the Device Topology view of the remote router where you want to configure a secondary interface. 6. Select File > Edit. 7. Select Edit > Paste. 8. Drag the Dialup_Link icon onto the correct secondary interface model. 9. Select File > Close Edit to exit Edit mode. Configuring Primary Interfaces on the Remote Router After you configure the secondary interface on the remote router, you must configure the primary interface on the remote router. (This step is not necessary for Primary on Demand Links). When you configure a primary interface, you associate the secondary link to the primary link(s) it is supporting. This is done in the Primary Interface Configuration view. You access the Primary Interface Configuration view by highlighting the Dialup_Link model and selecting Primary Interface Configuration from the Icon Subviews menu. Figure 3: The Primary Interface Configuration View Page 14

15 The Primary Interface Configuration view features two lists: The Complete Interface List includes all of the interfaces on all of the devices associated with the Dialup_Link model. For this basic configuration scenario, this is all of the interfaces on the remote router where the secondary interface has been configured. The Primary Interface List includes all currently configured Primary Interfaces for this Dialup_Link model. To configure a primary interface, do the following: 1. From the Complete Interface List, select the primary connection s remote router interface. 2. Click the Add Interfaces button. The newly configured Primary Interface will now appear in the Primary Interface List. Note: If more than one primary interface on a single remote router is selected through the Primary Interface Configuration view, these interfaces will be treated as a group. The status of the group of primary interfaces is determined by the healthiest group member. The backup interface will activate only if all of the primary interfaces in the group fail. Configuring Secondary Interfaces on the Host Router The final task is the configuration of a secondary interface on the host router. To do this, you must resolve the Dialup_Link model to the secondary interface in the Device Topology view of the host router. As with the interfaces on the remote router, this must be done manually as described below. 1. Select File > Edit. 2. Highlight the Dialup_Link model that needs to be resolved. 3. Select Edit > Copy. 4. Select File > Close Edit. 5. Navigate into Device Topology view of the remote router where you want to configure a secondary interface. Page 15

16 6. Select File > Edit. 7. Select Edit > Paste. 8. Drag the Dialup_Link icon onto the correct secondary interface model. 9. Select File > Close Edit to exit Edit mode. Viewing the Dialup_Link in the Topology View Once you have configured the Dialup_Link model connections and specified the interface on the remote router for the primary connection, the Dialup_Link model is fully integrated into the current modeling scheme and will react according to the type of link it represents. The Topology view containing the Dialup_Link model will show live pipes connecting the Dialup_Link model to the remote and host routers. The live pipes will have a brown condition when the dialup link is inactive. If the modeled primary link and secondary links involve the same two devices, the topology configuration involving the host and remote routers should look similar to Figure 4. Figure 4: The Modeled Connection Primary Link Dialup_Link Model Fixed Secondary (Backup) Link Page 16

17 DDR Configurations that are Dialer Map-Based This section discusses modeling a non-persistent connection that uses a DDR configuration that is mapbased. In This Section Modeling the Connection [page 17] Modeling the Connection [page 17] Overview A DDR configuration that is map-based (often referred to as a legacy DDR configuration) associates a call specification for a single destination and a particular physical interface configuration. The physical interface contains all of the configuration information that relates to receiving or making calls, and the bearer channels inherit the physical interface s configuration. Modeling the Connection To model a DDR configuration that is map-based, create the appropriate number of Dialup_Link models and then configure the connection for each Dialup_Link model. These processes are detailed below. Creating Dialup_Link Models Create one Dialup_Link model for each phone number that the remote router(s) could dial to create the non-persistent connection. For instructions on creating a Dialup_Link model, see Creating Dialup_Link Models [page 8]. If the remote router(s) can dial one number that can be picked up by one of several host routers or host router interfaces, one Dial_Up link model is used to represent this connection. Page 17

18 Configuring the Connection To configure Dialup_Link model connection: 1. Configure the secondary interface on the remote router that will serve as the dialing end of the dialup connection. a. Select File > Edit. b. Highlight the Dialup_Link model that needs to be resolved. c. Select Edit > Copy. d. Select File > Close Edit. e. Navigate into the Device Topology view of the remote router. Find the physical interface that will be making the call, and drill down through as many subinterface layers of the bearer channel interface as possible. Often the bearer channel interface will have an encapsulation layer interface (for example, an iftype PPP interface). Drill to this encapsulation layer interface if it is available. If it is not available, drill down to the interface that represents the bearer channel (for example, an iftype DSO interface). f. Select File > Edit. g. Select Edit > Paste. h. Drag the Dialup_Link icon onto the interface. i. Select File > Close Edit to exit Edit mode. 2. Configure the primary interface on the remote router. For instructions on how to do this, see Configuring Primary Interfaces on the Remote Router [page 14]. 3. Configure a secondary interface on the host router. To do this, follow the procedure outlined in step 1 above, using the host router model instead of the remote router model. Page 18

19 DDR Map-Based Connections with Multilink Secondary Interfaces on a Remote Router This section discusses modeling a non-persistent connection that uses one Dialup_Link model to specify a secondary link consisting of multiple interfaces that make up one logical link. This secondary link can be initiated by one or more ports on the remote router. In This Section Overview [page 19] Modeling the Connection [page 21] Overview It is possible to use one Dialup_Link model to support multiple secondary interfaces on a single remote router. For example, if your dialup connection uses a Multilink PPP over ISDN BRI configuration, you could associate a single Dialup_Link model with each of the PPP interfaces associated with the ISDN bearer channel connections. The Figure 5 shows a remote router that has two connections to a host router. Since these two connections make up one logical link, you can use one Dialup_Link model to represent the link. Depending on the type of connectivity you are using, you can resolve the Dialup_Link model at the interface or the subinterface level. Page 19

20 Figure 5: Multilink Secondary Interfaces on a Remote Router Host Router 1 1 Device B Remote Router Device A Connectivity resolved at the interface level. Host Router 1 1 Device B Remote Router Device A 2 2 Connectivity resolved at the subinterface level. Primary Interfaces Secondary Interfaces Page 20

21 Modeling the Connection There are three main tasks involved in creating this configuration. Each of these tasks is described below and references step-by-step instructions given in the previous chapter. 1. The first task is to configure the secondary interfaces on the remote router. This involves resolving the Dialup_Link model to the secondary interfaces in the Device Topology view. For instructions, see Configuring Secondary Interfaces on the Remote Router [page 13]. Repeat this process using the same Dialup_Link model for each secondary interface on the device. Secondary Groups When a Dialup_Link model is associated with more than one interface on the same device, these interfaces will form a secondary group. SPECTRUM determines the status of the connection by looking at the state of the group. The DevSecGrpActiveCriteria attribute allows you to change how SPECTRUM determines the state of the secondary group. This attribute has a default value of AnySecondaryIFActive (0). This means that the group will be active if any member of the group is up; and dormant only if all members of the group are down. The other possible value for this attribute is AllSecondaryIfsActive (1). If this is the value, the secondary group will only be considered active if all members of the group are up, and will be considered inactive if one member goes down. You can change the value of this attribute in the Alarm Configuration View [page 38]. 2. The next task is to configure a primary interface. When you configure a primary interface, you associate the secondary link to the primary link(s) it is supporting. This is done in the Primary Interface Configuration view. For instructions, see Configuring Primary Interfaces on the Remote Router [page 14]. 3. The final task is the configuration of the secondary interfaces on the host router. This involves resolving the Dialup_Link model to the secondary interfaces in the Device Topology view of the host router. For instructions, see Configuring Secondary Interfaces on the Host Router [page 15]. Page 21

22 DDR Configurations that use Dialer Profiles This section discusses modeling a non-persistent connection that uses a DDR configuration with Dialer Profiles. In This Section Overview [page 22] Representing a Dialer Interface with SPECTRUM [page 23] Modeling the Connection [page 23] Monitoring the Connection [page 24] Overview In DDR Configurations that are dialer-map based, each physical interface can only have one set of configuration characteristics. When using a DDR configuration with dialer profiles, physical interfaces take on different characteristics based on incoming or outgoing call requirements. This is possible because dialer profiles separate logical configurations from the physical interfaces that receive or make calls. This allows interfaces such as ISDN, asynchronous modems, or synchronous serial connections to be shared by multiple dialer profile configurations. The logical and physical interfaces are associated dynamically on a per call basis. A dialer profile is made up of three main components: Dialer Interface: Logical interfaces that represent a call to a particular destination. The dialer interface configuration contains all configuration settings specific to the destination. A router can have one or more dialer interfaces. Each interface references a group of physical interfaces called a dialer pool. Dialer Pool: A group of physical interfaces that are associated with a dialer profile. A physical interface can belong to multiple dialer pools. Physical Interface: Each physical interface is able to determine the dialer pool(s) to which it belongs. Interfaces in a dialer pool are configured for encapsulation parameters and each dialer profile supports PPP and HDLC encapsulation. Page 22

23 Representing a Dialer Interface with SPECTRUM SPECTRUM uses a logical interface model to represent a dialer interface. This means that the logical interface model represents a call to or from a particular destination. This model is automatically created when SPECTRUM discovers a DDR dialer profile configuration on a device. For example, if SPECTRUM discovered a dialer profile configuration on a Cisco router, the following logical interface model would be used to represent a dialer interface. If there are multiple dialer interfaces configured on the router, multiple logical interfaces are created. Modeling the Connection To model a connection that makes use of dialer profiles, create the appropriate number of Dialup_Link models and then configure the connection for each Dialup_Link model. It is possible for dialer profiles to be used on the remote router, on the host router, or on both routers. Creating Dialup_Link Models Create one Dialup_Link model for each phone number that the remote router(s) could dial to create the non-persistent connection. This means that you would create one Dialup_Link model for each logical interface model representing a dialer interface on the remote router. For instructions on creating a Dialup_Link model, see Creating Dialup_Link Models [page 8]. If the remote router(s) can dial one number that can be picked up by one of several host routers or host router interfaces, one Dial_Up link model is used to represent this connection. Page 23

24 Configuring the Connection To configure Dialup_Link model connection: 1. Configure the secondary interface on the remote router that will serve as the dialing end of the dialup connection. a. Select File > Edit. b. Highlight the Dialup_Link model that needs to be resolved. c. Select Edit > Copy. d. Select File > Close Edit. e. Navigate into the Device Topology view of the remote router where you want to configure a secondary interface. f. Select File > Edit. g. Select Edit > Paste. h. If you are making use of a dialer profile on the remote router, drag the Dialup_Link icon onto the logical interface model representing the dialer. i. If you are not using a dialer profile, on the remote router, drag the Dailup_Link icon onto the interface model that represents the dialing interface. j. Select File > Close Edit to exit Edit mode. 2. Configure the primary interface on the remote router. For instructions on how to do this, see Configuring Primary Interfaces on the Remote Router [page 14]. 3. Configure a secondary interface on the host router. To do this, follow the procedure outlined in step 1 above, using the host router model instead of the remote router model. Monitoring the Connection The logical interface model may behave in different ways when a call is activated. This behavior is often dependent on the particular router supporting the given dialer profile. The status indicator on the logical interface model icon may display OFF even when the connection has gone live. Page 24

25 The logical interface model icon may also move from the physical layer of the device topology view and stack itself on the PPP encapsulation layer interface model. You can locate the model by drilling down from the physical interface, to the bearer channel layer, to the PPP encapsulation layer, and then to the dialer interface. All of these behaviors are normal, but may differ depending on the device modeled. Therefore, you should rely upon the Dialup_Link model status and the views presented in the Monitoring Connections [page 31] chapter to monitor your connection. Page 25

26 Multiple Dial Backup Links This section discusses modeling a non-persistent connection that allows you to have variable or unspecified links between a remote router and a host router. There could be multiple remote routers linking to a single host router or a single remote router linking to multiple host routers. In This Section Overview [page 26] Multiple Remote Routers to a Common Host Router [page 27] Single Remote Router to Multiple Host Routers or Host Router Interfaces [page 28] Overview A single Dialup_Link model can support configurations that include multiple secondary links. Only one Dialup_Link model is needed to monitor multiple secondary connections, because only a single active secondary connection can exist between the host router and the remote router at one time. Multiple Dial Backup Links (MDBLs) are used in either of the following scenarios: Multiple remote routers each with a dial backup link that connects to a common host router. A single remote router with a dial backup link that could connect to one of several host routers. Page 26

27 Multiple Remote Routers to a Common Host Router Figure 6 shows three remote routers (devices B, C, and D) using one interface on a host router (Interface 4 of Device A) to provide redundant support for their primary links. Figure 6: A Dial Backup Link that Connects to a Common Host Router 1 2 Device B Host Router Device A 1 2 Device C Remote Routers Device D Primary Interfaces Secondary Interfaces There are three main tasks involved in creating this configuration. Each of these tasks is described below and references step-by-step instructions given in the previous chapter. Page 27

28 1. The first task is the configuration of the secondary interfaces on the remote routers. Configuration of these interfaces involves resolving the Dialup_Link model to each secondary interface in the Device Topology view of each remote router. For instructions, see Configuring Secondary Interfaces on the Remote Router [page 13]. Repeat these instructions for each remote router. 2. After you configure all of the secondary interfaces on the remote routers, you must configure the appropriate primary interfaces. When you configure a primary interface, you associate the secondary link to the primary link(s) it is supporting. This is done in the Primary Interface Configuration view. For instructions, see Configuring Primary Interfaces on the Remote Router [page 14]. Note: SPECTRUM will automatically affiliate the secondary interface configured on a device with the primary interface configured on the device, so that if this primary interface fails, the proper secondary connection will be monitored. 3. The final step is the configuration of fixed a secondary interface on the host router. This involves resolving the Dialup_Link model to the secondary interface in the Device Topology view of the host router. For instructions, see Configuring Secondary Interfaces on the Host Router [page 15]. Single Remote Router to Multiple Host Routers or Host Router Interfaces The figure below shows the remote router (device C) has secondary links established with two host routers (devices A and B) to provide redundant support for the primary link between device A and device C. When the secondary link becomes active, it will connect with either router A or router B. Before the connection is actually made, you cannot determine which of these routers the link will connect to. The same scenario exists if the redundant link could connect to one of several interfaces on a host router or routers. In all of these cases, the connection to the host router(s) is resolved at the device level. Page 28

29 Figure 7: Dial Backup Link Connecting to Multiple Host Routers Device A Host Router Remote Router 1 2 Device C Host Router Device B Primary Link Secondary Link There are three main tasks involved in creating this configuration. Each of these tasks is described below and references step-by-step instructions given in the previous chapter. 1. The first task is the configuration of a secondary interface on the remote router. This involves resolving the Dialup_Link model to the secondary interface in the Device Topology view. For instructions, see Configuring Secondary Interfaces on the Remote Router [page 13]. 2. After you configure the secondary interface on the remote routers, you must configure the appropriate primary interface. When you configure a primary interface, you associate the secondary link to the primary link it is supporting. This is done in the Primary Interface Configuration view. For instructions, see Configuring Primary Interfaces on the Remote Router [page 14]. 3. The final task is the configuration of the connection to the host router. If it is unknown which host router and/or host router interface the remote router will connect to, you should resolve the dialup connection to the device level rather than the interface level. Page 29

30 a. In the Topology view where you have created the dialup link, choose File > Edit. b. Double-click on the Dialup_Link model and then click on the host router. This creates a device level connection without connecting directly to one interface. If there are multiple host routers that the remote router could connect to, repeat this step for each of those host routers. c. Choose File > Save to save this view. d. Repeat these steps for each host router that the secondary link could connect to. Page 30

31 Monitoring Connections This section describes how SPECTRUM lets you monitor and manage non-persistent connections. In This Section Dialup_Link Information View [page 32] The Active NPC Summary View [page 32] Connected Devices View [page 35] Determining the Status of Multiple Primary or Secondary Links [page 36] Dialup_Link Condition Color [page 36] Alarm Configuration View [page 38] Alarms [page 40] Page 31

32 Dialup_Link Information View The Dialup_Link Information view (Figure 8) displays information about the creation, current settings, and status of the Dialup_Link model. You access the Dialup_Link Information view by highlighting the Dialup_Link model icon and selecting Information from the Icon Subviews menu. Figure 8: The Dialup_Link Information View The Active NPC Summary View The Active NPC ( Connections) Summary view provides a report on all Dialup_Link models that are currently active in a landscape. The view is dynamically updated. You access the Active NPC Summary view by highlighting the Dialup_Link model icon and selecting Active NPC Summary View from the Icon Subviews menu. Page 32

33 Figure 9: The Active NPC Summary View The following information is presented in this view: Condition: The condition of the Dialup_Link model. (See How to Manage Your Network with SPECTRUM (1909) for a complete explanation of conditions and condition colors.) Model Name: The model name for the Dialup_Link model. From Point: The remote router model name. To Point: The host router model name. Page 33

34 Activation Time: The time that the Dialup_Link model became active; i.e., when the Dialup_Link model was connected to the appropriate interfaces. Up Time: The length of time that the connection has been active. Link Type: The type of link between the two points. Possible types are Backup (DBL), Primary (PODL), and Bandwidth (BODL). (Refer to Types of Links Supported [page 8]). By default, the data in the Active NPC Summary view refreshes every milliseconds (every 5 minutes). It is possible to change the refresh rate to any millisecond value between and To do this: 1. Select Options > Preferences from the NPC Active Summary view menu. 2. In the Preferences dialog box, select the Display tab. 3. Change the Refresh Data Rate (milliseconds) field to the desired value. 4. To save this change, check the Make Changes Permanent check box and click the OK button. Note: Decreasing the value of the Refresh Data Rate so that SPECTRUM updates the Active NPC Summary view data more often can have an impact on the performance of the SpectroSERVER. The benefits of changing the Refresh Data Rate should be weighed against the performance impact. The rest of the menu and button options in the Active NPC Summary view operate in the same way as the Enterprise Alarm Manager Main Window. For specific instructions on how to use these menu and button options, refer to the EAM Main Window section of the Enterprise Alarm Manager (2065). Page 34

35 Connected Devices View The Connected Devices view displays a topology view showing the devices that the Dialup_Link model is connected to. These devices are represented by Off Page Reference (OPR) models. To access the Connected Devices view, highlight the Dialup_Link model and select Connected Devices from the Icon Subviews menu. This view can be accessed from a Dialup_Link model in the SpectroGRAPH or from a Dialup_Link model in other SPECTRUM applications like Alarm Manager. This view is especially useful when troubleshooting an alarm on a Dialup_Link model because it provides a quick way to see all devices connected by the Dialup_Link model. You can view the interfaces that the Dialup_Link model is connected to by accessing the OPR models Device Topology view (select DevTop from the OPR s Icon Subviews menu). For more information on OPR models, see the SPECTRUM Icons Reference (2518). For more information on the Device Topology view, see the SPECTRUM Views (2517) guide. Figure 10: Connected Devices View Page 35

36 Determining the Status of Multiple Primary or Secondary Links You can model non-persistent connections using multiple primary or secondary interfaces. When multiple primary interfaces are used, the status of the group is always determined using the following rule: If any of the interfaces are up, then the group is up. Otherwise, the group is down. Multiple secondary links use the DecSecGrpActiveCriteria attribute to determine the status of the group. If the value is AnySecondaryIFActive, and at least one of the secondary interfaces is up, then the group is considered up. Otherwise, the group is down. Multiple primary links operate in the same way. If the value of DecSecGrpActiveCriteria is AllSecondaryIfsActive, all of the interfaces must be up in order for the group to be considered up. If not, then the group is down. When one or more interfaces in the multiple link scenario is in Maintenance Mode, SPECTRUM will treat it as if that link does not exist, and base the status of the group on the remaining non-maintenance interfaces. The exception is if all interfaces are in Maintenance Mode, then the entire group is in Maintenance Mode. Dialup_Link Condition Color The way in which the Dialup_Link model reacts to changes in the primary and secondary links depends upon the type of non-persistent connection this model represents. The following tables show the possible conditions for the Dialup_Link model representing a Dial Backup Link, Bandwidth on Demand Link, or a Primary On Demand Link. Table 1: Dial Backup Link Conditions Primary Link Secondary Link Dialup_Link Condition Generated Events Up Up Yellow Both primary and secondary links active. Up Down Brown Secondary link inactive. Page 36

37 Primary Link Secondary Link Dialup_Link Condition Generated Events Down Up Green Secondary link active. Down Down Red Secondary link has failed to activate. Maintenance Mode Maintenance Mode Up Green Secondary link active. Down Brown Secondary link inactive. Up Maintenance Mode Brown Secondary link inactive. Down Maintenance Mode Brown Secondary link inactive. Maintenance Mode Maintenance Mode Brown Secondary link inactive. Table 2: Bandwidth on Demand Link Conditions Primary Link Secondary Link Dialup_Link Condition Generated Events Up Up Green None Up Down Brown Secondary link is inactive. Down Up Green Secondary link is active. Down Down Red Secondary link has failed to activate. Maintenance Mode Maintenance Mode Up Green Secondary link active. Down Brown Secondary link inactive. Up Maintenance Mode Brown Secondary link inactive. Down Maintenance Mode Brown Secondary link inactive. Maintenance Mode Maintenance Mode Brown Secondary link inactive. Page 37

38 Table 3: Primary On Demand Link Conditions Primary Link Dialup_Link Condition Generated Events Up Green No event is generated. Primary On Demand Link is active. Down Brown No event is generated. Primary On Demand Link is inactive. Up Yellow The maximum uptime value has been exceeded. Maintenance Mode Brown No event is generated. Primary On Demand link is inactive. There are two exceptions to the Dialup_Link Condition Tables. These involve special alarm conditions of Gray and Orange. A Gray condition is asserted on a Dialup_Link model when all secondary interfaces are considered unreachable. An Orange condition is asserted only in a multiple primary/secondary configuration when a primary link has failed but the secondary link is already active in support of another connection. Alarm Configuration View The Alarm Configuration view allows you to configure when alarms will be generated on the Dialup_Link model for certain conditions. To access the Alarm Configuration view, click on the Dialup_Link model and then choose View > Icon Subviews > Alarm Configuration. Page 38

39 Figure 11: Alarm Configuration View Activation Grace Period (Minutes): This field allows you to specify the time allowed, in minutes, for the secondary link to become active after a primary link failure. If this grace period expires before the secondary link is active, then a red alarm is generated. This field is only used by DBL-type link models. The value for this field can also be specified when creating a Dialup_Link model (see Model Creation [page 9]). Deactivation Grace Period (Minutes): This field allows you to specify the time allowed, in minutes, for an active secondary link to deactivate after the failed primary link reactivates. If the secondary link is still active after this grace period expires, then a yellow alarm is generated. This field is only used by DBL-type link models. The value for this field can also be specified when creating a Dialup_Link model (see Model Creation [page 9]). Active Time Until Yellow (Hours): This field allows you to specify the number of hours a backup link can be active before a yellow alarm is Page 39

40 generated. The value for this field can also be specified when creating a Dialup_Link model (see Model Creation [page 9]). Active Time Until Orange (Hours): This field allows you to specify the number of hours a backup link can be active before an orange alarm is generated. The value for this field can also be specified when creating a Dialup_Link model (see Model Creation [page 9]). Active Time Until Red (Hours): This field allows you to specify the number of hours a backup link can be active before a red alarm is generated. The value for this field can also be specified when creating a Dialup_Link model (see Model Creation [page 9]). Active Criteria: This field allows you to define the active state for nonpersistent connections that have more than one secondary interface, i.e. a connection that uses multiple physical connections to form one logical connection. When this multi-link type configuration is used the Dialup_Link model will monitor all of the secondary interfaces. If Active Criteria is set to Any Secondary IF Active then the dial-up link will be considered active if ANY of the secondary interfaces become active. If Active Criteria is set to All Secondary IFs Active then ALL the secondary interfaces must become active before the Dialup_Link model will be considered active. Alarms The following list shows the alarms that SPECTRUM can generate on a Dialup_Link model. Note: Events generated on a Dialup_Link model have an event message which contains information on the devices and interfaces that the Dialup_Link model is connected to. Alarm Code Alarm Alarm Cause 0x022ffff8 Excess timer has been exceeded. The link has been active for longer than the time specified by the Active Until Yellow, Orange or Red criteria.(see Model Creation [page 9]). 0x022ffff9 Backup link is already active. This alarm occurs when SPECTRUM attempts to activate a dialup link that is already active. 0x022ffffa Both the primary and the secondary links are active. Both the primary and the secondary links have been activated. Page 40

41 Alarm Code Alarm Alarm Cause 0x022ffffb The secondary link failed to activate. An attempt to activate the secondary link was unsuccessful. 0x022ffffc The secondary link is inactive. The primary link is functioning properly and the secondary link has returned to an inactive status. 0x022ffffd The Dialup_Link model is unreachable. This alarm is generated when all of the Dialup_Link model s neighbors are down. Neighbors include any interface model or device model to which the Dialup_Link model has a resolved connection. Page 41

42 Index A Activation Grace Period [10] Active NPC Summary View [32] Add Interfaces [15] B Bandwidth on Demand Link [8] C Connected Devices [35] D Deactivation Grace Period [10] Dial Backup Link [8] Dialup Protocol Type [9] Dialup Type [9] Dialup_Link Creation View [10] Dialup_Link Information View [32] Dialup_Link model [9], [13], [15], [16], [21], [26], [29], [32] H Host Router [15] I Information [32] L load balancing [7] Page 42

43 M Model Name [11] Multiple Dial Backup Links [26] P Primary Interface Configuration [14] Primary on Demand Link [9], [13] S Secondary Interfaces [15] Security String [9] U unspecified links [26] Page 43