chapter 6 network management software components presentation by don keller
Post on 05-Jan-2016
237 Views
Preview:
TRANSCRIPT
CHAPTER 6NETWORK MANAGEMENT
SOFTWARE COMPONENTS
PRESENTATION
BY
DON KELLER
NETWORK MANAGEMENTSOFTWARE COMPONENTS
There are many possible solutions to NMS development- this chapter describes one possible structure.Server-side componentsNetwork-receiving asynchronousNetwork-receiving synchronous Network-sendingDatabase accessClient-side componentsMiddleware componentsData presentation, such as XMLNorthbound interface
Figure 1
`
. Typical servers provide the following
functions.Servicing client user requests
Issuing provisioning operations, such as writing to agent MIBS(inserting table entries, updating/deleting existing objects)
Special-purpose listening operations, such as monitoring LSP operational state
Providing generic service, such as scheduling
Providing specific service, such as NE, firmware and configuration data-base back-up, restore, and distributionHandling incoming notifications from networkDatabase form the glue that ties together the major componentClientsMiddlewareServerNEs
Thin client tend not to use database directly and instead rely on the server to manage the database
Recording client-initiated operations, such as creating FR or ATM virtual circuits
Storing the detail of scheduled operations and associated result
Thin client can be based on standard Web browser, there can be many such clients, and where to carry out bulk of the processing is an important design decision. If the principal requirement for client software is fast execution, then as much as possible of the MIB and database access should be carried out by the client rather than the MIB. If the client software is required to be simple and intuitive to use, then it should be designed to be as generic as possible. Generic software hide complex network data as much as possible and presents simple visual object proving default values where appropriate.
. This involves setting the MIB object values for
Bit rate
Parity
Number of data bits
Number of start bits
Number of stop bits, and so on
Fault Server
The purpose of the Fault Server is to process NE notification. It faces into the network and seeks to maintain parity between the NMS picture of network faults and the real situation in the network. A Fault Server will generally provide the following features:
Listening for notifications
Determining the underlying problem(root-cause analysis)
Updating persistent repositories and any GUI visual indicators
Fault Server Database Tables
Node ID(the Key)Description: A text string embedded in the notification explaining the faultOrigin: The originating NE(processor, card, fabric,etc..) for the faultStatus: active, cleared, acknowledged( the user know about the fault but has not cleared it)Color: Red for active, blue for acknowledged, green for clear
Topology update
CORBA
J2EE
JAVA RMI
RPC
Database update
Configuration Server
The purpose of the configuration server is to execute client-initiated directives made against NEs. Like the Fault Server, it also faces into the network but operate s in less open-ended way because it is not required to process asynchronous NE-originated notifications.
Let’s assume that a client user creates an LSP (label Switched Path) there are three
types
Signaled
Best-effort
Unidirectional
Origin Destination
Signaling Protocol
Required QoS
Explict Route Object
LER1 LER2 LDP BEST EFFORT
NONE
Secure User
Security Setting;
No authentication and no encryption
Authentication and no encryption
Authentication and encryption
Trace Files
Software bugs
SNMP timeouts, such as a third-party NE that has a slightly slow (or heavily loaded) agent
Bad values in MIB operations, such as trying to write an illegal value to a MIB object
Generic Connection Table Update
ATM virtual connection (PVX and SPVX0
MPLS LSP( signaled and unsignaled)
FR cross connections into an MPLS core
SONET path
Topology Update
Change the administrative status of a connection from up to down
Creating a new LSP
Deleting an existing LSP
Configuration Server Database Tables
Generic connection table: these contain data relevant to all connection types Keyes by index value or origination/ destination node IDsTechnology-specific connection tables: These contain data relevant to specific connection types, such as ATM PVX and LSPsOperations log tables: These are for recording configuration changeOperations result log tables: These are recording all configuration change results
ACCOUNTING SERVER
Accounting and performance software share a number of similarities. The Accounting Server faces into the network and receives data record periodically generated by NEs. Often, the data records are emitted based on a preconfigured time. It is also possible for an accounting Server to poll MIBs for specific data ultimately, accounting data is concerned with billing users for network resources consumption.
Mediation
Mediation is the process of analyzing the raw data generated by NEs to produce standard format billing details for downstream use by third-party applications (from organizations such as ACE*COMM). It is not necessary to use standard formats if the billing application is proprietary. However, standard format have the merit of allowing different third-party application to be swapped in as required.
Aggregation
This is the process by which separate CDRs are combined. An example is an ATM PVC that spans a number of NEs Number of IP packets transported (if the circuit is an LSP)Number of cells transported per second (if the circuit is an ATM connection)Number of cells dropped due to excessive input trafficAverage bandwidth used by the cell trafficNumber of SLA contract violations
Correlation
Correlation is the process of combining multiple units of aggregated data with the details of the ultimate bill recipient, that is, one customer. Number of cells sent to or received from the SP networkBandwidth used in transporting the data across the ATM link
Reports
Utilization of objects, such as LSPs
The average and peak numbers of IP packets transported by the LEP
The bandwidth consumed
Performance Server
The purpose of the Performance Server is to analyze network data in order to Determine if problems exist prior to their affecting servicesMaximize network utilizationPre-empt the occurrence of congestionDemonstrate compliance with agreed SLAsIndicate when extra network investment is needed(capacity planning)
SLA Alert
It is very important for enterprises to avoid violating SLA terms because there may be financial penalties.SLA alert can be issued based on ongoing analysis of trends in an effort to pre-empt violations before they actually occur.
Source IP address 10.81.1.45
Source Port 444
Destination IP address 10.81.2.89
Destination Port 445
Link Bandwidth 10Mbps
Interpacket Delay 1ms
Ordered Delivery Yes
Packet Loss 0.0001%
Jitter No
Round Trip Delay 30ms
This SLA indicates that IP traffic from 10.81.1.45 port 444 will land in the SP network on a 10Mbps link destined for 10.81.2.89 port 445. The interpacket arrival time is specified to be no more than 1 millisecond with no packet arriving out of order. A tunneling technology such as MPLS or L2TP could be employed to achieve the latter
Topology Update
When congestion is imminent on a given link
When a virtual circuit is being presented with excessive traffic-it may be necessary to add extra bandwidth to the circuit
Performance Server Database Tables
Nodes
Interface
Links
Virtual connections
Each table has separate columns for relevant performance
Number of incoming and outing packets, cells, and frames
Bandwidth in use
SLA status
Security Server
If there is one area of network management that has moved to the top of the operator’s, agenda, it is security, Access application: SNMP, telnet, secure shell, Web, console( serial port)Authentication ; Password, community string, Kerberos, user-based security Remote Access Dial-In User Service (RADIUS)Privilege level: Superuser, Read-only, and UserPermitted views: Specific objects and soures
Access Applications
Limited or no logging apart from that provided by the NE or CLi
Fairly open access to sensitive NE data
It may be error-prone, and help facilities may be quite limited
Some popular access applications are:
SNMP
Telnet
Secure Shell
Web
Authentication: Privilege Level
Read-only
User-level
Superuser
Read-only access allow only MIB get; user-level allows gets and some sets; superusers can get and set all appropriate
Permitted Views
Access control list
Permitted object views
An access control list contain the source IP addresses allowed to connect to an NE. Permitted object views specify a subset of MIB object accessible to a given NMS user
A discovery Server exist to keep up with the detail of the deployed NEs
Discovery keep track of:NodesInterface and underlying stacksLinksVirtual connection Cross connections between different technologiesRouting protocolsRouting TablesSignaling protocolsICMPSNMPStandard and proprietary signaling protocols
NE Software Distribution
FTP/TFTP
Proprietary download mechanisms
Using an NMS
Distributing NE in step:
Preparing the NE for a new firmware loadRerouting traffic around any nodes to which downloads are pendingInitiating the transferHandling rollback if the transfer failsVerifying the transfer succeededStarting up the new NE software
Preparing the NE may involve
Bring the NE into a quiescent state
Closing down existing connections
Ensuring that no resource are in use on the NE
Determining the available FLASH and RAM free space
Taking a copy of the existing firmware
NE Configuration Database Backup and Restore
Some reason for backing up:
New firmware build may upgrade the configuration, making rollback difficult
Disaster recovery
Creating Mirror network
Using a given configuration as a template
NMS should handle the complexities of:
Knowing where the appropriate configuration data flies are locatedHandling the transfer via FTP, TFTP, and so onRestart the NEs or reloading the data filesInforming the operator when the operation is completeRerouting traffic around the nodes being restored
Middleware
Middleware is the part of an NMs that allow communication between the clients and servers, There is a broad range of software technology choices for achieving this, including RPC,JAVA,COBRA, J2EE, and Microsoft.Net
SUMMARY
The implementation of NMS software can take the form of sever .These are high perform software objects that can support interaction with both external clients and NEs, It is essential that server are resilient and designed so that they are unlikely to fail except in exceptional circumstances. They form the intermediate layer through which end users can securely communicate with NEs.
The need for generic software components is growing with the increasing deployment of dense, multiservice NEs Generic software attempts to abstract complex Ne data as much as possible and present simple GUIs applicable across a broad range of devices.On the client side, GUI views are often depicted as network topologies accompanied by fault listings, It is a major challenge for the NMS software to keep these views synchronized with the network. It is always hard to escape form legacy NEs, and for this reason it is often necessary for server components to be SNMP multilingual, that is able to use any of SNMPv1/2c/3.
top related