Demand poll indicates that a ping is being used.
When I log on to the router and status the interface, it does indicate that
it is down.
The only thing peculiar about this setup is that there is a very large
amount of unmanaged devices. Could this be causing the delay?
Regards, Peter.
----- Forwarded by Peter Chow/CA/TDBFG/TDGROUP on 05/14/02 03:51 PM -----
nv-l-digest-help@lists.
tivoli.com To:
nv-l@lists.tivoli.com
cc:
05/13/02 06:38 PM Subject: nv-l Digest 13
May 2002 22:38:51 -0000 Issue 70
nv-l Digest 13 May 2002 22:38:51 -0000 Issue 70
Topics (messages 1301 through 1327):
Netview
1301 by: Fission CC Lin
Ciscoworks Intergration
1302 by: Simon Collins
1306 by: Yang, Peter
Re: Bandwidth Usage
1303 by: Leslie Clark
Re: RFI
1304 by: Leslie Clark
Re: Switch Analyzer meeting details
1305 by: Pam Geiger
Re: packet errors -- how do you monitor?
1307 by: Leslie Clark
1309 by: Todd H.
1311 by: Leslie Clark
1318 by: Todd H.
Netview 7.1 Training
1308 by: reamd.Nationwide.com
Netview Traps - Time to post
1310 by: Peter_Chow.TD.COM
1326 by: Leslie Clark
cant collect snmp on certain devices
1312 by: Duble, Ethan
1327 by: Leslie Clark
Re: packet errors -- (cisco links)
1313 by: Leslie Clark
Question about forwarding node down event to TEC.
1314 by: Westphal, Raymond
1316 by: Stephen Hochstetler
1317 by: Westphal, Raymond
1323 by: Brett Coley
Re: NetView 7.1.1 installation (Lanugage kit)
1315 by: James Shanks
deleted segment
1319 by: D'Apice, Dominic
1320 by: Stephen Hochstetler
1321 by: D'Apice, Dominic
update : RE: [nv-l] deleted segment
1322 by: D'Apice, Dominic
1325 by: Stephen Hochstetler
trapgend
1324 by: Eric Pobst
Administrivia:
To subscribe to the digest, e-mail:
<nv-l-digest-subscribe@lists.tivoli.com>
To unsubscribe from the digest, e-mail:
<nv-l-digest-unsubscribe@lists.tivoli.com>
To post to the list, e-mail:
<nv-l@lists.tivoli.com>
----------------------------------------------------------------------
Date: Mon, 13 May 2002 12:05:17 +0800
To: nv-l@lists.tivoli.com
From: "Fission CC Lin" <flin@tw.ibm.com>
Subject: Netview
Message-ID: <OF29FAE381.C60E5DB3-ON48256BB8.00162BAD@tw.ibm.com>
RGVhciBhbGwsDQogICBUaGUgTmV0dmlldyB3aWxsIHJlY29nbml6ZSBzb21lIHNlcnZlcnMgKHR3
byBpbnRlcmZhY2UgY2FyZHMpIGFzIHJvdXRlcnMNCmJ1dCBhY3R1YWxseSBub3QuIFdoeSA/IElu
IHdoYXQgc2l0dWF0aW9uIHRoYXQgTmV0dmlldyB3aWxsIHJlY29nbml6ZQ0Kc29tZXRoaW5nIGFz
IHJvdXRlcnMgPyBmb3IgZXhhbXBsZSBtdWx0aXBsZSBpbnRlcmZhY2UgY2FyZHMgPyBvciBhbnkN
Cm90aGVycz8gIEhvdyBjb3VsZCBJIHJlc2V0IHRoZW0gdG8gb3JkaW5hcnkgc2VydmVycz8gICBQ
bGVhc2UgaGVscCwNCnRoYW5rcy4uLg0KDQpCZXN0IFJlZ2FyZHMsDQpGaXNzaW9uIExpbiwgqkyt
xaX+DQpJIC8gVCBTcGVjaWFsaXN0ICAsIFRpdm9saSBQcm9mZXNzaW9uYWwgU2VydmljZXMsDQpJ
VFMvU01CVS9OU00sICBJQk0gVGFpd2FuDQoyMDYsIFNlYy4xIEtlZWx1bmcgUmQsIFRhaXBlaSwg
VGFpd2FuLCBSLk8uQy4NClRlbDo4ODYtMi0yNzI1LTg4NzIsIE1vYmlsZTowOTM1LTU1ODYyMg0K
RS1NYWlsOiBmbGluQHR3LmlibS5jb20NCg==
------------------------------
Date: Mon, 13 May 2002 14:22:58 +0400
To: nv-l@lists.tivoli.com
From: "Simon Collins" <Simon@ae.ibm.com>
Subject: Ciscoworks Intergration
Message-ID: <OF3525AB38.B7AD231C-ON44256BB8.00388446@portsmouth.uk.ibm.com>
Hi,
I know this is a very general question but could anyone pls advise on how
many days it would possibly take to intergrate Ciscoworks into Netview and
what are the pitfalls etc to look out for ?
Thanks in advance,
Simon
_______________________________________
Simon Collins
GBM - Tivoli Services
Gulf Business Machines - Distributor of IBM WTC
PO Box 9226
Dubai, United Arab Emirates
+ 971 (0)50 65 66 417
Email: simon@ae.ibm.com
------------------------------
Date: Mon, 13 May 2002 08:58:58 -0400
To: "'Simon Collins'" <Simon@ae.ibm.com>, nv-l@lists.tivoli.com
From: "Yang, Peter" <peter.yang@lmco.com>
Subject: RE: [nv-l] Ciscoworks Intergration
Message-id:
<25AF30BCCD7BD411968200508BDF7FAE6EEB06@emss10m02.rck.atm.lmco.com>
It should be very straight forward to integrate Ciscoworks2000 with
Netview.
Here is what I know on this subject,
1. Netview has installation step to integrate CW2000 with Netview.
Ciscoworks has it too. This is a few minutes work.
2. The integration is an user command ( new menu item at top of map) to
start Ciscoworks2000. It is implemented with a new registration file. No
more than that. You can also start CW2000 by type >> netscape:<The C@2000
hostname>:1741.
3. You install Ciscoworks2000 first, this may take half a day. There are 5
or 6 CDs and it is kind of slow to install them all. If this is a brand
new
install to you, pls give yourself an extra day to read the manuals and do
some configurations. This installation has nothing to do with Netview.
For planning pupose, give yoruself a week to read the manuals, do the
installation, configuration and check things out.
-----Original Message-----
From: Simon Collins [mailto:Simon@ae.ibm.com]
Sent: Monday, May 13, 2002 6:23 AM
To: nv-l@lists.tivoli.com
Subject: [nv-l] Ciscoworks Intergration
Hi,
I know this is a very general question but could anyone pls advise on how
many days it would possibly take to intergrate Ciscoworks into Netview and
what are the pitfalls etc to look out for ?
Thanks in advance,
Simon
_______________________________________
Simon Collins
GBM - Tivoli Services
Gulf Business Machines - Distributor of IBM WTC
PO Box 9226
Dubai, United Arab Emirates
+ 971 (0)50 65 66 417
Email: simon@ae.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 08:05:54 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] Bandwidth Usage
Message-ID: <OF3A82031F.62F81660-ON85256BB8.004225D0@raleigh.ibm.com>
SSBhcG9sb2dpemUgZm9yIHRoZSBjb25mdXNlZCBhbnN3ZXIuICBMZXQgbWUgY2xhcmlmeToNCg0K
Rm9yIGhhbGYtZHVwbGV4LHVzdWFsbHkgb24gTEFOcywgeW91IGNhbiB1c2UgdGhpcyBleHByZXNz
aW9uOg0KDQpCYW5kd2lkdGhVdGlsSGR4IFwNCiI4KjEwMCooaWZJbk9jdGV0cytpZk91dE9jdGV0
cykgLyBpZlNwZWVkIiBcDQogICAgICAuMS4zLjYuMS4yLjEuMi4yLjEuMTAuICBcDQogICAgICAu
MS4zLjYuMS4yLjEuMi4yLjEuMTYuICtcDQogICAgICAuMS4zLjYuMS4yLjEuMi4yLjEuNS4gLyBc
DQogICAgICA4MDAgKg0KDQpGb3IgZnVsbCBkdXBsZXgsIHVzdWFsbHkgb24gV0FOcywgeW91IHNo
b3VsZCBtZWFzdXJlIGluYm91bmQgYW5kIG91dGJvdW5kDQp0cmFmZmljIHNlcGFyYXRlbHksIHNp
bmNlIHRoZSBsaW5rIGNhbiB1c2UgMTAwJSBvZiB0aGUgaWZTcGVlZCBpbiBib3RoDQpkaXJlY3Rp
b25zDQphdCB0aGUgc2FtZSB0aW1lOg0KDQpCYW5kd2lkdGhVdGlsSW4gXA0KIjgqMTAwKiBpZklu
T2N0ZXRzIC8gaWZTcGVlZCIgXA0KICAgICAgLjEuMy42LjEuMi4xLjIuMi4xLjEwLiAgXA0KICAg
ICAgLjEuMy42LjEuMi4xLjIuMi4xLjUuIC8gXA0KICAgICAgODAwICoNCg0KQmFuZHdpZHRoVXRp
bE91dCBcDQoiOCoxMDAqIGlmT3V0T2N0ZXRzIC8gaWZTcGVlZCIgXA0KICAgICAgLjEuMy42LjEu
Mi4xLjIuMi4xLjE2LiBcDQogICAgICAuMS4zLjYuMS4yLjEuMi4yLjEuNS4gLyBcDQogICAgICA4
MDAgKg0KDQpDb3JkaWFsbHksDQoNCkxlc2xpZSBBLiBDbGFyaw0KSUJNIEdsb2JhbCBTZXJ2aWNl
cyAtIFN5c3RlbXMgTWdtdCAmIE5ldHdvcmtpbmcNCkRldHJvaXQNCg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg
ICAgICAgICAgICAgICAgIEZpc3Npb24gQ0MgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
CiAgICAgICAgICAgICAgICAgICAgICBMaW5ASUJNVFcgICAgICAgICAgICAgICAgVG86ICAgICAg
IExlc2xpZSBDbGFyay9Tb3V0aGZpZWxkL0lCTUBJQk1VUyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNj
OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDA1LzEzLzIwMDIgMTI6MTAgICAg
ICAgICBGcm9tOiAgICAgRmlzc2lvbiBDQyBMaW4vVGFpd2FuL0lCTUBJQk1UVyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBBTSAgICAgICAgICAg
ICAgICAgICAgICAgU3ViamVjdDogIFJlOiBbbnYtbF0gQmFuZHdpZHRoIFVzYWdlICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQpE
ZWFyIHNpciwNCiAgV2hhdCBJIHdvdWxkIGxpa2UgdG8gYXNrIGlzIHdoeSB5b3Ugd2lsbCBleHBl
Y3QgbWUgdG8gdXNlICJmdWxsLWR1cGxleCINCmZvciBhIGxpbmsgYmV0d2VlbiByb3V0ZXJzIGFu
ZCB0aGUgZm9ybXVsYSB5b3UgcHJvdmlkZSAoIHN1bSBvZiBzZW5kIGFuZA0KcmVjZWl2ZSBkaXZp
ZGVkIGJ5IHRoZSBpbnRlcmZhY2Ugc3BlZWQgKSBzaG91bGQgYmUgdXNlZCBmb3IgaGFsZi1kdXBs
ZXggYnV0DQpub3QgZnVsbC1kdXBsZXguIEkgY2hlY2tlZCB0aGUgbWliRXhwci5jb25mIGFuZCBm
b3VuZCB0aGF0IE5ldHZpZXcgb25seQ0KcHJvdmlkZSB0aGUgaGFsZi1kdXBsZXggZm9ybXVsYSwg
Y291bGQgeW91IHNob3cgbWUgdGhlIGZ1bGwtZHVwbGV4IG9uZT8gSQ0KbmVlZCB5b3VyIGhlbHAu
ICBUaGFuayB5b3UgdmVyeSBtdWNoISEhDQoNClRoYXQncyB3aGF0IHRoZSBEYXRhIENvbGxlY3Rp
b24gZnVuY3Rpb24gaXMgZm9yLiBBbW9uZyB0aGUgcHJlLWRlZmluZWQgbWliDQpleHByZXNzaW9u
cyB5b3Ugd2lsbCBmaW5kIGJvdGggaGFsZi1kdXBsZXggYW5kIGZ1bGwtZHVwbGV4IGJhbmR3aWR0
aA0KdXRpbGl6YXRpb24uIFlvdSBuZWVkIHRvIGRldGVybWluZSB3aGljaCBpbnRlcmZhY2UgaXMg
aW52b2x2ZWQgaW4gdGhlIGxpbmssDQpieSBpbmRleCBudW1iZXIgaW4gdGhlIE1JQiBJSSBpbnRl
cmZhY2UgdGFibGUsIGFuZCBzdGFydCB1cCBkYXRhIGNvbGxlY3Rpb24NCm9uIG9uZSBlbmQsIG9y
IGJvdGggZW5kcy4gRm9yIGEgbGluayBiZXR3ZWVuIHJvdXRlcnMgSSBleGVjdCB5b3Ugd2lsbA0K
dXNlIGZ1bGwtZHVwbGV4IChzdW0gb2Ygc2VuZCBhbmQgcmVjZWl2ZSBkaXZpZGVkIGJ5IHRoZSBp
bnRlcmZhY2Ugc3BlZWQuKQ0KDQpTZWUgdGhlIG1hbnVhbCwgYW5kIHRoZSBvbmxpbmUgaGVscC4g
VGhlIGZ1bmN0aW9uIGlzIHVuZGVyDQogIFRvb2xzLi5NSUIuLkNvbGxlY3QgRGF0YS4NCg0KQ29y
ZGlhbGx5LA0KDQpMZXNsaWUgQS4gQ2xhcmsNCklCTSBHbG9iYWwgU2VydmljZXMgLSBTeXN0ZW1z
IE1nbXQgJiBOZXR3b3JraW5nDQpEZXRyb2l0DQoNCkJlc3QgUmVnYXJkcywNCkZpc3Npb24gTGlu
LCCqTK3Fpf4NCkkgLyBUIFNwZWNpYWxpc3QgICwgVGl2b2xpIFByb2Zlc3Npb25hbCBTZXJ2aWNl
cywNCklUUy9TTUJVL05TTSwgIElCTSBUYWl3YW4NCjIwNiwgU2VjLjEgS2VlbHVuZyBSZCwgVGFp
cGVpLCBUYWl3YW4sIFIuTy5DLg0KVGVsOjg4Ni0yLTI3MjUtODg3MiwgTW9iaWxlOjA5MzUtNTU4
NjIyDQpFLU1haWw6IGZsaW5AdHcuaWJtLmNvbQ0KDQoNCkJlc3QgUmVnYXJkcywNCkZpc3Npb24g
TGluLCCqTK3Fpf4NCkkgLyBUIFNwZWNpYWxpc3QgICwgVGl2b2xpIFByb2Zlc3Npb25hbCBTZXJ2
aWNlcywNCklUUy9TTUJVL05TTSwgIElCTSBUYWl3YW4NCjIwNiwgU2VjLjEgS2VlbHVuZyBSZCwg
VGFpcGVpLCBUYWl3YW4sIFIuTy5DLg0KVGVsOjg4Ni0yLTI3MjUtODg3MiwgTW9iaWxlOjA5MzUt
NTU4NjIyDQpFLU1haWw6IGZsaW5AdHcuaWJtLmNvbQ0KDQo=
------------------------------
Date: Mon, 13 May 2002 08:42:02 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] RFI
Message-ID: <OF9CBDCCBC.C087FB96-ON85256BB8.00435250@raleigh.ibm.com>
I think you would have to do what everyone did before there was RFI.
The usual approach was to ignore most of the events, and use rulesets to
handle
classes of events. Operators would only react to events that passed the
filters of the rulesets, and ignore the red areas of the map, focusing on
the device pointed out by the ruleset. A separate events display that
subscribes to that ruleset helps them with that focus.
- Core switches and routers: Interface Down/Up are very important.
- Remote routers: Node Down events - check for corresonding
interface events from core device; if none, then this is the cause
- Ignore as many lower-level remote devices as possible; for significant
remote servers and switches Node Down, check status of corresponding
remote router; if it is up, this is an isolated outage.
Others may have sample rulesets for T/EC and/or Netview that
implement this, but it is not likely that they will help your case
specifically.
They might be useful as a guide, however. Anybody?
Another approach might be to run them both, but let netmon poll the
routers.
This might result in double polling, if you are using more than one
Netview.
The RFI function enables netmon to generate special events - network
unreachable, Router Down, etc. You would still get the flood of down
events for downstream nodes, and you would still take the approach of
ignoring them, but these RFI events would simplify your ruleset processing
and reduce or eliminate the administrative burden of maintaining tables
of dependancies.
Either way, it is important that you not monitor anything that you do not
need to monitor. Specifically, if you do not really need every workstation
in the map, take measures (seedfile) to exclude them from discovery.
If the trap rate is your main concern, rather than notification, then this
is
your first line of attack.
If you are going to do RFI, you should try to get to the lastest code. It
is
always improving.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Kevin Smith
<c-kevin.smith1@w To: Nv-L
<nv-l@lists.tivoli.com>
com.com> cc:
Subject: [nv-l] RFI
05/10/2002 03:59
PM
Lists,
My servers IBM f50 AIX 4.3.3 Netview 6.02 MLM. I wold like to
implement rfi but the following says it's not possible:
CF Document ID: 1016900 - IBM Tivoli NetView: Can Netview 6.02 monitor
routers using RFI and MLM run at the same time?
Problem Desc: Can Netview 6.02 monitor routers using RFI and MLM run at
the
same time?
Solution: When running 6.02 Netview Unix (this was only tested on Unix
Netview) do not
use MLM's to monitor Routers when using RFI. This is a current limitation
on
the product.
Is there anyone that has an MLM and has the functionality that RFI has
without implementing RFI. The functionality I seek is that when a link
goes
down I dont get traps from netmon for every interface of the node behind
that link reporting down. Instead I would like to see that node be
unreachable and receive an alarm from the source of the failure.
Sincerely
Kevin Smith
System Administrator
410-965-0328
c-kevin.smith1@wcom.com
9-5p.m (est)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 08:45:57 -0400
To: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>
From: "Pam Geiger" <pgeiger@us.ibm.com>
Cc: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>,
"Netview - List (E-mail)" <nv-l@lists.tivoli.com>,
"'reamd@Nationwide.com'" <reamd@Nationwide.com>
Subject: RE: [nv-l] Switch Analyzer meeting details
Message-ID: <OF21A9FDB7.3A56C266-ON85256BB8.00454E9D@raleigh.ibm.com>
Dominic,=20
The main difference is that it adds the support for Tivoli Switch=20
Analyzer and the initial integration with Tivoli Enterprise Console.=20
Pam
Pam Geiger
Tivoli Performance and Availability Evangelist
pgeiger@us.ibm.com
919-224-1665, T/L 687-1665
"D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>
05/10/2002 11:13 AM
=20
To: "'reamd@Nationwide.com'" <reamd@Nationwide.com>, "D'Apice,
=
Dominic"=20
<D.D'Apice@SAQ.qc.ca>
cc: "Netview - List (E-mail)" <nv-l@lists.tivoli.com>, Pam=20
Geiger/Raleigh/IBM@IBMUS
Subject: RE: [nv-l] Switch Analyzer meeting details
=20
and shortly what the difference between 7.1.1 and 7.1.2 ?=20
it is also a "maintenance level release" same as netview 7.1.1 ?
Dominic=20
-----Message d'origine-----
De : reamd@Nationwide.com [mailto:reamd@Nationwide.com]
Envoy=E9 : 10 mai, 2002 11:09
=C0 : D'Apice, Dominic
Cc : Netview - List (E-mail); 'Pam Geiger'
Objet : RE: [nv-l] Switch Analyzer meeting details
Per the Emeeting, it was said that 7.1.2 would be available at the end of
May..
=20
"D'Apice, Dominic"
<D.D'Apice@SAQ.qc.ca> To: "'Pam Geiger'"
<pgeiger@us.ibm.com>=20
cc: "Netview - List
(E-mail)" <nv-l@lists.tivoli.com>=20
bcc:
Subject:
RE: [nv-l] Switch Analyzer meeting=20
details
05/10/2002 10:55 AM
=20
=20
Hi, in your ppt presentation you mention NetView 7.1.2, is this version
exist ?
-----Message d'origine-----
De : Pam Geiger [mailto:pgeiger@us.ibm.com]
Envoy=E9 : 30 avril, 2002 16:16
=C0 : nv-l@lists.tivoli.com
Cc : Mike Odom
Objet : [nv-l] Switch Analyzer meeting details
Folks,
Here is the information on the Switch Analyzer presentation on Friday. Let
me know if you have any questions or problems. Please note that for the
emeeting you will need to dial in as well as connect to the emeeting site.
Essentials
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Meeting Name IBM Tivoli Switch Analyzer
Start Time Fri May 3 10:00am 2002 EDT (UTC -4)
Duration 1hr30mi
Password itsa1ov
Moderator Pam Geiger
Meeting Bookmark
For IBMers
http://d02db541.southbury.ibm.com/team/emeetings=5Fout/stconf.nsf/openMeeti
=
ng?
openAgent&00768C458B678C5285256BA5006EFB09
For Customers
http://www-125.ibm.com/team/emeetings/stconf.nsf/ExtBookmarkView/IBM%20Tivol
i%20Switch%20Analyzer
Call in Information:
CALL DATE: MAY-03-2002 (Friday)
CALL TIME: 10:00 AM EASTERN TIME
DURATION: 1 hr 30 min
USA Toll Free Number: 888-889-6317
USA Toll Number: +1-630-395-0195
PASSCODE: TIVOLI
LEADER: Ms Pam Geiger
When you call you will be asked for your name as well as the name of your
company. The slides are available online now, thanks to our friends at
Magnum Technologies at:
http://www.magnum-tech.com/ibmtivoli/Netviewlist-presentation.ppt
You can view the presentation from there or use 'Save As' to download the
powerpoint file.
This time I asked the audio conference folks to put all but the speaker
lines on mute during the presentation portion since we had some problems
with folks using cell phones the last time. I hope it won't take away from
the presentation too much. For those who are accessing the emeeting, you
will still have the chat option for entering questions during the
presentation itself.
I look forward to talking to you on Friday.
Pam
Pam Geiger
Tivoli Performance and Availability Evangelist
pgeiger@us.ibm.com
919-224-1665, T/L 687-1665
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 09:18:11 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] packet errors -- how do you monitor?
Message-ID: <OFB0812F82.7B086A95-ON85256BB8.00484A7E@raleigh.ibm.com>
These are the ones in the current mibExpr.conf, and are what I have been
using for years. They are what was outlined some time ago in a Cisco
document that covered recommended mib monitoring. Both should
usually be thresholded at 1%, depending on your network. I'm presently
using the ErrorRate on WAN links and find that repeated thresholds
exceeded of more than 2% or 3% generally presages a link failure.
DiscardRate \
" (ifinDiscards+ifOutDiscards) * 100 \
\ (ifInUcastPkts + ifInNUcastPkts + \
ifOutUcastPkts + ifOutNUcastPkts)" \
.1.3.6.1.2.1.2.2.1.13. \
.1.3.6.1.2.1.2.2.1.19. + \
.1.3.6.1.2.1.2.2.1.11. \
.1.3.6.1.2.1.2.2.1.12. + \
.1.3.6.1.2.1.2.2.1.17. + \
.1.3.6.1.2.1.2.2.1.18. + / 100 *
ErrorRate \
" (ifinErrors+ifOutErrors) * 100 \
\ (ifInUcastPkts + ifInNUcastPkts + \
ifOutUcastPkts + ifOutNUcastPkts)" \
.1.3.6.1.2.1.2.2.1.14. \
.1.3.6.1.2.1.2.2.1.20. + \
.1.3.6.1.2.1.2.2.1.11. \
.1.3.6.1.2.1.2.2.1.12. + \
.1.3.6.1.2.1.2.2.1.17. + \
.1.3.6.1.2.1.2.2.1.18. + / 100 *
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
netview@toddh.net
(Todd H.) To:
nv-l@lists.tivoli.com
cc:
05/10/2002 06:27 Subject: [nv-l] packet
errors -- how do you monitor?
PM
Please respond to
nv-l
Howdy,
I've got a best practices/survey question for the masses. How are
you monitoring interface error rates?
Given my (possibly incorrect) assumptions:
o all the MIB2 variables you need are are COUNTER's (absolute from
when box booted): ifInErrors ifOutErrors ifInUcastPkts
ifInNUcastPkts ifOutUcastPkts ifOutNUcastPkts
o you need to make a calculation of the current datapoint
subtracted from the last polled sample for 6 different
variables
o and NetView can't combine the functionality of mib.coerce
and mibExpr.conf....
..I don't see how you can do it with NetView.
The equation I think needs to be solved is:
"%errors_over_past_polling_period= delta total error / delta total
traffic"
or specifically,
((ifInErrors(t2)+ifOutErrors(t2)) -
(ifInErrors(t1)+ifOutErrors(t1)))
/ divided by the quantity
(
(ifInUcastPkts(t2)+ifInNUcastPkts(t2)+ifOutUcastPkts(t2)
+ifOutNUcastPkts(t2)) -
(ifInUcastPkts(t1)+ifInNUcastPkts(t1)+ifOutUcastPkts(t1)
+ifOutNUcastPkts(t1))
)
Can anyone elighten, debunk, confirm or provide another way to monitor
a percentage of packet errors in NetView?
--
Todd H.
http://www.toddh.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: 13 May 2002 09:36:01 -0500
To: "Leslie Clark" <lclark@us.ibm.com>
From: netview@toddh.net (Todd H.)
Cc: nv-l@lists.tivoli.com
Subject: Re: [nv-l] packet errors -- how do you monitor?
Message-ID: <m0r8kg5d4e.fsf@rcn.com>
"Leslie Clark" <lclark@us.ibm.com> writes:
> These are the ones in the current mibExpr.conf, and are what I have been
> using for years. They are what was outlined some time ago in a Cisco
> document that covered recommended mib monitoring. Both should
> usually be thresholded at 1%, depending on your network. I'm presently
> using the ErrorRate on WAN links and find that repeated thresholds
> exceeded of more than 2% or 3% generally presages a link failure.
I'll hunt for that Cisco document. I'm aware of these existing in
mibExpr.conf, but continue to muse about the counter nature of all of
them and how that can make your alert latency (the time from when you
have a problem to when the threshold gets triggered) be strongly
dependent on how long the device has been up.
For example--if the counter is reset only on device boot, then imagine
the following scenario:
day 1: 0 errors. 10,000 packets of trafic
day 2: 0 errors. 10,000 packets of trafic
...
day 10: 0 errors. 10,000 packets of trafic
We've now got a denominator of 100,000 packets in these counters.
Now, day 11 comes and the world goes haywire:
day 11: 999errors. 999 packets.
Even though the entire day we didn't send a packet successfully, even
a 1% threshold wouldn't be reached because the denominator is holding
so much hysteresis of the "good" days.
2 questions:
Theoretically, is my understanding of these variables correct?
Practically, do you find that this effect dramatically slows your
alerting to a given problem?
Best REgards,
Todd
> ErrorRate \
> " (ifinErrors+ifOutErrors) * 100 \
> \ (ifInUcastPkts + ifInNUcastPkts + \
> ifOutUcastPkts + ifOutNUcastPkts)" \
> .1.3.6.1.2.1.2.2.1.14. \
> .1.3.6.1.2.1.2.2.1.20. + \
> .1.3.6.1.2.1.2.2.1.11. \
> .1.3.6.1.2.1.2.2.1.12. + \
> .1.3.6.1.2.1.2.2.1.17. + \
> .1.3.6.1.2.1.2.2.1.18. + / 100 *
>
Todd wrote:
> Howdy,
>
> I've got a best practices/survey question for the masses. How are
> you monitoring interface error rates?
>
> Given my (possibly incorrect) assumptions:
> o all the MIB2 variables you need are are COUNTER's (absolute
from
> when box booted): ifInErrors ifOutErrors ifInUcastPkts
> ifInNUcastPkts ifOutUcastPkts ifOutNUcastPkts
>
> o you need to make a calculation of the current datapoint
> subtracted from the last polled sample for 6 different
> variables
>
> o and NetView can't combine the functionality of mib.coerce
> and mibExpr.conf....
>
> ..I don't see how you can do it with NetView.
>
>
> The equation I think needs to be solved is:
>
> "%errors_over_past_polling_period= delta total error / delta total
> traffic"
>
> or specifically,
>
> ((ifInErrors(t2)+ifOutErrors(t2)) -
> (ifInErrors(t1)+ifOutErrors(t1)))
> / divided by the quantity
> (
> (ifInUcastPkts(t2)+ifInNUcastPkts(t2)+ifOutUcastPkts(t2)
> +ifOutNUcastPkts(t2)) -
> (ifInUcastPkts(t1)+ifInNUcastPkts(t1)+ifOutUcastPkts(t1)
> +ifOutNUcastPkts(t1))
> )
>
>
> Can anyone elighten, debunk, confirm or provide another way to monitor
> a percentage of packet errors in NetView?
>
> --
> Todd H.
> http://www.toddh.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
--
Todd H.
http://www.toddh.net/
------------------------------
Date: Mon, 13 May 2002 11:54:21 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] packet errors -- how do you monitor?
Message-ID: <OFDE32C36D.E2760166-ON85256BB8.00571FD9@raleigh.ibm.com>
Netview knows all about counters and handles them very well. It does the
subtraction between time intervals and divides by the seconds, as described
in mib.coerce. The header in mib.coerce describes what must be done
with counters; its purpose is to let you convert things that behave as
counters
into actual counters so they can be handled that way by Netview. For things
that already are counters, netview does it for you. I don't understand what
you are worried about.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
netview@toddh.net
(Todd H.) To: Leslie
Clark/Southfield/IBM@IBMUS
cc:
nv-l@lists.tivoli.com
05/13/2002 10:36 Subject: Re: [nv-l] packet
errors -- how do you monitor?
AM
Please respond to
nv-l
"Leslie Clark" <lclark@us.ibm.com> writes:
> These are the ones in the current mibExpr.conf, and are what I have been
> using for years. They are what was outlined some time ago in a Cisco
> document that covered recommended mib monitoring. Both should
> usually be thresholded at 1%, depending on your network. I'm presently
> using the ErrorRate on WAN links and find that repeated thresholds
> exceeded of more than 2% or 3% generally presages a link failure.
I'll hunt for that Cisco document. I'm aware of these existing in
mibExpr.conf, but continue to muse about the counter nature of all of
them and how that can make your alert latency (the time from when you
have a problem to when the threshold gets triggered) be strongly
dependent on how long the device has been up.
For example--if the counter is reset only on device boot, then imagine
the following scenario:
day 1: 0 errors. 10,000 packets of trafic
day 2: 0 errors. 10,000 packets of trafic
...
day 10: 0 errors. 10,000 packets of trafic
We've now got a denominator of 100,000 packets in these counters.
Now, day 11 comes and the world goes haywire:
day 11: 999errors. 999 packets.
Even though the entire day we didn't send a packet successfully, even
a 1% threshold wouldn't be reached because the denominator is holding
so much hysteresis of the "good" days.
2 questions:
Theoretically, is my understanding of these variables correct?
Practically, do you find that this effect dramatically slows your
alerting to a given problem?
Best REgards,
Todd
> ErrorRate \
> " (ifinErrors+ifOutErrors) * 100 \
> \ (ifInUcastPkts + ifInNUcastPkts + \
> ifOutUcastPkts + ifOutNUcastPkts)" \
> .1.3.6.1.2.1.2.2.1.14. \
> .1.3.6.1.2.1.2.2.1.20. + \
> .1.3.6.1.2.1.2.2.1.11. \
> .1.3.6.1.2.1.2.2.1.12. + \
> .1.3.6.1.2.1.2.2.1.17. + \
> .1.3.6.1.2.1.2.2.1.18. + / 100 *
>
Todd wrote:
> Howdy,
>
> I've got a best practices/survey question for the masses. How are
> you monitoring interface error rates?
>
> Given my (possibly incorrect) assumptions:
> o all the MIB2 variables you need are are COUNTER's (absolute
from
> when box booted): ifInErrors ifOutErrors ifInUcastPkts
> ifInNUcastPkts ifOutUcastPkts ifOutNUcastPkts
>
> o you need to make a calculation of the current datapoint
> subtracted from the last polled sample for 6 different
> variables
>
> o and NetView can't combine the functionality of mib.coerce
> and mibExpr.conf....
>
> ..I don't see how you can do it with NetView.
>
>
> The equation I think needs to be solved is:
>
> "%errors_over_past_polling_period= delta total error / delta total
> traffic"
>
> or specifically,
>
> ((ifInErrors(t2)+ifOutErrors(t2)) -
> (ifInErrors(t1)+ifOutErrors(t1)))
> / divided by the quantity
> (
> (ifInUcastPkts(t2)+ifInNUcastPkts(t2)+ifOutUcastPkts(t2)
> +ifOutNUcastPkts(t2)) -
> (ifInUcastPkts(t1)+ifInNUcastPkts(t1)+ifOutUcastPkts(t1)
> +ifOutNUcastPkts(t1))
> )
>
>
> Can anyone elighten, debunk, confirm or provide another way to monitor
> a percentage of packet errors in NetView?
>
> --
> Todd H.
> http://www.toddh.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
--
Todd H.
http://www.toddh.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: 13 May 2002 13:55:40 -0500
To: "Leslie Clark" <lclark@us.ibm.com>
From: netview@toddh.net (Todd H.)
Cc: nv-l@lists.tivoli.com
Subject: Re: [nv-l] packet errors -- how do you monitor?
Message-ID: <m0n0v3q3mb.fsf@rcn.com>
"Leslie Clark" <lclark@us.ibm.com> writes:
> Netview knows all about counters and handles them very well. It does the
> subtraction between time intervals and divides by the seconds, as
described
> in mib.coerce. The header in mib.coerce describes what must be done
> with counters; its purpose is to let you convert things that behave as
> counters
> into actual counters so they can be handled that way by Netview. For
things
> that already are counters, netview does it for you. I don't understand
what
> you are worried about.
I'm under the (perhaps mistaken) impression that you can either do
math in mibExpr.conf OR do the delta rate of change interval stuff
courtesy of mib.coerce, but I haven't seen any indication that you can
do math on coerced variables.
Can anyone confirm or deny? What is the order in which polled mib
variables get processed?
--
Todd H.
http://www.toddh.net/
------------------------------
Date: Mon, 13 May 2002 09:31:39 -0400
To: nv-l@lists.tivoli.com
From: reamd@Nationwide.com
Subject: Netview 7.1 Training
Message-ID: <OF9C61D393.DC709C66-ON85256BB8.004A123C@ent.nwie.net>
Any new status on Netview Education for 7.1? I have new potential
candidates for netview training and would like them to get trained on the
current version..
------------------------------
Date: Mon, 13 May 2002 10:55:55 -0400
To: nv-l@lists.tivoli.com
From: Peter_Chow@TD.COM
Subject: Netview Traps - Time to post
Message-ID: <OF18B017A7.C9A112B7-ON85256BB8.0051DF29@dms.ops.tdbank.ca>
We're performing some testing with Netview traps in a lab environment.
One of the tests was to pull out the interface cable on a router and see
how long it would take to receive the interface down trap on netview.
We expected to receive the trap within minutes but instead received the
trap almost two and a half hours later!!!
What is going on here? How can we minimize this 'turnaround time' to
within minutes?
------------------------------
Date: Mon, 13 May 2002 18:31:18 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] Netview Traps - Time to post
Message-ID: <OF21AA9E5A.72FB0C2E-ON85256BB8.007B8B26@raleigh.ibm.com>
By any chance are you polling that device via SNMP as opposed to ping?
You can tell when you do a demandpoll. If it is SNMP, the status of each
interface is displayed in terms of ifAdmin and ifOper status.
Is it possible that the device itself believes that the interface is up and
reports it as up, for that long?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Peter_Chow@TD.COM
To: Leslie
Clark/Southfield/IBM@IBMUS
05/13/2002 03:55 cc:
PM Subject: Re: [nv-l] Netview
Traps - Time to post
I agree that this is not normal and thank God that its not happening in our
production environment.
If I ping the interface object after I pull the cable, the status will
change to down and a trap is received right away.
If I do nothing, then no status update or trap is received for a long
period (2.5 hrs)..
SNMP Polling Info is : timeout 4.0; retry 3 ; polling 3m.
The IP interface is represented and managed.
Any suggestions on what may be wrong?
"Leslie
Clark" To: Peter_Chow@TD.COM
<lclark@us.ib cc:
m.com> Subject: Re: [nv-l] Netview
Traps - Time to post
05/13/02
12:35 PM
Well, that's not good. Fortunately it is not normal, either!
When you pull the cable, can you still ping the address
of that interface from the Netview box? And what is the
polling interval set to? That is in Options...SNMP configuration
and defaults to 5 minutes. Is the IP address of the interface
represented on the map, and is it managed? You should see
at least an Interface Down event in trapd.log for that interface
within one polling cyle.
I would have to say there is a lot more to this story than
what you have told us so far. Tell us more...
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Peter_Chow@TD.COM
To:
nv-l@lists.tivoli.com
05/13/2002 10:55 cc:
AM Subject: [nv-l] Netview
Traps - Time to post
We're performing some testing with Netview traps in a lab environment.
One of the tests was to pull out the interface cable on a router and see
how long it would take to receive the interface down trap on netview.
We expected to receive the trap within minutes but instead received the
trap almost two and a half hours later!!!
What is going on here? How can we minimize this 'turnaround time' to
within minutes?
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 12:13:59 -0400
To: nv-l@lists.tivoli.com
From: "Duble, Ethan" <Ethan.Duble@coopertools.com>
Subject: cant collect snmp on certain devices
Message-ID:
<8EC511A990DED511BC3A00B0D0227831281AF5@webmail.apex.coopertools.com>
netview 7.1.1 / aix 4.3.3
I am having a problem collecting snmp information on 2 (out of 45) routers
and one ibm switch. Netview discovers them fine , snmp is running , i can
snmp walk them , browse mib etc , however when i try to graph data or look
in the snmpCollect log i see netmon message
"Tue May 07 00:55:20 2002 : SNMP send to Apex-1.cis.7206.apx returned:
An error occurred in building out bound data.
Deferring SNMP of all collections on Apex-1.cis.7206.apx
60 minutes (1.00 hours). Send event (via
snmpCollect -C <node>) to retry sooner. "
when the next hour passes and it tries again , it fails
any ideas folks ?
Ethan
Coopertools
------------------------------
Date: Mon, 13 May 2002 18:38:43 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: RE: [nv-l] cant collect snmp on certain devices
Message-ID: <OF6BF67D73.198B83CF-ON85256BB8.007BEA99@raleigh.ibm.com>
My next stop on the trail of voodoo problem determination would be to
adjust the configuration of snmpCollect, cutting the maxpdu size in half,
so it does not ask for so much stuff at once, turn the retry down from
1 hour to 15 minutes, and after it gets restarted, toggle tracing on
and if it still happens, see if there are any more clues in the
snmpCol.trace
file. It can get very verbose with the -T and -V options. See the
man page for the snmpCollect command.
The other voodoo thing is to reset the snmp agent on those devices,
especially the IBM switch.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Duble, Ethan"
<Ethan.Duble@coope To: Leslie
Clark/Southfield/IBM@IBMUS
rtools.com> cc:
Subject: RE: [nv-l] cant
collect snmp on certain devices
05/13/2002 01:53
PM
yes , to both , we only use a /etc/host file and seedfile , discovery is
turned off
i have removed it (completely) from the netview database ( easy to do with
one map ) , netmon always finds it , changes to proper icon , (cisco router
icon) , after discovery , we monitor via the seedfile using snmpstatus
polling
tis very odd
Ethan
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Monday, May 13, 2002 1:00 PM
To: Duble, Ethan
Subject: Re: [nv-l] cant collect snmp on certain devices
Hmm. Does that name resolve in both directions? And does it
resolve to the same address every time?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Duble, Ethan"
<Ethan.Duble@coope To:
nv-l@lists.tivoli.com
rtools.com> cc:
Subject: [nv-l] cant
collect snmp on certain devices
05/13/2002 12:13
PM
netview 7.1.1 / aix 4.3.3
I am having a problem collecting snmp information on 2 (out of 45) routers
and one ibm switch. Netview discovers them fine , snmp is running , i can
snmp walk them , browse mib etc , however when i try to graph data or look
in the snmpCollect log i see netmon message
"Tue May 07 00:55:20 2002 : SNMP send to Apex-1.cis.7206.apx returned:
An error occurred in building out bound data.
Deferring SNMP of all collections on Apex-1.cis.7206.apx
60 minutes (1.00 hours). Send event (via
snmpCollect -C <node>) to retry sooner. "
when the next hour passes and it tries again , it fails
any ideas folks ?
Ethan
Coopertools
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 12:26:47 -0400
To: nv-l@lists.tivoli.com
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: [nv-l] packet errors -- (cisco links)
Message-ID: <OF3BA3C446.04B4CB86-ON85256BB8.0058D738@raleigh.ibm.com>
There is enough information in the vacinity of this link to write your own
network management system for cisco devices:
http://www.cisco.com/warp/public/477/SNMP/snmp-indx.html
This site list their Best Practices White Papers
http://www.cisco.com/warp/public/126/
The one I referenced is the Performace Management: Best Practices White
Paper
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
netview@toddh.net
(Todd H.) To: Leslie
Clark/Southfield/IBM@IBMUS
cc:
nv-l@lists.tivoli.com
05/13/2002 10:36 Subject: Re: [nv-l] packet
errors -- how do you monitor?
AM
Please respond to
nv-l
"Leslie Clark" <lclark@us.ibm.com> writes:
> These are the ones in the current mibExpr.conf, and are what I have been
> using for years. They are what was outlined some time ago in a Cisco
> document that covered recommended mib monitoring. Both should
> usually be thresholded at 1%, depending on your network. I'm presently
> using the ErrorRate on WAN links and find that repeated thresholds
> exceeded of more than 2% or 3% generally presages a link failure.
I'll hunt for that Cisco document. I'm aware of these existing in
mibExpr.conf, but continue to muse about the counter nature of all of
them and how that can make your alert latency (the time from when you
have a problem to when the threshold gets triggered) be strongly
dependent on how long the device has been up.
For example--if the counter is reset only on device boot, then imagine
the following scenario:
day 1: 0 errors. 10,000 packets of trafic
day 2: 0 errors. 10,000 packets of trafic
...
day 10: 0 errors. 10,000 packets of trafic
We've now got a denominator of 100,000 packets in these counters.
Now, day 11 comes and the world goes haywire:
day 11: 999errors. 999 packets.
Even though the entire day we didn't send a packet successfully, even
a 1% threshold wouldn't be reached because the denominator is holding
so much hysteresis of the "good" days.
2 questions:
Theoretically, is my understanding of these variables correct?
Practically, do you find that this effect dramatically slows your
alerting to a given problem?
Best REgards,
Todd
> ErrorRate \
> " (ifinErrors+ifOutErrors) * 100 \
> \ (ifInUcastPkts + ifInNUcastPkts + \
> ifOutUcastPkts + ifOutNUcastPkts)" \
> .1.3.6.1.2.1.2.2.1.14. \
> .1.3.6.1.2.1.2.2.1.20. + \
> .1.3.6.1.2.1.2.2.1.11. \
> .1.3.6.1.2.1.2.2.1.12. + \
> .1.3.6.1.2.1.2.2.1.17. + \
> .1.3.6.1.2.1.2.2.1.18. + / 100 *
>
Todd wrote:
> Howdy,
>
> I've got a best practices/survey question for the masses. How are
> you monitoring interface error rates?
>
> Given my (possibly incorrect) assumptions:
> o all the MIB2 variables you need are are COUNTER's (absolute
from
> when box booted): ifInErrors ifOutErrors ifInUcastPkts
> ifInNUcastPkts ifOutUcastPkts ifOutNUcastPkts
>
> o you need to make a calculation of the current datapoint
> subtracted from the last polled sample for 6 different
> variables
>
> o and NetView can't combine the functionality of mib.coerce
> and mibExpr.conf....
>
> ..I don't see how you can do it with NetView.
>
>
> The equation I think needs to be solved is:
>
> "%errors_over_past_polling_period= delta total error / delta total
> traffic"
>
> or specifically,
>
> ((ifInErrors(t2)+ifOutErrors(t2)) -
> (ifInErrors(t1)+ifOutErrors(t1)))
> / divided by the quantity
> (
> (ifInUcastPkts(t2)+ifInNUcastPkts(t2)+ifOutUcastPkts(t2)
> +ifOutNUcastPkts(t2)) -
> (ifInUcastPkts(t1)+ifInNUcastPkts(t1)+ifOutUcastPkts(t1)
> +ifOutNUcastPkts(t1))
> )
>
>
> Can anyone elighten, debunk, confirm or provide another way to monitor
> a percentage of packet errors in NetView?
>
> --
> Todd H.
> http://www.toddh.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
--
Todd H.
http://www.toddh.net/
------------------------------
Date: Mon, 13 May 2002 11:36:28 -0500
To: "NV List (E-mail)" <nv-l@lists.tivoli.com>
From: "Westphal, Raymond" <RWestphal@erac.com>
Subject: Question about forwarding node down event to TEC.
Message-ID:
<3BDB65726E32D411AF3F00508BCFDCCC0813ECCA@EXCORP02.corp.erac.com>
Hello Everyone.
NV 7.1.1 on AIX 4.3.3
I'm working on forwarding node down events to TEC. The event forwarding
works fine. The question is how can NV identify for TEC whether a node is
an
NT server or a router? This is especially important if the node name cannot
be resolved. If we can help TEC identify the device type, the TEC operators
will know who to correctly page because we can customize TEC "Event
Support"
button.
For instance, I can use Query SmartSet node in a ruleset to forward node
downs for members of the MicroSoft SmartSet. Therefore all node downs TEC
receives would be NT servers. However, what if I want to start forwarding
Cisco network equipment failures or all node down events. How can I help
TEC
determine the device type?
I tried adding a prefix to the hostname by using an Inline Action node in
the ruleset like, NVATTR_2="NT-$NVATTR_2". But the node name remained the
same in the event.
Any ideas or suggestions?
Thanks,
Ray Westphal
Enterprise Rent-A-Car
------------------------------
Date: Mon, 13 May 2002 12:38:04 -0500
To: nv-l@lists.tivoli.com
From: "Stephen Hochstetler" <shochste@us.ibm.com>
Subject: Re: [nv-l] Question about forwarding node down event to TEC.
Message-ID: <OFA5D82398.0769A1E4-ON86256BB8.005FEDAE@raleigh.ibm.com>
Ray,
I think you have two choices. Either you can put the logic/process in
NetView or you can put it in TEC. I will give you a potential NetView
answer. You really have multiple collections of nodes to care about
1 - Cisco (networking)
2 - Servers (microsoft, SUN ...)
3 - non-SNMP
Setup work:
- add 3 customized trap definitons for Node Down for the 3 different node
collections, don't forget to add 3 new TEC classes in your trap
definitions.
- add to the TEC Baroc the definitions for the 3 new TEC classes.
You already have collections for those three types in NetView. From your
ruleset instead of forwarding traps of "Node Down". call an action to
generate a new trap based on collection membership. "Node Down" now
becomes "NT Node Down" or "Cisco Node Down" ....... Now update your
ruleset to forward to TEC the 3 new traps you have defined. Update your
TEC rules to handle the new classes if you need to.
-- the above logic can be expanded to break up your traps into whatever
support groups you have
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization - Austin
Office - 512-436-8564 FAX - 512-436-8701
ITSO redbooks at http://www.redbooks.ibm.com
------------------------------
Date: Mon, 13 May 2002 12:56:57 -0500
To: "'Leslie Clark'" <lclark@us.ibm.com>,
"NV List (E-mail)"
<nv-l@lists.tivoli.com>
From: "Westphal, Raymond" <RWestphal@erac.com>
Subject: RE: [nv-l] Question about forwarding node down event to TEC.
Message-ID:
<3BDB65726E32D411AF3F00508BCFDCCC0813ECCE@EXCORP02.corp.erac.com>
Leslie,
Regarding option #2, how reliable is wpostemsg? Will the NV server cache
the
events if oserv process fails in the same way NV does with native TEC event
forwarding?
I suppose this will force us to introduce oserv process monitoring on the
NetView server. :)
Thanks very much.
Ray Westphal
Enterprise Rent-A-Car
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Monday, May 13, 2002 12:07 PM
To: Westphal, Raymond
Subject: Re: [nv-l] Question about forwarding node down event to TEC.
The answer is that you cannot modify the event being forwarded.
There are a couple of approaches commonly taken.
1) Many people use wpostemsg to send their own event from the
ruleset, rather than passing the Netview event. Generate that event
from an Action in a Netview ruleset running in ESE.automation.
2) Many people use snmptrap to generate new, custom events in the
Netview enterprise, one which contains additional slot mappings for
use by the TEC rule. Do this in a ruleset running in ESE.automation,
and use another ruleset, aimed at the TEC, to just pass those long.
3) Add name resolution from the point of view of the Netview box and
the TEC box. The events will go over with meaningful names. This
will only get you so far. Next you will want to pass other information
such as Department.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Westphal,
Raymond" To: "NV List (E-mail)"
<nv-l@lists.tivoli.com>
<RWestphal@erac.c cc:
om> Subject: [nv-l] Question
about forwarding node down event to TEC.
05/13/2002 12:36
PM
Hello Everyone.
NV 7.1.1 on AIX 4.3.3
I'm working on forwarding node down events to TEC. The event forwarding
works fine. The question is how can NV identify for TEC whether a node is
an
NT server or a router? This is especially important if the node name cannot
be resolved. If we can help TEC identify the device type, the TEC operators
will know who to correctly page because we can customize TEC "Event
Support"
button.
For instance, I can use Query SmartSet node in a ruleset to forward node
downs for members of the MicroSoft SmartSet. Therefore all node downs TEC
receives would be NT servers. However, what if I want to start forwarding
Cisco network equipment failures or all node down events. How can I help
TEC
determine the device type?
I tried adding a prefix to the hostname by using an Inline Action node in
the ruleset like, NVATTR_2="NT-$NVATTR_2". But the node name remained the
same in the event.
Any ideas or suggestions?
Thanks,
Ray Westphal
Enterprise Rent-A-Car
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 16:12:52 -0400
To: nv-l@lists.tivoli.com
From: "Brett Coley" <bcoley@us.ibm.com>
Subject: RE: [nv-l] Question about forwarding node down event to TEC.
Message-ID: <OF6FB74B41.7F0B32E5-ON85256BB8.006EF6CA@raleigh.ibm.com>
> Regarding option #2, how reliable is wpostemsg? Will the NV server cache
the
> events if oserv process fails in the same way NV does with native TEC
event
> forwarding?
If you use the -f option of wpostemsg,
you can specify caching parameters in
a configuration file, and any cached
events will be sent on the next
wpostemsg that connects successfully.
See the TEC Adapter's Guide for
syntax of the configuration file.
Regards,
Brett
------------------------------
Date: Mon, 13 May 2002 13:12:52 -0400
To: nv-l@lists.tivoli.com
From: "James Shanks" <jshanks@us.ibm.com>
Subject: RE: [nv-l] NetView 7.1.1 installation (Lanugage kit)
Message-ID: <OFCDFDFA29.91C5BEFD-ON85256BB8.005DE947@raleigh.ibm.com>
The language kits are for the message catalogs which allow the NetView GUI
=
to have labels, help panels, and man pages in languages other than=20
English.
Using them, NetView will also issue certain operator messages in these=20
languages as well, but only the public ones. None of the trace or=20
diagnostic messages will be translated, which means that most of the logs
=
found in /usr/OV/log will NOT be translated.=20
There are only three language kits at this time, Japanese (Kanji),=20
Korean, and simplified Chinese. That's all there have ever been.
If you have no need of them, then do not install them.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
=20
Leslie Clark/Southfield/IBM@IBMUS
05/10/2002 02:45 PM
=20
To: nv-l@lists.tivoli.com
cc:=20
Subject: RE: [nv-l] Netview 7.1.1 installation (Lanugage
kit)
=20
I've never had to use the language kits, being US-based. It is the
component that adds National Lanugage Support to the product.
No, you don't have to install it, but in .CA you might want to.
Others can tell you more about it. Others??
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
=20
"D'Apice, =20
Dominic" To: Leslie=20
Clark/Southfield/IBM@IBMUS=20
<D.D'Apice@SAQ.qc cc: "Netview - List=20
(E-mail)" <nv-l@lists.tivoli.com>=20
.ca> Subject: RE: [nv-l]=20
Netview 7.1.1 installation=20
=20
05/10/2002 10:45 =20
AM =20
=20
=20
thank Leslie,
and what about the language kit ?
what is it exactly ?
it's also installed with netview or i have the choice to install or not ?
thank again
-----Message d'origine-----
De : Leslie Clark [mailto:lclark@us.ibm.com]
Envoy=E9 : 10 mai, 2002 10:06
=C0 : nv-l@lists.tivoli.com
Objet : Re: [nv-l] Netview 7.1.1 installation
You can do an upgrade, and the process will make the backup for
you and then merge it it. The backup that you take is for extra
safety. So backup anything you have customized. Usually the
database and /usr/OV/conf is enough, but I did notice that it
replace a product-delivered mib application that I had customized.
So look around for files like that which you may have changed.
Make sure you upgrade the AIX to ML 9 if you are not already there.
I did not have to do much after the upgrade. Upgrade the web client if
you have downloaded it. Well, I upgraded from 6.0.3 to 7.1.1. and had
to add the new environment file to my cron scripts that used Netview
commands.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"D'Apice,
Dominic" To: "Netview - List
(E-mail)" <nv-l@lists.tivoli.com>
<D.D'Apice@SAQ.qc cc:
.ca> Subject: [nv-l] Netview
7.1.1 installation
05/10/2002 08:56
AM
Hi, nv 7.1 and aix 4.3.3 :
i readed the release note for 7.1.1 and i would like to confirm
something=20
:
1- I think i can install a upgrape of netview, does it means that netview
re-install all the netview files and it keep all the databases and conf
directories or i must backups databases and configuration file and after
the
upgrade finish, i must put it back the databases and conf directorie ?
2- What should i backup before i do the upgrade ? databases directorie=20
and
conf directorie are enoufh ?
3- What should i do after the upgrade is finish ?
4- What means exactly language kit ?
thank to all
> Dominic D'Apice
> * D.D'Apice@saq.qc.ca
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 15:09:30 -0400
To: "Netview - List (E-mail)" <nv-l@lists.tivoli.com>
From: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>
Subject: deleted segment
Message-ID: <B8EFF747323ED411AC7E005004744A08035CB99B@MERLOT.saq.qc.ca>
hi all nv711 aix433
what happen when we deleted one segment
how netview react to this change ?
does he alert with segment downs ?
must i delete the record on the database if i don't what netview alert me
if
my cie decide to delete , may be 5 segments ?
thank
> Dominic D'Apice
> * D.D'Apice@saq.qc.ca
>
>
------------------------------
Date: Mon, 13 May 2002 14:40:49 -0500
To: nv-l@lists.tivoli.com
From: "Stephen Hochstetler" <shochste@us.ibm.com>
Subject: Re: [nv-l] deleted segment
Message-ID: <OF95FB1468.AD388584-ON86256BB8.006BB3C2@raleigh.ibm.com>
Dominic,
The question I have, why would you want to delete any segments from the
map? NetView is discovering segments for you. If you delete a
segment, then NetView will rediscover it (probably) the next time it config
polls the router that has any interfaces in that segment.
Do you just not care about devices in that segment.....such as PCs on
people's desk? Instead of deleting it, just change the status to
"unmanage" for what you want NetView to ignore. It will leave it in the
map but remove it from the polling queues.
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization - Austin
Office - 512-436-8564 FAX - 512-436-8701
ITSO redbooks at http://www.redbooks.ibm.com
------------------------------
Date: Mon, 13 May 2002 15:52:36 -0400
To: "'Stephen Hochstetler'" <shochste@us.ibm.com>, nv-l@lists.tivoli.com
From: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>
Subject: RE: [nv-l] deleted segment
Message-ID: <B8EFF747323ED411AC7E005004744A08035CB99F@MERLOT.saq.qc.ca>
what i mean when i said delete a segment is physically delete a =
segment, so
a portion of my network
does'nt exist anymore. So how netview will react me on the event =
windows ?
=20
i know that i can unmanage a segment with the right click of my mouse,
=20
but what i would like to knows is how netview can understand the =
difference
between=20
a real segment down and a withdrawal segment ?
thank
-----Message d'origine-----
De : Stephen Hochstetler [mailto:shochste@us.ibm.com]
Envoy=E9 : 13 mai, 2002 15:41
=C0 : nv-l@lists.tivoli.com
Objet : Re: [nv-l] deleted segment
Dominic,
The question I have, why would you want to delete any segments from the
map? NetView is discovering segments for you. If you delete a
segment, then NetView will rediscover it (probably) the next time it =
config
polls the router that has any interfaces in that segment.
Do you just not care about devices in that segment.....such as PCs on
people's desk? Instead of deleting it, just change the status to
"unmanage" for what you want NetView to ignore. It will leave it in =
the
map but remove it from the polling queues.
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization - Austin
Office - 512-436-8564 FAX - 512-436-8701
ITSO redbooks at http://www.redbooks.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 15:59:07 -0400
To: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>,
"'Stephen Hochstetler'"
<shochste@us.ibm.com>, nv-l@lists.tivoli.com
From: "D'Apice, Dominic" <D.D'Apice@SAQ.qc.ca>
Subject: update : RE: [nv-l] deleted segment
Message-ID: <B8EFF747323ED411AC7E005004744A08035CB9A0@MERLOT.saq.qc.ca>
another thing :
Does the database is dynamically change when a segment is down or
unreachable ? so the next time netview will pool he will not alert me =
in the
event windows ?
Dominic=20
thank
=20
----Message d'origine-----
De : D'Apice, Dominic [mailto:D.D'Apice@SAQ.qc.ca]
Envoy=E9 : 13 mai, 2002 15:53
=C0 : 'Stephen Hochstetler'; nv-l@lists.tivoli.com
Objet : RE: [nv-l] deleted segment
what i mean when i said delete a segment is physically delete a =
segment, so
a portion of my network
does'nt exist anymore. So how netview will react me on the event =
windows ?
=20
i know that i can unmanage a segment with the right click of my mouse,
=20
but what i would like to knows is how netview can understand the =
difference
between=20
a real segment down and a withdrawal segment ?
thank
-----Message d'origine-----
De : Stephen Hochstetler [mailto:shochste@us.ibm.com]
Envoy=E9 : 13 mai, 2002 15:41
=C0 : nv-l@lists.tivoli.com
Objet : Re: [nv-l] deleted segment
Dominic,
The question I have, why would you want to delete any segments from the
map? NetView is discovering segments for you. If you delete a
segment, then NetView will rediscover it (probably) the next time it =
config
polls the router that has any interfaces in that segment.
Do you just not care about devices in that segment.....such as PCs on
people's desk? Instead of deleting it, just change the status to
"unmanage" for what you want NetView to ignore. It will leave it in =
the
map but remove it from the polling queues.
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization - Austin
Office - 512-436-8564 FAX - 512-436-8701
ITSO redbooks at http://www.redbooks.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
------------------------------
Date: Mon, 13 May 2002 16:52:51 -0500
To: nv-l@lists.tivoli.com
From: "Stephen Hochstetler" <shochste@us.ibm.com>
Subject: Re: [nv-l] update : RE: [nv-l] deleted segment
Message-ID: <OFFA1F71F6.21BE8821-ON86256BB8.00732772@raleigh.ibm.com>
OK -- I think I understand that you are changing the router configuration
so that an existing segment/subnet will no longer exist in the physical
network.
When NetView pings the IF in that segment next time, yes, IF down traps
will be generated for those interfaces. 5 minutes later when it pings
again, no new traps are generated, they are already down. There is a
setting for NetView that will remove interfaces after they have been down
for xx days (hours). So all you have to do after it goes red is to go
ahead and Acknowledge the interfaces of that segment if you are concerned
about having a green map. DO NOT acknolwedge the segment icon itself, only
interfaces should be acknowledged. NetView will automatically clean up
those interfaces/segments later.
note -- one thing I am not sure is if NetView will clean them up if you
acknowledge them. I think so, but only testing will validate it.
Kind regards,
Stephen Hochstetler shochste@us.ibm.com
International Technical Support Organization - Austin
Office - 512-436-8564 FAX - 512-436-8701
ITSO redbooks at http://www.redbooks.ibm.com
------------------------------
Date: Mon, 13 May 2002 20:08:01 +0000
To: nv-l@lists.tivoli.com
From: "Eric Pobst" <epobst98@hotmail.com>
Subject: trapgend
Message-ID: <F37u9Xj4i5aX38Rx6Rp00017877@hotmail.com>
I was wondering if anyone had any experience with trapgend agents not
forwarding events to NetView server (All aix 4.3x). I had to manually
install the trapgend (SA's refused to open up reexec) which involved
placing
trapgend related files on target machine, editing snmpd.conf, and inserting
auto-start entry in rc.tcpip file. The agent appears to run normally and I
am able to browse netview6000subagent mib with no issue, but when
attempting
to validate trap forwarding (set OPMSG error to true and issueing errlogger
hello command), no trap is forwarded.
SNMP configuration is set correctly, as I recieve other traps, so I most
likely missed something during the manual installation process.
Thanks,
Eric
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
------------------------------
End of nv-l Digest
***********************************
|