|
|
The Serial Configuration Upload Download (SCUD) 2.0 application supports configuration save and restore functionality over a serial interface for IPX/BPX/IGX switches. SCUD is used for disaster recovery and is freely available to Cisco WAN Manager (CWM) users with a support contract.
The Serial Configuration Upload Download (SCUD) 2.0 application has the following features:
The SCUD software will run on any Sun workstation running SunOS 4.1.x operating system. It can also be run on Sun workstation running Solaris 2.5 or 2.6 with binary compatibility support. The minimum memory requirement is 64MB. There is no special hardware requirement other than the required serial interface.
SCUD software is available on quarter inch tape in UNIX tar format. Following procedure needs to be followed for installation.
Step 1 Login on Sun workstation.
Step 2 Change directory to where you need to install SCUD (SCUD home directory). It is advisable to install SCUD in the /usr/users/svplus directory. For this you have to move any existing CWM installation in /usr/users/svplus to some other place before installing SCUD.
Step 3 Insert tape in the tape drive.
Step 4 Use tar command as shown below to get software loaded.
$ tar xvf /dev/<driveid> where driveid indicates the tape drive identifier
For example, rst0, rmt0 etc.
There is no install script to be run. The software is ready for use.
SCUD software uses two configuration files. Configuration file cnfnodes is used to specify the switch identification. Second file config.sv is similar to one used by CWM and contains the serial line configurations.
The cnfnodes file can have only one line with format shown below:
<nodename>|<switch_node_id>|<switch_net_id>|<SV+_netid>|
For example,
nmsipx02|2|1|1|
switch_node_id is node id of a switch.
switch_net_id is network (also called as domain) is of a switch.
SV+_netid is SV+ network id (from config.sv file)
The config.sv file can have only one line with following fields using a pipe ( | ) as delimiter:
SV+_netid NO NEED TO CHANGE
networkname NO NEED TO CHANGE
serialport Specify the device file name for the serial port used
Baudrate Set serial port speed to match speed of control port at the node; supports baud rates of 2400, 4800, 9600, 19200 and 38400
autodial Phone # to dial out including any prefix needed, 0 for not dialing
SV_Timeout NOT ALLOWED TO CHANGE
Retransmit NOT ALLOWED TO CHANGE
DL_Thresh_TO NOT ALLOWED TO CHANGE
DL_Ack_TO Set application level time-out value in seconds as appropriate
DL_Blk_Size Set transmission block size in bytes, no greater than 1024
Release Specify switch software release as appropriate
For example,
1|Network1|/dev/ttya|19200|0|7|3|0|30|256|9.2
If SCUD is running with SunOS system, no configuration is needed for the serial port. You only need to identify which tty (/dev/ttya or /dev/ttyb) is for SCUD to use.
If SCUD is running with Solaris system, you must run the system administration tool admintool to configure the serial port as Modem - Dial-Out Only. This tool can only be run by super user (root). The serial port device name to use in the config.sv file should be /dev/cua/a for ttya and /dev/cua/b for ttyb.
To configure the remote node control port, complete the following steps:
Step 1 Run the following command to set control port function as VT100/StrataView:
cnftermfunc c 1
nmsipx06 TN StrataCom IPX 8 8.1.50 Sep. 18 1997 19:16 PST
Control port Auxiliary port
1. VT100/StrataView 1. Okidata 182 Printer
2. VT1002. Okidata 18 2 Printer with LOG
3. VT100
4. Alarm Message Collector
5. External Device Window
6. Autodial Modem
Last Command: cnftermfunc c 1
Next Command:
Step 2 Run the following command to replace the port speed parameter (19200) to match the setting in config.sv:
cnfterm c 19200 n 8 1 x x y n
nmsipx06 TN StrataCom IPX 8 8.1.50 Sep. 18 1997 19:29 PST
Control port Auxiliary port
Baud Rate: 19200 Baud Rate: 9600
Parity: None Parity: None
Number of Data Bits: 8 Number of Data Bits: 8
Number of Stop Bits: 1 Number of Stop Bits: 1
Output flow control: XON/XOFF Output flow control: XON/XOFF
Input flow control: XON/XOFF Input flow control: XON/XOFF
CTS flow control: Yes CTS flow control: Yes
Use DTR signal: No Use DTR signal: Yes
Last Command: cnfterm c 19200 n 8 1 x x y n
Next Command:
We recommend that you use the modem settings for Motorola Codex 3220+. If you are not using this model, use the corresponding commands for your modem to configure the following settings:
AT&F Reset to factory default
ATS0=1 Enable auto-answer on first ring
ATL1 Modem speaker at low volume
AT*SM3 Enable automatic MNP error correction
AT*DC0 Disable data compression
AT*FL0 Disable XON/XOFF flow control
AT&S1 Sets DSR to normal
ATE0 Disable local character echo
ATQ1 Disable result codes (modem will appear dead)
AT&W Save current configuration settings
AT&F Reset to factory default
ATL0 Modem speaker at minimum volume
AT*SM3 Enable automatic MNP error correction
AT*DC0 Disable data compression
AT*SC1 Enable DTE speed conversion
AT*FL0 Disable XON/XOFF flow control
AT&C1 DCD controlled by modem
AT&D2 Modem disconnects when SCUD toggles DTR
AT&W Save current configuration settings
SCUD allows you to save and restore configuration from/to IPX/BPX/IGX switches. The configuration saved using Cisco WAN Manager is stored in the /usr/users/svplus directory using <saveid>_Cfgdir as directory name. To restore the saved configuration, copy this directory to the SCUD home directory.
For example, if SCUD is installed in the /usr/SCUD directory and the current saved configuration has saveid of SV72, copy the SV72_Cfgdir directory from /usr/users/svplus (or from other directory where files are manually copied) to /usr/SCUD directory.
To set up the SCUD Configuration file, complete the following steps:
Step 1 Change the cnfnodes and config.sv files to the required configurations:
Step 2 Change directory to where SCUD is installed.
Step 3 Set the environment variable DISPLAY to your workstation display.
% setenv DISPLAY :0.0 (for local display) % setenv DISPLAY mach1:0.0 (for remote machine name mach1)
$ set DISPLAY :0.0 $ export DISPLAY (for local display) $ set DISPLAY mach1:0.0 $ export DISPLAY (for remote machine name mach1)
Before launching SCUD, make sure the configuration files, the remote nodes control port, and the modems on both sides are configured properly.
To launch SCUD, enter SCUD on the command line and press Return.
When SCUD is launched you will see Node Administration window on screen. You can login to switch and use loadcnf command to restore the configuration. The configuration to be restored must have already been copied to the SCUD home directory.
You can make a modem connection using SCUD or another communications tool, such as tip.
This is enabled by putting the phone number in the config.sv file. The phone number can be prefixed by P or T for pulse or tone dialing. A comma is also allowed in this field for additional pause time. When SCUD starts, it will dial out from the modem and wait for it to connect before the actual applications are started. Messages are displayed at the start-up window to show the progression.
If SCUD fails to make the connection, it will retry indefinitely. If retries continue to fail, you should correct the failing condition and restart SCUD.
After the connection is established, the Node Administration window will appear. However, it may take a couple minutes before the nodes login prompt is displayed in the Node Administration window. This is because the node may send a lot of data out once the connection is established and SCUD has to filter them out. At this time, the RD light on the modem is almost solid on. Wait until this RD light is off, you should be able to get the nodes login prompt by hitting Return on the Node Administration window.
In some cases, you cannot establish the modem connection by simply dialing a phone number. For example, if the remote end modem connects to a terminal server, some commands have to be issued after the modems are connected to route the connection to the port that the remote node is on. Therefore, you must establish the connection manually before launching SCUD.
The modem should be setup in a way that it would not drop the line even when DTR is dropped. After you have established the connection using tools like tip, the remote node will start sending the command line interface screen data to the screen. These data include VT100 terminal escape sequence that looks like garbage. You should wait until these are cleared and the node's login prompt appears, then exit the tip session. Make sure the line is still up by checking the CD light on the modem.
Before launching SCUD, verify that in SCUD's configuration file config.sv, the autodial (phone number) field is set to 0. If this field is set to any valid phone number, SCUD will drop the line and redial that number. After SCUD is launched with the no dial out setting, the Node Administration window will appear right away and the node's login prompt will show up in seconds time.
If network ID in the config.sv file does not match with one from cnfnodes SCUD does not detect it.
SCUD may not be launched if CWM is running on the same workstation.
The protocol between SCUD and the remote node during a configuration save or restore session enforced a simple handshaking protocol that the sending side after sending a data packet, will wait for an acknowledgment (ACK) from the remote side before sending the next data packet. An application level time-out is imposed. When time-out on waiting the ACK, the sending side will send an ABORT message to the remote end and the operation is aborted completely. At the application layer, there is no retry capability. However, at the link layer, each packet will retransmit 3 times before giving up. Depending on the modem line quality, it could be so worse that the session keep aborting and never get completed.
In SCUD release 2.0, some enhancements are added to address this issue:
1. SCUD will perform retry on a configuration restore session (loadcnf). Configuration data is sent from SCUD to the remote node. When SCUD time-out on receiving the ACK, it will re-send the last data packet. By default, SCUD will try totally 3 times on the same packet before it gives up and abort the session. A -r <num> command line option can be given to configd in the start_SCUD script to specify the number of retries SCUD uses.
Please note that the retry is only performed by SCUD and it works only for a configuration restore session. For configuration save, there is no retry feature at all.
2. The Baudrate (port speed), DL_Ack_TO time-out value and the DL_Blk_Size values in SCUDs configuration file config.sv can be tuned to optimize performance and cope with line quality. For example, if the line quality is good, port speed and block size could be set to a higher value. On the other hand, when line quality is not so good, these 2 fields should be set to a smaller value while DL_Ack_TO should be set to a larger value to give sufficient time for link layer retransmission.
One can check the quality of the serial communication between SCUD and the remote node by running dspsv1 command at the node. This command will show any errors on the serial communication to and from the node. Time-out values at the remote node can also be configured by the cnfdlparm command and setting parameters #7 (Session Timeout) and #14 (Rmt Response TO).
Log files are stored in the log directory under SCUD home directory. Messages are appended to these log files continuously even when SCUD is restarted. When they grow to certain size, they are moved to *.old and new log files are used. When the new log files are full again, the *.old will be overwritten. In other words, only one backup is kept to prevent using up all disk space.
These log files are there to help debugging in case problems occur. You should save these files when there is problem. Otherwise, there is no need to backup these files.
There are some debugging capabilities built into SCUD as highlighted here:
1. Higher levels (L3 and L4) of verbose messages for log/svmain.log can be enabled at SCUD start-up time and toggled on/off during run time. To enable these levels of verbose messages at start-up time, modify the start_SCUD script to include -w command line option for socketd as follows:
#!/bin/sh # # $RCSfile: start_SCUD,v $ $Revision: 1.1.4.1 $ # # -f option for topod and configd need to point # the same file. # If there is a port conflict then change base # 4000 to some other number. socketd -b 4000 -c config.sv -g 560x342+1+90 -w << ! topod -e topo.err -f cnfnodes downld configd -C cnfnodes
L3 and L4 verbose messages for log/svmain.log can also be toggled on/off by sending SIGUSR2 signal to svmain process. The command is: kill -USR2 <pid> where <pid> is the process id of svmain.
2. Verbose mode can also be turned on for configd process which is responsible for the configuration save and restore operation in SCUD. Modify the start_SCUD script to give the -v command line option to configd:
#!/bin/sh # # $RCSfile: start_SCUD,v $ $Revision: 1.1.4.1 $ # # -f option for topod and configd need to point # the same file. # If there is a port conflict then change base # 4000 to some other number. socketd -b 4000 -c config.sv -g 560x342+1+90 << ! topod -e topo.err -f cnfnodes downld configd -C cnfnodes -v
The output for the verbose message from configd is stored in configd.verbose in the SCUD home directory. This file is overwritten every time SCUD is started.
At times, you may see the following messages:
ipc.c:598:IPC Connect Failed, Address(4001) PID(25409):: Connection refused topod: send_packet_2_IPX failed, retrying ... ipc.c:598:IPC Connect Failed, Address(4001) PID(25408):: Connection refused topod: send_packet_2_IPX retry succeeded.
This is generated by topod process when it could not communicate with another process due to the start-up time difference. This problem is fixed in SCUD 2.0 that topod will now wait for 1 second and retry until successful. Normally, it takes only one retry to succeed. As long as the retry succeeded message is shown, there is no problem and you do not need to restart SCUD. If the topod: send_packet_2_IPX failed, retrying ...message keep showing, it usually indicates a serious system problem. You may need to reboot the workstation to clear the problem.
If the phone line dropped or hung in the middle of a SCUD session, you must restart SCUD to re-establish the connection.
In the case that modem connection is made by tip or other communication tools, the re-established connection may appear to be dead (no prompt or any data), or showing some garbage. This is because at the remote node, it is still in StrataView mode so it would not send the VT100 screen data. You can launch SCUD as usual and SCUD would be able to communicate with the node in StrataView mode. However, if you want to make sure the connection is working, send the DEL character to the remote node by pressing the Del key on the workstation. This will toggle the node's control port function back to VT100 mode, and you should be able to see the nodes login prompt.
Posted: Wed Mar 31 15:20:36 PST 1999
Copyright 1989-1999©Cisco Systems Inc.