DiscoScope.cfg, Konfigurationsdatei
Die Konfigurationsdatei DiscoScope.cfg kann für die Konfiguration eines Erkennungsbereichs verwendet werden.
Verwendete Datenbanktabellen
Diese Konfigurationsdatei kann für die Konfiguration von Einfügungen in die folgenden Datenbanktabellen verwendet werden:
- scope.zones
- scope.detectionFilter
- scope.instantiateFilter
- scope.multicastGroup
- scope.multicastSource
- scope.special
Beispiel: Einschlusszone definieren
Die folgende Beispieleinfügung definiert 10.10.2.* Teilnetz als Einschlusszone.insert into scope.zones
(
m_Protocol,
m_Action,
m_Zones
)
values
(
1,
1,
[
{
m_Subnet="10.10.2.*"
}
]
);- Alle Einheiten im Teilnetz 172.16.1.0 (mit der Teilnetzmaske 24, d. h. 24 Bit aktiviert und 8 Bit inaktiviert, was die Netzmaske 255.255.255.0 impliziert).
- Alle Einheiten im Teilnetz 172.16.2.0 mit der Maske 255.255.255.0.
- Alle Einheiten im Teilnetz 172.16.3.0 mit der Maske 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"
}
]
);Beispiel: Ausschlusszone definieren
insert into scope.zones
(
m_Protocol,
m_Action,
m_Zones
)
values
(
1,
2,
[
{
m_Subnet="172.16.1.0",
m_NetMask=24
]
);Beispiel: Einschlusszone in einer Domäne für die Netzadressumsetzung (NAT) definieren
insert into scope.zones
(
m_Protocol, m_Action, m_Zones, m_AddressSpace
)
values
(
1,
1,
[
{
m_Subnet="172.16.2.*",
}
],
"NATDomain1"
);Beispiel: Einheitenabfrage nach IP-Adresse beschränken
Das folgende Beispiel zeigt, wie die weitere Abfrage von Einheiten verhindert wird, die einer bestimmten IP-Adresse entsprechen. Es werden nur Einheiten weiter abgefragt, die nicht die IP-Adresse 10.10.63.234 haben. Geben Sie in der Tabelle 'scope.detectionFilter' Folgendes an:- Die Filterbedingung(en). Nur Einheiten, die diese Filterbedingungen erfüllen, d.h., für die der Filter mit 'wahr' ausgewertet wird, werden weiter untersucht. Wird kein Filter angegeben, passieren alle Einheiten den Erkennungsfilter.
insert into scope.detectionFilter
(
m_Filter
)
values
(
"( ( m_UniqueAddress <> '10.10.63.234' ) )"
);Da die Prozessabfolge der Erkennung vollständig konfigurierbar ist, können Sie diesen Stitcher so konfigurieren, dass er zu einem beliebigen Zeitpunkt während des Erkennungsprozesses aktiv wird. Der Stitcher führt den Bedingungstest standardmäßig für die Einheitendetails aus, die vom Agenten für Details zurückgegeben werden. Ihr Filter muss daher auf den Spalten der Tabelle 'Details.returns' basieren.
Sie können die Filterbedingung zwar konfigurieren, um alle Spalten in der Tabelle 'Details.returns' zu testen, Sie müssen die IP-Adresse jedoch unter Umständen als Basis für den Filter verwenden, um die Erkennung einer bestimmten Einheit zu beschränken. Gewährt die Einheit keinen SNMP-Zugriff auf den Agenten für Details, ruft der Agent für Details möglicherweise keine MIB-Variablen wie die Objekt-ID ab. Jedoch ist die Rückgabe mindestens der IP-Adresse garantiert, wenn die Einheit erkannt wird.
Die folgenden Beispiele zeigen andere Konfigurationsmöglichkeiten für den Erkennungsfilter.Beispiel: Abfrage nach Objekt-ID beschränken
Das folgende Beispiel zeigt, wie die weitere Abfrage von Einheiten verhindert wird, die einer bestimmten Objekt-ID entsprechen. Die OQL-Klausel not like gibt an, dass nur Einheiten, die den Filter erfüllen (d. h. Einheiten, deren OID nicht ist, wie 1.3.6.1.4.1. *) werden weiter abgefragt.
.)
verwendet werden, der andernfalls als Platzhalterzeichen behandelt werden würde.insert into scope.detectionFilter
(
m_Filter
)
values
(
"(
( m_ObjectId not like '1\.3\.6\.1\.4\.1\..*' )
)"
);Beispiel: Mehrere Filterbedingungen kombinieren
insert into scope.detectionFilter
(
m_Filter
)
values
(
"(
( m_ObjectId not like '1\.3\.6\.1\.4\.1\..*' )
AND
( m_UniqueAddress <> '10.10.63.234' )
)"
);Instanziierung beschränken - Einschränkungen beim Filtern von Schnittstellen
RaiseAlertsForUnknownInterfaces festlegen. Führen Sie dazu die folgenden Schritte aus:- Bearbeiten Sie die Konfigurationsdatei $NCHOME/etc/precision/NcPollerSchema.cfg .
- Fügen Sie die folgende Zeile in der Datei hinzu:
update config.properties set RaiseAlertsForUnknownInterfaces = 0;
Beispiel: Instanziierung nach dem Entitätsnamen beschränken
Fügen Sie eine OQL-Einfügung in der Tabelle scope.instantiateFilter an, um die Einheiten zu beschränken, die instanziiert werden. Für die Tabelle instantiateFilter ist ein Bedingungstest erforderlich. Nur Einheiten, die die Filterbedingungen erfüllen, werden an 'ncp_model' gesendet. Wird kein Filter definiert, werden alle erkannten Einheiten an 'ncp_model' übergeben.
Der Bedingungstest muss auf dem 'ncimCache'-Datenformat basieren.
Im folgenden Beispiel eines Filters nach der Erkennung wird die Instanziierung mehrerer Chassis und ihrer Komponenten begrenzt.
insert into scope.instantiateFilter
(
m_Filter
)
values
(
"
(
BASENAME != 'jane'
)
"
);Im folgenden Beispiel eines Filters nach der Erkennung wird die Instanziierung mehrerer Chassis und ihrer Komponenten begrenzt.
insert into scope.instantiateFilter
(
m_Filter
)
values
(
"
(
snmpSystem->SYSDESCR NOT LIKE ' device'
)
"
);
'scope.special' verwenden, um die Einheitenerkennung einzuschränken
Nehmen Sie für Netzschnittstellen, auf die über mehrere IP-Adressen zugegriffen werden kann, Einträge in der Tabelle 'scope.special' vor. Die Einträge in der Tabelle scope.special steuern, welche IP-Adressen Network Manager zum Überwachen von Einheiten für NCMP-und SNMP-Polling-Richtlinien verwendet.
Das folgende Beispiel stellt eine INSERT-Anweisung für die Tabelle 'scope.special' dar. Die Anweisung definiert die IP-Adresse 192.168.1.3 als mögliche Managementschnittstelle für Chassis und Schnittstellen. Sie stellt zusätzliche Kundeninformationen bereit, die zum Abschnitt 'ExtraInfo' der Entität in der Modelldatenbanktabelle 'master.entityByName' hinzugefügt werden, wenn die IP-Adresse erkannt wird.
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
);Für eine Einheit, die über die beiden IP-Adressen 172.20.1.1 und 192.168.1.3 verfügt, bedeutet diese Konfiguration, dass 172.20.1.1 nicht als IP-Adresse für die Verwaltung der Einheit ausgewählt wird. Stattdessen wird 192.168.1.3 verwendet. Das folgende Beispiel stellt dar, wie der endgültige Topologieeintrag in der Tabelle 'master.entityByName' in diesem Beispiel aussieht. Die Daten im Abschnitt 'ExtraInfo', denen 'm_ScopeSpecial' vorangestellt ist, stammen aus dem Eintrag 'scope.zones', der mit der IP-Adresse 192.168.1.3 übereingestimmt hat.
{
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;
}