Network reliability

Network reliability considerations

This section describes network reliability considerations.

Reliability between NFM-P components

The NFM-P requires reliable network communications between all the NFM-P components:

• NFM-P servers

• NFM-P databases

• NFM-P auxiliaries

• NSP Flow Collector

• NSP Flow Collector Controller

• NFM-P auxiliary databases

• NSP analytics server

• NFM-P clients and NFM-P client delegate server

• NFM-P XML API clients

The performance and operation of NFM-P can be significantly impacted if there is any measurable packet loss between the NFM-P components. Significant packet loss can cause NFM-P reliability issues.

Nokia supports the deployment of NFM-P using the RHEL IP Bonding feature. The support for IP Bonding is intended only to provide network interface redundancy configured in active-backup mode for IP Bonding on the OS instance hosting the application software. All other modes of IP Bonding are not supported. See the RHEL documentation for information about configuring IP Bonding.

NFM-P server to NE network reliability

The NFM-P server requires reliable network connectivity between the NFM-P server/Auxiliary to the managed network elements. The mediation layer in NFM-P is designed to recover from lost packets between the NFM-P server and the network elements; however, these mechanisms come with a cost to performance. Any measurable packet loss will degrade performance of NFM-P's ability to manage the network elements. The loss of packets between NFM-P and NE will have an impact on (but not limited to):

• Any SNMP operations to the network elements:

• SNMP Trap processing performance

• Provisioning performance

• Provisioning failures

• Performance statistics collection (possibly to the point where statistics collection will be incomplete)

• STM test operation (initiating test and collecting results retrieval)

• NE discovery and resync performance

• NE discovery and resync failures

• scheduled polling for reachability checks

• Accounting statistics retrieval (possibly to the point where statistics collection will be incomplete)

• CLI session operation

• NE backup retrieval and software download performance

The following example highlights the significant impact of lost packets. It only considers the SNMP communication times with one network element. With the default mediation policy configured with an SNMP retry time-out of 10 seconds, and an average round trip latency of 50 ms between NFM-P server and the network element, NFM-P will spend a total of 25 seconds sending and receiving 1000 packets (500 SNMP gets and 500 SNMP responses). With a 0.1% packet loss (1 packet out of the 1000) the NFM-P server will wait for the retry time-out (10 seconds) to expire before retransmitting. This will cause the time to complete the 500 SNMP gets to increase by 10 seconds – for a total of 35 seconds of communication time, or an increase of 40% over the time with no packet loss. With 0.5% packet loss, the 500 SNMP gets would increase by 50 seconds – for a total of 75 seconds to complete or an increase of 200%.