From: Tim Last (packtmon@yahoo.com)
Date: Sat Apr 10 2004 - 10:00:50 GMT-3
Is that possible? There are things more exciting than SNMP and Rmon? Perhaps, but I doubt they're as vaguely documented as this stuff.
You're right about it now being time to move on to another topic. Care to talk about voice?
In any case, I'm glad to be rid of all those nagging doubts. Thanks again, Tim
Scott Morris <swm@emanon.com> wrote:
heheheh... no problems, glad I could help.
Yes, yes and yes...
I believe you have it now!
Guess that means you get to move onto to something more exciting now! (grin)
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
_____
From: Tim Last [mailto:packtmon@yahoo.com]
Sent: Friday, April 09, 2004 9:35 PM
To: Scott Morris; 'Brian McGahan'
Cc: 'Group Study'
Subject: RE: Rmon & SNMP
Hey Scott,
Your'e the best. I've been seeking an answer to that question for a while
now and was never able to find or hear a satisfactory answer until now.
Thanks so much.
Now, putting everything you've told me together, can I conclude the
following?
Even though Rmon can be config'ed in such a way that it just waits until
it's polled by snmp, as a practical matter, that's not what it was designed
for. Furthermore, from the point of view of the lab, if Rmon needs to be
configured, I should also config, at a minimun the snmp-server host command,
so that Rmon knows where to send it's event when it's triggered by an alarm.
In addition, if an Rmon event is going to generate an snmp trap, I must also
config the "trap parameter. It's NOT optional if a trap is to
be sent.
As you could probably tell, these questions had been really annoying me, so
now knowing these details is tremendously gratifying. Thanks for clearing
all this up.
Tim
Scott Morris wrote:
That's an awfully good question. And logically, it would stand to reason if
you could find an object to poll through SNMP in order to gather the RMON
log, then yes. However, it's hard to find any intelligent listing of HOW to
do that. :)
There appears to be a CISCO-RMON-CONFIG MIB, an RMON-MIB and RMON2-MIB. The
SNMP Object Navigator on CCO will help with this. In pondering through the
RMON-MIB, there is an polling object type called 'logTable' and this would
contain the sequence of log entries...
So the long-winded answer to your question, is yes. You could do it
passively.
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
_____
From: Tim Last [mailto:packtmon@yahoo.com]
Sent: Friday, April 09, 2004 8:35 PM
To: swm@emanon.com; 'Brian McGahan'
Cc: 'Group Study'
Subject: RE: Rmon & SNMP
Hey Scott,
Thanks so much for responding. You cleared alot of my questions, but one
question I still have is this. Must a rtr be configured so that when Rmon
has something to say ( a trap) it also has a way (snmp) to tell someone
(snmp mgr) or is it possible for Rmon to just hold it's tongue (the trap)
until the snmp mgr gets around to asking Rmon for what it knows (snmp poll)?
I know how to configure the 1st scenario but I'm not sure if the 2nd
scenario is possible or exactly how it would be configured.
BTW, I'm very grateful Brian isn't the only guru and great guy roll into
one.
Thanks again, Tim
Scott Morris wrote:
Now Tim... Every once and a while people who know things come out and post
them. :) On the other hand, there is a plethora of e-mail on this list to
go through and only so many hours in the day! (on the other hand, if we got
rid of February, we could increase every other day of the year by 4 hours
and it would work out)
The RMON alarm is your on/off switch for something that is happening. The
RMON event is what you do when that happens. So if you're an event sitting
around going "I need to tell someone something", how do you know when to
tell them if you don't have an alarm?
The big difference for things is that SNMP works on a polling process. The
router just 'does' what it's told (in config) or what it's asked (by get
requests). RMON on the other hand does things on its own WHEN something
happens. Hence the relationship to alarms and events.
As for the community part, look at the rest of the event line. You have:
Log -- creates a log entry (perhaps you syslog this?)
Trap (comm) -- triggers a trap (more later)
Description (string) -- Just is a chunk of text to go with the event being
triggered
Owner (string) -- Another chunk of text.
So whatchya gonna do with it? Log is simple to see. You log it. The trap
needs to be tied to whatever you have set up for your snmp devices. So yes,
there is a relationship there.
For your text, take a look at some of the show commands (show rmon history,
show rmon alarms, etc.) and see what's being sent out.
The snmp-server host (ip|name) [(comm)] -- this sets up a listing of devices
that may be talked to and which community they work with
Snmp-server enable traps [optional-stuff] -- this actually enables the
process of when a trap or inform is received to proactively go tell the
server device about it rather than waiting for a poll. Remember that snmp
is a largely passive technology.
So to answer your question, once you create an alarm you create the ability
to "notice" something. The event is what you are going to do about it when
you notice it. If you log yourself, that's all you need. If you are going
to tell someone else (trap) then you also need the snmp commands to tell
your device what to actually do with the traps. Otherwise, it's gonna sit
there like a little kid thinking "I have something to tell someone" but not
know who or how or why. :)
Hope that helps a bit...
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tim
Last
Sent: Friday, April 09, 2004 7:24 PM
To: Brian McGahan
Cc: Group Study
Subject: Rmon & SNMP
Hi Brian,
I'm writing you because there doesn't seem to be that many people on GS who
really know Rmon & SNMP that well ( or don't reply to questions about this
topic.) So, I'm hoping maybe you could help me better understand this.
(True guru's and great persons don't often come in one package.)
I'm trying to understand the inter-dependencies between certain commands and
unfortunately the documentation is not that comprehensive and I can't test
this in my lab.
Re: the Rmon event command.
Can or does this command do anything if the Rmon alarm command isn't also
configured? If yes, what?
If the trap option is used, what happens if no snmp commands
are configured? (I assume not much because the device doesn't know where to
send the trap, correct?) Is this option needed so that an snmp mgr can poll
this device and get the traps that have accumulated, again assuming no snmp
commands have been configured?
On the other hand, if the snmp-server community command is configured, is
the trap still required? Why?
The command reference says, "This configuration also generates a Simple
Network Management Protocol (SNMP) trap when the event is triggered." What
does generate an snmp trap actually mean?
What does Rmon (or snmp) do with the other 2 options, description and owner?
Re: the Rmon alarm command.
Can this command be used without the Rmon event command? If yes, what? My
guess is that without the Rmon alarm also configured, this command just
defines and stores any triggered alarms until an snmp mgr polls for the
info. I am close?
I'm sorry for all the questions. I've checked all the Cisco documentation
and several books but still I haven't been able to find out much detail
about how these various parameters real work and what they actually do. Any
help you can provide is greatly appreciated.
Thanks, Tim
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:45 GMT-3