| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3713.1 | It's imperative to keep that function. | MSDOA::REED | John Reed @CBO = Network Services | Wed Jul 17 1996 02:00 | 12 |
| I use the port frequently (on behalf of my customers) to configure FDDI
or TOken ring hubs from my Laptop. I use the SLIP option of HUBwatch
from my laptop. It is also very handy for setting up the backplane LAN
segments and moving module LIGOs around without getting blown off of
the network.
I have used the port to dial into customer HUBs and manage them from my
office, when they have swapped out MAM cards, or gotten a configuration
messed up. It has saved me a lot of airfare and time.
JR
|
| 3713.2 | | CSC32::D_PERRIN | | Thu Jul 18 1996 15:29 | 2 |
| FWIW, at the U.S. CSC we haven't had any customer requests for more
modem functions on these ports.
|
| 3713.3 | OBM port on MAM is preferred method for clearVISN Recovery Manager | NETCAD::GILLIS | | Fri Aug 02 1996 20:13 | 11 |
| In the clearVISN Recovery Manager docs, we recommend that all Backups
(and especially Restores) be done via the OBM port. In-band management works,
but one has to be careful that the path from the nms to the managed devices does
not include backplane connectivity and some other "gotchas" specific to
the device the nms is connected to.
The OBM port is slower and requires a terminal server/SLIP connection if
not directly connected, but is the most reliable means of maintaining
connection between an nms and its managed devices
John Gillis
|
| 3713.4 | PPP Support? | SNOFS1::KHOOJEANNIE | Poles are the best post-impressionists | Mon Aug 05 1996 06:27 | 9 |
| Are we planning to implement PPP for the OBM port?
With Win 95, PPP is common but SLIP isn't ... and the clearVISN docs
seem to be missing in this area - for example, in the Configuration
and Use manual, there is a section on "Making a SLIP Connection Through
an Access Server" and "Making a SLIP Connection to a DECagent 90", but
there isn't a section on using SLIP to the DEChub 900 MultiSwitch OBM
port (?)
|
| 3713.5 | | NETCAD::MILLBRANDT | answer mam | Mon Aug 05 1996 18:30 | 4 |
| First request we've had for PPP. Hmm, interesting.
Thanks,
Dotsie
|
| 3713.6 | Lets Talk about the setup Port... | ZUR01::ACKERMANN | | Wed Aug 14 1996 15:33 | 41 |
|
Hello Shawn,
You are talking about the OBM Port. Why not talking about
really helpfull Features of the setup Port?
Would it be possible to implement a Telnet Session for direkt
Access to the MAM ?
Like implemented on the Terminal Servers in Hubwatch in the
ACCESS Server Summary Display.
Customers dont understand, why they have to connect a VT
Terminal to the setup Port to:
-Set or change the IP Address of the MAM or a Module
-Change the Community
-Change the Ip Service Module
-Dump Error Log of the MAM or a Module
and so on....
I think for the initial setup of the MAM, the setup Port is
ok. But for all the other things a Telnet Session would be
really helpfull. Specially in a large Environment or when
the Customer does the management over the WAN.
Ok, they can use a Terminal Server and then connect a Cable
to the setup Port. Then create a Reverse LAT Service and
connect like this.
But this needs more Equipment, like Cables, then they
loose a Port on each DECSERVER. If they connect over a WAN with
only Routers they need Bridging for the LAT Protocol,
and so on...
What do You think about this ?
Thanks and regards,
Daniel MCS Switzerland
|
| 3713.7 | Okay, lets chat... | NETCAD::GALLAGHER | | Thu Aug 15 1996 12:40 | 53 |
| Hi Daniel,
TELNET support is a touchy, controversial issue. But hey, I'll take my
turn as a target.
> You are talking about the OBM Port. Why not talking about
> really helpfull Features of the setup Port?
I was talking about the OBM port to see if it was worth planning some
development in this area. (PPP and better modem control for example.)
It doesn't appear to be a high priority. Certainly, "fixing" the setup
port seems more important.
> Would it be possible to implement a Telnet Session for direkt
> Access to the MAM ?
> Like implemented on the Terminal Servers in Hubwatch in the
> ACCESS Server Summary Display.
> Customers dont understand, why they have to connect a VT
> Terminal to the setup Port to:
>
> -Set or change the IP Address of the MAM or a Module
> -Change the Community
> -Change the Ip Service Module
> -Dump Error Log of the MAM or a Module
We agree that customers should not have to visit the hub in order to
perform these functions. However, I don't think TELNET is the answer.
The answer is to provide SNMP access to these objects, enabling a user
to use a ClearVISN "setup" application to change IP addresses, community
strings, etc. All the user should have to do is initially give the
Management Agent Module one IP address. (Same as would be required
before TELNET access.)
> I think for the initial setup of the MAM, the setup Port is
> ok. But for all the other things a Telnet Session would be
> really helpfull. Specially in a large Environment or when
> the Customer does the management over the WAN.
> Ok, they can use a Terminal Server and then connect a Cable
> to the setup Port. Then create a Reverse LAT Service and
> connect like this.
> But this needs more Equipment, like Cables, then they
> loose a Port on each DECSERVER. If they connect over a WAN with
> only Routers they need Bridging for the LAT Protocol,
> and so on...
We agree on this point as well. There are some good stories about hub
equipment installed in toxic environments (like Dow Chemical) where
it's inconvenient (understatement!) to visit the equipment to change
IP addresses, etc.
I've attached a paper on the subject as well. It's from a HTML document.
-Shawn
|
| 3713.8 | DEChub900 and DEChub600 Remote Configuration | NETCAD::GALLAGHER | | Thu Aug 15 1996 12:42 | 176 |
|
For Digital Internal Use Only
-----------------------------
DEChub900 and DEChub600 Remote
******************************
Configuration
**************
Last modified on $Date: 1996/07/23 20:01:04 $ by $Author: shawn $
This paper briefly addresses problems in the ability to remotely configure
DEChub900 and DEChub600 products. The intent of this paper is to circulate the
Hub Products Group's plan to address remote configuration. Please address
comments/concerns/feedback to Shawn Gallagher.
Problem Statement
==================
User's are sometimes required to visit the hub/stack and use the setup port
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
to configure IP and SNMP for management, perform firmware upgrades, and
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diagnose the hub/stack. Users should only be required to provide an IP
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
address (and optionally a subnet mask) to the Hub/Stack's Management
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Agent upon installation, and never have to visit the installation site again.
Even though some agent instrumentation exists, there's no ClearVISN Multi
Chassis Manager screen in which users can initiate operations such as:
configuring module IP addresses and subnet masks, configuring module SNMP
communities, configure trap destination addresses, read the error log, etc.
Some of the more visible manifestations of this problem are that users are
required to visit each installed hub/stack to:
o Configure an IP server.
o Change a subnet mask.
o Change the SNMP read-only or read-write communities.
o Assign an IP address to a module to upgrade it. (This is really a remote
configuration problem coupled with the fact that some modules do not
support MAM-assisted upgrades.)
Solution
========
The Hub Products Bussiness Group's strategy is to make everything
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
manageable via the SNMP. Providing remote configuration involves two areas
of development:
1. Provide access to all setup parameters in DEChub products via SNMP.
2. Provide a ClearVISN management application ("screen") which allows
users to setup DEChub products.
Implementation details are described in Remote Configuration Implementation
Details.
Providing SNMP Access to all Setup Parameters
+++++++++++++++++++++++++++++++++++++++++++++
Most parameters read and written from the console setup port can also be read
and written remotely using the SNMP. Some agent instrumentation (MIB
objects) need to be added. The bulk of the agent work will be in:
o Providing SNMP MIB objects to configure IP addresses and subnet
masks for out-of-band, in-band through IP-services, and module in-band
management.
o Implement an SNMP readable "Event Display Mode".
o Add miscellaneous objects for, "last load time", "Out-of-band
Management port speed", "Out-of-Band Management Port
Request-To-Send enable/disable", and "BootP Enable/Disable".
o Add "device specific" objects as required.
Providing a ClearVISN Screen(s)
+++++++++++++++++++++++++++++++
This application should provide the same level of functionality as is currently
provided by the console setup screens in the DEChub900 Management Agent
Module. Functions include:
o Reset with factory defaults.
o Reset with current settings.
o Show current settings.
o Configure IP and SNMP.
o Dump the error log.
o Downline upgrade. (Or launch a downline upgrade application.)
o Configure the out-of-band management port.
o View the error log.
Setup functions are discussed in DEChub900Lite Management Agent Module
Local Setup Port and DEChub900 Multiswitch Owner's Manual..
Issues: Security
================
A software switch will be added on each product. This switch is only accessible
from the device's console setup port. The "remote access" switch can have
values; no-access, read-only-access, and read-write-access. The default value
is read-write-access.
When "remote access" is no-access products behave as before. IP addresses,
subnet masks, SNMP security, etc., may only be set for the console setup port.
Remote access to these management parameters is not allowed. Attempts to
read or write these parameters cause SNMP errors to be returned.
When "remote access" is read-only-access or read-write-access, remote
access to the functions listed below is allowed.
o Reset with factory defaults.
o Configure IP and SNMP.
o Downline upgrade. (Or launch a downline upgrade application.)
o Configure the out-of-band management port.
The functions listed above can only be changed when "remote access" is
read-write-access.
A few miscellaneous points about security:
o Disabling all SNMP and BOOTP can be accomplished by disabling
Bootp and not configuring IP addresses. (But giving a hub or stacks
Management Agent Module an IP address means you'll never have to
visit it again.)
o Disabling all SNMP access can be accomplished by supplying
non-public SNMP read-only and read-write community strings.
o Disabling all SNMP management sets can be accomplished by supplying
a non-public SNMP read-write community string.
o Providing SNMP access only to specific IP address can be
accomplished by supplying the specific IP addresses in the
public-common MIB's pcomSnmpAuth group.
For example, you can specify that the device will respond only to set
requests with community "doubleSecret" from IP addresses 16.21.32.14
and 16.20.80.2. Or, you could specify that all stations on subnet 16.20.32.0
have access to the device.
o Users can only read SNMP read-write community information using the
read-write community.
o Information about last several unauthorized SNMP accesses can be read
from the public-common MIB's pcomSnnmpAuthUnauthTable.
References/Related Topics
=========================
o A description of the setup port on the DEChub900 and DEChub600
Management Agent Modules.
o DEChub900 and DEChub600 TELNET Support.
o The DEChub900 Multiswitch Owner's Manual..
|
| 3713.9 | Thanks, and two more Questions... | ZUR01::ACKERMANN | | Thu Aug 15 1996 15:54 | 23 |
|
Hello Shawn,
Thanks for Your fast and detailed Response. I think, Your Plans
to implement a Clearvisn "setup" application sounds interesting.
If You can provide Access to all the SNMP MIBs to have the
"full" setup Port functionality, this would be really helpful.
I think, with a functionality like this, the Customers would
be happy. It mus not be a Telnet Session, this was just an Idea,
how to do it.
But i see, there are also more Tasks, like Security and so on,
which have to be implemented to.
But, are there any Plans, when this "extended Setup Port Feature"
will be implemented in Clearvisn ? Or are You waiting on more
Feedback inputs to this from other peoples ?
Anyway, thanks a lot
Daniel MCS Switzerland
|
| 3713.10 | | NETCAD::GALLAGHER | | Thu Aug 15 1996 17:27 | 20 |
| Daniel,
> But i see, there are also more Tasks, like Security and so on,
> which have to be implemented to.
Security will consist of the ability to turn this "remote setup port"
feature off. (Oh, and the object to turn this on and off will be the
only object that's not remotely manageable.)
> But, are there any Plans, when this "extended Setup Port Feature"
> will be implemented in Clearvisn ? Or are You waiting on more
> Feedback inputs to this from other peoples ?
We feel we've gotten plenty of feedback on this. Although not everyone
likes the method - some still want TELNET - everyone seems to agree that
it's a problem we must solve.
However, there's no schedule for this. We have plenty of work to do
for the next wave of products.
-Shawn
|