Integrating Packet Core Network Elements to NetAct

Integrating Packet Core NetworkElements to NetAct

DN00297251 © Nokia Corporation 1 (100)Issue 7-1 en Nokia Proprietary and Confidential

Integrating Packet Core Network Elements to NetAct

The information in this documentation is subject to change without notice and describes onlythe product defined in the introduction of this documentation. This documentation is intendedfor the use of Nokia's customers only for the purposes of the agreement under which thedocumentation is submitted, and no part of it may be reproduced or transmitted in any form ormeans without the prior written permission of Nokia. The documentation has been prepared tobe used by professional and properly trained personnel, and the customer assumes fullresponsibility when using it. Nokia welcomes customer comments as part of the process ofcontinuous 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 bindingbut shall be defined in the agreement made between Nokia and the customer. However, Nokiahas made all reasonable efforts to ensure that the instructions contained in the documentationare adequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the documentation.

Nokia's liability for any errors in the documentation is limited to the documentary correction oferrors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL(INCLUDING MONETARY LOSSES), that might arise from the use of this documentation orthe information in it.

This documentation and the product it describes are considered protected by copyrightaccording 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 respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2006. All rights reserved.

2 (100) © Nokia Corporation DN00297251Nokia Proprietary and Confidential Issue 7-1en

Contents

Contents 3

List of tables 6

List of figures 7

1 About this document 91.1 NetAct compatibility and capacity information 91.2 Terms 9

2 Introduction to Packet Core integration 112.1 Integration principles 112.1.1 Integration principles for GGSN 112.1.2 Integration principles for Flexi ISN 122.1.3 Integration principles for 3G SGSN 132.1.4 Integration principles for CG, GNS, and DHCP server 132.1.5 Integration principles for Content Analyser (CA) 142.1.6 Integration principles for router (RTR) and Ethernet switch (IPSW) 142.1.7 Integration principles for SGSN 142.2 Integration procedures 142.2.1 Integration procedure for IP platform network elements 142.2.2 Integration procedure for CG, GNS, and DHCP server 162.2.3 Integration procedure for BIG-IP Network Elements 162.2.4 Integration procedure for Traffic Analyser (TA) 162.2.5 Integration procedure of routers 172.2.6 Integration procedure for Content Analyser (CA) 172.2.7 Integration procedure for SGSN 18

3 Preliminary tasks for Packet Core NE integration 193.1 Reviewing the system requirements 193.1.1 Nokia NetAct 193.1.2 IP platform NEs 203.1.2.1 Verifying the versions 213.1.3 CG, GNS, and DHCP server 233.1.4 BIG-IP 233.1.5 Routers 233.1.6 Content Analyser 243.1.7 SGSN 243.2 Adding managed objects to DNS 253.2.1 Adding a PaCo NE to DNS using NameSurfer 263.2.1.1 Adding a host to PaCo forward zone with NameSurfer 293.2.2 Adding a Packet Core NE to DNS using BIND 303.2.2.1 Adding a host to Packet Core forward zone 333.3 Creating managed objects for Packet Core NEs 333.3.1 SNMP-specific attributes for managed objects 393.4 Checking Maintenance Region Service Users in NetAct 413.5 Checking the DNS configuration 43



4 Configuring a Nokia IP Platform based NE 474.1 Checking the IP configuration 474.2 Configuring a static route 484.3 Configuring network time protocol (NTP) 494.4 Configuring SNMP 534.5 Setting measurement data file format for GGSN 57

5 Configuring HP-UX based Network Elements 595.1 Configuring Charging Gateway 595.1.1 Configuring HP-UX SNMP agent 595.1.2 Configuring Charging Gateway SNMP agent 605.1.3 Configuring Charging Gateway Alarm Interface 615.1.4 Configuring the network time protocol (NTP) 625.2 Configuring DHCP server 645.2.1 Configuring SNMP 645.2.2 Configuring NTP 645.3 Configuring GNS 64

6 Configuring BIG-IP 676.1 Configuring BIG-IP 4.5 676.2 Configuring BIG-IP 9.1 69

7 Configuring a router 757.1 Configuring SNMP for a router 75

8 Providing users access to NetAct applications and networkelements 79

9 Verifying integration 819.1 Nokia IP platform network elements 819.1.1 Verifying IP connectivity 819.1.2 Verifying performance management data flow for IP platform network

elements 819.1.3 Verifying fault management data flow 829.1.4 Verifying Configuration Management 839.1.5 Verifying Element Manager launch 839.2 Nokia CG, DHCP server and GNS 849.2.1 Verifying performance management flow for CG, DHCP Server and

GNS 849.2.2 Verifying fault management data flow for CG, DHCP Server and GNS 849.2.3 Verifying configuration management for CG, DHCP Server and GNS 859.2.4 Verifying Element Manager launch for CG, DHCP Server and GNS 85

10 Where to find more information 87

Appendix A. Moving GNS-managed zone(s) under the management of theNetAct DNS 89

A.1 GNS 91A.1.1 NameSurfer is not the primary Name Server 91A.1.2 NameSurfer is the primary Name Server 92A.2 NetAct DNS environment 92


A.2.1 Name Server has zones required by GNS 92A.2.2 Name Server does not have the zones required by the GNS 93A.2.3 NameSurfer is the primary Name Server 94A.2.4 All authoritative zones exist in BIND based slave DNS 96A.2.5 All authoritative zones do not exist in BIND based slave DNS 96A.3 GNS 97

Index 99



List of tables

Table 1. DNS entries example 29

Table 2. DNS entries example 33

Table 3. Mapping between Packet Core network elements and managed objectclasses 36

Table 4. Network Editor dialog example input for Packet Core MOs 40

Table 5. Maintenance Region Service users needed during PaCo integration 42


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 toNetAct 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/net-snmp/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



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 NameServer 97


About this document

1 About this documentIntegrating Packet Core Network Elements to NetAct describes how to integratePacket Core network elements to Nokia NetAct. Integration of the followingPacket 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 anoperator.

Additionally, you need to perform various configuration tasks directly on the NEsthat you are integrating. For information on the tasks related to SGSN andContent 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 protocolsused in integrating Packet Core NEs to NetAct, go to Chapter 3 Preliminary tasksfor Packet Core NE integration.

1.1 NetAct compatibility and capacity information

For information on the NetAct system and capacity and the compatibility betweenNetAct and network element releases, see the NetAct Compatibility and CapacityInformation document.

1.2 Terms

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


Introduction to Packet Core integration

2 Introduction to Packet Core integrationThis chapter describes the integration principles and procedures for the PacketCore 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 ofthis document, see:

• Integration principles in Integrating SGSN to NetAct

• Integration principles in Integrating FlexiServer Network Elements toNetAct

2.1.1 Integration principles for GGSN

Gateway GPRS Support Node (GGSN) acts as the interface between a GPRSnetwork and external networks. GGSN is connected to Nokia NetAct throughPacket Core IP backbone network.

GGSN is implemented on Nokia IP650 (GN2500) series or Nokia IP740(GN3500) series platforms. The following figure illustrates the connectionsbetween GGSN and Nokia NetAct.



Figure 1. GGSN connections to NetAct

2.1.2 Integration principles for Flexi ISN

The Flexi ISN acts as a gateway between the wireless data networks and theInternet. In addition to the 'classic' GGSN functionality, NokiaFlexi ISN (releases2.0 and 3.0) has a traffic analysis functionality for differentiated chargingpurposes. Flexi ISN is based on the FlexiServer hardware platform and NokiaIPSO Operating System. The communication between Flexi ISN and NetAct isbased on the Nokia enhanced SNMP Solution Suite (NE3S).

The remote management of the Flexi ISN from NetAct is enabled by thefollowing management interfaces and protocols:

• NE3S for collecting alarms and performance indicators

• Voyager Web interface for configuration and administration of the FlexiISN

• Network Time Protocol (NTP) for synchronising the Flexi ISN internalclock

• File Transfer Protocol (FTP) for software image download, configurationdata backup and restore functions

• SSH/Telnet for remote shell access

NetAct

NetAct FirewallO&M data

GGSN

(DNS)

Packet Corebackbone

Demilitarisednetwork

ChargingGatewaynetwork

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



2.1.3 Integration principles for 3G SGSN

3G SGSN acts as a link between 3G Radio Access Network (RAN) and packetcore network. 3G SGSN performs both control and traffic handling functions forpacket switched domain in 3G system.

3G SGSN is based on the high-capacity IP3400 Nokia Multiprocessor routerPlatform and on the Nokia IPSO operating system.

3G SGSN is managed from Nokia NetAct through the following interfaces andprotocols:

• Simple Network Management Protocol (SNMP), for alarms, performanceindicators, and configuration data.

• Nokia Voyager Web interface for the initial configuration andadministration of 3G SGSN.

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

• Telnet or Secure Shell (SSH) for software downloading and activating andconfiguration 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 interfacein 3G SGSN for implementing the management connection. 3G SGSN Gnphysical interfaces can be implemented through 10/100BaseTX RJ45 interface(IEEE 802.3, 802,3u), Gigabit Ethernet (IEEE 802.3z), or ATM 155 Mbps STM-1.

2.1.4 Integration principles for CG, GNS, and DHCP server

The following protocols and interfaces are used in Nokia NetAct for managingCG, GNS, and DHCP server:

• Simple Network Management Protocol (SNMP), for alarms, performanceindicators, and configuration data.

• Element Manager for the initial configuration and administration of CG.

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

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



• 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, zonenotifications and zone polling.

2.1.5 Integration principles for Content Analyser (CA)

For information on integration principles of Content Analyser, see Integrationprinciples 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 SNMPtraps and how to configure the community strings, are delivered with theequipment. The equipment usually provides its own element manager system forthis kind of configuration steps.

For generic instructions on how to integrate a router to Nokia NetAct, see Chapter7 Configuring a router. These instructions apply to all the routers that supportSNMP and standard Management Information Base (MIB).

For instructions on integrating Cisco switch or router, see Optional configurationsin Integrating DCN Backbone to NetAct.

2.1.7 Integration principles for SGSN

For information on integration principles of SGSN, see Integration principles inIntegrating SGSN to NetAct.

2.2 Integration procedures

This section provides an overview of integrating Packet Core network elementsto 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 setof preliminary tasks and then configuring NTP, SNMP and DNS services. Thefollowing figure shows an overview of the integration procedure.



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 ofpreliminary tasks and then configuring NTP and SNMP. The following figureshows an overview of the integration procedure.

NE

NetAct

Task is done in:

Configure the NetActservers Check the IP

configuration

Configure NTP

Configure SNMP

Start preliminarytasks

Review the systemrequirements

Check the DNSconfiguration

Start configuration

Verify the NetActconnections



Figure 3. Basic procedure for integrating LIG, BG and Packet Core FW toNetAct

2.2.2 Integration procedure for CG, GNS, and DHCP server

CG, GNS, and DHCP server integration consists of configuring static route, NTPand SNMP. For the procedure, see the figure 3 Basic Procedure for integratingLIG, BG and Packet core FW to Nokia NetAct presenting the basic procedure forintegrating LIG, BG and Packet Core FW to Nokia NetAct.

For information on how to move GNS-managed zones, see A Moving GNS-managed 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 haveto be configured. They need to be already configured when BIG-IP NEs areconfigured 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 withNetAct TA 3.0 FM uses the Nokia Enhanced SNMP Solution Suite (NE3S)interface, while TA 3.0 PM is SNMP polling based.

NE

NetAct

Task is done in:

Configure the NetActservers

Start preliminarytasks


End

Configure the NTP

Configure SNMP

LIGBGFW



2.2.5 Integration procedure of routers

The integration of a router to Nokia NetAct includes a set of preliminary tasks andthe configuration of SNMP. The following figure gives an overview of theintegration procedure.

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 Integrationprocedure in Integrating FlexiServer Network Elements to NetAct.


Start

Add the router informationto the DNS

Create MOs for therouter

Check the MRService users

Configure SNMPfor the router

End

Verify the integration



2.2.7 Integration procedure for SGSN

For information on integration procedure of SGSN Network Elements, seeIntegration procedure in Integrating SGSN to NetAct.


Preliminary tasks for Packet Core NE integration

3 Preliminary tasks for Packet Core NEintegration

This chapter describes the preliminary tasks, which need to be performed beforethe 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. SeeTesting the System Platform

• GPRS domain name and IP addresses for GPRS Name Servers areavailable

• IP addresses for NetAct servers and osscore2 are available

To find out the IP address of the osscore2 ServiceGuard package andthe 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:



...Name: rc80cor2.netact.noklab.netAddress: 10.8.xxx.xxx

3. Interrogate the IP address and FQDN of the primary node (DatabaseServer) 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. Note down these IP addresses, as you need them during the NE integration.

3.1.2 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 NetActCompatibility and Capacity Information. For further instructions on installing theNE 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) areavailable.

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

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

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



Note

Note

3.1.2.1 Verifying the versions

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

With version SGN4, all http connections can be replaced with httpsconnections 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.



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. Checking the IPSO version



Note

3.1.3 CG, GNS, and DHCP server

Apart from what is presented in Section 2.2.2 Integration procedure for CG, GNSand DHCP server, there are no specific system requirements for CG, GNS, andDHCP 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 HotFix-C119009.tgz installed on the BIG-IP, and for the BIG-IP version 9.1 you need tohave the HotFix-CR54731 installed on the BIG-IP. You can obtain the hotfixesfrom the supplier F5 on request.

3.1.5 Routers

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.

• Router has been integrated to Packet Core IP network.

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

• Router is configured for Telnet access.



To interrogate the version of a router

1. Open a Telnet session to router.

% telnet <router>

where <router> 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:

> enable

4. Interrogate router version by entering:

# show version

The output of the command shows the version of the router and otherinformation, 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:

# configure terminal

7. Enter the password for the configure mode.

3.1.6 Content Analyser

CA is running on FlexiServer platform, for information on system requirements,see Section Nokia FlexiServer platform in Integrating FlexiServer NetworkElements to NetAct.

3.1.7 SGSN

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



Note

3.2 Adding managed objects to DNS

DNS (Domain Name Service) is a distributed database that contains naminginformation about network elements. The system provides the service ofconverting host names into IP addresses and the other way round. Before you addnetwork elements to DNS, familiarise yourself with DNS management conceptsand the lists of required zones presented in DNS Management Principles.

When integrating a new PaCo network element to Nokia NetAct, you need to addthe IP address and hostname of the network element to PaCo/GPRS zone, forexample, mnc003.mcc262.gprs or paco.netact.done.fi. The selected zone dependson the fact whether the management and user planes in PaCo network arecombined 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 GNS-managed 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 editorto add the elements to DNS.

If you are unsure whether the primary Name Servers are implemented with BINDor 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 theTop-level User Interface, click Utils → System Mgmt → DNS Manager... tostart the application.



Note

3.2.1 Adding a PaCo NE to DNS using NameSurfer

If you have NameSurfer included in your NetAct software delivery package, youneed to carry out the tasks listed in this section using web-based GUI ofNameSurfer and a text editor.

Before continuing, ensure you are familiar with DNS solution architecture wherethe primary NS is implemented with NameSurfer that works with severalsecondary NSs implemented with BIND. For more information, see chapterConfiguring DNS with NameSurfer as primary Name Server in Managing theDNS 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 adifferent NetAct cluster than where the NE is integrated. For more information,see chapter Name Servers and zones in the NetAct system in DNS ManagementPrinciples.

When NameSurfer is used as the primary DNS server, you must also configureBIND 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 clusterwhere the NE is integrated (if not the same) as shown in the figure below.



Figure 7. Adding a NE to DNS using NameSurfer as the primary NS

The following figure illustrates the configuration tasks.

New NE

Integrated NEs

RC1RC2

Configured as"slaves"

Primary NS

Secondary NSs

System Server Database Server

System Component Server

BIND(named)

GC

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

NameSurfer

BIND(named)

"master"



Figure 8. 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 orpaco.netact.done.fi), used for the management of PaCo NEs isknown. The correct domain depends on the IP topology of the PaConetwork, that is whether the management and user planes are combined orseparated in the network. For instructions on selecting the correct domain,see section Different IP topologies in a network in chapter Name Serversand zones in the NetAct system in DNS Management Principles.

• The primary and secondary Name Servers are known. For instructions onlocating Name Servers, see section Locating Primary Name Server in DNSManagement Principles.

Have the forward zonesbeen created?

No

Yes

No

Are the domain,primary and

secondary NS known?

Locating primary NameServer

Create the zone

Configure secondaryBIND Name Servers

Verify the DNSconfiguration

Add the host to theforward zone

Yes



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

• If you created the forward zone, check whether the it is available. Forinstructions, see section Verifying the DNS configuration (in chapterConfiguring DNS with NameSurfer) in Managing the DNS with NetAct.

3.2.1.1 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 andname to the Domain Name Service (DNS).

To add a host to PaCo forward zone

1. For instructions, see section Host (A) (in section Using NameSurfer to editdata in DNS) in Managing the DNS with NetAct. When you fill in a hostname and the IP address of the network element, you need to fill in thefollowing 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 <name><ip address>

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 theDNS forward zone

• create alias ems-<AdminServerHostName> for the admin server,where the <AdminServerHostName> is the hostname of the adminserver.

For example, if the hostname of the Admin Server in CG iscgadmin.nss.netact.done.fi, and its IP address is 10.1.2.3, the DNS shouldhave 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 cgadmin.nss.netact.done.fi



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

3.2.2 Adding a Packet Core NE to DNS using BIND

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



Note

Figure 9. Adding a NE to DNS using BIND as the primary NS

The exact configuration procedure depends on the cluster (Regional/Global)where the primary Name Server is located. The primary NS can be located in adifferent NetAct cluster than where the NE is integrated. See section NameServers and zones in the NetAct system in the document DNS ManagementPrinciples.

The following figure illustrates the configuration tasks.

RC1

RC2

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

Database Server

Configured asa "slave"

Secondary NS

System Component Server

BIND(named)

Primary NS

Configured asa "master"

GC

BIND(named)

System Server

New NE

Integrated NEs



Figure 10. Adding hosts to PaCo forward zone with BIND

Preliminary tasks

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

• The domain (for example, paco.netact.done.fi), the primary andsecondary Name Servers are known. For instructions on locating NameServers, see section Locating primary Name Server in DNS ManagementPrinciples.

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

• If you created the PaCo forward zone, check that the forward zone isavailable. For instructions, see section Verifying the DNS configuration (inchapter Configuring the DNS with BIND as primary Name Server) inManaging the DNS with NetAct.

Have the forward zonesbeen created?

No

Yes

No

Are the domain,primary and

secondary NS known?

Locating primary NameServer

Create the zone

Configure the secondaryName Server as slave

Verify the DNSconfiguration

Add the host to theforward zone

Yes



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) inManaging 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 theDNS forward zone

• create alias ems-<AdminServerHostName> for the admin server,where the <AdminServerHostName> is the hostname of the adminserver.

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

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

For more details, see appendix Example of forward zone file in the document DNSManagement Principles.

When you have added all the required entries, go to Section 3.3 Creating managedobjects 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 tocreate Packet Core NEs in NetAct database. For more information on managedobjects and their hierarchy, see Managed Object Reference.

Table 2. 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 cgadmin.nss.netact.done.fi



Note

Note

In addition, you must manually upload Packet Core NEs for performancemanagement (PM) objects when you have created an object with Network Editor.To customise Packet Core PM Object Upload, you have to check an additionalcron 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 usefor creating the MO for the NE you are integrating to NetAct.

2. Find the parent object for the MO you are creating. For information, seeNetAct object hierarchy for Packet Core objects in Managed ObjectReference.

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

Flexi ISN MO does not exist as a separately defined object type. You need tomodel the object on the GGSN object, depending on the Flexi ISN version; FlexiISN 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 theparent object.

4. In Network Editor, open the pop-up menu of the parent object and selectAdd New Child → <MOC>.

The Creating an Object dialog appears.



Note

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 theMaintenance Region pane, and select the Maintenance Region associated withGraphical User Interface Server on which Checkpoint FireWall-1 software for theFW object is running.

You need to update the Version attribute each time your NEs are upgraded to alater version to keep your Nokia NetAct system functional.

The following table describes all GPRS and 3G NEs supported by Packet CoreAdaptation, and provides the mapping information between the NEs and theMOCs.

The table includes only MOCs that refer to Packet Core NEs that physically existand raise alarms. You have to instantiate these NEs and integrate them to thetopology system. All the other MOCs, such as the generic interfaces, are onlycreated for performance management purposes, and are not listed in the tablebecause they are not integrated to NetAct topology system.



Table 3. Mapping between Packet Core network elements and managedobject classes

GPRSnetworkelement

DescriptionManagedobjectclass, ID

3G SGSN 3rd Generation Serving GPRS Support Node.

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

SG3G, 474

BG Border Gateway.

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

BG, 461

BIGI Big IP Adaptation

Big IP is a traffic management solution for localarea application. It ensures high availability,reliability, security, and scalability for Webapplications.

BIGI, 1214

CA Content Analyser

CA is an engine to run mass scale browsingbusiness with the operator’s own or third-partycontent.

CA, 1239

CG Charging Gateway.

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

CG, 451

DHCP server Dynamic Host Configuration Protocol server.

Assigns dynamic IP addresses to the users.

DHCP, 473

DNS,(primary)Name Server

A primary Name Server, which updates mappingsbetween IP addresses and symbolic namesstored in the secondary Name Servers.

NS, 455

DNS,secondaryGPRS NameServer

Secondary GPRS Name Server.

Updated by the primary Name Server with name-address mappings.

GNS, 456

Ethernetswitch

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

IPSW, 459

Firewall Server that prevents unauthorised access toprotected networks.

FW, 457



Flexi ISN A carrier-grade platform incorporating GGSN andadvanced service aware functionality.

A gateway between wireless data networks andthe Internet.

Flexi ISN does not have an object of its own yet.Instead it is modelled with the managed object ofGGSN, version depending on the version of theFlexi ISN (GGSN v.4.1 for Flexi ISN 2.0 andGGSN FI3.0 for Flexi ISN 3.0).

No separatelydefined objecttype of its ownyet. Modelledon GGSNobject.

Frame RelayBearerChannel

A user access channel for frame relay data traffic. FRBC, 464

GenericGPRS BB NE

Generic GPRS backbone network element.

Needs to be modelled and does not have aseparately defined object type of its own.

GGNE, 460

GGSN Gateway GPRS Support Node.

Forms the gateway to external networks whilehides the GPRS infrastructure from them.

GGSN, 454

GGSNInterface

Network Interface for the GGSN with an IPaddress.

GGIF, 466

GPRS NameServer

Secondary GPRS Name Server used in GPRSPacket Core networks.

GNS, 456

GPRS site Site object are used for grouping the managedobjects located on one site.

GPST, 453

IP Interface Additional IP address for IP-based equipment.

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

IPIF, 472

IP Switch See Ethernet switch. IPSW, 459

LawfulInterceptionGateway, LIG

In the Nokia implementation, the LIG consists oftwo separate network elements:

• Lawful Interception Controller (LIC)

• Lawful Interception Browser (LIB)

LIB, 467

LIC, 468

Table 3. Mapping between Packet Core network elements and managedobject classes (Continued)

GPRSnetworkelement




Location areas Location areas are identified by associationsbetween Visitor Location Registers (VLRs) andlocation areas. Such an association can beintegrated as a managed object under SGSN.

VLA, 470

(VLR-LAassociation)

MCHU Marker and Charging Unit.

A functional unit of the SGSN. Its main tasks aremarking, configuration management, andcollecting charging data.

MCHU, 566

NetworkService VirtualConnection

An end-to-end virtual communication pathbetween peer entities dealing with networkservices.

NSVC, 465

Packet Corenetwork

Packet Core backbone network. GPBB, 452

Packet CoreSubnetwork

Subnetwork object to which Packet Core objectscan be associated so that they are groupedtogether in a single MO.

Such an association is not a parent-child orcontainment relationship. No alarms arrive in thePacket Core object from the associated MOs.

PACO, 475

PAPU Packet Processing Unit.

Functional unit of the SGSN used for packetprocessing. Converts GPRS backbone protocolsto BSS protocols. All BTSs that belong to thesame routing area are controlled by the samePAPU.

PAPU, 462

PCM line 2-Mbit trunk interface. PCM, 15

Router For integrating router equipment, useCiscoWorks2000 and the standarddocumentation set that accompanies the product.

RTR, 127

TA Traffic Analyser.

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

TA, 1240

VLR-LAassociation

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

VLA, 470

WA Wireless Accelerator. WA, 1301

Table 3. Mapping between Packet Core network elements and managedobject classes (Continued)

GPRSnetworkelement




Note

Note

3.3.1 SNMP-specific attributes for managed objects

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

• Main Hostname and IP

General hostname and IP address of the NE.

If you have added the hostname(s) and IP address(es) of the NE to DNS asdescribed in Section 3.2 Adding managed objects to the DNS, you do not need tospecify 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 portsmust be the same as the ports on the NE.

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

• Get Community

The get community string of the NE, which is a type of password that isnecessary for performing the get SNMP operation.

To enable the reliability service of traps, the get community string for LIGhas to be configured when creating a managed object.

• Set Community

The set community string of the NE, which is a type of password that isnecessary for performing the set SNMP operation.

The Creating an Object dialogs for Packet Core MOCs LIC, LIB, and NSdo not contain text fields for the get and set community strings. Thefollowing figure shows their dialog.



Figure 12. Creating an Object dialog for SNMP MOs without community strings

The Network Editor knows from the information on MOCs stored in TopologyDatabase whether the MO has another SNMP object as parent object, and selectsthe correct Network Editor dialog and its default values accordingly.

When you are creating an MO for a Packet Core NE, you need to specify thefollowing attributes in the Network Editor dialog after checking the correct valuesfrom the actual configuration of the NE. The following table shows someexample values.

Table 4. Network Editor dialog example input for Packet Core MOs

Technology-specific attributes Example values

Main Hostname

IP (selected automatically if NE integrated with DNS)

Border_Gateway_003

172.13.222.14



Note

Note

Note

3.4 Checking Maintenance Region Service Users inNetAct

The following table presents the users that need to exist in NetAct before you canstart integrating Packet Core NEs.

To ensure the required MR service users with correct properties have been createdin NetAct, you need to use Service User Management application to check and/orcreate the users listed in the table.

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

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

SNMP Get and SNMP Set community string information has to be set via theNetwork editor during the time when the managed object is created. Thisinformation is used for getting read and write access to managed objects whichare integrated via SNMP. Although SNMP Get and SNMP Set information is notset 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, seeManaging Users and Service User Management Help.

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

Table 4. Network Editor dialog example input for Packet Core MOs

Technology-specific attributes Example values


Integrating Packet C

ore Netw

ork Elem

ents to NetA

ct

42 (100)©

Nokia C

orporationD

N00297251

Nokia P

roprietary and Confidential

Issue7-1

en

Co integration

Connectedto NetActuser group

MR MOFor example,needed for

sysop, allgroups withusers ofAoM

MR ofGGSN

GGSN Administration ofMeasurements

sysop FW orGUIS’MR

FW Checkpoint FWGUI

Table 5. Maintenance Region Service users needed during Pa

MR serviceusers andusernamedependencies

Examplesof an MRserviceuser’susername

Passworddependencies

ServiceType andprofile

Username canbe freelyselected but amatching localuser must existin GGSNs insidethe same MR

ne3suser Password canbe freelyselected but itmust be identicalas used for local“ne3suser” in allGGSNs in thesame MR

Generic NEFTP ACCESS

Freely selectable fwgui Freely selectable ProgrammaticPC Access


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 hasbeen created in the Maintenance Region of GGSN, and its Service Typeand Profile is set to Generic_NE_FTP_Access. The service user must beincluded in the sysop UNIX user group in NetAct.

2. From Service User Management application, ensure that the username andpassword for the MR service user (with Generic_NE_FTP_Access) andthe local service user in GGSN (for example, the ne3suser user) match.For instruction on creating users in GGSN, see section ConfiguringSecurity 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 theunix user group mentioned above. To ensure that other features (likesoftware download or upload) are working, see Service types in SystemAdministration Principles.

3.5 Checking the DNS configuration

The IP addresses of the primary and secondary Name Servers and the name of theGPRS domain are configured so that the DNS queries are forwarded to the correctName Server.

DNS needs to be configured for the following network elements:



Note

Note

• GGSN

• 3G SGSN

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

All domain names and IP addresses shown below are examples and must not becopied 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. Configuring DNS for Packet Core NEs



4. If undefined, fill in the following values:

<Domain name:> APN domain name

<primary name server:> IP address of GNS1 (GPRS Name Server1)

<secondary name server:> IP address of GNS2 (GPRS NameServer 2)

5. Click Apply and Save.

6. Click Home.


Configuring a Nokia IP Platform based NE

4 Configuring a Nokia IP Platform basedNE

This chapter describes the configuration of the Nokia IP Platform-based networkelements.

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. Checking IP configuration



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.

4.2 Configuring a static route

Static routes are used by the NEs to send data directly to NetAct using a specificpath. Configuring static routes is the best way to ensure that all packets will besent directly to their destination. To provide IP packet routing between the NEand 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 theNE from a PC, for example, that is located in the same subnet with the NE.

To configure static route


2. Click Config.

3. From Routing Configuration list, click Static Routes.

The static routes configuration window opens.



Figure 15. Configuring static route

4. Add the static route by filling in the following values:

<New static route:> IP address of the NetAct network

<Mask length:> The number of bits in the subnetwork mask of router,see /etc/rc.config.d/netconfFor example, a Class B subnetwork mask uses 16 bits.

<Next hop type:> normal

<Gateway type:> address


6. Click Home.

4.3 Configuring network time protocol (NTP)

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



NetAct receives its reference time from an operator maintained NTP server. TheNEs NetAct manages can either retrieve the time from NetAct or from theoperator maintained NTP server. For more information on time management inNetAct, see Time management in System Administration Principles.

The reference time is used in the NEs for time stamps and event logging. NTPneeds 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


2. Click Config.

3. Click the Local time setup link in the System Configuration section.

The time setup window opens.

Figure 16. Selecting a time zone



Note

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


6. Click Home.

7. Configure NTP.

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


2. Click NTP link in the Router Services section.

3. Click NTP service in NTP Global Settings.

The NTP configuration window opens.



Figure 17. Configuring NTP for Packet Core NEs

4. Enter the IP addresses of the new NTP servers based on your network setupin 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 IPaddress and click Apply.

By default, the new server is enabled, v3 is selected, and the PreferYes 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 PreferNo radio button is selected.



<Add new server address:> As NTP servers, add the following IPaddresses with the attributes given in parenthesis:1. System Server, if reference time is retrieved from

NetAct/External NTP server (<IP address>: on,Prefer: yes, Version: v3)

2. Database Server, if reference time is retrieved fromNetAct/Backup for the external NTP server (<IPaddress>: on, Prefer:no, Version: v3)

<Add new peer address:> Optional

<NTP reference clock:> Optional


6. Go to Section 4.4 Configuring SNMP.

4.4 Configuring SNMP

SNMP is an application layer protocol that enables the SNMP managementstation to communicate with an SNMP agent (NE). After SNMP parameters areconfigured, Nokia NetAct is able to perform a full range of managementfunctions on the NE

SNMP needs to be configured in the following network elements:

• GGSN

• 3G SGSN

• Border Gateway (BG)

• Packet Core Firewall



Note

Note

• LIG

• TA

When configuring SNMP, in Step 6 <read-write community string:>need not be configured for LIG.

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

To configure SNMP


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 fieldand click Apply.

SNMP configuration window opens. The following figure shows anexample of configuring SNMP for 3G SGSN.



Figure 18. Configuring SNMP for Packet Core NEs (top part)



Figure 19. Configuring SNMP for Packet Core NEs (bottom part)

6. Fill in the following fields:

<Read-only community string:> <get-community-string>The string has to be identical in NetAct and NE.

<Read-write community string:> <set-community-string>The string has to be identical in NetAct and NE.

<Add new trap receiver> IP address of osscore2

<Trap status> onEnable all traps.The number of traps varies according to networkelement type.

<Trap PDU agent address:> IP address of the network elementinterface towards NetAct

<SNMP location string> Optional

<SNMP contact string> Optional




Note

8. Click Home.

9. Go to Section 3.5 Checking the DNS configuration.

SNMP alarms must be enabled in the LIG application. For more information oninitialising or changing alarm transfer settings refer to section Initialising orchanging alarm transfer settings of the Administrator in Chapter LIG alarmsoverview 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 themeasurement 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.

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.


Configuring HP-UX based Network Elements

5 Configuring HP-UX based NetworkElements

This chapter describes the configuration of Charging Gateway, DHCP Server andGNS.

5.1 Configuring Charging Gateway

This section describes the SNMP performance management and Alarm Interfaceconfiguration 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.0in document Installing CG, available in Nokia Charging Gateway, Rel 3.0Product 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 ConfiguringCharging Gateway SNMP agent.

To configure SNMP performance management

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

1. Setget-community-name andset-community-name accordingto the SNMP community string values set to the NE’s managedobject in NetAct.

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

3. Set max-trap-dest to 1.



The following is an example of the NetAct related part of the/etc/SnmpAgent.d/snmpd.conf file:

get-community-name: publicset-community-name: sGoH0P9Jmax-trap-dest: 1trap-dest: 10.8.58.183

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

2. 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. Edit the snmp.conf file in /opt/cg/4.0/net-snmp/etc/snmp/:



Note

Note

rocommunity publicrwcommunity sGoH0P9Jproxy -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/net-snmp/etc/snmp/snmpd.conf.

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

The get-community-name matches with rocommunity and set-community-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 faultmanagement of CG versions up to 4.2. In CG version 4.3 NE3S interface is usedfor alarms. You need the IP address of the osscore2 package for configuring theinterface.



Note

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

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

2. Modify the line starting with text:

MANAGER=.

# managersMANAGER=<ip address of osscore2>,<port>,<community string>

Correct values:

<ip address of osscore2>

= IP address of osscore2 SG-package

<port>

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

<community string>

= 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

When you are configuring CG version 4.3, please see chapter Configuring the CGNE3S alarm interface for ESYMAC alarm agent in document Commissioningand Integrating Charging Gateway 4.3 (DN03385317) which is delivered inNOLS. 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 platformbased NEs, that is CG, DHCP and GNS.



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.110.8.1.2”

The System Server (SS) is the preferred NTP server, and it has to be addedas the first entry for NTPDATE_SERVER. The Database Server (DS) isadded 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 thesecondary NTP server.

6. Restart NTP.

Enter:

/sbin/init.d/xntpd start

7. Verify the synchronisation.

Enter:

ntpq -p



The synchronisation may take a couple of minutes. Current reference timeservers 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

1. Log in to the DHCP server.

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

3. 5.2.1 Configure SNMP.

4. 5.2.2 Configure NTP.

5.2.1 Configuring SNMP

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

5.2.2 Configuring NTP

For instructions on configuring NTP, see section 5.1.4 Configuring the networktime 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 thenetwork time protocol (NTP).

For moving the zones managed with GNS under the management of the NetActDNS please refer to Appendix A Moving GNS-managed zone(s) under themanagement of the NetAct DNS.



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


Configuring BIG-IP

6 Configuring BIG-IPThis chapter provides the instructions you need for activating Nokia NetActsupport for a BIG-IP network element. It also describes how you can set trapdestinations and community strings for BIG-IP network element and how youenable SNMP.

6.1 Configuring BIG-IP 4.5

For integrating a BIG-IP 4.5 network element to Nokia NetAct, you need to havethe version 4.5PTF7 (or later) installed and HotFix-C119009.tgz has to beinstalled 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

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 upa normal SNMP configuration (for specific instructions, see BIG-IPmanual.

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



Note

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

10. You need to perform different tasks if the configuration is a newconfiguration 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 routedto specific files or message handling applications. The F5 Networkssoftware uses the following facilities:

• local0.*

• local1.*

• local2.*

• auth.*

• kern.*

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

2. Using a text editor, open the /etc/syslog.conf file and locatethe lines near the bottom of the file that contain information similarto the following:

#/local0.* /var/run/trapper

3. Remove the number (#) symbol from each of the facilities for whichyou 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.conffile with /etc/snmptrap.conf.example file as follows.

Back up the original snmptrap.conf file to snmptrap.conf.ORG before youoverwrite it.

cp /etc/snmptrap.conf.example /etc/snmptrap.conf

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


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 havethe 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 andSNMP Access.

Add Nokia NetAct IP address to the Client Allow list.



Figure 22. 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 trapdestination.


Configuring BIG-IP

Figure 23. SNMP Destination pane

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



Figure 24. New trap record pane

To enable BIG-IP to send NE3S (Nokia SNMP) traps, you need to perform thefollowing tasks. Ensure that the BIG-IP network element is configured (taskscompleted) 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 <ip address of BIG-IP>

2. Enable Alertd.Nokia.Alarm.

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

# bigpipe db Alertd.Nokia.Alarm enable


Configuring BIG-IP

3. Restart Nokia snmpd.


# bisgtart restart nokiasnmpd

4. Restart alertd.


# bigstart restart alertd


Configuring a router

Note

Note

7 Configuring a routerThis chapter provides instructions on how to enable a router to send traps to NokiaNetAct and accept SNMP get requests from Nokia NetAct. It also describes howyou 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 routerand switch in Integrating DCN Backbone to NetAct.

For the username and passwords that you need for implementing the followingsteps, contact the router administrator.

Before you start integrating a router into Nokia NetAct, perform the preliminarytasks that are described in Chapter 3 Preliminary tasks for Packet Core NEintegration.

7.1 Configuring SNMP for a router

The following instructions are valid for the Cisco routers only.

You can configure a router to send SNMP traps to Nokia NetAct when certainevents occur. Nokia NetAct handles these traps as fault management events,which can be viewed in Alarm Monitor and are stored in the database of thenetwork element that sent the original trap.

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



To configure SNMP for a router

1. Open a Telnet session to the router.

% telnet <router>

where <router> 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:

# configure terminal

6. Enter the password for the configure mode.

7. Configure the types of traps that the router sends and the IP address ofosscore2 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 <IP address> version 1 public snmp syslog tty config


Configuring a router

where <IP address> is the IP address of osscore2 to which the routersends traps.

8. Go back one level by pressing CTRL+Z.

9. Save the configuration by entering:

# write memory

10. Exit the Telnet session.


Providing users access to NetAct applications and network elements

8 Providing users access to NetActapplications and network elements

To provide users of a group access to the network through the applications inNetAct, you need to check or create Maintenance Region service users andassociate them with the service types the users in the group will need. For theNetAct applications to be able to use this MR service user, it must be connectedwith the user group. This connection allows the users in the group to access anetwork MR service user (for example Remote MML access or Generic NE FTPaccess). For the members of the group, the access to managed objects (NEs) willbe transparent.

To ensure the users have access to Network Elements, check if the MaintenanceRegion 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 witha particular NE, see Service types in System Administration Principles. Forinstructions how to create user groups and set service accesses, see NetActPermission Manager Help and Managing Service Users in Managing Users.


Verifying integration

Note

9 Verifying integrationThis 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 networkelements.

9.1.1 Verifying IP connectivity

After the network element has been installed and configured, check that theconnection 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 SSHconnection is available, depending on the configuration.

3. Open the Element Manager from NetAct to the NE.

9.1.2 Verifying performance management data flow for IP platformnetwork elements

Check that PM data is arriving from the NE to NetAct.

Perform the check only for NEs which produce PM data and for which NetActprovides PM support.



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>

measurement table A measurement table as defined in the databasedescription, and into which you are receiving PM data.

3. Wait for a measurement time, depending on the NE, and give samecommand 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 NokiaNetAct. Generate a test alarm from Voyager interface by disabling oneidle/unused network interface temporarily in order to create alarm Interfacedown. If test alarms cannot be created safely from Voyager, they can also becreated directly from the NE console interface.

1. Open either Telnet or SSH connection to the NE with administrativeaccount.

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.

3. Select some alarm from the list.

4. Generate test alarm with the command:



fmc alarm <alarm number> 'Test_Alarm' `date`

5. If the alarm is created successfully, the ID number of that particular alarmappears 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.

9.1.4 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 & ConfigurationMgmt → Software Mgmt → Download Software Package ... from thepop-up menu of the NE.

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

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

9.1.5 Verifying Element Manager launch

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



To start an element manager from an MO

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

2. Select an element manager (EM) application from the pop-up menu. Forexample, click SSH Session... for SSH.

For a list of the available EMs for the various MOCs, see Table Alivenesssupervision applications and EMs for Packet Core MOCs in ConfiguringPacket Core Adaptation.

If the pop-up menu does not list any EMs, start Status Check... to performa ping to the NE.

If launching the EM or executing Status Check is successful, the MO has beencorrectly 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 andGNS

Check that PM data is arriving as presented in section 9.1.2Verifyingperformance 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

1. Open Alarm Monitor application in Nokia NetAct.

2. Apply the Configuration Change trap (EnablesystemTrapConfigurationChange traps) with Nokia Voyager.

3. Click Apply twice.



4. The Temporary Configuration change trap appears in AlarmMonitor.

9.2.3 Verifying configuration management for CG, DHCP Server and GNS

For instructions on testing SW download, see 9.1.4 Configuration managementfor 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 NokiaNetAct by starting an element manager application from the pop-up menu of theMO 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 tocheck.

2. Select an element manager (EM) application from the pop-up menu. Forexample, click SSH Session... for SSH.

For a list of the available EMs for the various MOCs, see Table Alivenesssupervision applications and EMs for Packet Core MOCs in ConfiguringPacket Core Adaptation.

If the pop-up menu does not list any EMs, start Status Check... to performa ping to the NE (this is not available for all NEs).

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

For troubleshooting instructions, see Troubleshooting System ManagementProblems, Troubleshooting Fault Management Problems and TroubleshootingPerformance Management Problems.


Where to find more information

10 Where to find more informationThis document is meant to be used together with other Nokia NetAct documents.

Nokia NetAct documentation

• For more information on creating additional managed object classes withthe Managed Object Class Adding Tool (MOECAT), see ConfiguringNetAct for 3GPP CORBA Northbound Interface.

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

• For information on monitoring, see Monitoring Principles.

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

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

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

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

• For information on troubleshooting, see Troubleshooting FaultManagement Problems and Troubleshooting Performance ManagementProblems.

• For instructions on DNS, see DNS Management Principles and Managingthe DNS with NetAct

• For information on configuring Cisco router and switch, see IntegratingDCN Backbone to NetAct.

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

Related non-NetAct documentation

• NameSurfer documentation set



Related non-Nokia documentation

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


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

Appendix A. Moving GNS-managed zone(s) under the management of theNetAct DNS

This appendix describes moving zone(s) managed with GNS under themanagement of the NetAct DNS.

DNS management related issues are covered in documents DNS ManagementPrinciples and Managing the DNS with NetAct.



Figure 25. Zone transfer from GNS to NetAct DNS

GNS NetAct DNS environment

Backup DNS data in the GNS

IFNameSurfer isprimary Name

ServerTHEN

BIND basedprimary DNS

NO

YES

NO

YES

BIND based slave DNS

NameSurferbased

primary DNS

NO YES

Create newzones

as master forBIND primary

Re-start BINDprocess

Transfer DNSzone data to new

masterName Server

CheckIF

Name Server haszones required by

GNSTHEN

Create newzone master

files

Modify SOAResourcerecords

for new zones

Re-start BINDprocess

Changetransferred zone types to slave

Check andmodifyzone

contents

Load new zonesto NameSurfer

from GNS

Change SOAResource Record

details fornew zones

CheckIF

all authoritativezones exist

THEN

Add zones

Move zonecontents



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


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

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

3. Based on the command output the required zones and the correspondingzone files can be located from the GNS.

A.1.1 NameSurfer is not the primary Name Server

To transfer the DNS zone data to a new master Name Server whenNameSurfer is not the primary Name Server

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



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

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

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

A.1.2 NameSurfer is the primary Name Server

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

A.2 NetAct DNS environment

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

To check the primary DNS zone files in NetAct with BIND

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 thezone files that BIND primary Name Server in NetAct has.

A.2.1 Name Server has zones required by GNS

To check and modify the zone contents

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



Note

Note

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

Make sure to do the editing carefully, as any extra or missing information mightcause the DNS to malfunction.

2. Re-start BIND in SS with the command:

root% rndc reload

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

A.2.2 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.

Make sure to do the editing carefully, as any extra or missing information mightcause the DNS to malfunction.

4. Re-start BIND in SS with the command:

root% rndc reload

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



Note

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 primaryName Server in the Global Cluster

1. Open NameSurfer Web UI by using the web browser and thecorresponding URL as for example:

http://<IP address of Global Cluster OSSCORE SG package>:8053

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

3. If NameSurfer has zone(s) required by the GNS there is no need to createnew corresponding zones. However, check the zone contents carefully.

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

Make sure to do the editing carefully as any extra or missing information mightcause the DNS to malfunction.

OR:

If NameSurfer does not have the zone(s) required by the GNS, you need tocreate the corresponding zone(s) by copying it into the NameSurfer fromGPRS Name Server:

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

http://<IP-of-Global-Cluster-OSSCORE-SG-package>:8053

2. After a successful login to the NameSurfer Web UI the Index pageis displayed.

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



Note

4. On the Copy from other name server page fill in:

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

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

and click OK.

5. On the Zone Root <name of the zone> page modify the SOAResource Record and authoritative Name Servers of the zones to theZone Root page:

• Modify Master NS and Admin email address of the SOAResource Record as in the following:

Figure 26. Master NS and Admin email address of the SOA Resource Record

Start of Authority (SOA) object is defined in NameSurfer as in the followingexample.

Figure 27. SOA object in NameSurfer

• Modify authoritative Name Server for the zone as in thefollowing:

Figure 28. Authoritative Name Server for the zone



If the Zone Root page displays only one empty field foradding new authoritative Name Server, follow theinstructions in the following:1. Add only one FDQN on the field and click OK.

The Zone <name of 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 asthe zone.The Zone Root <name of zone> page is displayed.

3. Add another FQDN on the next empty field underAuthoritative NameServers (NS) and click OK.

4. Go to step Close the NameSurfer Web UI.

• Scroll down on the page and click OK.

The Zone <name of zone> page is displayed.

6. Close the NameSurfer Web UI.

A.2.4 All authoritative zones exist in BIND based slave DNS

If all authoritative zones exist, go to procedure To configure zones as slaves forBIND 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 NetActas root user.

2. Check that Name Server in the DS is backing up all the zones that the NameServer 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 thezones managed by Name Server in SS, create the missing zones as slavesfor the Name Server in the DS.

4. Re-start BIND in the DS with the command:

root% rndc reload



5. Verify that all created zones are downloaded with the correct SerialNumber 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 aremodified, continue with the instructions on Configuring zones as slaves forName Server in the GNS.

A.3 GNS

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

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


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 zonerespectively about the primary Name Server application in use on theGlobal Cluster. That is done for all zone statements in the file excluding thezone "0.0.127.in-addr.arpa".

See the following examples about zone statement differences regardingprimary Name Server application in use:

zone "netact.done.fi" {type slave ;file "db.netact" ;masters {<IP address of the primary DNS> ;} ;} ;

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 {<IP address of the primary DNS> ;} ;} ;

Figure 30. Example of a zone statement for NameSurfer based primary NameServer



4. Re-start BIND on GNS with the command

root% rndc reload

5. Verify that all changed zones are downloaded with correct Serial Numbersfrom the correct IP address and the port of the primary Name Server andthere are NO error messages in the /var/adm/syslog/syslog.logabout 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 PrimaryName Server is completed.


IndexNumerics

3G network elements 353G -SGSN 363G SGSN

checking time zone 50checking version 21event logging 50management connection 13platform 13time setup 50what it does 13

A

alarm flowchecking 84

alarms 84ATM 13

B

BG 36big IP adaptation

See BIGI 36BIGI 36border gateway

See BG 36

C

CA 36CG 36Charging Gateway

See CG [CG:charging g ] 36Content Analyser 36

D

DHCP servers 36DNS

configuring in 3G SGSN 44DNS 14, 36, 43

E

element managerslaunching 83, 85

Ethernet switches 36

F

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

G

Gateway GPRS Support Node 11gateway GPRS support node

See GGSN [GGSN:gateway gprs ] 37generic GPRS network elements 37get community string 39, 41GGSN 11, 37GGSN interfaces 37GNS1 45GNS2 45GPRS 11GPRS domain name 45GPRS name server

See secondary GPRS name servers 37GPRS name servers 45GPRS network elements 35GPRS site 37GPS 49

I

integrationverifying 81

IP interfaces 37IP switches 37IP3400 13IP650 11IP740 11IPSO

checking version 22correct version 20

IPSO 13

L

Lawful Interception Gateway 37LIG 37location areas 38

M

main hostname 39, 40Managed Objects 40management connection 13

DN00297251 ©Nokia Corporation 99 (100)Issue 7-1 en Nokia Proprietary and Confidential


marker and charging unitSee MCHU 38

MCHU 38

N

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

O

OSPF 48

P

Packet Core network 38Packet Core subnetwork 38packet processing unit

See PAPU 38PAPU 38parent objects 40PCM lines 38Performance Management 35primary name server 43, 45

R

router 9, 14, 23, 24, 38

S

secondary GPRS name servers 36, 37secondary name server 45set community 41set community string 39SNMP

community strings 75configuring 54

SNMP 13, 14, 15, 53SNMP -specific database attributes 39SNMP traps 75, 76start an Element Manager 84, 85STM -1 13switch 9, 14System Server 52

T

TCP/IP 49time zone 51

U

UDP address 39, 41

V

VLR -LA association 38Voyager

password 21username 21

W

WA 38


Integrating Packet Core Network Elements to NetAct

Documents

Transcript of Integrating Packet Core Network Elements to NetAct