| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
I have a customer with a DECbridge 90 problem that I've never seen
and didn't think it could ever happen.
They have a 10B5 backbone with two DEChub 90's each with a DECbridge
90 and some 10BaseT repeaters. The one hub in the computer room
is OK. The other hub or should I say bridge is not doing so well.
The problem hub has some PC's with Western Digital cards, a VAXstation
and a couple of SPARC II's. The VAXstation talks to a big VAX in
the other hub. It randomly sees delays of 3-5 seconds. Idicative
of lost packets and the sender timing out and resending any lost
packets. This is the wierd part. Have a look at the Flash EPROM
erasure count below. I thought this count count only be altered
by doing a downline load upgrade.
The customer has found a possible problem with a SUN motherboard
and is getting it replaced. If the VAXstation runs fine after this
and the EPROM count doesn't keep on incrementing then what could
the SUN be sending out that would affect the bridge??
DECbridge> SHO BRIDGE
DECbridge 90 V1.14 08-00-2B-33-59-D1 � 1991 Digital Equipment Corp
FPROM V1.5 �1991 Digital Equipment Corp. 19-APR-1991
Bridge states:
Console owner: AA-00-04-00-66-E7 Uptime: 24.26 seconds
Bridge state: 16 Work group size: 3
Hub management enable: 1 Spanning tree enable: 1
Flash EPROM erasures: 30,836 Address lifetime: 450*2 sec.
Event counters:
System buffer unavailable errors: 0
Work group size exceeded errors: 0
Spanning tree parameters:
Bridge id: FF-FF-08-00-2B-33-59-D1 Root port: 1
Designated_root: 00-6F-08-00-7C-00-30-62 Root path cost: 1,796
Current Forward delay: 15, Hello interval: 1, Listen time: 15
Default Forward delay: 15, Hello interval: 1, Listen time: 15
Topology change flag: 0 Topology change timer: 30
Bad hello limit: 15 Bad hello reset interval: 5
Epoch_mode: 1 Epoch1 who: 00-00-00-00-00-00 Mode changes: 1
Epoch 1 poll time: 18 seconds Epoch 1 response time: 15 seconds
DECbridge>
I know the FPROM version is old but field service swapped the unit
with a V3.0 one and still the bridge is getting hit by bad packets.
Any ideas?
dave
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 541.1 | Old bridge firmware | QUIVER::SLAWRENCE | Mon Dec 06 1993 17:30 | 6 | |
V1.5 is _VERY_ old DECbridge code;
My sources didn't know about any EPROM erasures problem that far back,
but there were many other problems.
Upgrade your bridge code ASAP to V3.1
| |||||
| 541.2 | Good bridge, same results. | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Fri Dec 17 1993 14:48 | 32 |
Ok, let's try this one. This is the new bridge that field service
swapped into place for the customer. I just got it back and thought
I'd post the results. A SUN SPARC II has had its motherboard replaced
and there have been no further EPROM erasures count increments.
The question remains. How can a bad Ethernet interface send (and
what type of packets) and cause the EPROM erasure count to increment?
DECbridge> SHO BRIDGE
DECbridge 90 V1.14 08-00-2B-25-D7-11 � 1991 Digital Equipment Corp
FPROM V3.0 �1991,92 Digital Equip Corp 1-OCT-92
Bridge states:
Console owner: AA-00-04-00-66-E7 Uptime: 765.15 seconds
Bridge state: 17 Work group size: 58
Hub mgmt enable: 1 Spanning tree enable: 1
Flash ROM erasures: 65,331 Address lifetime: 450*2 sec.
Event counters:
Sys buffer unavail. errors: 0
WG size exceeded errors: 0
Spanning tree parameters:
Bridge id: FF-FF-08-00-2B-25-D7-11 Root port: 2
Designated_root: 80-00-08-00-2B-A0-F8-28 Root path cost: 10
Current Forward delay: 15, Hello interval: 2, Listen time: 20
Def. Forward delay: 15, Hello interval: 1, Listen time: 15
Topology change flag: 0 Topology change timer: 30
Bad hello limit: 15 Bad hello reset interval: 5
Epoch_mode: 3 Epoch1 who: 00-00-00-00-00-00 Mode changes: 0
Epoch 1 poll time: 18 seconds Epoch 1 response time: 15 seconds
dave
| |||||
| 541.3 | QUIVER::SLAWRENCE | Fri Dec 17 1993 16:44 | 8 | ||
That still isn't the latest, but I'll poll the local bridge gurus...
the latest is:
FPROM V3.1
...just cause you just got it, doesn't mean it hasn't been in a
warehouse for a _long_ time.
| |||||
| 541.4 | New enough? | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Fri Dec 17 1993 18:25 | 11 |
The fiber bridge is shipping with V3.1 but I think the normal DB90
is still shipping with V3.0. Or am I wrong??
Anyways I thought the only thing different was the correcting of
spanning tree problems in V3.0. Besides, they have only 2 bridges
(DB 90s) on the entire network. All the rest (Cabletron, UB) are
repeated onto the backbone.
Under what conditions would the erasure counter get incremented??
dave
| |||||
| 541.5 | Before this note is forgotten... | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Wed Dec 29 1993 16:06 | 8 |
I haven't been corrected yet (??) about V3.0 or V3.1 in the DECbridge
90. Given that it happened under V1.5 and V3.0 I'd bet dollars
to donuts that it will still happen under V3.1.
Anyways, anyone hazard a guess why and how a misbehaving SUN could
cause that counter to increment?
dave
| |||||
| 541.6 | QUIVER::SLAWRENCE | Wed Dec 29 1993 17:33 | 2 | ||
No one here has seen anything like this that I can find...
| |||||
| 541.7 | Reset the counter? | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Fri Jan 07 1994 11:05 | 4 |
Is there any way that the counter can be field reset back to a more
real number like 1?
dave
| |||||
| 541.8 | No. | ROGER::GAUDET | Because the Earth is 2/3 water | Fri Jan 07 1994 13:56 | 1 |
RE: .7 I'm afraid not. | |||||