Configuring the Mainframe-to-Router Link

Before you can use ISM to manage routers on your network, a link must be established between the mainframe and the router for communication. To establish this link, you need to configure both the mainframe and the router sides of the network. Configuring the mainframe-to-router link involves the following tasks:

This chapter provides detailed instructions for enabling the link between the mainframe host and a router. This chapter discusses the following topics:

Coordinating the ISM Installation

This chapter explains how to configure the network devices for use with ISM, and how the router configuration correlates to the VTAM PU definition on the mainframe.

To ensure successful configuration of the mainframe-to-router link, the network engineer should coordinate setup of the router configuration with the MVS system programmer responsible for configuring the router's VTAM connection on the mainframe.

For the Network Engineer

This section describes installation information relevant to the network engineer.

•

If you have already configured SNA service point support on your routers for ISM V1R3.0, then you do not need to perform any additional configuration on the router.

•

If you are installing ISM at your site for the first time, be sure to read the "Preparing to Install ISM" chapter before proceeding.

For the MVS System Programmer

This section describes installation information relevant to the MVS system programmer.

•

If you have ISM V1R3.0 installed and are adding new routers to the network, you must define a PU in VTAM. If you do not need to add new routers, skip this chapter, and read Chapter 3, "Installing ISM."

•

If you are installing ISM for the first time, you must configure VTAM to define a PU for each router you will be managing from ISM. This step can be performed before you install ISM, to verify that the proper mainframe connections to the router are established.

Configuring a VTAM Connection

Before you can use ISM to view and manage a Cisco router from your NetView console, the router must be connected to the VTAM host through a systems services control point-to-physical unit (SSCP-to-PU) session. This connection is established by defining a PU for each router in the VTAM configuration file.

To define a PU, add the following lines to the VTAM configuration file for each router, and specify the values for the SERVICE_POINT_NAME, idblock number, and id number arguments for each router. These arguments must correspond to the values specified in the configuration of the router.

The PU type, ID block, and ID number arguments are the most important arguments in the sample VTAM definition. The other arguments are given as an example only, and are not required.


Argument	Description
SERVICE_POINT_NAME	Service point name of the router (1 to 8 characters).
idblock number	Identification number sent to the host when a connection is being established. The idblock number corresponds to the first 3 hexadecimal digits of the router exchange identification (XID) number. It is recommended that you specify 05D for routers.
id number	Unique number that identifies the router. The id number corresponds to the last 5 hexadecimal digits of the router's XID number.

Configuring the Router

In addition to configuring a VTAM connection for each router, you must configure the router to support communication with ISM. To ensure that the router is properly configured, perform the tasks in the following sections:

Configuring and Connecting the Router to the Network

Be sure to enable the router according to the instructions provided in the documentation that came with your router. Verify that the router is configured and connected to the network.

Specifying the Router Name and Enable Password

Use the dspu/sna host and enable password commands in the configuration file of each router to specify the router name and password-protected security level for the router. These parameters are used in the implementation of ISM.

Router Name

The name that you specify for the router in the dspu/sna host command is used when you configure SNA service point support in the router and also when you configure the VTAM connection.

For more information about using this command, see the Cisco IOS Configuration Fundamentals Configuration Guide.

Enable Password

The enable password command controls access to various privilege levels on the router. When enable password is enabled in the configuration file of the router, ISM recognizes this level of security and prompts the user to specify the password to execute any enable-mode commands from ISM.

Note

ISM also supports Terminal Access Controller Access Control System (TACACS) security in the router. Your router configuration may vary if TACACS is implemented.

To specify the privilege level and password that you would type to enter enable mode on the router, use the following command:

enable password [level level]{password | encryption-type encrypted-password}

For more information about using this command, see the Cisco IOS Security Command Reference.

Configuring SNA Service Point Support

To configure SNA service point support on the router, you need to add Cisco IOS software sna host commands to the configuration file of your router. The specific commands you add will depend on the type of connection you wish to establish. For detailed information on configuring SNA service point support and the Cisco IOS software command for your interface type, refer to the Cisco IOS Bridging and IBM Networking Configuration Guide and Command Reference publications.

The following procedure shows the basic steps to define SNA service point support for Ethernet and Token Ring connections. Again, the actual commands you use will depend on the type of connection you wish to establish. If you want to view some specific configuration examples, see the " Router Configuration Samples" section on page 2-6.

Perform the following tasks to define SNA service support for Ethernet and Token Ring:

Step 1

Define a link to an SNA host in global configuration mode using the sna host command.

The following example shows the syntax of the sna host command for Token Ring, Ethernet, FDDI, RSRB, or virtual data-link control (VDLC) connections:

sna host host-name xid-snd xid rmac remote-mac rsap remote-sap lsap local-sap focalpoint

Note

Be sure to specify the focalpoint argument when you define the SNA link. Accept only the default values for the other options (such as retries) in the sna host command. If you specify any other values for these options, the router connection to ISM may not work properly. The focalpoint argument in the router configuration file is not related to ISM's Focal Point application.

Step 2

Enable the local service access point (SAP) on the interface when you are in interface configuration mode, using the command syntax:

Step 3

Start an outgoing connection when you are in interface configuration mode, using the command syntax:

For more information about these commands and their options, see the Cisco IOS Bridging and IBM Networking Command Reference.

Router Configuration Samples

This section provides five samples of the SNA Service Point configuration in a router configuration file. The following samples are provided:

Configuration Through a Local Ring to an IBM 3745 Token Ring Interface Connector

The following example shows the lines that would appear in the configuration file of a router with an interface configured through a local ring to 3745 Token Ring Interface Connector:

Configuration for a DSPU with RSRB on a CMCC

The following example shows the lines that would appear in the configuration file of a router combining a Cisco mainframe channel connection with an interface configured for RSRB:

Configuration for DSPU with RSRB

The following example shows the lines that would appear in the configuration file of a router with an interface configured for DSPU with RSRB:

Configuration for RSRB with a Loopback

The following example shows the lines that would appear in the configuration file of a router with RSRB and an interface configured with loopback:

Configuration for DLSw+ Using Virtual Data-Link Control

The following is an example of the lines that would appear in the configuration file of a router using virtual data-link control over DLSw+:

Correlating the Router and VTAM Configuration Information

The router's service point name and the XID number must correspond in both the router and VTAM configurations to successfully establish a link between the router and the SNA host. It is important that the network engineer and the MVS system programmer communicate for proper setup of these two configurations.

The following example shows the format of a Cisco IOS software sna host command that you use to configure the router for SNA Service Point support:

sna host host_name xid-snd xid rmac remote_mac [rsap rsap_addr] [lsap local_sap] [focalpoint]

The values for the host_name and xid in the router configuration correspond to the VTAM PU definition in the following way:

•

The SERVICE_POINT_NAME argument shown in the VTAM PU definition is the name of the router configured the in host argument of the sna host command.

•

The idblock number and id number arguments shown in the VTAM PU definition are components of the router XID number that you specify as the value for xid in the xid-snd argument of the sna host command.

For example, if the router XID is 05D00001, you specify an idblock number of 05D and an id number of 00001 in the VTAM PU definition. You specify a value of 05D00001 in the xid-snd argument of the sna host command.

Example

The following example shows a VTAM configuration file which was configured for connection to a router with the hostname GLENDUSK and XID of 05DBB000:


`SWDRTRS VBUILD TYPE=SWNET`
`GLENDUSK`	`PU`	`ADDR=01, PUTY PE=2, IDBLK=05D, IDNUM=BB000, DISCNT=(NO), ISTATUS=ACTIVE, MAXDATA=521, IRETRY=YES, MAXOUT=7, PASSLIM=5, MAXPATH=4`	`x x x x x x x x x x`

sna host glendusk xid-snd 05dbb000 rmac 4001.3745.1088 rsap= 4001.3745.1088 fsap 4 lsap 4 focalpoint

For more information about the sna host command, see the Cisco IOS Bridging and IBM Networking Command Reference.

Verifying the NetView Environment

This section describes the following procedures, which are used to verify that NetView is properly configured to support the service point in the router:

Verifying the Timeout Value for RUNCMDs

This section describes the procedure to verify the values of the costime and maxreply options are set correctly in NetView to support the ISM autotasks.

The costime option specifies the amount of time (in seconds) that ISM waits before detecting that a timeout of the RUNCMD has occurred. The ISM autotasks will wait for a RUNCMD to complete, and all other ISM processing stops until it is done. This may result in ISM pausing for long periods waiting for a response from a RUNCMD.

The maxreply option specifies the amount of time (in seconds) that NetView waits before detecting that a timeout of the RUNCMD has occurred. If the value is 86400, NetView will timeout the RUNCMD after 24 hours have passed.

When a RUNCMD times out, ISM places the router in an inoperable (INOP) state until an operator resets the router's status.

Note

When costime defaults to the value of maxreply, only costime should be changed.

To verify the value for the costime option and change it if necessary, complete the following steps:

Step 1

From a NetView command prompt, type the command list defaults and press Enter.

Note the value for the costime argument. A value of 120 seconds is suggested for the costime argument.

Step 2

To change the value of the costime argument, complete one of the following tasks:

•

To dynamically change the value of the costime argument without restarting NetView, type defaults costime=120 from the NetView command prompt.

•

To permanently specify the costime argument in NetView, modify the NetView production CLIST (the default CLIST is CNME1035) to specify the command defaults costime=120.

Verifying if NetView Supports RUNCMDs

This section describes the procedure that verifies proper configuration of the NetView VTAM definition for LU 6.2 support. Although the router rejects NetView's initial LU 6.2 commands, NetView's response is to use the DSIGDS or CNMxxGDS task to send RUNCMDs, which are supported by the router. LU 6.2 support must be configured in VTAM so that NetView uses the DSIGDS task, which allows communication with the router.

To verify NetView's RUNCMD support, browse the VTAM definition for NetView and verify that your site's NetView application major node contains the following information in the second and third lines:

Verifying the Router's Mainframe Connection

Once you have configured a VTAM connection for each router and verified that the configuration and SNA service point support have been properly defined, you can test the router's configuration from NetView and VTAM. This is the first level of installation verification for ISM.

If the verification procedures indicate a problem with the link, see Chapter 7, "Troubleshooting" to diagnose the error.

Verifying the Router Connection from NetView

Use the following procedure to verify that the network devices are configured properly and that the router can attach to the network:

Step 1

From a NetView command prompt, issue the following command for each router, where router_name is the hostname and service point name of the router that you are verifying:

If properly configured and connected, the router status displays an active (ACTIV) status. If the router does not display an active status, either it is not successfully configured, and therefore is not attached to the network, or the service point is not defined correctly. See Chapter 7, "Troubleshooting" to further diagnose the problem.

Testing with NetView RUNCMDs

ISM uses NetView's RUNCMD facility to support communication between ISM and the router. To verify that the router can communicate with NetView using RUNCMDS, use the following procedure:


SP=router_name	Specifies the name of the service point to execute the command. This is the name of the router and the service point name that you configured in VTAM.
APPL=applname	Specifies the name of the link connection subsystem manager to execute the command. This is the service point application name. This example specifies console.
CLISTVAR={Y/N}	Specifies whether replies are saved in command list variables. This example specifies no.
show ?	The command that the router should execute. The show ? command produces a list of the supported show commands for the router.

Step 2

Verify that you receive a list of the commands supported by that router. If you receive a response indicating a router problem (such as not defined to VTAM, not active, disabled service point, or RUNCMD timeout), see "Troubleshooting" to further diagnose the problem.

Verifying the Router Connection from VTAM

You can verify communication between the router and the mainframe from VTAM, using the following procedure:

Step 1

From the MVS console, issue the following command for each router name, where router_name is the hostname and service point name of the router you are verifying:

Configuring SNMP on a Target Router

Before ISM uses SNMP to monitor Cisco routers, you must enable SNMP within a target router. ISM uses the community name to obtain variables. By default, ISM uses "public" as the community name. When defining a router to ISM, the community name can be changed for a single router or all routers.

If you want to send SNMP traps to a host where ISM resides, complete the following steps:

Step 2

Add statements for each host that is to monitor the router, as follows:

Defining SNMP in Cisco Routers

To specify the recipient of an SNMP notification operation, use the snmp-server host global configuration command.

snmp-server host host [traps | informs] [version {1 | 2c}] community-string [udp-port port] [notification-type]


Syntax	Description
host	Name or Internet address of the host.
traps	Send SNMP traps to this host. This is the default.
informs	Send SNMP informs to this host.
version	Version of the Simple Network Management Protocol (SNMP) used to send the traps.
1	SNMPv1. This option is not available with informs
2c	SNMPv2C
community-string	Password-like community string sent with the notification operation
udp-port port	UDP port of the host to use. The default is 162.
notification-type	Notification Type to be sent to the host. If no type is specified, all notifications are sent. The notification type includes one or more of the following keywords: •bgp—Sends Border Gateway Protocol (BGP) state change notifications. •config—Sends configuration notifications. •dspu—Sends downstream physical unit (DSPU) notifications. •entity—Sends Entity MIB modification notifications. •envmon—Sends Cisco enterprise-specific environmental monitor notifications when an environmental threshold is exceeded. •frame-relay—Sends Frame Relay notifications. •isdn—Sends Integrated Services Digital Network (ISDN) notifications. •llc2—Sends Logical Link Control, type 2 (LLC2) notifications. •rptr—Sends standard repeater (hub) notifications. •rsrb—Sends remote source-route bridging (RSRB) notifications. •rtr—Sends response time reporter (RTR) notifications. •sdlc—Sends Synchronous Data Link Control (SDLC) notifications. •sdllc—Sends SDLLC notifications. •snmp—Sends Simple Network Management Protocol (SNMP) notifications defined in RFC 1157. •stun—Sends serial tunnel (STUN) notifications. •syslog—Sends error message notifications (Cisco Syslog MIB). Specifies the level of messages to be sent with the logging history level command. •tty—Sends Cisco enterprise-specific notifications when a Transmission Control Protocol (TCP) connection closes. •x25—Sends X.25 event notifications

Defaults

If you enter this command with no keywords, the default is to send all trap types to the host. No informs will be sent to this host.

If no version keyword is present, the default is version 1. If no traps or informs keyword is present, traps are enabled.

The no snmp-server host command with no keywords will disable traps, but not informs. In order to disable informs, use the no snmp-server host informs command.

Usage Guidelines

SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it receives traps. The sender cannot determine if the traps were received.

However, an SNMP entity that receives an inform request acknowledges the message with an SNMP response PDU. If the sender does not receive a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.

However, informs consume more routers in the agent and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network.

If you do not enter an snmp-server host command, no notifications are sent. In order to configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no keywords, all trap types are enabled for the host. In order to enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.

When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each succeeding command overrides the previous command. Only the last snmp-server host command will be in effect. For example, if you enter an snmp-server host inform command for a host and then enter another snmp-server host inform command for the same host, the second command will replace the first.

The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.

However, some notification types cannot be controlled with the snmp-server enable command. For example, some notification types are always enabled. Other notification types are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.

A notification-type option's availability depends on the router type and Cisco IOS software features supported on the router. For example, the envmon notification-type is available only if the environmental monitor is part of the system.

SNMP Trap Examples

The following example sends the SNMP traps defined in RFC 1157 to the host specified by the name myhost.cisco.com. The community string is defined as comaccess:

The following example sends the SNMP and Cisco environmental monitor enterprise-specific traps to address 172.30.2.160:

The following example enables the router to send all traps to the host myhost.cisco.com using the community string public:

The following example will not send traps to any host. The BGP traps are enabled for all hosts, but only the ISDN traps are enabled to be sent to a host:

The following example enables the router to send all inform requests to the host myhost.cisco.com using the community string public:

Related Commands

You can use the master indexes or search online to find documentation for the following related commands:

Table Of Contents