DiscoScope.cfg configuration file

The DiscoScope.cfg configuration file can be used to configure the scope of a discovery.

Database tables used

This configuration file can be used to configure inserts into the following database tables:

scope.zones
scope.detectionFilter
scope.instantiateFilter
scope.multicastGroup
scope.multicastSource
scope.special

Restriction: The scope.zones table can only be used to configure scoping for IP-based entities. Non-IP entities such as layer 1 optical devices must be scoped using the scope.detectionFilter table.

Sample: defining an inclusion zone

The following example insert defines the 10.10.2.* subnet as an inclusion zone.

Restriction: Network Manager does not support the IPv4–mapped IPv6 format and expects all IPv6 addresses to be in standard colon-separated IPv6 format. For example, Network Manager does not support an IPv4–mapped IPv6 address such as ::ffff:192.0.2.128. Instead enter this address as ::ffff:c000:280 (standard colon-separated IPv6 format).

insert into scope.zones
(
        m_Protocol,
        m_Action,
        m_Zones
)
values
(
        1,
        1,
        [
            {
                m_Subnet="10.10.2.*"
            }
        ]
);

Sample: defining multiple inclusion zones

The following example defines three different IP inclusion zones each using a different syntax to define the subnet mask. The following devices are discovered:

Any device within the 172.16.1.0 subnet (with a subnet mask of 24, that is, 24 bits turned on and 8 bits turned off, which implies a netmask of 255.255.255.0).
Any device within the 172.16.2.0 subnet with a mask of 255.255.255.0.
Any device within the 172.16.3.0 subnet with a mask of 255.255.255.0.

insert into scope.zones
(
    m_Protocol,
    m_Action,
    m_Zones    
)
values
(
        1,
        1,
        [
              {
                    m_Subnet="172.16.1.0",
                    m_NetMask=24
              },
              {
                    m_Subnet="172.16.2.*"
              },
              {
                    m_Subnet="172.16.3.0",
                    m_NetMask="255.255.255.0"
              }
        ]
);

Sample: defining an exclusion zone

The following example insert defines a single exclusion zone for the IP protocol, and associates the zone with a subnet.

insert into scope.zones
(
        m_Protocol,
        m_Action,
        m_Zones
)
values
(
        1,
        2, 
        [ 
            {
                m_Subnet="172.16.1.0",
                m_NetMask=24
        ]
);

Sample: defining an inclusion zone within a NAT domain

The following example defines one inclusion zone. The inclusion zone includes any device with an IP address starting with 172.16.2 that also belongs to the NAT address space NATDomain1. The protocol is set to 1, that is, IP.

insert into scope.zones
(
    m_Protocol, m_Action, m_Zones, m_AddressSpace
)
values
(
        1,
        1,
        [
            {
                m_Subnet="172.16.2.*",
            }
        ],
        "NATDomain1"
);

Sample: restricting device interrogation based on IP address

The following example shows how to prevent the further interrogation of devices that match a given IP address. Only devices that do not have the IP address 10.10.63.234 are interrogated further. Within the scope.detectionFilter table, specify:

The filter condition(s). Only devices that pass this filter, that is, for which the filter evaluates true, are further investigated. If no filter is specified, all devices are passed through the detection filter.

insert into scope.detectionFilter
(
        m_Filter                                    
)
values
(
        "( ( m_UniqueAddress <> '10.10.63.234' ) )"
);

A stitcher tests each discovered device against the filter condition in the scope.detectionFilter table, and the outcome of this test determines whether the device is discovered.

Because the process flow of the discovery is fully configurable, you can configure this stitcher to act at any time during the discovery process. By default, the stitcher performs the conditional test on the device details returned by the Details agent. Your filter must therefore be based on the columns of the Details.returns table.

Although you can configure the filter condition to test any of the columns in the Details.returns table, you might need to use the IP address as the basis for the filter to restrict the detection of a particular device. If the device does not grant SNMP access to the Details agent, the Details agent might not retrieve MIB variables such as the Object ID. However, you are guaranteed the return of at least the IP address when the device is detected.

The following examples show how else you might configure the detection filter.

Sample: restricting interrogation based on Object ID

The following example shows how to prevent the further interrogation of devices that match a given Object ID. The OQL not like clause indicates that only devices that pass the filter (that is, devices for which the OID is not like 1.3.6.1.4.1.*) are interrogated further.

The backslash must be used in the insert to escape the ., which would otherwise be treated as a wildcard.

insert into scope.detectionFilter
(
        m_Filter
)
values
(
        "(
                ( m_ObjectId not like '1\.3\.6\.1\.4\.1\..*' )
        )"
);

Sample: combining multiple filter restrictions

You can combine filter conditions within a single OQL insert. The following example ensures that only devices that do not have the specified OID and do not have the specified IP address are detected:

insert into scope.detectionFilter
(
        m_Filter
)
values
(
        "(
                ( m_ObjectId not like '1\.3\.6\.1\.4\.1\..*' )
                AND
                ( m_UniqueAddress <> '10.10.63.234' )
        )"
);

Restricting instantiation: limitation when filtering out interfaces

Note the following limitation when you restrict instantiation of interfaces.

Restriction: To ensure that alerts are not raised for interfaces that are excluded by the instantiation filter, you must set the RaiseAlertsForUnknownInterfaces variable. To this, perform the following steps:

Edit the $NCHOME/etc/precision/NcPollerSchema.cfg configuration file.

Add the following line to the file:

update config.properties set RaiseAlertsForUnknownInterfaces = 0;

Sample: restricting instantiation based on entity name

To restrict the devices that are instantiated, append an OQL insert into the scope.instantiateFilter table. The instantiateFilter table requires a conditional test. Only devices that pass the filter are sent to ncp_model. If no filter is defined, all discovered devices are passed to ncp_model.

The conditional test must be based on the ncimCache data format.

The following example postdiscovery filter restricts instantiation of a chassis and its contents.


insert into scope.instantiateFilter
(
    m_Filter
)
values
(
    "
    (
        BASENAME != 'jane'
    )
    "
);

The following example postdiscovery filter restricts instantiation of a chassis and its contents.


insert into scope.instantiateFilter
(
    m_Filter
)
values
(
    "
    (
        snmpSystem->SYSDESCR NOT LIKE ' device'
    )
    "
);

Using scope.special to restrict device detection

Make entries in the scope.special table for network interfaces that can be accessed through multiple IP addresses. The entries in the scope.special table control which IP addresses Network Manager uses to monitor devices for NCMP and SNMP polling policies.

The following sample shows an INSERT statement to the scope.special table. It defines the IP address 192.168.1.3 as a potential management interface for chassis and interfaces. It provides extra customer information that is added to the ExtraInfo section of the entity in the model master.entityByName database table if the IP address is discovered.

insert into scope.special
(
        m_Zones,
        m_Identifier,
        m_Priority,
        m_NonPingable,
        m_AdminInterface,
        m_ExtraInfo,
        m_Protocol,
        m_IsManagement,
        m_OutOfBand,
        m_IsValidVirtual
)
values
(
        [
                {
                        m_Subnet="192.168.1.3",
                        m_NetMask=32
                }
        ],
        "CustomerFacing",
        99,
        0,
        1,
        {
                m_CustomerName = 'MyCompany',
                m_CustomerType = 'Internal'
        },
        1,
        0,
        1,
        0
);

For a device that has 2 IP addresses, 172.20.1.1 and 192.168.1.3, the configuration means that 172.20.1.1 is not chosen as the IP address through which to manage the device. 192.168.1.3 is used instead. The following example shows what the final topology entry in the master.entityByName looks like in this instance. The data inside ExtraInfo that is prefixed with m_ScopeSpecial comes from the scope.zones entry that matched the IP address of 192.168.1.3.

{
        EntityName='192.168.1.3';
        Address=['','','192.168.1.3'];
        EntityType=1;
        EntityOID='1.3.6.1.4.1.8072.3.2.10';
        IsActive=1;
        Status=1;
        ExtraInfo={
                m_SysName='SYS1';
                m_DNSName='DNS1';
                m_time=1362486845;
                m_DisplayLabel='DNS1';
                m_AssocAddress=
[{m_IfIndex = 1, m_IpAddress = '172.20.1.1', m_Protocol = 1, m_IfOperStatus = 1 },
{m_IfIndex = 2, m_IpAddress = '192.168.1.3', m_Protocol = 1, m_IfOperStatus = 1 }];
                m_ScopeSpecialIsManagement=1;
                m_ScopeSpecialPriority=99;
                m_ScopeSpecialIdentifier='CustomerFacing';
                m_ScopeSpecialExtraInfo={
                          m_CustomerName = 'MyCompany',
                    m_CustomerType = 'Internal'
                    };
                m_DefinedMgmtIP=1;
                m_IsOutOfBand=1;
                m_BaseName='192.168.1.3';
                m_AddressSpace=NULL;
                m_AccessProtocol=1;
                m_AccessAddress='192.168.1.3';
                };
        LingerTime=3;
        ActionType=0;
        CreateTime=1362486848;
        ChangeTime=1362486848;
        ClassName='NetworkDevice';
        ClassId=5;
        ObjectId=2272;
}