Conference netcad::hub_mgnt

2634.0. "Backup, Restore, and Copy utility for DEChubs" by SLINK::HOOD (Maine state bird: The black fly) Fri Aug 11 1995 18:09

Coming soon will be a new clearVISN software product which will save config-
urations of DEChubs and DEChub modules (and maybe GIGAswitches), and be able 
to restore those saved configurations.  Version 1 will be available soon. 
[To find out what "soon" means, you need to talk to the product manager, 
Jack NAC::Forrest.]

Attached below is a user-level perspective on what this product is and what 
it does.  

+--------------------------------------------------------------------+
| DO NOT READ THIS DOCUMENT UNTIL YOU AGREE TO THE FOLLOWING TERMS:  |
+--------------------------------------------------------------------+
|   (1) THIS IS NOT AN SPD!  An engineer (me) wrote this based on    |
|       what he thinks might be in the shipping product.             |
|   (2) ALL INFO IN HERE IS SUBJECT TO CHANGE!   The product is not  |
|       quite ready to ship, so we might move or change some features|
|       at the last minute.                                          |
|   (3) DO NOT GIVE THIS DIRECTLY TO CUSTOMERS!  For reasons, please |
|       see (1) and (2) above.                                       |
+--------------------------------------------------------------------+
So, you agree to those three items?  OK, read on...  

Your comments are welcome.  Please send them to Jack or to me.

And don't forget... You agreed to the three conditions!

- Tom Hood





+--------------------------+
| Backup & Restore Utility |
|   Overall Description    |
+--------------------------+

Official Product Name:
   Not yet decided, but it will not be Backup and Restore.  This document
   refers to it as "B&R", which is also not its real name.  Expect
   something like "ClearVISN Resilience" or some such thing.


Brief Description:
   B&R is a utility program which performs the following functions for 
   supported devices:
    - Backup some or all parameters from a network device to a file 
      on the workstation or PC.
    - Restore some or all saved parameters from a file into a selected
      network device.
    - Copy some or all parameters from one network device to another
      network device of a similar kind.

   B&R is a standalone application which may be invoked through HUBwatch.  
   B&R is not a HUBwatch component, but is a separate software product.

Definitions:
   Backup:      Read parameters from a network device, and write those 
                parameters to a file on the workstation or PC.
   Restore:     Read network device parameters saved in a file on the 
                workstation or the PC, and write them to a network device.
   Copy:        Read parameters from one network device, and copy those
                parameters to a different network device.  B&R implements
                the copy function as a backup followed by a restore.
   Subset:      A logical group of network device parameters that may be
                backed-up or restored as a set.  Typical subsets may include
                spanning tree parameters (for bridges/switches), security
                parameters (for repeaters), and so forth.
   Network Device: An SNMP-manageable device connected to the network,
                such as a DEChub 900, a DEChub module, or a GIGAswitch/FDDI.
   Family:      A group of one or more network devices which share similar
                backup and restore characteristics, such that information
                backed-up from one member of the family may be restored
                or copied to another member of the family.  For example,
                the DECswitch 900EF and the PEswitch 900TX are in the same
                family because of their similar port LAN technologies and
                overall architecture.
   SavedData File: The PC or workstation file created by a backup
                operation.  This file contains the names, instances, and
                values of the SNMP MIB variables read from the network
                device, as well as a list of the subsets backed-up, 
                information about the network device, and other data.  
                This is an ASCII (human-readable) file which is read by
                the B&R utility during a restore operation.
   Supported Device: A network device which is recognized by the B&R
                utility.  Only supported devices may be backed-up or
                restored.


Product Roll-Out:
   There will be at least two releases of B&R:
   VERSION 1.0:    <soon>
        NETWORK DEVICES:
           Support for the following network devices:
           - DECbridge 900MX.  Standalone and in DEChub 900.
           - DECrepeater 900, all variations. Standalone & in DEChub 900.
           - DECconcentrator 900, all variations. S/A & in DEChub 900.
           - DEChub 900 chassis
           - DECmau 900TH and 900TL, S/A & in DEChub 900.
           - DECrepeater 90, all variations. In DEChub 900 only.
           - DECrepeater 900, all Ethernet variations. S/a & DEChub 900.
           - DECrepeater 900TL, 900SL, 900FL (Token Ring) in DEChub 900.
           - DECswitch 900EE and 900EF.  Standalone & in DEChub 900.
           - GIGAswitch/FDDI (*** support likely, but not committed ***)
           - PEswitch 900TX.  Standalone & in DEChub 900.
           - RoamAbout Access Point (Standalone & in DEChub 900)
           The following network devices are NOT supported in version 1:
           - DECagent 90
           - DECbridge 90 and 90FL
           - DECrepeater 90 modules in DEChub 90 backplane.
           - DECserver modules
           - DEChub 90
           - All router and brouter modules.
           - GIGAswitch/ATM

        PLATFORMS:
           Version 1 will be supported on Microsoft Windows (PCs) and on
           Digital UNIX (Alpha) and OpenVMS VAX.
           The first release at first ship will NOT support Windows 95,
           Windows NT, SunOS or HPUX.

           For the Windows version, this product's kit will not include any
           any IP stacks, although it will be tested against all major
           IP stacks.

   VERSION 2.0:    <later>
        Additional support for application launch to perform backup and
        restore functions for the new routing family of modules, including 
        routing code for the DECswitch 900's, RouteAbout modules, etc.

   Beyond these two versions, minor versions of B&R will ship with each wave 
   of hub products.  These minor versions will mostly just add backup/restore 
   script support for new devices, and are not expected to change the B&R 
   utility itself.

Supported Device Requirements:
   B&R requires that a device implement the sysObjectId variable from SNMP 
   MIB-II.  This MIB variable is used by B&R to determine device type, and is 
   used as a pointer to the device-specific backup script and restore script.  
   Additionally, there must be (Digital-supplied) backup and restore scripts
   written for the device, and the device must appear in the B&R master file.


User Interface:
   B&R has two interfaces:  A GUI (for both Windows and Motif) and a command 
   line interface (CLI).  The GUI is the expected interface to the product. 
   The CLI exists so that B&R functions can be accumulated to a batch queue 
   or a command procedure, for execution at some other time.  Although the CLI 
   is quite cryptic, the B&R can automatically generate CLI commands.

   The B&R interface is modeled after a traditional disk backup and restore 
   utility.  Analogies:

                Disk Backup                     B&R
           ----------------------------    ----------------------------    
           Select a disk to backup         Select a network device to backup
           Select whether a full disk      Select whether all parameters of
              backup should occur, or         the device should be backed-up,
              just certain directories        or just certain subsets of
              or files.                       params (adrs filters, etc)
           Select the saveset/tar file     Select the SavedData file where
              name where the data will        the data will be stored.
              be stored.
           Using a saveset/tar file,       Using a SavedData file, select
              select whether a whole disk     whether all device parameters
              will be restored, or just a     to be written to a device, or
              few files or directories.       just subsets of params.


Components of B&R:
   B&R consists of several components, listed below:
    - The B&R Utility.  This is the GUI, a script compiler, a script
      interpreter, SNMP libraries, and other associated components.
    - Script files.  Script files contain backup and/or restore scripts
      written in the special B&R Language.  Each supported network device has 
      a backup script and a restore script which contains the directions for 
      backing up and restoring its device parameters.  As new hardware is 
      developed, script files for that hardware will also be developed.  [The 
      B&R Language description will be shipped with B&R.  Although officially 
      unsupported, smart customers may be able to write their own backup and 
      restore scripts for various devices.]
    - Master File:  This file is used to map sysObjectId's to device type to 
      backup script to restore script.
    - SavedData Files:  Data backed-up with B&R is written to a file (name and
      path are user-determined). The contents of this file are human-readable.

To Perform a Backup:
   To perform a backup (saving the configuration of a network device to a 
   file), the following procedure is used:
    - The user selects (by IP/Community) a network device to be backed-up.
      The device can be a module in a hub, a standalone module, or a DEChub 
      900.  If the device is a DEChub 900, the MAM and all the modules within 
      the hub are selected. 
    - The B&R GUI issues an SNMP GET request to the selected device to get the 
      sysObjectID variable.  It then uses the returned value of the sysObjectID 
      to determine the following information:
                - Is the device a supported B&R network device?
                - What kind of device is this?
                - What backup subset options are available for this device?
      (If the device is a DEChub 900, B&R then issues another SNMP request
      to build a list of which modules are in the hub.)
    - For supported devices, the GUI then displays the backup subset options 
      for the device (or devices, if a DEChub 900).  By default, a "full" 
      backup for each supported device is selected. 
    - The user then selects the following:
                - The filename for the saved data.
                - The backup subset options desired.
    - When the user hits the "OK" button, the B&R utility then performs the
      selected backup operations.  Status is written to a logfile and
      displayed in a B&R window.


To Perform a Restore:
   To perform a restore (from a SavedData file to a network device), the 
   following procedure is used:
    - The user selects (by IP/Community) a network device to be restored.
      The device can be a module in a hub, a standalone module, or a DEChub 
      900.  The user also enters the filename which contains the saved data 
      for the device.
    - The B&R GUI issues an SNMP GET request to the selected device to get the 
      sysObjectID to determine the device type.  If the device is a DEChub 900, 
      the MAM and all the modules within the hub are selected; the user can
      select whether to restore the entire hub, a particular slot in the hub, 
      or the MAM (slot=0).  
    - The B&R then uses the SavedData file to determine which restore subset 
      options are available to the device.  (If a device has the following as 
      backup subset items: full, A, B, and C, and if the user backed up only 
      subsets A and C, then only A and C are available for restore.)
    - The user selects which subsets (and which devices, if a hub) are to be 
      restored, and presses the OK button.
    - B&R then reads the data stored in the SavedData file, and issues SNMP
      SET requests to load the network device with the appropriate saved
      data from the file.  Status is written to a logfile and displayed in
      a B&R window.


To Perform a Copy:
   Because B&R implements the copy function as a backup followed by a
   restore, the user actions are a combination of the two operations.  B&R
   will make it appear to the user as a single operation.

    TOm - a very big THANK YOU  for posting this note!  It's nice to have a
    'heads up' abotu what the future is so we can help deal with it at
    least semi-accurately.
    
    Hurrah for Tom!
    
    Regards,
    j
    

    
    As I demonstrate the DEChub product to customers, more and more I get
    puzzled looks from the really technical members of the audience. When I
    demonstrate the power down function and restoration of all connections,
    they think this is great. However, when I pull a module and replace it
    with the SAME module (or LIKE module is a better term), they wonder why
    we can't SIMPLY restore the configuration the same was we do as if the
    whole hub experienced a power failure. They are not very swayed by the
    argument that if we pull a module that maybe we won't want the same
    configuration when putting a replacement module back into the same
    slot. Even so, they say, why not make the reconfiguration of the
    replaced module a hub wide option? So, if the customer has the restore
    config flag set to TRUE, if the same type of module is inserted, reload
    the configuration as if a hub power failure occurred. 
    
    So, the question is, how do I answer these questions? To start, the
    save and restore utility is not the answer in this case as it requires
    human intervention and the real *beauty* of our hubs is our hot swap
    capabilites and this is the one thing that make us fail the real hot
    swap ability.

This is what I've been and my customer has been complaining about. My customer
would like to see a removable flash card on the mam. So if the mam is replaced,
we just use the flash card to reload any configs. This is the main reason why we
don't sell many hub's into MCI. They are terrified that if a mam is replaced and
power is applied to the hub, the lan interconnects will default back to factory.
The only way around this is to pull all the modules and then load the mam.

.2  Tell your customers:

"Restoring a configuration after a module has been removed
and the same type of module inserted is a really good idea,
especially if the user has protection via a Restore-Config/
Don't-Restore button in Hubwatch.  It's such a good idea, in
fact, that our engineers are busy designing it into the
next release.  Thank you for your suggestions, what would we
do without you (indeed!)."

.3  No new MAM hardware planned for next release, sorry.

	- Dotsie

    re: .5
    
    My customer had a meeting with engineering a little more that 1 1/2
    years ago and told them they had to have some kind of strategy to fix
    the problem I stated in .3, they choose to ignore them, we lost the
    business to redesign their Software Development Center and many of
    their data centers lans. This was going to be several hundred hubs.
    

	in reply to .2 , you have already a REAL hot-swap 
capability with FDDI and auto-healing feature , as you can remove 
an FDDI module , plug back a module of the SAME kind , and 
the backplane connection will be automatically restored 
( look at Karl Pieper configuration guide in this Notesfile ) 

i have customers who like so much this feature they'd like it also
for Ethernet repeaters : as now , when you re-insert an Ethernet module , 
it is automatically restored to Thinwire ( for Tm and GM , i didnt tested it 
with PortSwitch ) and you have to delete this and restore to the right 
Ethernet VLAN with Lan Interconnect window : this can cause a lot of trouble 
as there is a chance for ethernet loop ( it happened in the customer plant ) 

as for .3 and .6 , i vote for MAM card  ( like for Decserver900 ) 
as i have same requirements for mission critical network . 

now , if i understand correctly "Resilience" option as described 
by Tom Hood , this could be achieved by one GREAT RESTORE_ALL  command , so that 
after replacing the failed MAM , you just have to give it an IP address 
and apply this magical "restore_all" command for MAM configuration . 

PJ

>	in reply to .2 , you have already a REAL hot-swap 
>capability with FDDI and auto-healing feature , as you can remove 
>an FDDI module , plug back a module of the SAME kind , and 
>the backplane connection will be automatically restored 
>( look at Karl Pieper configuration guide in this Notesfile ) 

>i have customers who like so much this feature they'd like it also
>for Ethernet repeaters

This is exactly what we're building for the next major release -
backplane configuration information is not deleted from the MAM
when a module is removed, and if the module put in that same slot
is the same type of module, the configuration is restored to it.  
We're calling it module autorestore.  It's slot oriented, not 
whole-hub oriented, and if you reset the MAM while the module
is out, you've lost the configuration.  It's just an extension 
of hot swapping, as was said in the last note.  While you use 
Hubwatch to enable this feature, once enabled, Hubwatch does 
not need to be running.

Resilience has a higher mission - whole hub configurations can
be saved and restored to the original hub or to any number
of other hubs, thus saving a lot of repetitious setup.
Resilience serves the same purpose as .3 said he'd like a
flash card for, only better: you can more easily verify that
Resilience saved a configuration correctly than that a flash 
write to a card.

Other interesting differentiators:  Resilience exists, you can
sell it now.  Autorestore presumably will exist some months
away.  Flash cards are not on the drawing board at this time.
As always, specific product requests can be sent to the
product managers.

	Dotsie 

thanks dotsie for your reply ; it explains all 
and now we have a perfect picture :

auto-healing for FDDI
auto-restore for Ethernet 
resilience for backup/restore anything you need when you need it 

i guess Flash cards are not needed anymore 
( by the way , my prefered customer is not fond of the 
	flash cards for decservers and prefers
	a graphical utility like resilience which 
	allows for a better management of the products )

PJ