| 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 |
Hello Could you please help me to clarify the following point : How can we manage 90c repeaters ? Those will be installed in stackable hubs where 90FS will be available. There will be also standalone Decagent available. When we read the "SPD" and doc of 90C. It is told that these are SNMP manageable via either a Decagent or a 90FS. My current understanding of the "SNMP manageable" is not ok ? . does it exist any differences between the management solution that would be based on the SNMP proxy used by the 90Fs and the other management solution that would be based on the Decagent. Do we get same functionality or does it exist differences between both solutions. Our current Hubwatch tests does not show any differences. . we did some tests using Hubwatch and Netview-NT, we are going ahead with additional tests but the current understanding is . we can't get any counters related to the BNC ports. . it seems that no trap mechaninsm exists and that the only way to discover a fault (partitioning) on a port is to pool the port (via the FS agent) . it seems that it exists no snmp variables related to the 90c. . how could we get the list of stations residing on a 90c ports via Netview as Hubwtach is able to get them . in Netview we don't see any MIB related to 90FS or 90C, however we see MIB for other type of equipements (like 90FA, 90FL...) and one generic Decrepeater... thanks for your help regards Pierre Triniane Digital Luxembourg
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3511.1 | On/Off but no stats | PTOJJD::DANZAK | Pittsburgher � | Wed May 08 1996 22:46 | 13 |
I believe that the 90c (and 90t) when managed by an agent (read
DECagent90 or 90TS or 90FS) will provide you only port status (is it
on/off) and a connected station list. Because the agent is providing
PROXY for the repeaters, and SNMP values are DELTAS from the prior get,
the agent doesn't have enough memory to provide stats on modules.
So you get no stats!
u c?
RE: Mims...who knows...
j
| |||||
| 3511.2 | trap / snmp variables | LUX01::lxp215.bro.dec.com::triniane | Thu May 09 1996 09:46 | 29 | |
hello
>thanks for the info I have however still few questions
I believe that the 90c (and 90t) when managed by an agent (read
DECagent90 or 90TS or 90FS) will provide you only port status (is it
on/off) and a connected station list.
>is the port status send by a trap (link up, link down) or is it the result
>of a pooling.
Because the agent is providing
PROXY for the repeaters, and SNMP values are DELTAS from the prior get,
the agent doesn't have enough memory to provide stats on modules.
>what do you mean by snmp values, which type of info can we get via
snmp get...Is it describe in a document I can read/use
So you get no stats!
u c?
RE: Mims...who knows...
thanks
Pierre
Pierre
| |||||
| 3511.3 | Not enough memory | PTOJJD::DANZAK | Pittsburgher � | Thu May 09 1996 14:13 | 18 |
RE: .-1
No, I dont' believe that you can trap port up/down etc.
RE: Stats etc.
I mean that stats that the agent (DECagent 90, 90TS or 90FS) gets from
the module via whatever black magic that it uses. The agent gets the
values and doesn't have enough memory to store all the prior ones etc.
For example, if you took a Multistack with T16 repeaters stacked 14
high you could get 154 ports! That's a LOT of data for the itty bitty
agent to store etc.
hope that helps,
Regards,
j
^--a grunt in the field
| |||||