[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
|
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
3744.0. "Recovery Mgr: use caution when restoring in-band" by NETCAD::MOWER () Wed Jul 24 1996 16:29
ClearVISN Recovery Manager
Notes on maintaining NMS-to-IPS connectivity
The issue.
When performing a restore operation that involves either restoring the
hub900 settings and/or restoring a PORTswitch's� settings, you must be
very careful in your selection of hub900 IP Services (IPS) module�.
If you communicate from your NMS to your hub900 via out-of-band
communications, this issue does not apply to your situation, and you
can safely ignore this note.
When performing a backup operation, such considerations are not
necessary, as no module or hub900 settings are changed.
� For this note, the DECrepeater 900FP qualifies as a PORTswitch.
� The hub900 can have several modules configured for IP Services.
Disclaimers.
This note attempts to clearly explain the necessary considerations a
user of Recovery Manager must take to guard against a loss of
connectivity between their NMS, (station running Recovery Manager), and
the hub900's IPS module. This issue is also discussed in the Recovery
Manager printed documentation and on-line help. This note is offered
only as a supplement to those [more formal] documents.
It should be stated up-front that the problem discussed here is NOT due
to an oversight. Time / manpower / time-to-market considerations
prevented a solution that eliminates the problem. Additionally, it is
unknown if there even exists a solution that eliminates the problem.
If the precautions described in this note are too restrictive for you,
(or your customer), please contact the appropriate product manager with
your comments and input.
Adhere to these restrictions.
The general problem to be avoided is analogous to taking care that you
not saw off the [tree] limb you are sitting on. Specifically, the
problem to be avoided is performing a restore operation that [as an
intermediate state] interrupts connectivity between the NMS and the
hub900's IPS module.
The most common symptom of the problem is that a restore of a hub900 or
of a PORTswitch stalls for a long time, and then terminates with an
error. This stall is due to the loss of connectivity. After specified
timeouts, the restore operation will terminate with an error.
As stated earlier, the problem can only occur on a restore operation.
Specifically, the restore must involve one or both of the following:
- a restore of the hub900's settings
- a restore of a PORTswitch's settings,
if that module is the IPS module or if it is in the path
from your NMS to the hub900's IPS module.
If you intend to do the first type of restore, you must guarantee that:
- a restore of the hub900's settings
your path NMS-IPS must NOT use the hub900's backplane
If you intend to do the second type of restore, you must guarantee that:
- on a restore of a PORTswitch 's settings
the PORTswitch must NOT be in the path from NMS to IPS, (which
also means that the PORTswitch to be restored may NOT be the IPS
module).
Obviously, if you intend to do both types of restore, you must adhere to
both of the rules listed above, simultaneously.
How to implement the restrictions.
The simplest way to conform to both of the above rules it to perform
restore operations using out-of-band, (OBM), communication to the hub900.
If communicating to your hub900 out-of-band, none of the issues in this
note will apply to your situation.
If OBM communications are not possible, you must choose your NMS-IPS
path very carefully. Read on...
The next two sections explain the rules you should follow to avoid the
loss of NMS-IPS communication described above when communicating to the
hub900 in-band.
If communicating to the hub900 in-band, and restoring a PORTswitch.
When a restore of a PORTswitch is performed, the module's port groupings
are erased as an intermediate step in the restore.
You must guarantee that your path from NMS to hub900 IPS module does NOT
involve the PORTswitch being restored.
Note that even connecting from you NMS to the front panel of a PORTswitch
configured for IPS is inadequate when restoring that PORTswitch; (the
module's MAC is disconnected as an intermediate step in the restore).
The simplest way to achieve this is to not use PORTswitch modules for the
IPS module of the hub900.
An alternative solution is to configure several IPS modules for the
hub900 and use the appropriate IP address depending on which slot is
being restored. This solution is obviously more complex and much more
prone to error. Additionally, this method would, (in cases where you
have two PORTswitches, each an IPS module), prohibit doing a full
restore, since the IP address of PORTswitch A must be used to restore
PORTswitch B, and vice-versa.
If communicating to the hub900 in-band, and restoring the hub's settings.
When a restore of the hub900 is performed, the hub's backplane
interconnections are erased as an intermediate step in the restore.
You must be careful to guarantee that a connection between your NMS and
IPS will exist even after all backplane connections are erased.
Selection of your IPS module, and physical wiring of the hub to the
network backbone is critical.
When communicating in-band to your hub900, the following 2 rules should
be adhered to:
1. Select as the hub's IPS the module which has a physical front-panel
connection to the NMS.
2. Select as the hub's IPS the module which has a physical front-panel
connection to the network backbone.
If you have only one NMS, (that will remain connected at a fixed point),
use rule #1 for the hub that the NMS connects to, and use rule #2 for all
other hubs.
For example...
HUB-B
+---+---+---+---+---+---+---+---+
|1 |2 |3 |4 |5 |6 |7 |8 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | |IPS| | | |
+---+---+---+---+---+---+---+---+
|
|
NMS----. .---------------. |
| HUB-A | | |
+---+---+---+---+---+---+---+---+ -------------
|IPS| | | | | | | | ( )
| | | | | | | | | ( network )
| | | | | | | | | ( backbone )
| | | | | | | | | ( )
|1 |2 |3 |4 |5 |6 |7 |8 | ( )
+---+---+---+---+---+---+---+---+ -------------
|
|
|
+---+---+---+---+---+---+---+---+
| | | |IPS| | | | |
| | | | | | | | |
| | | | | | | | |
|1 |2 |3 |4 |5 |6 |7 |8 |
+---+---+---+---+---+---+---+---+
HUB-C
If you have several NMS stations connected to several different hubs, you
need to apply both rules #1 and #2 to all hubs. The simplest way to
achieve this is to select as IPS for each hub the module which has a
physical front-panel connection to the network backbone, and to only
connect NMS stations to those same modules.
For example...
HUB-B
+---+---+---+---+---+---+---+---+
|1 |2 |3 |4 |5 |6 |7 |8 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | |IPS| | | |
+---+---+---+---+---+---+---+---+
NMS---. | |
| | `---NMS
| .-----------------. |
HUB-A | | | |
+---+---+---+---+---+---+---+---+ -------------
| | | | | | | |IPS| ( )
| | | | | | | | | ( network )
| | | | | | | | | ( backbone )
| | | | | | | | | ( )
|1 |2 |3 |4 |5 |6 |7 |8 | ( )
+---+---+---+---+---+---+---+---+ -------------
|
|
|
+---+---+---+---+---+---+---+---+
| | | |IPS| | | | |
| | | | | | | | |
| | | | | | | | |
|1 |2 |3 |4 |5 |6 |7 |8 |
+---+---+---+---+---+---+---+---+
HUB-C
(An alternative way to apply both rules #1 and #2 is to define multiple
IPS per hub; however, this method presents the difficult problem of how
to know which IP address to use in a particular situation, and is
particularily error-prone).
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|