| >> On the hub with four V1 hardware DETMMs I am unable to successfully
>> create and attach the bridge and the DETMMs to created LANs.
Please describe how your configuration attempts failed in greater
detail. In what order did you create LANs on the backplane, connect
repeaters to the backplane LANs, connect the bridge to the backplane
LANs? What was the failure mode? Did the HUBwatch LAN Interconnect
view "rubber-band"? Did any of the modules crash?
>> I can move the Module to any of the DETMMs but I then cannot remove that
>> module from the "thinwire" channel.
I'm not sure I understand what you mean here. Does "move the Module to
any of the DETMMs" mean making a given DETMM the IP server for the hub.
Are you saying that you can't remove a DETMM designated as the IP
server from the backplane thinwire?
|
|
Thanks for your response. This is the sequence they created their
LANs.
| 1. We reset the HUB and modules to factory defaults.
| 2. We used to the LAN interconnect menu to verify that we had four
| DETMMs all connected the ThinEthernet.
| 3. We used the config option to put the six Ethernets out the
backplane.
| We also connected the A FDDI to the front and the B FDDI to the
back.
| This worked great.
| 4. We created 4 LANs named Ether2, Ether3, Ether4 and Ether5 in the
FDDI
| <mumble> menu and connected the first four Ethernet ports on the
| DECbridge900MX to these Ethers, port2 to Ether3, port3 to Ether3,
etc.
| This worked great.
| 5. We when the LAN interconnect menu and we tried to attach DETMM4
to
| Ether5. We disconnected it from the ThinEthernet and then we
| attached it to the Ether5. This worked OK. We then tried the
| same with DETMM3 and Ether4 or DETMM1 and Ether2. When we would
| try to remove the DETMM from the Thinnet, it would hang. The
| terminal that we started HUBwatch from would log timeout and
retry
| or some such language. HUBwatch would not work after this.
The error received was a timeout and yes, it did "rubber-band". It
sounds like it may be a hardware revision issue with the DETMM's. Only
the V1.0 modules give us this symptom. Any issue with this version?
Thanks.
Mark
|
|
Mark,
You may have blown away your connectivity to your IP Services
Module from your NMS (HUBwatch workstation). For example, if
your NMS is attached to a DETMR on the Thinwire, and your IP
Services module is a DETMM connected to the Thinwire, and you
disconnect the DETMM from the Thinwire, you have lost the ability
for your NMS to reach the MAM in-band via IP Services (assuming
no bridging is taking place). This might explain the retries seen
by HUBwatch. A fairly easy way to determine if this is the case is
to connect your NMS directly to your IP Services module (if possible)
and retry the scenario which you described. This way you'll be assured
of connectivity between your NMS and IP Services.
Regards,
Bob
|