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: (
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
|
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: (
|