Hello List,
AIX 4.3.3, Netview 6.03
does somebody know what are the parts of mibs that Netview need to have
access to with snmp, in order to properly discover a cisco routers?
The email from Leslie below describe something close to what I have to do
but the other way around.
We have lots of routers on our customer network that are managed by some
other organizations. We are negotiating with them to get a limited snmp
access in the routers that would allow us to discover the network (but not
necessarily the VPNE core network that interconnect our sites). A lot of
the remote sites don't have any routing devices that we control. So we need
to have snmp access to the provider router to see the existing subnets (ARP
and interface table and maybe something else ...?)
I want to implement in all these routers a view on the mibs that we need to
access and exclude everything else.
does anybody have experience in that ?
Thanks,
Regards,
Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Phone: (514) 205 6695
-----------------------------------
Date: Fri, 10 May 2002 15:03:15 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [NV-L] Router CPU usage high (repost)
Message-ID: <OF696024AD.56B88318-ON85256BB5.00682D53@raleigh.ibm.com>
A repost of a popular item...
Be careful when following the intructions below for limiting SNMP access.
If you remove access to too much, Netview will have trouble discovering
all interfaces and addresses on the device.
__________________
From: http://www.cisco.com/warp/public/490/ipsnmphighcpu.html
IP Simple Network Management Protocol (SNMP) Causes High CPU Utilization
This Tech Note explains how to troubleshoot high CPU utilization in a
router due to the IP_SNMP process, which can result from a network
management station using an SNMP walk to "find" the topology of a network,
coupled with a large route table in a smaller router. This problem can
effect lower end Cisco routers.
If you notice high CPU utilization on a Cisco router, and you determine
the cause is isolated to the IP_SNMP process using the output of the
show process cpu command, check the output of the debug ip snmp command
to see if the SNMP queries are being made to the router's entire route
table. As always, take precaution when running a debug over a production
network due to the potential for overwhelming the router.
Network Management stations query routers for their entire route table
to learn what other networks the router knows about. It uses this
information to find other routers, and query them about their knowledge
of networks around them. In this fashion, the management station can
learn the topology of the entire network. The route table is stored in
the router in a hashed format, more conducive to quick route searches.
However, SNMP requests for the route require the router to first sort
the table into sequential order due to the way in which the router responds
to queries. The management station sends requests asking for the "next
route entry" one entry at a time until the router has sent the whole table.
Every time the router sees a "get next route" request, the router must
determine the last route it sent, then sort the entire table sequentially
to find the next route to send in sequence. This process is very CPU
intensive,
as the entire routing table is sorted from top to bottom every time it gets
one of these requests, and it gets a request for each individual line in
the route table.
SNMP is a low priority process as far as the CPU scheduler is concerned,
so if another process requires CPU resources, it generally takes priority.
As such, while CPU spikes occur in this scenario, they shouldn't effect
performance at first. To avoid performance issues, force the router to
prematurely end the queries for the route table from the network management
system server. (**Note from L.C I believe here they mean limit the number
of route table entries in Netview's snmp configuration dialog where the
default is 800.) Configure the router to respond with a "complete" message
as soon as it receives the start of a request for the route table, as
follows:
snmp-server view cutdown internet included
snmp-server view cutdown ipRouteTable excluded
snmp-server view cutdown ipNetToMediaTable excluded
snmp-server view cutdown at excluded
snmp-server community public view cutdown RO
snmp-server community private view cutdown RW
This configuration blocks requests to retrieve the route table
(ipRouteTable)
and the Address Resolution Protocol (ARP) table (ipNetToMediaTable), but
allows all other requests through. Older versions of Cisco IOS Software
don't recognize the MIB object ipRouteTable, so the following configuration
should be used instead.
snmp-server view cutdown internet included
snmp-server view cutdown ip.21 excluded
snmp-server view cutdown ip.22 excluded
snmp-server view cutdown at excluded
snmp-server community public view cutdown RO
snmp-server community private view cutdown RW
In both of these examples, you can substitute your own community strings.
The outcome of these configuration changes is that the router doesn't
return either the ARP table or the IP route table when queried. This
prevents SNMP network discoveries from creating CPU spikes on the router
in question, but it also removes a degree of manageability from the router.
As a final note, routers that previously were not exhibiting this problem
may begin to do so if there is a change in their routing table. The amount
of cycles required to reply to the IP route table requests is a function
of the number of routes in the routing table. If the number of routes
increases, CPU utilization increases as well.
Related Information
SNMP Command Reference
More SNMP Technical Tips
All contents copyright 1992--2001 Cisco Systems Inc. Important Notices and
Privacy Statement.
|