NETWORK MANAGEMENT

1
CHAPTER 6

• NETWORK MANAGEMENT
• SOFTWARE COMPONENTS
• PRESENTATION
• BY
• DON KELLER

2
NETWORK MANAGEMENTSOFTWARE COMPONENTS

• There are many possible
  solutions to NMS development- this chapter
  describes one possible structure.
• Server-side components
• Network-receiving asynchronous
• Network-receiving synchronous
• Network-sending
• Database access
• Client-side components
• Middleware components
• Data presentation, such as XML
• Northbound interface

3
Figure 1
4
. 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

5

• Providing specific service, such as NE, firmware
  and configuration data-base back-up, restore, and
  distribution
• Handling incoming notifications from network
• Database form the glue that ties together the
  major component
• Clients
• Middleware
• Server
• NEs

6
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

7

• 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.

8
. 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

9
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

10

• Listening for notifications
• Determining the underlying problem(root-cause
  analysis)
• Updating persistent repositories and any GUI
  visual indicators

11
Fault Server Database Tables

• Node ID(the Key)
• Description A text string embedded in the
  notification explaining the fault
• Origin The originating NE(processor, card,
  fabric,etc..) for the fault
• Status active, cleared, acknowledged( the user
  know about the fault but has not cleared it)
• Color Red for active, blue for acknowledged,
  green for clear

12
Topology update

• CORBA
• J2EE
• JAVA RMI
• RPC
• Database update

13
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.

14
Lets assume that a client user creates an LSP
(label Switched Path) there are three types

• Signaled
• Best-effort
• Unidirectional

15
(No Transcript)
16
Secure User

• Security Setting
• No authentication and no encryption
• Authentication and no encryption
• Authentication and encryption

17
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

18
Generic Connection Table Update

• ATM virtual connection (PVX and SPVX0
• MPLS LSP( signaled and unsignaled)
• FR cross connections into an MPLS core
• SONET path

19
Topology Update

• Change the administrative status of a connection
  from up to down
• Creating a new LSP
• Deleting an existing LSP

20
Configuration Server Database Tables

• Generic connection table these contain data
  relevant to all connection types Keyes by index
  value or origination/ destination node IDs
• Technology-specific connection tables These
  contain data relevant to specific connection
  types, such as ATM PVX and LSPs
• Operations log tables These are for recording
  configuration change
• Operations result log tables These are recording
  all configuration change results

21
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.

22
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
  ACECOMM). 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.

23
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
  traffic
• Average bandwidth used by the cell traffic
• Number of SLA contract violations

24
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
  network
• Bandwidth used in transporting the data across
  the ATM link

25
Reports

• Utilization of objects, such as LSPs
• The average and peak numbers of IP packets
  transported by the LEP
• The bandwidth consumed

26
Performance Server

• The purpose of the Performance Server is to
  analyze network data in order to
• Determine if problems exist prior to their
  affecting services
• Maximize network utilization
• Pre-empt the occurrence of congestion
• Demonstrate compliance with agreed SLAs
• Indicate when extra network investment is
  needed(capacity planning)

27
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.

28
(No Transcript)
29

• 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

30
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

31
Performance Server Database Tables

• Nodes
• Interface
• Links
• Virtual connections

32

• Each table has separate columns for relevant
  performance
• Number of incoming and outing packets, cells, and
  frames
• Bandwidth in use
• SLA status

33
Security Server

• If there is one area of network management that
  has moved to the top of the operators, 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 User
• Permitted views Specific objects and soures

34
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

35

• Some popular access applications are
• SNMP
• Telnet
• Secure Shell
• Web

36
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

37
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

38
A discovery Server exist to keep up with the
detail of the deployed NEs Discovery keep track
of

• Nodes
• Interface and underlying stacks
• Links
• Virtual connection
• Cross connections between different technologies
• Routing protocols
• Routing Tables
• Signaling protocols
• ICMP
• SNMP
• Standard and proprietary signaling protocols

39
NE Software Distribution

• FTP/TFTP
• Proprietary download mechanisms
• Using an NMS

40
Distributing NE in step

• Preparing the NE for a new firmware load
• Rerouting traffic around any nodes to which
  downloads are pending
• Initiating the transfer
• Handling rollback if the transfer fails
• Verifying the transfer succeeded
• Starting up the new NE software

41
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

42
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

43
NMS should handle the complexities of

• Knowing where the appropriate configuration data
  flies are located
• Handling the transfer via FTP, TFTP, and so on
• Restart the NEs or reloading the data files
• Informing the operator when the operation is
  complete
• Rerouting traffic around the nodes being restored

44
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

45
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.

46

• 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.