Integrating Packet Core Network Elements to NetAct

Integrating Packet Core Network Elements to NetAct

DN00297251 Issue 7-1 en

© Nokia Corporation Nokia Proprietary and Confidential

1 (100)


The information in this documentation is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia's customers only for the purposes of the agreement under which the documentation is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the documentation are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the documentation. Nokia's liability for any errors in the documentation is limited to the documentary correction of errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this documentation or the information in it. This documentation and the product it describes are considered protected by copyright according to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this documentation may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright © Nokia Corporation 2006. All rights reserved.

2 (100)


DN00297251 Issue 7-1 en

Contents Contents 3 List of tables 6 List of figures 7 1 1.1 1.2

About this document 9 NetAct compatibility and capacity information 9 Terms 9

2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7

Introduction to Packet Core integration 11 Integration principles 11 Integration principles for GGSN 11 Integration principles for Flexi ISN 12 Integration principles for 3G SGSN 13 Integration principles for CG, GNS, and DHCP server 13 Integration principles for Content Analyser (CA) 14 Integration principles for router (RTR) and Ethernet switch (IPSW) 14 Integration principles for SGSN 14 Integration procedures 14 Integration procedure for IP platform network elements 14 Integration procedure for CG, GNS, and DHCP server 16 Integration procedure for BIG-IP Network Elements 16 Integration procedure for Traffic Analyser (TA) 16 Integration procedure of routers 17 Integration procedure for Content Analyser (CA) 17 Integration procedure for SGSN 18

3 3.1 3.1.1 3.1.2 3.1.2.1 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.2 3.2.1 3.2.1.1 3.2.2 3.2.2.1 3.3 3.3.1 3.4 3.5

Preliminary tasks for Packet Core NE integration 19 Reviewing the system requirements 19 Nokia NetAct 19 IP platform NEs 20 Verifying the versions 21 CG, GNS, and DHCP server 23 BIG-IP 23 Routers 23 Content Analyser 24 SGSN 24 Adding managed objects to DNS 25 Adding a PaCo NE to DNS using NameSurfer 26 Adding a host to PaCo forward zone with NameSurfer 29 Adding a Packet Core NE to DNS using BIND 30 Adding a host to Packet Core forward zone 33 Creating managed objects for Packet Core NEs 33 SNMP-specific attributes for managed objects 39 Checking Maintenance Region Service Users in NetAct 41 Checking the DNS configuration 43

DN00297251 Issue 7-1 en


3 (100)


4 4.1 4.2 4.3 4.4 4.5

Configuring a Nokia IP Platform based NE 47 Checking the IP configuration 47 Configuring a static route 48 Configuring network time protocol (NTP) 49 Configuring SNMP 53 Setting measurement data file format for GGSN 57

5 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.2 5.2.1 5.2.2 5.3

Configuring HP-UX based Network Elements 59 Configuring Charging Gateway 59 Configuring HP-UX SNMP agent 59 Configuring Charging Gateway SNMP agent 60 Configuring Charging Gateway Alarm Interface 61 Configuring the network time protocol (NTP) 62 Configuring DHCP server 64 Configuring SNMP 64 Configuring NTP 64 Configuring GNS 64

6 6.1 6.2

Configuring BIG-IP 67 Configuring BIG-IP 4.5 67 Configuring BIG-IP 9.1 69

7 7.1

Configuring a router 75 Configuring SNMP for a router 75

8

Providing users access to NetAct applications and network elements 79

9 9.1 9.1.1 9.1.2

9.2.2 9.2.3 9.2.4

Verifying integration 81 Nokia IP platform network elements 81 Verifying IP connectivity 81 Verifying performance management data flow for IP platform network elements 81 Verifying fault management data flow 82 Verifying Configuration Management 83 Verifying Element Manager launch 83 Nokia CG, DHCP server and GNS 84 Verifying performance management flow for CG, DHCP Server and GNS 84 Verifying fault management data flow for CG, DHCP Server and GNS 84 Verifying configuration management for CG, DHCP Server and GNS 85 Verifying Element Manager launch for CG, DHCP Server and GNS 85

10

Where to find more information 87

9.1.3 9.1.4 9.1.5 9.2 9.2.1

Appendix A. Moving GNS-managed zone(s) under the management of the NetAct DNS 89 A.1 GNS 91 A.1.1 NameSurfer is not the primary Name Server 91 A.1.2 NameSurfer is the primary Name Server 92 A.2 NetAct DNS environment 92

4 (100)


DN00297251 Issue 7-1 en

A.2.1 A.2.2 A.2.3 A.2.4 A.2.5 A.3

Name Server has zones required by GNS 92 Name Server does not have the zones required by the GNS 93 NameSurfer is the primary Name Server 94 All authoritative zones exist in BIND based slave DNS 96 All authoritative zones do not exist in BIND based slave DNS 96 GNS 97 Index 99

DN00297251 Issue 7-1 en


5 (100)


List of tables

6 (100)

Table 1.

DNS entries example

29

Table 2.

DNS entries example

33

Table 3.

Mapping between Packet Core network elements and managed object classes 36

Table 4.

Network Editor dialog example input for Packet Core MOs

Table 5.

Maintenance Region Service users needed during PaCo integration


40 42

DN00297251 Issue 7-1 en

List of figures Figure 1.

GGSN connections to NetAct 12

Figure 2.

Basic procedure for integrating an IP platform NE to NetAct 15

Figure 3.

Basic procedure for integrating LIG, BG and Packet Core FW to NetAct 16

Figure 4.

An overview of integrating a router to Nokia NetAct 17

Figure 5.

Checking the NE version 22

Figure 6.

Checking the IPSO version 22

Figure 7.

Adding a NE to DNS using NameSurfer as the primary NS 27

Figure 8.

Adding hosts to PaCo forward zone with NameSurfer 28

Figure 9.

Adding a NE to DNS using BIND as the primary NS 31

Figure 10. Adding hosts to PaCo forward zone with BIND 32 Figure 11. Creating an Object dialog for SNMP MOs with community strings

35

Figure 12. Creating an Object dialog for SNMP MOs without community strings 40 Figure 13. Configuring DNS for Packet Core NEs 44 Figure 14. Checking IP configuration 47 Figure 15. Configuring static route 49 Figure 16. Selecting a time zone 50 Figure 17. Configuring NTP for Packet Core NEs 52 Figure 18. Configuring SNMP for Packet Core NEs (top part) 55 Figure 19. Configuring SNMP for Packet Core NEs (bottom part) 56 Figure 20. Example of the NetAct related part in the file /etc/SnmpAgent.d/snmpd.conf 60 Figure 21. Example of the NetAct related part in the file /opt/cg/4.0/netsnmp/etc/snmp/snmpd.conf. 61 Figure 22. SNMP Agent Configuration pane 70 Figure 23. SNMP Destination pane 71 Figure 24. New trap record pane 72 Figure 25. Zone transfer from GNS to NetAct DNS 90 Figure 26. Master NS and Admin email address of the SOA Resource Record 95 Figure 27. SOA object in NameSurfer 95

DN00297251 Issue 7-1 en


7 (100)


Figure 28. Authoritative Name Server for the zone 95 Figure 29. Example of a zone statement for BIND based primary Name Server 97 Figure 30. Example of a zone statement for NameSurfer based primary Name Server 97

8 (100)


DN00297251 Issue 7-1 en

About this document

1

About this document Integrating Packet Core Network Elements to NetAct describes how to integrate Packet Core network elements to Nokia NetAct. Integration of the following Packet Core network elements is described in this document: •

GGSN, WA, 3G SGSN, LIG, BG, Packet Core FW, Flexi ISN and TA

•

CG, GNS, and DHCP Server

•

BIG-IP

•

Router (RTR) and Ethernet switch (IPSW).

The document is written for the management and the integration personnel of an operator. Additionally, you need to perform various configuration tasks directly on the NEs that you are integrating. For information on the tasks related to SGSN and Content Analyzer, which is based on FlexiServer platform, see: •

Integrating SGSN to NetAct

•

Integrating FlexiServer Network Elements to NetAct

If you are already familiar with the general connection principles and protocols used in integrating Packet Core NEs to NetAct, go to Chapter 3 Preliminary tasks for Packet Core NE integration.

1.1

NetAct compatibility and capacity information For information on the NetAct system and capacity and the compatibility between NetAct and network element releases, see the NetAct Compatibility and Capacity Information document.

1.2

Terms For terms and abbreviations that are used in this document, see Glossary.

DN00297251 Issue 7-1 en


9 (100)


10 (100)


DN00297251 Issue 7-1 en

Introduction to Packet Core integration

2

Introduction to Packet Core integration This chapter describes the integration principles and procedures for the Packet Core network elements in scope of this document.

2.1

Integration principles For information on the integration principles for IP platform based NEs, CG, GNS, and DHCP server, and Flexi NEs to Nokia NetAct outside of the scope of this document, see:

2.1.1

•

Integration principles in Integrating SGSN to NetAct

•

Integration principles in Integrating FlexiServer Network Elements to NetAct

Integration principles for GGSN Gateway GPRS Support Node (GGSN) acts as the interface between a GPRS network and external networks. GGSN is connected to Nokia NetAct through Packet Core IP backbone network. GGSN is implemented on Nokia IP650 (GN2500) series or Nokia IP740 (GN3500) series platforms. The following figure illustrates the connections between GGSN and Nokia NetAct.

DN00297251 Issue 7-1 en


11 (100)


NetAct

NetAct Firewall

O&M data

Packet Core backbone

Charging Gateway network

Demilitarised network (DNS)

O&M data (SNMP, NTP, HTTP, FTP)

Figure 1.

2.1.2

GGSN

GGSN connections to NetAct

Integration principles for Flexi ISN The Flexi ISN acts as a gateway between the wireless data networks and the Internet. In addition to the 'classic' GGSN functionality, NokiaFlexi ISN (releases 2.0 and 3.0) has a traffic analysis functionality for differentiated charging purposes. Flexi ISN is based on the FlexiServer hardware platform and Nokia IPSO Operating System. The communication between Flexi ISN and NetAct is based on the Nokia enhanced SNMP Solution Suite (NE3S). The remote management of the Flexi ISN from NetAct is enabled by the following management interfaces and protocols:

12 (100)

•

NE3S for collecting alarms and performance indicators

•

Voyager Web interface for configuration and administration of the Flexi ISN

•

Network Time Protocol (NTP) for synchronising the Flexi ISN internal clock

•

File Transfer Protocol (FTP) for software image download, configuration data backup and restore functions

•

SSH/Telnet for remote shell access


DN00297251 Issue 7-1 en


2.1.3

Integration principles for 3G SGSN 3G SGSN acts as a link between 3G Radio Access Network (RAN) and packet core network. 3G SGSN performs both control and traffic handling functions for packet switched domain in 3G system. 3G SGSN is based on the high-capacity IP3400 Nokia Multiprocessor router Platform and on the Nokia IPSO operating system. 3G SGSN is managed from Nokia NetAct through the following interfaces and protocols: •

Simple Network Management Protocol (SNMP), for alarms, performance indicators, and configuration data.

•

Nokia Voyager Web interface for the initial configuration and administration of 3G SGSN.

•

Network Time Protocol (NTP) for the synchronisation of 3G SGSN internal clock with Nokia NetAct.

•

Telnet or Secure Shell (SSH) for software downloading and activating and configuration upgrade. With SGN4 version, Telnet can be disabled and only SSH is in use, depending on the configuration.

•

File Transfer Protocol (FTP) for software image downloading, configuration data backup, and restoring function.

Typically, 3G SGSN uses the IP backbone network and the physical Gn interface in 3G SGSN for implementing the management connection. 3G SGSN Gn physical interfaces can be implemented through 10/100BaseTX RJ45 interface (IEEE 802.3, 802,3u), Gigabit Ethernet (IEEE 802.3z), or ATM 155 Mbps STM1.

2.1.4

Integration principles for CG, GNS, and DHCP server The following protocols and interfaces are used in Nokia NetAct for managing CG, GNS, and DHCP server:

DN00297251 Issue 7-1 en

•

Simple Network Management Protocol (SNMP), for alarms, performance indicators, and configuration data.

•

Element Manager for the initial configuration and administration of CG.

•

Network Time Protocol (NTP) for the synchronisation of the NE’s internal clock with Nokia NetAct.

•

Telnet or Secure Shell (SSH) for software downloading and activating and configuration upgrade.


13 (100)


2.1.5

•

File Transfer Protocol (FTP) for software image downloading, configuration data backup, and restoring function.

•

DNS protocol for making DNS queries, such as of zone transfers, zone notifications and zone polling.

Integration principles for Content Analyser (CA) For information on integration principles of Content Analyser, see Integration principles in Integrating FlexiServer Network Elements to NetAct.

2.1.6

Integration principles for router (RTR) and Ethernet switch (IPSW) RTR and IPSW are generic objects, and their integration depends on the supplier. The detailed instructions, for example, how to configure the target for SNMP traps and how to configure the community strings, are delivered with the equipment. The equipment usually provides its own element manager system for this kind of configuration steps. For generic instructions on how to integrate a router to Nokia NetAct, see Chapter 7 Configuring a router. These instructions apply to all the routers that support SNMP and standard Management Information Base (MIB). For instructions on integrating Cisco switch or router, see Optional configurations in Integrating DCN Backbone to NetAct.

2.1.7

Integration principles for SGSN For information on integration principles of SGSN, see Integration principles in Integrating SGSN to NetAct.

2.2

Integration procedures This section provides an overview of integrating Packet Core network elements to Nokia NetAct.

2.2.1

Integration procedure for IP platform network elements GGSN, 3G SGSN, Flexi ISN and WA

Integration of GGSN, 3G SGSN, Flexi ISN and WA consists of completing a set of preliminary tasks and then configuring NTP, SNMP and DNS services. The following figure shows an overview of the integration procedure.

14 (100)


DN00297251 Issue 7-1 en


Start preliminary tasks

Review the system requirements

Configure the NetAct servers

Start configuration

Check the IP configuration

Configure NTP

Configure SNMP

Check the DNS configuration

Task is done in:

NE

Verify the NetAct connections

NetAct

Figure 2.

Basic procedure for integrating an IP platform NE to NetAct

LIG, BG and Packet Core FW

LIG, BG and Packet Core FW integration consists of completing a set of preliminary tasks and then configuring NTP and SNMP. The following figure shows an overview of the integration procedure.

DN00297251 Issue 7-1 en


15 (100)


Start preliminary tasks

LIG BG FW


Configure the NTP

Configure the NetAct servers

Configure SNMP

Task is done in:

End

NE NetAct

Figure 3.

2.2.2

Basic procedure for integrating LIG, BG and Packet Core FW to NetAct

Integration procedure for CG, GNS, and DHCP server CG, GNS, and DHCP server integration consists of configuring static route, NTP and SNMP. For the procedure, see the figure 3 Basic Procedure for integrating LIG, BG and Packet core FW to Nokia NetAct presenting the basic procedure for integrating LIG, BG and Packet Core FW to Nokia NetAct. For information on how to move GNS-managed zones, see A Moving GNSmanaged zone(s) under the management of the NetAct DNS.

2.2.3

Integration procedure for BIG-IP Network Elements For integrating BIG-IP to Nokia NetAct, the static route, NTP, and SNMP have to be configured. They need to be already configured when BIG-IP NEs are configured with other NEs, for example MMSC or NGW.

2.2.4

Integration procedure for Traffic Analyser (TA) Nokia ISN Traffic Analyser (TA) 3.0 is an IP router. For communicating with NetAct TA 3.0 FM uses the Nokia Enhanced SNMP Solution Suite (NE3S) interface, while TA 3.0 PM is SNMP polling based.

16 (100)


DN00297251 Issue 7-1 en


2.2.5

Integration procedure of routers The integration of a router to Nokia NetAct includes a set of preliminary tasks and the configuration of SNMP. The following figure gives an overview of the integration procedure.

Start


Add the router information to the DNS

Create MOs for the router

Check the MR Service users

Configure SNMP for the router

Verify the integration

End

Figure 4.

An overview of integrating a router to Nokia NetAct

For instructions on how to configure a router, see Chapter 7 Configuring a router.

2.2.6

Integration procedure for Content Analyser (CA) For information on integration procedure of Content Analyser, see Integration procedure in Integrating FlexiServer Network Elements to NetAct.

DN00297251 Issue 7-1 en


17 (100)


2.2.7

Integration procedure for SGSN For information on integration procedure of SGSN Network Elements, see Integration procedure in Integrating SGSN to NetAct.

18 (100)


DN00297251 Issue 7-1 en

Preliminary tasks for Packet Core NE integration

3

Preliminary tasks for Packet Core NE integration This chapter describes the preliminary tasks, which need to be performed before the integration.

3.1

Reviewing the system requirements This section describes the system requirements to be met for the integration.

3.1.1

Nokia NetAct Not all requirements apply to all network elements. Before beginning integration, ensure the following: •

Nokia NetAct environment is configured and functioning properly. See Testing the System Platform

•

GPRS domain name and IP addresses for GPRS Name Servers are available

•

IP addresses for NetAct servers and osscore2 are available

To find out the IP address of the osscore2 ServiceGuard package and the primary nodes for db and system packages (SS & DS) 1.

For a full list of options available with the ldapacmx.pl script, enter:

ldapacmx.pl -help

2.

Interrogate the IP address and FQDN of the osscore2 pkg by entering:

omc% ldapacmx.pl -sgPkgHost osscore2 | nslookup

Example output:

DN00297251 Issue 7-1 en


19 (100)


... Name: Address:

3.

rc80cor2.netact.noklab.net 10.8.xxx.xxx

Interrogate the IP address and FQDN of the primary node (Database Server) for db package by entering:

omc% ldapacmx.pl -pkgPrimaryNode db | nslookup

4.

Interrogate the IP address and FQDN of the primary node (System Server) for system package by entering:

omc% ldapacmx.pl -pkgPrimaryNode system | nslookup

5.

3.1.2

Note down these IP addresses, as you need them during the NE integration.

IP platform NEs The same requirements apply to all IP platform NEs presented in this document: 3G SGSN, GGSN, Flexi ISN, WA, LIG, BG, Packet Core FW and TA. For information on supported NE releases, please see Packet Core in NetAct Compatibility and Capacity Information. For further instructions on installing the NE software package, see Installation instructions provided with the NE delivery. Before you start the integration

Before you start the integration, ensure the following: •

The username and password for accessing the network element (NE) are available.

•

NE has been integrated to Packet Core IP network.

•

The IP address of the NE is known for Nokia Voyager management.

•

GPRS domain name and IP addresses for GPRS Name Servers are available.

•

The correct versions of the NE and IPSO have been installed.

For information on the versions of the packet core network elements supported by Nokia NetAct, see Packet Core in NetAct Compatibility and Capacity.

20 (100)


DN00297251 Issue 7-1 en


3.1.2.1

Verifying the versions

Note In the following, the figures of 3G SGSN are used as an example. Other NEs are presented only if they have different instructions.

Note With version SGN4, all http connections can be replaced with https connections depending on the configuration.

To connect to the network element If the IP address of the NE is known, do the following: 1.

Connect to Nokia Voyager with the username admin and your password.

2.

Select Config.

To check the NE version 1.

Connect to NE with Nokia Voyager.

2.

Select Manage Installed Packages from System Configuration. The Manage Packages page opens.

DN00297251 Issue 7-1 en


21 (100)


Figure 5.

Checking the NE version

To check the IPSO version 1.

Connect to the NE with Nokia Voyager.

2.

Select Manage IPSO Images from System Configuration. The IPSO Image Management page opens.

Figure 6.

22 (100)

Checking the IPSO version


DN00297251 Issue 7-1 en


3.1.3

CG, GNS, and DHCP server Apart from what is presented in Section 2.2.2 Integration procedure for CG, GNS and DHCP server, there are no specific system requirements for CG, GNS, and DHCP server before the actual configuration.

3.1.4

BIG-IP The following BIG-IP versions are supported: •

4.5 PTF6/PTF7

•

4.5 PTF8

•

4.5.9

•

9.1

•

9.1.1

For the BIG-IP versions 4.5 PTF6 and PTF7 you need to have the HotFixC119009.tgz installed on the BIG-IP, and for the BIG-IP version 9.1 you need to have the HotFix-CR54731 installed on the BIG-IP. You can obtain the hotfixes from the supplier F5 on request.

3.1.5

Routers

Note The following instructions are valid for Cisco routers only. Before you start the integration, ensure the following: •

The username and password for accessing router are available. For the username and passwords for the enable and configure mode, contact the router administrator.

DN00297251 Issue 7-1 en

•

Router has been integrated to Packet Core IP network.

•

The IP address, the host name, and the version of the router are available and configured correctly.

•

Router is configured for Telnet access.


23 (100)


To interrogate the version of a router 1.

Open a Telnet session to router.

% telnet

where is the name or the IP address of the router. 2.

Enter the username and password for router.

3.

Switch to the enable mode by entering:

>

4.

enable

Interrogate router version by entering:

# show version

The output of the command shows the version of the router and other information, for example, the host name and the amount of memory. 5.

Enter the password for the enable mode.

6.

Switch to the configure mode by entering:

#

7.

3.1.6

configure terminal

Enter the password for the configure mode.

Content Analyser CA is running on FlexiServer platform, for information on system requirements, see Section Nokia FlexiServer platform in Integrating FlexiServer Network Elements to NetAct.

3.1.7

SGSN For information on Reviewing the system requirements related to SGSN, see Integrating SGSN to NetAct.

24 (100)


DN00297251 Issue 7-1 en


3.2

Adding managed objects to DNS DNS (Domain Name Service) is a distributed database that contains naming information about network elements. The system provides the service of converting host names into IP addresses and the other way round. Before you add network elements to DNS, familiarise yourself with DNS management concepts and the lists of required zones presented in DNS Management Principles. When integrating a new PaCo network element to Nokia NetAct, you need to add the IP address and hostname of the network element to PaCo/GPRS zone, for example, mnc003.mcc262.gprs or paco.netact.done.fi. The selected zone depends on the fact whether the management and user planes in PaCo network are combined or not. The IP address added to DNS must be the IP address of the NE O&M interface. For information on DNS management, see DNS Management Principles. For information on how to move GNS-managed zones, see A Moving GNSmanaged zone(s) under the management of the NetAct DNS. If you have NameSurfer included in your NetAct software delivery DNS server. The alternative for NameSurfer is BIND. With BIND you need to use a text editor to add the elements to DNS.

Note If you are unsure whether the primary Name Servers are implemented with BIND or NameSurfer in your system, log into System Server and enter: # ls /opt/namesurfer

If the directory is found, the software is installed on your System Server. In the Top-level User Interface, click Utils → System Mgmt → DNS Manager... to start the application.

DN00297251 Issue 7-1 en


25 (100)


3.2.1

Adding a PaCo NE to DNS using NameSurfer If you have NameSurfer included in your NetAct software delivery package, you need to carry out the tasks listed in this section using web-based GUI of NameSurfer and a text editor.

Note Before continuing, ensure you are familiar with DNS solution architecture where the primary NS is implemented with NameSurfer that works with several secondary NSs implemented with BIND. For more information, see chapter Configuring DNS with NameSurfer as primary Name Server in Managing the DNS with NetAct. The exact configuration procedure depends on the cluster (Regional/Global) where the primary Name Server is located. The primary NS can be located in a different NetAct cluster than where the NE is integrated. For more information, see chapter Name Servers and zones in the NetAct system in DNS Management Principles. When NameSurfer is used as the primary DNS server, you must also configure BIND as the secondary Name Server. In practice, this means adding PaCo zone (“slave”) to the named.conf file in the /etc directory on the cluster servers. This must be done in the cluster where the primary NS is located and in the cluster where the NE is integrated (if not the same) as shown in the figure below.

26 (100)


DN00297251 Issue 7-1 en


Secondary NSs (BIND) in the cluster where the new NE is integrated to are configured as "slaves"

RC2 RC1 GC

Primary NS "master"

Secondary NSs Configured as "slaves"

System Component Server

NameSurfer

BIND (named)

BIND (named)

System Server

Database Server

New NE

Integrated NEs

Figure 7.

Adding a NE to DNS using NameSurfer as the primary NS

The following figure illustrates the configuration tasks.

DN00297251 Issue 7-1 en


27 (100)


Are the domain, primary and secondary NS known?

No

Locating primary Name Server

Yes

Have the forward zones been created?

No

Create the zone

Configure secondary BIND Name Servers Yes Add the host to the forward zone

Figure 8.

Verify the DNS configuration

Adding hosts to PaCo forward zone with NameSurfer

Preliminary tasks

Before adding the objects to the forward zone, check the following: •

The domain (for example, mnc003.mcc262.gprs or paco.netact.done.fi), used for the management of PaCo NEs is known. The correct domain depends on the IP topology of the PaCo network, that is whether the management and user planes are combined or separated in the network. For instructions on selecting the correct domain, see section Different IP topologies in a network in chapter Name Servers and zones in the NetAct system in DNS Management Principles.

•

28 (100)

The primary and secondary Name Servers are known. For instructions on locating Name Servers, see section Locating Primary Name Server in DNS Management Principles.


DN00297251 Issue 7-1 en


3.2.1.1

•

The forward zones have been created for the primary and secondary Name Servers. For instructions on creating zones, see sections Creating the zones (in chapter Configuring DNS with NameSurfer) and Configuring secondary BIND Name Servers in Managing the DNS with NetAct.

•

If you created the forward zone, check whether the it is available. For instructions, see section Verifying the DNS configuration (in chapter Configuring DNS with NameSurfer) in Managing the DNS with NetAct.

Adding a host to PaCo forward zone with NameSurfer

When adding a new host to PaCo zone, you need to add the host’s IP address and name to the Domain Name Service (DNS).

To add a host to PaCo forward zone 1.

2.

For instructions, see section Host (A) (in section Using NameSurfer to edit data in DNS) in Managing the DNS with NetAct. When you fill in a host name and the IP address of the network element, you need to fill in the following values for each Packet Core network element you are adding: •

IP address of the O&M unit

•

DNS zone, for example paco.netact.done.fi

•

name of the object (NE), which is given as

If you are integrating Charging Gateway version CG4.3, you also need to: •

add the hostname of the Admin Server in Charging Gateway to the DNS forward zone

•

create alias ems- for the admin server, where the is the hostname of the admin server.

For example, if the hostname of the Admin Server in CG is cgadmin.nss.netact.done.fi, and its IP address is 10.1.2.3, the DNS should have following entries:

Table 1.

DNS entries example

Name

Class

Type

Data

cgadmin.nss.netact.done.fi

IN

A

10.1.2.3

ems-cgadmin.nss.netact.done.fi

IN

CNAME


DN00297251 Issue 7-1 en


29 (100)


3.

3.2.2

Go to Section 3.3 Creating managed objects for Packet Core NEs.

Adding a Packet Core NE to DNS using BIND When BIND is used as the primary DNS server, you must also configure BIND as the secondary Name Server. In practice, this means adding PaCo zone to the named.conf file in the /etc directory on the cluster servers (SS and DS). This must be done in the cluster where the primary NS is located and in the cluster where the NE is integrated (if not the same) as shown in the following figure.

30 (100)


DN00297251 Issue 7-1 en


Secondary NSs (BIND) in the cluster where the new NE is integrated are configured as "slaves"

RC2 RC1 GC

Primary NS Configured as a "master"

System Component Server

BIND (named)

BIND (named)

System Server

Database Server

Secondary NS Configured as a "slave"

New NE

Integrated NEs

Figure 9.

Adding a NE to DNS using BIND as the primary NS

Note The exact configuration procedure depends on the cluster (Regional/Global) where the primary Name Server is located. The primary NS can be located in a different NetAct cluster than where the NE is integrated. See section Name Servers and zones in the NetAct system in the document DNS Management Principles. The following figure illustrates the configuration tasks.

DN00297251 Issue 7-1 en


31 (100)


Are the domain, primary and secondary NS known?

No

Locating primary Name Server

Yes

Have the forward zones been created?

No

Create the zone

Configure the secondary Name Server as slave Yes Add the host to the forward zone

Figure 10.

Verify the DNS configuration

Adding hosts to PaCo forward zone with BIND

Preliminary tasks

Before adding the objects to the forward zone, check the following:

32 (100)

•

The domain (for example, paco.netact.done.fi), the primary and secondary Name Servers are known. For instructions on locating Name Servers, see section Locating primary Name Server in DNS Management Principles.

•

The forward zones have been created for the primary and secondary Name Servers. For instructions on creating zones, see sections Creating the zones (in chapter Configuring the DNS with BIND as primary Name Server) and Configuring the secondary Name Server as slave in Managing the DNS with NetAct.

•

If you created the PaCo forward zone, check that the forward zone is available. For instructions, see section Verifying the DNS configuration (in chapter Configuring the DNS with BIND as primary Name Server) in Managing the DNS with NetAct.


DN00297251 Issue 7-1 en


3.2.2.1

Adding a host to Packet Core forward zone

To add a host to PaCo forward zone 1.

Increase the serial number. For instructions, see Start of Authority (SOA) in Managing the DNS with NetAct.

2.

If you are integrating Charging Gateway version CG4.3, you also need to: •

add the hostname of the Admin Server in Charging Gateway to the DNS forward zone

•

create alias ems- for the admin server, where the is the hostname of the admin server.

For example, if the hostname of the Admin Server in CG is cgadmin.nss.netact.done.fi, and its IP address is 10.1.2.3, the DNS should have following entries:

Table 2.

DNS entries example

Name

Class

Type

Data


IN

A

10.1.2.3

ems-cgadmin.nss.netact.done.fi

IN

CNAME


3.

Add the host to the zone. For instructions, see Host (A) in Managing the DNS with NetAct.

For more details, see appendix Example of forward zone file in the document DNS Management Principles. When you have added all the required entries, go to Section 3.3 Creating managed objects for Packet Core NEs.

3.3

Creating managed objects for Packet Core NEs Before Nokia NetAct can receive and store network element data, you have to create Packet Core NEs in NetAct database. For more information on managed objects and their hierarchy, see Managed Object Reference.

DN00297251 Issue 7-1 en


33 (100)


In addition, you must manually upload Packet Core NEs for performance management (PM) objects when you have created an object with Network Editor. To customise Packet Core PM Object Upload, you have to check an additional cron job entry and modify it if the default upload schedule is changed.

To create managed objects for Packet Core NEs 1.

Check Managed object reference to find out which MOCs you have to use for creating the MO for the NE you are integrating to NetAct.

2.

Find the parent object for the MO you are creating. For information, see NetAct object hierarchy for Packet Core objects in Managed Object Reference.

Note CG objects can be integrated either under PLMN or GPST objects. However, to ensure consistent PM reporting, it is recommended that you create all CG MOs under the same parent MOC, either PLMN or GPST.

Note Flexi ISN MO does not exist as a separately defined object type. You need to model the object on the GGSN object, depending on the Flexi ISN version; Flexi ISN 2.0 is integrated as GGSN 4.1 and Flexi ISN 3.0 is integrated as GGSN FI3.0.

3.

Find a view in Network Editor that contains the parent object and select the parent object.

4.

In Network Editor, open the pop-up menu of the parent object and select Add New Child → . The Creating an Object dialog appears.

34 (100)


DN00297251 Issue 7-1 en


Figure 11.

Creating an Object dialog for SNMP MOs with community strings

If you are integrating an FW managed object, click the Select... button in the Maintenance Region pane, and select the Maintenance Region associated with Graphical User Interface Server on which Checkpoint FireWall-1 software for the FW object is running.

Note You need to update the Version attribute each time your NEs are upgraded to a later version to keep your Nokia NetAct system functional. The following table describes all GPRS and 3G NEs supported by Packet Core Adaptation, and provides the mapping information between the NEs and the MOCs. The table includes only MOCs that refer to Packet Core NEs that physically exist and raise alarms. You have to instantiate these NEs and integrate them to the topology system. All the other MOCs, such as the generic interfaces, are only created for performance management purposes, and are not listed in the table because they are not integrated to NetAct topology system.

DN00297251 Issue 7-1 en


35 (100)


Table 3.

Mapping between Packet Core network elements and managed object classes

GPRS network element

Description

Managed object class, ID

3G SGSN

3rd Generation Serving GPRS Support Node.

SG3G, 474

Connects the WCDMA radio access network (RAN) to the Mobile IP packet core network. BG

Border Gateway.

BG, 461

Ensures a secure connection between GPRS / 3G Packet Core networks of various operators. BIGI

Big IP Adaptation

BIGI, 1214

Big IP is a traffic management solution for local area application. It ensures high availability, reliability, security, and scalability for Web applications. CA

Content Analyser

CA, 1239

CA is an engine to run mass scale browsing business with the operator’s own or third-party content. CG

Charging Gateway.

CG, 451

Collects the accounting information in the GPRS / 3G Packet Core network. DHCP server

Dynamic Host Configuration Protocol server.

DHCP, 473

Assigns dynamic IP addresses to the users.

36 (100)

DNS, (primary) Name Server

A primary Name Server, which updates mappings between IP addresses and symbolic names stored in the secondary Name Servers.

NS, 455

DNS, secondary GPRS Name Server

Secondary GPRS Name Server.

GNS, 456

Ethernet switch

Ethernet switching module for powerful switching in high-performance IP Packet Core networks.

IPSW, 459

Firewall

Server that prevents unauthorised access to protected networks.

FW, 457

Updated by the primary Name Server with nameaddress mappings.


DN00297251 Issue 7-1 en


Table 3.

Mapping between Packet Core network elements and managed object classes (Continued)

GPRS network element Flexi ISN

Description A carrier-grade platform incorporating GGSN and advanced service aware functionality. A gateway between wireless data networks and the Internet. Flexi ISN does not have an object of its own yet. Instead it is modelled with the managed object of GGSN, version depending on the version of the Flexi ISN (GGSN v.4.1 for Flexi ISN 2.0 and GGSN FI3.0 for Flexi ISN 3.0).

Managed object class, ID No separately defined object type of its own yet. Modelled on GGSN object.

Frame Relay Bearer Channel

A user access channel for frame relay data traffic.

FRBC, 464

Generic GPRS BB NE

Generic GPRS backbone network element.

GGNE, 460

GGSN

Needs to be modelled and does not have a separately defined object type of its own. Gateway GPRS Support Node.

GGSN, 454

Forms the gateway to external networks while hides the GPRS infrastructure from them. GGSN Interface

Network Interface for the GGSN with an IP address.

GGIF, 466

GPRS Name Server

Secondary GPRS Name Server used in GPRS Packet Core networks.

GNS, 456

GPRS site

Site object are used for grouping the managed objects located on one site.

GPST, 453

IP Interface

Additional IP address for IP-based equipment.

IPIF, 472

Managed object located under MCHU, PAPU, BG, FW, GGNE, GGSN, GNS, IPSW, LIB, LIC, NS, CG, DHCP, and SG3G.

DN00297251 Issue 7-1 en

IP Switch

See Ethernet switch.

IPSW, 459

Lawful Interception Gateway, LIG

In the Nokia implementation, the LIG consists of two separate network elements:

LIB, 467

•

Lawful Interception Controller (LIC)

•

Lawful Interception Browser (LIB)


LIC, 468

37 (100)


Table 3.

Mapping between Packet Core network elements and managed object classes (Continued)

GPRS network element Location areas

MCHU

Description

Managed object class, ID

Location areas are identified by associations between Visitor Location Registers (VLRs) and location areas. Such an association can be integrated as a managed object under SGSN.

VLA, 470

Marker and Charging Unit.

MCHU, 566

(VLR-LA association)

A functional unit of the SGSN. Its main tasks are marking, configuration management, and collecting charging data. Network Service Virtual Connection

An end-to-end virtual communication path between peer entities dealing with network services.

NSVC, 465

Packet Core network

Packet Core backbone network.

GPBB, 452

Packet Core Subnetwork

Subnetwork object to which Packet Core objects can be associated so that they are grouped together in a single MO.

PACO, 475

Such an association is not a parent-child or containment relationship. No alarms arrive in the Packet Core object from the associated MOs. PAPU

Packet Processing Unit.

PAPU, 462

Functional unit of the SGSN used for packet processing. Converts GPRS backbone protocols to BSS protocols. All BTSs that belong to the same routing area are controlled by the same PAPU. PCM line

2-Mbit trunk interface.

PCM, 15

Router

For integrating router equipment, use CiscoWorks2000 and the standard documentation set that accompanies the product.

RTR, 127

TA

Traffic Analyser.

TA, 1240

Nokia ISN Traffic Analyser (TA) 3.0 is an IP router.

38 (100)

VLR-LA association

Association between the VLR and the location areas that identify location areas.

VLA, 470

WA

Wireless Accelerator.

WA, 1301


DN00297251 Issue 7-1 en


3.3.1

SNMP-specific attributes for managed objects The technology-specific attributes for SNMP-managed NEs are included on SNMP MO pane as presented in figure 11 Creating an Object dialog for SNMP MOs with community strings. •

Main Hostname and IP General hostname and IP address of the NE.

Note If you have added the hostname(s) and IP address(es) of the NE to DNS as described in Section 3.2 Adding managed objects to the DNS, you do not need to specify the IP address(es) here; the hostname(s) are sufficient. •

Get/Set UDP Port UDP Ports of the NE for the get and set SNMP operations. The ports must be the same as the ports on the NE.

Note The community strings created into an NE at this point must match those values which were set to NetAct during object creation. •

Get Community The get community string of the NE, which is a type of password that is necessary for performing the get SNMP operation. To enable the reliability service of traps, the get community string for LIG has to be configured when creating a managed object.

•

Set Community The set community string of the NE, which is a type of password that is necessary for performing the set SNMP operation. The Creating an Object dialogs for Packet Core MOCs LIC, LIB, and NS do not contain text fields for the get and set community strings. The following figure shows their dialog.

DN00297251 Issue 7-1 en


39 (100)


Figure 12.

Creating an Object dialog for SNMP MOs without community strings

The Network Editor knows from the information on MOCs stored in Topology Database whether the MO has another SNMP object as parent object, and selects the correct Network Editor dialog and its default values accordingly. When you are creating an MO for a Packet Core NE, you need to specify the following attributes in the Network Editor dialog after checking the correct values from the actual configuration of the NE. The following table shows some example values.

Table 4.


Technology-specific attributes

Example values

Main Hostname

Border_Gateway_003

IP (selected automatically if NE integrated with DNS)

172.13.222.14

40 (100)


DN00297251 Issue 7-1 en


Table 4.


Technology-specific attributes

Example values

Get/Set UDP Port

161

Get Community (not applicable to LIC, LIB, NS objects)

public

Set Community (not applicable to LIC, LIB, NS objects)

private

3.4

Checking Maintenance Region Service Users in NetAct The following table presents the users that need to exist in NetAct before you can start integrating Packet Core NEs. To ensure the required MR service users with correct properties have been created in NetAct, you need to use Service User Management application to check and/or create the users listed in the table.

Note In SGN4 the password for the user account has to be changed regularly. It is important to update the password for the user for http access in Service User Management application as soon as it changes on the 3G SGSN side.

Note An MR service user is created only once for each MR. If the new NE that is being integrated is put to an MR that already contains a similar type of NEs, the MR service users presented here must already exist.

Note SNMP Get and SNMP Set community string information has to be set via the

Network editor during the time when the managed object is created. This information is used for getting read and write access to managed objects which are integrated via SNMP. Although SNMP Get and SNMP Set information is not set by creating Service users via SUM, NetAct stores and uses it in a similar way. For more information, see System Administration Principles. For more information on user management and Maintenance Regions, see Managing Users and Service User Management Help.

DN00297251 Issue 7-1 en


41 (100)

42 (100)

Table 5.

Maintenance Region Service users needed during PaCo integration


MR service users and username dependencies

Examples of an MR service user’s username

Username can be freely selected but a matching local user must exist in GGSNs inside the same MR

ne3suser

Freely selectable

fwgui

Service Type and profile

Connected to NetAct user group

Password can be freely selected but it must be identical as used for local “ne3suser” in all GGSNs in the same MR

Generic NE FTP ACCESS

sysop, all

Freely selectable

Programmatic PC Access

sysop

Password dependencies

groups with users of AoM

For example, needed for

MR

MO

MR of GGSN

GGSN

Administration of Measurements

FW or GUIS’ MR

FW

Checkpoint FW GUI Integrating Packet Core Network Elements to NetAct

DN00297251 Issue 7-1 en


Checking MR service users in GGSN

The following needs to be done in order to use Administration of Measurements.

Checking Maintenance Region Service users in GGSN 1.

From Service User Management application, ensure that a service user has been created in the Maintenance Region of GGSN, and its Service Type and Profile is set to Generic_NE_FTP_Access. The service user must be included in the sysop UNIX user group in NetAct.

2.

From Service User Management application, ensure that the username and password for the MR service user (with Generic_NE_FTP_Access) and the local service user in GGSN (for example, the ne3suser user) match. For instruction on creating users in GGSN, see section Configuring Security and Access in IPSO3.6 NET Voyager Reference Guide FCS11. After creating and connecting these service users, basic NetAct features (such as EM, FM, and PM) between NetAct and the NE are working for the unix user group mentioned above. To ensure that other features (like software download or upload) are working, see Service types in System Administration Principles.

3.5

Checking the DNS configuration The IP addresses of the primary and secondary Name Servers and the name of the GPRS domain are configured so that the DNS queries are forwarded to the correct Name Server. DNS needs to be configured for the following network elements:

DN00297251 Issue 7-1 en


43 (100)


•

GGSN

•

3G SGSN

Note With version SGN4, all http connections can be replaced with https connections depending on the configuration.

Note All domain names and IP addresses shown below are examples and must not be copied to your system.

To check DNS configuration in GGSN and 3G SGSN 1.

Open Nokia Voyager

2.

Click Config on the homepage of the GGSN or 3G SGSN.

3.

Click the DNS link in the System Configuration section. The DNS configuration page opens.

Figure 13.

44 (100)

Configuring DNS for Packet Core NEs


DN00297251 Issue 7-1 en


4.

If undefined, fill in the following values: APN domain name IP address of GNS1 (GPRS Name Server

1) IP address of GNS2 (GPRS Name

Server 2)

DN00297251 Issue 7-1 en

5.

Click Apply and Save.

6.

Click Home.


45 (100)


46 (100)


DN00297251 Issue 7-1 en

Configuring a Nokia IP Platform based NE

4

Configuring a Nokia IP Platform based NE This chapter describes the configuration of the Nokia IP Platform-based network elements.

4.1

Checking the IP configuration

To check IP configuration 1.

Open Nokia Voyager.

2.

Click Interfaces from Interface Configuration. The Interface Configuration window opens.

Figure 14.

DN00297251 Issue 7-1 en

Checking IP configuration


47 (100)


4.2

3.

Verify that the IP address of the interface to NetAct is configured.

4.

Click Up.

5.

Click the OSPF link in Routing Configuration.

6.

Verify that OSPF routing is configured to Packet Core IP network.

7.

Click Up.

Configuring a static route Static routes are used by the NEs to send data directly to NetAct using a specific path. Configuring static routes is the best way to ensure that all packets will be sent directly to their destination. To provide IP packet routing between the NE and Nokia NetAct, you must configure the static route. The initial configuration of the static route cannot be done remotely from NetAct. To perform the task, you need to connect and start a Nokia Voyager session to the NE from a PC, for example, that is located in the same subnet with the NE.

To configure static route 1.

Open Nokia Voyager.

2.

Click Config.

3.

From Routing Configuration list, click Static Routes. The static routes configuration window opens.

48 (100)


DN00297251 Issue 7-1 en


Figure 15.

4.

Configuring static route

Add the static route by filling in the following values: IP address of the NetAct network The number of bits in the subnetwork mask of router, see /etc/rc.config.d/netconf For example, a Class B subnetwork mask uses 16 bits. normal address

4.3

5.


6.

Click Home.

Configuring network time protocol (NTP) Network Time Protocol (NTP) is a TCP/IP based time management protocol used to synchronise the clocks of IP hosts with an external time source (such as a Global Positioning System (GPS) or radio clock).

DN00297251 Issue 7-1 en


49 (100)


NetAct receives its reference time from an operator maintained NTP server. The NEs NetAct manages can either retrieve the time from NetAct or from the operator maintained NTP server. For more information on time management in NetAct, see Time management in System Administration Principles. The reference time is used in the NEs for time stamps and event logging. NTP needs to be configured in the following IP Platform based NEs: •

GGSN

•

3G SGSN

•

Border Gateway (BG)

•

Lawful Interception Gateway (LIG)

•

Traffic Analyser (TA)

To check the time zone 1.

Open Nokia Voyager.

2.

Click Config.

3.

Click the Local time setup link in the System Configuration section. The time setup window opens.

Figure 16.

50 (100)

Selecting a time zone


DN00297251 Issue 7-1 en


4.

Select the time zone you want to use. Do not set the time manually.

5.


6.

Click Home.

7.

Configure NTP.

Note Local time zone can be verified at the same time when NTP is configured. 1.

In Nokia Voyager view select Config.

2.

Select Local time zone under the System configuration section.

To configure NTP 1.

Open Nokia Voyager.

2.

Click NTP link in the Router Services section.

3.

Click NTP service in NTP Global Settings. The NTP configuration window opens.

DN00297251 Issue 7-1 en


51 (100)


Figure 17.

4.

Configuring NTP for Packet Core NEs

Enter the IP addresses of the new NTP servers based on your network setup in the Add new server: Address: edit box. Accept the default settings: 1.

Type in System Server’s IP address or the external NTP server’s IP address and click Apply. By default, the new server is enabled, v3 is selected, and the Prefer Yes radio button is selected.

2.

Type in Database Server’s IP address, and click Apply. By default, the new server is enabled, v3 is selected, and the Prefer No radio button is selected.

52 (100)


DN00297251 Issue 7-1 en


As NTP servers, add the following IP

addresses with the attributes given in parenthesis: 1. System Server, if reference time is retrieved from NetAct/External NTP server (: on, Prefer: yes, Version: v3) 2. Database Server, if reference time is retrieved from NetAct/Backup for the external NTP server (: on, Prefer:no, Version: v3) Optional Optional

4.4

5.


6.

Go to Section 4.4 Configuring SNMP.

Configuring SNMP SNMP is an application layer protocol that enables the SNMP management station to communicate with an SNMP agent (NE). After SNMP parameters are configured, Nokia NetAct is able to perform a full range of management functions on the NE SNMP needs to be configured in the following network elements:

DN00297251 Issue 7-1 en

•

GGSN

•

3G SGSN

•

Border Gateway (BG)

•

Packet Core Firewall


53 (100)


•

LIG

•

TA

Note When configuring SNMP, in Step 6 need not be configured for LIG.

Note When configuring SNMP for 3G SGSN, the SNMP version depends on the 3G SGSN version. With version SGN3 onwards, the SNMP version used is 2c, while with the previous SGN versions (SGN2) the SNMP version used is v2.

To configure SNMP 1.

Open Nokia Voyager.

2.

Select Routing Instance. This step applies only to the GGSN, in other NEs proceed to the next step.

3.

Click Config on the homepage.

4.

Click SNMP.

5.

Tick the checkbox on Yes radio button in the Enable SNMP Daemon field and click Apply. SNMP configuration window opens. The following figure shows an example of configuring SNMP for 3G SGSN.

54 (100)


DN00297251 Issue 7-1 en


Figure 18.

DN00297251 Issue 7-1 en

Configuring SNMP for Packet Core NEs (top part)


55 (100)


Figure 19.

6.

Configuring SNMP for Packet Core NEs (bottom part)

Fill in the following fields:

The string has to be identical in NetAct and NE.

The string has to be identical in NetAct and NE. IP address of osscore2 on

Enable all traps. The number of traps varies according to network element type. IP address of the network element

interface towards NetAct Optional Optional

7.

56 (100)



DN00297251 Issue 7-1 en


8.

Click Home.

9.

Go to Section 3.5 Checking the DNS configuration.

Note SNMP alarms must be enabled in the LIG application. For more information on initialising or changing alarm transfer settings refer to section Initialising or changing alarm transfer settings of the Administrator in Chapter LIG alarms overview in Release 4 Nokia Lawful Interception Gateway Reference Guide.

4.5

Setting measurement data file format for GGSN If the version of the GGSN is 4.1 or later, you need to do the following to set the measurement data file format.

To set the measurement data file format for GGSN 1.

Go to the Nokia Voyager.

2.

From the main page in GGSN, select the Routing Instance section.

3.

Instances Config and Monitor are available. Click on the Monitor instance.

DN00297251 Issue 7-1 en

4.

Select section Performance Management.

5.

You have two options for the OMeS file: 1.0 and 2.0.

6.

Select 2.0 and click Save.

7.

Click Apply.


57 (100)


58 (100)


DN00297251 Issue 7-1 en

Configuring HP-UX based Network Elements

5

Configuring HP-UX based Network Elements This chapter describes the configuration of Charging Gateway, DHCP Server and GNS.

5.1

Configuring Charging Gateway This section describes the SNMP performance management and Alarm Interface configuration for Charging Gateway. The following procedures apply to Charging Gateway versions 4.0 and 4.3. For information on configuring CG 3.0 version, see Chapter Configuring CG 3.0 in document Installing CG, available in Nokia Charging Gateway, Rel 3.0 Product documentation.

5.1.1

Configuring HP-UX SNMP agent The following procedure describes how to configure an HP-UX SNMP agent. The Charging Gateway specific tasks are presented in the 5.1.2 Configuring Charging Gateway SNMP agent.

To configure SNMP performance management 1.

DN00297251 Issue 7-1 en

Edit file /etc/SnmpAgent.d/snmpd.conf: 1.

Set get-community-name and set-community-name according to the SNMP community string values set to the NE’s managed object in NetAct.

2.

Set trap-dest to be IP address of the osscore2 SG-package.

3.

Set max-trap-dest to 1.


59 (100)


The following is an example of the NetAct related part of the /etc/SnmpAgent.d/snmpd.conf file: get-community-name: public set-community-name: sGoH0P9J max-trap-dest: 1 trap-dest: 10.8.58.183

Figure 20.

2.

Example of the NetAct related part in the file /etc/SnmpAgent.d/snmpd.conf

Ensure that the snmpdm service is running by entering: # ps -ef | grep snmpd

Resulting output should be as in the following example:

root

851

1

0

Mar

3

?

91:39 /usr/sbin/snmpdm

To stop the snmpd, enter command: /sbin/init.d/SnmpMaster stop

To restart the snmpd, enter command: /usr/sbin/snmpd

5.1.2

Configuring Charging Gateway SNMP agent

To configure SNMP performance management 1.

60 (100)

Edit the snmp.conf file in /opt/cg/4.0/net-snmp/etc/snmp/:


DN00297251 Issue 7-1 en


rocommunity public rwcommunity sGoH0P9J proxy -v 1 -c public \ localhost:163 .iso.org.dod.internet.private.enterprises.hp

Figure 21.

Example of the NetAct related part in the file /opt/cg/4.0/netsnmp/etc/snmp/snmpd.conf.

Note When you are configuring CG version 4.3, replace the 4.0 with 4.3 in the path.

Note The get-community-name matches with rocommunity and setcommunity-name matches with rwcommunity in the examples. 2.

Stop and start the net-SNMP agent. Stop net-SNMP agent: 1.

Login as cg user.

2.

Enter the following command: $CG_HOME/net-snmp/sbin/stop.sh

Start net-SNMP agent: 1.

Login as cg user.

2.

Enter the following command: nohup $CG_HOME/net-snmp/sbin/start.sh

5.1.3

Configuring Charging Gateway Alarm Interface Nokia NetAct uses Charging Gateway SNMP Alarm Interface for fault management of CG versions up to 4.2. In CG version 4.3 NE3S interface is used for alarms. You need the IP address of the osscore2 package for configuring the interface.

DN00297251 Issue 7-1 en


61 (100)


To configure SNMP Alarm Interface for CG4.2 or older version 1.

Open the agent.conf.fm file, which is located in the opt/cg/4.0/mercury/ with text editor (e.g. vi). directory.

2.

Modify the line starting with text:

MANAGER=. # managers MANAGER=,,

Correct values:

= IP address of osscore2 SG-package

= Number of the snmpd’s port on NetAct side. Use default value 162.

= SNMP community string for traps. Currently it is not used by NetAct, therefore in practice any value can be inserted here, for example, public. 3.

Restart the SNMP agent with:

cd /opt/cg/4.0/mercury ./stopAgentFM.sh ./startAgentFM.sh

Note When you are configuring CG version 4.3, please see chapter Configuring the CG NE3S alarm interface for ESYMAC alarm agent in document Commissioning and Integrating Charging Gateway 4.3 (DN03385317) which is delivered in NOLS. Do not configure or start SNMP Alarm Interface if the CG version is 4.3.

5.1.4

Configuring the network time protocol (NTP) The following procedure describes how to configure the NTP on HP-UX platform based NEs, that is CG, DHCP and GNS.

62 (100)


DN00297251 Issue 7-1 en


Before you start The UNIX timezone must be set up correctly. 1.

Configure routing to the server(s) that will be used for time reference. For instructions, see Configuring LAN connections.

2.

Login as user root

3.

Stop NTP daemon. Enter:

/sbin/init.d/xntpd stop

4.

Add the address of the NTP server to, for example

/etc/rc.config.d/netdaemons

If there are two NTP servers export NTPDATE_SERVER=”10.8.1.1 10.8.1.2” The System Server (SS) is the preferred NTP server, and it has to be added as the first entry for NTPDATE_SERVER. The Database Server (DS) is added as the second entry for NTPDATE_SERVER. 5.

Add the address or the hostname of the NTP server to

/etc/ntp.conf

as, for example, server 10.8.1.1 prefer server 10.8.1.2

where System Server is the preferred NTP server, and Database Server the secondary NTP server. 6.

Restart NTP. Enter:

/sbin/init.d/xntpd start

7.

Verify the synchronisation. Enter:

ntpq -p

DN00297251 Issue 7-1 en


63 (100)


The synchronisation may take a couple of minutes. Current reference time servers are prefixed with *, other possible references are prefixed with +. The values of delay and offset should diminish.

5.2

Configuring DHCP server The following procedure describes how to integrate DHCP server to NetAct. Managed Object for DHCP server has to be created before the configuration.

To configure DHCP server

5.2.1

1.

Log in to the DHCP server.

2.

On DHCP server, make sure that the latest HP patches are installed. The up-to-date list of patches is available on the HP web site.

3.

5.2.1 Configure SNMP.

4.

5.2.2 Configure NTP.

Configuring SNMP For instructions on configuring SNMP, see section 5.1.1 Configuring HP-UX SNMP agent.

5.2.2

Configuring NTP For instructions on configuring NTP, see section 5.1.4 Configuring the network time protocol (NTP).

5.3

Configuring GNS In GNS configuration, you need to configure SNMP and NTP. For instructions, see sections 5.1.1 Configuring HP-UX SNMP agent and 5.1.4 Configuring the network time protocol (NTP). For moving the zones managed with GNS under the management of the NetAct DNS please refer to Appendix A Moving GNS-managed zone(s) under the management of the NetAct DNS.

64 (100)


DN00297251 Issue 7-1 en


You have to activate DNS polling for GPRS zones because this is not done automatically. For instructions, see chapter DNS polling in Managing the DNS with NetAct.

DN00297251 Issue 7-1 en


65 (100)


66 (100)


DN00297251 Issue 7-1 en

Configuring BIG-IP

6

Configuring BIG-IP This chapter provides the instructions you need for activating Nokia NetAct support for a BIG-IP network element. It also describes how you can set trap destinations and community strings for BIG-IP network element and how you enable SNMP.

6.1

Configuring BIG-IP 4.5 For integrating a BIG-IP 4.5 network element to Nokia NetAct, you need to have the version 4.5PTF7 (or later) installed and HotFix-C119009.tgz has to be installed on BIG-IP.

To configure BIG-IP 4.5 1.

Open a web browser and connect to BIG-IP network element https://bigip.operator.com

DN00297251 Issue 7-1 en

2.

From BIG-IP configuration utility click Configure your BIG-IP.

3.

Click System Admin under System category.

4.

Select SNMP administrator.

5.

Check the box to enable SNMP.

6.

Check the box to enable Nokia SNMP traps.

7.

Configure Client Access and System Information as if you were setting up a normal SNMP configuration (for specific instructions, see BIG-IP manual.

8.

In the Trap configuration pane define community name (by default “public”), service port number (by default “162”), and the IP address of the osscore2 SG package in the trap Sink box.


67 (100)


9.

Click Add to add the trap sink to the Current List.

10.

You need to perform different tasks if the configuration is a new configuration or an upgrade: 1.

If you are configuring BIG-IP for the first time to NetAct: In the /etc/syslog.conf file, enable the applicable facilities. These facilities allow log messages fro various sources to be routed to specific files or message handling applications. The F5 Networks software uses the following facilities: •

local0.*

•

local1.*

•

local2.*

•

auth.*

•

kern.*

The syslog utility sends messages to the /var/run/trapper log file, which BIG-IP continuously monitors for new input. 2.

Using a text editor, open the /etc/syslog.conf file and locate the lines near the bottom of the file that contain information similar to the following:

#/local0.* /var/run/trapper

3.

Remove the number (#) symbol from each of the facilities for which you want traps. The edited text must look as the following example:

/local0.* /var/run/trapper

•

If you are upgrading from the previous version of BIG-IP: Use the command line utility to replace the /etc/snmptrap.conf file with /etc/snmptrap.conf.example file as follows.

Note Back up the original snmptrap.conf file to snmptrap.conf.ORG before you overwrite it. cp /etc/snmptrap.conf.example /etc/snmptrap.conf

If you manually edited the original snmptrap.conf file (added new traps or removed old ones), you must make the same edits in the new file. The new syntax is described within the file.

68 (100)


DN00297251 Issue 7-1 en

Configuring BIG-IP

6.2

Configuring BIG-IP 9.1 For integrating a BIG-IP 9.1 network element to Nokia NetAct, you need to have the version 9.1 with HotFix-CR54731 or 9.1.1 (or later) installed on BIG-IP.

To configure BIG-IP 9.1 1.

Open a web browser and connect to the BIG-IP network element.

2.

In the BIG-IP configuration utility, click System.

3.

Select SNMP under System category.

4.

On the SNMP Agent configuration pane configure Global Setup and SNMP Access. Add Nokia NetAct IP address to the Client Allow list.

DN00297251 Issue 7-1 en


69 (100)


Figure 22.

70 (100)

SNMP Agent Configuration pane

5.

Click Traps → Configuration.

6.

Select the checkbox Agent Start/Stop.

7.

Select the checkboxes Agent Authentication and Device.

8.

Click Update to apply the changes.

9.

Click Traps → Destination.

10.

On the SNMP Destination pane, click Create to create a new trap destination.


DN00297251 Issue 7-1 en

Configuring BIG-IP

Figure 23.

11.

SNMP Destination pane

On the New trap record pane configure SNMP version, community name, IP address (destination), and Port number of the NetAct, and click Finished.

DN00297251 Issue 7-1 en


71 (100)


Figure 24.

New trap record pane

To enable BIG-IP to send NE3S (Nokia SNMP) traps, you need to perform the following tasks. Ensure that the BIG-IP network element is configured (tasks completed) before executing the steps described in the following.

To enable BIG-IP to send NE3S traps 1.

Establish an ssh connection to BIG-IP network element.

ssh -l root

2.

Enable Alertd.Nokia.Alarm. Execute the following command on the command prompt of BIG-IP.

# bigpipe db Alertd.Nokia.Alarm enable

72 (100)


DN00297251 Issue 7-1 en

Configuring BIG-IP

3.

Restart Nokia snmpd. Execute the following command on the command prompt of BIG-IP.

# bisgtart restart nokiasnmpd

4.

Restart alertd. Execute the following command on the command prompt of BIG-IP.

# bigstart restart alertd

DN00297251 Issue 7-1 en


73 (100)


74 (100)


DN00297251 Issue 7-1 en

Configuring a router

7

Configuring a router This chapter provides instructions on how to enable a router to send traps to Nokia NetAct and accept SNMP get requests from Nokia NetAct. It also describes how you can configure the types of traps a router sends to Nokia NetAct. For instructions on how to integrate a Cisco router, see Configuring a Cisco router and switch in Integrating DCN Backbone to NetAct. For the username and passwords that you need for implementing the following steps, contact the router administrator. Before you start integrating a router into Nokia NetAct, perform the preliminary tasks that are described in Chapter 3 Preliminary tasks for Packet Core NE integration.

7.1

Configuring SNMP for a router Note The following instructions are valid for the Cisco routers only. You can configure a router to send SNMP traps to Nokia NetAct when certain events occur. Nokia NetAct handles these traps as fault management events, which can be viewed in Alarm Monitor and are stored in the database of the network element that sent the original trap.

Note Ensure that the SNMP community strings are configured consistently in the router and in Nokia NetAct.

DN00297251 Issue 7-1 en


75 (100)


To configure SNMP for a router 1.

Open a Telnet session to the router.

% telnet

where is the name or the IP address of the router. 2.

Enter the username and password for the router.

3.

Switch to the enable mode by entering:

>

enable

4.

Enter the password for the enable mode.

5.

Switch to the configure mode by entering:

#

6. 7.

configure terminal

Enter the password for the configure mode. Configure the types of traps that the router sends and the IP address of osscore2 to which the router sends the traps.

# snmp-server enable traps config # snmp-server enable traps ds0-busyout # snmp-server enable traps ds1-loopback # snmp-server enable traps envmon # snmp-server enable traps frame-relay # snmp-server enable traps hsrp # snmp-server enable traps ipmulticast # snmp-server enable traps idsn # snmp-server enable traps msdp # snmp-server enable traps RTR # snmp-server enable traps rtr # snmp-server enable traps snmp # snmp-server enable traps syslog # snmp-server enable traps tty snmp-server host version 1 public snmp syslog tty config

76 (100)


DN00297251 Issue 7-1 en

Configuring a router

where is the IP address of osscore2 to which the router sends traps. 8.

Go back one level by pressing CTRL+Z.

9.

Save the configuration by entering:

# write memory

10.

DN00297251 Issue 7-1 en

Exit the Telnet session.


77 (100)


78 (100)


DN00297251 Issue 7-1 en

Providing users access to NetAct applications and network elements

8

Providing users access to NetAct applications and network elements To provide users of a group access to the network through the applications in NetAct, you need to check or create Maintenance Region service users and associate them with the service types the users in the group will need. For the NetAct applications to be able to use this MR service user, it must be connected with the user group. This connection allows the users in the group to access a network MR service user (for example Remote MML access or Generic NE FTP access). For the members of the group, the access to managed objects (NEs) will be transparent. To ensure the users have access to Network Elements, check if the Maintenance Region where this NE was added already contains the MR service users needed. For instructions on how to find out the kind of service types that are needed with a particular NE, see Service types in System Administration Principles. For instructions how to create user groups and set service accesses, see NetAct Permission Manager Help and Managing Service Users in Managing Users.

DN00297251 Issue 7-1 en


79 (100)


80 (100)


DN00297251 Issue 7-1 en

Verifying integration

9

Verifying integration This chapter describes how to verify NE integration to NetAct.

9.1

Nokia IP platform network elements This section provides information on how to verify IP platform based network elements.

9.1.1

Verifying IP connectivity After the network element has been installed and configured, check that the connection from NetAct is working properly. 1.

Ping the NE from NetAct.

2.

Open the Telnet or SSH connection from NetAct to the NE. Note that with version SGN4 Telnet can be disabled and only the SSH connection is available, depending on the configuration.

3.

9.1.2

Open the Element Manager from NetAct to the NE.

Verifying performance management data flow for IP platform network elements Check that PM data is arriving from the NE to NetAct.

Note Perform the check only for NEs which produce PM data and for which NetAct provides PM support.

DN00297251 Issue 7-1 en


81 (100)


To verify PM data flow 1.

Start a measurement with Element Manager of the NE. When you are verifying PM dataflow for GGSN, use AoM.

2.

Verify that measurements have arrived to NetAct database.

SQL> select count (*) from

measurement table A measurement table as defined in the database

description, and into which you are receiving PM data. 3.

Wait for a measurement time, depending on the NE, and give same command again.

4.

Stop the test measurements you just started.

See also Troubleshooting Performance Management Problems.

9.1.3

Verifying fault management data flow Check that FM data is arriving from the NE to Nokia NetAct.

To check the alarm flow from 3G SGSN Generate a test alarm from the NE to verify the FM data flow towards Nokia NetAct. Generate a test alarm from Voyager interface by disabling one idle/unused network interface temporarily in order to create alarm Interface down. If test alarms cannot be created safely from Voyager, they can also be created directly from the NE console interface. 1.

Open either Telnet or SSH connection to the NE with administrative account.

2.

Find a suitable alarm to be used in testing with the following command: dbget -irv fm:alarms:table |more

List of alarms supported by the NE is printed on the screen.

82 (100)

3.

Select some alarm from the list.

4.

Generate test alarm with the command:


DN00297251 Issue 7-1 en


fmc alarm 'Test_Alarm' `date`

9.1.4

5.

If the alarm is created successfully, the ID number of that particular alarm appears as an output to the NE console.

6.

Test_Alarm appears in the NetAct Alarm Monitor.

7.

After verifying the FM flow to NetAct, cancel the Test_Alarm. 1.

Login to Nokia Voyager → Config → Current Alarm List

2.

Enter alarm ID number to Cancel an alarm field and select Apply.

Verifying Configuration Management For testing the configuration management, there are some prerequisites: •

NetAct cluster including Packet Core management

•

Required NEs: FW, BG, GGSN, 3G SGSN NEs

•

archived SW package from /var/opt/nokiaoss/uma/admin/swarchive directory.

To test configuration management 1.

Download software package for a NE listed in prerequisites. In Top-level User Interface, select Element Software & Configuration Mgmt → Software Mgmt → Download Software Package ... from the pop-up menu of the NE.

9.1.5

2.

Give the requested information for the SW package to be downloaded.

3.

Check for example with Nokia Voyager that the SW package is downloaded and it is not activated yet. Open web browser with the IP address of NE, select config, select Manage IPSO images, and check that downloaded package is on the list of IPSO images.

Verifying Element Manager launch Check whether a managed object (MO) has been successfully integrated to Nokia NetAct, by starting an element manager application in Nokia Voyager from the icon for the MO in Top-level User Interface.

DN00297251 Issue 7-1 en


83 (100)


To start an element manager from an MO 1.

In Top-level User Interface, right-click the pop-up menu of the MO you want to check.

2.

Select an element manager (EM) application from the pop-up menu. For example, click SSH Session... for SSH. For a list of the available EMs for the various MOCs, see Table Aliveness supervision applications and EMs for Packet Core MOCs in Configuring Packet Core Adaptation. If the pop-up menu does not list any EMs, start Status Check... to perform a ping to the NE.

If launching the EM or executing Status Check is successful, the MO has been correctly integrated. You can exit the element manager application.

9.2

Nokia CG, DHCP server and GNS This section describes how to verify CG, DHCP Server and GNS.

9.2.1

Verifying performance management flow for CG, DHCP Server and GNS Check that PM data is arriving as presented in section 9.1.2Verifying performance management data flow for IP platform network elements.

9.2.2

Verifying fault management data flow for CG, DHCP Server and GNS Check that FM data is arriving with Alarm Monitor.

To check the alarm flow

84 (100)

1.

Open Alarm Monitor application in Nokia NetAct.

2.

Apply the Configuration Change trap (Enable systemTrapConfigurationChange traps) with Nokia Voyager.

3.

Click Apply twice.


DN00297251 Issue 7-1 en


4.

9.2.3

The Temporary Configuration change trap appears in Alarm Monitor.

Verifying configuration management for CG, DHCP Server and GNS For instructions on testing SW download, see 9.1.4 Configuration management for IP platform NEs.

9.2.4

Verifying Element Manager launch for CG, DHCP Server and GNS Check whether a managed object (MO) has been successfully integrated to Nokia NetAct by starting an element manager application from the pop-up menu of the MO in the Top-level User Interface.

To start an element manager from an MO 1.

In Top-level User Interface, right-click the icon of the MO you want to check.

2.

Select an element manager (EM) application from the pop-up menu. For example, click SSH Session... for SSH. For a list of the available EMs for the various MOCs, see Table Aliveness supervision applications and EMs for Packet Core MOCs in Configuring Packet Core Adaptation. If the pop-up menu does not list any EMs, start Status Check... to perform a ping to the NE (this is not available for all NEs).

If launching the EM or executing Status Check is successful, the MO has been correctly integrated. You can exit the element manager application. For troubleshooting instructions, see Troubleshooting System Management Problems, Troubleshooting Fault Management Problems and Troubleshooting Performance Management Problems.

DN00297251 Issue 7-1 en


85 (100)


86 (100)


DN00297251 Issue 7-1 en

Where to find more information

10

Where to find more information This document is meant to be used together with other Nokia NetAct documents. Nokia NetAct documentation

•

For more information on creating additional managed object classes with the Managed Object Class Adding Tool (MOECAT), see Configuring NetAct for 3GPP CORBA Northbound Interface.

•

For information on the integration of the different Packet Core and Radio Access network elements into the Data Communications Network (DCN), see Integrating FlexiServer Network Elements to NetAct and Integrating SGSN to NetAct.

•

For information on monitoring, see Monitoring Principles.

•

For information on Reporter and Performance Management, see Reporter and Performance Management Principles.

•

For more information on managed objects, see Managed Object Reference.

•

For general information on functionality and usage of Network Editor, see Network Editor Help.

•

For information on Alarm Monitor, TLUI, and Network Editor, see Alarm Monitor Help, Top-level User Interface Help, and Network Editor Help.

•

For information on troubleshooting, see Troubleshooting Fault Management Problems and Troubleshooting Performance Management Problems.

•

For instructions on DNS, see DNS Management Principles and Managing the DNS with NetAct

•

For information on configuring Cisco router and switch, see Integrating DCN Backbone to NetAct.

•

For information on firewalls, see Security Policy in NetAct Firewalls, available in NOLS.

Related non-NetAct documentation

•

DN00297251 Issue 7-1 en

NameSurfer documentation set


87 (100)


Related non-Nokia documentation

•

88 (100)

BIG-IP related documentation, available from f5 web-pages http://tech.f5.com (require authentication)


DN00297251 Issue 7-1 en

Moving GNS-managed zone(s) under the management of the NetAct DNS

Appendix A. Moving GNS-managed zone(s) under the management of the NetAct DNS This appendix describes moving zone(s) managed with GNS under the management of the NetAct DNS. DNS management related issues are covered in documents DNS Management Principles and Managing the DNS with NetAct.

DN00297251 Issue 7-1 en


89 (100)


GNS

NetAct DNS environment

Backup DNS data in the GNS

IF NameSurfer is primary Name Server THEN NO Transfer DNS zone data to new master Name Server

YES BIND based Check primary DNS IF Name Server has zones required by GNS THEN NO YES Create new zones as master for BIND primary

Check and modify zone contents

Create new zone master files

Change transferred zone types to slave

Re-start BIND process

Check IF all authoritative zones exist THEN

NO

YES Add zones

Re-start BIND process

BIND based slave DNS

Figure 25.

90 (100)

Change SOA Resource Record details for new zones

NameSurfer based primary DNS

Move zone contents

Modify SOA Resource records for new zones

Load new zones to NameSurfer from GNS

Zone transfer from GNS to NetAct DNS


DN00297251 Issue 7-1 en


A.1

GNS This section describes the procedures you need to carry out in GNS.

To make a full backup of BIND setup 1.

Log in to GNS as root user.

2.

Make a backup from the following files/directories: /etc/rndc.key /etc/named.conf etc/rndc.conf

3.

Make a backup also from the zone files in the path: var/named/

4.

Repeat steps 1 to 3 for all GNS that need to be modified.

To check the zones and the corresponding zone files in the GNS 1.


2.

Check the zones and the corresponding zone files with the command:

root% grep -e zone -e file /etc/named.conf

3.

A.1.1

Based on the command output the required zones and the corresponding zone files can be located from the GNS.

NameSurfer is not the primary Name Server

To transfer the DNS zone data to a new master Name Server when NameSurfer is not the primary Name Server 1.

DN00297251 Issue 7-1 en

Check all the zones and the corresponding zone files in the GNS you need to move to the primary Name Server in NetAct.


91 (100)


A.1.2

2.

Configure the primary Name Server in NetAct with the zones required by the GNS and copy the corresponding zone files to the primary Name Server in NetAct.

3.

Re-configure GNS BIND name server zones as slave for the primary Name Server in NetAct.

4.

Start integrating GNS and the zone data of the primary Name Server in NetAct according to the instructions on checking the zones and the corresponding zone files in the following.

NameSurfer is the primary Name Server When NameSurfer is the primary Name Server, go to procedure To update the Primary DNS in NetAct with NameSurfer.

A.2

NetAct DNS environment This section describes the procedures you need to carry out in NetAct DNS environment.

To check the primary DNS zone files in NetAct with BIND

A.2.1

1.

Login to OSS4 NetAct Primary Name Server in NetAct SS as root user.

2.

Compare the zones and zone files required by GNS with the zones and the zone files that BIND primary Name Server in NetAct has.

Name Server has zones required by GNS

To check and modify the zone contents 1.

92 (100)

Check the zone contents carefully to make sure that all required information is in the /etc/named.conf file.


DN00297251 Issue 7-1 en


Make sure to check if there is a resource record (RR) which needs to be modified or removed. Also there might be a new RR which has to be added.

Note Make sure to do the editing carefully, as any extra or missing information might cause the DNS to malfunction. 2.

Re-start BIND in SS with the command:

root% rndc reload

3.

A.2.2

Verify that all modified zones are updated with the correct Serial Number and that there are NO error messages in the /var/adm/syslog/syslog.log about the modified files.

Name Server does not have the zones required by the GNS

To create the primary DNS zone files in NetAct with BIND 1.

Create the corresponding zone statement(s) to the file /etc/named.conf

2.

Move the corresponding zone file under path /var/named/

3.

Modify the SOA resource record for new zones.

Note Make sure to do the editing carefully, as any extra or missing information might cause the DNS to malfunction. 4.

Re-start BIND in SS with the command:

root% rndc reload

5.

DN00297251 Issue 7-1 en

Verify that all modified zones are updated with the correct Serial Number and that there are NO error messages in the /var/adm/syslog/syslog.log about the modified files.


93 (100)


A.2.3

NameSurfer is the primary Name Server

To update the Primary DNS in NetAct with NameSurfer

The following instructions describe how to update the NameSurfer based primary Name Server in the Global Cluster

1.

Open NameSurfer Web UI by using the web browser and the corresponding URL as for example: http://:8053

2.

After successful login to the NameSurfer Web UI, check the zones and contents required by the GNS and compare those with the zones and the content of the zones.

3.

If NameSurfer has zone(s) required by the GNS there is no need to create new corresponding zones. However, check the zone contents carefully. Make sure to check if there is a resource record (RR) which needs to be modified or removed. Also there might be a new RR which has to be added.

Note Make sure to do the editing carefully as any extra or missing information might cause the DNS to malfunction. OR: If NameSurfer does not have the zone(s) required by the GNS, you need to create the corresponding zone(s) by copying it into the NameSurfer from GPRS Name Server: 1.

Open the NameSurfer Web UI by using the web browser and the corresponding URL as in the following example:

http://:8053

94 (100)

2.

After a successful login to the NameSurfer Web UI the Index page is displayed.

3.

Create new zone for NameSurfer by clicking Copy from other name server, which is under the Create zone on the left side menu.


DN00297251 Issue 7-1 en


4.

On the Copy from other name server page fill in: •

name of the zone, for example, mnc003.mcc262.gprs, onto the upper field of the page

•

IP address of the GNS, for example, 192.168.200.12, onto the lower field of the page

and click OK. 5.

On the Zone Root page modify the SOA Resource Record and authoritative Name Servers of the zones to the Zone Root page: •

Figure 26.

Modify Master NS and Admin email address of the SOA Resource Record as in the following:

Master NS and Admin email address of the SOA Resource Record

Note Start of Authority (SOA) object is defined in NameSurfer as in the following example.

Figure 27.

SOA object in NameSurfer

•

Figure 28.

DN00297251 Issue 7-1 en

Modify authoritative Name Server for the zone as in the following:

Authoritative Name Server for the zone


95 (100)


If the Zone Root page displays only one empty field for adding new authoritative Name Server, follow the instructions in the following: 1. Add only one FDQN on the field and click OK. The Zone page is displayed. 2. Open the Zone Root page again by clicking the object at the top of the page. The page has the same name as the zone. The Zone Root page is displayed. 3. Add another FQDN on the next empty field under Authoritative NameServers (NS) and click OK. 4. Go to step Close the NameSurfer Web UI. •

Scroll down on the page and click OK. The Zone page is displayed.

6.

A.2.4

Close the NameSurfer Web UI.

All authoritative zones exist in BIND based slave DNS If all authoritative zones exist, go to procedure To configure zones as slaves for BIND Name Servers in the GNS.

A.2.5

All authoritative zones do not exist in BIND based slave DNS

To configure other authoritative DNS in NetAct 1.

Log in to OSS4 NetAct DS or another authoritative slave DNS in NetAct as root user.

2.

Check that Name Server in the DS is backing up all the zones that the Name Server SS is managing. If all the zones can be found, continue from step 6.

3.

If the Name Server in DS does not have all the zones compared with the zones managed by Name Server in SS, create the missing zones as slaves for the Name Server in the DS.

4.

Re-start BIND in the DS with the command:

root% rndc reload

96 (100)


DN00297251 Issue 7-1 en


A.3

5.

Verify that all created zones are downloaded with the correct Serial Number and there are NO error messages in the /var/adm/syslog/syslog.log about the loaded zone files.

6.

Repeat steps 1-5 to all authoritative servers. If all the slave servers are modified, continue with the instructions on Configuring zones as slaves for Name Server in the GNS.

GNS This section describes the tasks you need to perform in GNS to complete the zone transfer.

To configure zones as slaves for BIND Name Servers in the GNS 1.


2.

Open the file /etc/named.conf with a text editor, for example with vi.

3.

Change the type of the zone as slave and define masters for a zone respectively about the primary Name Server application in use on the Global Cluster. That is done for all zone statements in the file excluding the zone "0.0.127.in-addr.arpa". See the following examples about zone statement differences regarding primary Name Server application in use:

zone "netact.done.fi" { type slave ; file "db.netact" ; masters { ; } ; } ;

Figure 29.

Example of a zone statement for BIND based primary Name Server

zone "netact.done.fi" { type slave ; file "db.netact" ; masters port 8054 { ; } ; } ;

Figure 30.

DN00297251 Issue 7-1 en

Example of a zone statement for NameSurfer based primary Name Server


97 (100)


4.

Re-start BIND on GNS with the command

root% rndc reload

5.

Verify that all changed zones are downloaded with correct Serial Numbers from the correct IP address and the port of the primary Name Server and there are NO error messages in the /var/adm/syslog/syslog.log about the loaded zone files.

6.

Repeat steps 1 to 5 for all GNS that need to be modified. After the steps above the integration of GNS zone data into NetAct Primary Name Server is completed.

98 (100)


DN00297251 Issue 7-1 en

Index Numerics

F

3G network elements 35 3G -SGSN 36 3G SGSN checking time zone 50 checking version 21 event logging 50 management connection 13 platform 13 time setup 50 what it does 13

A alarm flow checking alarms 84 ATM 13

84

B BG 36 big IP adaptation See BIGI 36 BIGI 36 border gateway See BG 36

37

G Gateway GPRS Support Node 11 gateway GPRS support node See GGSN [GGSN:gateway gprs ] generic GPRS network elements 37 get community string 39, 41 GGSN 11, 37 GGSN interfaces 37 GNS1 45 GNS2 45 GPRS 11 GPRS domain name 45 GPRS name server See secondary GPRS name servers GPRS name servers 45 GPRS network elements 35 GPRS site 37 GPS 49

37

37

I

C CA 36 CG 36 Charging Gateway See CG [CG:charging g ] Content Analyser 36

36

D DHCP servers 36 DNS configuring in 3G SGSN DNS 14, 36, 43

44

E element managers launching 83, 85 Ethernet switches 36

DN00297251 Issue 7-1 en

firewalls 36, 87 frame relay bearer channels FTP 13, 14

©Nokia Corporation Nokia Proprietary and Confidential

integration verifying 81 IP interfaces 37 IP switches 37 IP3400 13 IP650 11 IP740 11 IPSO checking version 22 correct version 20 IPSO 13

L Lawful Interception Gateway LIG 37 location areas 38

37

M main hostname 39, 40 Managed Objects 40 management connection 13

99 (100)


T

marker and charging unit See MCHU 38 MCHU 38

TCP/IP 49 time zone 51

N

U

NameSurfer 26 NetAct Packet Core Adaptation 35 network service virtual connections 38 Nokia IP650 11 Nokia IP740 11 NTP 13, 14, 15, 49 NTP servers 52, 53, 56

O OSPF

UDP address

39,

41

V VLR -LA association Voyager password 21 username 21

38

W

48

WA

P

38

Packet Core network 38 Packet Core subnetwork 38 packet processing unit See PAPU 38 PAPU 38 parent objects 40 PCM lines 38 Performance Management 35 primary name server 43, 45

R router

9,

14,

23,

24,

38

S secondary GPRS name servers 36, 37 secondary name server 45 set community 41 set community string 39 SNMP community strings 75 configuring 54 SNMP 13, 14, 15, 53 SNMP -specific database attributes 39 SNMP traps 75, 76 start an Element Manager 84, 85 STM -1 13 switch 9, 14 System Server 52

100 (100)


DN00297251 Issue 7-1 en

Integrating Packet Core Network Elements to NetAct

Recommend Documents