T.R | Title | User | Personal Name | Date | Lines |
---|
302.1 | Some answers, not all... | KYOA::KOCH | It never hurts to ask... | Thu Jul 18 1991 20:48 | 50 |
| >1. NIH would like to dual home DAS workstations to two concentrators. They
> want to use our workstations (for high availability data). Will we ever
> support a DAS controller for this situation? Is there some technical
> reason why this is not a good idea?
You don't want to do this. Having workstations as DAS connects
actually reduces availability. They are part of the ring and thus
if powered off, the ring is broken. To get around this, you then have
to put in optical bypass units, reducing the size of the ring. You
don't want people able to affect the ring.
>2. NIH doesn't have any VMS systems (therefore no DECelms). They really
> want to be able to manage the concentrators with SET SNMP commands (which
> won't be available till the end of the year?). Until then the only other
> choice for management is DECmcc MSU V1.1, right? Also, is it
> possible to manually shutdown a concentrator port (sorry I've never seen
> one)?
This is a good question. However, MSU is the Management Station for
Ultrix. In all the presentations I have seen, MSU will be replaced by
DECMCC for Ultrix, a different product. However, to manage the newer
products, you need the Fiber Access Module for DECMCC. My suggestion is
to lend them the hardware to manage this until DECMCC for Ultrix is
available. Not the best answer, but you have limited options.
>3. For some reason they want a roving MAC. I know our concentrator doesn't
> support this. They want to know if we don't have a roving MAC what
> happens when a station is inserted or removed (what frames are sent around
> the ring)?
No answer.
>4. When SET SNMP is available which MIB extensions will it support?
> Are there special fddi MIB extensions? Will we support them? Where
> can I get a list of those parameters? Is there an RFC?
No answer.
>5. Are there any plans to develop a concentrator with more than 8 ports,
> say something around 30?
What are the distances involved? They can get higher concentrations
using copper FDDI if the distance involved is < 100m. Other than this,
you need to contact the product manager. Each copper board can support
6 connections for copper vs. 4 connections for fiber.
>6. SMF is for the backbone and between concentrators, right? It won't be
> employed from controller to concentrator, right?
No answer.
|
302.2 | Couple of more answers | QUIVER::CIARFELLA | When in doubt, mumble. | Fri Jul 19 1991 10:37 | 36 |
| >2. NIH doesn't have any VMS systems (therefore no DECelms). They really
> want to be able to manage the concentrators with SET SNMP commands (which
> won't be available till the end of the year?). Until then the only other
> choice for management is DECmcc MSU V1.1, right? Also, is it
> possible to manually shutdown a concentrator port (sorry I've never seen
> one)?
It is possible to enable and disable concentrator ports, in DECelms,
DECmcc ELM, and in the future (when SET capability is available)
DECmcc SNMP, and MSU.
As for SET capability, any SNMP implementation will be able to do
'gets' and 'sets' on our FDDI products.
>3. For some reason they want a roving MAC. I know our concentrator doesn't
> support this. They want to know if we don't have a roving MAC what
> happens when a station is inserted or removed (what frames are sent around
> the ring)?
This question does not make much sense to me.
Whenever a MAC leaves or enters the ring, it must scrub the ring for a
certain period of time. This scrubbing action (the sourcing of idle
symbol pairs) will clean the ring of all packets and fragments. After
the scrubbing completes, the normal FDDI claim process begins.
>4. When SET SNMP is available which MIB extensions will it support?
> Are there special fddi MIB extensions? Will we support them? Where
> can I get a list of those parameters? Is there an RFC?
The MIBs supported will be
MIB II - RFC 1158
FDDI MIB - currently under the experimental branch of the
IETF management model; no RFC number yet
DEC vendor extended MIB - under the vendor branch
|
302.3 | Some more answers | JUMP4::JOY | Get a life! | Fri Jul 19 1991 11:36 | 32 |
|
>1. NIH would like to dual home DAS workstations to two concentrators. They
> want to use our workstations (for high availability data). Will we ever
> support a DAS controller for this situation? Is there some technical
> reason why this is not a good idea?
I believe there is also the question do the higher level
protocols support dual- or multi-homing? The dual-homing concept allows
a concentrator to have a hot-standby connection to another CON. A
workstation would have to support this type of hot-standby DECnet or
TCP/IP connection to make it feasible. Are they worried about the CON
failing or the adapter board in the WS? If they have to shut down a
DECnet circuit or TCP/IP circuit and then bring up the other one if the
CON fails, it might be almost as fast to just swap the cable from one
CON to another.
>3. For some reason they want a roving MAC. I know our concentrator doesn't
> support this. They want to know if we don't have a roving MAC what
> happens when a station is inserted or removed (what frames are sent around
> the ring)?
Not a good idea and also a proprietary implementation. See Paul
Koning's comments in 239.1 and 288.1.
>6. SMF is for the backbone and between concentrators, right? It won't be
> employed from controller to concentrator, right?
So far there are no plans to offer an adapter with SMF. But check with
the product managers to be sure (Geirge Nielsen, Sharon O'Neill)
|
302.4 | | CIVAGE::FEARNOW | Bobbi Fearnow @WNP 427-5683 | Fri Jul 19 1991 15:38 | 23 |
|
Thanks for all your responses, they are most helpful.
Just a couple of clarifications:
re .1
My understanding is that a customer with MSU (and the upgrade service)
will be ugraded to DECmcc for Ultrix when it is available.
Also, NIH has several Ultrix Workstations. They would prefer to have
a single SNMP based management station (I think its ATT) rather than
an SNMP management station and an Ultrix station running MSU (for the
RBMS piece in V1.1).
re .3
NIH is concerned about the concentrator failing, not the adaptor. We
have discussed having a second concentrator and swapping cables as an
option. Your point about the higher level protocols needing to support
dual homing is a good one, something I try to communicate to them.
Thanks again!
Bobbi
|
302.5 | | KONING::KONING | Eesti vabaks! | Mon Jul 22 1991 11:55 | 32 |
| Re .1: careful with that answer about DAS. You actually answered a different
question, which was "I want to connect my ws directly to the dual ring, what
can you do for me?"
1. To connect to the dual ring you MUST have a DAS. However, for reasons
explained in .1 and elsewhere, connecting things that are accessible to
users to the dual ring is a bad idea. The only thing connected to the
dual ring should be tightly controlled "backbone" devices -- and not many
of them. Concentrators are the primary example; bridges can also be
connected that way.
2. However, if you have a DAS that doesn't mean you have to connect it to
the dual ring. You can also connect it, dual-homed, to concentrators.
That is a perfectly sensible thing to do! This will give you redundancy
to protect from a limited set of faults.
We don't offer this configuration. An alternative that will protect
from a much larger set of faults is to use two FDDI (SAS) adapters.
Subject to the rules of the higher layer protocols, you can connect them
to the same FDDI (via concentrators). Alternatively, it would be even
better to connect them to SEPARATE FDDI LANs. That way you're still
in business even if an entire LAN goes down, which is possible.
Before you propose this sort of approach, be sure to find out what higher
layer protocols (e.g., IP, OSI) are to be used, and what the topology
rules are that need to be followed.
Re roving MAC: see the earlier notes on this topic. I'd suggest you ask
the customer "Roving MAC is a mechanism that may (or may not) do something
useful. What service -- as opposed to mechanism -- are you looking for?"
Also discuss with them the ANSI standard station insertion rules we follow;
it's a good bet that this will be perfectly adequate for their needs.
paul
|