Hi Tim -
One more question, please?
I understand what's going on better based on your comments. I like mapping
to the interface level this way much better than our previous method of a
router icon for each interface; it yields a much tidier model.
I'm unclear just how to construct dependencies to get the results we
want/are used to. Say my near-end Router A has 2 serial links to Routers B
and C. Mapping these devices in version 5 with (icons & IPs for each
interface) we would typically set an "up dependancy" for RouterA-S1/0 on
RouterB and an "up dependency for RouterA-S1/1 on RouterC. Then, should
either link or far-end router fail, the near-end interfaces would not be
polled, preventing a cycle of down-up notifications while the near end
router attempts to recover its link partner.
It appears that implementing WUG V7's interface service I can only set one
such dependency, unless there's a way to set dependencies specific to an
'up' interface service. Per the example above, RouterA would only have one
appearance in the table shown at the Dependencies Tab, not one appearance
for each interface. Same thing using the Console GUI - if I rightclick >
set dependencies, I can subsequently select only one other device's
connection. Yet it's only logical that various interfaces would have
different dependencies and be related to multiple partners...
Is it possible to do this using the interface service and without going
back to the practice of cloning icons?
I had hoped I could drag and drop to multiple levels under the Dependencies
Tab, but that does not seem to work.
Thanks for your consideration on this followup!
-Don McCotter (#SWG002915)
"Tim Farley"
<[EMAIL PROTECTED] To:
<[EMAIL PROTECTED]>
> cc:
<[EMAIL PROTECTED]>
Sent by: Subject: RE: [WhatsUp Forum]
More Router Interface Service
[EMAIL PROTECTED]
switch.com
01/09/02 12:47 PM
Please respond to
WhatsUp_Forum
> I scanned up some routers that fit the profile of my custom device
> 'Cisco3600' - that template includes the Interface service. My newly
> discovered device gets modeled but quickly goes magenta,
> indicating service down.
Ah, I see where your original issue came from. We added something to
services in 7.0 that you are missing out on, and it happens that the auto
discovery is filling it in for you. Let me explain.
When you add a service manually to a host (by clicking ADD in the Services
list for that host), you now get a dialog that has three input boxes. Two
of these are new. One is a "comment" field that lets you record why you
are
monitoring that service. No explanation needed there.
But the other (the middle one on the dialog) is marked "Arguments". This
is
a new capability in WUG 7.0 that allows a special customization value be
passed to each service to match it to particulars of that host.
(The fact that you used a custom host type to put Interface on your hosts
helped hide this from you, since you didn't get to see the Add dialog from
there).
In previous versions of WUG, if you wanted to use the SNMP Threshold
service
to monitor interfaces, you would have had to set up a separate custom
service for each possible interface number on the target. I.e. one to
monitor "Interface 1", another to monitor "Interface 2" and so on. It was
very tedious.
In WUG 7 this new argument field allows us to have a single custom service
definition called Interface, and store the interface numbers with the host,
where they belong.
The flip side of this is that if you create an "Interface" service
definition on a host manually, and you leave the Argument blank, it will
fail! The argument is essential because of the way "Interface" is defined.
That's why you were seeing a down result.
If you open Logs | Debug Log..., and then right click the affected host and
choose Check Now (or waited for a poll), you would have seen something like
this:
Checking 192.168.0.1 : 00 : Interface No argument
SNMPMON [Interface] OID:1.3.6.1.2.1.2.2.1.8 on IP:192.168.0.1
SNMPMON ERROR: SNMP GET failed!
Check Complete (-2) 192.168.0.1 : 00 : Interface No argument
That would have showed you why it was failing - because there was no
argument present. The MIB-II OID 1.3.6.1.2.1.2.2.1.8 is not a valid one to
fetch, you need at least one more element on there to specify which
interface number you are requesting. That's what the (missing) argument
supplies.
When you use Auto Discover to fill in the Interfaces, these arguments get
filled in for you automatically, based on what the host actually has. I
recommend you use Auto Discover (or Discover Devices / New Map Wizard,
which
do the same thing) to populate your Interface services, rather than doing
it
manually.
The argument field is actually generically useful for any custom service
you
build that is based on the "SNMP Monitoring" monitor. It always gets
appended to the OID that is in the custom service at poll time. So you can
build your own SNMP checks that behave the way Interface does in this
respect (minus the auto-discovery part).
Currently there aren't any other service monitors (besides "SNMP
Monitoring") that use the custom argument, but it is exposed through the
API
so third parties can use it if needed. (Indeed, in WUG 7 all the service
monitoring uses the very same API we publish to the outside world).
Hope that makes sense.
--Tim Farley
IPSWITCH
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/whatsup_forum%40list.ipswitch.com/
******************* PLEASE NOTE *******************
This message, along with any attachments, may be confidential or legally
privileged. It is intended only for the named person(s), who is/are the
only authorized recipients. If this message has reached you in error,
destroy it without review and notify the sender immediately. Thank you.
**********************************************************
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/whatsup_forum%40list.ipswitch.com/
