| > The DECconcentrators all have MOD-pmd for UTP, and by default were not
> connected to the backplane. I could not access them through HUBwatch,
> and had no way to link to them to move their connections to the
> backplane. How do I do this?
If you are using Hubwatch v4.n and MAM v3.n, Stop. You can't do that.
When using Hubwatch v4.n, you must have MAM v4.n, concentrator 3.n,
900ef v1.5 etc., all the latest.
> I upgraded the MAM from v3.x to v4.x, and the Concentrator from 2.8 to
> 3.x, and the bridge from 1.4x to 1.5.1.
Okay, now we're talking...
> Now, I can't manage the
> DECrepeater 900. It says that the "module's MAC address is not in the
> agent table". Where can I find this information without affecting the
> users on the module? What do I need to do to make this work?
This could be a bug, exposed by the IP services module being upgraded,
which will be fixed in the next release of the MAM.
You could try resetting the MAM, this may "blink" the repeater's
backplane connection, but that's better than resetting the repeater.
> I am upgrading a 16-slot hub 90 config, serviced by a Bridge 90, and a
> Thinwire/BC16E jumper set between the backplanes with a few ports from
> the DECswitch 900EF. I am wondering if I can still manage both remote
> hub 90's now from the old slot where the Bridge was. I removed the
> bridge and replaced it with a DECagent. I terminated the ThinWire at
> both backplanes, but left the BC16E in place between them. I will
> feed each hub through one of the 10BaseT Switch ports on the 900EF, to
> a 90T in each. Can I now manage them both from the DECagent, even
> though they are on different Ethernets, but the same management bus?
I don't know the 90 stuff.
(But I'll make the observation that they're on the same extended
LAN so it should work).
> I have been trying to set up an FDDI ring entering the hub on an A port
> in a Concentrator on the front panel, and passing through four other
> concentrators, and exiting on a "B" port of a 900EF. The Concentrator
> that I am entering on is not at the "left", but in slot 6, in the
> middle of the concentrators, and the bridge is in slot 8. I created an
> FDDI LAN, and pushed the ports to the backplane on all but the slot
> six, which got a ligo of "enter hub=B" and the bridge got the "Exit hub"
> ligo. I cannot keep the "B" backplane port of slot 6 connected. It
> goes to "C Wrap B" condition with fault reason of "Topology Reject".
> All of the other modules show no rejects or port errors. So I don't
> know what port is rejecting it's connection attempt. I looked at DNA
> and UNA addresses, and the module below it is happy with the link. But
> if I pull the "B" fiber optic feed, the "A" loop does not appear to
> function, cause all of the users drop.
C_Wrap_B means that the concentrator has it's B-port connected
but the ring wraps there because the A port is not active.
So the problem is with the A-port. What's your ring look
like? What kind of port are you trying to connect to your
A-port?
> How do I catch traps under MS/DOS? I have set all modules to trap to
> the PC, and have loaded HUBwatch and ProbeWatch. The stack is WRQNET
> and I am not running MAnageworks, or HP openview or other manager. Is
> there a generic SNMP trap catcher that I could compile the HUB module
> Traps into ??
Pass.
|
| Thanks for the help.
Now I have some more questions. Same customer (in fact still onsite
late in the evening, working before the users come in tomorrow).
I still would like to know how to catch Traps. There are no VMS or
ULTRIX nodes available. The site is ALL novell and TCP/IP. I am
running HUBwatch V4.0.1 and the PC has WRQNET as the IP stack. How can
I collect the SNMP trap messages?
I found that all of the DECbridge 90's in the customer's hubs were old
rev 2.9 or below. I upgraded all of them a few hours ago to v3.9 using
a NDUplus kit. The kit was unable to look at the bridge
decndup /s 08-00-2b-xx-xx-xx gave me a CDI_BIND error, and IRIS tells
me that packets are not coming out of my PC using this command...
How do I tell the revision of the Bridge module, if I don't have a MOP
host handy? I have been using a DECagent 90, until I tried to upgrade
it, which is the next bullet.
I had several (4) DECagent 90's on site, which were at firmware 1.1, so
I decided to bring them up to v3.0.1. I tried HUBloader, but it did
not work with that version. So, I pulled out DECndu again.
I have only PC's at the site. So I loaded a copy of DECnduplus onto
one of the pentiums, and tried to upgrade using the ip address. Nope.
So, I used the DECNIS load host PC (which includes a MOP boot loader
section), and I did the "CCI> load denmalod.sys" trick which worked
very nicely for me. Now I have a DECagent which is blinking it's
console port for me, and running MOP boot code.
I went back to my DECnduP PC, and tried to feed DENMA301.SYS to it. I
send 143 packets, and the Agent stops requesting any more. I thought
that I might be going too high, so I got an old distribution kit, and
tried to load DENMA021.SYS, which stopped exactly after 143 frames.
I looked at the load procedure using IRIS, and saw that the DECagent
requested each packet, and the PC sent it. The agent requested 143,
and the PC sent it. Then the PC waited, and sent packet number 143
again. And again. and after ten tries, the PC stopped and logged a
RECEIVE ERROR. These are the only images that I have to try. I went
back to the CCI prompt, and tried the TEST command. The DECagent
passes all diagnostics. I stuck two Agents in the BAD pile that
failed test 26, I will have the service rep swap them out.
What should I do with my DECagents that won't accept the DECnpuP load
image? They won't behave as DECagents any more either. They just sit
and wait for software.
FDDI> I have seven sites with FDDI DECconcentrator 900MX modules with
no ModPMD's. I have been caught ordering hundreds of UTP ModPMD's and
there aren't any to be had. So, in order to bring up the FDDI ring, I
have installed several remote sites as follows. DEChub ONE/MX
stand-alone with two ANSI-MIC MMF ModPMDs, and a DECconcentrator 900MX
with no front panel ModPMD's. I could not figure out how to upgrade
the software on these units. Out of the box, the concentrators did not
have firmware to allow the VT async terminal to move the ports to the
backplane. I had to disassemble each unit, and plug it into a HUB900
to upgrade it, and then reassemble the DEChub ONE. Lucky I had a few
spare ports. After the upgrade of software, I could push the A/B ports
to the HUB ONE/MX. But now, I get several flaky errors during the
day. The ring keeps going up and down. I do not trust it.
I have had to swap out three ANSI MMF ModPMD's cause the PHY LED goes
out, even though the link is up, or it stays on when the link is down.
I have a set of optical power meters, and verify that NO LIGHT is
coming out of various ports, but the PHY LED stays lighted. In other
cases, I verify that the remote site sees a site, and can complete a
link, but the LED (which lights during the self-test phase) won't come
on. The ring supports about twenty Novell file servers, and some SUN
TCP/IP stations. I am running FDDI_SNAP frame type, and the Ethernets
are running 802.3 on the DECswitch 900EF sites, and Ethernet_II on the
sites fed from the DECNIS. (I had a long fight with the DECNIS and
packet frame types that I won't go into here).
I am concerned about the concentrators without front panel ModPMD's.
Should I just power them all down, until I can install at least ONE
modPMD in the front? I wanted to be able to test the ring, and verify
all of the fibers, before the CAD group get's their stations on the
ring. I hope the UTP ModPMDs show up soon.
|
| Hello:
I have gotten answers to most of the questions I had during the initial
installation for this customer. He now is running ProbeWatch on the
PC, which includes a trap catcher, but I don't see any traps occuring.
I pulled some modules out of the hub, and created some RMON thresholds
in the probe that should have trapped, but didn't show up on the PC. I am not sure how
that is supposed to work.
My MAIN concern is the MOD-PMD behaviour. I'ts been a few weeks now,
and the customer has been running happily except for some FDDI
dropouts. From my last post:
>
> I have seven sites with FDDI DECconcentrator 900MX modules with
>no ModPMD's. I have been caught ordering hundreds of UTP ModPMD's and
>there aren't any to be had. So, in order to bring up the FDDI ring, I
>have installed several remote sites as follows. DEChub ONE/MX
>stand-alone with two ANSI-MIC MMF ModPMDs, and a DECconcentrator 900MX
>with no front panel ModPMD's. Now, I get several flaky errors during the
>day. The ring keeps going up and down. I do not trust it.
>I have had to swap out three ANSI MMF ModPMD's cause the PHY LED goes
>out, even though the link is up, or it stays on when the link is down.
>I have a set of optical power meters, and verify that NO LIGHT is
>coming out of various ports, but the PHY LED stays lighted. In other
>cases, I verify that the remote site sees a site, and can complete a
>link, but the LED (which lights during the self-test phase) won't come
>on.
>I am concerned about the concentrators without front panel ModPMD's.
>Should I just power them all down, until I can install at least ONE
>modPMD in the front? I wanted to be able to test the ring, and verify
>all of the fibers, before the CAD group get's their stations on the
>ring.
The ring has dropped a few times since the installation. Each time,
HUBwatch showed a wrapped ring. But, the Green LED indicating a good
link to a neighbor port was on solid. The customer went out and
bought an optical power meter. He connected it to the ANSI MIC ModPMD
at the rear of the DEChub ONE/MX, and there was NO LIGHT coming from
the transmit port. But the Green PHY led stayed lighted, even without
a cable connected to the port. This does not seem right.
Powering down the DEChub ONE/MX fixed the symptom. During the self-test
the LED's cycled orange, and Green, and came up correctly. Then they
inserted the MIC jumper, and indications were correct again. I have
had this symptom now on FOUR similarly configured locations at the
site. Each has a DEChub ONE/MX with two ANSI MIC Mod PMD's, and a six
port DECconcentrator 900MX with NO modPMDs installed. Each
concentrator was upgraded to the latest firmware release, and the A/B
ports pushed to the back of the HUB ONE. Traps, SNMP, IP address and
Mask were all set using the menu.
The customer is NOT comfortable with the reliability of this solution,
and wants to remove the DECconcentrators from his ring. What is the
appropriate escalation procedure to have engineering look into this?
thanks,
JR
|