Contents

1   Introduction

This document describes how to use the Configuration Management (CM) function in the IPWorks.

1.1   Related Information

Trademark information, typographic conventions, and definition and explanation of abbreviations and terminology can be found in the following documents:

• Trademark Information
• Typographic Conventions
• Glossary of Terms and Acronyms

2   Basic Concepts

This section defines the basic concepts used when working with the Configuration Management (CM) in the IPWorks product.

It describes the IPWorks schema, the data model that is used to configure the services within a network and is also the base of the IPWorks architecture.

IPWorks provides two configuration methods. One is provided by Ericsson Command-Line Interface (ECLI) to control basic functions of IPWorks components. This method is based on the Ericsson Information Model (ECIM) compliant Managed Object Model (MOM). The other method is IPWorks CLI (also called as IPWCLI), it is used to perform provisioning related configuration for DNS, ASDNS, and ENUM related objects.

For more information about how to use IPWCLI and ECLI, refer to Managed Object Model User Guide and Command Line Interface User Guide for IPWorks SS.

2.1   Managed Object Model (ECLI)

In IPWorks, Ericsson Command-Line Interface (ECLI) is used for controlling the basic functions of the IPWorks components, including:

• Configuring logging of IPWorks processes.
• Defining configuration parameters specific to the current host.
• Determining whether enable or disable functions.

The IPWorks managed objects used by ECLI are represented in the Managed Object Model (MOM) as follows:

ManagedElement
  +-IpworksFunction
    +-IPWorksAAARoot
      +-IPWorksAAACommonRoot
      +-IPWorksDiameterAAARoot
      +-IPWorksRadiusAAaRoot
    +-IpworksCommonRoot
      +-StorageServer
    +-IpworksDnsRoot
      +-AsdnsServer
      +-DnsServer
      +-IpworksEnumRoot
      +-ServerType

For general information about the MOM, MOCs, MOs, cardinality, and related concepts, refer to Managed Object Model User Guide.

Table 1 describes the IPWorks specific Managed Object Classes (MOCs).

2.2   IPWorks Managed Objects (IPWCLI)

The IPWorks configuration is defined by a set of configuration objects. These objects are managed in the IPWCLI. Each object has a class which determines how the object is used.

Every object has a set of fields associated with it. The fields associated with an object are determined by the class of the object. Fields have values that are specific to that object. Some multi-valued fields preserve the order of the values. For object classes, there are fields that require a value, while other fields are optional.

For every object, there is a set of fields that uniquely identify that object. These fields are referred to as the key fields and the values of those fields are called the key values. The combination of key values must be unique. They are also used to identify that object.

Some classes also have special operations that are performed on the managed objects. These operations may take parameters.

For details about the IPWorks managed objects used by IPWCLI, refer to IPWorks DNS, ASDNS, ENUM Parameter Description.

2.2.1   Organizational Concepts

This section introduces classes that assist the organization of data in IPWCLI.

2.2.1.1   Partition

A partition is a management container that allows the user to maintain different sets of data within IPWorks. All objects are placed into a partition.

• When a new object is created, the object is assigned to a specific partition.
• If the user is working with multiple partitions, all the objects in one partition are independent of objects in another partition.

Therefore, the partition acts as a data separation mechanism.

IPWorks predefines the active partition. It is used to manage data that is active on the network. Other partitions can be created for test or experiment purposes. However, only the active partition is used for publishing data in the PL. Using scoping, this partition is set up as the default partition for all actions.

Note:  

Unless the user wants to work within a different partition, the partition being worked on does not need to be specified. IPWorks assumes that the partition is active.

A partition isa named container that can be seen using the list command.

The following is a sample command for partitions.

IPWorks> list partitions

[Partition active]
	 Name: active

A partition object is considered as a prerequisite for all objects contained in the partition. Therefore, if any partition other than the active partition is used, the partition object must be created before any object in the partition is created.

Data in partitions is independent of data in other partitions, therefore partitions can be used in experimental containers. A configuration is created, experimented with, or examined by the resulting configuration files, and so on. This can be done without any impact on the active data.

For example, there is an external file called gprs.cli includes all the commands for creating the sample GPRS network. To create a partition that contains these objects to experiment with, use the following commands:

IPWorks>create partition gprs
1 object(s) created.
IPWorks> scope partition gprs
IPWorks> gprs.cli -trace
... <actual command output removed> ...

These commands create a partition and set the scope. All the subsequent operations are performed within the partition. Then, the command file is executed with tracing turned on to display the output.

2.2.1.2   Area

An area is a virtual container used for organizing some of the managed objects in IPWorks. An area contains all the objects that define a namespace and address-space (such as resource records). The area acts as a boundary for many of the consistency checks made by IPWorks.

Some of the sample networks in this document use two separate areas, one for the internal network configuration and the other for the external network configuration. These are called internalarea and externalarea just to keep the naming schema simple. The following IPWorks CLI commands are examples for creating and displaying these areas:

IPWorks> create area internalarea -set 
description="Area for internal data"
1 object(s) created.
IPWorks> create area externalarea -set 
description="Area for external data"
1 object(s) created.
IPWorks> list areas

[Area default]
	Partition: gprs
	Name: default
[Area externalarea]
	Partition: gprs 
	Name: externalarea 
	Description: Area for external data
[Area internalarea] 
	Partition: gprs 
	Name: internalarea 
	Description: Area for internal data

Note:  

IPWorks has a predefined default area when it is installed (as shown in the example above). In sample networks where there are no overlapping address spaces, or when the network is not deployed with a split namespace, it is best to use the default area to configure the data.

2.2.2   Data Management Conventions

This section describes the basic data management conventions. To have a thorough understanding of the schema, it is suggested that users learn the data management conventions for IPWorks.

It is not allowed to create objects for data that is not managed in IPWorks. Whether the data is managed depends on related objects. These related objects indicate how the data is managed, therefore, usually a set of objects can only be created in one order.

When one object must exist for a second object to be created, the first object is called a prerequisite object and the second object is called the dependent object. This principle also requires that all dependent objects must be deleted before a prerequisite object is deleted.

As an example of these principles, consider the relationship between resource records and zones. A resource record is considered to be managed if there is at least one zone already defined that could contain the resource record. The following is a list of rules for zones and resource records that must be followed:

• A zone must be created before the resource records for that zone.
• Resource records must be within a zone, otherwise the resource record is considered unmanaged data and causes an error.
• If a zone is deleted, the resource records belonging to that zone must be deleted as well.

3   User Management

This section describes the concepts related to SS user management and access control.

For information on the configuration procedures, refer to Configure User Account.

3.1   User

The default configuration for IPWorks requires users to log on to the product to gain access to the IPWorks data. This applies to all management interfaces. To facilitate this, IPWorks has a user object that can be created to represent information about the users of the system.

Note:  

Unless the default access control has been modified, only administrators are allowed to modify user objects.

When defining a user object, the following items are included:

When IPWorks is installed, it creates an admin account that has administrative privileges. The username and password for this account are based on questions answered during the installation. Since this is the only account with privileges, it is important to remember both the account name and the password specified.

To show the definition of an admin user, refer to Showing User Definition in Configure User Account.

3.2   Profile

A profile is used in IPWorks to define a set of common access control rules that are applicable to one or more users. A user can have more than one profile, in which case the access control is consisted of the rules defined in all the profiles.

Note:  

Unless the default access control is modified, only administrators are allowed to modify profile objects.

When defining a profile object, the following items are included:

See the following example for the syntax of edit rules:

<permission> <type> [ <action> ]

Note:  

• <permission> : either allow or deny
• <type>: the type of object this rule applies to. It can be a schema class, a subclass, or the value all.
• <action>: the type of edit action the rule applies to: either create, delete or modify. If not specified, the rule applies to all edit actions for the specified class.

IPWorks is delivered with the following predefined profiles:

To show the profile definition, refer to Showing Profile Definition in Configure User Account.

3.3   Login History

IPWorks supports login management for IPWorks SS user. When an SS user logs in successfully, the login history is displayed via CLI.

The system records the login attempts between two successful logins.

• If any failed attempt is available, the system displays the number of failed attempts to SS users at the next successful login.
• If no failed attempt is available, the system displays the last successful login information (session start and stop time) to SS users at the next successful login.

3.4   Password

All passwords are stored in an encrypted form in IPWorks to ensure the highest level of security. The passwords chosen are subject to constraints as described in the following table:

(1)  The four character classes are digit, lower-case letters, upper-case letters, and special characters. The special characters are defined for the following 32 characters: `~!@#$%^&*()_-+={[]}|\:;"'<,>.?/

4   Storage Server

This section describes the concepts related to Storage Server.

4.1   Basic Concepts

The Storage Server stores objects. Each object has a class that defines basic structural information about the object. Classes can be defined as extensions of other classes (in other words, there is an inheritance hierarchy of class definitions). The class defines a set of fields that may have values for the object. Some fields have only one value, some have multiple values (that may or may not be ordered).

Each class has a field, or set of fields, whose values can be used to identify an object uniquely in that class. This unique identifier is known as the key value. In some classes the key consists of several fields, while in other it is a single field.

Each class also defines a set of relationships that exist between objects of that class and objects in other classes. Relationships are established by having one or more common values in fields between objects. Often the common values are keys. Relationships can be used to navigate among the stored objects. A relationship can link an object with one other object, or with many other objects. This depends on the context and meaning of the relationship.

Each class also defines operations that can be performed on objects in that class. An operation represents a special action that can be invoked upon an object.

The Storage Server also manages enumerations. These are known sets of values or objects that are assigned a name to simplify their retrieval. The current set of values or objects, or both, are defined as a static collection, or as search criteria to be dynamically computed if necessary.

4.2   Fields

A storage field defines a field (or attribute) that can have a value for a stored object. Following information can be defined for a field:

• Field Names: For example: display name, database name, and aliases.
• Field Type: For example: Single Valued, Multi Valued (ordered) and Multi Valued (unordered).
• Plugin Methods: These can be called to customize the field behavior. For example, methods is defined to invoke when the values are read from the field and when the values such as the data type are changed. This defines the semantics of the values that the field can have.
• Enumeration: The values of the field can be restricted by associating it with an enumeration.
• Flags: Define special characteristics for the field, for example: Read only.

4.3   Classes

A storage class defines the structure of a stored object. This includes the following:

• The fields that can have values for the object.
• How the object is to be stored in the repository.
• Which fields are used as keys for the object.
• The relationships that apply to the object.

A storage class is similar to both a Java class and an LDAP object class, but does not map directly into either one. Each stored object is an instance of only one storage class.

4.4   Relationships

A storage relationship is a link between stored objects. Relationships are ’relative’ to a ’source’ object. The relationship can be followed from the source object to the destination objects linked by that relationship.

The following relationship is one way of navigating through the stored objects. Some of the information that can be defined for a relationship are as follows:

• Search criteria to define how to find related objects.
• Fields that are used to link related object.
• Plug-in methods that can be called to customize the default behaviors.
• Flags to define special characteristics of a relationship.
• Automatic creation and deletion of related objects.

4.5   Operations

An operation represents a custom action that can be performed. The Storage Server allows the operations to be defined so that they act on a specific object, or they can be defined as global operations.

Operations can also have parameters. These are extra pieces of information (sometimes optional) that can be specified when the operation is invoked to specify how the action is performed.

4.6   Enumerations

A storage enumeration is a named set of values or stored objects. The named set can be defined by either of the following:

• List a predefined static set of values explicitly.
• Specify search criteria that are applied dynamically to determine that current values or objects to be included in the named set.

Named sets of objects are always dynamic, while named sets of values can be either static or dynamic. An enumeration that represents a set of objects can be used in a context where a set of values is required. In this situation, the key values for each object are used to form the set of values.

When the enumeration is defined, it is often defined as a current search to be performed, so that the current set of objects or values may change, except the name of the enumeration. This is one of the primary mechanisms for navigating through the stored objects.

4.7   Finding Objects

To perform operations on an object (or set of objects), first find the objects that the user is interested in. Use one of the following methods:

• Finding objects by key values: If user knows the class and keys of object, then user can retrieve the object directly.
• Finding objects in an enumeration: If there is an enumeration that defines the set of objects, then the user can retrieve the objects using that enumeration.
• Finding objects through relationships: If user uses either of the preceding methods to obtain some objects, then user can retrieve more objects by traversing the known relationships.

All searches can be customized, so that only a subset of the values is retrieved or to customize the sorting order within the returned results.

4.8   Creating Objects

To create an object, the IPWorks starts a transaction and puts the object in the transaction. A transaction guarantees consistency of the object. If creation of an object also requires creation of other objects, the creation of other objects is added to the same transaction as well.

An object can be in only one transaction at a time. The Storage Server uses locking capabilities to ensure this. Keep transactions as small and as short as possible.

4.9   Modifying Objects

To change an object, the user must first place the object in a transaction. A transaction represents a set of changes to one or more objects that must all be done together to guarantee consistency. If a change to an object also requires changes to be made to other objects, the user needs to add them to the same transaction.

4.10   Deletion of an Object

To delete an object, IPWorks starts a transaction and put the object in the transaction. Similar to modifying objects, a transaction guarantees consistency of the object. If a deletion of an object also requires deletion of other objects, the deletion of other objects is added to the same transaction as well.

4.11   Making Decisions

There are situations where the Storage Server must choose between two (or more) behaviors - someone must decide what to be done. The Storage Server provides a flexible algorithm for decisions as follows:

• Check whether there is a property in the configuration file of server that defines what to do. If so, this represents an administrator decision about what to do.
• When there is a transaction associated with the operation, check whether the client has specified a DecisionMaker . This is a client application object that interacts with the user, or checks a client-side properties file to decide what to do.
• Check whether the client session has a DecisionMaker that defines what to do.
• Check whether the value can be determined from the property defaults of the server. . It is another configuration file that the administrator can edit to provide default settings for properties.
• Use a hard-coded default for the decision.

This algorithm provides flexibility to both client applications and administrators in how decisions get made.

5   DNS Management

This section provides concepts that are required for mapping DNS.

For information on how to configure IPWorks DNS, refer to Configure DNS and ENUM.

5.1   DnsServer

A DnsServer object represents a DNS server that is running on the network.

For more information about the object, refer to the DnsServer section in IPWorks DNS, ASDNS, ENUM Parameter Description.

5.1.1   Auto Register

If an IPWorks DNS server is installed on a system in the network, it can be configured to auto-register when the Server Manager is started. In the process of doing this, it creates a DnsServer object in the database to correspond to the active server. It is defined with the IP addresses and domain names for that system. With this feature, it is unnecessary to create the object manually. Review the automatically created object to ensure that it reflects the configuration that is required for the DNS server.

5.1.2   DNS Server IPv6 Support

IPWorks DNS server supports queries on both IPv4 and IPv6 transport as specified by listen-on option and listen-on-v6 option. When creating a DnsServer object, it is configured with IPv4 support by default. If IPv6 supported is needed, the option listen-on-v6 must be specified. When the option is used to configure IPWorks DNS server in order for it to listen for incoming queries using different version of Internet Protocol, the option is configured as follows:

• Queries using IPv4: listen-on
• Queries using IPv6: listen-on-v6
• Queries using both IPv4 and IPv6: both listen-on and listen-on-v6

For more information about how to configure IPv6 for DNS, refer to the Section DNS Server IPv6 Support in Configure DNS and ENUM.

5.2   View

A View object is a DNS management concept used to present a name-server configuration to a community of hosts and a different configuration to another community, based on the IP addresses of the hosts. Views permit the support of multiple (possibly conflicting) definitions of zones within a DNS server. Many DNS configurations do not need to use any views. The reason for using views in the DNS configuration is to implement a split namespace (having a zone with different internal and external definitions) within a single DNS server.

Within the configuration of a DNS server, all the zones are considered to be within a view. When a DNS server is created, a default view is automatically created for each server. All zones in that server that are not added to a view are automatically associated with the default view.

For more information about the object, refer to the View section in IPWorks DNS, ASDNS, ENUM Parameter Description.

Default View

In addition to views that are created, every DNS server also has a default view. When the zones are created, they are placed in the default view if a view is not specified. When a view is created, the default area for zones that are in the view must be specified. This is the area that is used as the source for resource records for zones in that view if the zone does not specify an area.

5.3   Zones

A Zone is an area of authority within the DNS name space. It is important to understand what zones are managing the DNS. For details on DNS, refer to DNS and BIND 4th Edition.

Every zone in the DNS has a server that is designated as the primary or master authority for that zone. In addition, zones can have other DNS servers that are designated as secondary or slave authorities for the zone. These are other servers that are considered as authoritative sources for the zone, but they obtain their authoritative data from the master server for that zone. The slave servers provide redundancy in the network in case the master server goes down.

The most important aspects in configuring the DNS within the network are planning the following details:

• Where the servers are run?
• Which servers are masters?
• Which servers are slaves for each zone?

In IPWorks, zones are not created explicitly. Instead, declarations are created within each server for the role that the server has for the zone. For example, if a DNS server is a master for a zone, then this is indicated by creating a MasterZone object within that DNS server.

IPWorks DNS has the following types of zones (see Table 4):

(1)  If the DNS Server is down, or is unavailable, then the records in that zone are also unavailable (not just on the network, but also unavailable in IPWorks).

(2)  If DDNS is not used, then there is no need for dynamic zones.

(3)  If data is changed on the DNS server system, but not in the central database, it will be overwritten the next time the server is updated. When a MasterZone is created, it is configured as a static zone by default.

For more information about the parameters of zones, refer to the Zones section in IPWorks DNS, ASDNS, ENUM Parameter Description.

5.4   DNS Resource Records

Resource records are the basic elements used in DNS to represent data to be distributed by the DNS protocol. It is good to consult an external reference if not familiar with the concepts. Many types of resource records are available in the DNS. Some of them are more important to the overall DNS configuration than others, so IPWorks provides extra support, data-checking, and custom behaviors for some of these resource records to ensure that the overall DNS configuration is correct.

In the DNS protocol, resource records are organized into zones based on the dnsname that they are associated with. This dnsname is also called the owner dnsname and must be specified for all resource records.

Another important field on all resource records is the container. All resource records in IPWorks are either contained in a specific zone, or they are contained in an area. Resource records that are contained in an area can be shared in multiple zones. The value of the container field must be set as follows:

• If the resource record is contained in a specific zone, the container field must be set to the Zone for the MasterZone that contains the record. Only three types of records are to be defined in this way: SOARecords, NSRecords, and ARecords that are needed as glue for the NS and SOARecords.
• If the resource record is contained in an area, the container field must be set to the name of the area. The record is then compared with all the zones that are associated with the area to determine (based on the owner dnsname) which zones include this resource record.
• If the container field is not specified, IPWorks checks all known MasterZones to determine which zone (or zones) can include the record. The record is then automatically added to the area associated with these MasterZones if only one possible area is available. If multiple possible areas are available, then there is a prompt to identify the area that can include the resource record.

Table 5 lists the types of records that have customized support.

(1)  Although a DnsServer has fields for both its dnsname and Address, IPWorks does not automatically create ARecords or PTRRecords for the server. If the ARecords or PTRRecords are wanted for the DnsServer, the user needs to create them manually.

For more information about the parameters of the DNS resource records, refer to the DNS Resource Records section in IPWorks DNS, ASDNS, ENUM Parameter Description.

5.5   ACL

An ACL is a named access control list, or address match list that is used to specify sets of incoming clients in the configuration options that are used for controlling the server security.

A named ACL in DNS can be used to associate a name with a list of address-matching criteria. A number of options in DNS that have values that are address-match-lists. These lists are used to specify criteria to compare with incoming client requests to determine how they are handled. In many instances, the same address-match-list is used in multiple places. Named ACLs provide a mechanism that allows the definition of the list in one place and then use a name to refer to that list. This simplifies the management of these lists because it is assured that the list is propagated correctly without having to review every option in the configuration.

In IPWorks, the namespace for ACLs is shared among all the DNS servers. Hence, when an ACL is defined it can be used anywhere — even in different servers.

For more information about the object, refer to the ACL section in IPWorks DNS, ASDNS, ENUM Parameter Description.

5.6   TSIGKeys

TSIGKeys are used in the DNS for securing or authenticating packets, or both. A TSIGKey is shared by the DNS client and the DNS server. When a DNS packet is sent to the server, the name of the key and a digital signature are included in the packet. The server checks the signature for authenticity and then performs the appropriate action.

In the configuration of DNS these keys can be used in address match lists (discussed earlier). This means they can be used for identifying certain clients and for controlling access to any functions that are managed by address match lists. In IPWorks, TSIGKeys can be used for the following items:

• Securing dynamic updates sent from a DHCP server to the DNS server.
• Securing the communications between two DNS servers.
• Securing the communications between a DNS server and an ActiveSelect Monitor.
• Securing the communications between DIG, nsupdate, and a DNS server.

For more information about the object, refer to the TSIGKeys section in IPWorks DNS, ASDNS, ENUM Parameter Description.

5.7   Options

All the DNS management concepts described here (DnsServers, Views, Zones) can be further customized by specifying configuration options. This is done by adding values on a special field on the objects.

Each of these objects has a field called Option. This field can have multiple values and each value is used to specify a single configuration option and the setting for that option. The syntax of the value is as follows:

<option-name> <value 1> <value 2> ...

Many configuration options can be specified. Some options can only be applied to certain types of objects. Many of these options have complicated values when they are specified. It is important to understand both, the meaning of the option and the syntax that must be used to specify values for that option.

Note:  

When the user tries to define a value of data type AddrList as some ipnet values, IPWorks supports an abbreviated notation so that the zero at the end of the subnet address can be abbreviated. For example, subnet 192.168.0.0/16 could be written as 192.168/16.

If unsure how to define a configuration option for an object, use this command to review the option before setting it. IPWorks checks the syntax of any values that has been set for configuration options.

5.7.1   DNS Options

The user can use the command show in CLI to get more information about these options. For details, refer to the Show dns Option Commands section in Command Line Interface User Guide for IPWorks SS.

For more information about all the BIND 9 DNS options that are supported by the IPWorks DNS server, see Section 15.1.

6   ActiveSelect DNS Management

ActiveSelect DNS (ASDNS) is an IPWorks-specific feature that allows redundancy to be defined in the network. It also allows better performance of complex load balancing than the DNS protocol.

ActiveSelect DNS is an extension to the IPWorks DNS server. This extension makes DNS more dynamic when responding to queries. The IPWorks DNS server with ASDNS uses information sent to it from ASDNS Monitors so that it can make more intelligent decisions about what information to include in a response.

Use of ASDNS is optional. ASDNS can be used with standard DNS servers, though query to these standard DNS servers is not benefit from the ASDNS feature.

For information about the ASDNS managed objects about provisioning management, refer to the ActiveSelect DNS Objects section in IPWorks DNS, ASDNS, ENUM Parameter Description.

For information on how to configure ASDNS, refer to Configure DNS and ENUM.

6.1   ActiveSelect Application Scenarios

ActiveSelect DNS is useful in the following cases:

• Only addresses that are reachable are returned for queries of domain names.
• Addresses that are close to each other are returned for queries of domain names.
• Addresses that are close to the source of the query are returned.
• Load balancing of resources is required.

ActiveSelect DNS is used in situations where there are multiple systems, either in a single location or multiple locations, that can provide similar services. An example is a group of web servers at two locations where each provides the same pages. In this example, ActiveSelect DNS can be used to direct traffic to a web server that is up. The addresses of the servers that are down are not included in the answers to DNS queries and the addresses of the servers that are up can be ordered based on the source of the DNS query.

Following figure shows the topology diagram of ASDNS.

6.2   ActiveSelect Functions

ActiveSelect DNS has the following four functions:

• Monitoring is a mechanism for an ActiveSelect DNS server to receive information about entries in its database. The ActiveSelect DNS Monitor is independent on the DNS server. One or more monitors can be deployed almost anywhere in the network. The monitor uses an external script to determine if an address (or service at an address) is responding. Information collected from this monitoring activity is sent to the DNS server, where it is stored and used to filter and order responses to future queries. Once set up, the process is automated. Information in the DNS zone files is unchanged.
• Filtering is done at the DNS server using information sent by ActiveSelect DNS Monitors. Addresses for systems that are down are deleted from the responses for ActiveSelect DNS enabled names.
• Grouping is done at the DNS server after filtering. Addresses can be grouped based on, for example, location or system capacity. Each group can also limit the number of addresses that are included from that group.
• Ordering is the final step used by the DNS server and allows the server to structure the answers in a way that is specific to the source of the query, such as providing local addresses before more remote addresses. Ordering can also limit the number of groups whose addresses are included.

Filtering, grouping, and, ordering can be used separately or together to form rules for answering queries.

ActiveSelect DNS does not use zone transfers or incremental zone transfers to communicate monitoring state changes. Instead, all the servers (master and slave) for a zone are configured to receive monitoring information.

6.3   ActiveSelect DNS Components

This section describes the following ActiveSelect DNS components:

• ActiveSelect DNS Enabled DNS Server
• ActiveSelect DNS Monitor

6.3.1   ActiveSelect DNS Enabled DNS Server

The ActiveSelect DNS enabled DNS server provides the following functions:

• Receiving monitoring reports from ActiveSelect DNS Monitors. The last reported status on each address is stored and used when queries for ActiveSelect DNS enabled DNS names are received. In general, when ActiveSelect DNS is being used, both the master and slave servers for the ActiveSelect DNS enabled DNS names must receive monitoring reports.
• Responding to queries for ActiveSelect DNS enabled DNS names when the answer includes A or AAAA resource records by first filtering and ordering the addresses. See the following steps for the responding process:
  1. Obtain all the addresses for the DNSname.
  2. Delete the addresses that are not reported as up (based on the stored monitoring reports).
  3. Sort the remaining addresses based on the configured sites for that DNSname. For each site, the addresses are ordered in a BIND round-robin mechanism is applied to a fashion starting at a random point. This randomizes the order of the up addresses.
  4. Based on the site rules (which can depend on the query's source address), place the addresses from each site on the list of addresses to return. Enforce any limit placed on the site for the number of addresses from that site to include. Enforce the limit on the total number of sites (with at least one up address) to include.
  5. If all the addresses associated with the sites in a preferred list are reported as down, alternative actions occur. One of three optional keywords (site, none, or default) might be specified at the end of a preferred statement to specify what behavior is followed in this case. The default behavior is followed if the keyword is omitted.
     • When all addresses in sites listed in the preferred statement are down and if the keyword site is specified, ActiveSelect DNS returns all addresses in sites listed in the prefer statement.
     • When all addresses in sites listed in the preferred statement are down and if the keyword none is specified, ActiveSelect DNS returns no addresses.
     • When all addresses in sites listed in the preferred statement are down and if the keyword default is specified, ActiveSelect DNS returns all addresses associated with the name.

     This can be explained with the following example:

     resource "Melbourne_GGSN"
     {
     dnsname "ggsn1.mnc001.mcc001.gprs";
     key "a_dns_key";
     site "Melbourne" {10.1.0.1/24;};
     site "Stockholm" {10.2.0.1/24;};
      site "NewYork" {10.3.0.1/24;}; 
     //SGSNs in the 10.1.0.0 net are directed to Melbourne
     10.1.0.0/16 prefer "Melbourne" "NewYork" "Stockholm";
      //SGSNs in the 10.2.0.0 net are directed to NewYork
     10.2.0.0/16 prefer "NewYork" "Stockholm" "Melbourne";
     //SGSNs in the 10.3.0.0 net are directed to Stockholm
     10.3.0.0/16 prefer "Stockholm" "NewYork" "Melbourne";
     //Default to NewYork
     prefer "NewYork" "Stockholm" "Melbourne";
     }

     Return statement

     Syntax:

     return <integer>;

     Description:

     The return statement limits the number of IP addresses returned in a query. By default (no return statement) addresses that are available in all sites are returned for query on the domain name (unless a prefer statement is specified). If a return n is specified within a site statement, the number of addresses returned for that site is limited to n.

     Example:

     resource "Internet_apn
     dnsname " internet.mnc001.mcc001.gprs ";
     key "a_dns_key";signature "a_dns_key"; 
     site "Melbourne"
     {
     return 2; // return 2 IPs from this site
     10.1.0.1; 
     10.1.0.2;
     10.1.0.3;
      };
     site " NewYork "
      { 
     return 3; // return 3 IPs from this site
     10.2.0.1; 
     10.2.0.2; 
     10.2.0.3; 
     10.2.0.4;
      }; 
     site " Stockholm "
      { //By default all IPs from this site
     10.3.0.1; 
     10.3.0.2; 
     10.3.0.3;
     }; 
     };
     

• BIND round-robin is applied to any addresses returned to distribute the load. (This is not the case if Active Select is implemented).

Note:  

Repeated queries for a single ActiveSelect DNS enabled dnsname do not always return the exact list of addresses. Addresses that are reported up are returned and as restrictions can be placed on the number of addresses in a site that can be returned, even the addresses in the returned lists might change (not just the order) with each query.

ActiveSelect DNS also supports load balancing using load information reported by the systems, not just whether each system is up or down. In this case, the loading information is used to statistically order the list of returned addresses to place those addresses (and sites) that are least loaded first more often. This avoids redirecting all traffic to the least loaded system or site, which would quickly overload that one system or site.

When ActiveSelect DNS is being used, both the master and slave servers for the ActiveSelect DNS enabled DNS names should receive monitoring reports and should be configured for ActiveSelect DNS operation.

6.3.2   ActiveSelect DNS Monitor

The ActiveSelect DNS Monitor is responsible for:

• Monitoring various systems.
• Reporting system status to ActiveSelect DNS enabled DNS servers.

Each monitor:

• Probes a system periodically to determine whether it is responding and then reports that information, through a DNS message, to one or more ActiveSelect DNS enabled DNS servers.
• Can probe multiple systems and report the status of each monitored system to multiple servers.
• Can probe and report not just whether a system is up or down, but also loading information.

While an ActiveSelect DNS Monitor can monitor any system and report to all DNS servers, consider where to place these monitors and how many to use in monitoring a system. Particularly in cases such as:

• The monitor needs to communicate with the system being monitored. Typically this is done through ICMP Echo/Echo Reply messages. This means that the two systems need to be able to send packets to each other. It also means that the network connectivity between these systems affects the up or down reports — not just whether the monitored system itself is up or down.
• The monitor needs to report the status to the DNS servers. This typically means that the monitor must send reports to all the servers (primary and secondary) for a particular zone. And, as with the system being monitored, network connectivity between the monitor and DNS servers affect the ability of the monitor to report status (if a monitor report fails to reach a DNS server, the DNS server eventually assumes that the monitored systems are down). These reports are sent to the DNS server using the DNS protocol (UDP with default port 53) and therefore the network must be configured to allow this traffic between the monitors and servers.
• Multiple monitors can be used to monitor a system. And each of these monitors can report to a subset (or all) of the DNS servers. However, the impact of this on the monitored system must be considered since it receives and needs to respond to more monitor requests. Having multiple monitors reporting to a DNS server means that if one monitor (or the network connectivity between it and the DNS server) fails, the other monitor's reports suffice to provide an accurate view of the status of the monitored systems. But, this increases the processing overhead at the DNS server system.

The ActiveSelect DNS Monitor needs the following configuration information to operate:

• The DNS servers to which to send monitoring reports. This can be a primary DNS server or a secondary DNS server.
• The systems to monitor for each DNS server.
• The method and interval used to monitor each system.
• The TSIGKey needed to communicate with the DNS servers, if any.

Custom scripts (programs) can be written to perform complex monitoring of systems. These scripts return an indication of whether the monitored system is up or down and if up, can also report load information.

6.4   ActiveSelect Managed Objects

Table 6 outlines the ActiveSelect managed objects. For more information about the parameters of the objects, refer to the ActiveSelect DNS Objects section in IPWorks DNS, ASDNS, ENUM Parameter Description.

7   ENUM Management

This section provides concepts that are required for mapping ENUM. It mainly focuses on the managed objects used by the ENUM Server.

For more information on how to configure ENUM service and ENUM related functions, refer to the Section Configuring ENUM in Configure DNS and ENUM.

7.1   ENUM

ENUM is an application of the DNS protocol used for mapping telephone numbers to Uniform Resource Identifiers (URIs). Specifically, ENUM is an application of the Dynamic Delegation Discovery System (DDDS), which is built on DNS. IPWorks provides a single solution for DNS and ENUM services. It is required to provide many ENUM records with high ENUM transaction rates and low latency. To realize this, the ENUM Server stores and manages its data using MySQL database.

The ENUM Server supports applications, such as IMS Networks. IMS Networks have endpoints with direct IP connectivity to the network through a Session Border Controller (SBC). Endpoints typically use the SIP protocol but some use the H.323 protocol. Users are identified by URIs, but also require an E.164 alias to enable calls from the legacy networks. Users require multiple URIs to identify different endpoint terminals.

The ENUM Server provides standard E.164 number (NAPTRecord) query function, and also implements a view concept and an access control function based on the client IP address. Unlike the DNS server, the ENUM Server currently does not support full-split namespace and TSIG/DNSSEC functions.

Figure 2 shows the relationship between the ENUM Server and selected IPWorks components. After receiving ENUM and DNS requests from the clients, the ENUM Server handles ENUM-related requests itself and forwards all other requests to the DNS server. Responses from the DNS server are returned without change through the ENUM Server. MySQL database stores the ENUM Server configuration data. The Storage Server replicates the ENUM Server configuration data on the MySQL NDB Clusters. NDB is an in-memory clustered database from MySQL. Each MySQL NDB cluster is independent of the other clusters, that is, they can be managed, maintained, and enhanced separately.

7.2   ENUM Managed Objects

Table 7 provides short description of each ENUM managed object in IPWCLI. For more information about the parameters of the objects, refer to the corresponding sections in IPWorks DNS, ASDNS, ENUM Parameter Description.

8   AAA Management

This section describes the basic concepts to configure IPWorks AAA.

IPWorks AAA uses IPWCLI and ECLI to perform the configuration management.

For more information on:

• AAA Managed Objects in IPWCLI, refer to IPWorks AAA Parameter Description.
• AAA Managed Objects in ECLI, refer to the MOC IPWorksAAARoot in Managed Object Model (MOM).

8.1   Radius AAA

The IPWorks Radius AAA server provides authentication, authorization and accounting functions for the wired and wireless network access. Authentication verifies the identity of an entity; authorization determines whether a requesting entity is allowed to access a resource; and accounting collects information on resource usage for the purpose of trend analysis, auditing, billing or cost allocation.

3GPP-WLAN Network Architecture

Figure 3 shows the 3GPP-WLAN network architecture. IPWorks Radius AAA supports the Wa, Wm, and D'/Gr' interfaces.

For more information about the interfaces, refer to the following interface descriptions:

• IPWorks 3GPP AAA Server-WLAN Access Network Wa Interface
• IPWorks 3GPP AAA Server-PDG Wm Interface
• IPWorks 3GPP AAA Server-HLR D'/Gr' Interface

Fixed Access Network Architecture

Radius AAA supports user authentication, authorization, and accounting for fixed access network, as shown in Figure 4.

GPRS Network Architecture

Figure 5 shows the network of AAA for GPRS (Gi interface).

For more information about the interface, refer to the following interface description:

• IPWorks AAA Server-AAA Clients Gi Interface

Protocol Stack Overview

The relevant protocol stacks shall be configured to achieve IPWorks Radius AAA functions. Figure 6 shows an overview of the protocol stacks used by IPWorks Radius AAA:

IPWorks Radius AAA configuration is composed of the following parts:

• SS7 Stack configuration.

  Certain Radius AAA functions (such as, Wi-Fi AAA if the use case is 2G/3G USIM(SIM) based UE authentication with HLR) require SS7 Stack configuration.

  For information on how to configure SS7 Stack, refer to Configure SS7 for AAA.

• Radius AAA components, including the following configurations:
  • Radius Stack: The module is used to send/receive the radius message
  • Radius Backend: The module is used to perform authentication, authorization and accounting functions.
  • Radius CSV Engine: The module is used to generate the session based CSV file and provide FTP related function.

The following tools are used to configure Radius AAA:

• ECLI configuration

  The Radius AAA function are mainly configured by using ECLI, refer to Configure Radius AAA.

• IPWCLI configuration

  The AAA server and user provisioning are configured by using IPWCLI.

8.1.1   Radius AAA Allocation in Cluster

Figure 7 shows the typical allocation of Radius AAA in IPWorks 2+2 cluster.

• CSV Engine is integrated with Storage Server.
• CSV Engine is working in active/standby mode.
• Radius Backend and Radius Stack are working on Active/Active mode.
• Radius Stack supports load balancing and failover.

8.2   EPC AAA

IPWorks AAA server that is used as the 3GPP AAA server in EPC network is called IPWorks EPC AAA. IPWorks EPC AAA server supports the authentication and authorization of User Equipment (UE) which wants to access EPC through Non-3GPP IP Access Network. It also supports the network-based Mobility Management mechanism over s2a/s2b reference point.

Figure 8 shows the EPC network architecture. IPWorks EPC AAA server supports the STa, S6b, SWm, S13 and SWx interface specified in 3GPP TS 29.273.

For more information about the interfaces, refer to the following interface descriptions:

• IPWorks 3GPP AAA Server-Non-3GPP Access GW STa Interface
• IPWorks 3GPP AAA Server-HSS SWx Interface
• IPWorks 3GPP AAA Server-EIR S13 Interface
• IPWorks 3GPP AAA Server-PDN GW S6b Interface
• IPWorks 3GPP AAA Server-ePDG SWm and SWm+ Interface

IPWorks supports SES authentication involving D' and SWm' reference points, as shown in Figure 9.

For more information about the interfaces, refer to the following interface descriptions:

• IPWorks 3GPP AAA Server-HLR D' Interface
• IPWorks 3GPP AAA Server-SES SWm' Interface

The relevant protocol stacks shall be configured to achieve IPWorks EPC AAA functions. Figure 10 shows an overview of the protocol stacks used by IPWorks EPC AAA:

IPWorks EPC AAA configuration is composed of the following parts:

• Diameter Stack configuration

  Diameter stack configuration is mandatory and needed first for all EPC AAA services, refer to Diameter Stack Configuration Guide for details.

  For basic concepts about the Diameter Stack, see Section 8.2.1 Diameter Stack.

• SS7 Stack configuration

  Certain AAA functions (such as, Wi-Fi Mobility Management, SES Support, Diameter Over SCTP) require the SS7 stack configuration. For information on how to configure SS7 stack, refer to Configure SS7 for AAA according to different IPWorks deployment scenario.

• EPC AAA configuration, including the following:
  • ECLI configuration

    The AAA function (such as, PKI authentication, Wi-Fi Mobility Management, SES Support, IMEI check support) related configurations are mainly performed by using ECLI, refer to Configure EPC AAA.

  • IPWCLI configuration

    The AAA server and user provisioning are performed by using IPWCLI.

8.2.1   Diameter Stack

Diameter Stack is a component that is used by IPWorks AAA server as the protocol front end.

Figure 11 shows Diameter Stack 2+2 deployment in IPWorks Cluster. IPWorks Cluster, called as IPWorks Own Node, uses the same Diameter realm and Diameter host.

Other Diameter Nodes connected to IPWorks Cluster are called as Diameter Peer Nodes.

In IPWorks Cluster:

• Controller daemon of Diameter Stack in SC node manages the connectivity of user processes across the cluster.
• Payload daemon of Diameter Stack in PL node engages in Diameter signaling.
• IPWorks AAA process handles the business logic, for example, authentication.

For more details on how to configure diameter stack initially or update diameter Stack configuration in runtime, refer to Diameter Stack Configuration Guide.

9   DHCPv4 Management

This section describes the basic concepts to configure IPWorks DHCPv4 server.

IPWorks DHCPv4 uses IPWCLI and ECLI to perform the configuration management. For more information on:

• DHCPv4 Managed Objcts in IPWCLI, refer to IPWorks DHCP Parameter Description.
• DHCPv4 Managed Objects in ECLI, refer to the Managed Object Model (MOM).

9.1   DHCPv4 Overview

IPWorks DHCPv4 server contains the following functions:

• DHCPv4 service: Mainly used for IPv4 address allocation. It is the automatic configuration of IP networking parameters.
• NACF service: The Network Access Configuration Function (NACF) is the DHCPv4 Server that interacts with another network element called Connectivity Session Location Function (CLF). The purpose of this interface is to exchange the binding information pertaining to the exchange of the IP address allocated to the Customer Premises Equipment (CPE) and the network location information provided by the NACF.

For detailed configuration, refer to Configure DHCP.

9.2   DHCPv4 Service

The Dynamic Host Configuration Protocol (DHCP) is an extension of the Bootstrap Protocol (BOOTP) that handles dynamic IP address assignments for remote clients. It allows a remote client to plug into a network and broadcast a request, to one or more DHCP servers managing a particular subnet, for network configuration information. One or more DHCP servers reply to the remote client and one server ultimately negotiates a lease of terms including an IP address, a specified period of usage for the address, and other client configuration parameters.

IPWorks DHCP configuration is composed all or part of the following parts according to customer’s requirements:

• Creating DHCPv4 Server
• Creating DHCP Policy Objects
• Overlapping Lease Pools (Optional)
• DDNS (Optional)
• Failover (Optional)
• Load Balancing (Optional)
• Generating Client Host Names (Optional)
• Authentication of DHCP Clients (Optional)
• User-Defined Options (Optional)

9.3   NACF Service

The NACF is the DHCPv4 server that interacts with another network element called CLF. The purpose of this interface is to exchange the binding information pertaining to the exchange of the IP address allocated to the Customer Premises Equipment (CPE) and the network location information provided by the NACF. Each IP Addressing Zone contains multiple Topology Zones. CPEs across the Topology Zones are connected to NACF through routers. Each Topology Zone maintains its own router.

The following four routers are supported by NACF by default. This is due to how they form option82 and the way option82 is decoded and reformatted by NACF to form CLID and RemoteId:

• Alcatel
• Cisco
• Juniper
• Red Back

NACF and CLF communicate over a TCP connection where NACF acts as TCP client and CLF as the TCP server.

NACF configuration should be done after the DHCP service configuration and the following extra configurations were completed:

• Creating Option82 Objects
• CLF Interface Specifications
• P-CSCF Discovery
• User ID Provisioning

10   MySQL Database Management

IPWorks uses MySQL databases as repositories for storing network configuration data. The Storage Server uses a MySQL database to store static network data. MySQL database on the Storage Server is a centralized resource for managing the network.

This section introduces the basic information of MySQL database.

10.1   MySQL File Locations

All MySQL files are installed to the MySQL installation directory. A symbolic link, /usr/local/mysql, is created to point to the MySQL installation directory. This allows fixed pathnames to be used regardless of where MySQL has been installed.

The IPWorks Storage Server database is named as ipworks. The database is installed in the following directories on SC-1 and SC-2 as shown in Table 8.

(1)   User must not change the files in any of the above directories or their subdirectories. Otherwise, this might corrupt the databases.

10.2   MySQL Scripts

The MySQL distribution provides scripts for managing most of the common administrative operations on the MySQL server. However, IPWorks provides its own customized script ipworks.mysql in the /etc/init.d directory to manage MySQL processes.

To start/stop or show the status of the MySQL NDB cluster nodes, refer to Configure MySQL NDB Cluster.

10.3   MySQL Server

When the MySQL server software is installed, it creates one daemon, the MySQL server (mysqld), which is started automatically.

For more information on the operation of the MySQL server, refer to the MySQL Documentation. The MySQL manual is available in Info format in the /usr/local/mysql/docs/ directory on the machine where the server software is installed. User can also access it online in HTML and PDF formats, refer to MySQL Documentation.

10.4   MySQL NDB Cluster

MySQL NDB Cluster is a technology that enables clustering of in-memory databases in a shared-nothing system. It integrates the standard MySQL server with an in-memory clustered storage engine called NDB. The MySQL NDB Cluster allows high availability and also provides high performance, while allowing for near linear scalability.

A MySQL Cluster consists of a set of computers, each running a number of processes including MySQL servers, data nodes for NDB Cluster, management servers, and possibly specialized data access programs. All these programs work together to form a MySQL Cluster.

When data is stored in MySQL NDB Cluster, the tables are stored in the data nodes. Such tables are directly accessible from all other MySQL servers in the cluster. The data stored in the data nodes for the cluster can be mirrored, and the cluster can handle failure of individual data nodes with no other impact than that a few ended transactions because of losing the transaction state. Since transactional are expected to handle transaction failure, this is not a problem.

IPWorks stores the persistent data in MySQL NDB Cluster. The database tables in the cluster are created with engine type ndb. All data is provisioned by Storage Server on the SQL Node. SQL Node saves data to Data Node automatically.

The MySQL NDB Cluster is organized in units called "nodes". In MySQL NDB Cluster terminology, "nodes" correspond to processes rather than machines. There might be more than one node on the same machine. A cluster has three types of node, as follows:

MySQL NDB Cluster may have a minimum of three nodes (one Management Node, one Data Node, and one SQL Node) and a maximum of 63 nodes.

• Management Node

  The role of this type of node is to manage the other nodes within the cluster, such as providing configuration data, starting and stopping nodes, running backup. The location of the Management Node has no impact upon the ENUM Server.

• Data Node

  There can be multiple Data Nodes in a cluster. Data Nodes contain in-memory copies of the database. Data Nodes can contain replicas of all or part of the database. A large database can be segmented (or partitioned) over several Data Nodes if it does not fit into the RAM available on a single server. Replication and partitioning within a cluster are hidden from the clients of the database.

  The Data Node stores the ENUM tables using the in-memory NDB storage engine.

  The data stored in the Data Nodes for MySQL NDB Cluster can be mirrored. A cluster can handle failure of an individual Data Node with no impact other than the loss of a few transactions as a result of losing the transaction state. This is not a problem because transactional applications are expected to handle transaction failure.

• SQL Node

  This is the node that accesses the cluster data. It is a traditional MySQL server that uses the NDB storage engine.

  MySQL NDB cluster has two SQL Nodes with multiple instances. All cluster data is accessed by the NDB API or SQL Node. The ENUM Server accesses the ENUM-related data using the MySQL NDB API interface.

In IPWorks, there is also a type of node can be called NDB Node. This is similar to SQL Node, but with the SQL interface replaced by a lower-level interface named MySQL NDB API. Database clients can access the NDB Node directly by using the interface. The ENUM Server uses the MySQL NDB API to a locate NDB Node to gain access to the MySQL NDB Cluster.

Provisioning of the database is by the IPWorks application on the Storage Server. It uses SQL Nodes (one per cluster) to populate the in-memory database.

For more information about on MySQL Cluster, refer to MySQL 5.5 Reference Manual.

Figure 14 illustrates the architecture of the MySQL database that is composed of MySQL NDB Cluster.

For more information about how to manage the MySQL NDB Cluster nodes, refer to Configure MySQL NDB Cluster.

10.5   MySQL CLI

The MySQL distribution provides a user interface for performing tasks to administer and monitors the MySQL server. The MySQL tool is an SQL shell and supports interactive and non-interactive use. When used interactively, it presents query results in an ASCII-table format. When used non-interactively (for example, as a filter), it presents the results in tab-separated format.

The MySQL CLI program is located in the /usr/local/mysql/bin directory.

To start the MySQL CLI, refer to Configure MySQL NDB Cluster.

11   Service Life Cycle Management

Several types of Availability Management Framework (AMF) tools are available to help to manage AMF services or AMF components. The command ipw-ctr is recommended to control the life cycle of service application from high level for user view.

This tool wraps immadm and immlist to communicate with AMF.

The usage is as follows:

ipw-ctr[17963]: Usage: ipw-ctr <option> <component> [<hostname>]
Usage:===================================================================
Usage: ipw-ctr $1 $2 $3
Usage: $0 {ipw-ctr}
Usage: $1 {start | stop | restart | status}
Usage: $2 {ss | dns | dnssm | asdns | asdnssm | enum | fesync | aaasm | aaa_diameter |⇒
aaa_radius_stack | aaa_radius_backend | sqlnodemgr | [status] all...}
Usage: $3 {hostname}
Usage: eg: ipw-ctr start ss SC-1
Usage: eg: ipw-ctr stop dns PL-3
Usage: eg: ipw-ctr status enum PL-3
Usage: eg: ipw-ctr status all
Usage:===================================================================

(1)  To make sure that the ENUM FE Sync provides service, enable ENUM FE in ECLI first. Refer to Section Configuring ENUM Front End in Configure DNS and ENUM for details.

12   Transaction Logging

The IPWorks DNS and ActiveSelect DNS Monitor provide transaction logging. The purpose of transaction logging is to provide a historical (long-term) log of all major activity for these IPWorks components.

Transaction logging is not detailed operational logging and is not likely useful for diagnosing problems. Rather, components standard log file is used for diagnosing problems. It exists to provide an administrator a means to determine what has happened to network in the past. For example, if an administrator needs to determine who was using an IP address at a given time or who deleted a DNS resource record, they can do this by viewing the transaction log.

For more information about the Transaction Logging, refer to DnsTransLog and AsdnsMonTransLog.

12.1   Transaction Logging Periodic Maintenance Operations

As only a limited number of transaction log files are retained, it is necessary to back up the files for a long-term historical archiving. The files must be backed up before they are automatically deleted.

As the files are automatically deleted, it does not need to delete them manually. However, they can be manually deleted if disk space should become an issue or there is a desire to delete the files once backed up.

Note:  

If these files are deleted, the highest numbered files must be deleted before deleting lower numbered files (for example, first delete the file ipworks_service_trans.log.<max-1>).

12.2   Transaction Logging Message Format

The format of each record written to the transaction log is as follows:

date-time|service|event|event-data

where:

12.3   Transaction Logging Events

This section describes the general or service-specific events written to the transaction log.

12.3.1   Standard Events

The following events are reported by all servers unless not appropriate to the service:

• Startup: This indicates when the server started. Event-data provides the version of the server.
• Stop: This indicates when the server stopped. Event-data reports the reason for the stop (such as operator requested or invalid configuration).
• Reload: This indicates when a reload was requested. Event-data usually indicates what was reloaded and who or what requested the reload.
• Newfile: This indicates when a new transaction log file was created and should be the last record in the old file (event-data reports the reason the file was closed) and first record in the new file. A transaction log starts with either a Startup or Newfile message.
• Stats: This periodically (every 15 minutes) reports operating statistics on the service. This information is used to enforce capacity-based licenses. The event-data reports the statistics used to calculate the transactions per second and transaction type mix for the service. The pt=value statistic is special and is the number of seconds that have elapsed for the reported statistics.

12.3.2   ActiveSelect DNS Monitor Events

• Node down: This indicates that a resource is down. The event-data identifies the resource that is down.
• Node up: This indicates that a resource is up. The event-data identifies the address of resource that is up.
• Stats: The ActiveSelect DNS Monitor logs the following statistics:
  • p1 = Number of times resources were probed.
  • p2 = Number of ASDNS notifications transmitted to DNS servers.

The ActiveSelect DNS Monitor only reports status changes.

An excerpt from an ActiveSelect DNS monitor's transaction log file is as follows:

2008/12/11 21:58:40|ASDNSMON|startup|IPWorks ASDNS Monitor
2008/12/11 22:00:00|ASDNSMON|stats|pt=80|p1=64|p2=4
2008/12/11 22:01:56|ASDNSMON|NODE UP|10.5.1.1
2008/12/11 22:01:56|ASDNSMON|NODE UP|10.5.1.2
2008/12/11 22:01:56|ASDNSMON|NODE UP|10.5.1.3
2008/12/11 22:01:56|ASDNSMON|NODE UP|10.5.10.1
2008/12/11 22:02:11|ASDNSMON|stop|Stopping Transaction log

12.3.3   DNS Events

• AddRR: This indicates that a resource record was added through a dynamic update. The event-data identifies the zone, added Resource Record (at least the domain name and RR type) and the source of the request (IP address). Format for event-data is source-ip, domain name, RR type, and Rdata.
• DeletedRR: This indicates that a resource record was deleted through a dynamic update from a zone. The event-data identifies the zone, deleted Resource Record, and the source of the request (IP address). Format for event-data is source-ip, domain name, RR type, and Rdata
• Zxfr: This indicates that a zone transfer was done. The event-data identifies the direction (received or send), partner of the transfer (IP address) and status. Format for event-data is direction, zone, peer (master) address, and status.
• Stats: The DNS server logs the following statistics:
  • p1 denotes Number of Interactive queries processed.
  • p2 denotes Number of Recursive queries processed.
  • p3 denotes Number of DDNS updates processed.
  • p4 denotes Number of dropped requests (number of requests received which had little or no processing, because of security violations).
  • p5 denotes Incremental zone transfers initiated (number the server started to other servers).
  • p6 denotes Incremental zone transfers honored (number the server received from other servers).
  • p7 denotes Full zone transfers initiated (see p5 and p6).
  • p8 denotes Full zone transfers honored.
  • p9 denotes Notifies sent.
  • p10 denotes Notifies received.
  • p11 denotes ActiveSelect DNS notification received (status/load updates).

  Note:  

  Counters are mutually exclusive.

  
  

An example from a DNS servers transaction log file is as follows:

2008/12/15 12:30:33|DNS|startup|IPWorks DNS Server BIND 9.9.7
2008/12/15 12:30:49|DNS|reload|user requested reload
...
2008/12/22 14:33:52|DNS|AddRR|iptelco.com host992.
iptelco.com. 84600 IN A 11.5.4.68
2008/12/22 14:33:52|DNS|AddRR|iptelco.com host993.
iptelco.com. 84600 IN A 11.5.4.69
2008/12/22 14:33:52|DNS|AddRR|iptelco.com host994.
iptelco.com. 84600 IN A 11.5.4.70
2008/12/22 14:33:52|DNS|AddRR|5.11.in-addr.arpa 68.4.5.11.
inaddr.arpa. 84600 IN PTR host992.iptelco.com.
2008/12/22 14:33:52|DNS|AddRR|5.11.in-addr.arpa 69.4.5.11.
inaddr.arpa. 84600 IN PTR host993.iptelco.com.
2008/12/22 14:33:52|DNS|AddRR|5.11.in-addr.arpa 70.4.5.11.
inaddr.arpa. 84600 IN PTR host994.iptelco.com
...
2008/12/22
14:45:00|DNS|stats|pt=900|p1=0|p2=0|p3=102|p4=0|p5=0|p6=0|
p7=0|p8=0|p9=0|p10=0|p11=0
2008/12/15 12:46:06|DNS|stop|Stopping Transaction log|user
requested shutdown

13   Server Manager Configuration Properties

The Server Manager (SM) is the IPWorks component that resides on the same PL and links it to the rest of the IPWorks management system. It has the following functions:

• Update the PL with the latest configuration data for DNS server.
• Retrieve dynamic resource records from the PL for DNS server.
• Retrieve dynamic AAA sessions from PL for AAA server.
• Update the PL with the latest configuration data for DHCPv4 server.
• Retrieve dynamic leases status from the PL for DHCPv4 server.

13.1   Log Files for Server Manager

In DNS, AAA, and DHCPv4 services, SM is working as an interface between SC and PL, the Server Manager's debug logging is helpful in debugging problems with the PL and SC as well as with the Server Manager itself. The Server Manager can be configured to use debug logging through the ECLI interface. By default, the name of the Server Manager's log file is <server_name>sm.log, where <server_name> is the type of service, such as DNS, AAA, or DHCP.

The directory of the SM log files is designated by the parameter directory of the correlative SM Log MOM. For example, the DnsSMLog class for DNS SM logs in IPWorks MOM. These MOMs can be accessed through ECLI interface. The default directory of the SM log files is /cluster/storage/no-backup/ipworks/logs.

Note:  

Currently SM log directory cannot be changed.

13.2   Configuration Files

There are two configuration files that control the behavior of the Server Manager. The file /opt/ipworks/sm/confs/ipworks_sm_defaults.conf , which is located on the Payload, contains the default values for properties used for all the Server Managers. This file is changed rarely. The file /etc/ipworks/ipworks_*sm.conf contains the Server Manager properties that are used most often. The * in the filename is the type of server, such as DNS. Properties in this file override those in the ipworks_sm_defaults.conf file. Configuration changes made via ECLI are written to this file.

Some of the Server Manager configuration properties are discussed in the following sections. For a complete list of the properties, see the description of each individual property in the configuration files cited above.

13.3   Server Manager Instances

There is one instance of the Server Manager running for each type of server being managed on a given machine. Each instance is a separate process running in a Java Virtual Machine. When the Server Manager process is created, the command line contains the parameter App=ipw*sm, where * represents the type of server, such as DNS. This allows the processes for the Server Managers in a ps command [output] to be differentiated.

For any given type of server, there should only be one instance of the Server Manager running. When the Server Manager starts, it creates a file /var/run/*sm.port. This file serves the following purpose:

• Serves as a sentry file that prevents another Server Manager for the same type of server from being started. If the Server Manager is stopped in an abnormal manner (for example kill -9), this file will not be deleted when the Java Virtual Machine exits.

The port that the Server Manager listens on is chosen by OS as an available port. To make the Server Manager listen on a particular port, set the Sm.ListenPort property in the /etc/ipworks/ipworks_*sm.conf file. The loopback address can also be changed from the default value with the ServerAddress property.

13.4   Startup of Server Manager

When the Server Manager starts up, it connects to the Storage Server, logs in, registers as a remote agent for the server, and reports the status of the server to the Storage Server. It might also create a Storage Server object for the server.

For more information on the problems that can occur in this chain of events, refer to:

• IPWorks Troubleshooting Guideline
• Command Line Interface User Guide for IPWorks SS

After the Server Manager has logged in, it searches for a server object in the Storage Server that has the same IP address as the machine on which it is running. It uses the IP address from the local side of the TCP connection that it has made to the Storage Server. If it has the connection using an IPv4 or IPv6 address for the Storage Server, the address for the server is an IPv4 or IPv6 address correspondingly. For a multihomed host, the Server Manager can be configured to use a particular IP address with the Sm.LocalAddress property in the ipworks_*sm.conf file.

If the Server Manager does not find a server object in the Storage Server with the address of the machine, it does not create a server object by default. This behavior is defined by the parameter Sm.CreateServer in file /etc/ipworks/ipworks_*sm.conf. The default value of Sm.CreateServer is false that indicates that Server Manager cannot automatically create a server object. Therefore, set the parameter Sm.CreateServer as true to allow Server Manager to create a server object.

When creating the server object, the Server Manager uses the hostname configured for the machine on which it is running for the name field of the object. This is the name that is returned by the hostname command. The Server Manager sets the address field of the server object to be a list of all the IP addresses on the machine, unless it is configured to use a particular address with the Sm.LocalAddress property. The Server Manager sets the dnsname field of the server object to be a list of all the DNS names of the machine. The DNS domainname parameter must be properly configured in the /etc/resolv.conf file for this to work.

Note:  

In the Linux system, DNS server is configured through the /etc/resolv.conf file. However, in IPWorks the resolv.conf file is generated from the configuration entries in the /cluster/etc/cluster.conf file. For details, refer to LDE Management Guide.

13.5   Communication with DNS Server

The Server Manager communicates with the DNS server using the standard DNS and BIND interfaces. DNS queries and dynamic updates are sent to the DNS server, which must be listening for DNS traffic on the loopback address. The loopback address and port can be changed from the default values using the Sm.DnsLoopbackAddress and Sm.DnsLoopbackPort properties in the /etc/ipworks/ipworks_dnssm.conf file. The Server Manager manages the dynamic zones in the DNS server for the IPWorks user. When IPWorks CLI queries for resource records in a dynamic zone or adds/deletes a resource record in a dynamic zone, the Server Manager forms a DNS packet and sends it to the DNS server on the loopback interface. TSIGKeys are used to select the proper view in the DNS server. These TSIGKeys are automatically generated by the Storage Server and used in creating the proper ACLs in the named.conf file. The Server Manager's TSIGKey must appear in an allow-query, allow-update, and allow-transfer statement for every dynamic zone as well as the match-clients statement for the view.

The Server Manager uses the BIND RNDC facility to send control commands, such as stop, reload, stats, to the DNS server. This utility is shipped with IPWorks and is installed with a link from /usr/bin. The RNDC client can be run from the command line independent of the Server Manager. Typing rndc from a terminal window gives a list of the commands that can be sent to the DNS server. RNDC requires the use of a TSIGKey. This TSIGKey is created when the DNS server is installed. It resides at /etc/rndc.key and should not be deleted or modified. ERH does not have a Server Manager.

13.6   Communication with ActiveSelect DNS Monitor

The Server Manager does not directly communicate with the ASDNS Monitor. The ASDNS Monitor does not store dynamic network data like resource records (DNS server). The Server Manager starts, stops, updates the configuration and reports status of the ASDNS Monitor using the UNIX command line and watches the pid of the Monitor's process.

13.7   Communication with AAA Server

The Server Manager communicates with the AAA server over a TCP connection, using a proprietary protocol. The protocol supports querying the server for sessions (dynamic AAA session data). The AAA server listens on the default loopback interface. When the Server Manager starts, it attempts to connect to the AAA server. If the Server Manager cannot connect, it assumes that the status of the server is down. Next time the Server Manager needs to communicate with the AAA server, it will again attempt to connect.

13.8   Communication with DHCPv4 Server

The Server Manager communicates with the DHCPv4 servers over a TCP connection, using a proprietary protocol. The protocol covers sending control commands to the DHCPv4 server and querying the server for leases (dynamic DHCP data). The DHCPv4 servers listen on the loopback interface, and the port is 17071.

When the Server Manager starts, it attempts to connect to the DHCPv4 server. If connection fails, it assumes that the status of the DHCPv4 server is down. Next time the Server Manager needs to communicate with the DHCPv4 server, it will again attempt to connect.

13.9   Server Status

When the Server Manager attempts to contact the server (DNS, ASDNS, AAA, or DHCP) and fails, it assumes that the status of the server is down. In addition, a server might have any number of other status strings that it returns when it is queried for its state. The status can be down or running.

The servers do not automatically inform the Server Manager of a change in status. When the Server Manager starts, it checks the status of the server. For example, if the Server Manager has already established a connection to the DHCPv4 server, when the connection is broken, the Server Manager assumes that the status of the server is down.

For some applications, it is desired to have a relatively current status of a server stored in the Storage Server. The Server Manager can be configured to poll the server for its status. The rate at which the Server Manager polls can be set with the Sm.MonitorInterval property. Set this property to the number of seconds between queries for the servers status.

• For the DNS server, the Server Manager uses the BIND RNDC command line utility to get the status.
• For the ASDNS Monitor, the Server Manager checks the pid of the monitor's process.
• For the AAA server, the Server Manager checks the pid of the process.
• For the DHCPv4 server, the Server Manager sends a request on a TCP connection to get the status.

In all cases mentioned previously, there is no network traffic generated by the Server Manager's query for status. If the status has not changed, the Server Manager does not send the results to the Storage Server. Only if the status of the server has changed, the Server Manager generates network traffic by polling the server for status.

Configuring the Server Manager to poll for status every 30 seconds gives a relatively up-to-date status for the server in the Storage Server. The impact of this configuration on the server's performance is not significant.

13.10   Query Limits

The IPWorks product is designed for high performance of servers. When there are no IPWorks users interacting with a server, the server performance is same as an unmanaged server. That is, the server does not send any information such as newly generated dynamic network data or server status to the Server Manager. However, the IPWorks user can interact with a server to affect the servers' performance potentially. This would most likely happen when a query is made to a DNS or DHCPv4 server for a large number of dynamic resource records.

The queries made by the Server Manager for dynamic data can be limited in a number of ways. The IPWorks administrator can limit the time required for performing the query. This is configured with the Sm.QueryTimeLimit property, which is used for the DNS and DHCPv4 servers. This property limits the time in seconds taken to construct the response to the query. If this time is exceeded, no results are returned to the user. Instead the user receives a message giving the time limit that has been exceeded.

The IPWorks administrator can limit the number of objects (resource records or leases) in a query response. For the DNS server, this is configured with the Sm.DnsAxfrCountLimit property. Large DNS queries cause the Server Manager to perform a zone transfer from the DNS server. When the number of resource records in the transfer exceeds this number, the AXFR is terminated and a limit-exceeded message is returned. No resource records are returned. For a DHCPv4 Server, the limit on the number of leases for a response is configured with the attribute maxLeaseQuery of MO DHCPServerManager. This attribute is sent to the DHCPv4 server when the Server Manager connects to it. The DHCPv4 server enforces the limit and returns no leases if the limit is exceeded. A message about exceeded lease limit will also be received.

There is a separate property Sm.DnsAllowAxfr that the IPWorks administrator can use to disallow zone transfers by the Server Manager. This prevents all zone transfers without regard to the size of the returned data or the time for the zone transfer.

IPWorks CLI provides queries for data, especially dynamic data, with filters that minimize the amount of data that is retrieved. Queries for resource records must specify the dnsname of the record wherever possible.

For example the CLI command:

IPWorks> list arecord -source iptelco.com -where
address=10.0.0.1

Note:  

-source must be used only for arecords of zones that are dynamic.

This requires that the Server Manager performs a zone transfer for the iptelco.com zone.

The IPWorks CLI command:

IPWorks> list arecord -source iptelco.com -where dnsname=fred.iptelco.com

This requires only the Server Manager perform a simple owner query. For a large amount of data in the iptelco.com zone, the latter query has a much smaller effect on the performance of the DNS server.

14   Configuration Management

This section lists the operating instructions (OPI) CPIs that the user must follow:

User Account Configuration Management

• Configure User Account

DNS, ASDNS, and ENUM Configuration Management

• Configure DNS and ENUM

AAA Configuration Management

• Configure Radius AAA
• Configure EPC AAA

DHCP Configuration Management

• Configure DHCP

MySQL NDB Cluster Configuration Management

• Configure MySQL NDB Cluster

15   Appendix

15.1   DNS Options

Reference List