Limit Number of Interfaces Returned

[FlyingDuffman]

I am having a problem setting up querying for SNMP Interface Statistics on a Cisco router. The issue appears to be that there are a very large number of ATM interfaces on the device and there is not a lot of available bandwidth on the T1 connections going to the device. I have been unable thus far to successfully add SNMP Interface Statistics as polling all the interfaces brings then entire network to a grinding halt causing widespread complaints from the DSL users that run through the router. Is there any way I can poll (add interfaces for) ONLY the serial interfaces? That's all I'm interested in getting, I do not need anything else.

[gandalf]

The initial setup of the table will require a lot of snmp traffic to that host, indeed.
As soon as you have the Interface Table set up (you see if when "Create Graphs for this Host" was selected), you may select only the SE interface you're interested in. This is the only one that will be pollerd, then.
Reinhard

[FlyingDuffman]

The initial setup of the table will require a lot of snmp traffic to that host, indeed.
As soon as you have the Interface Table set up (you see if when "Create Graphs for this Host" was selected), you may select only the SE interface you're interested in. This is the only one that will be pollerd, then.
Reinhard

The problem is that I cannot get the initial set of interfaces That's my hangup, I need to find a way to only get either the serial interfaces or only return a certain number of interfaces. I think there is simply too much traffic to do this and it eventually times out (after killing performance of the DSL users while it runs) and then returns an Interface list with a bunch of blank interfaces.

The serial interfaces are ussually before the ATM interfaces, so if I could find a way to only do SNMP statistics for the first 50 interfaces I would probably be fine.

[gandalf]

AFAIK, there is no such options. The Settings -> Visual -> Javascript Rows will limit the numbers of rows displayed but will not limit the amount of information retrieved from the device.
Some time ago, there was a discussion on some REGEXP for filtering "relevant" indices only. But there was no progress in this topic.
Perhaps it would be possible using a very specfic OIR/REGEXP for the index parse option in interface.xml to limit cacti when polling the device initially. But this would require to find the SE-interfaces at specific indices only (or a specific but narrow range of indices). Are you able to define such a rule (e.g. only scan indices consisting of a single number, e.g. indices 0 .. 9)
Reinhard

[FlyingDuffman]

Hmmm... The interfaces I am interested in will all have a name something like Se0/0:0... so they should all contain the name "Se" followed by a number a slash, then a number colon number... that could be made into a regular expression.

I'm not sure how to impliment anywhere to use it though or how to setup rules, I'm afraid you're talking above my knowledge of Cacti at this point. Though maybe if you hum a few bars... or point me to a document/forum topic on this area.

Alternatively, if I know the description and types of interface, is there a way to manual enter in this information, hack it into a file or database row or something?

Thanks for your time so far.

[gandalf]

That does not help. Lets try to talk pure SNMP lingo.
You're talking about the interface table (e.g. snmpwalk -c .. -v 1 ... interface). If you run this command against some host, it will return sth. like

Code: Select all

IF-MIB::ifNumber.0 = INTEGER: 3
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: irda0
IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: other(1)
...

The ifIndex stuff denotes the numerical index that applies to all other data of this table (ifAlias, ifDescription, ifInOctets, ...). What I would need is a numeric range of indices that are of interest. E.g. if you see, that SE-stuff always appears between indices 3 and 7 (or whatever), I may try to find a solution
Reinhard

[lard]

Hello,

Just a thought but is there another router of this type with the exact same cards/interfaces on the network?

You could add this similair device, then change the ip address of it to the one which is unable to respond in time to your full snmp walk and then pick the interfaces to graph,

As long as the snmp ifindex numbers are the same (1 for loopback, 2 for serial0/0 e.t.c.) then it may work - or if you know the if index's from the manual snmpwalk then you can pick the one you are interested in

Either than or use the snmp generic template and add the specific oid for the interface you are concerned about (again, assuming you are able to find the snmp ifindex number, but if you have an identical router with the same cards (in the same slots!) then this could be gained from there)

HTH

Lard

[FlyingDuffman]

I tried each method and came to a similar conclussion... something is wrong with my router. Anytime an SNMP request is sent, the CPU usage is pegged and doing anything else on the router becomes very difficult.

I couldn't successfully complete an SNMP walk on the router, so I could not get interface names/numbers.

We do have another 7200 router so I setup things on that one and then changed the IP addressing. The graphs did work but it used so much CPU on the router (for two graphs) that I had to turn it off. I know that's not right because I've graphed hundreds of interfaces on our other router before I experienced any slow down and it was no where near the degree that I'm expreiencing on this router.

I'll probably try a flash update on the router and hopefully that helps. Otherwise it may be hardware related, but it's still under warranty so I should be okay. Thanks both of you for your help/suggestions.

[gandalf]

We're currently running several 7200's with cacti. No SNMP issues on our side
Reinhard

[lard]

I've had problems with one 7200 and SNMP before - only in as much as it was already being polled for IP acounting info and was being asked to checkpoint the table and then send it via snmp, a "show proc cpu" showing snmp as being the culprit - though I was blamed in the first instance it's the ip accounting system that was at fault (as it took more than the 5 minute frequency it was being asked to send the table to create it) - we ended up swapping this out for a 7300 which is marginally better

HTH

Larry