4 Setting Up Domain Information

This chapter explains the tasks you need to do immediately after installation of Oracle Communications IP Service Activator in order to set up domains.

The chapter describes how to:

• Create domains and set up proxy agent assignment for the devices within the domain

• Load files containing basic configuration data

• Open domains

Setting Up Domains

Oracle Communications IP Service Activator uses a concept of domains to define the logical networks to be managed. You can create multiple domains to represent managed networks: one domain for each AS region to be managed. No domains exist when you first install IP Service Activator, so the first step is to create one or more domains.

To create a new domain:

1. Select New Domain from the File menu. The Domain dialog box opens.

2. Enter an identifying name for the domain.

3. Specify the type of domain:

   • Public if the network only uses public IP addresses.

   • Private if you plan to manage independent networks with overlapping address space.

   • MPLS VPN if you are going to set up MPLS-based virtual private networks.

4. For MPLS VPN domains, specify whether interfaces on Provider Edge routers that connect to the Customer Edge routers use public or private addresses.

   By default, they are assumed to use unique, public IP addresses. If they use private IP addresses, clear the Public PE to CE Addresses check box.

   For further configuration, see the cartridge or driver guide that applies to your configuration.

5. In the Manual Config field, specify the default action within this domain for detecting manual configuration. The Manual Config field setting does not apply to the Network Processor. The system only checks to see if changes have been made to the commands that may be configured by IP Service Activator, as these may affect the operation of the system:

   • Delete: If manual configuration is detected, the device drivers will issue commands to reconfigure the device. No warning is output regarding the detected manual configuration.

     Caution:

     Oracle strongly recommends that you use only the Delete setting.

   • Warn and delete: If manual configuration is detected, a warning message (Message 3203) is output and the device drivers will issue commands to reconfigure the device.

   • Fail and don't delete: If manual configuration is detected, a critical fault (Message 3494) is raised. The device status is set to Intervention Required but is not reconfigured.

   Note:

   The domain-level manual configuration settings can be overridden for specific devices (see "Setting Manual Configuration Detection").IP Service Activator never deletes manually pre-configured VRF tables even if you select the Delete or Warn and delete options.

6. If you want to own the domain and set permissions on it for yourself, members of your user group and other users, select the Ownership property page.

   Note:

   If you are setting up VPNs you also need to set parameters on the VPN BGP, VPN MPLS and ASN property pages. For full details of how to set up VPNs, see IP Service Activator VPN User's Guide.

Manual Configuration with Manual Config Field set to Delete

On the Domain properties page of the Domain dialog box, the Manual Config menu lets you select how IP Service Activator deals with manually applied configuration statements that it encounters on the devices. The Manual Config field does not apply any configurations to the Network Processor. See "Setting Up Domains"for more information.

Caution:

Oracle recommends that you use only the Delete option.

Device Driver Handling of Manually Configured Objects when Delete Selected

This section discusses how IP Service Activator deals with manually applied configuration statements on devices that are managed by a Device Driver. See "Network Processor Handling of Manually Configured Objects when Delete Selected" for information about how this process relates to network processor or cartridge managed devices.

If the name of a manually configured object on a managed device exactly matches a name that already exists in the IP Service Activator object model, IP Service Activator assumes control of the configuration of that object. The parameters stored in the object model are used to configure the object on the device so that it aligns with the object model. This overwrites the manually applied configuration of that object if it differs from the object model.

If the name of a manually configured object exactly fits the default naming convention used by IP Service Activator for such objects, IP Service Activator assumes that the object was deleted from the object model but erroneously left on the device. IP Service Activator then deletes the manually configured object from the device, so that the device configuration matches the object model.

If a manually configured object's name does not match any name in the object model, and does not fit the default naming convention used by IP Service Activator, the object is left on the device and its configuration is not altered.

Network Processor Handling of Manually Configured Objects when Delete Selected

This section discusses how IP Service Activator deals with manually applied configuration statements on devices that are managed through cartridges and the Network Processor.

IP Service Activator does not maintain an internal model of the state of devices managed through the Network Processor. Configuration for particular objects are applied to the device and if there is a manually configured object already on the device with the same name, it is overwritten, or potentially augmented, depending on the type of object and the particular configuration statements involved.

If the name of a manually configured object on the device does not match any of the names in the IP Service Activator Configuration, the object is left on the device and its configuration is not altered.

Setting the Default Loopback ID Value for Discovery

On the Domain dialog box, VPN BGP property page, you can specify a value for the Loopback ID field. The Loopback ID value is used to create a loopback interface name by appending it to the name 'loopback'. For example, if the Loopback ID is 0, the loopback interface name created is 'loopback0'. When a device in this domain is discovered, a check is made to see if a loopback interface matching this text string exists. If it does, the IP address of the loopback interface is stored with the device information. The Loopback ID value can be overridden on a per-device basis (on the Device dialog box) and on a per-discovery basis (on the Topology dialog box).

Setting Up Proxy Agent Assignment

All devices in the domain that are to be managed by IP Service Activator must be assigned to a proxy agent. It is the proxy agent that controls when and what type of configuration is to be applied to a specific interface.

Although it is possible to assign devices to proxy agents manually, it is generally performed automatically during device discovery.

Assigning a Proxy Agent to a Domain

If you have a distributed installation with multiple proxy agents and you are creating multiple domains, you can assign specific proxy agents to each domain.

A device can only be assigned to a proxy agent that is either global or has been assigned to the domain that the device is in.

To assign a proxy agent to a domain:

1. Select a domain from the global setup window and select Properties from the context menu.

2. Select the Proxy Agent property page. The list shows all the proxy agents currently installed.

3. Select one or more proxy agents to be used within the domain by clicking the check box associated with the proxy agent.

Repeat these steps to assign specific proxy agents to specific domains.

Note:

If you do not explicitly define proxy agents for each domain, all proxy agents remain global and devices within any domain can be assigned to them.

Setting Up Proxy Agents for Automatic Assignment

Devices can be assigned to a proxy agent automatically whenever devices are discovered or rediscovered. You can configure IP Service Activator either to assign all devices to one proxy agent or to assign the devices equally to a number of proxy agents.

Devices are assigned only to proxy agents that are:

• Specifically assigned to the domain that the device is in, or are global (that is, not assigned to any domain) and

• Defined as active for auto-assignment

To check that a proxy agent is active, display the proxy agent properties by selecting the relevant proxy agent on the System tab in the System Hosts folder and choosing Properties from the context menu. Ensure the Auto device assignment is set to On (this is the default setting).

To configure automatic proxy agent assignment within a domain:

1. From the Tools menu, select Options.

   The Options dialog box opens.

2. Under Auto proxy assignment, select either First or Load balance:

   • First assigns each new device discovered to the first active proxy agent. This is the default setting.

   • Load balance allocates devices to multiple proxy agents with an equal allocation to all active proxy agents in order to balance the processing load between them.

   • If Off is selected, devices are not assigned to proxy agents automatically. Before they can be managed you will need to link them manually.

Only supported devices, that is, those that are included in the DeviceTypes.cfg file in the Config directory, can be automatically assigned.

Working in multi-proxy environments

When running in a multi-proxy environment:

• If you discover a device and fetch capabilities under a Domain which has both a Network Processor and a Proxy Agent proxy active, you will not be able to tell which fetched the capabilities. In this case, assign the device to the desired proxy, and then reset and re-fetch the capabilities.

Loading Policy Configuration Data

The next step is to install one or more set-up files that create standard policy configuration data in the IP Service Activator database – basic policy components and, if required, sample rules and PHB groups.

Note:

Oracle recommends loading the default configuration policy data. If you do not load the data, you have to create all the basic component data manually. Loading configuration policy data is mandatory if you want to use configuration policy.

The following configuration files are supplied in the SamplePolicy directory:

• default.policy creates some basic policy data, including:

  • Packet markings representing IP Precedence values 0-7

  • Gold, Silver and Bronze classes of service

  • Packet marking based traffic types representing the Gold, Silver and Bronze classes of service and port-based traffic types representing the most common TCP and UDP port numbers

  • Classifications based on the traffic types

• advanced.policy creates additional policy data:

  • Packet markings based on the full range of DiffServ codepoints and MPLS experimental bits

  • Packet marking based traffic types representing DiffServ codepoints and MPLS experimental bits

  • Port-based traffic types representing the most common IP protocols

  • Classifications based on the packet marking traffic types

  This data is useful if your routers support the full range of DiffServ codepoints and/or MPLS experimental bits.

• Rule_and_PHB.policy includes some example policy rules and standard PHB groups. If you wish, you can base your own rules and PHB groups on these examples.

The files must be loaded in the order in which they are listed above. The following files may also be loaded:

• ConfigletPolicyTypes.policy loads the configlets, which are needed by CTM.

• ConfigurationManagementPolicyTypes.policy loads other config policies needed by Configuration Manager.

• ExtensionPackAPolicyTypes.policy contains standard definitions for:

  • Extension Pack A Configuration Policy Types

  • ATM PVC Vc Class

  • Save Running Config

  • Static NAT

• ExtensionPackBPolicyTypes.policy contains standard definitions for:

  • Extension Pack B Configuration Policy Types

  • VRF Custom Naming

  • VRF Export Route Filter

• ExtensionPackCPolicyTypes.policy contains standard definitions for:

  • Extension Pack C Configuration Policy Types

  • ATM Vc Class

  • BGP CE

  • Extended ACL

• GeneralPolicyTypes.policy contains standard definitions for:

  • General Configuration Policy Types

  • Banners

  • IP Pools

  • Key Chain

  • Prefix List

  • SNMP Community

  • SNMP Host

  • Static Route

  • User Authentication

  • User Data

  • Traffic Statistics

• InterfaceManagementPolicyTypes.policy contains standard definitions for:

  • Interface Creation Configuration Policy Types

  • Interface Decoration Configuration Policy Types

  • Subinterface Creation Configuration Policy Types

  • Channelized Interface Creation Configuration Policy Types

  • Other Interface Management Configuration Policy Types

• IPMulticastPolicyTypes.policy contains standard definitions for:

  • IP Multicast Configuration Policy Types

  • Mulitcast Interface types can be installed by loading the

  • MulticastInterfacePolicyTypes.policy file

• IPSecPolicyTypes.policy contains standard definitions for:

  • IPSec Configuration Policy Types

  • Customer IPSec

  • Public IPSec

  • IPSec

• JuniperJUNOSQoSPolicyTypes.policy contains standard definitions for:

  • Juniper JUNOS QoS Configuration Policy Types

  • Juniper JUNOS COS Attachment

• juniper.policy defines MPLS packet markings, classes of service and an example PHB group for configuring WRR on Juniper M-series devices. For more information, see the IP Service Activator Juniper M-series Driver Support Guide.

• LSPPolicyTypes.policy contains standard definitions for:

  • LSP Configuration Policy Types

  • LSP Tunnel

• MulticastInterfacePolicyTypes.policy contains standard definitions for Multicast Interface Configuration Policy Types to be used with VPN and IP Multicast Policy Type services.

• Role_Assignment_Rules.policy defines a set of role assignment rules that allocate system-defined roles to devices and interfaces. Do not use role assignment rules - assign roles manually.

• RoutePolicyPolicyTypes.policy contains standard definitions for:

  • Route Policy Configuration Policy Types

  • BGP Route Policy

  • VRF Route Policy

• ServiceAssurancePolicyTypes.policy contains standard definitions for:

  • Service Assurance Configuration Policy Types

  • Collector Parameters

  • Netflow Parameters

  • RTR Responder

• VLANPolicyTypes.policy contains standard definitions for:

  • VLAN Configuration Policy Types

  • MGMT VLAN Interface

  • VLAN Interface

  • VLAN Definition

• VPNMulticastPolicyTypes.policy contains standard definitions for:

  • VPN Multicast Configuration Policy Types

  • Mulitcast Interface types can be installed by loading the

  • MulticastInterfacePolicyTypes.policy file

The SharedPolicyData.policy file is loaded automatically at system start-up. It defines a set of commonly-used IP protocols which are available in any domain you create. You only need to load this file if the IP protocols are deleted or edited incorrectly.

All of the above files are domain-specific – that is, they must be loaded into each domain in which you wish to use their information.

To load a policy configuration file:

1. Select a domain from the global setup window and select Properties from the context menu.

2. On the Domain dialog box, select the Setup property page.

3. Click Browse to view the available configuration files in the SamplePolicy folder.

4. Select the file to load and click Open. A brief explanation of the file appears in the File Information box.

5. Click Load to load the selected file and create the data. Note that files must be loaded in the following order:

   1. default.policy

   2. advanced.policy

   3. Rule_and_PHB.policy

Note:

It is important to load the files in order. Always load default.policy first, and do not load Rule_and_PHB.policy if you have already created PHB groups.

Opening the Domain

To open the domain on which you are going to work, double-click on the relevant domain on the Domains tab, or select the domain and select Open from the context menu.

A new domain management window opens.