AutoNOC 2.5 User Guide
Preface
Acknowledgements
System Requirements
Legal

Part 1 - Introduction
1.1 The Ideal Difference
1.2 Automated Operations
1.3 Services & Scaler
1.4 Acquisition Stacks
1.5 Portal Deployment
1.6 Discovery and Crawler
1.7 Monitoring Agents
1.8 Recoiling Database
1.9 Multiple Languages
1.10 Security

Part 2 - NOC Views
2.1 Investigate
2.2 Observe
2.3 Visualize
2.4 Alarms
2.5 Analyze
2.6 Design
2.7 Configure

Part 3 - Model Design
3.1 Object Model
3.2 Devices
3.3 Sets
3.4 Set Criteria
3.5 Probes
3.6 Logs & Events
3.7 Alarms
3.8 Actions
3.9 Reports
3.10 Users
3.11 Polling
3.12 Service Levels
3.13 Dependencies
3.14 Performance

Part 4 - Developer Features
4.1 Adding SNMP MIBs
4.2 Variables
4.3 OSP API
4.4 Probe Template
4.5 Log Template
4.6 Device Template
4.7 Interface Template
4.8 Rebranding

Part 5 - Troubleshooting
5.1 General Issues
5.2 Linux
5.3 Windows

Appendix
A.1 OSP API Functions
A.2 Variables
A.3 Object Reference

1.5 Portal Deployment
Whether your organization is an ASP, ISP, MSP, educational institution, major corporation, governmental department, NGO, mid-sized company or SOHO, some time needs to be spent planning how to deploy AutoNOC 2.
  • Stand Alone
  • Centralized
  • Distributed
  • Embedded

Which strategy is right for you? That depends on how the network you are going to manage is distributed. The following topics discuss the different deployment methods.

1.5.1 Stand Alone
Stand alone deployment of AutoNOC is the most straight forward. Find a server, preferably inside your organization's intranet and setup the service. Typically it is a good idea to make this a dedicated server but that is not necessarily a requirement. Add all of the networks devices to the AutoNOC portal, create local user accounts, customize the views and you will be all set.

1.5.2 Centralized
Centralized deployment is essentially the same thing as stand alone and is deployed the same way. The key difference is that in a centralized management model, remote devices are managed over smaller pipes, typically T1 or similar WAN links.

Centralized management is advantageous in that there is only a single server to install the AutoNOC service on, and it manages the entire network.

However, managing your network with a centralized model has pluses and minuses in real world scenarios.For instance, a centralized management model is ideal when the remote devices and networks to be managed are relatively small and contain few devices. When operating an active model, AutoNOC needs to poll data from the remote devices. This will use a small amount of bandwidth on the network. If the remote networks to be monitored are small in comparison to the available WAN bandwidth then the centralized model is typically ideal.

If active monitoring of the network is not necessary, it is also possible to use a centralized management scheme passively in a large distributed network. What does this mean? Well, in a passively monitored network, the management portal simply sits around and waits for events to be sent in to the portal. This is called event management. It is nice because you only use bandwidth when something actually happens. It defers intelligence about the network to the remote agents. Receiving a syslog event is an example of passive management as is receiving SNMP traps.

AutoNOC can be used to manage very large networks in a centralized manner by using it purely in a passive (events only) setup. This capability is enabled by default and all you need to do is setup the software and direct management agents to send events to AutoNOC. The software acts as a server for a variety of commonly used event formats. When the events come in, it will log them, create devices for them, and store them over time for review.

The trade-off you make with passive management is that you lose the vast amount of valuable detailed information that active monitoring is able to acquire about your network.

Centralized monitoring is not as efficient as distributed deployment on small or heavily used WAN connections to remote networks with large numbers of devices.

1.5.3 Distributed
An alternative to centralized management is distributed management. Distributed management means locating and deploying multiple AutoNOC servers at specific locations throughout a network. The ideal scenario for this is when you have small or heavily used WAN connections to remote networks and large numbers of devices on a fast local network.

By distributing the servers around you are able to do full active and passive management of remote networks while not impacting WAN connectivity. This is the ideal model for large multinational corporations and other organizations that have many distributed support centers.

A good way to think about distributed management is to ask where are the support personnel? If you have numbers of support personnel located at remote sites then chances are a distributed model is the right model for you. The tough case is when there is only one remote support person. At that point you are kind of in the grey subjective area to determine whether distributed or centralized management is right for you.

Deploying a distributed management model involves setting up AutoNOC services at the locations either on a dedicated server (preferred) or installing it on an existing server. Port holes for HTTP access, and IP access rules to AutoNOC as described in 1.10 Security should be created to allow only specific users into the portal if it is on a public network.

Another advantage of the distributed deployment model is severability. That is the management capability of your network will keep working in the event that WAN links and other parts of the network go down. In mission critical projects, this single benefit of the flexibility AutoNOC provides the user with is often a reason for choosing AutoNOC.

1.5.4 Embedded
Embedded deployment is the same as massively distributed deployment of AutoNOC. The software becomes a lightweight service within some kind of a kiosk, remote application, or something similar.

Embedded deals traditionally require some specific customization of the software for ideal and proper use, but it is important to note that AutoNOC is lean, consistent, and integrated sufficiently that it will perform well in an embedded type of an environment.

1.5.5 Better Security with Management LANs
Larger organizations adopting a permanent network strategy should consider the use of a Management LAN for the network if the hardware you are using includes that capability. The idea behind a management LAN is that all management traffic (SNMP, etc.) and all ports related to management, etc. are only accessible from certain locations throughout the network.

The Management LAN then becomes a network layer where all network management related security, access, management, configuration, etc. travels. A Management LAN, when properly setup can vastly increase security so that only people who have access to the management LAN are allowed to tinker in it.

There are a variety of strategies for doing this depending on the hardware available. Simply segmenting the network with all networking devices in one IP range and all hosts in another range is an easy and effective way to do this, for instance. A firewall can then be used to control access to who can get into the Management LAN. The idea being that AutoNOC can be deployed inside a Management LAN and access all devices within the management LAN.

This is kind of like putting an internal firewall around the core network applications and dramatically increases security and reduces risk exposure.

1.5.6 Choosing the Right Deployment Model
The following diagram can help you to evaluate which deployment strategy is right for you:

Stand Alone Centralized Distributed Embedded
Small Local Network X
Small Remote Networks
No Link or Dial-Up
X X
Many Small Remote Networks
128Kbps or Better WAN Link
X
Large Remote Networks
Slow or Busy WAN Link
X
Large Remote Networks
T1 or Better WAN Link
X X
Large Numbers of Autonomous
Remote Networks / Devices
X
Passive / Events Only Monitoring X X
(C) 2007 - All Rights Reserved - AutoNOC LLC
      Call me!