Basic Planning

Learn about the best practices to get started with managing infrastructure for Oracle Communications Unified Assurance.

Define Business Requirements

To ensure Unified Assurance provides the value for which it has been purchased, it is extremely important to define the business goals extensively and communicate and measure against them throughout the duration of the implementation. Examples of business goals are:

Operations

Operations, in the context of Unified Assurance, are the usage or interaction of the various user communities with the Unified Assurance software solution. This may include executives, engineers, end-users, and NOC operators.

User Authentication

Unified Assurance supports the following types of user authentication:

You can configure multiple instances of each of the external authentication types, and external users map to internal Unified Assurance users. Transient users (users authenticated externally that do not have corresponding internal Unified Assurance users) are also supported.

See the following in Unified Assurance Security Guide for more information:

Multitenancy

Unified Assurance supports the capability to provide multiple securely segmented read-only access groups used for multitenancy. This is usually for client-side portaling or segmented departments within a single organization. You define these configurations by using Unified Assurance user groups, device groups, dashboard groups, diagram groups, and event filter groups. You must define multitenancy configurations before implementation to prevent rework.

For more information, see:

Defined Roles

To leverage any secure application, you must define roles and assign privileges to them. Unified Assurance includes five default roles:

Determine if you need any additional roles at the earliest stage of implementation.

User Group Creation

Like roles, you must determine user groups before implementation. User groups use roles to control access into Unified Assurance, and have associated groups of users.

Process Management

Oracle recommends that you list and create use cases for all major processes (defined or yet undefined) if interaction with the Unified Assurance software solution is required or wanted. This ensures that any process interaction will be successful and accomplished with ease.

Unified Assurance Architecture

Unified Assurance architecture consists of a typical three-tier implementation, where the presentation layer leverages an Apache web server, the data layer consists of MySQL, OpenSearch, Influx, and Neo4j database instances, and the application layer runs Unified Assurance compiled binaries.

Components Required

Before determining your architecture, you must first determine all the Unified Assurance components you will need to achieve the features and functionality you require. This list is vital in the planning and design phases and any architecture created without this component list completely identified may run into scaling issues.

Security Requirements

Determine if you require a FIPS 140-2 compliant environment. Unified Assurance installed on Oracle Linux 8 supports FIPS 140-2 compliance.

See FIPS Compliance in Unified Assurance in Unified Assurance Security Guide and FIPS 140-2 Compliance in Oracle Linux 8 in Oracle Linux 8 Enhancing System Security for more information.

System Requirements

Oracle recommends the following:

Hardware Requirements

Estimates are broken out into the following categories, with baseline hardware recommendations for Unified Assurance:

All Historical database storage estimates are based on default configuration and retention policies. Storage requirements depend on data retention policies, the number of raw events received, and the number of metrics collected. Contact your sales representative for a personalized estimate.

Minimum Installations

Minimum installations are less than 1000 devices.

Supported implementations:

Requires:

Medium Installations

Medium installations are between 1,000 and 25,000 devices.

Supported implementations:

Requires:

Large Installations

Large installations are greater than 25,000 devices.

Supported implementations:

Requires:

Software Map

To determine the software map, apply the components list to the hardware list. Although you can install components on any server, Oracle recommends the following best practices:

Redundancy, Failover and Failback

Unified Assurance supports pairs of geographical or cross-data center (XDCR) failover and failback capabilities. Oracle recommends you read the redundancy brief provided by Oracle and document your failover requirements for production implementation before implementation.

See Scalability and Redundancy in Unified Assurance Concepts.

Backup and Restore Strategy

As with all software, standard backup and restore requirements should apply. By default, the Unified Assurance configuration database is backed up every Saturday at 1 AM. You must create a backup plan for the other databases and define all backup requirements before implementation.

See Backup and Restore in Unified Assurance System Administrator's Guide for more information.

Unified Assurance Component Network Requirements

Unified Assurance uses some network ports for communication between components. You must open them bi-bidirectionally in your local operating system firewall and network ACLs or firewalls. Oracle recommends doing this before installing Unified Assurance.

See Linux Prerequisites for a detailed list of ports that are used.

Unified Assurance Typical Collection Network Requirements

Because Unified Assurance is typically used for polling devices across the network, you must open the following ports from at least the collection servers to the remote network devices. Oracle recommends creating a management subnet to make maintenance easier.

Scale and Capacity Planning

Unified Assurance scales based on two major areas: the number of database inserts per second and database retention requirements. These can be calculated using the Unified Assurance scalability brief and storage calculation spreadsheet. A detailed discovery and planning session is required to determine your polling requirements and storage retention levels for the initial implementation as well as considering future capacity required or expected.

DNS Caching

DNS caching on Linux is disabled by default, which can cause performance issues (such as increased load on DNS servers and increased response latency) in large scale implementations. For optimal performance, Oracle recommends configuring a DNS caching agent on all Unified Assurance servers.

Recommended DNS Caching agents:

Device Management Process

The device management process is one of the most common key administration processes that will need to be defined. This process includes what needs to be done in Unified Assurance to facilitate adding new devices to be monitored as well as how devices are decommissioned and handling the various changes a device may experience. Below is a basic list of areas that need to be addressed by the process:

As part of this process there may be additional enrichment or security required rules that may need to be written. The following are commonly required:

Most of the discovery engines are designed for discovery of new devices. The following device changes may need to be handled in some way by this process:

When devices are decommissioned the following areas will need to be addressed:

It is also important to understand how discovery and/or re-discovery processes will be initiated. Typically, most customers run discovery on-demand, but you may wish it to be fully automated and scheduled jobs can be enabled to run at set time of day, week, and month.

Dashboards

Custom Dashboards

Plug-ins

Metrics (Polling, Collection, Display)

Metric Manager is used for collection, processing, reporting, and displaying of availability, performance, or capacity-based data. The individual component types need to be properly scoped so that the correct configuration can be deployed. Below are commonly discussed requirements that need to be discussed/determined before moving into implementation.

Base Configuration

Pollers

Collectors

Synthetic Transactions

Thresholding

Dynamic Device Overviews

Besides the following, are there any custom metric overviews required?

Custom Reporting

Service Level Management

Events

Event Collection

Scalability

Escalation/Notification

Event Display

Enrichment

Correlation

Northbound Integrations

(Custom, Ticketing, Historical)

Historical Reporting

Topology

Network Inventory Collection

Topology Stitching

(ARP, CDP, IPRoutes, Config Agent, Custom CRM/Provisioning, Billing)

Configuration Agent

DNS IP SLA Naming Standards and Examples

A standard IP addressing scheme for distributing IP networks between access, distribution, core, WAN networks, and data centers should be devised. Networks should be allocated in CIDR blocks to help routing protocols summarize the networks as well as provide ease of identification.

All host and network devices should be configured to use Domain Name Service (DNS) servers for name resolution. For Unified Assurance components, configuring both forward and reverse resolution is recommended.

At least 2 DNS servers should be setup to provide authoritative DNS lookups to devices and hosts. Zones should be setup to provide forward lookups for all domains and subdomains (example.com), as well as provide reverse lookups for all IP networks (X.X.X.in-addr.arpa). If one device is accessible from multiple interfaces/IP addresses (from an ICMP and/or SNMP perspective), you should add reverse DNS to the management addressed host name.

A standard naming scheme should be used to provide consistency. The standard can include description by location, device type, purpose, etc. Names cannot include spaces, nor should they contain underscores (_) due to standards-based DNS restrictions.

Example 1

(Device Use)(Device Type)(Floor)(Device Number)(BuildingName)(Riser)
ASW-1-2-RDP-A1 = Access Switch 1st Floor Device Number 2 Galter Riser A1
DSW-1-2-RDP-PACS = Distribution Switch 1st Floor Device Number 2 Feinberg Building Riser PACS
CSW-5-1-259 = Core Switch 5th Floor Device Number 1 259 Building Riser N/A

Example 2

(Building)(Floor/Closet)(Device Type)(Device Number)
1st 3 characters designate building
4th thru the 7th characters designate the area, floor and closet
8th thru the 10th characters designate the device use & function
11th and 12th characters designate the device number

The example would result in a device name like "str-x201-wap-01", and could translate to meaning "the 1st wireless access point at stratford, area x, 2nd floor, 1st closet".

Cisco

Example IOS Configuration

ip domain-name <DNSDomain>
ip name-server <DNSSrv1>
ip name-server <DNSSrv2>

Example CatOS Configuration

set ip dns domain <DNSDomain>
set ip dns server <DNSSrv1> primary
set ip dns server <DNSSrv2>
set ip dns enable

Basic Device Configurations

Common Server Configurations

The following are some of the common server configurations for Unified Assurance.

SNMP Polling Options

Oracle recommends leveraging the Net-SNMP agent for Unix, Linux, and Windows-based platforms. For more information about the Net-SNMP agent, see the Net-SNMP website. If you wish to use Windows SNMP Agent, we highly recommend downloading SNMP Informant Patch for Windows. The stability, popularity, conformity of the agent, various platforms supported, and large default MIB support are the reasons for this recommendation. Oracle provides a net-snmp SNMP rules file that provides many of the common metric data requirements customers are seeking. For all other agents, custom SNMP rules may need to be created, so you may want to consult with your Oracle sales representative before implementation. Be aware that only SNMP v2 and v3 are supported by default by the pollers.

Unix/Linux Syslog Forwarding

Syslog forwarding is documented by the syslog daemon being used on your server. Some external research about your particular operating system will be needed, and you can also run "man syslogd.conf".

NTP

Oracle recommends all devices being monitored are synchronized to a single common clock source. Consult with your operating system documentation to determine the best NTP strategy for your organization.

You can use the chrony suite to configure network time. See Configuring Network Time in Oracle Linux 8 Setting Up Networking for more information.

Common Network Device Configurations

The following are some of the common network device configurations for Unified Assurance.

SNMP Polling Setup

Most network devices monitored by Unified Assurance leverage SNMP for communication. Consult your vendor documentation on how to set up SNMP connectivity and test the process before implementation. Below is a running list of different vendors and the recommended configuration required:

Cisco

Example IOS Configuration

no snmp-server community public RO
no snmp-server community private RW
snmp-server community <enter_read_only_password_here> RO
snmp-server community <enter_read_write_password_here> RW

Example CatOS Configuration

set snmp community read-only <enter_read_only_password_here>
set snmp community read-write <enter_read_write_password_here>
set snmp community read-write-all

Cisco devices can provide serial numbers through SNMP, although they are only configured by default on fixed chassis devices. All other modular devices should have the serial number configured manually to provide ease of contract and warranty management.

Example IOS Configuration

snmp-server chassis-id <enter_device_serial_number_here>

Example CatOS Configuration

set logging level snmp 7 default

Interface Descriptions

To assist with troubleshooting issues and to provide additional information to an enterprise management system, all interfaces should have a description defined for them. This description can either be a generic description about the interface type, or can include specific information like customer name, circuit ID, etc.

Example IOS Configuration

interface Serial0/1
 description T1 connection to Internet provider (circuit id: XXXX/0000001)

Example CatOS Configuration

set port name 4/1 Trunk to distribution switch

SNMP Interface Index Renumbering

One of the big challenges associated with many SNMP performance management tools is the tool's ability to handle interface index re-numbering. It is true that some tools handle this better than others; however, there are steps that your organization can take to minimize the problems you'll likely encounter when this occurs. One of the relatively easy and straight forward approaches to take is to configure all IOS routers with the command 'snmp-server ifindex persist'.

The tools also need to be smart enough to know when ifIndexes change for other devices. Usually vendors say they key off of the ifDescr, but they should allow this to be configurable by device type. For example, ifDescr is always the same on CatOS Ethernet ports, but portName will be unique.

Syslog/Trap Forwarding

Most network devices monitored by Unified Assurance forward event information either by Syslog or by Trap. Some devices can send equal quality of data in either format, and where this is the case Oracle recommends using syslog because it is easier to parse. Consult your vendor documentation on how to set up syslog or trap forwarding and test the process before implementation. Below is a running list of different vendors and the recommended configuration required:

Cisco Syslog

Example IOS Configuration

logging trap notifications
logging source-interface <DevMgmtIntf>
logging <MgmtSrvIPAddr>

Example CatOS Configuration

set logging server severity 5
set logging server enable
set logging server <MgmtSrvIPAddr>
set logging timestamp enable

NTP

Oracle recommends all devices on monitoring be synchronized with a single common clock source. Consult with your vendor documentation to determine the best NTP strategy for your organization. Below is a running list of different vendors and the recommended configuration required:

Cisco

Example IOS Configuration

service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
clock timezone CST -6
clock summer-time CDT recurring
ntp authenticate
ntp authentication-key 1 md5 <enter_auth_key_here>
ntp trusted-key 1
ntp source <DevMgmtIntf>
ntp server <NTPSrv1> key 1
ntp server <NTPSrv2> key 1

Example CatOS Configuration

set timezone CST -6
set summertime enable CDT
set summertime recurring
set ntp broadcastclient disable
set ntp client enable
set ntp authentication enable
set ntp key <enter_auth_key_here>
set ntp server <NTPSrv1>
set ntp server <NTPSrv2>