aggarwal@nisc.jvnc.net (Vikas Aggarwal) (11/07/90)
This is regarding the IP accounting feature in cisco r8.xx. The feature *would* have been really useful if the data collected by the router could be more "manageable" (sound's SNMPish enough, I guess). Presently, the router can be configured for a fixed memory limit for accounting- the accounting table takes up only the configured amount of memory, etc. However, the entries in the accounting table are *not* sorted in any manner, and the table is effectively a list of the *first* X number of hosts who sent traffic its way. The table really offers very little by means of *useable* information in a WAN that has a large number of hosts. I was hoping that the familiar "access-list" methodology would be used in the accounting software too- it would be nice to be able to configure the accounting for IP addresses using access lists which determine which entries are recorded in the accounting table. That way, I could account packets depending on the topology of my network and in a manner that was more meaningful to me than a mere collection of host-address pairs and packet counts. Over a period of time, I could make the accounting as specific as I would want and not have to worry about not being able to get info on a host because the host couldn't make it first into a slot in the accounting table. The "I" used above might seem self-centered but it was just easier wording it that way than try and make the whole thing RFCedly abstract and RFCedly-(un)comprehendible. Comments ?? -vikas vikas@nisc.jvnc.net (609) 258-2403 Network Engineering JvNCnet, Princeton, NJ -----------------------------------------------------------------------------
pte900@jatz.aarnet.edu.au (Peter Elford) (11/07/90)
>From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) > >This is regarding the IP accounting feature in cisco r8.xx. > ... stuff deleted ... > >However, the entries in the accounting table are *not* sorted in any >manner, and the table is effectively a list of the *first* X number of >hosts who sent traffic its way. The table really offers very little by >means of *useable* information in a WAN that has a large number of hosts. Not quite true. If you retrieve the table via SNMP, you get it back ordered by source IP address. >I was hoping that the familiar "access-list" methodology would be used in >the accounting software too- it would be nice to be able to configure the >accounting for IP addresses using access lists which determine which >entries are recorded in the accounting table. That way, I could account >packets depending on the topology of my network and in a manner that was >more meaningful to me than a mere collection of host-address pairs and >packet counts. Over a period of time, I could make the accounting as >specific as I would want and not have to worry about not being able to get >info on a host because the host couldn't make it first into a slot in the >accounting table. This would be *EXTREMELY* useful. I find that just watching at our central hub router for a minute or so I get ~300 pairs of numbers. Some method of selecting out the interesting bits is definitely required. Perhaps it might be more useful to allow some sort of "masked" counting to be done, ie. so that totals can be collected on a per net or subnet basis, eg. ip access-list 801 permit ip 128.250.1.0 0.0.0.255 130.56.0.0 0.0.255.255 ip access-list 801 permit ip 0.0.0.0 255.255.255.255 130.56.0.0 0.0.255.255 ip access-list 801 permit ip 0.0.0.0 255.255.255.255 139.130.72.0 0.0.0.63 ip access-list 801 permit ip 0.0.0.0 255.255.255.255 139.130.104.0 0.0.0.63 ip accounting access-group 801 This would create only four accounting table entries (but see below). One for all packets from subnet 128.250.1.0 to network 130.56.0.0, one for all other packets destined for network 130.56.0.0 and one each for a count of all packets routed to a couple of subnets of 139.130.0.0 (which is subnetted with mask 255.255.255.192). Of course, you might still want to gather "the rest" on a per host or per net basis, so maybe ip accounting per-network ip accounting per-host would be useful as well. These would be mutually incompatible, and would act as wildcards for acess-lists, so that if no match was found in the access-list, or if no acess-list was present, then per-whatever accounting would be done. If neither per-network, nor per-host were on, then only the entries allowed by the access-list would apply. Of course the killer with all this is that performance might disappear down the plug hole ... but it is a pretty important feature. All of what I have described above is doable with NNstat (for example), but if your network backbone is a router rather than an Ethernet cable you need NNstat features inside the router (including per TCP/UDP port statistics). With regard to performance, perhaps a coprocessor, that gets passed packets from the main processor for inspection might be the way to go ... Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, post: PO Box 4 Australian National University Canberra 2601 Canberra, AUSTRALIA
robel2@mythos.ucs.indiana.edu (Allen Robel) (11/07/90)
>Perhaps it might be more useful to allow some sort of "masked" >counting to be done, ie. so that totals can be collected on a >per net or subnet basis, eg. I suggested exactly this to cisco a few months ago but, alas, they do not feel that this would be all that useful. I personally feel that their IP accounting feature as it stands now is virtually useless if you have to account for much more than several subnets. We have 45 local subnets and will be hosting a state network comprised of god-knows-how-many subnets in the near future. There's just no way to do accounting strictly on a host basis on this scale. Allen Robel robel2@mythos.ucs.indiana.edu University Computing Services ROBELR@IUJADE.BITNET Network Research & Planning voice: (812)855-7171 Indiana University FAX: (812)855-8299
pte900@jatz.aarnet.edu.au (Peter Elford) (11/07/90)
>From robel2@mythos.ucs.indiana.edu Wed Nov 7 15:49:02 1990 > >>Perhaps it might be more useful to allow some sort of "masked" >>counting to be done, ie. so that totals can be collected on a >>per net or subnet basis, eg. > >I suggested exactly this to cisco a few months ago but, alas, >they do not feel that this would be all that useful. I personally >feel that their IP accounting feature as it stands now is virtually >useless if you have to account for much more than several subnets. >We have 45 local subnets and will be hosting a state network >comprised of god-knows-how-many subnets in the near future. >There's just no way to do accounting strictly on a host basis on >this scale. I agree. I have found ip accounting only useful for problem diagnosis (and in this scenario it is VERY useful). Any other use involves too much work to retrieve the data from the router at frequent intervals and then fiddly post-processing to get it into something useful (which is not necessary with NNstat, for example). Did cisco give any reasons why they did not wish to pursue some sort of filtered accounting ? Peter Elford, e-mail: P.Elford@aarnet.edu.au Network Co-ordinator, phone: +61 6 249 3542 Australian Academic Research Network, fax: +61 6 247 3425 c/o, Computer Services Centre, post: PO Box 4 Australian National University Canberra 2601 Canberra, AUSTRALIA
eckert@medusa.informatik.uni-erlangen.de (Toerless Eckert) (11/07/90)
From article <29341@boulder.Colorado.EDU>, by pte900@jatz.aarnet.edu.au (Peter Elford): Talking about IP accounting: Is there a way too initiate the "clear ip accounting" command by means of snmp ? I haven't found a variable that could do this (i.e.: by doing a snmp 'set' onto it). Another question: with a little programming (well, maybe a bit more) one could write nice programs using frequently retrieved accounting data to calculate traffic dispersion between different ip connections. For example sampling the accounting data every 5 minutes, and subsampling the host/host pairs that produce most network traffic could provide a nice 'top' tool for monitoring. Has anybody done these kind of things ? -- Toerless Eckert | /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert V.4: Noah's ark of Unix | X.400 ^ Internet> eckert@informatik.uni-erlangen.de
robel2@mythos.ucs.indiana.edu (Allen Robel) (11/08/90)
>Did cisco give any reasons why they did not wish to pursue some >sort of filtered accounting ? > >Peter Elford, e-mail: P.Elford@aarnet.edu.au >Network Co-ordinator, phone: +61 6 249 3542 >Australian Academic Research Network, fax: +61 6 247 3425 >c/o, Computer Services Centre, post: PO Box 4 >Australian National University Canberra 2601 >Canberra, AUSTRALIA I forwarded some correspondence I had with cisco directly to Peter but did not think it appropriate to send this everyone. If others are interested in this feature I would suggest letting cisco know and perhaps cisco can respond to the list. cisco didn't actually say that they wouldn't implement this feature; just that it would require "hardware assist." regards, Allen Robel robel2@mythos.ucs.indiana.edu University Computing Services ROBELR@IUJADE.BITNET Network Research & Planning voice: (812)855-7171 Indiana University FAX: (812)855-8299
forster@cisco.com (Jim Forster) (11/08/90)
I thought I'd add a bit of background to the discussion: When we did the IP accounting, we envisioned the need for two crucial pieces -- lots of memory dedicated to the accounting function, and a fairly sophisticated "back end" data base application to crunch the raw data into useful form. If you dedicate 1 Mbyte of memory to IP accounting, then there is enough room to hold over 30,000 accounting entries. We guessed that this would be enough entries for at least 15 minutes of traffic for a busy hub (anyone care to contribute some data confirming or disproving this?). We also knew that 30,000 raw accounting entries is useless unless digested into a convenient form. That's where the sophisticated DB application comes in -- it can massage the data into per-subnet, or any other arbitrary billing grouping desired. The advantage of collecting the raw data as per-host is that it's less effort for the router, and you don't throw away information that may be useful. The disadvantage is that you need a lot of memory, and you probably don't want to use SNMP Get-next's to read 30,000 entries. Unfortunately, no one has done the type of application that we envisioned. Our 8.2 release will add accounting access lists, to specify what packets should be counted, and an option to only count packets sourced from or destined to a connected network. -- Jim
gfw@pueblo.att.com (11/09/90)
I would like to second the sentiments of Vikas Aggarwal on providing a mechanism to filter packets included in cisco's IP accounting table. Actually, I would also like an extension to the mechanism provided by the "access-list" mechanism. The access-list would allow screening on the basis of src and dst addresses, but the table would still (probably) appear as host src, dst pairs. This would definitely be an improvement over the current situation, but not as useful as I would like. The extension I would propose would be a mechanism that allowed aggregation of octet and packet counts based on some maskable portion of the addresses. For example, using a filter mask of 255.255.255.0 for a class C network, I could get an IP accounting entry that reflected the total counts of all hosts on that network (rather than for each host). I realize that I could accumulate the host detail information to obtain subnet-based totals. The problem is (as Vikas pointed out) there are simply too many (src, dst) pairs in a large internet for that level of detail to be kept in the router's memory (and it fills up too fast to be able to snarf and clear before you start losing data in the "overflow" area). By providing aggregation in the router you reduce the overhead of constant polling and clearing, not to mention the reduction in memory use and the potential for more accurate data (less ending up in the overflow area). Greg Wetzel (708) 979-4782 G_F_Wetzel@att.com AT&T Bell Laboratories (IH 1B-213) 2000 N. Naperville Road Naperville, IL 60566
aggarwal@nisc.jvnc.net (Vikas Aggarwal) (11/09/90)
>> Our 8.2 release will add accounting access lists, to specify what >> packets should be counted, and an option to only count packets sourced >> from or destined to a connected network. If its something along the concept of your "extended access lists", it would be great. On another topic, did cisco ever add the "reliability" variable in the list of SNMP variables as a "route metric variable" ? Right now, I can get everything but "reliability" via SNMP, and since the igrp metric takes the reliability of the line into account, I don't see why it is not retrievable, especially since the SNMP variable exists (_ip_ipRoutingTable_ipRouteEntry_ipRouteMetric[1234]). It seems to be giving me the "hop" count presently - any reason why the hop count (if it is not used in your metric ??). -vikas vikas@jvnc.net (609) 258-2403 Network Engineering -2400 JvNCnet, Princeton, NJ ----------------------------------------------------------------------------- Ford-Gateway>sh route 46.0.0.0 Routing entry for 46.0.0.0 (mask 255.0.0.0) Known via "igrp 97", distance 100, metric 35910 Redistributing via igrp 97 Last update from 130.94.0.67 on Ethernet1, 1 seconds ago Routing Descriptor Blocks: * 130.94.0.67, from 130.94.0.67, 1 seconds ago, 373 uses, via Ethernet1 Route metric is 35910, traffic share count is 1 Total delay is 294000 microseconds, minimum bandwidth is 1536 Kbit Reliability 242/255, minimum MTU 1500 bytes Loading 48/255, Hops 7 _mgmt_mib_ip_ipRoutingTable_ipRoute_ipRouteMetric1_46.0.0.0 0x8c46 35910 _mgmt_mib_ip_ipRoutingTable_ipRoute_ipRouteMetric2_46.0.0.0 0x600 1536 _mgmt_mib_ip_ipRoutingTable_ipRoute_ipRouteMetric3_46.0.0.0 0x47c70 294000 _mgmt_mib_ip_ipRoutingTable_ipRoute_ipRouteMetric4_46.0.0.0 0x7 7
cdr@hobbes.amd.com (Carl Rigney) (11/09/90)
Has everyone forgotten the basic SNMP principle that agents should be kept simple and the network management station should do any sophisticated processing? In an afternoon I wrote a perl script that uses the CMU snmpwalk to retrieve the cisco accounting table, flag the addresses it doesn't think are valid hosts, and print it out. A pass through sort and head then gives you the top talkers. Drop me a line if you want a copy. If you only want to query for a given subnet, that's easy if you subnetted on byte boundaries, almost easy otherwise. I've got another program that does the same thing for etherfind, although its more detailed and rudimentary. It only took another afternoon to turn that data into a (so far, static) SGI Net Visualizer style plot that shows all the connections, colored to emphasize the biggest links. Access lists are great, and accounting lists are OK if they don't slow things down too much. I know the temptation to merge routers and network monitoring devices is strong because that way you need only one box instead of two, but implementing a lanwatch algorithm in hardware seems a little excessive! -- Carl Rigney cdr@amd.com
nipper@i32fs2.ira.uka.de (Arnold Nipper) (11/09/90)
In article <3230@medusa.informatik.uni-erlangen.de> eckert@medusa.informatik.uni-erlangen.de (Toerless Eckert) writes: >From article <29341@boulder.Colorado.EDU>, by pte900@jatz.aarnet.edu.au (Peter Elford): > [ stuff deleted ] >Another question: with a little programming (well, maybe a bit more) >one could write nice programs using frequently retrieved accounting data to >calculate traffic dispersion between different ip connections. For example >sampling the accounting data every 5 minutes, and subsampling the host/host >pairs that produce most network traffic could provide a nice 'top' tool >for monitoring. Has anybody done these kind of things ? I wrote a short awk script producing a top x list of host/host pairs. Input data for awk is retrieved by Daniel Karrenbergs program to get IP Accounting from the cisco via a telnet like session. Output looks like: TOTAL bits/s KByte shost dhost % KByte shost dhost % KByte shost dhost % KByte ... ... ... ... TOTAL means total throughput over all interfaces. % is the percentage of the shost/dhost connection where 100% is the TOTAL throughput. I use the "Accounting data age is" line to calculate bits/s. This is reasonable if the polling period is long enough but will give quite incorrect data when the period is short. But anyway the % still holds and gives a good look of which host/host is consuming most of the bandwidth. The list length can be set by specifying the percentage to which you want to see shost/dhost pairs e.g down to 10% of total throughput. I would like to have accounting data indexed by interface number too. Than it would be easier to compute bandwidth consuming of each line connected to you cisco. OK, I know, this will not reduce memory consumption for IP accounting but I think this would be a nice feature. Arnold ******************************************************************************** Arnold Nipper *** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ********************************************************************************
satz@cisco.com (Greg Satz) (11/09/90)
I refer you to the latest draft of the MIB-II on nnsc.nsf.net in the internet-drafts directory. We are working with the IETF SNMP-WG to add the required MIB variables. 8.2 supports MIB-II. Greg
haddad@hplred.hpl.hp.com (R. Peter Haddad) (11/11/90)
Does anyone have accurate numbers for the performance cost of IP accounting as it currently is implemented ? How would adding extended access lists for accounting impact this ? Accounting is all well and good, but I think HPLabs needs to understand the cost before jumping in wholeheartedly. Thanks R. Peter Haddad RS Network Engineering HPLabs
haddad@hplred.hpl.hp.com (R. Peter Haddad) (11/13/90)
From: Greg Satz <satz@cisco.com> Any extra instructions executed while forwarding a packet take away from the overall performance. The IP accounting feature as it is presently implemented tries to be as efficient as possible without doing anything extra. One can perform tests against the router with and without IP accounting enabled to see what the performance ramifications are. Greg Allow me to restate my question, has anyone at cisco or elsewhere performed these tests ? Peter