|
|
This chapter describes how to start the DLSw, RSRB, and APPN Motif applications, how to discover network devices, how to use the cwbinit preferences file, and how to start the CiscoWorks Blue web server. This chapter contains the following main sections:
This section describes how to start the DLSw application. You can start the DLSw application from the workstation system prompt or from a network management system, such as NetView for AIX.
Before you start the DLSw application, you should identify at least one or two selected routers as key devices. If you do not identify key routers in the seed file, the DLSw application cannot display its key devices view and it prompts you to designate key devices or to select another view of the network. You can designate key devices in one of these ways:
The term network management system refers to NetView for AIX, HP OpenView, or Sun Net Manager on the network management workstation.
You can provide network information to DLSw in two ways. You can use the database maintained by a network management system. Or you can list all the network devices in a seed file. If you do not have a network management system, or if the network management system is not up-to-date and cannot be updated, or if you know the network management system database is so large that you do not want a map application to spend the time querying every device listed there, you can create a seed file. A seed file is a text file that lists the routers, and their read community strings, that you want to be recognized by a specific Maps application. Supply this seed file to the Maps application using the procedure in the section "Discovering the Network with a Seed File."
If you are using a network management system database, verify that the network management system has current data to share with Maps applications before you start DLSw. Even if the network management system is not running at this time, verify that it has been run recently in automanage mode or that you have run the discovery process at least once since the last installation of new routers or reconfiguration of existing routers. If you want to discover new routers dynamically as they come online, the network management system must be running in automanage mode continually.
The collection of information and graphical representation of DLSw devices and peer states in the network is usually automatic. You can see a representation of a complete DLSw network or a narrowed perspective of the DLSw network, including Token Rings, routers, peer statistics, circuit lists, and links.
You can start DLSw from any valid user account. The installation process establishes a sample default user account named cwblue. The user cwblue does not have a starting password. You can either assign a password to cwblue or log in as root and change to cwblue.
cd /opt/CSCOcb/bin
./cwb start dlsw
You can log in to a remote UNIX host from your own local UNIX workstation, export the remote host display to your local workstation, and then run the application from the remote host. To start the remote host's DLSw application from your local workstation, use the following procedure:
Step 1 At your local UNIX workstation, enter the following command:
xhost +
Step 2 Log in to the remote UNIX host.
Step 3 Set your DISPLAY environment variable to export the display from the remote host to your local workstation. Depending on which shell you are using, use one of the following commands.
export DISPLAY=IP_address:0.0
setenv DISPLAY IP_address:0.0
Step 4 To start DLSw, enter the following commands:
cd /opt/CSCOcb/bin
./cwb start dlsw
When you start DLSw, the cwb start dlsw command uses the runprocess script to start the monitor and poller daemons. The monitor and poller daemons monitor the changes in the network, update the database with the changes, and notify the DLSw application when network changes occur. When you exit the DLSw application, all daemons continue to run to maintain the database. If you want to stop them, use the Process Manager, as described in "Using Process Manager."
This section describes what happens when you start DLSw for the first time (or when you select View>Key Devices from the menu bar).
When it first starts, DLSw tries to display a special view called the key devices view. The key devices view displays those routers that you have designated as "key devices."
If no devices are specified as key routers, the key devices view is empty. DLSw determines whether there are any routers enabled for DLSw in the database. Depending on whether there are DLSw--------enabled routers in the database, DLSw proceeds as described in the following sections:
If the key devices view is empty and there are no DLSw routers in the database, then discovery was not done. DLSw displays the following message:
Key devices discovery needs to be performed.
Please create a seed file with "key" tags in it.
After that, select Admin->Discover->Seed File.. on that seed file.
OK?
Select Admin>Discover>Database or Admin>Discover>Seedfile to discover the network. Now retry the key devices view. If the key devices view is still empty, go to the section "DLSw Routers in the Database."
If the key devices view is empty, but there are DLSw routers in the database, then discovery was done but no key routers are designated. DLSw displays the message window shown in Figure 8-1.
You have the following choices:
This section describes how to discover the Cisco DLSw-enabled routers in your SNA network.
Discovery is the process by which the DLSw application queries each device in the network to determine whether it is enabled for DLSw networking. Each time the DLSw application finds a router, it performs one of the following actions:
There are several ways that the DLSw application can discover the routers in a network. You can provide a list of enabled routers in a special file called a seed file. Or you can let the Maps application get its information from a network management system database. Both methods of discovery are described in this section, which contains the following subsections:
Each record in the seed file can be either a comment or a router specification. You can list the routers in any order within the seed file.
A comment is a single line of text that begins with the pound (#) character as shown below.
# This line is a comment.
A router specification can have one of the following formats:
router [ReadCommunityString] [key]
or
router:[ReadCommunityString]:[key]
Use the following conventions for the router specification:
The following sample router specification designates router west.cisco.com as a key device with the read community string "public":
west.cisco.com:public:key
Because the "key" parameter is used for DLSw only and is ignored for APPN and RSRB, you can use the same seed file for all three Maps applications. The following lines are from a sample seed file:
# Seed file for CiscoWorks Blue Maps applications
# Next is a non-key router with goldilocks read community string
east.cisco.com goldilocks
# Next is a non-key router with default read community string
172.18.7.47
# Next is a key router with default read community string
west.cisco.com:*:key
# Next is a key router with a read community string
east.cisco.com:readstring:key
To use a seed file to provide the information to the application, use the following procedure:
Step 1 Use a text editor to create the seed file. Save the seed file, for example with the name dlswseed.
Step 2 Start DLSw and select Admin>Discover>Seed File to display the Seed File Discover window.
Or you can use the CiscoWorks Blue Administration application, as described in "Using the Administration Application."
Step 3 Enter the name of the seed file, verify the correct read community string, and click Discover. Discovery takes place while you wait.
After loading the database using the seed file, the DLSw application operates normally until a router is taken off line or a new router is configured. At that time, you can perform one of the following actions:
The network management system maintains a database that includes all SNMP-managed routers in your network. You can use that database to provide the Maps application with the information that it needs to discover the DLSw-enabled routers in the network. You can do this manually or automatically.
To have the Maps application discover the network from the network management system database manually, select Admin>Discover>Database from the Maps application menu bar. The Maps application adds the routers found by the network management system to the database. The Maps application checks the database for new routers, polls their MIBs, and updates the database with the new MIB information.
You can have Maps check the network management system database automatically. This is called automatic discovery mode; you might want to use it if you expect to install or reconfigure routers often. To use automatic discovery mode, use the cwb start cwbdiscover command as a UNIX cron job (a chronologically started job) job. Set the cron job to run at night or when system and network activity are low.
If you want to add only one or a few routers to your network, you can discover each router individually using the following procedure:
Step 1 Select Edit>Add Device(s).
Step 2 When prompted, enter the router's device name and its read community string.
Step 3 Click OK.
The DLSw application adds the router to the database, polls the router's MIB, and adds the MIB information to the database. Watch the status area to see a message that indicates the success or failure of this polling.
It is sometimes useful to rediscover a DLSw router, especially if one of the following events occurs:
There are several ways to rediscover individual routers:
The following conditions must be met to have SNA PUs and LUs correlated with the DLSw routers that support them:
This section describes how you can specify selected DLSw routers as key devices to limit some of the SNMP traffic on your network.
A key device is a router that you designate as "key." This usually means that the router is in close proximity to the mainframe, or it supports an important set of network resources. You can use key routers to reduce the SNMP traffic needed to manage your network, to minimize the number of devices shown on a DLSw map, and for circuit polling, which is needed for SNA correlation. You can also specify a faster polling rate for key devices.
You can limit some of the SNMP traffic involved in discovering and polling routers by selecting only key routers that are in close proximity to the mainframe and that are responsible for handling traffic between the mainframe and other remote routers and devices in your network. If a router is marked as a key device, the poller daemon polls this router for all of the circuits in addition to the peer connections. If a router is not marked as a key device, the poller daemon polls the router just for the peer connections.
A DLSw circuit is represented in both of the DLSw peers through which an SNA session passes. Because part of the circuit information is duplicated in each peer router, the DLSw Maps application can find the SNA path used, even if it polls only one of the routers (a key router, for example). Polling one peer reduces the polling interval and reduces network traffic.
If you designate a set of routers as key devices, you can later display a view of just the key devices. This view is called the key devices view of the network and is described in the CiscoWorks Blue Maps and SNA View User Guide.
The key devices view of the network displays just the DLSw-enabled peer routers that have been designated as key devices. The key devices view represents all the peers of a key router with one icon, which is called an aggregated peer router icon. The connection between each key router and its aggregated peer router icon is shown as a single connection called an aggregated peer connection.
To see how using key devices can remove the clutter from your maps, compare the key devices view with the global view shown in the CiscoWorks Blue Maps and SNA View User Guide.
The DLSw application lets you define two different polling intervals, as described in the section called "Using cwbinit to Configure Polling Intervals." You can specify how the DLSw application polls routers for peer connection information and for circuit information. You can select from the following polling methods:
If you make no changes, the DLSw polling daemon uses all three polling methods: it polls key routers and non-key routers for peer connection information, and it polls key routers for circuit information. You can change these selections using the polling values in the cwbinit file.
You can also use the cwbinit file to configure multiple polling threads. By default, Key-----Peer polling uses five threads so that it can poll more key routers concurrently, while Non--Key--Peer polling uses only one thread by default. You can change these settings in the cwbinit file.
This section gives you some guidance in choosing which routers to designate as key devices. Usually, you will want to choose key routers for the following reasons:
The following two network examples show how to choose key routers.
Figure 8-2 shows a network in which the two DLSw-enabled data center routers handle all the peer connections between the mainframe and the remote branch routers. In this case, you should designate these two data center routers as key devices.
Figure 8-3 shows a network in which one DLSw-enabled concentrator router handles all the connections between the mainframe and the remote branch routers. In this case, you should designate the concentrator router as a key device.
Initially, no routers are marked as key devices when they are added to the database. You must take some action to mark a router as a key device. There are several ways that you can define a router as a key device.
For each router that you include in the seed file, you can use the key parameter to designate that router as a key device. If the key parameter is not used, the router is not a key device in the seed file. To see which routers are key devices, select Edit>Key Device(s) from the menu bar. In the list of routers, the key devices are highlighted.
Once you mark a router as a key device, removing the key parameter in the seed file will not change the device's status as a key device. To change the router's status as a key device, select Edit>Key Device(s) from the menu bar, deselect the router in the router list, and click Apply.
For information on using the key parameter, read the section "Discovering the Network with a Seed File."
Step 1 From the DLSw menu bar, select Edit>Key Device(s). A list of routers is displayed. If a router name is highlighted, it is a key device.
Step 2 Select those routers that you want to add to the list of key devices. Each router that you select is highlighted.
Step 3 Deselect those routers that you do not want to be key devices. The routers that you select here will not be highlighted.
Step 4 Click Apply to apply your changes in the database.
Step 5 Click Close to close the window.
In a key devices view of the network, each key router is shown connected to one icon that represents all of that router's peers. This icon is called an aggregated peer router. The connection from the key router to its aggregated peer router is called an aggregated peer connection. Each aggregated peer connection and each aggregated peer router is displayed in a color that indicates its status. The status that is shown for the aggregated peer or peer connection represents the status of each component that makes up the aggregate. You can specify how to choose the color in which the aggregated status is displayed. There are two ways to choose the status of an aggregated peer or peer connection: using the worst-case status or using a calculated status.
You can choose to have all aggregated peers displayed in the color that is used for the peer with the worst status. For example, if the worst peer connection represented in the aggregated peer connection is inactive, then the aggregated peer connection is displayed as a red line and its aggregated peer router is also displayed in red.
To specify how aggregated peers are displayed, use the following procedure:
Step 1 Select Edit>Define Aggregate Status from the menu bar. The Aggregate Status Definition window is displayed.
Step 2 Select Propagate Highest Abnormal Status.
Step 3 Click Apply.
A peer connection can have one of the four statuses: active, degraded, inactive, or unknown. Degraded, and inactive statuses are considered abnormal. When all peer connections have unknown status, the aggregate status is "unknown."
You can choose to have the aggregated peers displayed in a color that represents a status that is calculated from the statuses of the individual peers that make up the aggregation. The calculation is based on the percentage of peers in the aggregation whose condition is abnormal. An abnormal condition is based on the reported status of the peer.
To determine how to display an aggregated peer, look at the percentage of individual peers in the aggregated peer that have an abnormal condition. Once that percentage is determined, you define two threshold values: the Marginal% value and the Critical% value.
To specify percentages for the Marginal% value and Critical% value, use the following procedure:
Step 1 From the menu bar, select Edit>Define Aggregate Status. The Aggregate Status Definition window (Figure 8-4) is displayed.
Step 2 Select Threshold Value (%) and enter the values in the Critical% and Marginal% fields.
Step 3 Click Apply.
You define the Marginal% value for your network. The default Marginal% value for DLSw aggregated peers is 0 percent.
You define the Critical% value for your network. The default Critical% value for DLSw aggregated peers is 20 percent.
A special case occurs when all peers are unknown. In this case, the aggregated peer is considered unknown and is displayed in blue.
DLSw calculates the status of an aggregated peer connection using the following method:
1. DLSw finds the percentage of all peer connections in the aggregation whose status is abnormal. For this example, let x percent be the percentage of abnormal peer connections.
2. DLSw compares the percentage of peer connections that are abnormal (x percent) to the Critical% value and to the Marginal% value.
3. DLSw now calculates the status of the aggregated peer connection:
For example, that there is a key router with six peer connections: three connections are active; one connection is unknown; and, two connections are inactive. That means that 50 percent of the peer connections have abnormal status. Here are some scenarios:
The cwbinit file contains a set of startup options and variables with which the DLSw application starts. However, if you start DLSw with command-line options, the command-line options override the options set in the cwbinit file. These DLSw parameters in the cwbinit file are used only by the DLSw poller when it starts. If you change the cwbinit file while the poller is running, you must reset the poller to enable the changes in cwbinit.
To reset the poller, use the Process Manager or enter the following commands from the command prompt:
/opt/CSCOcb/bin/cwb stop cwbdlswpollerd
/opt/CSCOcb/bin/cwb start cwbdlswpollerd
For each variable that you set in cwbinit, ensure that there is a space before and after the equal sign. For example, to set the eventgen variable off, you would enter the following line in cwbinit:
eventgen = off
The following cwbinit file sample shows just the values that apply to the DLSw application:
Cisco Works Blue Maps and SNA View preferences file
# CWBlue applications first check for a user-customized version of
# this file as $HOME/.cwbinit. If the file is not found there, they
# use the installed version at $CWBROOT/etc/cwbinit.
# RULES:
# Keywords must start in column 1.
# There must be a space on each side of the = character.
# Everything on the right of the = character is taken as the value contents.
# Comments must start with # in column 1 only.
# Comments cannot be included on lines with keywords and values.
# Blank lines are ignored.
# [cwbsnamapsd section deleted]
# ************************************************************************
# These parameters are only read at startup time by the DLSw poller
# (cwbdlswpollerd) and APPN applications (cwbsnamapsd and appn).
# ****************************************************
# *** Global parameters used by both DLSw and APPN ***
# ****************************************************
# This parameter controls how often cwbdlswpollerd and cwbsnamapsd will
# check to see if another process has requested that it recycle itself.
# Other processes make this request after APPN, TN3270, and/or DLSW
# discovery/rediscovery and after DLSW key routers are assigned. The DLSw
# poller and cwbsnamapsd processes periodically check to see if a restart
# request has been made. The value supplied is in seconds.
processRestartInterval = 30
# to turn off event generation set eventgen = off.
# valid values : on/off. default value : on.
eventgen = on
# to turn on device state change event generation set eventgen_device = on.
# valid values : on/off. default value : off.
eventgen_device = off
# ***********************
# *** DLSw parameters ***
# ***********************
# These parameters are used by the DLSw poller. If the poller is already
# running, it must be stopped and restarted from the process manager,
# or from the command line as follows:
# $CWBROOT/etc/runprocess cwbdlswpollerd -f
# *** DLSw event generation parameters ***
# to turn off dlsw peer event generation set eventgen_dlswpeercxn = off.
# valid values : on/off. default value : on.
eventgen_dlswpeercxn = on
# to turn on dlsw circuit event generation set eventgen_dlswcircuit = on.
# valid values : on/off. default value : off.
eventgen_dlswcircuit = off
# *** DLSw polling parameters ***
# to set key routers polling timer set keyPeerSleepTime = <number of seconds>.
# valid range of values : 0 to 65535 seconds. default value : 600 seconds.
keyPeerSleepTime = 600
# to turn on slow polling of non-key dlsw peer routers set pollNonKeyPeer = on.
# valid values : on/off. default value : on.
pollNonKeyPeer = on
# to set slow polling timer set nonKeyPeerSleepTime = <number of seconds>.
# valid range of values : 0 to 65535 seconds. default value : 600 seconds.
nonKeyPeerSleepTime = 600
# to turn on circuit polling of dlsw key routers set pollKeyCircuit = on.
# valid values : on/off. default value : on.
pollKeyCircuit = on
# to set circuit polling timer set keyCircuitPollSleepTime = <number of seconds>
# valid range of values : 0 to 65535 seconds. default value : 1200 seconds.
keyCircuitPollSleepTime = 1200
# to set number of threads for polling key router peer connections set
# numKeyPeerPollThreads = <number>.
# valid range of values : 1 to 10. default value : 5.
numKeyPeerPollThreads = 5
# to set number of threads for polling non-key router peer connections set
# numNonKeyPeerPollThreads = <number>.
# valid range of values : 1 to 10. default value : 1.
numNonKeyPeerPollThreads = 1
# to set number of threads for polling key router circuits
# set numKeyCircuitPollThreads = <number>.
# valid range of values : 1 to 10. default value : 1.
numKeyCircuitPollThreads = 1
# to set sleep time for directed poll set
# directedPollSleepTime = <number of seconds>.
# valid range of values : 0 to 65535 seconds. default value : 0.
directedPollSleepTime = 0
# to set action to take when peers are down set
# peerDownAction = <executable Name>
# valid values : /path/executableName
# passed parameters : Local-Ip-Address Remote-Ip-Address
#peerDownAction =
# to set action to take when circuits are down set
# circuitDownAction = <executable Name>
# valid values : /path/executableName
# passed parameters : MacAddress1 SAP1 MacAddress2 SAP2
#circuitDownAction =
# to poll additional devices for dlsw
# peer connections at the rate of key-peer-poll and
# circuits at the rate of circuit-poll
# additionalPollRouterList = <router_name seperated by ', '>
# valid values : router1.name.com, router2.name.com
#additionalPollRouterList =
.
.[APPN parameters Deleted]
You can configure the DLSw application to generate event notifications (trap messages) when specific network events occur. These events can include device state changes, peer connection state changes, and changes to the status of a circuit. When a specified network event occurs, DLSw sends an event notification to the UNIX network management system.
Use the following event values in the cwbinit file to specify whether to send event notifications and to configure which events will cause trap messages to be sent.
After you configure the event notification options, DLSw will send trap messages to the network management system at your UNIX workstation. The "Event Notification Messages" chapter describes the trap messages sent by the Maps applications.
Use the processRestartInterval value to control how often, in seconds, the cwbdlswpollerd and cwbsnamapsd processes check to see whether some other process has requested that it recycle itself. Other CiscoWorks Blue processes make this request after APPN, TN3270, and DLSW discovery and rediscovery, and after DLSW key routers are assigned. The DLSw poller and cwbsnamapsd processes periodically check to see if a restart request has been made. The default value is 30 seconds.
You can configure how the DLSw application polls routers for peer connection information and for circuit information. You can select from the following polling methods:
If you make no changes, the DLSw polling daemon uses all three polling methods: it polls key routers and non-key routers for peer connection information, and it polls key routers for circuit information. You can change these selections using the following polling values in the cwbinit file.
additionalPollRouterList = routera.domain.com,routerb.domain.com
The peerDownAction and circuitDownAction event generation exits let you create your own exit routines to handle situations when key routers do not respond to polling for peer connection information and for circuit information.
Use the peerDownAction value to define a program to be run when routers do not respond to polling for peer connection information. Replace the string executableName with the name of your application. The poller daemon calls your application with the following command format:
user_application local_IP_address remote_IP_address
Where:
user_application is the name of the program that you supply.
local_IP_address is the IP address of the local peer.
remote_IP_address is the IP address of the remote peer.
Use the circuitDownAction value to define a program to run when key routers do not respond to polling for circuit information. Replace the string executableName with the name of your application. The poller daemon calls your application with the following command format:
user_application MACAddress1 SAP1 MACAddress2 SAP2
Where:
user_application is the name of the program that you supply.
MACAddress1 is the MAC address of the local peer.
SAP1 is the SAP of the local peer.
MACAddress2 is the IP address of the remote peer.
SAP2 is the SAP of the remote peer.
When your exit routine is invoked by one of these exits, it can do a number of things:
This section describes how to start the RSRB application. You can start the RSRB application either from the workstation system prompt or from a network management system, such as NetView for AIX.
The term network management system refers to NetView for AIX, HP OpenView, or Sun Net Manager on the network management workstation.
You can provide network information to RSRB in two ways. You can use the database maintained by a network management system, such as NetView for AIX, HP OpenView, or Sun Net Manager, or you can list all the network devices in a seed file. If you do not have a network management system, or if the network management system is not up-to-date and cannot be updated, or if you know the network management system database is so large that you do not want a map application to spend the time querying every device listed there, you can create a seed file. A seed file is a text file that lists the routers, and their read community strings, that you want to be recognized by a specific Maps application. Supply this seed file to the Maps application using the procedure in the section "Discovering the Network with a Seed File."
If you are using a network management system database, verify that the network management system has current data to share with Maps applications before you start RSRB. Even if the network management system is not running at this time, verify that it has been run recently in automanage mode or that you have run the discovery process at least once since the last installation of new routers or reconfiguration of existing routers. If you want to discover new routers dynamically as they come online, the network management system must be running in automanage mode continually.
To start the RSRB application from a system prompt, enter the command shown below:
cd /opt/CSCOcb/bin
./cwb start rsrb
You can log in to a remote UNIX host from your own local UNIX workstation, export the remote host display to your local workstation, and then run the application from the remote host. To start the remote host's RSRB application from your local workstation, use the following procedure:
Step 1 At your local UNIX workstation, enter the following command:
xhost +
Step 2 Log in to the remote UNIX host.
Step 3 Set your DISPLAY environment variable to export the display from the remote host to your local workstation. Depending on which shell you are using, use one of the following commands:
export DISPLAY=IP_address:0.0
setenv DISPLAY IP_address:0.0
Step 4 To start RSRB, enter the following commands:
cd /opt/CSCOcb/bin
./cwb start rsrb
When you start RSRB, the cwb start rsrb command script automatically starts the monitor and poller daemons that monitor the changes in the network and update the database with the changes. When you exit the RSRB application, all daemons continue to run to maintain the database. If you want to stop them use the Process Manager, as described in "Using Process Manager".
There are several ways that the RSRB application can discover the routers in a network. You can provide a list of enabled routers in a special file called a seed file. Or you can let the Maps application get its information from the network management system database. The methods of discovery are described in the following sections:
Each record in the seed file can be either a comment or a router specification. You can list the routers in any order within the seed file.
A comment is a single line of text that begins with the pound (#) character, as shown in the following line:
# This line is a comment.
A router specification has one of the following formats:
router [ReadCommunityString]
or
router:[ReadCommunityString]
Use the following conventions for the router specification:
You can use the same seed file for all three Maps applications (DLSw, RSRB, and APPN). Although the DLSw application uses a third parameter on each router entry to identify a router as a DLSw key device, that parameter is ignored for the RSRB and APPN applications. The following lines are from a sample seed file:
# Seed file for CiscoWorks Blue Maps applications
# Next is a non-key router with goldilocks read community string
east.cisco.com goldilocks
# Next is a non-key router with default read community string
172.18.7.47
# Next is a key router with default read community string
west.cisco.com:*:key
# Next is a key router with a read community string
east.cisco.com:readstring:key
To use a seed file for discovery, use the following procedure:
Step 1 Use a text editor to create the seed file. Save the seed file, for example with the name rsrbseed.
Step 2 Start RSRB and select Admin>Discover>Seed File to display the Seed File Discover window.
Or you can use the CiscoWorks Blue Administration application (cwbadmin) described in "Using the Administration Application."
Step 3 Enter the name of the seed file, verify the correct read community string, and click Discover. Discovery takes place while you wait.
After loading the database using the seed file, the application operates normally until a router is taken off line or a new router is configured. If a new router is added to the network, you can perform one of the following tasks:
The network management system maintains a database that includes all SNMP-managed routers in your network. You can use that database to provide the Maps application with the information that it needs to discover the routers in the network.
To have the RSRB application discover the network from the network management system database manually, select Admin>Discover>Database from the Maps application menu bar. The Maps application adds the routers found by the network management system to the database. The Maps application checks the database for new routers, polls their MIBs, and updates the database with the new MIB information.
You can have Maps check the network management system database automatically. This is called automatic discovery mode; you might want to use it if you expect to install or reconfigure routers often. To use automatic discovery mode, use the cwb start cwbdiscover command as a UNIX cron job (a chronologically started job) job. Set the cron job to run at night or when system and network activity are low.
If you want to add only one or a few routers to your network, you can discover each router individually by using the following procedure:
Step 1 Select Edit>Add Device(s) from the menu bar.
Step 2 When prompted, enter the router's device name and its read community string.
Step 3 Click OK.
The Maps application adds the router to the database, polls the router's MIB, and adds the MIB information to the database. Watch the status area to see a message that indicates the success or failure of this polling.
It is sometimes useful to rediscover an RSRB router, especially if one of the following events occurs:
To rediscover individual routers you can select Edit>Rediscover Device(s) from the RSRB menu bar.
You can start the APPN application from the workstation system prompt, from a remote workstation, or from a network management system, such as NetView for AIX. Before you can display APPN resources, you must have access to a network topology agent that collects and stores the information. A network topology agent is an APPN network node that provides information about the backbone APPN network. You can specify a network topology agent in one of the following ways:
You can start APPN from any valid user account. The installation process establishes a sample default user account named cwblue. The user cwblue does not have a starting password. You can either assign a password to cwblue or log in as root and change to cwblue.
To start the APPN Maps application from a workstation system prompt, enter the following commands:
cd /opt/CSCOcb/bin
./cwb start appn [-f devicename [-r read_community_string]] [-v]
Where:
-f devicename specifies the host name or IP address of an APPN node to be used as the network topology agent.
-r read_community_string specifies the read community string for the router specified by devicename. APPN uses the read_community_string value when communicating with an APPN node. If you do not enter a read community string, the APPN application uses the default read community string specified in the cwbinit file or, if there is not one there, the default string "public."
-v displays version information.
-v displays online help.
You can log in to a remote UNIX host from your own local UNIX workstation, export the remote host display to your local workstation, and then run the application from the remote host. To start the remote host's APPN application from your local workstation, use the following procedure:
Step 1 At your local UNIX workstation, enter the following command:
xhost +
Step 2 Log in to the remote UNIX host.
Step 3 Set your DISPLAY environment variable to export the display from the remote host to your local workstation. Depending on which shell you are using, use one of the following commands:
export DISPLAY=IP_address:0.0
setenv DISPLAY IP_address:0.0
Step 4 To start APPN, enter the following commands:
cd /opt/CSCOcb/bin
./cwb start appn [-f devicename [-r read_community_string]] [-v] [-h]
Where:
If you start APPN from NetView, or if you do not enter any options with the cwb start appn command, the APPN application looks in its preferences file, /opt/CSCOcb/etc/cwbinit, for the control point (CP) name, or for an IP address or device name (and read community string) of a network topology agent. If a network topology agent is not specified in the cwbinit file, APPN polls all discovered APPN routers and does not use a network topology agent.
This section describes how you can select a network topology agent, which is an APPN network node that provides information about the backbone APPN network.
When you first start APPN, you can select a network topology agent by its host name or IP address and its read community string. Enter the device name or IP address in the Device Name field, and enter the read community string in the Read Community field. The device name and read community string are both case-sensitive. Click OK.
If the APPN application has already learned the IP address or device name and the read community string of the network topology agent, you can enter just the network topology agent's control point (CP) name. In the APPN CP Name field, enter the CP name of a network topology agent and click OK.
You can discover a network topology agent even though you do not know the host name, IP address, or CP name. Click Discover (option) and then use the following procedure:
Step 1 Select either Database or Seed File in the Source field.
If you select the Database option, APPN uses the network management system database to get a list of devices to discover.
If you select the Seed File option, APPN prompts you to enter the name of a Maps seed file.
Step 2 In the Method field, select either Discover One to discover just one network topology agent, or select Discover All to discover all APPN network topology agents. This discovery also saves the correlation between each device's IP address and CP name.
Step 3 Click OK.
This section describes the APPN discovery process and includes the following sections:
The APPN application performs several kinds of discovery:
APPN identifies nodes using their APPN names, which are in the form NETID.CPNAME. NETID is the network ID; CPNAME is the control point name. To query and collect management data from nodes, APPN must also know the IP address for each node (because the APPN application manages APPN nodes using the SNMP protocol).
The process of finding an IP address for each APPN node is called discovery. APPN starts with the APPN CP name for each node. Then it discovers the IP address by prompting you to enter an IP address or device name (and read community string) for each CP name the first time that you request a view. The APPN application maintains this correlation between IP address and CP name for subsequent sessions.
To avoid being prompted for IP addresses or host names, you can perform a one-time discovery of the entire APPN network. For APPN, this discovery is the process of querying all IP devices in the network to determine whether they are also APPN network nodes, and, if so, to get their APPN names.
The APPN application stores the correlation data in a binary file named
/opt/CSCOcb/etc/appnfile. You should not edit this file, but you can delete it to force the APPN application to lose all its correlation data and rediscover the network. You can delete this file to force rediscovery when CP names or IP addresses are changed or reassigned.
You can launch the discovery process by selecting Admin>Discover item on the menu bar or from a network management system.
You can launch the discovery process from the Admin menu in two ways:
This process discovers all the devices in the seed file or database. After discovery is complete, select View>Global to display the global view with the network topology agent.
We recommend that you not launch the discovery process using a network management system because the network management system selects a topology agent at random. It is better to explicitly select a topology agent or to use a seed file of network nodes from which to select a network topology agent. APPN queries the devices from the seed file in the order in which they are listed. You can launch discovery using a network management system to correlate the IP addresses with CP names for the remaining nodes.
Each record in the seed file can be a comment or a router specification. You can list the routers in any order within the seed file, but the order of routers in the seed file determines the order in which the routers are discovered to select a network topology agent.
A comment is a single line of text that begins with the pound (#) character, as follows:
# This line is a comment.
A router specification has one of the following formats:
router [read_community_string]
or
router:[read_community_string]
Use the following conventions for the router specification:
The delimiter can be a space or a colon (:).
router can be either a host name or an IP address of a router in the network.
read_community_string is the read community string for that router. To use the default string (public), you can omit the read_community_string or you can use just an asterisk (*) as a place holder for the default read community string. If a read community string is missing for a device, the APPN application uses the default read community string specified by the rdcommstr parameter in the cwbinit file. You can create the APPN seed file with a text editor, and then save it as the appnseed file. The recommended location for the seed file is $HOME/.appn/appnseed.
You can use the same seed file for all three Maps applications (DLSw, RSRB, and APPN). Although DLSw has a third parameter on each router entry to identify a router as a key device, that parameter is ignored for the APPN and RSRB applications. The following lines are from a sample seed file:
# Seed file for CiscoWorks Blue Maps applications
# Next is a non-key router with goldilocks read community string
east.cisco.com goldilocks
# Next is a non-key router with default read community string
172.18.7.47
# Next is a key router with default read community string
west.cisco.com:*:key
# Next is a key router with a read community string
east.cisco.com:readstring:key
To use a seed file to provide the information to the application, use the following procedure:
Step 1 Use a text editor to create the seed file. Save the seed file, for example with the name appnseed.
Step 2 Start APPN and select Admin>Discover>Seed File. to display the Seed File Discover window.
You can use the CiscoWorks Blue Administration application (cwb start admin command) described in "Using the Administration Application."
Step 3 Enter the name of the seed file, verify the correct read community string, and click Discover. Discovery takes place while you wait.
After loading the database using the seed file, the application operates normally until a router is taken off line or a new router is configured. At that time, you can perform one of the following actions:
The cwbinit file contains a set of startup options and variables for the APPN application. However, if you start APPN with command-line options, the command-line options override the options set in the cwbinit file.
These APPN parameters in the cwbinit file are used only when you issue the cwb start appn command. If you change the cwbinit file while the APPN application is running, you must stop and restart the APPN application to activate the changes in cwbinit.
To reset the APPN application, select File>Exit Program from the APPN menu bar. Then restart the APPN application using the following command:
cd /opt/CSCOcb/bin
./cwb start appn
For each variable that you set in cwbinit, ensure that there is a space before and after the equal sign. For example, to turn off the eventgen variable, you would enter the following line in cwbinit:
eventgen = off
Each APPN user can have a private cwbinit file. If the APPN application cannot find the file $HOME/.cwbinit, it uses the file /opt/CSCOcb/etc/cwbinit. You might want to use a set of private cwbinit files to monitor different APPN networks from different user IDs.
The following shows a sample cwbinit file stored during installation of
CiscoWorks Blue Maps:
# Cisco Works Blue Maps and SNA View preferences file
# CWBlue applications first check for a user-customized version of
# this file as $HOME/.cwbinit. If the file is not found there, they
# use the installed version at $CWBROOT/etc/cwbinit.
# RULES:
# Keywords must start in column 1.
# There must be a space on each side of the = character.
# Everything on the right of the = character is taken as the value contents.
# Comments must start with # in column 1 only.
# Comments cannot be included on lines with keywords and values.
# Blank lines are ignored.
# [cwbsnamapsd section deleted]
# ************************************************************************
# These parameters are only read at startup time by the DLSw poller
# (cwbdlswpollerd) and APPN applications (cwbsnamapsd and appn).
# ****************************************************
# *** Global parameters used by both DLSw and APPN ***
# ****************************************************
# This parameter controls how often cwbdlswpollerd and cwbsnamapsd will
# check to see if another process has requested that it recycle itself.
# Other processes make this request after APPN, TN3270, and/or DLSW
# discovery/rediscovery and after DLSW key routers are assigned. The DLSw
# poller and cwbsnamapsd processes periodically check to see if a restart
# request has been made. The value supplied is in seconds.
processRestartInterval = 30
# to turn off event generation set eventgen = off.
# valid values : on/off. default value : on.
eventgen = on
# to turn on device state change event generation set eventgen_device = on.
# valid values : on/off. default value : off.
eventgen_device = off
.
. [DLSw parameters Removed]
.
# ***********************
# *** APPN parameters ***
# ***********************
# These parameters are used by both appn and cwbsnamapsd. If either
# are already running, they must be stopped and restarted for changes
# to take effect.
# Selection of the network topology agent is done in this order:
# 1) command line parameters, if any;
# 2) parse this config file.
# 3) user will be prompted to run discovery or enter agent information
#
# #3 applies to appn only. No prompt dialog is given in cwbsnamapsd.
# network topology agent ip address or device name (NOT appn cpname)
nettopoagentdevname =
# network topology agent read community string
nettopordcommstr =
# network topology agent APPN control point name (NETID.CPNAME format)
nettopoagentcpname =
# backup network topology agent ip address or device name (NOT appn cpname)
backupnettopoagentdevname =
# backup network topology agent read community string
backupnettopordcommstr =
# backup network topology agent APPN control point name (NETID.CPNAME format)
backupnettopoagentcpname =
# default read community string
rdcommstr = public
# automatic collection of local topology (NONE, NN_ONLY, ALL)
autolocaltopo = ALL
# network topology polling interval, in seconds
nettopopoll = 15
# backup network topology polling interval, in seconds
# (in backup mode only, when primary agent fails, backup uses nettopopoll)
backupnettopopoll = 600
# local topology polling interval, in seconds
loctopopoll = 600
# control whether appn polls the DLUR PU table as part of local topology
# polling. To turn off polling for PUs, set appn_pu_polling = off
appn_pu_polling = on
# control whether appn polls the APPN port table as part of local topology
# polling. To turn off polling for ports, set appn_port_polling = off
appn_port_polling = on
# control whether appn polls the APPN link table as part of local topology
# polling. To turn off polling for links, set appn_link_polling = off
appn_link_polling = on
# This option controls TG event generation.
# To turn off TG event generation, set eventgen_tg = off.
# To generate event for existing TGs when an operational state change
# is detected, set eventgen_tg = on.
# To generate events for existing TGs when an operational state change
# is detected and for newly created operational (active) TGs,
# set eventgen_tg = all.
# Exception: No events are generated for TGs created on
# the first poll cycle. This avoids a storm of events during
# process startup.
# valid values: on/off/all
eventgen_tg = on
# to turn off dlur session event generation set eventgen_dlur = off
# valid values : on/off
eventgen_dlur = on
# to turn on port event generation set eventgen_port = on
# valid values : on/off
eventgen_port = off
# to turn on link event generation set eventgen_link = on
# valid values : on/off
eventgen_link = off
# This option controls the CWBlue cache deletion of TGs that are no longer
# reported by local topology agents. A Cisco IOS change was made to delete
# inactive dynamic TGs from the router database.
# To delete TGs that are no longer reported by the agent,
# set this parameter to 'off'.
# To keep those TGs in the CWBlue cache, set this parameter to 'on'. If TG
# events are enabled, this will trigger an event if the TG becomes
# operational again.
# valid values:on/off
keep_deleted_tgs = off
You can use the cwbinit file to specify a topology agent in one of the following ways:
If you specify a network topology agent in the cwbinit file, you can also specify a backup network topology agent in the cwbinit file. Specify the backup network topology agent in one of the following ways:
If APPN cannot collect network topology from the agent you identify, it tries again using the interval specified by the nettopopoll variable in the cwbinit file.
Use the processRestartInterval value to control how often, in seconds, the cwbdlswpollerd and cwbsnamapsd processes check to see whether some other process has requested that it recycle itself. Other CiscoWorks Blue processes make this request after APPN, TN3270, and DLSW discovery and rediscovery and after DLSW key routers are assigned. The DLSw poller and cwbsnamapsd processes periodically check to see if a restart request has been made. The default value is 30 seconds.
Network topology polling is the periodic collecting of data from the network topology agent. Local topology polling is the periodic collecting of data from each APPN node.
Because the overhead of network topology polling is less than the overhead of local topology polling, the APPN application performs network topology polling more frequently than local topology polling. To control the frequency of polling, use the nettopopoll, loctopopoll, and backupnettopopoll parameters in the cwbinit file.
You can use the appn_pu_polling parameter to control polling for PU information. If you set appn_pu_polling = on, APPN polls for PU information at the interval specified by the loctopopoll parameter. The appn_pu_polling parameter affects polling only; it does not affect the collecting of local topology when you select Get Local Topology from a popup menu.
The APPN application collects and stores local topology data collected from an APPN node. The APPN application usually collects local topology data on demand, such as when the generation of a view requires it. To expedite the generation of some views, and to assure the completeness of adjacent-node views, set the autolocaltopo parameter to one of the following values:
You can configure the APPN application to generate event notifications (trap messages) when specific network events occur. These network events can include changes to a transmission group's state, changes to a DLUS-DLUR session state, and changes to the status of a node, a port, or a link. When the specified network event occurs, APPN sends a trap message to the network management system.
Use the following event values in the cwbinit file to specify whether to send event notifications and to specify which events will cause trap messages to be sent:
After you configure the event notification options, APPN will send trap messages to the network management system at your UNIX workstation. The chapter "Event Notification Messages" lists the trap messages sent by the Maps applications.
Use the keep_deleted_tgs=on value to keep inactive TGs in the Maps and SNA View cache. The Cisco IOS software deletes inactive dynamic TGs from the router database. If you want to keep those inactive TGs in the Maps and SNA View cache, set the keep_deleted_tgs=on option in the cwbinit file. If you want to delete those inactive TGs from the Maps and SNA View cache, set the keep_deleted_tgs=off option in the cwbinit file.
Posted: Thu Sep 9 08:58:16 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.