nv-l
[Top] [All Lists]

RE: [nv-l] Discovery and network migration, couple questions

To: "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
Subject: RE: [nv-l] Discovery and network migration, couple questions
From: "Allison, Jason (JALLISON)" <JALLISON@arinc.com>
Date: Wed, 24 Mar 2004 12:47:42 -0500
Delivery-date: Wed, 24 Mar 2004 18:00:05 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
Funny timing.
 
Just got done verifying everything you have said.  However, I did not use loadhosts for the end system, I just made sure my /etc/hosts file was correct, added new node, updated verified IP information and then demand'polled the device.  Seemed to work like a champ.  Only change really is NV has no tracability on the map with connection symbols.
 
Thanks for the confirmation though, good to know.
 

Jason Allison
Principal Engineer
ARINC Incorporated
Office:  (

-----Original Message-----
From: James Shanks [mailto:jshanks@us.ibm.com]
Sent: Wednesday, March 24, 2004 11:49 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Discovery and network migration, couple questions


I'll take a shot at this.  If  anyone else has an opinion,  please chime in.

>1.  Once a node is discovered and managed, if the underlying data flow, paths, hardware, etc change, does the end Node need to be rediscovered (deleted and discovered) in the NV DB?

No, I don't think so, as long the IP address of the main interface remains the same, and as long as NetView can get to the device, and it still responds to SNMP.   Configuration polls should take care of everything else that I can think of.

>2.  Is it possible in NV to not discover through the cloud to get to the end Node, but instead create symbols/objects for the end nodes and demand poll them and they be added to the NetView DB, thus circumventing the cloud all together?

This is done by turning off discovery and using loadhosts.   But you need the correct subnet mask, and the device has to ultimately be accessible through the cloud by ping/SNMP, else it will be blue forever.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group



"Allison, Jason (JALLISON)" <JALLISON@arinc.com>
Sent by: owner-nv-l@lists.us.ibm.com

03/23/2004 04:00 PM
Please respond to
nv-l

To
"nv-l (nv-l@lists.us.ibm.com)" <nv-l@lists.us.ibm.com>
cc
Subject
[nv-l] Discovery and network migration, couple questions





Going to try to not confuse with too many details.

We are migrating underlying infrastructure and I am working on the procedures to migrate currently discovered and managed nodes as well as the procedures for discovering and managing new nodes.  Good news is neither the NMS or the old end Nodes changing addresses.  For lamens sake we have:

NMS -> <cloud A> -> Managed Node

Migrating to ...

NMS -> <cloud B> -> Managed Node

Our paradigm is to manage through cloud A, manage end Node, unmanage and hide cloud A on map.

1.  Once a node is discovered and managed, if the underlying data flow, paths, hardware, etc change, does the end Node need to be rediscovered (deleted and discovered) in the NV DB?

Our new Cloud B border router has an access list to not allow SNMP traffic (any traffic) to the NMS originating from within the cloud, HOWEVER it will allow traffic originating from the end Node.  This breaks our current set of procedures to manage through the cloud to get to the end Node.

2.  Is it possible in NV to not discover through the cloud to get to the end Node, but instead create symbols/objects for the end nodes and demand poll them and they be added to the Netview DB, thus circumventing the cloud all together?

Thanks in advance,

Jason Allison
Principal Engineer

ARINC Incorporated

Office:  (

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

Archive operated by Skills 1st Ltd

See also: The NetView Web