nv-l

Re: [nv-l] Routers in Isolated Subnet

2004-12-16 09:00:20
Subject: Re: [nv-l] Routers in Isolated Subnet
From: SIXFC AT pjm DOT com
To: nv-l AT lists.us.ibm DOT com
Date: Thu, 16 Dec 2004 08:59:38 -0500

All,
        Thank you very much for the help. The description clarifies what I've read. It would be difficult to test that at our shop. We do have the browser interface available and I'll raise that question.

Thanks, again.
Chris

Chris Six
PJM Interconnection, llc
phone: 610-666-8891
fax: 610-666-4613
sixfc AT pjm DOT com



Date: Mon, 13 Dec 2004 22:10:38 -0500
From: Leslie Clark <lclark AT us.ibm DOT com>
Subject: Re: [nv-l] Routers in Isolated Subnet

This is a multipart message in MIME format.
- --=_related 0011320D85256F6A_=
Content-Type: multipart/alternative; boundary="=_alternative 0011320D85256F6A_="


- --=_alternative 0011320D85256F6A_=
Content-Type: text/plain; charset="US-ASCII"

If I understand the question correctly, then in most cases James'
description is accurate. For the routers between Netview and the subnet,
you will get a Router Marginal event, which is meant to indicate that they
have at least one interface up and one down, and that down one is a
problem. For the remote subnet you get subnet unreachable, and for routers
beyond that, you get Router Unreachable, meaning they are only victims.
The Router Marginal events are therefore the most important ones. There
will be Router Unreachable event, and yes, they indicate the impact of the
Router Marginal problems.

There is a case in which you get a Router Marginal for a nearby router
when it is blameless. For serial interfaces, when there is a remote
failure, the nearby router will shut its end down in response. Netview
will report that nearby router as Router Marginal, and the serial network
as Network Unreachable and the remote, failing router as Router
Unreachable. This suggests that the failure was an interface on the near
router, when the problem was really the failure of the remote router. This
is probably not the case in the arrangement you are describing, however.

Is your concern that with RFI enabled you won't get the Node Down event
for the servers on that subnet, and the servers are what you are really
worried about? You kind of have to focus on the root cause events, the
router problems, as a trade off for all of the event suppression you get
with RFI.

If you have Switch Analyzer installed, it can generate an impact report
for a given router or layer2 device.

I hope that throwing all of these words out there will help. If not,
digest this and ask again.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager




James Shanks/Raleigh/IBM@IBMUS
Sent by: owner-nv-l AT lists.us.ibm DOT com
12/10/2004 10:18 AM
Please respond to
nv-l


To
nv-l AT lists.us.ibm DOT com
cc

Subject
Re: [nv-l] Routers in Isolated Subnet






I was hoping that someone with more experience with RFI would try to
answer you on this, but since no one has, here's my two cents.

First, there is no list nor utility that will tell you what routers netmon
currently thinks are unreachable. That might be nice enhancement to netmon
someday, but it is not available today.

But, if you have a router (A) connected to a subnet, and you have another
router (B) connected to that same subnet, and the only path to router B is
across the subnet and out via router A, then if A has a problem, you
should get
(a) either an Interface Down event if just the connecting interface is
lost, and a Router Marginal for A, or
(b) a Router Down event for router A if the entire thing is lost.
But in either case you should get a Router Unreachable event for B, and a
Subnet Unreachable event for the subnet between them. At least that is my
understanding, though I must add that I don't work on netmon. If I have
gotten this wrong, then perhaps someone else will correct me.

Now as for you admins, I have to ask why they are not planning to use the
web client when they login from their remote location?
That's exactly what it is for, so you can use the map and all the
attendant NetView functions from a remote location. All you need a is
browser.
If they aren't going to do that, then the only thing I can think of for
you to do to get a list of routers which are unreachable would be to
either
(1) create a smartset for isRouter and IP Status Unreachable and then use
nvUtil to query it
(2) create a report for the same thing using nvdbformat and run that You could then email that to the admins, but putting it in a pager notice

itself would likely make the message very large.

NetView has a map precisely so that operators can get an idea of the
status of the network visually, so they can drill down and see the source
of the problem, rather than be told about it descriptively. So I still
think having them log in remotely via the web client is a much better
idea. And I know other NetView users are doing exactly this. Some of their
operators take a laptop with them wherever they go, just so they can log
in from wherever they are when the pager goes off.

Anyone else?

James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
SIXFC AT pjm DOT com


SIXFC AT pjm DOT com
Sent by: owner-nv-l AT lists.us.ibm DOT com
12/09/2004 12:22 PM

Please respond to
nv-l




To

nv-l AT lists.us.ibm DOT com

cc


Subject

[nv-l] Routers in Isolated Subnet





We have parallel paths between critical servers. If a router on one path
is down, the admins will be notified. If a router on the second path goes
down, they will also be notified. Additionally, with both paths down, the
admins want to know what routers are now isolated. Will there be a router
unreachable event for each one, following or preceding the subnet
unreachable? How can we relate them to the source problem? Does RFI keep a
list of the relationships or have a utility to determine them? Do I have
access to it?
After a pager alert, these folks will most likely login from a remote
location and open their e-mail. That's where we're trying to put the
information and why we're not telling them to look at the map.
Thanks.
Chris Six
PJM Interconnection, llc
sixfc AT pjm DOT com


<Prev in Thread] Current Thread [Next in Thread>