Basic Planning

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

Business Requirements

Define Business Goals

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/measure against them throughout the duration of the implementation. Examples of business goals are defined below:

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 both internal and external authentication mapped one-to-one to the user defined, but no fail-over capability between the types. Below are the three types of external authentication, make sure you determine these configurations prior to implementation:

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. All these configurations are defined within the User Groups, Device Groups, Dashboard Groups, Diagram Groups, and Event Filter Groups all need to be defined prior to its creation. Any multitenancy configuration needs to be designed prior to implementation to prevent rework.

Defined Roles

To leverage any secure application, certain roles need to be defined and each role needs to be assigned privileges. By default, five roles come pre-defined by Unified Assurance: Administrator, Anonymous, API, Operator, and Publisher. Additional roles may be required within your environment, so this needs to be determined at the earliest stage of implementation.

Users Group Creation

User groups, like roles, need to be determined prior to implementation. User Groups use roles to control access into Unified Assurance and have a group of defined usernames associated to the group.

Process Management

Oracle Communications recommends that all major processes (defined or yet undefined) be listed and use cased 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's architecture consists of a typical 3-tier implementation, where the presentation layer leverages an Apache web server, the data layer consists of MySQL, Elastic, 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/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 Communications recommends the following:

Hardware Requirements

Estimates are broken out into four categories and are baseline hardware recommendation for Unified Assurance.

All Historical Storage estimates given are based on default configuration and retention policies. Storage requirements depend on data retention policies, number of raw events received, and number of metrics collected. Contact your Sales Representative for a personalized estimate.

Minimum

Minimum installs are less than 1000 devices.

Supported implementations:

Requires:

Medium

Medium installs are between 1,000 - 25,000 devices.

Supported implementations:

Requires:

Large

Large installs are greater than 25,000 devices.

Supported implementations:

Requires:

...and Beyond

For extremely large installations or more specific requirements, please contact your Sales Representative.

Software Map

Determining the software map is a matter of applying the components list to the hardware list. Components can be installed on any server, but there are some best practices rules detailed below:

Redundancy, Fail-over and Fail-back

Unified Assurance supports pairs of geographical or cross data center (XDCR) fail-over and fail-back capabilities. We recommend you read the redundancy brief provided by Oracle Communications and document your fail-over requirements for production implementation prior to start of implementation.

Backup and Restore Strategy

As with all software, standard backup/restore requirements should apply. By default, the Unified Assurance configuration database is backed up every Saturday at 1 AM. The other databases need to be included into a backup plan. All backup requirements need to be defined prior to implementation.

Unified Assurance Component Network Requirements

Unified Assurance uses few network ports for inter-component communications. These need to be opened bi-bidirectionally via the local operating system firewall and/or network ACLs or firewalls. Oracle recommends that this is done prior to installation.

Unified Assurance Typical Collection Network Requirements

As Unified Assurance is typically used for polling devices across the network, the following ports need to be opened from at least the collection servers to the remote network devices (Oracle Communications recommends a management subnet be created to make maintenance of this easier).

Scale and Capacity Planning

Unified Assurance scales based upon two major areas: database inserts/second and database retention requirements. These can be calculated using the Unified Assurance scalability brief and storage calculation spreadsheet. A detailed discovery & 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 (increased load on DNS servers, increased response latency, etc.) in large scale implementations. For optimal performance, it is recommended that a DNS caching agent be configured 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 Communications 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 Communications 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 Communications 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.

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 Communications 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 Communications 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>