Table Of Contents

The Helpers

The Helpers

Configuring the Helpers

Configuring the ARP Helper

Configuring the DNS Helper

Configuring the PING Helper

Configuring the SNMP Helper

Configuring the TELNET Helper

The Helper databases

The ARP Helper database

The DNS Helper database

The PING Helper database

The SNMP Helper database

The TELNET Helper database

The Helper Server database schemata

The ARP Helper database schema

The DNS Helper database schema

The PING Helper database schema

The SNMP Helper database schema

The TELNET Helper database schema

Conclusion

The Helpers

---

This section describes the Helpers and the databases they use in servicing requests from the Helper Server to retrieve information from the network. You are also shown how to configure the operation of the Helpers using their configuration files.

The Helpers

The Helpers are part of the Helper System. They are processes that are responsible for going to devices and retrieving requested information. The Helpers deposit the gathered information in the Helper Server for retrieval by the Agents. By default there are five Helpers; they are described in Table 12-1.

Table 12-1 The different types of Helpers currently available with MWFM NMOS

Helper name	Executable name	Description
ARP Helper	riv_dh_arp	Performs IP address to MAC address resolution.
DNS Helper	riv_dh_dns	Gives the name of a particular device based on the IP address.
PING Helper	riv_dh_ping	Pings each device in a subnet, an individual IP address or the broadcast or multicast addresses. The result of this would not be of concern to the caller but may be used to populate a device's MIB.
SNMP Helper	riv_dh_snmp	Returns results of an SNMP request such as get, getnext, getbulk, etc.
TELNET Helper	riv_dh_telnet	Performs a TELNET to a specified device and parses the result back to the calling application.

Configuring the Helpers

Similar to the Finders, the Helpers are flexible because you can configure the operation of the Helpers by making OQL inserts into the appropriate databases. These configuration databases are created and initialized with default values when MWFM NMOS is started, so it is not mandatory that you configure the databases.

Table 12-2 Location of the configuration files for each of the Helpers

Finder	Configuration file and location
ARP Helper	$RIV_HOME/etc/DiscoARPHelperSchema.cfg
DNS Helper	$RIV_HOME/etc/DiscoDNSHelperSchema.cfg
PING Helper	$RIV_HOME/etc/DiscoPingHelperSchema.cfg
SNMP Helper	$RIV_HOME/etc/DiscoSnmpHelperSchema.cfg $RIV_HOME/etc/RivSnmpStackSchema.cfg
TELNET Helper	$RIV_HOME/etc/DiscoTelnetHelperSchema.cfg $RIV_HOME/etc/RivTelnetPasswordSchema.cfg

The Helper System uses one database for each Helper to configure the Helpers' operations. These databases are defined in the appropriate Helper configuration files, which are discussed below.

Configuring the ARP Helper

The operation of the ARP Helper is configured by the configuration file DiscoARPHelperSchema.cfg, located in $RIV_HOME/etc/. The ARP Helper accepts its configuration information in a database format, which enables you to make amendments using OQL statements. The configuration database is called the ARPHelper database (ARPHelper) and it consists of one table, the configuration table (ARPHelper.configuration).

The configuration table

The configuration table specifies the operation of the ARP Helper. The configuration table contains only one record and the type of information therein is listed below.

Table 12-3 The configuration table: ARPHelper.configuration 

Table column name	Properties (column constraints)	Column data type	Description
m_NumThreads		Integer	The number of threads to be used by the Helper.

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the ARP Helper:

insert into ARPHelper.configuration ( m_NumThreads ) values ( 1 );

Configuring the DNS Helper

The operation of the DNS Helper is configured by the configuration file DiscoDNSHelperSchema.cfg, located in $RIV_HOME/etc/. The DNS Helper accepts its configuration information in a database format, which enables you to make amendments using OQL statements. The configuration database is called the DNSHelper database (DNSHelper) and it consists of one table, the configuration table (DNSHelper.configuration).

The configuration table

The configuration table specifies the operation of the DNS Helper. The configuration table contains only one record and the type of information contained therein is listed below.

Table 12-4 The configuration table: DNSHelper.configuration

Table column name	Properties (column constraints)	Column data type	Description
m_NumThreads		Integer	The number of threads to be used by the Helper.
m_TimeOut		Integer	The maximum time to wait for a response from a device (seconds).

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the DNS Helper:

insert into DNSHelper.configuration ( m_NumThreads, m_TimeOut ) values ( 1, 5 );

Configuring the PING Helper

The operation of the PING Helper is configured by the configuration file DiscoPingHelperSchema.cfg, located in $RIV_HOME/etc/. The PING Helper accepts its configuration information in a database format, which enables you to make amendments using OQL statements. The configuration database is called the pingHelper database (pingHelper) and it consists of one table, the configuration table (pingHelper.configuration).

The configuration table

The configuration table specifies the general rules of the ping methodology. In this table, you are allowed to specify some degree of flexibility in the ping operation. The configuration table contains only one record and the type of information contained therein is listed below:

•The number of threads that the Helper is allowed to use.

•The maximum time to wait for a reply from a device (the timeout).

•The time interval (milliseconds) between successive ping attempts of subnet addresses.

•The number of times a device should be re-pinged (the timeout increases by the default value on each retry).

•A flag used to denote whether broadcast address pinging is allowed.

•A flag used to denote whether multicast address pinging is allowed.

Though pinging of broadcast/multicast addresses will allow devices to be discovered quicker than other detection methods, it is sometimes less desirable to do so under certain network conditions—for instance, when the network is heavily congested.

.

Table 12-5 The configuration table: pingHelper.configuration 

Table column name	Properties (column constraints)	Column data type	Description
m_NumThreads		Integer	The number of threads to be used by the Helper.
m_TimeOut		Integer	The maximum time to wait for a reply from a pinged address.
m_InterPingTime		Integer	The time interval (milliseconds) between successive ping attempts of subnet addresses.
m_NumRetries		Integer	The number of times a device should be re-pinged.
m_Broadcast		Integer	Flag used to enable or disable broadcast address pinging: Enable (1) Disable (0)
m_Multicast		Integer	Flag used to enable or disable multicast address pinging: Enable (1) Disable (0)

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the PING Helper:

insert into pingHelper.configuration ( m_NumThreads, m_TimeOut, m_NumRetries, m_InterPingTime, m_Broadcast, m_Multicast ) values ( 20, 250, 5, 50, 0, 0 );

Configuring the SNMP Helper

The operation of the SNMP Helper is configured by the configuration file, DiscoSnmpHelperSchema.cfg. In order to give the SNMP Helper the flexibility to access many devices, you have to configure the community strings that will enable the SNMP Helper to gain access to these devices. Community strings can be configured on a per-device or per-subnet basis and this is done by configuring the SNMP device access and password configuration file, RivSnmpStackSchema.cfg. Both files are located in $RIV_HOME/etc/.

---

Note Only SNMP v1 is supported in MWFM 2.0.1.

---

The SNMP Helper accepts its configuration information in a database format, which enables you to make amendments using OQL statements. The configuration database is called the snmpHelper database (snmpHelper) and it consists of one table, the configuration table (snmpHelper.configuration).

The configuration table

The configuration table is used to specify the general rules of SNMP information retrieval. In this table, you are allowed to specify some degree of flexibility in the SNMP operation. The configuration table contains only one record and the type of information contained therein is listed below:

•The number of threads that the Helper is allowed to use.

•The maximum time to wait for a reply from a device in milliseconds (the timeout).

•The number of attempts to retrieve SNMP variable(s) from a device (increasing the timeout by the default value on each retry).

•The delay to be added to the timeout on each SNMP retry (this delay is used in collaboration with the next variable defined in Table 12-6, i.e., GetNextBoundary).

•The minimum SNMP variable list size that would signify that an increment of the timeout value is needed.

•A flag used to denote whether all GetCommunityString requests should be issued in parallel

.

Table 12-6 The configuration table: snmpHelper.configuration 

Table column name	Properties (column constraints)	Column data type	Description
m_NumThreads		Integer	The number of threads to be used by a Helper.
m_TimeOut		Integer	The maximum time to wait for a reply from a device.
m_NumRetries		Integer	The number of attempts to retrieve SNMP variable(s) from a device.
m_GetNextSlowDown		Integer	The additional delay to add to the timeout on each retry.
m_GetNextBoundary		Integer	The minimum required list size needed in order to imply that an increase in the default timeout value is needed.
m_Parallel		Integer	Flag denoting whether all requests should be in parallel.

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the SNMP Helper:

insert into snmpHelper.configuration ( m_NumThreads, m_TimeOut, m_NumRetries, m_GetNextSlowDown, m_GetNextBoundary, m_Parallel ) values ( 20, 5, 10, 20, 500, 0 );

SNMP Helper community string and device access configuration

In order to fully enable the SNMP Helper to conduct its operation, it is important that you first provide it with the community strings that will be used to access the various devices on the network and, hence, give it the ability to retrieve requested MIB variables from the device. This information is supplied to the SNMP Helper using the RivSnmpStackSchema.cfg configuration file.

The SNMP Helper community string configuration file allows you to specify community strings on a per-device basis as well as on a per-subnet basis. The SNMP Helper accepts its security configuration in a database format, which enables you to make amendments easily using OQL insert statements. The database that retains the security configuration is called the snmpStack database (snmpStack) and it contains two tables, the configuration table (snmpStack.configuration), and the verSecurity table (snmpStack.verSecurity).

The configuration table

The configuration table of the snmpStack database allows you the flexibility of specifying either manual or automatic configuration of the SNMP version the Helper is to use. If you specify that an automatic configuration should be used then the SNMP Helper will initially attempt to use SNMP V3 for device access; if unsuccessful it will use SNMP V2, then SNMP V1. If automatic configuration is specified, the SNMP Helper will ignore the entries in the versions table. The information contained within the configuration table is shown below.

Table 12-7 The configuration table: snmpStack.configuration 

Table column name	Properties (column constraints)	Column data type	Description
m_AutoVersion	Externally defined boolean data type	Integer	Flag turning automatic SNMP versioning on (1) or off (0).

The verSecurity table

The verSecurity table allows you to map an IP or subnet address with an SNMP version (1, 2, or 3). The security parameters must be configured, as specified by the SNMP version, in order to gain SNMP access to the network device(s), e.g., the use of community strings for SNMP versions 1 and 2, as well as the specification of the different security levels offered by SNMP V3. The flexibility of the fields gives you the ability to specify device access information on a per-device or per-subnet basis.You can distinguish between SNMP set community strings and SNMP get community strings.

Table 12-8 The versions table: snmpStack.verSecurity 

Table column name	Properties (column constraints)	Column data type	Description
m_IpOrSubNetVer		Text	The IP or subnet address to which the device access configuration specified by this record is applicable. The interpretation of this field as an IP or a subnet address is dependent on the value specified in the m_NetMaskBitsVer field.
m_NetMaskBitsVer		Integer	The subnet mask for the address specified by the m_IpOrSubNetVer field. If this field is set to 32 then m_IpOrSubNetVer is taken as a single IP address.
m_SNMPVersion	NOT NULL	Text	The SNMP version that this configuration applies to. SNMP V1 (0) SNMP V2 (1) SNMP V3 (3) Note SNMP V3 is represented by the integer 3 rather than the expected value of 2; this is a common source of error.
m_Password		Text	The password to try for this IP or subnet address, e.g., community string.
m_Type		Integer	An integer classification of the password type SNMP set password (1), or SNMP get password (2).
m_SNMPVer3Level		Integer	Integer representation of the SNMP V3 security level.
m_SNMPVer3Details		Object of type V3SecInfo	An object representation of the authpassword and/or privpassword details for SNMP V3.
m_SecurityName		Text	The SNMP V3 security password.

Example configurations

The following section shows you examples of how the SNMP Helper is configured with device access information by appending the appropriate inserts to the configuration file.

SNMP versioning

The following example shows the use of auto-versioning when configuring the SNMP device access parameters:

insert into snmpStack.configuration ( m_AutoVersion ) values ( 1 // Auto-versioning turned on );

The OQL insert in the above example is an insertion into the configuration table of the RivSnmpStackSchema.cfg configuration file. Auto-versioning is turned on.

Configuration of the SNMP verSecurity table

The following OQL insert into the verSecurity table of the RivSnmpStackSchema.cfg configuration file shows how you can manually configure the SNMP version:

insert into snmpStack.verSecurity ( m_SNMPVersion, m_Password, m_SNMPVer3Level, m_SNMPVer3Details, m_SecurityName, ) values ( 0, `public', 2, { m_AuthPswd="authpassword", m_PrivPswd="privpassword" }, `authPriv' );

With auto-versioning turned on, a community string of `public' will be used for devices that support SNMP version 2 and specific configuration used for devices that support SNMP version 3.

Configuring the TELNET Helper

The operation of the TELNET Helper is configured by the configuration file DiscoTelnetHelperSchema.cfg. In order to give the TELNET Helper the flexibility to access many devices, you have to configure the attributes and parameters that will enable the TELNET Helper to gain access to them; this is done by configuring the TELNET access and password configuration file, RivTelnetPasswordSchema.cfg. Both files are stored in $RIV_HOME/etc/. The TELNET Helper accepts its configuration information in a database format, which enables you to make amendments by using OQL statements. The configuration database is called the telnetHelper database (telnetHelper) and it consists of one table, the configuration table (telnetHelper.configuration).

The configuration table

The configuration table specifies the general rules of receiving information from remote devices. In this table, you describe the commands that streamline the flow of information during the TELNET operation, using the following types of information:

•The number of threads that the Helper is allowed to use.

•The maximum time in seconds to wait for access to a device (the timeout).

•The command to issue in order to set the output page length (set to "set length" by default).

•The size of the output page length (this entry is set to zero (0)—i.e., no paging—by default).

•The message to expect from the remote device when it begins to page output, e.g., "Do you want to continue" (regular expressions constitute valid entries).

• The command necessary in order to enable the remote device to continue the paged output (this is usually set to "y").

.

Table 12-9 The configuration table: telnetHelper.configuration

Table column name	Properties (column constraints)	Column data type	Description
m_NumThreads		Integer	The number of threads to be used by the Helper.
m_TimeOut		Integer	The maximum time to wait for access to a device.

Table 12-10 The configuration table: telnetHelper.deviceConfig 

Table column name	Properties (column constraints)	Column data type	Description
m_IpOrSubNet		Text	The IP or fully qualified subnet address of the device corresponding to a particular configuration. If this is not specified, the configuration is used as the default subnet address.
m_NetMaskBits		Integer	The number of most significant bits in the netmask. This number must be specified if m_IpOrSubNet is specified.
m_PageLengthCmd		Text	The command to issue in order to set the output page length (the default value is set to "set length").
m_PageLength		Integer	The output page length size. This is set to zero by default, i.e., no paging.
m_ContinueMsg		Text	The expected prompt from the remote device between paged output, e.g., "Do you want to continue". Regular expressions are valid entries.
m_ContinueCmd		Text	The response to send to the remote device in order for it to continue the paged output. This is usually set to "y".

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the TELNET Helper:

insert into telnetHelper.configuration ( m_NumThreads, m_TimeOut, ) values ( 20, 5, "set length", 20, ".*wish to continue.*", "y" ); insert into telnetHelper.configuration ( m_IpOrSubNet, m_NetMaskBits, m_PageLengthCmd, m_PageLength, m_ContinueMsg, m_ContinueCmd ) values ( 192.168.112.0, 24, "set length", 0, "y" );

TELNET Helper password configuration

You must configure the access parameters in order to enable the TELNET Helper to gain access to devices on your network; this is done by configuring the access and password configuration file RivTelnetPasswordSchema.cfg.

The TELNET Helper accepts its access configuration information in a database format, which enables you to make amendments using OQL statements. The access configuration database is called the telnetStack database (telnetStack) and it consists of one table, the passwords table (telnetStack.passwords).

The passwords table

The passwords table is used to specify the general device access rules of the TELNET operation. In this table, you are allowed to specify some degree of flexibility in the TELNET operation. The information contained within each record of the configuration file is listed below.

•The IP or subnet address; the resolution of this entry to either an IP address or a subnet address is based on the value contained within the subnet mask.

•The subnet mask. If the value is set to 32, the above entry is interpreted as an individual IP address.

•The timeout, i.e., maximum time to wait for a response from a remote device before considering the session to have timed out (default = 10 seconds).

•The password to attempt for devices within the declared IP address or subnet; the default value for this field is "\n", i.e., a carriage return.

•The username to attempt for devices within the declared IPaddress or subnet; the default value for this field is "", i.e., a null character.

•The password prompt to expect from the remote device (regular expressions are valid entries); the default value is set to ".*assword:.*".

•The login prompt to expect from the remote device (regular expressions are valid entries); the default value is set to ".*ogin:.*".

•The console prompt to expect; this is usually a regular expression. By default, it is set to a regular expression that captures all characters, i.e., "^.*[a-zA-Z0-9].*[$%>#]$".

Table 12-11 The passwords table: telnetStack.passwords 

Table column name	Properties (column constraints)	Column data type	Description
m_IpOrSubNet		Text	IP or subnet address depending on value of m_SubNetMask.
m_NetMaskBits		Integer	The subnet mask. If set to 32, m_IpOrSubNet is taken to be a single IP address.
m_TimeOut		Integer	Maximum time to wait for remote device response before aborting the session. Default =10 seconds.
m_Password	NOT NULL	Text	The password to try for this subnet or IP address. Default = "\n".
m_Username		Text	The username to try for this subnet or IP address. Default = "".
m_PwdPrompt		Text	Password prompt to expect from remote device. Default = ".*assword:.*"
m_LogPrompt		Text	Login prompt to expect from remote device. Default = ".*ogin:.*"
m_ConPrompt		Text	Console prompt to expect from remote device. Default = "^.*[a-zA-Z0-9].*[$%>#]$"

Example configurations

The following example shows how you can append OQL insertion statements to the configuration file in order to configure the operation of the TELNET Helper:

insert into telnetStack.passwords ( m_IpOrSubNet, m_NetMaskBits, m_Password, m_Username, m_PwdPrompt, m_LogPrompt, m_ConPrompt ) values ( '172.18.1.21', 32, '', '', '.*assword.*', '.*sername.*', '.*Morr.*' );

The Helper databases

The Helper databases are created when the Helper Server starts and loads up the Helper Server Schema configuration file, DiscoHelperServerSchema.cfg. The number of databases created depends on the number of Helpers that will be allowed to run, since each Helper has its own database.

The Helper databases are active databases that consist of one table each. The structure of each Helper's database is specific to the type of information it is designed to retrieve. The information about each Helper's database is listed in the following sections.

Figure 12-1 Diagram showing the databases of the various Helpers

The ARP Helper database

The ARP Helper database (ARPHelper) serves as the repository for information about the requests the ARP Helper makes from the network. The ARP Helper database contains only two tables, the ARPHelperTable table (ARPHelper.ARPHelperTable) and the ARPHelperConfig table (ARPHelper.ARPHelperConfig).

The ARPHelperTable table

The information stored by the ARPHelperTable table about each request is listed below.

•A unique request Reply key interface to the databases of the Helper Server.

•A request Get key interface to the databases of the Helper Server.

•How long the requested information is to live within the Helper Server.

•The IP address of the physical device which the Helper is to interrogate for information.

•The subnet of the host device to be interrogated.

•The subnet mask of the host device to be interrogated.

•The ID of the VLAN to which the interrogated host device belongs.

•The MAC address of the host device.

The ARPHelperConfig table

•The information stored by the ARPHelperConfig table relates to the overall behavior of the ARP Helper database.

•The Helper database timeout, i.e., how long before the database expires in the absence of any activity.

•The Helper request timeout, i.e., how long before each request expires.

•The default Helper start-up timeout, i.e., the maximum time to wait for a Helper to start up when requested.

The DNS Helper database

The DNSHelper database (DnsHelper) serves as the repository for information about the requests the DNS Helper makes from the network. The DNSHelper database contains two tables, the DNSHelperTable table (DnsHelper.DnsHelperTable) and the DNSHelperConfig table (DnsHelper.DnsHelperConfig).

The DNSHelperTable table

The information stored by the DNSHelperTable table about each request is listed below.

•A unique request Reply key interface to the databases of the Helper Server.

•A request Get key interface to the databases of the Helper Server.

•How long the requested information is to live within the Helper Server.

•The primary host name for the address to be interrogated.

•The primary IP address for the device to be interrogated.

•A list of host names by which the device is known.

•A list of IP addresses by which the device is known.

The DNSHelperConfig table

The information stored by the DNSHelperConfig table about the overall behavior of the DNS Helper database behavior:

•The Helper database timeout, i.e., how long before the database expires in the absence of any activity.

•The Helper request timeout, i.e., how long before each request expires.

•The default Helper start-up timeout, i.e. the maximum time to wait for a Helper to start up when requested to.

The PING Helper database

The PingHelper database (PingHelper) serves as the repository for information about the requests the PING Helper makes from the network. The PingHelper database contains two tables, the PingHelperTable table (PingHelper.PingHelperTable) and the PingHelperConfig table (PingHelper.PingHelperConfig).

The PingHelperTable table

The information stored by the PingHelperTable table about each request is listed below.

•A unique request Reply key interface to the databases of the Helper Server.

•A request Get key interface to the databases of the Helper Server.

•How long the requested information is to live within the Helper Server.

•The IP address the Helper is to ping.

•The subnet the Helper is to ping.

•The mask of the subnet the Helper is to ping.

•The type of request made by the Helper.

•The type of reply received by the Helper.

•The number of times the Helper is allowed to retry the ping.

•The ping timeout, i.e., maximum time to wait for a response from the address.

•A list of IP addresses that respond to the ping.

The PingHelperConfig table

The information stored by the PingHelperConfig table about the overall behavior of the PING Helper database behavior:

•The Helper database timeout, i.e., how long before the database expires in the absence of any activity.

•The Helper request timeout, i.e., how long before each request expires.

•The default Helper start-up timeout, i.e. the maximum time to wait for a Helper to start up when requested to.

The SNMP Helper database

The SnmpHelper database (SnmpHelper) serves as the repository for information about the requests the SNMP Helper makes from the network. The SnmpHelper database is made of only two tables, the SnmpHelperTable table (SnmpHelper.SnmpHelperTable) and the SnmpHelperConfig table (SnmpHelper.SnmpHelperConfig).

The SnmpHelperTable table

The information stored by the SnmpHelper table about each request is listed below.

•A unique request Reply key interface to the databases of the Helper Server.

•A request Get key interface to the databases of the Helper Server.

•How long the requested information is to live within the Helper Server.

•The IP address of the physical device which the Helper is to interrogate for information.

•The SNMP password to grant device access, i.e., the community string.

•The Object ID for the Get request.

•The request index, if the request type is a GetNext SNMP request.

•The Type of SNMP request, i.e., Get, GetNext, GetResponse etc.

•The request reply index.

•The value of the request reply.

•The Object ID for the reply.

The SnmpHelperConfig table

The information stored by the SnmpHelperConfig table about the overall behavior of the SNMP Helper database behavior:

•Helper database timeout i.e. how long before the database expires in the absence of any activity.

•The Helper request timeout i.e. how long before each request expires.

•The default Helper start-up timeout, i.e., the maximum time to wait for a Helper to start up when requested to do so.

The TELNET Helper database

The TELNET Helper database (TelnetHelper) serves as the repository for information about the requests the TELNET Helper makes from the network. The TELNET Helper database is made up of two tables, the TelnetHelperTable table (TelnetHelper.TelnetHelperTable) and the TelnetHelperConfig table (TelnetHelper.TelnetHelperConfig).

The TelnetHelperTable table

The information stored by the TelnetHelperTable table about each request is listed below.

•A unique request Reply key interface to the databases of the Helper Server.

•A request Get key interface to the databases of the Helper Server.

•How long the requested information is to live within the Helper Server.

•The IP address of the physical address which the Helper will interrogate for information.

•The IP address of the physical device which the Helper is to interrogate for information.

•The TELNET command the Helper is to send to the device.

•The reply to the command sent by the Helper to the device.

The TelnetHelperConfig table

The information stored by the TelnetHelperConfig table about the overall behavior of the TELNET Helper database behavior:

•The Helper database timeout, i.e., how long before the database expires in the absence of any activity.

•The Helper request timeout, i.e., how long before each request expires.

•The default Helper start-up timeout, i.e., the maximum time to wait for a Helper to start up when requested to do so.

The Helper Server database schemata

The schemata of each Helper's database within the Helper Server are show in Table 12-12.

The ARP Helper database schema

Table 12-12  Synopsis of the ARP Helper database and its tables

Database name	ARP Helper database: ARPHelper
Database definition location	$RIV_HOME/etc/DiscoHelperServerSchema.cfg
Fully qualified database table names	ARPHelper table: ARPHelper.ARPHelperTable ARPHelperConfig table: ARPHelper.ARPHelperConfig

Table 12-13 The ARP Helper table: ARPHelper.ARPHelperTable 

Table column name	Properties (column constraints)	Column data type	Description
RivHelperRequestReplyKey	PRIMARY KEY NOT NULL UNIQUE	Text	Unique request reply key.
RivHelperRequestGetKey	NOT NULL	Text	The request get key.
RivHelperDbTimeToDie		Long64	The death time of the requested information.
m_HostIp	NOT NULL	Text	IP address of the device to interrogate.
m_HostSubnet		Text	Subnet of the IP address to be interrogated.
m_HostMask		Text	The subnet mask.
m_HostMac		Text	The physical address of the device (MAC address).

Included in the ARPHelperConfig table below are extra options that require further explanation. The m_HelperDoWeQuery and m_HelperDoWeStore fields each have two related optional fields (m_HelperDoNotQueryVBs and m_HelperDoQueryVBs, and m_HelperDoNotStoreVBs and m_HelperDoStoreVBs respectively).

A record entered into either m_HelperDoWeQuery or m_HelperDoWeStore is the default setting to which the Helper responds if no records are entered into the optional fields. However, a record entered into either of the related optional fields overrides this setting.

In the field m_HelperDoWeQuery you can determine whether the Helper Server should query its database or the network. If, however, you enter a record into the optional field m_HelperDoNotQueryVBs this will override m_HelperDoWeQuery. For example, if m_HelperDoWeQuery is set to query the network (i.e., m_HelperDoWeQuery (0)) and if a record (m_IpAddress, 192.168.0.1) is then specified in m_HelperDoNotQueryVBs, then a request record which has the field m_IpAddress = 192.168.0.1 will result in the database being queried. If the device is found in the database then the network will not be queried.

Table 12-14 The ARP HelperConfig table: ARPHelper.ARPHelperConfig 

Table column name	Properties (column constraints)	Column data type	Description
m_HelperDbTimeout	UNIQUE	Long 64	The Helper database timeout, i.e., how long before the database expires.
m_HelperReqTimeout		Long 64	The Helper request timeout, i.e., how long before each request expires.
m_HelperStartupTimeout		Long 64	The default Helper start up timeout, i.e., the maximum time to wait for a Helper to start up when requested.
m_HelperDoWeQuery		Integer	Whether the Helper Server queries its database or whether it queries the network via a Helper. 0 = do not use cache 1 = use cache
m_HelperDoNotQueryVBs (optional)		Object type Varbinds	List of Helper inputs which do not query the database. This field is irrespective of m_HelperDoWeQuery.
m_HelperDoQueryVBs (optional)		Object type Varbinds	List of Helper inputs which always query the database before querying the network. If the item is found in the database then the network will not be queried.
m_HelperDoWeStore		Integer	Whether the Helper Server stores any replies from the Helpers in its database. 0 = do not store replies in database 1 = store replies in database
m_HelperDoStoreVBs (optional)