Joey Officer wrote:
Dave,

Thanks for this tip, I see the biggest difference between the command you
supplied and the command I was using is the version of the SNMP
implementation.  I was under the impression that the version was v2 so I
apologize for assuming, and not trying earlier.  Fortunately, using your
step, I do begin to see data, however there are a couple of things that
concern me.  I'll post the data that I see:

[EMAIL PROTECTED] harryk]$ snmpwalk -v 1 -c public -m
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt firewall
1.1.0 = "Linux firewall 2.4.20 #1 Sun May 11 18:53:34 CEST 2003 i586"
<snip limited snmp info>

From the firewall itself, try:
  snmpwalk localhost public

This same command (with localhost replaced with the actual IP or DNS name of your firewall, ie: snmpwalk 192.168.1.1 public) should work on any other system running net-snmpd, and typically returns *PAGES* of information.

I get basically the same thing when I remove the -m option.  At anyrate, I
see that I am atleast able to pull information (some) however what I have
noticed is that I do not see any statistical information.  From what I have
read through the snmpd.conf and through the maillinglist, I should be able
to use it without any major modification to the snmpd.conf file.  So I guess
my next question is, do I need to modify the snmpd.conf file in order to
retrieve eth 0/1/2 data, cpu usage, mem usage, etc... or should it work in
its default form?

I think some modifications to the configuration are required...at least I always modify the config when bringing a new router online (it's been long enough since I've done this, however, I don't remember exactly what if anything needs to be changed for basic functionality).


Here's my current Bering snmpd configuration (with snmp community changed to public), which works fine for reading interface stats, processor load, etc. (warning: Lines will probably wrap, but you should be able to figure out the proper format given the example config file):

###############################################################################
#
# snmpd.conf:
#   An example configuration file for configuring the ucd-snmp snmpd agent.
#
###############################################################################
#
# This file is intended to only be as a starting point.  Many more
# configuration directives exist than are mentioned in this file.  For
# full details, see the snmpd.conf(5) manual page.
#
# All lines beginning with a '#' are comments and are intended for you
# to read.  All other lines are configuration commands for the agent.

###############################################################################
# Access Control
###############################################################################

# As shipped, the snmpd demon will only respond to queries on the
# system mib group until this file is replaced or modified for
# security purposes.  Examples are shown below about how to increase the
# level of access.

# By far, the most common question I get about the agent is "why won't
# it work?", when really it should be "how do I configure the agent to
# allow me to access it?"
#
# By default, the agent responds to the "public" community for read
# only access, if run out of the box without any configuration file in
# place.  The following examples show you other ways of configuring
# the agent so that you can change the community names, and give
# yourself write access to the mib tree as well.
#
# For more information, read the FAQ as well as the snmpd.conf(5)
# manual page.

####
# First, map the community name "public" into a "security name"

#       sec.name  source          community
com2sec notConfigUser  default       public

####
# Second, map the security name into a group name:

#       groupName      securityModel securityName
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser

####
# Third, create a view for us to let the group have rights to:

#       name           incl/excl     subtree         mask(optional)
view    systemview     included      system

####
# Finally, grant the group read-only access to the systemview view.

# group context sec.model sec.level prefix read write notif
access notConfigGroup "" any noauth exact systemview none none


<everything past here is commented>

--
Charles Steinkuehler
[EMAIL PROTECTED]


------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to