Conference azur::mcc

The info returned from a "netstat -I ln0 -s" is for the *DNA* Ethernet Data
Link Layer counters & other status info.  DNA counters are *not* covered by the 
SNMP MIBII variables (at least not directly).  You can get the counters you're
looking for with 

	MCC> SHOW NODE4 foo LINE * ALL COUNT

*this* will return (among other things):
		Blocks Sent Initially Deferred
  	  	  Blocks Sent Single Collision
		Blocks Sent Multiple Collision
	                  	  Send Failure

It could also be that these data link counters do map into one of the MIB II
interface counters, but I don't know which, if any.

/doug

There is no DECnet at this particular site, only TCP/IP, so this won't work. Will
it?

What kind of Ethernet collision data *do* TCP/IP nodes return? And if that's a
sensible question, can I then write rules on those numbers?

PJDM

    You're options are slimming down fast....

    Is it required that you get this info from *those* SNMP systems (i.e.
    you're not able to put an RMON pod of some sort on the wire?

    I *think* that there's a host-based RMON agent for some UNIX-based
    systems... Don't know if that includes ULTRIX.  If you can get that
    running on a host system, then you could query the "History Table"
    portion of the RMON MIB for ether collisions.

    If that's not do-able, then you could hack your way around like so:
    Write a small little shell script that does a "netstat -I ln0 -s" then
    use awk or whatever to put the output into a format acceptable by  the
    Script AM.   To check the collisions info on *remote* systems, you'd
    need to be able to 'rsh' the script from your MCC systems....  The good
    thing about this is that you'd be able to create alarm rules on some of
    the data coming out of netstat.

    I realize this may not be the most *obvious* solution to your problem,
    but it *will* work.



The only hope you have left for ga

           <<< Note 5241.2 by BIGUN::MAYNE "`AXP!': Bill the Cat" >>>
                                -< TCP/IP only >-

There is no DECnet at this particular site, only TCP/IP, so this won't work. Will
it?

What kind of Ethernet collision data *do* TCP/IP nodes return? And if that's a
sensible question, can I then write rules on those numbers?

PJDM

    Have you tried SHOW STATION <mac-address> ALL COUNTERS ?
    
    If you have the "right" Ethernet Hardware, or the driver you have
    responds to MOPv3 or MOPv4 counter requests, you should be able to
    get the Data Link counters.
    
    You also need Data Link connectivity to the station in question...
    
    					Chris Brienen

I don't know if any SNMP agents's implement it yet, but there is an SNMP
MIB for Ethernet like devices. It's in RFC 1284. If a system implements 
an agent that supports that MIB, then once that MIB was compiled and loaded
into MCC you ought to be able to dig out these counters.

Mark

I've mow figured out how to get the counters. On DECstations, MCC shows all of
the numbers (various collisions, etc) and seems to do exactly what we want (and
what the manual says). However, from the particular devices we're interested in,
MCC shows nothing. It registers as a station fine, the "Show Counters" seems to
work successfully, but the window comes up with no fields in it at all.

MCC thinks that the device is IEEE803_Only, LLC Class I, LLC Type 1.

Presumably the vendor hasn't implemented something. Can someone please post [a
pointer to] some text describing in excruciating detail what exactly the
Ethernet AM is trying to get and how it gets it, the relationship between that
and SNMP, etc, etc, so I can contact the vendor and find out what he isn't doing
and what he has to do, in simple enough words that I can understand it and
explain it to him.

PJDM

    Someone should give you more detail but there really isn't any
    relationship between the STATION AM and the SNMP AM.
    
    I suspect that the vendor has not met all the 802.3 specifications
    for supporting required counters etc.
    
    Also, I suspect that they have not implimented MIB II for SNMP.
    
    What I would ask the vendor is what MIB they have implimented in their
    SNMP Agent. If there is a private MIB Extension, then ask for a
    machine readable copy and load it into mcc.
    
    s/rob

1. DEC ethernet controllers (most, anyway) support extra features that many other
   3rd party ethernet cards don't.   

2. Ethernet V2 is NOT the same as IEEE 802.2.    

If a vendor card supports IEEE 802.2, the SHOW and TEST directives for the
Ethernet Station AM will perform the IEEE 802.2 TEST  and XID functions,
respectively.

It sounds as if your vendor *does* have an IEEE 802.2 compliant ethernet card;
they just don't return the Digital MOP V3 counters (no big surprise there).

re: relationship to SNMP

They are both management protocols. That's about it. SNMP (usually) presumes a
full IP stack and can be routed over a TCP/IP Network.  The Ethernet AM uses a
DataLink level management protocol and *cannot* be routed (in the 'classic'
sense of the term...) across a WAN.  

If you wanted to get your collision counters via SNMP, this would presume that
the system you're talking to could 
	1) collect the counters 
	2) had an SNMP agent that could decode the request for the counters, 
	3) encode the response PDU for the request
This would also presume that there were some MIB definitions (see earlier
reply from Mark S.) that defined for the management system the names, data
types, OIDs, etc for these counters.

You can find more info on the Station AM capabilities in Section 1 of the
Ethernet Station AM USE Guide.

/doug

    By the way,  if your nodes are Suns, you will not get any reply from
    the Ethernet controller.  The controllers get their address from the
    CPU (so if you upgrade the CPU, the Ethernet address changes).  One of
    my customers had to write a simple "agent" to run on each Sun just to
    respond to REQID.
    
    -Dan