Re: FW: [NV-L] Reg Data Collection regarding health of Router

[Bill Evans <wvevans@epix.net>]

I believe James is off today since IBM is on holiday. 

You need to understand a couple things about how NetView works. 

In the first case, each of the entries in TRAPD.LOG has a "source" indicator.  In this case it is the "N" in the record and that indicates the information comes from NetView.  If the information comes from the agent on the device it has an "A" or an "a".  Agent information is "real", as it would be in a ColdStart trap since it comes from the device itself.  NetView information is less so since it is inferred from the failure to receive a polling response. 

NetView issues its SNMP or ICMP queries on a scheduled bases with a specified number of retries at a specified interval.  The default polling for Unix is five minutes with three tries separated by two seconds (if I remember correctly) and Windows is twenty minutes with the same number of tries and waits.  If the device does not reply in time to any of the polls, the NetView program generates the "down" traps you see.  The next time around you will get the "up" traps.  These traps do NOT reflect the real state of the device but the ability of external nodes to communicate with the device. 

There can be a number of reasons for NetView originated "down" traps:
    -- The device is really down and not working
    -- The network is slow and the replies did not get back in time.
    -- Some node in the network is overloaded and is throwing away the ICMP or SNMP traffic.  (This is allowed by the Internet Protocol architecture.)
    -- Your polling parameters are too tightly specified for the characteristics of your network. 

The polling parameters are an interesting problem of the slow network type I once encountered.  I was installing a NetView in New York City in July 2001 and I had to set the delay on the poll  to over twelve seconds to get responses from systems located in Ohio and Michigan -- about 500 miles or 600 km away.  I was very confused by this until I got back to my hotel and found out that the main fiber optic trunks had been destroyed in a railroad tunnel fire and the whole Eastern US telecommunications network was in very bad shape.  When they fixed the melted fiber things began to work with the default values. 

Other reasons to change the defaults can be such things as satellite links and slow speed links. 

I usually automate the "Router Down" events with messages to the network engineers and operations management since Routers are so significant.  Because of these common "false positive" reports I have added an SNMPGET for the system up time and include that information on the follow up "Router Up" message so they know if the outage was real and the device restarted or that it was a false report.

These issues are discussed in the NetView books in the area around trap customization.

Bill Evans

Santhanakrishnan Janakiraman (IT Services), Chennai wrote:

Hi James,

 

The information what I got from netview is

 

Netview Details

 

trapd.log:1175680799 3  Wed Apr 04 15:29:59 2007 10.254.10.5               N Network Down

trapd.log:1175680804 3  Wed Apr 04 15:30:04 2007 10.254.10.5               N Router Down.

trapd.log:1175681099 3  Wed Apr 04 15:34:59 2007 10.254.10.5               N Network Up

trapd.log:1175681099 3  Wed Apr 04 15:34:59 2007 10.254.10.5               N Router Up.

 

 

Actually the netview says that the router 10.245.10.5 is down for 6 min but our network team said that it is working properly and the information from the router is provided below, regarding this issue we are facing this problem for all the links and devices.

 

Router Details

 

HRCHVADMPMT001 uptime is 11 weeks, 4 days, 9 hours, 27 minutes

System returned to ROM by power-on

System image file is "disk2:c7200-ik9o3s-mz.124-12.bin"

 

 

Router IP address details ;

 

HRCHVADMPMT001#sh ip interface brief

Interface                  IP-Address      OK? Method Status                Prot

ocol

GigabitEthernet0/1         172.25.240.114  YES NVRAM  up                    up

 

GigabitEthernet0/2         10.254.1.81     YES NVRAM  up                    up

 

GigabitEthernet0/3         146.199.89.46   YES NVRAM  up                    up

 

FastEthernet3/0            unassigned      YES NVRAM  administratively down down

 

FastEthernet3/1            unassigned      YES NVRAM  administratively down down

 

FastEthernet5/0            unassigned      YES NVRAM  administratively down down

 

FastEthernet5/1            unassigned      YES NVRAM  administratively down down

 

Loopback0                  10.254.10.5     YES NVRAM  up                    up

 

Tunnel0                    10.254.12.10    YES NVRAM  up                    up

 

Tunnel1                    10.254.12.18    YES NVRAM  up                    up

 

 

Kindly help me in this .

 

 

 

 

Thanks & Regards

SanthanaKrishnan.J

Office: 044-28221129 Ext-2206

Mobile : +91- 9840943639

 

From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of James Shanks
Sent: Wednesday, April 04, 2007 8:03 PM
To: Tivoli NetView Discussions
Subject: Re: [NV-L] Reg Data Collection regarding health of Router

 

How about if you tell us what you mean by improper information? What exactly are you seeing that's incorrect or improper?

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
" Santhanakrishnan Janakiraman (IT Services), Chennai" <santhanakrishnanjn@hcl.in>

" Santhanakrishnan Janakiraman (IT Services), Chennai" <santhanakrishnanjn@hcl.in>
Sent by: nv-l-bounces@lists.ca.ibm.com

04/04/2007 10:14 AM

Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>

To	<nv-l@lists.ca.ibm.com>
cc
Subject	[NV-L] Reg Data Collection regarding health of Router

 

Hi All,

Actually iam facing a issue as netview is collecting improper information regarding the health of router and links, please suggest me in this

Thanks & Regards
SanthanaKrishnan.J

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only)
  

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.24/742 - Release Date: 4/1/2007 8:49 PM
  

_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)