| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2284.1 | | SLINK::HOOD | Maine state bird: The black fly | Tue May 16 1995 20:39 | 1 |
| Yes. Try <HELP>.
|
| 2284.2 | help with a display | CSC32::L_MORSE | | Thu May 18 1995 13:45 | 29 |
|
I tried help. thanks.
Here is her display. She can not identify the MAC addresses found.
The IP addresses are of 4 900ms hubs.
M A C I P commun Module Port
55-55-55-55-05-e0 137.241.51.27 public 1 1
55-55-55-55-05-e0 137.241.51.12 public 5 8
55-55-55-55-05-00 137.241.51.27 public 1 3
55-55-55-55-05-00 137.241.51.12 public 6 8
55-55-55-55-05-05 137.241.51.21 public 5 5
55-55-55-55-05-05 137.241.51.27 public 1 3
aa-aa-aa-aa-02-e0 137.241.51.21 public 5 3
aa-aa-aa-aa-02-e0 127.241.51.12 public 6 3
aa-aa-aa-aa-0a-e0 137.241.51.21 public 5 3
aa-aa-aa-aa-0a-e0 137.241.51.12 public 6 2
aa-aa-aa-aa-aa-00 137.241.51.27 public 1 2
aa-aa-aa-aa-aa-00 137.241.34.35 public 4 6
Are these MAC addresses identifiable? The customer and I
cound not find these in any registry. She will check for
any possible loops. They have a token ring on this LAN,
she will look there as well.
Any help to explain will be appreciated.
|
| 2284.3 | What HUBwatch version and platform | SLINK::HOOD | Maine state bird: The black fly | Thu May 18 1995 14:02 | 1 |
| What is the HUBwatch version and platform?
|
| 2284.4 | Look like bad CRC collision addresses to me. | MSDOA::REED | John Reed @CBO, (803) 781-9571 NIS Networker | Thu May 18 1995 14:41 | 6 |
| Those addresses sure look like collision frames. the alternating
pattern of 1010101010 seems to occur on collision frames, created when
the two nodes colliding didn't back off quickly enough. They should
have a bad CRC, and therefore (IMO) not be shown on your address list.
|
| 2284.5 | HW 3.1 and VMS | CSC32::L_MORSE | | Thu May 18 1995 14:56 | 3 |
|
VMS and 3.1 Hubwatch (the customer said 3.1.1)
|
| 2284.6 | same thin on 3.1/osf | CSC32::SCHLABS | | Tue May 23 1995 14:15 | 7 |
| I am talking to a guy who is seeing the same thing, but using hubwatch
3.1 (I think) on digital unix. Is this just collisions that hubwatch
reports erroneously (as mentioned previously), or is something else up.
My customer only sees this on on dechub..the other is ok.
thanks,
greg
|
| 2284.7 | Look like remenents of packet collisions.... | NETCAD::BATTERSBY | | Tue May 23 1995 14:21 | 5 |
| 1010101010's look like packet preamble to me, so I would support
the previous note that says they are the result of a collision
on the wire.
Bob
|
| 2284.8 | | NETCAD::DRAGON | | Wed May 24 1995 11:56 | 6 |
|
Any chance that the customer has a DECnet node with the Ethernet
Physical Address of AA-00-04-00-0A-E0 coming in through the
repeaters reported?
Bob
|
| 2284.9 | Customer says they don't | CSC32::L_MORSE | | Tue May 30 1995 11:45 | 8 |
|
RE .8
I asked my customer and they do not have that node number,
56.10. correct ?
ALM
|
| 2284.10 | Theory #2 Dead End... | NETCAD::DRAGON | | Tue May 30 1995 14:16 | 9 |
|
ALM,
56.10 looks correct to me. So much for that idea.
Thanks,
Bob
|
| 2284.11 | how does HW poll repeater ports ? | CSC32::L_MORSE | | Tue May 30 1995 17:33 | 8 |
|
Another question.
How does hubwatch poll the repeater ports ?
(ie getting a preamble in the source address field ?)
ALM
|
| 2284.12 | | NETCAD::DRAGON | | Wed May 31 1995 09:28 | 10 |
|
ALM,
In the case of a DECagent 90, HUBwatch does GET-NEXT on drpt90PortPhyAddr
and drpt90PortAddrIndex. In the case of the MAM and DECrepeaters with
their own SNMP agents erptrAddrDBPortPhyAddr, erptrAddrDBPortGroupIndex,
and erptrAddrDBPortIndex are used to get addresses seen on repeater
ports.
Bob
|
| 2284.13 | More Info | NETCAD::DRAGON | | Fri Jun 02 1995 11:55 | 11 |
|
Larry,
Do you know what repeaters are in the hubs/slots reporting those
"bogus" duplicate addresses. Also what type of hubs they are
(DEChub 90/900) and what SNMP agent is managing the hubs
(MAM/DENMA)?
We have seen a similiar problem.
Bob
|
| 2284.14 | 900TM, & MAM | CSC32::L_MORSE | | Wed Jun 07 1995 15:58 | 7 |
|
Still waiting on a FAX but they do have 900TM's on a 900MS.
I believe the MAM is used.
The customer will re-fax.
Larry
|
| 2284.15 | devices are 900tm's | CSC32::L_MORSE | | Tue Jun 13 1995 13:52 | 28 |
|
RE .13
They have 13 900ms hubs in 13 buildings broken down as follows:
building ps bridge 900tm 90t con
-------- -- ------ ----- --- ---
1 4 1 3 1
2 2 1 2 1
3 2 1 2 1
4 2 1 2 1
5 3 1 2 1
6 2 1 1
7 2 1
8 2 1
9 2 1 1 4
10 2 1 2
11 2 1 3
12 2 1 2
13 2 1 1 3
They are really not sure but most all of the hubs have
seen the problem. Also, they have a major power failure
and the duplicates were removed.
Larry
|
| 2284.16 | | NETCAD::DRAGON | | Tue Jun 13 1995 14:11 | 7 |
|
Larry,
There was a similiar problem reported by System Test, which
involved the DECrepeater 90T/T+.
Bob
|
| 2284.17 | where's the failing component ? | CSC32::L_MORSE | | Wed Jun 14 1995 11:55 | 11 |
|
Can someone venture a statement as to the failing component here ?
The repeaters or Hubwatch ?
The customer sees this as a short comming of a product and would like
a remedy.
thanks
Larry Morse
|
| 2284.18 | | NETCAD::DRAGON | | Wed Jun 14 1995 12:51 | 14 |
|
Larry,
In the case which I observed the SNMP Agent (DENMA and MAM) was
returning bogus addresses to HUBwatch. The problem appeared to
occur only with DECrepeater 90T/T+ modules with the given traffic.
Are the bad addresses being seen by the customer being reported
on DECrepeater 90T/T+ slots/ports? In the case which I observed
the same traffic was run through a DECrepeater 900TM with no
problems seen.
Bob
|