| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hi team,
Attached, please find a letter from a coustomer of ours. Can anyone
help us with some answers and/or some pointers PLEASE??? I would
greatly appreciate any help and support.
Please fell free to give the names of key people that might be able to
help us answers as many of the questions as possible. I'm in need of
the answers ASAP.
As always, THANK YOU in advance for your support.
Regards,
Bob
PS: Please fell free to share this note with any other colleagues
that could possibly help.
To: Bob Joseph Cite: 2S7180-92-016
From: Ed Jackson 29 January 1992
Subject: DEC Equipment Information
Pursuant to our conversation last week, here are some concerns and
information needs we have with respect to DEC equipment.
Vitalink TransLAN 350 Remote Bridge
1. After studying the manual provided with this device we
concluded that it may not be appropriate for our usage. But
it may be that the information given is misleading.
The manual states that the warranty is not valid if the
bridge is used with a satellite data link. Since that is
precisely the intended use, we need to either validate that
statement and choose another device or show why the statement
does not apply and confirm that the bridge is suitable for
use with a satellite data link.
The disclaimer is made on page 4 of the Miscellaneous
Section.
2. The bridge apparently supports IEEE 802.1d Spanning Tree
Protocol and also the original Spanning Tree Protocol
introduced earlier by DEC. The manual would lead one to
believe that these two Spanning Tree Protocols cannot
co-exist in the same network segment. Our question is: Does
DEC offer a choice of Spanning Tree Protocols it supports on
the routers and work stations? We would prefer to use the
IEEE 802.1d standard if possible.
3a. The manual indicates that the bridge supports the Simple
Network Management Protocol (SNMP). Does it also support the
Common Management Information Protocol (CMIP) which is
specified as a component of GOSIP? More importantly, is it
compatible with the DECmcc Management Station software
specified in our contract?
3b. The manual mentions the Vitalink Management Program (VMP) and
the WANmanager program. We take these to mean the internal
software that communicates with a VT100 through an RS-232 port
and a software package that runs on a work station communica-
ting with the bridge via the Ethernet port, respectively. Is
that correct? How do each of these programs relate to DECmcc
Management Station software?
4. The specific part number for the bridge that we need for our
implementation is DETLB-PP if we are reading correctly. We
understand that this part number will provide a bridge with
a 120/240 60 Hz power supply and a 2 port 'Turbo" Universal
Interface Card (UIC). We could not find the part number or
numbers to specify the rack mount version or a rack mount
kit. Please clarify that for us.
5. The information given in the manual specifies the use of an
adaptor cable to with the Universal Interface Card to provide
a specific electricl/mechanical interface. It also gives the
part numbers for extension cables. Nice. But it doesn't work
for us. We are not able to predict the required cable lengths
accurately and, more importantly, our installation standards
and our documentation methodology do not provide for
connectors in the middle of a cable run.
Therefore we need to have the rear panel data link connectors
accurately characterized so that we can fabricate the correct
one piece cables on site at installation time. Please provide
this information.
6. We understand that the bridge will boot up from a "Load Host"
on the same IEEE 802.3 network segment. This is the
recommended procedure. In our case that would be the host
workstation (the DECstation5000/240) that we have in Keith Hyman's
office. The bridges at Onizuka Air Force Base (OAFB) and Falcon
Air Force Base (FAFB) would boot from their respective local
DECstation 5000/240s.
We feel it is also appropriate to leave a properly configured
local boot diskette in each bridge so that each could be
initialized to a known default state in the event it's local
host is broken. After booting it could then be managed by the
DECmcc Management station running on the remote host. If you
see any fault with that logic, we would appreciate your
comments and/or recommendations.
WANrouter 500
1. The WANrouter 500 manual does not provide a tutorial on it's
use. Is there one available? If so, we'd like to have a copy.
2. The manual seems to indicate that this device will provide
X.25 protocol delivery of data between routers in our network
and that could be configured to use some other protocol that
was not identified. Is that correct?
We are not absolutely bound to use that X.25 protocol since,
under normal circumstances, we will have only drop at the end
of each arm of the STAR WAN and do not plan to forward data
across the "points" of the STAR. X.25 was chosen only because
we were familiar with it and wanted to have the error
recovery capability it offers as compared to the error
detection capability provided by the bridge. If some other
standard protocol is available on this router, we would like
to know what it is so we can evaluate it's suitability.
3. Does the WANrouter use the same Spanning Tree Protocols that
the Bridge uses? Or is it more restictive. Please comment.
4. Does the Micro Server software running on the router device
collect information on unknown stations attempting to access
the LAN? If it does, can the remote DECmcc Network Management
station detect the presence of said unknown station. this
question arises because we are trying to assess the need to
place a "sniffer" box on the LAN at each of our remote sites
to tattle on users. Please comment on this.
5. Our comments on characterizing the rear panel data link
connectors on the bridge apply to the router also. We will
need this information.
6. We were unable to determine from the manual the precise order
code for the WANrouters. The ones we need will be rack
mountable with four synchronous ports (similar to the UIC
ports on the Vitalink Remote Bridge), an appropriate software
package with license and one IEEE 802.3 network port. The
network port should be a thin port if that option is
available. That means fewer chassis to deal with.
Chipcom Concentrator
1. This Network Management Module seems to speak only SNMP but
we haven't been able to discover much about the information
it actually collect.
2. We understand that this device will boot from a "Load Host"
via the Ethernet port. In our final configuration this could
be our RCC Host (the 5000/240) or the 5000/120 that is
collocated with the concentrator.
3. Does the Management Module have it's own boot facility in
case the "Load Host" is broken (similar to the bridge)? What
information/control is available to the DECmcc Management
Station?
4. Does Chipcom offer an ONLine Module with multiple AUI (Thick
Net) connectors?
5. We will require several Chipcom 9308s or 9314s star couplers.
Does DEC market these directly? Can you obtain for us some
literature on them that shows the packaging configurations
and options?
DECmcc Management Station
1. The manual indicates that this software was designed to deal
mainly with TCP/IP networks and SNMP objects. Since we are
tying to build a GOSIP compliant open network (Whatever that
means!) we have some concerns about TCP/IP and SNMP being
imposed on us by the fact that DEC apparently does not offer
a version of DECmcc that runs on an OSI protocol stack and
versions of the bridge, router and concentrator software that
deal with the respective hardware as CMIP objects.
2. The manual mentions that DECmcc can deal with CMIP objects on
an TCP/IP network (CMOP) but doesn't mention the reverse
situation (SNMP objects on an OSI network).
3. The manual indicates that DECmcc is designed to run on a 19"
color monitor. We would like to run it on a 14" X Terminal.
Is there any problem with this other than the reduced image
size?
4. We would like to first be sure that DECmcc is installed and
running on our development system and second, have one of
your network management gurus meet with us to demonstrate the
software and discuss the functionality and alternatives
available. This may be a good time to test how well it will
function on a 14" X Terminal.
5. The manual mentions management of Phase IV networks and Phase
V networks assuming we understand these terms. We don't.
Please explain what is meant by Phase IV and Phase V
networks.
Thanks for your efforts at helping us understand the DEC
hardware/software and solve our network requirements with their
use.
Sincerely,
Ed Jackson
Network Data Systems
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2290.1 | Some data... | TOOK::MCPHERSON | Scientific progress goes 'Boink!' | Fri Feb 07 1992 09:23 | 77 |
> 2. The bridge apparently supports IEEE 802.1d Spanning Tree
> Protocol and also the original Spanning Tree Protocol
> introduced earlier by DEC. The manual would lead one to
> believe that these two Spanning Tree Protocols cannot
The two protocols cannot coexist on the sam extended LAN. All of DECs bridges
(poss exception of old LB100s) will 'sense' what the other bridges in the
network are using for Spanning Tree and use that . If so much as *one* bridge
is advertising DEC Spanning Stree, then all will revert to that protocol
(downwards compatibility).
> co-exist in the same network segment. Our question is: Does
> DEC offer a choice of Spanning Tree Protocols it supports on
> the routers and work stations? We would prefer to use the
> IEEE 802.1d standard if possible.
Spanning Tree is not germane to routers, only bridges.
Yes, DEC offers *both* protocols for our bridges. We just let the bridges
choose which one they want to use.
> 3a. The manual indicates that the bridge supports the Simple
> Network Management Protocol (SNMP). Does it also support the
> Common Management Information Protocol (CMIP) which is
> specified as a component of GOSIP? More importantly, is it
> compatible with the DECmcc Management Station software
> specified in our contract?
If he's talking about Vitalink bridges, they do NOT support CMIP.
Vitalink's SNMP Agent for their Translans (currently in beta) does appear to
work with the DECmcc SNMP Acces Module. (I have been doing some regression
testing on it...)
> 3b. The manual mentions the Vitalink Management Program (VMP) and
> the WANmanager program. We take these to mean the internal
> software that communicates with a VT100 through an RS-232 port
> and a software package that runs on a work station communica-
> ting with the bridge via the Ethernet port, respectively. Is
WANmanager does not quite work that way. It's workstation-based and uses a
combination of remote virtual terminal and RBMS protocol to manage TRanslans
remotely.
> that correct? How do each of these programs relate to DECmcc
> Management Station software?
WANmanager is a separate "element management system". It is completely
orthogonal to DECmcc management of the Translans, either via the Translan AM
(under DECmcc V1.1) or via the SNMP AM (under either DECmcc V1.1 or 1.2 [not
yet released] ).
> 6. We understand that the bridge will boot up from a "Load Host"
> on the same IEEE 802.3 network segment. This is the
> recommended procedure. In our case that would be the host
> We feel it is also appropriate to leave a properly configured
> local boot diskette in each bridge so that each could be
> initialized to a known default state in the event it's local
> host is broken. After booting it could then be managed by the
> DECmcc Management station running on the remote host. If you
> see any fault with that logic, we would appreciate your
> comments and/or recommendations.
Unless somethiong new has come up. Vitalink bridges boot from their OWN LOCAL
DISKETTE. I believe the 'load host' capability referred to is for the purpose
of downloading new versions of the basic Vitalink Translan software over the
network to another floppy on the Translan.
>
> DECmcc Management Station
>
Are you talking about MSU or DECmcc BMS (EMA-compliant director) ???
| |||||
| 2290.2 | Some more answers... | TOOK::R_SPENCE | Nets don't fail me now... | Fri Feb 07 1992 10:09 | 86 |
The manual states that the warranty is not valid if the
bridge is used with a satellite data link. Since that is
precisely the intended use, we need to either validate that
statement and choose another device or show why the statement
does not apply and confirm that the bridge is suitable for
use with a satellite data link.
Actually, extending LANs via bridges over satallite circuits isn't a
good idea and I can understand why any vendor wouldn't guarentee their
product to work. The problem is latency. LAN protocols were designed to
expect a medium that was very low error rate and very low latency.
Satellite circuits MAY have low error rates but certainly cannot have
low latency (the time to beam up 23,000 miles and back again takes
too long. This has a major effect on the performance of the entire LAN.
Any error (or collision) is going to take a very long (relative to LAN
speeds) time to resolve with a resulting impact on throughput and
response time.
4. Does the Micro Server software running on the router device
collect information on unknown stations attempting to access
the LAN? If it does, can the remote DECmcc Network Management
station detect the presence of said unknown station. this
question arises because we are trying to assess the need to
place a "sniffer" box on the LAN at each of our remote sites
to tattle on users. Please comment on this.
No, it doesn't. Why, because DECnet Phase IV doesn't have any concept
of a node that doesn't belong.
6. We were unable to determine from the manual the precise order
code for the WANrouters. The ones we need will be rack
mountable with four synchronous ports (similar to the UIC
ports on the Vitalink Remote Bridge), an appropriate software
package with license and one IEEE 802.3 network port. The
network port should be a thin port if that option is
available. That means fewer chassis to deal with.
Generally, trying to determine order numbers from a product manual is
not going to work. The Price book and catalogs are the right place.
DECmcc Management Station
1. The manual indicates that this software was designed to deal
mainly with TCP/IP networks and SNMP objects. Since we are
tying to build a GOSIP compliant open network (Whatever that
means!) we have some concerns about TCP/IP and SNMP being
imposed on us by the fact that DEC apparently does not offer
a version of DECmcc that runs on an OSI protocol stack and
versions of the bridge, router and concentrator software that
deal with the respective hardware as CMIP objects.
The first problem here is that we don't know which product for sure is
being discussed. DECmcc is not a product but is the name of a family of
products (Like VAX isn't a specific unit). It seems from the discussion
above that DECmcc MSU (Management Station for ULTRIX) is being
discussed.
The DECmcc Director product is the EMA compliant product and at the
current time has a DEC CMIP implimentation on it. We expect to ship an
OSI CMIP (which we have running) when we can test it against some real
OSI CMIP agents (of which we have not found any - at least last I
checked). In the future we will offer OSI CMIP agents on the routers
and bridges but at the time these products were designed, the OSI spec
was not complete.
2. The manual mentions that DECmcc can deal with CMIP objects on
an TCP/IP network (CMOP) but doesn't mention the reverse
situation (SNMP objects on an OSI network).
SNMP objects on an OSI network doesn't make any sense since SNMP is the
management protocol for a TCP/IP network, not an OSI network.
If you have both OSI and TCP/IP on the same network then you can have
both object types.
3. The manual indicates that DECmcc is designed to run on a 19"
color monitor. We would like to run it on a 14" X Terminal.
Is there any problem with this other than the reduced image
size?
Yes, you can use X-terms with both the DECmcc MSU and Director
products.
| |||||
| 2290.3 | Yes MSU is the correct one | TABOU::JOSEPH | Win agreements, not arguments | Fri Feb 07 1992 15:54 | 1 |
RE:.1 (DECMCC MGT STATION) YES the customer has the MSU software | |||||
| 2290.4 | Also try apple::msu | TOOK::MINTZ | Erik Mintz, DECmcc Development | Fri Feb 07 1992 16:06 | 5 |
> RE:.1 (DECMCC MGT STATION) YES the customer has the MSU software In that case you may get a more accurate response in the APPLE::MSU notes conference. | |||||
| 2290.5 | Thanks for your support | YOSMTE::JOSEPH_BO | Win agreements, not arguments | Mon Feb 10 1992 15:10 | 7 |
I'd like to take this opportunity to thank each and everyone of you for your
help/support.
Regards,
Bob
| |||||