A Real NMS Chapter 5 CIS 536 Network Management By Kode Venkateswara Rao

2 Hewlett – Packard’s OpenView The following are the headings under which we study the NMS: a)FCAPS support – Basic NMS application areas. b)MIB support features. c)MPLS Support. d)Policy Support. e)Reliability features, such as support for failure. f)Integration with other software. g)Programmability.

3 OpenView Network Node Manager Central to the function of NNM is the management station. This is the computer that performs the bulk of data collection like: a) Collection of information from NEs via SNMP. b) Processing and archiving data in a database. c) Distribution to registered applications.

4 There can be more than one management station which can exchange information with one another. Management station can delegate NE data collection to collection stations. HP suggests that a single management station can handle 5000 managed objects. Up to 60,000 objects can be managed if collection stations are deployed.

5 NNM Features Discovery and Mapping Monitoring Notification processing Reporting Data Warehousing Backup and Restore of firmware and configuration data Java interface for remote access to management features Remote administration of NMS

6 Network Discovery and Mapping This NMS feature enables discovery of new NEs. Automatic discovery frees the user from potentially error prone task of manually entering and maintaining the details of deployed NEs. Large service providers deploy NMS from the point in time that they start to build their networks.

7 Discovery has three main stages. They are: Initial discovery of previously unknown NEs. Examples of Initial Discovery are  IP address of SNMP agent on the device.  Inventory details like cards deployed in the device.  Protocols, technologies running on the device such as ATM, MPLS, X.25 and so on.  Virtual connections, traffic profiles, route objects and so on.

8 Incremental discovery of changes that occurred to previously discovered data. Discovery of removal – when a Network Element is taken out of network, it is automatically removed from NMS.

9 NNM Discovery and Mapping NNM provides and automatic discovery mechanism. Discovery process uses SNMP based polling and ICMP requests to build a picture of the network. Discovery process populates an IP topology database using a series of tables like Network-level connectivity, Segments, Nodes, Interfaces. This grouping allows NNM to create logical maps of the NEs and to graphically indicate operational status using a color, such as green for up, red for down, etc. An icon representing a network can be expanded to show the constituent nodes. In other words, containment relationships are depicted clearly.

10 Monitoring This is a process of recording changes in the status of managed objects such as:  Nodes  Interfaces  Links  Virtual Connections  Ethernet VLANs

11 Status changes can have important bearing on the service received by the end user. When an interface that is part of an ATM goes down, the interface is no longer able to handle the traffic. Such a status change may be service affecting if there is no backup connection. Because of this Monitoring functions are an important part of an NMS. The same process that carries out discovery also executes NNM monitoring. Status changes are reflected back into the topology.

12 Notification Processing An important part of fault management – this is the (F) part of the FCAPS. Following would be the issues for SNMP notifications.  Notifications are not acknowledged by the NMS.  Notifications are transported using UDP Protocol and are unreliable.  Faulty NEs can generate many notifications.  Aggregated services which are faulty can produce notification storms.

13 When an NMS receives an SNMP trap over an unreliable transport, it never acknowledges. This helps in scalability and keeps the management protocol as lightweight as possible. It reduces network congestion. When an agent detects a problem, it sends a best effort notification message and delegates problem resolution to the NMS. Networks are designed to have at least 25% bandwidth free to allow routing, signaling, and management protocols to operate at all times. If this is followed then agent notifications should always get through to the NMS.

14 NNM Notification Processing NNM uses the term EVENT to describe NE notifications as well as messages from other sources ( external applications). NNM provides an alarm browser for all such events. Important events can then be configured to show up as alarms for operator intervention.

15 NNM distinguishes between notifications and events. Lifecycle for a notification is:  An NE sends a notification.  Notifications is received by NNM and logged.  NNM distributes the notification to applications that are registered for it. NNM allows notifications to be paired so that notification A indicates a problem and notification B indicates problem rectification. Such paired notifications assist a network operator because they reflect those situations when the network self heals. When the correction notification does not occur then the fault remains active. NNM also supports event correlation in which a given notification is processed before it is forwarded to one of the applications.

16 Reporting Reporting is one of the most features of an NMS in which data is retrieved from the network and presented in a specified format. This can include the following:  Deployed NEs  NE configuration  Interfaces  Links  Virtual Connections

17 NNM Reporting NNM reporting is GUI Based and is accessible through a browser. The main options are:  Report Configuration: Create, delete and modify reports.  Report Presentation: View reports. NNM reports can be:  Scheduled  Configured/viewed using a standard browser  Automatically ed to a recipient

18 Examples of NNM pre-configured reports are as following:  Accounting  Availability  Congestion  Historical Details  Inventory  Performance  Real-time details  Thresholds  Trend Analysis  Utilization

19 Data Warehousing NMS provides a persistent repository, that is, a commercial database product such as Oracle. It is this database that is kept synchronized by the NMS Application regarding the network state. It also facilitates data security by hosting the database in a secure location with access grants only to authorized clients. The user can view all the necessary information to manage the network, such as, Viewing the configuration of a given node, Provisioning an ATM virtual connection between two nodes and so on. The database is therefore a key component of the NMS. All the FCAPS applications use it.

20 Backup and Restore In network management both firmware and NE configuration are high value items. The firmware version on a given NE is subject to change as new features and technologies are added. It is important to backup the existing version before any upgrade. Once the NEs have been configured and are operational, it is important to be able to backup the settings, also called as configuration database. NNM provides a backup facility that allows a snapshot to be taken of the topology and maps. These are frozen during the time it takes to copy the data into a backup directory. At no time during this process do the alarm handling and data collection procedures stop.

21 Java interface for Remote Access Standard Java enabled Web browsers reduce investment required for producing client side NMS solutions because no development is required for client application framework. Browser provides execution environment for client applications. Use of java as number of merits:  Java is object oriented.  Provides built-in security  Java is multiplatform programming language  Java supports field-replaceable packages

22 NNM Java Interface Java based Web interface in NNM allows user to connect to the NNM management station. It permits remote viewing of:  Topology  Alarms  Node status  MIBs  Maps  Graphs Java interface exports management station function onto desktop systems equipped with standard browsers on Remote clients.

23 MIB Support Features MIBs provide details concerning the network managed objects and form the basis for the NMS data model. NMS should provide number of baseline features for MIB support like:  Load new MIBs  Support Multiple versions of the same MIB  Unload MIBs no longer in use  Browse and analyze MIBs

24 MPLS Support MPLS nodes have a number of managed objects, the status of which can change over time:  Interfaces can be up or down  Routing protocols such as OSPF, IS-IS can be operational or disabled.  Forwarding table entries can be active or inactive  LSPs can be up or down Other MPLS objects that do not change are:  EROs  Resource Blocks  Cross-connects

25 NNM provides no special support for MPLS but can be extended to use the appropriate MIBs.

26 Policy Support Network management terms and policies can be used to automatically solve recurring problems. One example is traffic thresholds. User can set a threshold on an interface for the number of packets received. If the threshold is exceeded, a notification is generated and the NMS can divert the traffic.

27 NNM Policy Support Apart from basic policies like issuing s in response to certain events, NNM requires third party products to implement policy handling. Policy based applications provide features such as:  Application prioritization  Enterprise policy distribution, example: access to NEs.  User-based security policies and so on.

28 Reliability Features Backup facilities can help in improving reliability. In case of NMS, this can take the form of protecting the central database with a failover capability. User can deploy a backup version of the database that runs in a parallel mode with the primary system. NNM collection stations can be configured to failover to remote management stations.

29 Integration with other software NMS can be integrated with some ancillary systems or applications which can perform the following:  Data export of network topology/inventory data for business asset analysis  Data export of software based modeling packages for traffic analysis, network design. Specialized software applications can be used to carry out offline traffic analysis. A snapshot of the discovered topology can be exported into a modeling package, and the user can execute what-if scenarios. The effects of such changes can be viewed offline before making the changes.

30  Integration of alarms with trouble ticket system. Alarms generated by the network can be routed via the NMS to trouble ticket applications. This allows for recording and directing any remedial work required to clear the fault.  Performance analysis regarding the number of packets, cells, frames transported by a NE. Many NEs generate performance data records (PDR) that provide utilization details for: a) Ports, links and virtual circuit utilization b) Protocols c) Networking technologies

31  Billing: Reports generation using CDRs and other data such as connection type, class of service.  Security – distribution of keys, user accounts and passwords, digital certificates and so on. NNM Integration:  Many third party applications like Microsoft System Management Server can be integrated with NNM.

32 Programmability Facility of adding software to an NMS can greatly extend its usefulness. Network management requirements are unique to every network, so programmability is an important addition. NNM Programmability NNM allows for user-software to be added to enhance the base functions. This can include reporting, alarm and event processing.

33 Summary Effective network management requires broad range of software tools. In NNM Network Management is achieved by using a number of software packages. Special Software can be employed for billing, mediation and performance analysis. Minimizing the gap between the network situation and that perceived by the NMS is crucial and provides a baseline for defining the quality of a given NMS.