|
Dale,
I have a similar situation where we use Cisco VPN 3000 Concentrators for our Internet users.
Here are the scenarios that I tried just for up/down availability monitoring.
1. Manage them normally:
- Found that the dynamic addresses (interfaces) would be discovered managed and then marked down when the user logged off. Not good!
2. Manage them SNMP only ($ in seedfile):
- Found that the dynamic addresses (interfaces) would be discovered managed and then properly deleted when the user logged off. However, NetView occasionally switches SNMP polling addresses to one of those virtual addresses instead of remaining on the "Real" IP Interface. This causes the entire concentrator to be marked Critical in NetView when the user of that dynamic address logs off. Again, Not Good!
3. Changed management back to ping and removed NetView's community string to the concentrators.
- This prevents configuration polling and the concentrator stays Green. Green is good :)
I have opened a PMR for this SNMP address switching. I was advised to install FixPack-1 and 2 e-fixes.
I haven't got around to doing that yet.
Cheers,
Don Davis
-----Original Message-----
From: Dale Shaw [mailto:DShaw@exceed.com.au]
Sent: Tuesday, February 11, 2003 9:52 PM
To: nv-l@lists.tivoli.com
Subject: [nv-l] NetView managing devices with dynamic IP addresses
Greetings,
I have searched through the archives and found lots of great
information, but I didn't find anything that completely answered my
question..
I am working on a large deployment of wireless kiosks that will access
application servers in a central site over an IPSec VPN (tunnel mode,
but 'remote access' -- i.e. tunnel is from kiosk to gateway, not gateway
to gateway). NetView is currently installed and is managing another
connected kiosk network but those kiosks are not wireless, are not
coming in over a VPN and all have statically-assigned IP addresses and
associated DNS entries (A/PTR).
I have very little experience with NetView, and to be honest this
potential issue is only very vaguely anything to do with me, but it's
got me curious, so I thought I'd fire off this post.
I guess the question is "how does NetView deal with devices which do not
have a static IP address?", but here's some more detail on the
environment..
Whenever a kiosk fires up, it automatically establishes an encrypted
tunnel with a concentrator device in the central network. The
concentrator will dynamically assign an IP address (from a
locally-defined pool) to the tunnel and for all intents and purposes,
the 'real' IP address (assigned to the wireless NIC in the kiosk) is not
contactable while the tunnel is up. For those familiar with IPSec VPNs,
we are not using split tunneling or any sort of functionality that
enables the end device to communicate 'in the clear' while the tunnel is
up.
We actually -want- to discover and manage these 'virtual' addresses,
because we cannot talk to the kiosks via any other address.
This obviously introduces some management challenges. For various other
reasons, we will only go down the path of statically-assigning these
"virtual" IP addresses to individual tunnels if management issues
dictate it has to be that way. The kiosks (or more accurately, the
concentrator on their behalf) -will- perform a DDNS registration based
on their tunnel/virtual address, but I don't know if that means anything
for NetView.
We're looking at approximately 3,500 kiosks operating in this way, and
we will want NetView to be managing all of them. We're running 7.1.2 on
Windows 2000 (SP3) right now and in the next couple of days we'll be
giving 7.1.3 a shot on a test server. From NetView's point of view, all
the kiosks will be in a single, large IP network (probably just an
RFC1918 /16).
This might be a no-brainer, but any tips, advice, anecdotes would be
greatly appreciated.
Cheers,
Dale
--
Dale Shaw Tel: +61 2 62603500
Systems Consultant Fax: +61 2 62603511
Exceed Systems Integration Mobile: +61 412 135539
Level 1, 69 Dundas Court E-mail: dshaw@exceed.com.au
Phillip ACT 2606 Australia Web: http://www.exceed.com.au
---------------------------------------------------------------------
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)
------------------------------------------------------------------------------
This electronic mail and any files transmitted with it are confidential and are intended solely for the use of individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail.
==============================================================================
|