| Item #1 (splash screen border left on Windows95 display)
-also seen and PTR'ed by system test last week; lookin into. Will let
you know.
Item #2 (flexibility, in-band restrictions)
Out-of-band restores are the recommended method, and would also free you
of your in-band restrictions. In the online help, hit SEARCH, then
FIND help topic "Restoring PORTswitch and Repeater Internal LAN Port Groupings"
for an explanation of why PORTswitches cannot be in the connection path
between the nms and the IP Service module, nor should they be used as the
IP Services module.
A DECswitch-family device CAN be used as the IP Services module, but you
may need to increase your retry counts in the agents file. As the DECswitch
family of devices are bridges, a restore operation causes topology change
notifications over the bridge links. Depending upon which DECswitch device
and which physical port on the front panel of the DECswitch your nms is
attached to, your delay could be insignificant or as high as three minutes.
A quick explanation of this follows.
"Gotchas" with In-band restores using DECswitch900 EF/MX
as IP Services modules
----------------------
If the DECswitch has an FDDI port, its MAC address is used as the MAC address of
the whole bridge. If your point of attachment to the nms is to the front
panel FDDI port on the DECswitch, there should be very little or no delay. If
your point of attachment is to an Ethernet port, it has a different MAC
address than the FDDI port, and is treated like another bridge in the
topology. Therefore, Recovery Manager traffic won't get forwarded between
the FDDI and Ethernet links until the spanning tree
listening/learning/forwarding states have elapsed.
The above "gotchas" can be complicated and are specific to devices. The
DECswitch EE has Ethernet as its only physical media type, and won't
have this forwarding delay problem, for example.
This information caused us to declare that a "dumb" repeater be used
as the IP Services module, to avoid complication and connection delays.
Good question!
John Gillis
Recovery Manager developer
|