Document toolboxDocument toolbox

Operational and Deployment Best Practices

When you set up and deploy an Operations Center and its associated collectors, follow some best-practices guidelines to ensure a smooth and effective rollout.

  1. Keep device management levels below the licensed device limits on each collector appliance.
    • Though you have greater flexibility for network connectivity through using network views, multiple scan interfaces and virtual scan interfaces, these features do not influence the licensing limits and capacities of your appliances.
    • License limits should be defined to allow for the organic and anticipated growth of the network. Consult with your Infoblox sales representative for a detailed assessment of your licensing needs.
    • License limits are enforced on each collector appliance in an OC deployment. Your OC design should avoid having excessive numbers of licenses on collectors, which can overwhelm the Operations Center and prevent timely operation.
    • New devices can 'bump' older previously-discovered devices from the license limit.
    • Devices in higher-ranked device groups will be prioritized for licensing. (You can change device group rankings in Settings icon> Setup > Collection and Groups > Groups tab.)
    • Avoid using device licenses on devices in end-user network segments.
  2. During setup of a new deployment, use the default network view when you define your first discovery ranges to initially discover the network.
    • An initial network view will be present in a new Operations Center deployment. Initial setup for a new Operations Center deployment automatically creates a default network view, named Network 1, as part of the procedure. This network view is automatically assigned to the Collector appliance's LAN1 port before you perform the discovery of the network.
    • When you create your initial discovery ranges, the Network 1 network view is automatically assigned to the LAN1 interface on the Collector. This network view represents the global routed network, which is the network that NetMRI will discover that is not reliant on virtual networks to route traffic.
    • When you create your discovery ranges, static IP addresses, and Seed Routers (in Settings icon>Setup > Discovery Settings > Ranges/Static IPs/Seed Routers), each range provides a Network View drop-down menu. You select one network view for each discovery setting; however, a network view can work with multiple discovery ranges. A single network view can use all three discovery objects.
      To define network views, click the Settings icon > Setup > Network Views and then assign other networks to those views.
    • For VRF discovery, you do not need to define discovery ranges in the initial rollout. NetMRI will discover VRF-aware devices in its first discovery of the global enterprise network. The system then displays a System Health alert notifying you that unassigned VRFs have been discovered.

3. Avoid using too many device groups. Target using 50 or fewer Extended device groups. Platform Limits also influence the number of device groups allowable in your system.

    • Device groups govern summary data aggregations and other device processing within each group. Device groups are defined in two varieties: Basic device groups, which offer minimal functionality and simply provide a basic categorization for discovered devices such as end hosts; and Extended device groups, which allow the enabling and disabling of specialized group features based upon the type of devices in the group. For more information, see the sections beginning with Device Groups and Switch Port Management and Creating Device Groups.
    • You can define the required device groups for your deployment; delete those that you do not need. Also, avoid frequent group definition changes, additions, and deletions.
    • Keep the Unknown and Name Only device groups; do not delete these device groups.
    • Also see Understanding Platform Limits for your Deployment.

4. Ensure reliable network connections between collectors and the Operations Center node.

    • Avoid disruption of network connections between the Operation Center and its associated collectors.
    • Also ensure that DNS resolution is complete between all Collector appliances and the Operations Center Controller appliance. All Collectors should consistently be able to synchronize correctly with the Controller. (By itself, registering successfully with the Controller does not guarantee this, because registering is done solely by the Controller IP address. This could occur, for example, if a Collector is placed in the DMZ for an enterprise network.) You can use the show tunclient command on each Collector to verify DNS resolution of the Controller on the Collector. If you see RESOLVE: Cannot resolve host address messages in the show tunclient command output, add an entry for the Operations Center Controller to the Collector's /etc/hosts file.

5. Use recommended methods to improve reporting performance for your Operations Center.

    • Filter down to the most important data, such as individual device groups, specific time windows and other Report settings.
    • Schedule large, complex reports to run during off-hours.
    • Avoid unnecessarily large reports. Example: Save out monthly reports instead of running multiple-month reports.
    • Disable details for reports offering that function, if and when desirable and the details are not germane to the report.
    • If you have simultaneously running reports, change the Concurrently Running Reports setting under Settings icon > General Settings > Advanced Settings page.

6. Manage Syslog Traffic.