HDTenEightyP/NetNews huggingface dataset:
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 5 Oct 92 03:11:23 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>On all of our busy routers, 0 checksum errors are
>recorded for Appletalk and IPX, but IP has some recorded.  We do have
>services that actually use the checksum mechanisms for IPX (not sure
>about Appletalk).

I think you're find that IP is the only protocol with checksum
failures because it's the only protocol that uses checksums.

The IPX packet format is based on XNS, which has checksums.  So there
is a checksum field.  But last time I looked IPX always set the
checksum field to -1, and Novell software would not accept packets
with real checksums.  We'd love to enable checksums for IPX, and we've
asked Novell about this.  I'd love to hear that they had fixed it, but
I really doubt it.  Since Cisco's implementation of Novell is based on
XNS, they could easily support checksums for Novell, if Novell
themselves would implement it.  This explains why you never see a
checksum failure for Novell: none of the packets have Novell
checksums.  (More precisely, the checksum field always has -1, which
means "ignore checksum".)

Appletalk allows checksums, but I have a feeling it isn't normally
used.  We got a printer that supports Appletalk.  We couldn't talk to
it through a Cisco router, because all of our routers have Appletalk
checksumming enabled, and the printer had a bug in their checksum
code.  It worked fine locally.  This implies to me that at least some
Mac's don't generate checksums.  I just looked at our net for a minute
with Sun's etherfind, and if I understand the packet format correctly,
only packets generated by the Cisco have non-zero checksums.  This
would explain why you're seeing no checksum failures for Appletalk.
Newsgroups: comp.dcom.sys.cisco
From: appa@cbnewsk.cb.att.com (ravi.ramaswamy)
Subject: Priorities and Frame Relay
Organization: AT&T
Date: Fri, 2 Oct 1992 17:36:01 GMT

Folks,

	This is regarding the Priority Output Queueing feature in 
	Cisco routers. My understanding is that one can prioritize
	by protocol and by interface type. One can also assign
	priorities by TCP socket numbers. Thus, for instance, in an
	SNA environment one can give STUN traffic higher priority than
	telnet and ftp.

	Assume that the Cisco routers are connected via a frame relay
	backbone. One can map DLCIs (PVCs) to protocols and assign
	priorities to protocols. Thus the PVCs are indirectly assigned
	priorities going into the network. For example, STUN could be 
	mapped to one DLCI and Novell to another DLCI, with STUN being
	assigned higher priority.
	
	As far as I know there is no way to map TCP socket numbers to
	distinct DLCIs (nor is there a way to assign priorities by
	DLCIs directly). The conclusion is that, if one had a mixture
	of STUN traffic and TCP/IP (telnet,ftp) at a location, you 
	cannot prioritize STUN over TCP/IP going over frame relay.

	Is this correct or am I missing something here?

Ravi Ramaswamy
ravi@qsun.att.com
From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel (303)977-1480)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Any clues on AGS+ 'clear'?
Date: 28 Sep 92 16:32:48 GMT
Organization: PAGE @ Martin-Marietta

In article <1992Sep24.155113.6767@bristol.ac.uk>, smee@bristol.ac.uk (Paul Smee) writes:
|> First, 'clear bridge 1' doesn't seem to do anything at all, neither
|> forgetting learned MACs in that bridge group, nor clearing XMIT and
|> RECV counts for permanent entries.  Is there some magic I'm missing, or
|> is this a bug.  

	I'm running 9.1(0.22) (csc3) but "clear bridge 1" seems to work
	just fine for me.  It also works on 8.2(8) (with a csc2 cpu)

|> Second, I can't find any way to clear the various interface-associated
|> counters which are shown by 'show interface ethernet <n>' -- is there a
|> way of doing that? 

	I had trouble for a long time with this too until...

	sh int f 0

	Fddi 0 is up, line protocol is up
	.
	.

	  Five minute output rate 446000 bits/sec, 160 packets/sec
	     22663629 packets input, 391339485 bytes, 9 no buffer
	.
	.
	pgl-ags9#clear counters f 0
	Clear "show interface" counters on this interface [confirm]y
	pgl-ags9#sh int f 0

	Fddi 0 is up, line protocol is up
	.
	.
 	 Five minute output rate 481000 bits/sec, 170 packets/sec
 	    1911 packets input, 405874 bytes, 0 no buffer


	The hint here is the 'y' after the [confirm].

	Another problem your likely to find is 'clear ip route'.  You
	have to say 'clear ip route *' to clear the table.  Of course,
	just like clearing the bridge, new information is put into
	the table before you get a chance to look at it again.

John Zwiebel
Newsgroups: comp.dcom.sys.cisco
From: unrz38@epix.rrze.uni-erlangen.de (Eduard Beier)
Subject: Re: cisco snmp mib compatibilty with SunNet Manager
Organization: Regionales Rechenzentrum Erlangen
Date: Tue, 6 Oct 1992 09:12:58 GMT
Keywords: cisco snmp SNM

subbarao@nmsu.edu (Ravi Subbarao) writes:

>I have down loaded the cisco mib (one for 8.3 ver) from ftp.cisco.com

>I have tried to get this mib to work on the SunNet Manager platform.
>Usually I have to convert the mib to a schema file. When I get this done
>and try to use this schema file to retrieve information from the 
>remote server, only a few "groups" work. The groups like

>		lifTable
>		lipAddrTable
>		decnet
>		

>never work. When queried for data, the snmp.get-request call returns
>with a "No Data" response. Some other groups return "errors" of
>various types...

>There is something wrong in the mibs? If yes, is there is patched
>version of it somewhere?  

>Please reply back as soon as possible. I cannot get any of the mibs
>of cisco to work properly.  It is really frustrating.

>Any SNMP guru, who knows this?

>Thanks in advance....

>-Ravi

>-------------------------------------------------------------------------------
>Ravi Subbarao	  | New Mexico State University	| Internet: subbarao@nmsu.edu
>Network Engineer  | Dept 3AT, Box 30001		| Bitnet:   rsubbara@nmsuvm1
>		  | Las Cruces NM 88003		| UUCP:     nmsu.edu!subbarao
>		  | Phone: (505) 646-5779	| My Host:  flintstone.nmsu.edu
>		  | FAX:   (505) 646-5278	|


SUNNET-Manager supports only up to about 15 Atttibutes per snmp-group.
We had to split some cisco-groups as we introduced 9.0-snmp-support into the SUNNET-Manager


Eddy Beier
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 3 Oct 92 18:28:12 GMT
Article-I.D.: geneva.Oct.3.14.28.11.1992.4370
Organization: Rutgers Univ., New Brunswick, N.J.

ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>Only cisco can ansere this, but we've got over 50 ciscos and all supported
>media but token ring and I've seen this several times.

I suggest that you report it to Cisco support as a bug.  Networks are
complex enough that you may be getting misled, but what you are seeing
seems worth pursuing.  At any rate, I'm quite sure that accepting
packets with bad Ethernet CRC's, if it is occurring, is a bug.
From: dan@gacvx2.gac.edu
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Port stats for 500-CS using SNMP...
Date: 30 Sep 92 05:48:14 GMT
Organization: Gustavus Adolphus College, St. Peter, Minnesota

In article <1992Sep29.233952.1826@gacvx2.gac.edu>, dan@gacvx2.gac.edu writes:
> I have a 516-CS and I would like to track the use of its ports using SNMP.  I
> cannot find anyting in the mib that looks like a traffic counter for these
> ports.  Can anyone give me a pointer?

I have a second question.  I have been trying to dig for for the counters I
need using snmpwalk from the CMU-SNMP package.  However when I get a point, I
get and error and the command aborts.  The same command work fine on my CGS/2
and at AGS+ at the network.

nic [#55]> snmpwalk server public .iso.org.dod.internet.private.enterprises.cis
co
.
.
.
stuff deleted
.
.
.
INTEGER: 0
Name:
.iso.org.dod.internet.private.enterprises.cisco.local.lsystem.bufferFail.0
INTEGER: 31
Name:
.iso.org.dod.internet.private.enterprises.cisco.local.lsystem.bufferNoMem.
0
INTEGER: 0
Mangled packet
Mangled packet
Mangled packet
Mangled packet
No Response from server


Has anyone else seen this, or can explain it?
-- 
Dan Boehlke                    Internet:  dan@gac.edu
Academic Computing             BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596
From: bav@hobbes.ksu.ksu.edu (Brick Verser)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 2 Oct 1992 13:13:16 GMT
Organization: Kansas State University
NNTP-Posting-Host: hobbes.ksu.ksu.edu

ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>In <1aee3aINNfgk@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>
>>In article <BvF94p.9CA@usenet.ucs.indiana.edu> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>>>A cisco will look at the IP header checksum, not the ethernet checksum,
>>>when deciding whether to forward the packet or not.
>
>>Are you sure about this?  On most systems, the ethernet CRC is checked by
>>the interface, not the host software.  In particular, if the CRC is
>...
>
>Yep, I pretty sure.  I've seen very direct evidence of this.  Maybe
>cisco will chime in here and explain.  Of course the router doesn't
>...
>We've had broken repeaters that destroyed the tail of ethernet
>frames (thus the checksum), but not the headers.  The symptoms are
>IP will works just fine, but Novell or Appletalk packets don't pass
>through the router and are counted as input error on the interface
>stats.

This is, basically, what we were seeing.  Sending UDP packets across the
bad fiber transceiver through the AGS we would see coming out the other 
end things like this:

 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
 nopqrstuvwxyz{|}~ !"#$%&'()*+,-./012345678)*******

 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
 nopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=.**

 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
 nopqrstuvwxyz{|}~ !"#$%&'()*+,-./012345678UUUUUUUU

The tail end of about one every 10000 packets was getting stomped.  It didn't
matter for IP since it's checksummed, but UDP checksumming is turned off
by default in SunOS under the assumption that the Ethernet CRC check will
catch problems.  It felt like collisions were simply not being caught
somehow and instead the packets were being accepted in their mangled form
by the router.  If the Cisco is not verifying CRCs on Ethernet packets
then it seems like there's a major potential for NFS catastrophies lurking.

--Brick
Date: Friday, 2 Oct 1992 15:16:45 +01
Newsgroups: comp.dcom.sys.cisco
Subject: Re: What causes "Line up, Line protocol up?"
From: Andre' Pirard <pirard@vm1.ulg.ac.be>
X-UserAgent: Nuntius v1.1.1d11
X-XXMessage-ID: <A6F21681BB02180A@ampa.segi.ulg.ac.be>
X-XXDate: Fri, 2 Oct 92 14:08:49 GMT
Distribution: world
Organization: Universite' de Lie`ge (Belgium)

In article <1992Sep30.194733.17064@linus.mitre.org> Jerry Bass,
gbass@mitre.org writes:
>When  I do a 'show interfaces' command,  what is it that causes the
display to
>show 'line up' or 'line protocol up'?  (This is for serial ports)  Is it
the
>state of the DTR line or DSR line?

Line up is states of serial cable signals indeed (plus "no shutdown" and,
probably, good harware).
Protocol up is effective dialog with other router or response to own's
keepalive poll (e. g. on Ethernet)..
Maybe not exhausive answer for all types of interfaces.

-----
Andre Pirard          SEGI, Univ. de Li`ge         139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ge 1 (Belgium)            +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 5 Oct 92 22:01:25 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>Yea, yea, yea,  I assumed that SPX was checksumed and it isn't.
>But, I just ran a little experiment that still suggests that the
>show ip/ipx/appletalk traffic is relevant.  We captured a good IPX
>frame heading towards a cisco with the sniffer, changed it checksum
>from FFFF to 67FF, and resent it to the cisco.  The cisco counted
>it as a IPX checksum failure.  If none of our ciscos are recording
>any other IPX checksum failures, it suggests that corrupted packets
>caught by the ethernet CRC are not making it into the router.  All
>our ciscos are recording IP checksum failures, suggesting that the
>ethernet CRC is begin ignored.

This experiment doesn't mean what you think it does.  If you set the
IPX checksum to a value other than 67FF, then Cisco will either reject
it because it isn't FFFF (which Novell requires), or compute the
checksum of the packet, and find that it isn't actually 67FF.  But in
the normal case the value is FFFF.  This is a special value meaning
"don't care".  When the value is FFFF, Cisco will not compute the
checksum of the packet.  The packet could be completely trashed.  As
long as the trashing doesn't happen to hit the checksum field, you'll
never see a checksum failure.

This is not the case with IP.  Cisco will actually compute the header
checksum, or in cases where the packet is addressed to it, the UDP/TCP
checksum, and verify that the packet's computed checksum matches the
checksum field.  

So if for one reason or another you're getting corrupted packets,
you'll see IP checksum failures and you won't see IPX checksum
failures.  Now why you're getting corrupted packets is a question I
can't answer.  Perhaps it indicates that Ethernet CRC is not being
properly checked.  Perhaps there is a hardware problem that is
corrupting the packet after the CRC has been checked (i.e. bad memory,
in either the interface or the main box), or perhaps it means that
something in one of your hosts is corrupting the packet before the
Ethernet CRC is being added.  The only point I'm trying to make is
that the fact that you're seeing checksum failures for IP and not for
IPX does not indicate that Ethernet CRC's are being handled
differently for the two protocols.  
Newsgroups: comp.dcom.sys.cisco
From: stigall@bronze.ucs.indiana.edu (john stigall)
Subject: Apple file corruption thru ciscos???
Organization: Indiana University
Date: Tue, 29 Sep 1992 15:46:09 GMT

We're having a problem with file corruption of Appletalk transported
files between server and workstation sometimes...anybody have any idea
whether this might be a router hardware or software problem?...we're
running 8.3(3) on AGS+ routers with FDDI connecting them. Just fishing
for ideas...


-- 
**    Any opinions expressed are entirely my own, not my employers.     **
*     John Stigall - Indiana University Computing Services Network       *
**    stigall@ucs.indiana.edu  > Ham Radio: N9LKL@K9IU.IN.USA.NOAM <    **
From: kitchen@oit.unc.edu (Jim Kitchen)
Newsgroups: comp.dcom.sys.cisco
Subject: Source routing via a T-1
Date: 28 Sep 92 16:00:27 GMT
Organization: University of North Carolina at Chapel Hill

I am attempting to connect an AGS+, running software release
9.0(1), via a T-1 circuit to an MGS running software release
8.3(3).  In addition to other cards, there are Token-Ring cards
installed in each of these routers.  Everthing works fine when I
configure the units to route IP and IPX on the Token-Ring and T-1
interfaces.
 
However, problems develop when I attempt to configure source
route bridging on either of the units.  To do this, I issue the
following configuration commands from the console:
 
inter token 0
source-bridge 2 2 10
 
At this point, the CONSOLE port continues to function OK; TCP/IP
activity on the Token-Ring interface freezes; Novell IPX traffic
on the Token-Ring interface continues to function without any
problem.  I have tried various combinations of IP, IPX and source
routing on the TR interface.  In all cases, I have trouble with IP
and source routing together and no trouble with IPX.
 
In addition, if I leave source routing enabled on the AGS+
Token-Ring port for more than about 1 minute, the AGS+ will
ABEND.  The MGS (under 8.3(3)) does not seem to experience this
latter problem.
 
Has anyone had similar problems?  Can anyone tell me what to do
to correct the problem?  Thanks in advance for any help.
 -----------------------------------------------------------------
James O. Kitchen                   Telephone: (919) 962-1622
Networking Systems                    E-mail: ukitch@unc.bitnet
Office of Information Technology
CB #1405, Rm. 10 Phillips Hall
UNC-CH
Chapel Hill, NC 27599-1405
From: mark@wupost.wustl.edu (Mark Pohlman)
Newsgroups: comp.dcom.sys.cisco
Subject: 9.0 software queue flush failure?
Date: 5 Oct 1992 11:00:14 -0500
Organization: ONC - Washington University in St. Louis
NNTP-Posting-Host: wugate.wustl.edu
Summary: 9.0 queue flush failure

Has anyone noticed a problem with queues filling up on its interfaces and not
flushing its queues properly on 9.0. We've had interfaces on our ciscos showing 
76/75 input queue and hanging the interface.

Only able to clear by RELOAD.

-- 
mark@wugate.wustl.edu
From: fahnoe@C1MPLS.MN.Org (Larry Fahnoe)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Seeding ciscos from FastPaths.
Date: 2 Oct 92 20:03:03 GMT
Organization: Cellular One, Minneapolis

In article <5006@daily-planet.concordia.ca> gpkatch@alcor.concordia.ca (Gary Katch) writes:
>When a cisco port configured for appletalk Phase-I is given
>an address 0.0, it is supposed to be seeded by another router
>on the ethernet.  This does work for me if the other router
>is a cisco, but not if the router is a FastPath.
>
>The only way to start appletalking in the latter case is to
>configure the cisco port with at least the right apple net
>number.  From this it will determine a node number and zone
>name.  Is there something funny about appletalk, or FastPath
>setup for seed routing?
>
>Comments from anyone with cisco<-->FastPath experience needed.

Gary,

We run Phase II networks here, but I did find that there were some real
troubles convincing the seeding mechanisms to work properly with ciscos
and FastPaths.  This was all some time back so some of the details seem
a bit fuzzy, but the solution (for us) was to define just what we wanted
the routing to look like and then let both the ciscos and the FastPaths
become seed routers.  Things work quite well once we made that decision.

--Larry
-- 
Larry Fahnoe                             Cellular One
IS VAX System Manager                    7900 S. Xerxes Ave, Suite 301
612/832-7616                             Bloomington, MN  55431
Internet: lfahnoe@kegworks.mn.org        McCaw DECnet: 18435::FAHNOE
Newsgroups: comp.dcom.sys.cisco
From: C.Chaundy@its.unimelb.edu.au
Subject: Re: Multicast storms
X-Vms-Cc: IN%"cisco@spot.Colorado.EDU"
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0
Date: 30 Sep 1992 11:56:30 +1000
X-Vms-To: IN%"Sam.Wilson@edinburgh.ac.uk"

>Date: 29 Sep 1992 17:01:28 -0300 (BST)
>From: Sam Wilson <ercm20@festival.ed.ac.uk>
>Subject: Multicast storms
>
>Three times recently we have experienced a kind of multicast storm,
>apparently because of a breakdown in the bridge spanning tree.  We have
>Cisco AGS+/3s running 8.2(7) and routing IP, DECnet, Novell and
>AppleTalk and bridging other stuff (LAVC, LAT, ISO CONS/UK Pink
>Book/LLC2).  We have a meshed network of ethernets and FDDI and a leased
>line (which was installed after the first storm).  During the storms we
>saw large amounts of multicast traffic (LAVC and LAT mostly) apparently
>being looped within the network.  Traffic peaked at between 1000 and
>2000 pps, never falling below 1000pps, presumably the peak rate that the
>routers could forward the traffic on the the attached ethernets.

Strange coincidence!  Just last weekend, we had *exactly* the same
problem and fixed it temporarily by turning off bridging on the backup
cisco ethernet interfaces and later, by rebooting the cisco's concerned.

>At the time of the storms we were using the DEC spanning tree, and had
>been for the best part of two years with no trouble.  There were no
>obvious changes of configuration that we know about, in either hard- or
>software, that might have triggered the problem and we've been unable to
>track down any external events that might have caused it.  (The first
>and second occurrences were both at about 11.20 on consecutive Tuesday
>mornings.  Nothing has happened on following Tuesdays.  Third occurence
>started on a Thursday evening and continued off and on through most of
>Friday.  (I wasn't here and don't have exact details of what happened
>but I have no reason to suppose that the outcome would have been
>different if I had been.)

We have a very similar configuration.

>I'm preparing a note for our suppliers and Cisco, but I was just
>wondering if anyone else had come across anything similar. 

Aye!  But it has only happened rarely, once or twice before.

Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
Newsgroups: comp.dcom.sys.cisco
From: Jim Forster <forster@cisco.com>
Subject: Re: ip accounting 
             <CMM.0.90.2.718028906.beach@ddn.AF.Mil> 
Date: 02 Oct 92 09:06:51 PDT

>>   If I have 50,000 entries I don't think I can get them all every 15 to 20
>> minutes using SNMP without severely impacting the router's performance...:0
>> 
>> /dwb

Correct.  You need to pull them by telnet'ing, setting term len=0, and then
show ip accounting.  Telnet/TCP is much faster than SNMP/UDP.  You might
want to use the expect scripts on ftp.cisco.com to automate the telnet.


  -- Jim
Newsgroups: comp.dcom.sys.cisco
From: TOSDRST@ge1vm.schdy.ge.com
Subject: NOVELL SRB connectivity
Date: 02 Oct 92 09:50:07 EDT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From:
Subject: NOVELL SRB connectivity
From:
Subject: NOVELL SRB connectivity
 Hello list,
 We have been attempting to move many of our 37x5 NCP connected
remote token ring clients (pu's) off the remote NCP tic and over
to the CISCO Source Route Bridged environment.
 Many PU's/gateways work fine like (3174's, Attachmate) however,
the Novell gateways come up in a CONCT state.
 The same VTAM PU definitions and CISCO parameters are used for
every PU. (i.e We have not done any configs differnet for NOVELL)
 Must we config anything differently to make the NOVELL SRB connectivity
work ??????????????????????????????
 **********************************************************************

Don Smith
Senior Software Engineer--Network Services
General Electric Company
Corporate Information Technology-Schenectady Megacenter
*
              ______
             /      |   INTERNET:  TOSDRST@GE1VM.SCHDY.GE.COM
            |       |   IBMMAIL:   IBMMAIL(USGESTVS)
  _________/        |   PROFS:     GE1VM(TOSDRST)
  >              0  |   DIALCOMM   8-235-1946
 /                  |   AT&TNET:   1-(518)-385-1946
| ______________    |   SNEAKERNET:General Electric Company
               `_   |              Corporate Information Technology
                 `__|              2500 Cambridge Road
                                   2nd Floor East Wing
                                   Schenectady New York, 12345
                          FAX:      1-518-385-0654
                                       8-235-0654


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From The Desk of Don Smith.
From: dan@gacvx2.gac.edu
Newsgroups: comp.dcom.sys.cisco
Subject: Port stats for 500-CS using SNMP...
Date: 30 Sep 92 05:39:52 GMT
Organization: Gustavus Adolphus College, St. Peter, Minnesota

I have a 516-CS and I would like to track the use of its ports using SNMP.  I
cannot find anyting in the mib that looks like a traffic counter for these
ports.  Can anyone give me a pointer?

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Academic Computing             BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596
Newsgroups: comp.dcom.sys.cisco