Shasta GGSN: OA&M - Student Guide

Course UM642
GPRS 4.0 & UMTS 2.0

Shasta GGSN
OA&M - Student Guide
GGSN 2.0 Standard 03.05 September 2002

GPRS 4.0 & UMTS 2.0
Shasta GGSN
Course number: Course UM642

Product release: GGSN 2.0
Document version: Standard 03.05
Date: September 2002
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright  2000-2002 Nortel Networks, All Rights Reserved

Originated in the United States of America and Canada
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees
with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree
of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in
writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
Contivity, Shasta and Nortel are trademarks of Nortel Networks. All other trademarks are the property of their respective owners.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
iv Nortel Networks Confidential
Course UM642 Standard 03.05 September 2002For training purposes only

Nortel Networks Confidential v
Publication history
September 2002, Standard 3.05
This is the first Standard version of this student guide.
June 2002, Preliminary 3.04

This Preliminary version supports GPRS 4.0 and UMTS 2.0 functionality.
Exercises have been removed (they will be described by the instructor). Many
errors and inconsistencies have been addressed; these corrections are the
result of internal review.
May 2002, Preliminary 3.03

This Preliminary version supports GPRS 4.0 and UMTS 2.0 functionality.
Slides have been re-ordered for better flow. Support for Single APN
configurations is described. Errors and inconsistencies, especially in Lessons
2, 4 and 6 have been addressed.
February 2002, Standard 2.03

This Standard version supports GPRS 3.0 and UMTS 1.2 functionality. Slides
have been re-ordered for better flow. Network model terminology has been
updated. The discussion of network models has been combined into a single
lesson.
January 2002, Standard 2.02

This is an initial Standard version.
November 2001, Preliminary 2.01

New material was added to support GPRS 3.0 and UMTS 1.2 features.
Information on CORBA was added. Slides depicting protocol stacks for each
network access model were added. Slides were re-ordered for better flow.
New content was added to Lesson 9. Numerous changes were made
throughout as a result of suggestions.
GPRS 4.0 & UMTS 2.0 Shasta GGSN OA&M - Student Guide GGSN 2.0
vi Publication history Nortel Networks Confidential
September 2001, Preliminary 1.02

In this version, numerous changes were made throughout as a result of
suggestions from subject matter experts. The contents of the appendix have
been moved into “About this document”. Slides and exercises for a module
now appear in the same chapter.
May 2001, Preliminary 1.01

First version of this course, based on GPRS 2.1 and UMTS 1.1 features. This
Student Guide contains the embedded images of Power Point slides,
additional notes, plus information about the exercises.

Nortel Networks Confidential vii
Contents 1
About this course ix
Introduction ix
Items of prerequisite knowledge ix
Course concepts xi
Course objectives xii
Course agenda xiv
Support material xiv
Lesson 1
Welcome and introduction 17
Course UM642 layout 18
Lesson 1 - slides 20
Lesson 2
Review: the GGSN in GPRS / UMTS networks 27
Lesson 3
Software overview and installation 55
Lesson 4
Configuration: basic 75
Lesson 5
Configuration: network access models 95
viii Contents Nortel Networks Confidential
Lesson 6
Configuration: IP services 129
Lesson 7
Introduction to maintenance and troubleshooting 167
List of tables
Table 1 Course UM642, prerequisite knowledge x
Table 2 Course UM642, concepts reviewed or taught in class xi
Table 3 Course UM642, objectives xii
Table 4 Course UM642, organization xiv
Table 5 Network model configuration options 98
Table 6 IP services and network access models 136
Table 7 Firewall policy 142
Table 8 Simple IP security rules 144
Table 9 Simple IP VPN security rules 144

Nortel Networks Confidential ix
About this course

The sections in this chapter start on the page shown below:
Exercise Starting page

“Introduction” p. ix
“Items of prerequisite knowledge” p. ix
“Course concepts” p. xi
“Course objectives” p. xii
“Course agenda” p. xiv
“Support material” p. xiv
Introduction 0
The Shasta GGSN OA&M course, building on your understanding of GPRS
and UMTS network concepts as well as the Shasta hardware, will give you
the theoretical and practical knowledge needed to perform the main tasks
associated with operating and provisioning a Shasta GGSN. This is a leader-
led, hands-on course. Each module has two types of activities: lecture by the
instructor, followed by structured activities (labs) performed by the student.
Each of these activities is described in this Student Guide, which in turn
references NTP #411-5221-927, Shasta GGSN Procedures Reference
Manual.
Items of prerequisite knowledge 0

Familiarity with prerequisite knowledge and skills is necessary for you to
succeed in this course. You must meet the “Essential” criteria listed in Table
1, and will be helped if you also meet the optional “Desirable” criteria. A pre-
x Nortel Networks Confidential
test and/or equivalency test will be used to determine your incoming

knowledge level.
Table 1: Course UM642, prerequisite knowledge
Item # Description Importance
1 understand layout of GPRS or UMTS networks, by one or more of these: Essential

• take Nortel Networks Course UM10, UMTS System Description
• take Nortel Networks Course GP01, GPRS Technical Overview
2 understand roles of GGSN in GPRS network, by one or more of these: Essential

• read NTP #411-5221-926, Shasta GGSN User Guide
• take Nortel Networks Course UM31, GGSN Detailed Description
3 understand basic functions of a BSN - such as perform aggregation, apply Desirable

IP services, perform routing. This can be gained by taking Nortel Networks
Course 2728, Shasta 5000 Broadband Service Node (BSN) Overview.
4 have a working knowledge of the English language in order to effectively Essential

interact with the Shasta user interface
5 understand the Windows environment on a PC enough to launch an Essential

application, and navigate through a graphical user interface
6 understand IP and networking fundamentals sufficiently to: Essential

• interpret a network diagram
• be able to work with applications such as FTP (server and client), Ping,
Telnet, and a web browser
• understand the structure of the Internet
• understand IP addressing and subnets
• be familiar with Wide Area Networking (WAN) protocols such as
Asynchronous Transfer Mode (ATM) and Frame Relay
• be familiar with Local Area Network (LAN) protocols such as Point-to-
Point Protocol (PPP) and Point-to-Point Protocol over Ethernet (PPPoE
• be familiar with routing protocols such as Open Shortest Path First
(OSPF), BGP4, and Routing Information Protocol (RIP)
7 understand data communications fundamentals enough to be familiar with Essential

topics such as packet headers and the OSI model
8 understand the concepts behind different types of IP services (such as what Desirable
are Differential Services and why is it important to regulate Quality of
Service?)
9 understand the underlying wireless technology of GSM or UMTS networks Desirable

Nortel Networks Confidential xi
Table 1: Course UM642, prerequisite knowledge (continued)
Item # Description Importance
10 understand the UNIX environment enough to issue the commands needed Desirable
to configure the Shasta SCS server
11 understand the VxWorks environment enough to issue the commands Desirable

needed to interact with the Shasta Command Line Interface
Course concepts 0
Table 2 contains a list of concepts reviewed or taught in class. Each concept is
mapped to the module in the course in which it is reviewed or taught.
Table 2: Course UM642, concepts reviewed or taught in class
Item # Description Course module
1 describe roles of GGSN in GPRS network 2
2 list three basic access models 2
3 describe key functions and features of Shasta GGSN 2
4 list and describe IP services enabled by Shasta GGSN 2
5 describe the various types of tunneling connections 2
6 understand interaction between SCS and the network management 2

system
7 understand remote-access architectures 2
8 understand transparent and non-transparent access 2
9 understand load-balancing capabilities of the Shasta GGSN 2
10 understand redundancy capabilities of the Shasta GGSN 2
11 understand what utilities are needed in operations and provisioning 3

(such as Ping, Telnet, FTP, traffic generators)
12 understand file architecture of iSOS storage, directories (such as to 3

know where to FTP files, how to perform two types of reboot)
13 understand file architecture of SCS storage, directories (such as to 3
know where to find accounting records, event logs)
14 understand differences between SCS and CLI interfaces (what are 3

the limitations of each? who should be able to access each?)
15 describe the roles of “device owner” 4

16 describe the roles of “ISP user” 4
xii Nortel Networks Confidential
Table 2: Course UM642, concepts reviewed or taught in class (continued)
Item # Description Course module
17 describe the management capabilities of the SCS 4
18 describe the diagnostic capabilities of the SCS 7
19 describe the diagnostic capabilities of the CLI 7
20 know how to find and interpret software alarms, messages, and logs 7
21 know the meaning of hardware indicator lights and displays 7
22 how to find out about Nortel Networks technical bulletins and 7

upgrade notices
Course objectives 0
Table 3 lists the tasks which are considered essential to the operation and
provisioning of a Shasta GGSN. The course’s objective is to have you be able
to perform the following tasks. Each task is mapped to the module in the
course in which it is taught.
Table 3: Course UM642, objectives
Task # Description Course module
1 acquire, install/update LDAP and SCS server software, on-site or 3

remotely
1b acquire, install/update SCS client software 3
2 acquire, install/update Shasta GGSN software, on-site or remotely; 3

know how to use “quick start” utility
3 use the SCS client interface - know how to navigate 3

4 use the CLI interface - know key commands 3
5 use on-line help in SCS 3
6 use on-line help in CLI 3

7 create an SCS region 4
8 add a GGSN to an SCS region 4
9 set the default IP address on the GGSN and on an ISP 4
10 use SCS to configure each card in a chassis 4

Nortel Networks Confidential xiii
Table 3: Course UM642, objectives (continued)
Task # Description Course module
11 perform initial deployment configuration on a GGSN: 4

• create Gn and Connection ISPs
• create SCS Users and Passwords as required.
• define the BSN using Device Manager.
• define as many Trunk Connections and Interfaces as needed to
support the required data throughput. Implement routing protocols
on trunk interfaces. Interface with SGSN.
• configure routing protocols on the trunk interfaces to enable routing
through the external routers.
• define Pull Servers and Log Servers.
12 Configure interface between the SCS server and network management 4

software
13 configure components that are common to all network access models: 4
14 configure additional components for the Wireless ISP network model 5

15 configure additional components for the L2TP VPN network model 5
16 configure additional components for the IPSec VPN network model 5
17 configure additional components for the Shasta GGSN VPRN network 5

model
18 create / apply templates for DiffServ Marking 6
19 create / apply templates for accounting 6
20 create / apply templates for traffic shaping 6
21 create / apply templates for policing 6
22 create / apply templates for personal network portal & policy-based 6

forwarding
23 perform synchronization between SCS and GGSN 7

24 verify hardware functionality 7
25 perform shut down & restart - includes put in service, take out of service 7
26 perform records maintenance (such as backing up event log files) 7

27 monitor and interpret performance statistics 7
28 use SCS to monitor status of cards in a chassis - such as alarms, logs, 7

indicators
xiv Nortel Networks Confidential
Course agenda 0
The course will be organized as shown in Table 4 below.
Table 4: Course UM642, organization
Day Module Duration Concept Task

(hours) (Table 2, (Table 3,
p. xi) p. xii)
Day 1
1 - Welcome and introduction 0.25 n/a n/a
Pre-test 0.25
2 - Review: the Shasta GGSN in GPRS / UMTS 1.0 1-10 n/a

networks
3 - Software overview 1.0 11-14 3-6
4 - Configuration: basic 3.0 15-17 7-13
Day 2
4 - Configuration: basic (continued) 1.0 15-17 7-13
5 - Configuration: network access models 4.5 n/a 14-17
Day 3
6 - Configuration: IP services 4.0 n/a 18-22
7 - Introduction to maintenance and troubleshooting 1.0 18-22 23-28
Post-test 0.25
Course evaluation 0.25
(Optional) Installation of GGSN versions of LDAP n/a 1-2

Server, SCS Server, and iSOS software
Support material 0
This is a list of other information sources which may help you understand the
operation of the GPRS and UMTS networks:
• GPRS Conformance Guide, 411-5221-201
• Core Network Troubleshooting Guide, 411-5221-501
• GGSN Users Guide (Shasta), 411-5221-926
• Shasta GGSN Procedures Reference Manual, 411-5221-927
• SGSN Users Guide, 411-5221-955
• SIG Users Guide, 411-5221-957

Nortel Networks Confidential xv
• SGSN Parameters, 411-5221-110

• GPRS 1.5 to 2.0 Delta, 411-5221-199
• GPRS SGSN CDR, 411-5221-204
• GPRS 1.5 to 2.0 Upgrade Manual, 411-5221-303
• Wireless Gateway User's Guide, 411-8111-903
• Document suite for Shasta BSN, Release 2.5. In particular,
— Shasta 5000 Broadband Service Node Service Creation System
Installation Guide (p/n 01446)
Overview (p/n 01447)
Configuration Guide (p/n 01449)
— Shasta 5000 Broadband Service Node Command Line Interface
Guide—Administration (p/n 01451)
— Shasta 5000 Broadband Service Node Command Line Interface
Guide—Protocols (p/n 01452)
— Shasta 5000 Broadband Service Node Hardware Installation and
Maintenance Guide (p/n 01453)
— Shasta 5000 Broadband Service Node CORBA API Applications
Installation Guide (p/n 01457)
— Shasta 5000 Broadband Service Node CORBA API Applications
Guide (p/n 01458)
— Shasta 5000 Broadband Service Node ISOS Upgrade Note
(p/n 01461)
— Shasta 5000 Broadband Service Node Troubleshooting Guide
(p/n 01462)
— Shasta 5000 BSN Release Notes (p/n 01463)
Note: The Shasta BSN documents do not reflect a wireless configuration.

While there is much in common with BSN and GGSN deployment, there
will be significant differences. Be mindful of these differences.
xvi Nortel Networks Confidential

Nortel Networks Confidential 17
Lesson 1
Welcome and introduction
This chapter contains slides and notes for the “Welcome and introduction”
session, and for Lesson 1.
18 Lesson 1 Welcome and introduction Nortel Networks Confidential
0
Course UM642 layout 0
The length of this lesson, and the material to be covered, is as follows:
Module Duration Concept Task

(hours) (Table 2, p. xi) (Table 3, p. xii)
Welcome and introduction 0.25 n/a n/a
Notes:

Nortel Networks Confidential Lesson 1 Welcome and introduction 19
0
Lesson 1 - slides 0
After an initial welcome, personal introductions, and a description of the
training facility (such as location of washrooms, cafeteria, and fire escapes),
the course will begin with an explanation of the course objectives.
This module does not include any exercises.
Notes:

Course UM642 objectives 0

What this course is NOT about:
• network engineering
• installation and commissioning activities
• troubleshooting, although a brief overview is provided
What this course IS about:

• the Operation, Administration and Maintenance (OA&M) of the Nortel
Networks’ Shasta Gateway GPRS Support Node (GGSN).
The detailed list of objectives is contained in Table 2 (p. xi) and Table 3
(p. xii).
It is assumed that you are familiar with GPRS / UMTS and Internet Protocol
(IP) data-networking concepts.
Notes:

Course UM642 format & materials 0

Course UM642 is an instructor-led course designed to provide hands-on
experience with the Shasta GGSN by performing operations and provisioning
procedures.
Practical exercises will be preceded by introductory information delivered in

lecture format.
You will use the following materials:

• The Student Guide is organized in presentation format in a series of
lessons that are to be used by the instructor as a the course guide. This
document has copies of the slides used in class, additional notes, and
descriptions of the exercises (details of which are in the Shasta GGSN
Procedures Reference Manual).
• The Shasta GGSN Procedures Reference Manual
(NTP 411-5221-927) contains procedures for exercises. After each
lecture, the instructor will direct students to the appropriate exercise(s).
Notes:


Lesson 2
Review: the GGSN in GPRS / UMTS
networks
This chapter contains slides and notes for Lesson 2.
28 Lesson 2 Review: the GGSN in GPRS / UMTS networks Nortel Networks Confidential
0
Lesson 2 - slides 0
This module reviews the role of the GGSN in GSM/GPRS and UMTS
networks. It also details GGSN functionality, hardware, and basic subscriber
data flow.
This lesson does not include any exercises.

Review: the Shasta GGSN in GPRS / UMTS 1.0 1-10 n/a

networks
Notes:

Nortel Networks Confidential Lesson 2 Review: the GGSN in GPRS / UMTS networks 29
GPRS - Bearer services for GSM 0

GPRS is a set of bearer services for GSM networks. It provides mobile
subscribers with the ability to send and receive data to and from external
packet data networks (PDN) using packet switched rather than circuit
switched technologies, and it allows service providers to apply IP services to
subscriber data flows.
In order to add GPRS services to an existing GSM architecture, two GPRS

support nodes (GSN) are added to the GSM architecture: the serving GPRS
support node (SGSN) and the gateway GPRS support node (GGSN). The slide
• shows the new GSNs within a GSM/GPRS system
• details the GSM communication interfaces that connect them to other
nodes in the system
• contrasts the packet versus circuit switched data paths.
The GSNs are responsible for mobile station (MS) connection to the network,
authentication, route initialization, packet routing to and from external packet
data networks, application of IP services, and charging functions.
• The serving GPRS support node (SGSN) which is at the same hierarchical
level as the MSC, keeps track of the individual MS location and performs
security functions and access control. The SGSN is connected to the base
station system with Frame Relay.
• The gateway GPRS support node (GGSN) provides internetworking with
external packet-switched networks, and is connected to SGSNs via an IP
based GPRS backbone network.
In order to access the GPRS services, an MS has to register with the SGSN.
The SGSN then facilitates setting up a packet data context between the MS
and the GGSN. Once a packet data context exists between the MS and GGSN,
interworking with external data networks can commence. All subscriber
traffic is tunneled between the SGSN and GGSN using the GTP protocol
Communication interfaces define how network nodes communicate with each

other. They are specific to certain nodes, and specify what protocols are used
to communicate with other nodes that support the same interfaces. The SGSN
and GGSN communicate with each other through the Gn interface. The
GGSN communicates with external packet data networks through the Gi
interface. Inter-PLMN communication is carried out through the Gp interface.

circuit switched (GSM)

data path
PLMN 1
SMS-GMSC
MSC/VLR SMS-IWMSC HLR
Gs Gd Gr
TE MT BTS
R Um packet switched
data path (GPRS)
MS to external PDN
BSC SGSN GGSN
Gb Gn Gi
Gp
BTS
BG
data path
BG border gateway
BSC base station controller border gateways are
used to connect GSNs
BTS base transceiver station
in different PLMNs
GGSN gateway gprs support node
HLR home location register
MS mobile station
MT mobile terminal
PLMN 2
MSC mobile services switching centre BG
PDN packet data network

SGSN serving gprs support node packet switched data
TE terminal equipment GGSN path (GPRS) routed
Gi to a different PLMN
VLR visiting location register
Notes:
UMTS 0
Unlike GPRS which is a set of bearer services for GSM networks, UMTS is a
complete telecommunications network capable of delivering advanced
teleservices and bearer services. The integrated voice and data packet core
network and next generation technology for the radio access network offers
high data capacity that allows multimedia and a variety of services.
In order to deliver UMTS in a time scale suitable to the mobile industry,

UMTS has evolved from GSM/GPRS rather than starting from scratch. As
such, UMTS and GSM/GPRS networks use similar equipment to provide
similar functionality, especially in the packet core network where the
equipment and the interfaces are the same. The GGSN has the same role and
functionality in UMTS as it does in GSM/GPRS. It acts as the interface to
external public data networks and applies IP services to subscriber data flows.
The GPRS standards have been modified for UMTS to include the following
enhancements.
• The reworking of the system’s quality-of-service (QoS) to enable more
effective QoS between the mobile station and the external packet data
networks. UMTS enables end-to-end quality of service between two
terminals. UMTS also enables multiple QoS flows for a single IP address.
• The replacement of Frame Relay with Asynchronous Transfer Mode
AAL5 between the SGSN and Radio Network Controller (RNC).
Asynchronous Transfer Mode is now the fundamental transport layer
protocol linking all the different nodes in the infrastructure domain.
• The introduction of a new version of the GPRS tunneling protocol. The
new version reduces encapsulation overhead. But more significantly, the
control plane (used for signalling) and the user plane (used for data
transfer) have been separated such that the user plane protocol can now be
used between the SGSN and RNC. This means that a GTP tunnel is
established between the SGSN and RNC for the transport of user traffic.

GPRS 2G-PLMN
Gb Gr
MS BSS SGSN HLR
Gp
BG
UMTS 3G-PLMN1
BG
Uu Node
UE B
Iub
RNC Gr
Node
B
VMG
SG
Iu Gn Gi
RNC 3G-SGSN 3G-GGSN PDN
Wireless Gateway
BG
BG border gateway
BSS base station system
GGSN gateway gprs support node
UMTS 3G-PLMN2
HLR home location register BG
MS mobile station
Gp
PDN packet data network
RNC radio network controller
VMG
SG signalling gateway
SGSN serving gprs support node SG
Iu Gn
UE user equipment RNC 3G-SGSN 3G-GGSN
VMG virtual media gateway Wireless Gateway
Notes:
GGSN interfaces and protocols 0

The following GGSN interfaces are common to both GPRS and UMTS
networks.
• Ga: interface between GGSN and CGF (Charging Gateway Function) for
billing.
• Gi: interface between GGSN and external Packet Data Network (PDN)
• Gn: interface between GGSN and SGSN. The Shasta GGSN establishes,
maintains, and terminates logical links to the radio network across this
interface. In this sense, the GGSN acts as the “gateway” between the
GPRS / UMTS radio network and the land-line packet network.
• Gp: interface between GGSN and an SGSN in a Visiting Public Land
Mobile Network (VPLMN)
Legend for slide on opposing page:

• CGF: Charging Gateway Function
• CLI: Command Line Interface
• CORBA: Common Object Request Broker Architecture
• CTP: Card Telephone Protocol
• DHCP: Dynamic Host Configuration Protocol
• GTP: GPRS Tunneling Protocol
• GTP’: GPRS Tunneling Protocol for Accounting
• RADIUS: Remote Authentication Dial In User Service
• SCP: Service Control Point
• SCS: Service Creation System
• SGSN: Serving GPRS Support Node
• SMP: Shasta Management Protocol
• SNMP: Simple Network Management Protocol
• WRAP: Wireless RADIUS Application Protocol

Notes:
GGSN functionality 0
Previous sections have detailed where the GGSN is situated in GSM/GPRS or
UMTS networks. The gateway GPRS support node (GGSN) provides
interconnection between the PLMN network and a particular PDN, which can
be internet service provider (ISP) or corporate intranet. The GGSN supports
different network access models for connection with external PDNs and is
primarily responsible for packet routing and access control to these PDNs.
Within this context the GGSN carries out
• authentication: the GGSN authenticates (if required) the user and
determines what network services the user is entitled to. The GGSN
supports authentication via AAA RADIUS server.
• address allocation: the GGSN assigns the required network addresses to
the MS so that it can be identified to external networks. The type of
addresses depends on the network access model used for the session. The
following methods are supported:
— local address pools on the GGSN.
— external DHCP server (GGSN is the DHCP client on behalf of the MS
or DHCP relay agent).
— RADIUS (only if authentication is done by means of RADIUS): a
static address for each user is provisioned in the RADIUS server.
Dynamic allocation by RADIUS server is supported in GGSN 2.0.
• routing: the GGSN uses routing tables to determine where to forward
subscriber data packets. The GGSN converts the MS packets coming from
the SGSN into the appropriate packet data protocol (PDP) format and
forwards them to the corresponding PDN. In the reverse direction, it
receives data packets for mobile subscribers from the PDN. The packet
data network addresses of incoming data packets are mapped to the
destination user and sent to the SGSN serving that user. The GGSN
supports OSPF, RIP, BGP, and IS-IS routing protocols.
• tunneling: the GGSN supports the following types of outbound tunneling
on the Gi interface: L2TP tunnel, L2TP over IPSec, and IPSec tunnel. The
GGSN supports a GTP tunnel on the Gn interface only for communication
to the SGSN.
• IP services: the GGSN applies IP services to both inbound and outbound
traffic flows as they pass through the GGSN.
• wireless services: the GGSN supports wireless services such as tariffing
(Prepaid, Geozone) and wireless application protocol (WAP) services.
• accounting: the GGSN collects billing information and forwards the
information to a charging gateway function (CGF).
• OA&M: the GGSN collects logs, statistics, SNMP traps.

Notes:
Shasta GGSN chassis layout 0

The chassis consists of a card cage, a fan tray for cooling, and a power entry
and distribution shelf. The chassis mounts in a standard 19" rack, or in a 23"
rack using rack extenders. The chassis requires a –48 Vdc power source.
Front panel LEDs provide chassis alarm status and fan status. A DB25
connector enables you to connect the alarm outputs to an external terminal or
display.
The card cage has fourteen vertically aligned slots that house control, switching,
service processing and input/output cards. Cards are inserted and removed from
the front of the chassis. Supported cards include:
• control and management card (CMC): the CMC is responsible for
basic system operation and management of the GGSN.
• switch fabric card (SFC): the SFC is an ATM switching matrix that
provides ATM layer interconnection and queuing between the various line
cards and the processor cards.
• subscriber services card (SSC): the SSC contains the processor arrays
(subscriber service modules) used to perform service and policy
operations on subscriber dataflows.
• line cards (LC): the following line cards provides connectivity from
subscriber to PDN (ingress) and from PDN to subscriber (egress): ATM
OC-3/STM-1, Fast Ethernet, Gigabit Ethernet.
Cards and the slots on the card cage are colour coded, so that it is easy to
determine which cards go in what slots. Four colours are used.
• Blue: slots 13 and 14.
— slot 14 is used exclusively for the primary control and management
card (CMC)
— slot 13 can be used for any card except an SFC card. Usually used for
redundant CMC.
• Yellow: slots 7 and 8.
— used exclusively for primary and redundant switch fabric cards (SFC).
• Green: slots 1 to 6 and 9 to 13.
— used for subscriber services cards (SSC) or line cards (LC).
• Red: slots 5, 6, 9, and 10.
— indicates slots capable of 1.2 Gbit/s throughput. Other slots are only
capable of 622 Mbps.

Notes:
Control and Management Card (CMC) 0

The control and management card is responsible for basic system operation
and management of the GGSN. It contains both flash and disk storage for the
Shasta IP Services Operating System, configuration files, and subscriber
datafill.
As the system controller, the CMC is responsible for initializing, configuring,

and monitoring/reporting the state of operation of all GGSN cards. As the
route and data plane manager, the CMC maintains complete routing tables,
runs the appropriate routing protocols, handles all signalling protocols,
accounting, and performs system wide acceptance and connection
management.
One CMC is required for operation. It must be installed in slot 14. A

redundant CMC card can be provisioned in slot 13. If a redundant CMC card
is not required, slot 13 can be used for any other card except the SFC.
The Shasta GGSN uses the CMC-II, which features dual 10/100 BaseT ports,
and 1 GB RAM.
Note: The 10/100 BaseT ports on the CMC are not meant to carry
subscriber traffic (Gi). They can, however, be used for OA&M traffic,
RADIUS access, DHCP, DNS, Ga traffic, etc.

Notes:
Switch Fabric Card (SFC) 0

The switch fabric card (SFC) offers 10 Gbps non-blocking ATM switching
capacity using a shared memory architecture. The fabric handles the entire
data plane and some of the control plane for inter-card communication. A per
flow queueing function ensures that each subscriber flow receives an
established QoS independent of the state of other flows within the fabric.
One SFC is required for operation, and a second may be added for
redundancy. SFCs are always installed in slots 7 or 8. No other cards can be
installed in slots 7 and 8.

Notes:
Subscriber Services Card (SSC) 0

The subscriber service card (SSC) contains the processor arrays used to
perform service and policy operations on each subscriber data session. This
includes: encapsulation and deencapsulation, filtering, forwarding, wrapping
and unwrapping tunnels, application specific traffic steering, and subscription
and flow based accounting.
The SSC contains up to four Subscriber Service Modules (SSMs); the SSC is
field-upgradeable so that SSMs can be added as needed. Each SSM contains
four Subscriber Service Processors (SSPs).
Currently, supported SSCs for UMTS/GPRS applications are the SSC-II

(3DES encryption), and a version which does not support encryption. Both
feature 4 x SSMs and 512 MB RAM
The SSC can be installed in any slot, except slots 7, 8, or 14. A typical chassis
contains two to six SSCs. If the chassis contains only one CMC in slot 14,
then slot 13 can be used for an SSC.

Notes:
ATM Line Card (ALC) 0

The ATM Line Card (ALC) provides OC-3/STM-1 physical connectivity for
subscriber traffic into and out of the GGSN. It can be used on the Gi, Gn, and
Gp interfaces.
It has four ports that support either single or multi mode fibre connections.
Up to four of these cards are allowed per chassis.

Notes:
Fast Ethernet Line Card (FELC) 0

The Fast Ethernet Line Card (FELC) provides physical connectivity for
subscriber traffic into and out of the GGSN. It can be used on the Gi, Gn, and
Gp interfaces.
The FELC
• provides eight ports of Ethernet connectivity. Each port operates at either
10/100BaseT. Each port is auto-sensing to the line rate and connects to the
user network via an RJ45 and UTP cable. The FELC translates the
incoming Ethernet frames into ATM cells and steers those frames to the
appropriate SSM. In the outgoing direction, ATM cells are converted into
Ethernet frames with the appropriate MAC header.
• must be equipped in the high-speed slots 5, 6, 9, 10 in order to have full
functionality.
The card can be installed in other slots: 1 to 4, 11 to 12, and slot 13 if the
chassis contains only one CMC in slot 14. If the FELC is installed in any
of these slots, only ports 1 to 4 will be able to process traffic; ports 5-8
cannot be used in this configuration.
Up to four of these cards are allowed per chassis.

Notes:
GELC 0
The Gigabit Ethernet Line Card (GELC) has a single, full-duplex gigabit
Ethernet port that provides physical connectivity for subscriber traffic into
and out of the GGSN. It can be used on the Gi, Gn, and Gp interfaces.
The GELC:
• is primarily an egress-side interface and as such, a layer 3+ address
resolution facility is provided for the steering of packets to the correct
SSM (Subscriber Service Module) for service level processing.
• Gigabit Interface Converter (GBIC) modules allow for various media
types (e.g. short haul, long haul, copper or none) to be supported.
• The GELC must be installed in a high-speed slot (5, 6, 9, 10).

Notes:
Shasta GGSN data flow 0

Ingress data flow through the GGSN
1. Data sent by the mobile user enters the GGSN through the Gn interface.
The Ethernet port interface (EPIF) uses table lookup to determine which
subscriber service module (SSM) on what subscriber service card (SSC)
the packet has to be routed to. The destination SSM is assigned during the
create PDP context request. An internal ATM VC is used to route the
packet to its destination subscriber service card.
2. The data is then forwarded across the ATM backplane to the switch fabric
card using the ATM VC provided by the intelligent cell parser (ICP), and
is routed to the appropriate subscriber service card.
3. Within the subscriber service card, the data is routed to a specific
subscriber service processor on the specific subscriber service module, as
determined during PDP context creation.
4. The data stream is modified by any IP services that are to be applied to the
ingress data flow. Forwarding is done based on the ISP’s forwarding
information base (FIB). This provides a route entry that is an outgoing
trunk interface.
5. From the subscriber service card, the data re-crosses the switch fabric
card, exits the GGSN through the port defined for the Gn interface, and
continue on into the network.
Egress data flow through the GGSN

Data flow from the network through the GGSN to the subscriber follows the
same path as the ingress stream but in reverse. Egress mobile user traffic
arrives multiplexed on trunk lines. Individual mobile user data packets must
be isolated out of the multiplexed stream and directed to the subscriber
service processor where the subscriber context already exists for that
subscriber data session.
The intelligent cell parser on the line card uses table lookup to determine
which subscriber service processor on what subscriber service module the
packet should be sent to and routes the packet to the appropriate subscriber
service card using an internal ATM VC.
The data stream is modified by any IP services that are to be applied to the
ingress data flow. A lookup is done on the packet’s destination IP address and
the packet is dispatched to the appropriate output port.

Notes:

Lesson 3
Software overview and installation
This chapter includes slides and notes for Lesson 3.
56 Lesson 3 Software overview and installation Nortel Networks Confidential
0
Lesson 3 - slides 0
This lesson introduces you to the Shasta GGSN software architecture.
The exercises that are included in this lesson consist of installing the various
types of software that are required, and becoming familiar with them. Based
on your lab equipment configuration and the time available, you will perform
some or all of these exercises. Your instructor will assign the exercises for this
lesson, and provide the information to complete them.

Software overview 1.0 11-14 3-6
Notes:

Nortel Networks Confidential Lesson 3 Software overview and installation 57
OAM&P software components 0

The Operations, Administration, Maintenance & Provisioning (OAM&P)
software architecture for the Shasta GGSN consists of the following:
• Service Creation System (SCS) server – a provisioning system that
allows for central provisioning of ISP subscribers. It has a server/client
architecture in which SCS clients (on computers running Windows,
Linux, or Solaris) connect to an SCS server (on a Sun computer) which in
turn interacts with the iSOS on each GGSN to which it is connected.
• SCS Client - A graphical user interface to the SCS system. There are
client versions to run on various platforms
• IP Services Operating System (iSOS) – the operating system running on
the VxWorks operating system on the GGSN, that provides subscriber
awareness and data plane flexibility. It:
— controls the various cards of a GGSN chassis
— interfaces with a SCS server
— offers limited functionality by means of a command-line interface
(CLI)
• Customer Network Management (CNM) – a framework for creating
web-based network-management applications for the subscribers of the
ISPs (such as by using the Common Object Request Broker Architecture,
CORBA). With CNM, the subscribers can see the configuration, services,
logs, and other information about their network access.
• Lightweight Directory Access Protocol (LDAP) - a centralized
directory server containing subscriber-level configuration information.
Of these, only SCS Server, SCS Client, and the iSOS are covered in this
course. These are the software systems needed to actually provision the
GGSN equipment.

Notes:
iSOS software 0
iSOS is the VxWorks-based operating system that runs on the Shasta GGSN.
It comprises
• Image software is used to manage the GGSN processes. There are
separate images for the different circuit pack types. You interact with the
operating system through a CLI and/or the SCS.
Note: The Shasta GGSN supports all CLI commands that are supported
by the Shasta Broadband Services Node (BSN) platform. However, the
CLI is only to be used for setup and system diagnosis. All provisioning
and system administration is to be performed by means of the SCS.
• Configuration files contain the information used to configure the system.

These files are built with information pushed down from the SCS system,
where the user provisions the GGSN. When you perform a ‘sync’
between the SCS system and the GGSN, these files are overwritten.
• Data files are for logs and accounting information
There are three storage locations for iSOS software:

• Disk storage – default storage location for the configuration files, logs,
and accounting.
• Flash storage – default storage location for the image software. You can
have multiple images stored on Flash. You can also set the system to boot
from a trivial file transfer protocol (TFTP) server. If you do this, the CMC
image will be on the TFTP server, while the other circuit pack images are
downloaded to Flash, to be used by the CMC.
• Back-up storage, on an optional PCMCIA card.

Notes:
iSOS file system structure 0

Each of the storage devices (/flash, /disk, /pcmcia) on the CMC contains the
same file structure. There are five file directories (IMAGE, ACCT, LOG,
CONFIG and CORE), each with its own purpose:
• The IMAGE directory contains all images that are loadable by the GGSN.
This directory should contain subdirectories for each image available.
• The ACCT directory, or accounting directory, contains files for subscriber
accounting such as RADIUS.
• The LOG directory contains multiple log files to document administrative
activity on the GGSN.
• The CONFIG directory contains at least the Primary, QS1 and QS2
directories. The Primary directory contains the current configuration that
is loaded on the GGSN. QS1 contains the “quick start” configuration that
will be loaded upon boot of the GGSN, before re-syncing with the SCS
server. QS2 is a backup for QS1.
• The CORE directory contains core files that have been created because of
a failing SSM or CMC. When one of these devices fails, the core files are
dumped to this directory. Note that if the same SSM or CMC dumps and
there is a dump already in this directory from a previous failure, the old
dump will be overwritten.
The CMC’s software has two main modules, CPU0 and CPU1. In CPU1 run
all the routing tasks - for example, RIP, OSPF, BGP, IS-IS. In CPU0 runs
everything else - for example, subscriber management, ISP management, card
management, VPN management, SCS agent, protocol management (PPP/
L2TP…), and virtual-circuit management.

Notes:
iSOS CLI 0
The iSOS command line interface (CLI) runs on one of the CMC processors
and can be accessed through a Telnet session or a terminal connected to the
Console Port on the CMC. (Telnet sessions are not available while the CMC is
booting.) The CLI supports multiple simultaneous user logins. There are three
types of users or access privilege levels for the CLI:
• “User” (U) has read-only access to the iSOS software.
• “Super-user” (SU) has read and write access to the iSOS software. Super-
users can change configuration parameters for the current session, but
cannot save configurations.
• “Super-super-user” (SSU) has read and write access to the iSOS software,
and can also save configurations. The default SSU login is admin and its
password is admin.
Each type of user has access to a different set of commands within the CLI.
For a listing of these sets, please consult Appendix A of NTP 411-5221-927,
Shasta GGSN Procedures Reference Manual.
The CLI prompt indicates the hostname and the user access level. For
example,
SSG-1(SU)#
Enter ? to view a listing of the available commands or options for a partial

command. (For example, type ? to see a listing of all commands, or type
show ? to see a listing of all the show commands.)
The CLI is not to be used for configuring the Shasta GGSN because any
changes performed through the CLI are overwritten by the configuration
downloaded from the SCS server after a “resync” operation. The CLI can be
used for initial setup, and for performing diagnostics and troubleshooting.
Important notes:
• CLI users are completely independent from and unrelated to SCS GUI
users. CLI users are defined per-node while SCS users are defined (once)
in the SCS.
• CLI users can see information of all ISP contexts defined in the Shasta
node. (ISP contexts are described in the next lesson.) The “per-ISP”
separation of user privileges imposed on the SCS GUI is not enforced in
the CLI.

Notes:
SCS components 0
Service Creation System (SCS) is a powerful provisioning system designed to
allow rapid creation and delivery of network-based, value-added services to
the mass market. Using the SCS, service providers can economically deploy
managed network-based firewall, Virtual Private Network (VPN) and traffic
management services to millions of concurrent subscribers. The SCS is a
distributed client-server application that allows multiple concurrent users to
access the SCS server through a Java-based graphical user interface. The SCS
server communicates with a database that stores service policies, service
profiles, and subscriber-specific and ISP-specific information.
SCS has these characteristics:

• uses a client-server architecture
• is used for configuration of the GGSN, profile creation, subscriber
provisioning, monitoring, and troubleshooting
• as an element manager of the GGSN, SCS has limited support for open
interfaces to be used by high-level network administration agents such as
CORBA (Common Object Request Broker Architecture) or RMI (Remote
Method Indication)
SCS Server runs on the Solaris operating system. Different hardware

requirements apply, depending on the size of the regional deployment. For
example, a server supporting the deployment of 9-16 GGSNs requires
substantially more computing power than one supporting 1-8 GGSNs.
Versions of SCS Client, the graphical user interface, can be obtained to run on
operating systems such as Windows 95/98/2000/NT, Linux, or Solaris.

Notes:
SCS software architecture 0

The Service Creation System (SCS) server architecture consists of multiple
components:
1. A Lightweight Directory Access Protocol (LDAP) server contains all an
ISP’s non-device-specific data (such as subscriber records, RADIUS
profiles, and service policies) in the LDAP directory. The LDAP directory
server used by Shasta consists of:
a. Directory server – stores user data and server configuration data used
by other servers in the configuration.
b. Administration server – manages operation requests from all servers
in the LDAP configuration. You must have an administration server to
manage the Directory server.
c. Netscape console – a stand-alone Java application that provides access
to all LDAP resources and applications and displays them in a
graphical format. The console is independent of any one server.
Note: Never make changes to the database at the LDAP level, through the
Netscape console. Make all changes to subscriber configurations through
an SCS Client.
2. A domain server maintains a Solid database with all the information about
the regions, and all non-device-specific information for the Device Owner
that is shared across the regions. A domain server supports up to 16
regional servers. When a GGSN boots up, information is pushed to it by
the domain server.
3. An SCS Client is a graphical user interface to the domain server.
4. A region server maintains device-specific information for a group of
GGSNs. Up to 16 GGSNs can report to a region server.
5. A pull server allows the GGSNs to query dynamic PPP subscriber
information when a PPP subscriber is logged in. Up to three pull servers
can be configured for a GGSN, but only one will send the pull requests at
any given time.
6. A log server collects all device logs and stores them. The log server also
collects subscriber logs (for example, statistics and accounting logs) and
stores them in binary files. Up to three log servers can be defined to which
a GGSN can send logs.

Notes:
SCS deployment 0
Following are some general rules for deploying the software on your servers:
• the LDAP software must be installed on a server before installing the SCS
software
• SCS Client software interfaces with the domain server
Single-region installations:
• domain, region and pull servers are co-resident on the same host
• additional domain, region and pull servers may be incorporated for
redundancy
• the domain, region and pull server combination supports up to 16 GGSNs
Multi-region installations:
• log servers are shared by the regions
• one pull server is dedicated to each region
• region, pull, and log servers can have 1:N redundancy across all regions;
the log server does not require redundancy, though
• each region requires a region server
• a single region server supports up to 16 GGSNs

Notes:
Synchronization 0
Synchronization is the process of overwriting the configuration files on the
GGSN with the SCS configuration. The GGSN is wiped clean, rebooted and
reconfigured from the SCS files.
When a GGSN is “out of sync”, it means that the transaction counter on the
GGSN is different than that in the SCS server. There is a sequence number
check between the SCS and the GGSN that gets incremented as commands
from the SCS are pushed down to the GGSN. When the numbers no longer
match, the two are considered “out of sync”.
Possible causes of an “out of sync” message:

• adding a component that conflicts with something already downloaded to
the GGSN
• installing an iSOS load that is incompatible with the SCS load being used
• deleting a component with a bind that would be necessary to the next step
of an operation
The effect of “out of sync” and re-synchronizing:

• While un-synchronized, the GGSN icon in the Device Manager window
of SCS Client is red.
• During intervals when the GGSN is un-synchronized, existing subscriber
data is not affected.
• Any additional provisioning done during an “out of sync” condition will
be pushed down to the GGSN.
• The act of re-synchronizing will cause an outage as the GGSN is reset,
and all subscriber sessions during that period will be affected.

Notes:
Exercises 0
Note 1: All procedures are found in NTP 411-5221-927,

Shasta GGSN Procedures Reference Manual. For the purposes of these
exercises, “System Administrator” refers to your instructor.
Note 2: Use the naming conventions specified by your instructor.

Lesson 4
Configuration: basic
76 Lesson 4 Configuration: basic Nortel Networks Confidential
0
Lesson 4 - slides 0
This lesson describes the roles of the GGSN “Device Owner” and “ISP User”.
The Device Owner defines a Shasta GGSN, configures the hardware, and
builds the virtual ISP router(s). These functions are performed before an ISP
user can have full access and functionality.
The exercises that are included in this lesson consist of using SCS to
configure the Shasta GGSN for initial deployment. Based on your lab
equipment configuration, you will perform some or all of these exercises.
Your instructor will assign the exercises for this lesson and provide the
information to complete them.

Configuration: basic 4.0 15-17 7-13
Notes:

Nortel Networks Confidential Lesson 4 Configuration: basic 77
The ISP context 0

A central idea behind the provisioning of a Shasta GGSN device is that of the
“ISP context”. An ISP context is a logical partition of a particular Shasta
device (and the provisioning system, SCS). An ISP context (often referred to
simply as an “ISP”) functions as a virtual router (a router that is implemented
in software) with an independent, routed IP address space. An ISP context has
configurable “connections” (layer 2 links), as well as trunk and access
“interfaces” (connections with configurable IP addresses and behavior). An
ISP context runs independent routing protocol instances and has independent
routing tables. It can be managed and provisioned independently through the
SCS, and can have independent SNMP management (SNMP GET messages
and traps). An ISP has an associated default IP address, one that is unique to a
particular Shasta device on which it exists.
Shasta devices also incorporate a special, non-configurable, ISP context; it is

called the “default ISP context” or “default ISP”. This is an independent
routing entity that contains the management ports. (The main purpose of
management ports is to provide communication between the Shasta node and
the different components of the SCS, as well as to SNMP-based management
systems. They are also used to provide telnet access into the Shasta node, if
permitted by Management Services security policy.) It is not possible to route
packets from an ISP context to the default (management) ISP. In many cases,
CLI commands refer to the “default ISP” if an ISP context is not specified.
The Shasta GGSN can support multiple configurable ISP contexts (apart from
the default, non-configurable ISP context). This will be discussed further on
subsequent slides.
Moreover, a service provider can define a (configurable) ISP context in such a

way that it spans multiple Shasta devices in a network. In this case, an ISP is
not tied to a single, unique address, but rather a single, unique address per
device. This benefits large service providers that may have tens or hundreds
of Shasta devices in their networks, and wish to perform central provisioning.
Thus, there are three different levels of configuration information:

1. device-specific information (such as the number and type of cards in the
chassis of a specific Shasta device)
2. device-specific ISP information (such as the ISP’s default IP address on a
particular Shasta device)
3. ISP information that is common across the entire ISP context (such as that
pertaining to subscribers and IP services)

Notes:
Gn & Gi interfaces 0
An ISP context is a logical entity that encapsulates all of the services,
interfaces, and functionalities of one service provider. An ISP context is
similar to a virtual router. It contains the ISP’s default IP address (used,
among other things, to terminate tunnels), and the IP addresses of the ISP’s
interfaces. In order to separate the core network from the Gi side, each GGSN
requires one Gn ISP context and at least one Gi ISP context. GTP tunnels are
configured on the Gn ISP. Subscriber sessions are created on Gi ISPs - that is,
a Gi ISP implements services and protocols associated with an Access Point
Name (APN).
Note: If desired, one Gn ISP can have a presence on multiple GGSNs.

Similarly, one Gi ISP can span multiple GGSNs. This might be done to
simplify system-wide provisioning of GGSNs.
Only trunk connections are permitted for the Gn and Gi interfaces on the GGSN.
Trunk connections are layer-2 connections made up of either Ethernet or ATM
interfaces.
• With Ethernet, one port = one trunk.
• With ATM, all connections, both ingress and egress, are routed trunk
connections only. One PVC = one trunk. There are four assured
forwarding queues for QoS. Neither bridging nor VC multiplexing are
used in wireless networks.
IP tunneling at the Gi side

• The GGSN may initiate a tunnel at the Gi side for security and encryption
reasons. The Gi supported IP tunneling protocols are L2TP, L2TP over
IPSec, and IPSec.
• There is a one to one relationship between a GTP tunnel and a Gi tunnel.
• If the connection between the GPRS network and the ISP infrastructure is
secured, there is no need for encryption
The design of a GPRS Public Land Mobile Network (PLMN) network features
these security rules:
1. GTP tunnels are only valid if they terminate or originate on a Gn
interface. The Gi interface is not used for this.
2. The only types of traffic allowed over a Gn interface are GTP tunnels,
DHCP and RADIUS (if applicable), and OA&M.
3. Packets arriving on the Gi side cannot be routed to any node on the PLMN
network other than a mobile with a valid PDP context, and that only by
means of a GTP tunnel.

Notes:
ISPs and the Internet 0

The Shasta GGSN can be partitioned into multiple virtual router contexts for
separate Gi ISPs. A virtual router can be considered an independent routed
IP address space.
A device owner owns the GGSN and provisions the chassis, the connections,
and the ISPs (Gn and Gi). Each ISP is a virtual router, isolated from other
ISPs.
Given ownership of a virtual router, the ISP controls the routing services,
along with other services. One Gn ISP context and up to 63 Gi ISP contexts
can be provisioned on a single GGSN.
Because each ISP owns a secure virtual context in the GGSN with a separate
address space, conflicts or security issues that could arise from shared routing
tables do not occur. No ISP can see another ISP’s configuration.

Notes:
SCS user classes 0

Because of its architecture, the Shasta GGSN requires multiple system
permission levels to accomplish the entire task of provisioning. There are two
classifications of SCS users that can access the GGSN system:
1. Device Owner – The Device Owner, operating at the level equivalent to
the “Super User” in iSOS, has these main responsibilities:
— Configuring and maintaining the Shasta devices in the SCS regions,
including configuring cards and ports, and setting management
attributes.
— Creating an ISP and its associated “ISP User” identities
— Configuring the trunk connections (L1 + L2)
2. ISP User – Before the ISP User can have full access and functionality, the
Device Owner functions must be completed. In turn, the ISP User has
these main responsibilities:
— Provisioning the ISP and routing services
— Configuring the trunk interfaces (L3) and access properties
— Adding and configuring subscribers
— Configuring subscriber services

Notes:
Device Owner activities 0

The Device Owner is responsible for all functions that pertain to the ISP
contexts and to the GGSN chassis. The following are some of the functions that
the device owner performs:
1. configure the GGSN – the device owner is responsible for any function
that has to do with the physical box.
— install equipment
— install software
— provision GGSN within SCS
— configure cards and ports
— configure management attributes
2. provision virtual routers – the Device Owner sets up the virtual router
contexts within the GGSN and assigns the users for the ISPs.
3. build trunk connections – the Device Owner configures the trunk
connections for the ISP, including setting weight rates on PVCs
The Device Owner functions are performed before the ISP User can have full
access and functionality.
Note: These are the default definitions of each of these roles. In a

particular situation, the specific privileges of each of these users is
configurable from within the SCS Client application.

Notes:
ISP User activities 0

ISP user activities performed on the GGSN fall into two distinct categories,
depending on the ISP (e.g. Gn or Gi). Basically, the difference is that the Gn
ISP is unique on a GGSN, and the only one that supports GTP tunnels. There
may be up to 63 Gi ISPs, and have APNs configured for them (up to 2000
APNs per Gi ISP).
Gn ISP user tasks

The Gn ISP user:
1. defines the wireless ISP virtual router
2. configures the Gn trunk interface (L3)
3. configures a GTP tunnel; this consists of
— configuring a CGF
— configuring a connection template

Notes:
Gi ISP user tasks

The Gi ISP User’s tasks include:
1. define connection ISP virtual router
2. configure Gi trunk interface (L3)
3. configure APN group
— configure application server (WAP)
— configure Prepaid server (SCP)
— Subscriber template
– Access group (configure DHCP server, or internal address pool;
configure RADIUS server)
– outbound tunneling
– Service policies
– IP address allocation method

Notes:
GGSN provisioning sequence 0

These basic configuration elements, common to all network-access scenarios,
are fundamental to the provisioning and deployment of a GGSN:
1. Configure SCS server - load GGSN version of SCS Server software, then
create SCS users and passwords as required
2. Load GGSN version of iSOS software onto the GGSN(s)
3. Add an administrative region, add a GGSN to this region, choose a pull
server and a log server, perform a synchronization.
4. Configure the GGSN’s cards and ports.
5. Add a Gn ISP, and add a Gn ISP user. Define one or more trunk
connections for the Gn ISP. Configure the Gn ISP (trunk interfaces,
routing, connection templates, IP address pools, subscriber templates).
6. Add a Gi ISP, and add a Gi ISP user. Define one or more trunk
connections for a Gi ISP. Configure the Gi ISP (trunk interfaces, routing,
connection templates, IP address pools).
7. Add subscriber templates.
Note: Not included in this list, but equally necessary, are all the steps
needed to configure external systems such as the RADIUS server, the
external network management system, and the accounting system (such as
CGF).

Notes:
Exercises 0


Lesson 5
Configuration: network access models
96 Lesson 5 Configuration: network access models Nortel Networks Confidential
Lesson 5 - slides
This lesson offers some theory and describes the activities of the “ISP user”
that enables the various types of network access.
The exercises that are included in this lesson consist of using SCS to
configure the Shasta GGSN to perform four types of network access. Based
on your lab equipment configuration, you will perform some or all of these
exercises. Your instructor will assign the exercises for this lesson and provide
the information to complete them.

Configuration: network access models 4.5 n/a 14-17
Notes:

Nortel Networks Confidential Lesson 5 Configuration: network access models 97
Network-access models 0
The following table summarizes the configuration options associated with
each network model:
Table 5: Network model configuration options
Wireless ISP L2TP VPN IPSec VPN & Shasta
GGSN VPRN
Access Mode Transparent or Non- Transparent; Non- Transparent or Non-
Transparent Transparent if Single APN Transparent
used
Mobile RADIUS Authentication done at LNS RADIUS
Subscriber side
Authentication
(if required)
PDU Type IP or PPP IP or PPP IP or PPP
PPP Session Terminated Created between GGSN Terminated
and LNS for IP PDU and
pass through for PPP PDU
Gi Interface Raw IP L2TP or L2TP over IPSec IPSec
IP Address Address allocation by Address allocation by Address allocation by
Allocation GGSN remote Intranet GGSN
IP Address Public IP address from Public or Private IP address Public or Private IP
Domain operator’s domain and from ISP domain address from operator’s
Private IP address with domain
external NAT server
GGSN IP Internal address pools or IP Address allocation is not Internal address pool or
address DHCP or RADIUS static/ performed on GGSN, IP DHCP or RADIUS static/
allocation dynamic address Address is allocated at the dynamic address
methods allocation* LNS allocation*
IP Services Applied to the data packets Not supported Applied to the data packets
on the Gi interface on the Gi interface
Tariff Service Supported based on Supported based on Supported based on
configuration configuration configuration
WAP Service Supported (based on Not supported Not supported
configuration)
RADIUS Supported based on Supported based on Supported based on
Accounting configuration.* configuration. configuration.*
QoS Service Supported based on Supported on Gn interface Supported based on
configuration based on configuration configuration
ToD Service Supported based on Supported based on Supported based on
configuration configuration configuration
End to End IP IP and PPP for IP PDU and IP
Protocols PPP for PPP PDU
* Dynamic IP address allocation by Radius server only if Radius accounting is configured on same server.

Notes:
APN provisioning 0
Before delving into the network models, we need to discuss the concept of the
Access Point Name (APN). The APN is used to identify the data session
requested by the mobile. An APN is carried in the Create PDP Context
Request between the SGSN and GGSN. An APN is associated with a
subscriber template. APNs are provisioned on Gi ISPs. APNs are
provisioned—per group—within the GGSN internal LDAP directory. The
APN makes reference to the GGSN that is to be used, and identifies the
external network to which a subscriber may wish to connect. A GGSN
supports up to 2000 APNs per Gi ISP.
Information that can be deduced from an APN:

• subscriber authentication requirements (in the Subscriber Template)
• IP address allocation method (in the Subscriber Template)
• subscription required for the GTP session
• GTP accounting information
• prepaid versus postpaid subscription
• Wireless Application Protocol (WAP) server interaction
• outbound tunneling (in the Subscriber Template)
• IP Services (in the Subscriber Template)
• Quality of Service (in the Subscriber Template)
• Tariff Boundaries (Tariff Based Billing)
• Access Group (RADIUS and DHCP Server identification) (in the
Subscriber Template)
• VPRN membership (in the Subscriber Template)
Provisioning performed at the APN level gives the operator the flexibility to
create profiles with different policies in different APNs.

Notes:
Single APN implementation 0

Single APN implementation (introduced in UMTS2.0 / GPRS4.0) lets you
minimize the number of provisionable APNs and to invoke services on a per-
subscriber basis. An example of this would be to use a single APN for all cor-
porate access from all subscribers. Subscribers of different VPNs could use
the same APN but have different VPN membership and different IP services.
Single APN needs non-transparent access mode, where the GGSN uses the
Radius server for authentication. The information sent back from the
RADIUS Server at PDP session setup time indicates the VPN membership
and IP services that are associated with this mobile user connection, and will
be used in this PDP session.
The single APN concept enables APN consolidation by storing the per-
subscriber information on the RADIUS server instead of grouping the services
into different APNs on the Shasta GGSN. The services that can be provisioned
on a per subscriber basis on RADIUS Server include:
• VPN membership
• IP Services
• Prepaid Subscription
• Outbound Tunneling
One or many of these attributes may be provisioned on the RADIUS server
for each subscriber. If these attributes are not returned from the RADIUS
server, the provisioning of the corresponding APN via SCS will be used. The
minimum information that must be passed for the per subscriber information
lookup is the subscriber’s username and password. The anonymous mode user
authentication can be used for the Single APN.
When the Single APN attributes are returned from the RADIUS server to the
Shasta GGSN, these attribute values overwrite the APN configuration
provisioned via the SCS. This approach effectively associates the services
with individual subscriber, not the destined APN for this PDP session.
For example, to declare a VPN membership without single APN capability, the
following configuration is provisioned on Shasta GGSN:
• Provision a VPN within the VPRN Manager via SCS.
• Provision the Subscriber Template for the APN with the VPN name.
However, with Single APN capability, the VPN membership configuration
becomes:
• Provision an APN with authentication required.
• Provision a VPN within the VPRN Manager via the SCS.
• Provision the RADIUS Server to return the subscriber’s VPN name upon
successful authentication for the subscriber.

Notes:
Single APN implementation (continued) 0

Prior to the introduction of Single APN, provisioning multiple VPNs required
one APN for one VPN. The APNs need to be provisioned in both the HLR
and the subscriber’s mobiles. With additional RADIUS server provisioning,
Single APN simplifies the complexities of ensuring that the correct APNs are
provisioned in the appropriate subscriber’s mobiles across a large subscriber
base.
On the Shasta GGSN, the returned VPN attribute in the RADIUS Access-
Accept message is used to match a provisioned VPN and the matched VPN
configuration is used for the subscriber. As a result, many subscribers may
access the same APN, but retain different VPN memberships.
If the RADIUS server does not return any Single APN attributes, the
configuration provisioned via the SCS is used. Returning these Single APN
attributes from the RADIUS Server is optional. Nevertheless, the
configuration of multiple APNs for different VPN memberships can still be
used on Shasta GGSN if per subscriber information is not provisioned on the
RADIUS Server.
Single APN capability is supported for all network models and is only
available for the non-transparent mode (Radius authentication needed).
See the Shasta GGSN User Guide, 411-5221-926 for more information
concerning Single APN.

Notes:
Wireless ISP network model 0

In this model, the operator offers a basic ISP service for a mobile. The
encapsulated IP packets from the mobile are routed on the Gi Interface
(public Internet). IP packets received on the Gi interface are tunneled back to
the appropriate mobile.
This network model supports both transparent and non-transparent access for
both IP and PPP PDU types. If PPP PDU type is used, the PPP session is
terminated on GGSN and the encapsulated raw IP packets are delivered to the
Gi interface.
Any configured IP services will be applied to the IP packets before the

packets are sent to or when the packets are received from the Gi interface.

Notes:
Wireless ISP - protocol stacks 0

This network model supports both transparent and non-transparent access for
both IP and PPP PDU types.

Notes:
L2TP VPN model 0

This model allows for a remote user to connect on demand through an ad hoc
tunnel into another site. The user packets are tunneled across the public
network to the desired site, giving the impression to the user of being directly
connected into that site.
In the L2TP VPN network-access model, the GGSN terminates a GTP tunnel
from the SGSN and creates an associated PPP/L2TP tunnel to go out on the
Gi interface to the intranet/ISP. The tunnel mapping at the GGSN is one-to-
one (GTP tunnel to L2TP session). Both IP and PPP PDU types are supported
in this network model.
With the L2TP VPN model, the GGSN functions as a LAC. The operator has
a choice of enabling security (IPSec) on the L2TP tunnel (“L2TP over
IPSec”) to the remote LNS.
This network model supports transparent or non-transparent access. The

GGSN does not perform any user authentication nor IP address allocation for
the mobile subscriber. User authentication and IP address allocation is
performed by the LNS at the remote Intranet. The mobile is also dependent
upon the remote intranet to eventually provide access to the Internet. A
remote firewall can be used to protect/restrict the users’ access to the Internet.
If single APN is to be used, the non-transparent access mode must be

configured as the information necessary to create the connection will be sent
back by the Radius server following a successful authentication.

Notes:
L2TP VPN - protocol stacks 0

Both IP and PPP PDU types are supported in this network model:
• for PPP PDU,
— the PPP session from the mobile is “passed through” to the L2TP
tunnel.
— the GGSN tunnels all PPP packets between the mobile and the remote
LNS.
• for IP PDU,
— the PPP session is created between the GGSN and the L2TP Network
Server (LNS).
— the GGSN is responsible to pack the IP packets from the mobile with
a PPP header and ship them to the L2TP tunnel, and remove the PPP
header of the PPP packets from the LNS and ship them to the mobile.

Notes:
IPSec 0
IPSec is fundamental to the IPSec VPN model, so we will discuss this method
of encryption before proceeding to the discussion of the model itself.
Encrypted data cannot be read by intermediary observers in an un-trusted
network, but can be decrypted and read by the intended recipients who have
the appropriate key for decrypting the data. The Shasta GGSN supports
industry-standard encryption capabilities using IPSecurity (IPSec) and
associated key management protocols. IPSec within a VPN allows users to
behave as if they are on a secure isolated local area network (LAN), although
it is physically connected to unsecured public networks.
The IPSec protocol suite is an Internet Engineering Task Force (IETF)

standard created to add security to TCP/IP networking. IPSec is a network
layer security mechanism. It tries to provide services at the IP layer by
enabling a system to select required security protocols, determine the
algorithm(s) to use for the service(s), and put in place any cryptographic keys
required to provide the requested services. The set of security services offered
includes access control, connection-less integrity, data origin authentication,
protection against replays (a form of partial sequence integrity),
confidentiality (encryption), and limited traffic flow confidentiality.
These objectives are met through the use of two traffic security protocols, the
Authentication Header (AH) and the Encapsulating Security Payload (ESP),
and through the use of cryptographic key management procedures and
protocols. These protocols may be applied alone or in combination with each
other to provide a desired set of security services.
A security association (SA) is a relationship between two or more entities that

describes how the entities will use security services to communicate securely.
An SA is uniquely identified by a Security Parameter Index (SPI), an IP
Destination Address, and a security protocol (AH or ESP) identifier.
Internet Security Association and Key Management Protocol (ISAKMP)

defines procedures and packet formats to establish, negotiate, modify and
delete SAs. ISAKMP defines payloads for exchanging key generation and
authentication data. These formats provide a consistent framework for
transferring key and authentication data which is independent of the key
generation technique, encryption algorithm and authentication mechanism.
ISAKMP provides a framework for authentication and key exchange but does
not define them. It is designed to support many different key exchanges. One
such key exchange system is defined by the Internet Key Exchange (IKE).
IKE is an automated protocol for establishing, negotiating, modifying, and
deleting SAs between two hosts in a network. In order to exchange encryption
keys securely, sophisticated key-exchange algorithms have to be used,
specifically designed to meet the challenge of secure key distribution.
(References: RFC 2407, 2408, 2409)

Notes:
IPSec security associations 0

A Security Association (SA) is a relationship between two or more entities
that describes how the entities will use security services to communicate
securely. An SA is uniquely identified by a Security Parameter Index (SPI),
an IP Destination Address, and a security protocol (AH or ESP) identifier. In
principle, the Destination Address may be a unicast address, an IP broadcast
address, or a multicast group address. However, IPSec SA management
mechanisms currently are defined only for unicast SAs.

Notes:
IPSec VPN model: IPSec Branch Office 0

The IPSec VPN network model is used if the remote ISP/intranet gateway is
not a Shasta GGSN. In this case, the Shasta GGSN node is configured to have
a single point-to-point IPSec access tunnel to the remote intranet gateway.
This model provides a secured link (by means of IPSec) to an intranet/ISP.

The GGSN terminates a GTP tunnel from the SGSN and creates an IPSec
security association with a remote server belonging to the intranet/ISP. If the
mobile is not given an IP address at subscription (static address allocation),
then the GGSN must assign an address at PDP context activation (that is,
dynamic address allocation) in this model.
This network model provides both transparent and non-transparent access.

Both IP PDU and PPP PDU types are supported in this model.

Notes:
What happens during a connection to a VPN 0

When a remote user wants to reach the corporate intranet through his or her
network carrier, he or she has to establish a Virtual Private Networking
connection to the VPN platform (such as the Contivity Extranet Switch).
These are the events which occur in establishing a VPN connection and to be
able to exchange data:
1. the user on the mobile activates a PDP context
2. the SGSN activates the GTP Tunnel to the GGSN
3. authentication of the user occurs
4. authorization of the user occurs
5. the mobile obtains an IP address
6. VPN tunnel establishment occurs

Notes:
IPSec VPN: Shasta GGSN VPRN model 0

A Virtual Private Routing Network (VPRN) group can be created to span an
ISP to multiple Shasta GGSNs. An IPSec tunnel exists between every two
Shasta GGSNs in this VPRN group. This solution provides the added
functionality of IP address broadcasting between wireless Virtual Private
Network (VPN) groups. Multiple Shasta GGSN nodes can be added to the
VPRN group of the ISP for a point-to-multiple IPSec tunnels. To support the
link between Shasta GGSN VPRN and a private intranet, an access
connection is configured. It can optionally configure an IPSec tunnel with it.
Thus, the traffic can be routed via IPSec tunnel from any Shasta GGSN in the
VPRN to the one which has the access connection to the private intranet, from
which the traffic is forwarded to the intranet gateway.
The distinguishing characteristic of a VPRN, in comparison to other types of

VPNs, is that packet forwarding is carried out at the network layer. A VPRN
consists of a mesh of IP tunnels between ISP routers, together with the
routing capabilities needed to forward traffic received at each VPRN node to
the appropriate destination site. Attached to the ISP routers are CPE routers
connected via one or more links, termed 'stub' links. There is a VPRN specific
forwarding table at each ISP router to which members of the VPRN are
connected. Traffic is forwarded between ISP routers, and between ISP routers
and customer sites, using these forwarding tables, which contain network
layer reachability information.
The Shasta GGSN VPRN configuration is used if the remote ISP/intranet

gateway is a Shasta GGSN. In this case, the Shasta GGSN can be provisioned
as part of a VPRN group, in which case Shasta nodes have an IPSec tunnel set
up between them. The connection between VPRN and intranet gateway is an
access connection.

Both IP PDU and PPP PDU types are supported in this model.
This model provides a secured link (by means of IPSec) to an intranet/ISP.

The GGSN terminates a GTP tunnel from the SGSN and creates an IPSec
security association with a remote server belonging to the intranet/ISP. If the
mobile is not given an IP address at subscription (due to static address
allocation), then the GGSN assigns an address at PDP context activation (that
is, dynamic address allocation) in this model.

Notes:
IPSec VPN - protocol stacks 0

Both IP PDU and PPP PDU types are supported in this model. If PPP PDU is
used, the PPP session is terminated on the GGSN and the encapsulated IP
packets are delivered to the IPSec layer.

Notes:
Deployment for wireless services 0

These models also support the deployment of wireless services.

Notes:
Exercises 0


Lesson 6
Configuration: IP services
130 Lesson 6 Configuration: IP services Nortel Networks Confidential
0
Lesson 6 - slides 0
The GGSN offers a rich variety of IP services. Service policies are created
using the SCS service policy manager. Service polices are the building blocks
out of which subscriber templates are built.
The exercises that are included in this lesson consist of using the SCS to build
service policies and then applying them to subscriber templates. Based on
your lab equipment configuration, you will perform some or all of these
exercises. Your instructor will assign the exercises for this lesson and provide
the information to complete them.

Configuration: IP services 4.0 n/a 18-22
Notes:

Nortel Networks Confidential Lesson 6 Configuration: IP services 131
GGSN - more than a router 0

The GGSN is deployed at the edge of a GPRS or UMTS network. It provides
packet routing functionality by converting mobile subscriber packets into an
appropriate packet data protocol format and forwarding them out onto a
packet data network. In the reverse direction, the GGSN receives data packets
for mobile subscribers from the packet data network, it encapsulates them for
delivery across the GPRS or UMTS network, and then forwards them to the
SGSN serving the mobile subscriber they are destined for. However, this is
where the resemblance of a GGSN to a router or a switch ends. The GGSN is
much more sophisticated.
Unlike a general purpose router, the GGSN data plane is built around two
fundamental concepts – the subscriber and the session. Packets received by a
GGSN are associated with a particular subscriber. A subscriber template
contains instructions for how packets belonging to this particular subscriber
are to be processed. Packets not only belong to a particular subscriber, they
belong to a particular subscriber session. When a subscriber session is created
as a result of a Create PDP Context Request, a logical communications path
through the GGSN is created. All packets belonging to that particular
subscriber session follow that path, and are processed by the resources
allocated to manage that path. When the session comes to an end, the path is
terminated and the allocated resources are returned to the system. This is
unlike a router where each packet is treated as a separate entity and is
unrelated to any other packet.
Also, unlike a traditional router, the GGSN provides a rich set of IP services
that can be applied to subscriber sessions. A subscriber template is used to
capture which IP services (if any) are to be applied to a particular subscriber
session. When a subscriber session is created, the GGSN queries the
subscriber template associated with the subscriber initiating the session, and
allocates the resources required for the IP services specified in the template.
The services are managed by software processes that are created specifically
for the subscriber session. When a subscriber session ends the system
resources used by the session are returned to the system in general.

Notes:
SCS subscriber policy manager 0

IP services are defined using the service policy manager in the service creation
system (SCS). There are three different service categories: Traffic, ISP Node,
and Management. These categories reflect the different types of traffic that the
services can be applied to.
• Traffic: these services are applied to individual subscriber IP sessions,
and are the services we are going to focus on.
• ISP node: these services are applied to every packet at an ISP level. There
is only one service available (Security) which is a stateful firewall. The
firewall rules are applied to all subscriber IP conversations belonging to a
particular ISP.
• Management: There is only one service (Security) which is a stateful
firewall. The firewall rules are applied to all traffic flowing through the
management ports on the CMC card.
The slide shows the policy service manager panel with the three categories
open. The slide, for purposes of example, also shows the rules currently
defined for one of the security policies.
Service policies are constructed out of service objects. Service objects are the
building blocks out of which policies are created. For example, the simple
firewall policy depicted in the slide contains a set of rules. Each rule is
constructed out of the following service objects – source address, destination
address, service application, action, log, remark. Each type of IP service
policy has a required set of service objects that must be datafilled. Not all IP
services are constructed out of the same objects.
A service policy is a particular definition of an IP service that can be applied

to a subscriber session. Different policies are then grouped into a set of
policies called a service profile. Service profiles are then used in building
subscriber templates. Subscriber templates include not only IP services
information but define how, subscribers will connect to the network, be
authenticated, what they will be authorized to do, etc. This process allows
policies to be created once and then applied to many different subscribers. It
also allows for easy reconfiguration, if the policy is changed, those changes
are automatically applied to all subscriber sessions that use that policy.

Notes:
IP services and network access models 0

Table 6 lists the different IP services that the GGSN supports in general and
details which services are available to each different network access model.
Table 6: IP services and network access models
IP service Wireless ISP L2TP VPN IPSec VPN

GGSN VPRN
Security YES NA YES
Anti-Spoofing YES NA YES
Ingress Anti-Spoofing YES NA YES
Diffserv Marking YES NA YES
Egress Diffserv Marking YES NA YES
Traffic Shaping YES NA YES
Personal Content Portal YES NA YES
Policy Based Forwarding YES NA YES
Policing YES NA YES
Web Steering YES NA YES
Account Service YES NA YES
Content Based Billing YES NA YES
Remember, IP services which are permitted by the access model might not be
available to each subscriber. When a user initiates a connection to the network
and is authenticated, a subscriber template is applied to the user’s session.
The subscriber template determines which specific IP services are applied to
the subscriber’s session.

Notes:
Packet processing 0
This slide shows how IP services are applied to each packet, in both egress
and ingress directions. This processing takes place in the SSMs of an SSC.
Ingress (subscriber towards the core network):

1. Ingress anti-spoof
2. Personal Network Portal
3. DiffServ marking
4. Accounting
5. Policing
6. Virtual Private Network (VPN) steering - route traffic to VPN or ISP?
7. Firewall
8. Web steering
9. Policy-based forwarding
Egress (core network towards the subscriber):

1. Web steering
2. Firewall
3. VPN steering
4. Accounting
5. Egress DiffServ marking
6. Traffic shaping
7. Personal Network Portal
8. Anti-spoof
In most cases, the order in which policies are listed in the subscriber template
does not matter; at the end, the results are the same.

Notes:
Security 0
The security policy is a firewall. A firewall is a hardware device or software
process that sits between two networks. It has the capability to scrutinize the
traffic passing between the two networks and to make decisions on how to
handle that traffic (allow, modify, disallow). Scrutiny can be based on the type
of access (such as email, telnet, or FTP), contents of the data accessed, source
or destination IP address, ingress or egress direction, and time of day.
There are two types of firewalls:

• packet-filtering: this type of firewall filters individual packets. Each
packet is considered to be distinct from every other packet.
• stateful inspection: this type of firewall filters “IP conversation” rather
than IP packets. All packets belonging to an IP conversation are treated
the same (allowed, disallowed, etc.).
The GGSN provides stateful firewall processes that can be applied separately
for each subscriber, Firewalls are configured on SCS with easy-to-use
templates that can then be readily applied to additional subscribers as needed.

Notes:
Security (cont.) 0
Security policies are constructed using the subscriber policy manager.
Policies are constructed by building a set of rules that subscriber IP
conversations will be scrutinized against. Table 7 details a simple security
policy with two rules.
Table 7: Firewall policy
Rule # Source Destination Service Action
1 SubAddr Any Any Allow
2 Any Any Any Drop
The first rule states that any packet belonging to an IP conversation originated
by the subscriber, to any destination, by any application are to be allowed to
pass out onto the external packet data network. The second rule is applied
only to packets that do not match the first rule. The rule is a catch all that
makes sure that packets not part of IP conversations initiated from the client
source address are dropped.
It is important to understand that IP conversations are verified against the

rules in the order that the rules are datafilled. For example, an IP conversation
is checked against rule #1 to see if it passes, fails or does not apply. If the IP
conversation matches the rule, the action is applied and no more rules are
checked. If the rule does not apply, the conversation is verified against the
next rule, and so on. It is very important to get the order of the rules datafilled
correctly. In general, rules go from most specific to most general.
What actually happens in more detail. A subscriber will initiate many

conversations: check email, visit web sites, ftp files to/from another host,
engage in instant messaging. All of these represent different conversations.
When a packet arrives at the GGSN, the GGSN runs the packet through a
classifier to determine whether it belongs to an already existing conversation
or whether it is the first packet in a new conversation. If it is the first packet of
a new conversation, the GGSN assigns it a flow ID. It then checks the packet
against the rules in the security policy and treats the conversation
appropriately (allow, deny, drop). If the classifier determines that the packet
belongs to an existing conversation it does not verify it against the security
policy, but passes the packet to the processes on the SSM already allocated to
handle that conversation.

The following two examples show how the GGSN inspects a conversation
using the rules provided in Table 7.
HTTP example
Suppose a subscriber initiates an http session. When the first packet arrives at
the GGSN, it is run through the classifier which determines that it hasn’t seen
this data session before. The classifier assigns it a flow ID. It then checks the
packet against the rules in the security policy. It matches the first rule and
packets associated with this data session are allowed to pass out onto the
network. The packet is then sent to the processes on the GGSN set up to
handle this conversation. When the http server replies to the subscriber’s
request, the packets arrive at the GGSN and are passed examined by the
classifier. The classifier realizes that the packets are in response to the http
get, and that they belong to a previously established flow ID. Because of this,
the packets are not evaluated against the rules in the security policy. The
packets are routed to the software processes handling this particular
conversation. Note that if the response packets were evaluated against the
rules, the packets would match rule # 2 and would be dropped.
FTP example
Similar to above, the initial TCP connection, including initiator and response
packets used to set up a FTP process match the first rule. However, ftp uses
the initial connection to negotiate new TCP connections for any data transfer
(GET, PUT, DIR, etc.). The GGSN recognizes the initial control connection
as ftp, and monitors the negotiation for new TCP connections. It then derives
the new expected TCP connection information, and associates all packets in
those connections with the same overall “ftp conversation”. Even though
some parameters have changed, the packets are still identified with the
original flow ID for the ftp session.
Summary
The GGSN can track an IP conversations even when the conversation changes
port #s during the conversation. The GGSN has a sophisticated understanding
of how protocols setup, manage, and teardown connections.
Security (cont.) 0
Sample policies for Wireless ISP and L2TP VPN are presented below.
Security policy for Wireless ISP

For Wireless ISP, the primary packet flow involves packets sent from mobiles
out into the Internet and packets destined to mobiles arriving at the GGSN.
These packets may be sent to and originate from any source in the Internet.
The following two rules cover basic ingress and egress traffic. Additional
rules will be required based on the actual network security requirements.
Table 8: Simple IP security rules
Source Destination Service Action Remarks

Any Subscriber subnet address Any Accept Internet traffic destined to
subscribers
Any Internal subnet address Any Drop Internet traffic destined to
internal network
Security policy for L2TP VPN

L2TP VPN packet flow is very similar to the Wireless ISP case. The
difference is that packets are tunneled to/from Security Gateways at the edges
of the private networks. All mobile data traffic passes through the tunnel
between the GGSN and the Security Gateway in both directions.
The rules for L2TP VPN are more narrow in that no subscriber subnet
addresses are required because mobile data traffic is not routed directly to the
GGSN. Data traffic sent to the GGSN is limited to that tunneled from the
remote security gateways.
Table 9: Simple IP VPN security rules
Source Destination Service Action Remarks

Any GGSN ISP addresses L2TP Accept Tunnel to remote private
IPSEC network
Any Internal subnet address Any Drop Internet traffic destined to
internal network

Notes:
Anti-spoofing 0
What is IP spoofing
IP spoofing is a form of attack that targets machines that run software processes
that perform session authentication based on the IP address of the host
requesting access to the service. Many applications and tools in UNIX rely on
source IP address authentication and include:
• RPC (Remote Procedure Call services)
• the X window system
• the R services suite (rlogin, rsh, etc.)
In general, the attack relies on exploiting how TCP connections are initiated.
To understand the attack you need to understand the 3-way handshake used in
establishing a TCP connection. In the following scenario: B is the server and
A is a host that B trusts. Suppose A wants to establish a connection to the rsh
server on B. A sends the following message to B to initiate a TCP connection:
A->B: SYN, ISNa
A sends a packet with the TCP SYN (“synchronize sequence number”) bit set
and an initial sequence number ISNa. B replies with
B->: SYN, ISNb, ACK(ISNa)
In addition to sending its own initial sequence number, it acknowledges A’s

ISN. Note that the actual numeric value ISNa must appear in the message.
A concludes the handshake by acknowledging B’s ISN.
A->B: ACK(ISNb)
The initial sequence numbers for establishing a TCP connection are intended
to be more or less random as defined in RFC 793. Unfortunately, Berkeley
derived kernels increment a counter used for the ISN sequence numbers with
a set of constants. Thus, if you open a connection to one of these machines
and examine the ISN used for the connection, you know to a very high degree
of confidence what sequence number the server will use for its next
connection. And therein lies the attack. In this scenario let X be an attacker
who wants to gain access to B. X will impersonate A the trusted host.
X opens a real connection to its target B. This gives X ISNb. X can then guess
with a high degree of reliability what ISN will be used by B for its next
connection. B then sends a message to B to initiate a TCP connection using
A’s IP address as the source address (B impersonates A).
Ax->B: SYN, ISNx ,where Ax denotes a packet sent by X pretending to be A

Notes:
IP spoofing (cont.) 0
B’s response to X’s impersonation of A
B->A: SYN, ISNb’, ACK(ISNx)
is delivered to A. X never sees that message but can still send
Ax->B: ACK(ISNb’)
using the predicted value for ISNb’. If the guess is right and usually it will be,
B’s rsh server thinks it has a legitimate connection with A, when in fact X is
sending the packets. It is important to understand that X does not receive B’s
responses to A. X is conducting the attack completely in the dark. Once a
connection is established X starts executing commands on the server. X will
not see any responses to those commands, but this is not a problem for X.
There is a minor difficulty here. If A sees B’s message, it will realize that B is
acknowledging something it never sent, and will send a message to B to tear
down the connection. There are a number of ways to prevent A from
responding to connections it did not initiate; the easiest is to wait until A is
turned off; more difficult but still easy is to prevent A from responding (gag
it). There are a number of strategies for gagging machines, the most common
attack is SYN flooding (where a host’s TCP input queue is flooded).
How the GGSN prevents this

There are two types of anti-spoofing policies that can be built.
• Egress anti-spoofing: ensures that traffic coming from the internet does
not have a source address that is used on the subscriber side of the GGSN.
• Ingress anti-spoofing: ensures that traffic originating on the
GPRS/UMTS network is not disguised as traffic originating from outside
the GPRS/UMTS network.
In general, the GGSN state-aware filtering only allows packets that arrive in
response to traffic explicitly initiated by a mobile subscriber. This helps
protect the subscriber base from falling prey to most network-based direct
infiltration attack scenarios. For example, to protect against SYN floods, the
GGSN drops all unsolicited SYN requests. To protect against LAND attacks,
the GGSN disallows any packets with the same source and destination
addresses. Finally, the GGSN prevents ftp bounce attacks through its in depth
knowledge of ftp control streams.

NO SLIDE
Notes:
Traffic management and QoS 0

GGSN QoS based on DiffServ marking is currently the most relevant type of
priority setting. It prioritizes packets at the network’s edge based the
subscriber and application. Network elements within the core then implement
the necessary discard and buffering mechanisms on a per-hop basis to
properly handle the higher priority (that is, real-time) packets in the presence
of network congestion.
QoS parameters (A/R and TC parameters) are passed to the GGSN within the
PDP Context Request message. QoS is activated per APN. An APN QoS profile
is a statically provisioned policy profile that allows the operator to define policy
profiles based on the A/R parameter and the Traffic Class. The Shasta GGSN
uses these elements, provisioned per APN, to guarantee minimum bandwidth:
• traffic policing (Metering, Marking/Tagging): regulates user traffic in the
ingress direction to ensure it doesn’t exceed the contracted rate
• traffic shaping: allows for differentiation in the egress direction to provide
higher priority and rate guarantees for important applications during
congestion.
• queuing: sophisticated scheduling mechanisms manage output queues
based on defined marking rules;
A service package is based on the level of QoS desired. The Shasta GGSN’s
total QoS package enables end-to-end DiffServ, and traffic management.
Towards core:
• queuing priority (L3/L2 Mapping) and scheduling mechanisms
• WRED
• IP data packets over Gi are DiffServ marked when the GTP tunnel is
created.
• both GTP control packets and GTP’ packets are marked with the DSCP
Towards subscriber:
• queuing priority (L3/L2 Mapping) and scheduling mechanisms
• Selective Discard
• Hierarchical Weighted Fair Queuing (WFQ), application-based
• the TOS byte in the outer IP header of data packets is DiffServ marked
based on the provisioned DSCP.
• both GTP control packets and GTP’ packets are marked with the DSCP

Notes:
Wireless Quality of Service 0

Quality of Service (QoS) providers offer multi-tier network services with
service level agreements (SLA) to guarantee actual performance. Based on
the application, the appropriate amount of bandwidth is delivered over the
network. For example, on-demand video conferencing acquires higher levels
of bandwidth than data networking.
The GGSN provides many bandwidth-management features that allow the

wireless operator to differentiate services according to customer needs. For
example:
• prioritize real-time traffic over other data traffic
• manage infrastructure resources to improve the user experience:
— control bandwidth by application or user, so that each has the
bandwidth needed
— ensure efficient and fair use of resources for all, so that no bandwidth
is wasted by low-tier users and applications
— recognize that resource efficiency leads to lower cost and greater
profitability; thus, more is available for all or high-tier users
• Value-based QoS service packages: allows for higher prices to be charged
in exchange for higher priority assigned to certain types of data
• Fair share of limited RF and system resources: traffic-shaping allows
guaranteed access to all users during peak traffic periods
• QoS in a mobile environment
— QoS maintained at the subscriber edge (per-hop basis)
— supports subscriber IP QoS within operator’s private IP network
— traffic conditioning with AF classifier, policer, class-based selective
discard, and class-based hierarchical scheduler/shaper.

Notes:
DiffServ marking 0
GGSN ingress traffic is prioritized for Qos by a combination of DiffServ and
Weighted Fair Queuing (WFQ). Because the GGSN is a subscriber
aggregator, it is subscribers who are competing for bandwidth on the trunks in
the ingress direction. Therefore, during times of bandwidth congestion,
certain subscribers can pay higher fees to receive a higher QoS.
WFQ works in a weighted round robin format. On the trunk connection

configuration screen, weights are available for each queue on a per PVC basis
from 1 to 32. The heavier the assigned weight to a queue, the higher the
precedence of that queue in relation to the others. The result of the weighting
gives each queue a relative percentage of the bandwidth during any congested
period of service.
WFQ can also be applied on a per type of service basis. For instance, a
subscriber may not want to pay to have higher priority put on all his ingress
traffic, but may want just his voice over IP (VoIP) and FTP traffic receive
higher Qos. This can also be achieved through DiffServ and WFQ.
The GGSN implements DiffServ by manipulating the IP packet’s type of service

(TOS) field so that it reflects a specific Assured Forwarding (AF) classification
based on industry standards. Once the DiffServ / TOS byte is set, routers within
the network core will use this information to queue and or discard the traffic in
different ways.
• The AF describes the relative priority of the traffic. The AF classes range
from 1-4, with AF 1 being lowest priority and AF 4 being highest. The
GGSN is capable of mapping these AF classes into ATM QoS.
• Additionally, each AF queue has a subset known as a Drop Precedence
(DP). The DP defines how likely the traffic is to be discarded if the
network experiences congestion or if the subscriber exceeds the traffic
contract. The DP allows for prioritization within the queue, with DP 1
being highest and DP 3 being lowest.
• Therefore, AF 4 DP 1 is the highest of the DiffServ queues; AF 1 DP 3 is
the lowest. Assured Forwarding classification of a subscriber is done in a
relative manner to the AF classification of other subscribers. By default,
all IP traffic is marked into AF 1 DP 3 when generated.
On the GGSN, DiffServ is implemented and used in conjunction with a

shaping tool. In the ingress traffic direction, a WFQ tool is available on the
trunk connections. In the egress traffic direction, and traffic shaping tool is
available from the Service Policy Manager in the SCS Client.

Traffic shaping 0
Traffic shaping is a feature that provides traffic management to the subscriber
network. Traffic shaping allows service providers to provide higher priority
and rate guarantees to specific mission-critical applications while giving
lower priority to applications such as email or FTP. Traffic shaping is an
egress-only IP service.
Traffic-shaping policies rely on these parameters during times of link

congestion. The shaper on the GGSN identifies IP flows and shapes to an
absolute bandwidth and/or a relative percentage bandwidth under times of
congestion, on a per-subscriber basis, and for specific traffic flows. There are
two types of traffic shaping policies available from the Service Policy Manager
in the SCS Client: flow based and AF based.
1. The Flow-Based Shaper does not rely on any DiffServ marking to
prioritize traffic, but does so on a “per type of service” basis. There are
two varieties of the flow shaper.
— Shaping with rate weight: Rate weights allow the provider to
provision relative weights to a service type. Determines what
percentage of the available bandwidth a given traffic type can use
during times of congestion.
— Shaping by a per-flow rate limit: The per-flow rate parameters allow
the provider to limit a subscriber’s bandwidth on a per-service basis,
therefore allocating only a certain percentage of the overall egress
access bandwidth to a particular traffic type. It applies to all traffic
flows that match a specific rule (such as, all HTTP traffic between
subscriber and subnet “Local Content”).
Additionally, the per-flow rate parameter can be provisioned with a
per-connection rate parameter which defines the maximum bandwidth
available for a single connection belonging to the traffic type. It
applies to each individual connection that matches a specific rule
(such as, each individual HTTP/TCP session between subscriber and
subnet “Local Content”). Also available are per-policy, and per-
subscriber rate limits.
2. The AF Traffic Shaper works in conjunction with DiffServ marking

(either egress DiffServ from the GGSN or packets marked elsewhere in
the network and arriving in the egress direction). The AF shaper provides
the standard 4 AF queues with independent provisionable weights to fit
the industry standard for WFQ.

Notes:
Traffic policing 0
Traffic policing is used to ensure that connections conform to established
bandwidth parameters in the ingress direction. The policing function protects
the network core from traffic in excess of the subscriber's contracted rate. The
policing function relies on the results of the DiffServ marking in conjunction
with bandwidth limits to set different drop priorities.
Rules are applied as to what happens with excess traffic. The committed rate,
committed burst size, peak rate, and peak burst size thresholds are set with
corresponding actions. For each of the action categories (red, yellow, green),
the actions will vary from dropping the traffic, placing it in the appropriate
queue, or marking the IP precedence. The rates and actions are associated
with each of the 4 Diffserv Assured Forwarding classes. Two different types
of policers exist: a single-rate, three-color marker (SRTCM) and a two-rate,
three-color marker (TRTCM).
Traffic is monitored for each AF queue on a per subscriber basis. Any traffic
between line rate = zero (no traffic) and your CIR is a policing status of green,
typically no action needed. Traffic in excess of your CIR but within your CB
has a policing action of yellow. Traffic in excess of your CIR and CB has a
policing action of red.
For each policing status, the provider can establish an action for traffic in that
AF queue. Traffic from the subscriber can be reassigned a drop precedence
within the queue (such as, from AF 4 DP 1 to AF 4 DP 3) or can be dropped
to the CIR entirely.
The policing tool will monitor a subscriber’s traffic in each queue and assure
its adherence to any Service Level Agreement (SLA) made with the provider.
For instance, the ISP may have an SLA with a subscriber that all ingress
traffic in AF 4 will be at 128 kbps. This is the Committed Information Rate
(CIR). The provider can then set two thresholds to help monitor and control
any bursty traffic from the subscriber in excess of the CIR. The Committed
Burst (CB) is the next level threshold, while the Excess Burst (EB) is the
highest.

Notes:
Personal network portal 0

A key Shasta GGSN service is to help wireless carriers become wireless
portals. It gives service providers greater control over web sessions and
content delivery. It enables carriers to control content and network access on a
per-subscriber basis.
A personal network portal (PNP) policy permits an ISP to deliver customized

Web services to subscribers. When subscribers log on to the network, they are
directed by the policy to the provider's portal service and pushed to
customized home pages. The subscriber edge is the one point in the network
where the provider may actually implement the in-line portal.
A PNP service will translate a subscriber's HTTP requests from its intended
sites to a configured PNP web site. Subscribers can visit their intended web
sites only if the captive portal web site instructs the GGSN, which performs
the HTTP request “hijacking”, to switch from captive mode to non-captive
mode. After the configured elapse time has passed, subscribers may be
redirected to visit PNP web sites again.
The PNP features provide the capability to link retail or wholesale ISP
services to specific web content(s). Subscriber Hyper Text Transfer Protocol
(HTTP) or FTP requests are intercepted, and redirected from their intended
sites to pre-configured “personal network portal” web locations. For example,
instead of viewing an expected Hyper Text Markup Language (HTML) page,
subscribers are forced to navigate specific HTML pages on a portal server.
With the PNP capability, the subscriber session can be captured and steered to
specific content. Each subscriber can be mapped to a specific local home page
where different services and capabilities may be applied to them. Web
sessions can be captured on startup or at configurable intervals thereby
increasing advertising revenue opportunity.

Notes:
Policy-based forwarding 0
A policy-based forwarding policy enables an ISP to steer a packet that
matches a rule in the policy to an IP address that differs from the packet's
specified destination.
Description
• Capture and steer HTTP sessions
• Supports connectivity to an external portal server
Benefits
• Increased operator brand visibility
• Incremental ISP service/revenue model
— Capture web sessions on start up or at configurable intervals
— Match content to identified subscribers
• Quick content retrieval from local server support
The policy-based forwarding service can also be used for web steering. (The
Shasta GGSN supports co-located high bandwidth content servers. Accessing
content off a co-located server is generally much faster than having it traverse
over the public Internet. A web-steering policy permits an ISP to redirect
subscriber HTTP requests to a Web cache. The ISP can store frequently used
Web pages in the cache, promoting speed and efficiency. If the page is not
cached, it will be retrieved from the Internet.) A policy-based forwarding
policy essentially just forwards packets of matching conversations out the
interface chosen by performing a route lookup on the IP address specified in
the matching rules action.
Note: A web steering policy requires a cache that supports 'Forward

Proxy'. To support 'Transparent Caching', one can use policy-based
forwarding, in which case the proxy cache must be at one hop distance
from the Shasta GGSN. This limitation doesn't apply to a web steering
policy.

Notes:
Accounting 0
Accounting is used to collect network data related to resource usage by a
subscriber.
Accounting will track how many packets are sent and received by your
subscriber. If your subscriber has DiffServ applied, and is marking traffic,
your ISP can differentiate that traffic and count the packets based on the level
of service.
Accounting will divide the packet counts into separate “buckets”, based on
the marking applied to that traffic. Any traffic that does not match the
accounting policy is counted by Bucket 0 by default.
When you mark your traffic using a DiffServ policy, you can separate it into
different accounting buckets, based on the markings. If you do not mark
subscriber traffic, it will default to AF Class 1, Drop Priority 1 within the
Shasta. If you do not have an accounting policy set for this default marking, it
will be counted in Bucket 0.

Notes:
Exercises 0


Lesson 7
Introduction to maintenance and
troubleshooting
This chapter contains slides and notes for Lesson 7.
168 Lesson 7 Introduction to maintenance and troubleshooting Nortel Networks Confidential
0
Lesson 7 - slides 0
In this lesson, you will learn about the diagnostic and troubleshooting
capabilities of the Shasta GGSN equipment. You will learn about some
methods of monitoring performance, and how built-in diagnostics can detect
problems. You will learn about typical maintenance procedures, and how to
get technical assistance when you need it.
The following source contains a useful overview of troubleshooting

methodologies for the Shasta GGSN:
• NTP 411-5221-501, Core Network Troubleshooting Guide
There are no exercises associated with this lesson.

Introduction to maintenance and troubleshooting 1.0 18-22 23-28
Notes:

Nortel Networks Confidential Lesson 7 Introduction to maintenance and troubleshooting 169
The network view 0

Fault management is the process of interpreting and responding to alarms
displayed by the device under observation. Fault management tasks include
the following: device monitoring, acknowledgement of hardware and
software alarms, fault diagnosis, and fault recovery.
Fault management, maintenance, and troubleshooting need to be seen from a

network-wide perspective. The Nortel Networks Preside network management
portfolio consists of a set of ITU-T based network management features that
provide a centralized view of telecommunication networks. It aims to enable
service providers to monitor and evaluate the behaviour of a network on a
constant basis. It provides information and a means for service providers to
take either preventive or corrective action to maintain the desired network
performance level. Preside network management technology is Nortel
Networks’ long-term solution for unified networks management through which
new technology networks will be managed (UMTS, GPRS, IP core networks,
etc.). The Operation & Maintenance Centre for the GPRS/UMTS packet data
network (OMC-D) is a compact optimized subset of the Preside Management
solution designed to meet specifically GPRS Core Network management needs.
It provides the following management functions:
• fault management.
• alarm management.
• configuration management
• software download management.
• performance management.
• security management.
OMC-D provides remote administration for core network configuration, as

well as the download and activation of core network software releases. It ties
in to an underlying element manager for each core network device; for
example, SCS is the element manager for the GGSN.

Notes:
Assess the Shasta GGSN’s performance 0

The Shasta GGSN uses a combination of SNMP (Simple Network
Management Protocol) and non-SNMP proprietary protocols to provide
performance and availability information pertaining to the card, interfaces,
and general device related information. The GGSN can be configured to
generate SMNP Version 1 traps, based on standard IETF Management
Information Bases (MIBs) and Shasta-proprietary MIBs. An SNMP profile
can be defined on a GGSN by means of the SCS GUI client so that the GGSN
sends SNMP traps to an SNMP manager, either directly or through an SNMP
proxy. The current trap events include: Trap on Health Warnings, Trap on
Health Alerts, Generate Periodic Heartbeat, Trap on Hardware Warnings and
Alerts, Generate Power Up Trap, Trap on Intrusions, Trap on Failed Login
Attempts. The SMNP traps can be handled by an external SMNP
management system.
There are four types of logs that the Shasta GGSN can generate: event logs,
system logs, service logs, and service-accounting logs. Each type of log has
distinct characteristics as well as values and can be used for various purposes.
Event log items include: tunneling, security, backups, debugging, hardware
devices, processes and driver events. So, for example, an event log generated
following a card port failure can be used for fault management and
troubleshooting. System logs contain security and configuration information.
Service accounting can be used both for usage-based billing and for
performance reporting. A firewall service log can be used to notify a
subscriber of Denial of Service attack.
The Shasta GGSN collects logging information, then stores the information in
the SCS log server. The SCS is based on a distributed architecture where the
log servers are part of the architecture. The log server collects service logs
and accounting logs relevant to the respective GGSNs only. The log servers
do not collect event-logs information; the event-logs information is sent by
the GGSN (if configured) to an appropriate Syslog server. The files are stored
in binary files that can be viewed via the SCS interface or through
SCSLogCat (a utility that converts binary files into ASCII files).
The types of information that the GGSN logs provide include:

• user and session details (such as NAI, IP address, TX/RX bytes, TX/RX
frames, bad frames, TX/RX PPP frames, and TX/RX IP frames)
• system performance metrics (such as min/max users per hour, failed
authorization requests per hour, failed PPP attempts per hour, failed L2TP
attempts per hour, TX/RX bytes per hour, GGSN initiated session
clearings per hour, and GGSN restarts)

Notes:
Use the SCS Client 0

The SCS Client has various tools for performing monitoring and diagnostics.
Use these to view messages, logs, and alarms (except for those communicated
by indicators or displays on the hardware). They are:
• Monitoring window: right-click on the icon for a specific GGSN in the
Device Manager window, select Monitor, then one of several choices
(such as Chassis, Connection, Frame Relay, Trunk Interfaces, Routing,
Subscriber, Tunnels, VPNs, Access Properties, and ISP)
Note: Different monitoring choices are available, depending on whether
one is logged in to the SCS as ISP User or Device Owner.
• Diagnostics window: right-click on the icon for a specific GGSN in the

Device Manager window, then select Diagnostics
• Log Manager window: the Log Manager window enables you to view the
system-wide service and accounting logs gathered by the log server
module. Its Logging tab enables you to view an entire service log of a
network device. Its Accounting tab enables you to view the accounting
statistics for services, devices, ISPs, trunk, and VPNs.
Note: This window is only available when logged in to the SCS as ISP
User.
• Alarm Manager window: the Alarm Manager window enables you to

view and manage the system-wide alarms indicative of problems that
occur on Shasta GGSNs. Alarms are generated by the hardware and
software components of a Shasta GGSN. As opposed to events, the
Alarms within the device have been ranked on four severity levels. The
“Major” and “Minor” alarms map onto the “Warning” events, while the
“Critical” and “Information” alarms have a similar connotation.
The Shasta GGSN supports device logging. There are three type of device
logs: command, event, debug. Each type of log can be output to a system
log, console or disk. For outputting logs to a system log host, a host
address has to be provided. The command and debug logs only has the
“Info” severity level; the event logs can have “Info”, “Warning” or
“Critical” severity levels.
Note: This window is only available when logged in to the SCS as Device
Owner.
For more information about this, please refer to:

• the SCS online help
• the Shasta 5000 Broadband Service Node Service Creation System
Configuration Guide (Part No. 01449).

Notes:
SCS log structure 0

Shasta log files are stored in a directory structure that can expand as needed.
The log files in these directories have identical file names. The files in the
“isp” folders contain device, ISP aggregate, and subscriber-accounting
statistics. They also contain subscriber service statistics - for example,
Security and DiffServ statistics. If it is desired to export this log data to a
target system for processing, one must identify all log files and directories,
and then aggregate the logged data into a single file for processing. A typical
directory structure is seen here:
/server/log/
+-------region1
+-------device1
|-------isplog
| +-------security.log
|
|-------isp0
| +-------device.acc
| isp.acc
| trunk.acc
|
|-------isp1
|-------isp.acc
| service.acc
| trunk.acc
| vprn.acc
| vprnlink.acc
|
|-------sub1
| +-------antispoof.log
| +-------captive.log
| +-------ingress.log
| +-------shaping.log
| +-------security.log
| +-------diffserv.log
| +-------ediffserv.log
| +-------policer.log
| +-------steer.log
| +-------forward.log
| +-------nat.log
|
+-------sub2
:
The SCS Log Writer receives accounting data in binary format on a TCP
connection from the GGSN and writes it to disk for later processing.
(Accounting has to be turned on for device owner/ISP either through the CLI
or the SCS GUI). Accounting logs can be accessed either through the SCS log
GUI or by a text dump utility, SCSLogCat that exports the logs into text files.
For text files, use the SCSLogCat utility under the SCS install directory (SCS
server/bin/) to view logs.

Notes:
SCS log structure (cont.) 0

This is a sample location of accounting logging files in the SCS server:
/space/scs/server/log
This is a sample location of GGSN directories:
/space/scs/server/log/region1
This is a sample location of session logs for a GGSN:
/space/scs/server/log/region1/device2
This is a sample location of ISP log files:
/space/scs/server/log/region1/device2/isp2
For device owner there is only one accounting file containing device-related
statistics. There is one file for all the accounting information for an ISP. All
subscriber accounting is written into one ISP services-accounting file. The
“isp-0” directory, indicates the Device Owner ISP; it contains device statistics
and services accounting for the default ISP.
The latest data is always written to the service.acc file in the appropriate ISP
directory. When the file reaches the maximum file size, the file will roll over,
meaning the file service.acc will be renamed to service.acc.0 and a new
service.acc file will be created (into which the new data will be written). If
there is an older service.acc file at the time of the rollover, it will be renamed
to service.acc.1 and if a service.acc.1 file already exists, it will be deleted.
This is if the maximum number of rotations was set to 2. Do NOT delete
accounting non-rollover files (that is, those with a suffix of .1, .2, … .n).

Notes:
Use the iSOS CLI 0

By establishing a Telnet session with a GGSN, a system administrator can use
the command line interface (CLI) to interact with the CMC card. A user must
log in for each new session. After 15 minutes, the system automatically logs
out an inactive user. To log out, use the exit command, with no arguments.
The Shasta GGSN supports a wide variety of CLI commands. In particular,

the show commands allow one to monitor the activity, status, or configuration
of a subsystem or its components.
Key show commands include:

• show bootorder - shows the boot configuration
• show conn - shows the status of a connection
• show interface - shows the status of an interface
• show fib - shows the current forwarding information base entries
• show l2tp tunnel - shows the active L2TP tunnels
• show l2tp session - shows the active L2TP sessions
• show ppp sessions - shows the active PPP sessions
• show sub - shows subscriber information
• show version - shows the GGSN iSOS version load
• show card - displays the status of a particular circuit pack. (For example,
enter show card slot=4 to view the status of the card in that slot.)
Note that the show commands cannot be used to make any changes. Recall
that the CLI is not to be used for configuring the Shasta GGSN because any
changes performed through the CLI are overwritten by the configuration
downloaded from the SCS server after a “resync” operation. The CLI can be
used for initial setup, and for performing diagnostics and troubleshooting. All
provisioning and system administration is to be performed by means of the
SCS.
For more information about this, please refer to:

• the CLI online help - for example, enter this command: show ?
• the Shasta 5000 Broadband Service Node Administrative Command Line
Interface Guide (Part No. 01451).
• the Shasta 5000 Broadband Service Node Protocols Command Line
Interface Guide (Part No. 01452).

Notes:
Check the hardware indicators 0

The Shasta GGSN chassis and each individual circuit pack have a variety of
hardware indicators that communicate a wealth of detailed information.
(However, in many cases the simplest way to check the overall “health” of a
GGSN is simply to ping it from another computer on the same network.)
Refer to the Shasta 5000 Broadband Service Node Hardware Installation and
Maintenance Guide (Part No. 01453) to interpret the meaning of each
hardware alarm and indicator.
Chassis indicators
The chassis front has light-emitting diode (LED) indicators for Alarm Status
(minor, major, critical) and Fan Status.
The chassis front has a connector for alarm contact signals to enable an
optional audible alarm.
The chassis rear has a connector to receive status signals from optional AC
power shelf status.
Circuit pack indicators

The SFC has an alphanumeric display and two LEDs to provide information
about card configuration, status, and activity.
The CMC has an alphanumeric display and two LEDs to provide information
about card configuration, status, and activity. The PCMCIA slot has one LED,
and each Ethernet port has two LEDs, to indicate status.
The SSC has an alphanumeric display and two LEDs per SSM, and two LEDs
for the overall card, to provide information about configuration, status, and
activity.
Each line card has an alphanumeric display and two LEDs for the overall
card, and LEDs for each port, to provide information about configuration,
status, and activity.

Notes:
Understand the Shasta GGSN’s redundancy 0

In order to meet stringent availability and reliability standards, the GGSN is a
highly redundant carrier-class system. Except for the line cards, all common
elements are either redundant or load-sharing. Consider these aspects:
• Redundant (1+1) hot-swappable Switch Fabric Card (SFC)
— Backup is in warm-standby and does not pass traffic. If an SFC fails,
traffic is redirected from the line cards to the backup SFC. Since the
connection table is replicated, this will result in minimal data loss.
• Redundant (1+1) hot-swappable Control and Management Card (CMC)
— Warm standby; if primary CMC fails, existing subscriber sessions are
not immediately affected but no new sessions may be established until
the backup CMC is ready.
— When the backup CMC boots, all sessions are re-established in a
maximum of 3 minutes for a fully loaded CMC. CMC redundancy is
maximum 15 seconds of reboot (all sessions are dropped, users have
to re-establish their sessions).
• Load-sharing, hot-swappable subscriber service card (SSC)
— The traffic load is shared among SSCs. Since no SSC can be
considered “redundant”, there can be no “N+1” or “N+N”
configurations. The load on a failed SSC is distributed by the CMC
card to the other SSC cards. If insufficient space exists on a target SSP
to transfer the entire contents of a tunnel, as many sessions as possible
within that tunnel will be transferred. The remainder of the sessions
within the tunnel are dropped.
— If an SSM fails, subscriber state is maintained by the CMC and
sessions are shifted to the other SSMs by means of a load-balancing
algorithm. Each SSM runs a connection admission algorithm, so this
assumes that excess capacity is available. If no capacity is available,
the sessions will not be re-established. SSCs may be extracted or
inserted under scheduled downtime conditions, without clearing any
established sessions and resulting in minimal data loss. The CMC
shifts all sessions off the SSC before the card is removed.
• Hot-swappable (but not redundant) line cards. There is no automatic
hardware redundancy for line cards. (However, redundancy can be
achieved through the installation of multiple interfaces with different
connection paths and the use of an Equal Cost Multi-Path routing
protocol, such as OSPF.) Line cards are hot-swappable - that is, they can
be inserted or extracted in an operational system without affecting service
(provided that subscribers were previously re-routed).
• Hot-swappable fan trays, distributed DC and redundant AC power options

Notes:
Perform hardware maintenance 0

The only periodic hardware maintenance required by the chassis is
replacement of the fan filters. For instructions, refer to the Shasta 5000
Broadband Service Node Hardware Installation and Maintenance Guide
(Part No. 01453).
Occasionally, diagnostics may indicate that a component has failed. Field repair
consists entirely of replacement of defective items. No components of the
Shasta GGSN are user-serviceable. Components that can be replaced are as
follows:
• cards
• fan tray
• fan filter
For replacement procedures, please refer to Shasta 5000 Broadband Service

Node Hardware Installation and Maintenance Guide (Part No. 01453).
To return a failed component to Nortel Networks:

1. Obtain RMA number and approval to return component from the Nortel
Networks Technical Assistance Center (TAC).
2. Pack and ship in original container to Nortel Networks. Obtain a shipping
address from the Nortel Networks web site, www.nortelnetworks.com.

Notes:
Perform software maintenance 0

Routine software maintenance procedures include:
• Upgrade the Shasta GGSN iSOS software to the latest version. If you do
not already have an account set up on the Nortel Networks support page,
send an e-mail to shsupprt@nortelnetworks.com to receive one. An
account will be set up that will allow you access to the software updates.
To receive the new software, go to the Nortel Networks web site at
www.nortelnetworks.com and select Customer Support then Software
Distribution. Once you log in, then you can access the new software and
its release notes. The release notes will provide detailed information about
installing the software update. The main steps of the upgrade are these:
(1) New iSOS image is copied to pre-defined directory on the CMC. (2)
GGSN shutdown process is initiated. (3) GGSN initialization begins after
power-up. (4) New software image is loaded onto the CMC and
subsequent cards. (5) SGSN establishes a new session with GGSN.
• Upgrade the SCS Server and SCS Client software to the latest version.
• Clean log files from the SCS Server
• Monitor parameters related to the Shasta GGSN CPU (such as utilization)
• Check for core files on the Shasta GGSN
• Back-up SCS and LDAP databases. The Solid database, at the heart of the
Service Creation System, contains both device-specific and non-device
specific information relating to the SCS environment. The LDAP
component of the SCS architecture plays a critical role in providing
subscriber related information to the Shasta GGSNs. It is crucial to back
up the Solid and LDAP databases in order to maintain a complete set of
backups in case of a system failure. Both the Solid and LDAP backups
should be started at the same time, to have a complete snapshot of the
SCS system. Note that if a restore to one database is needed then you must
also restore the other database. For example, if the Solid database
becomes corrupt you must restore both the Solid and LDAP backups.
When needed, the process for restoring a previously generated backup
consists of copying the database and associated index files from the
backup location to the database directory. (Note: restoring a database
overwrites your existing database files!). To carry out this procedure,
please refer to the Nortel Networks document, Service Creation System
Backup Procedures For SCS Version 2.x.
It is also possible to move the LDAP and Solid databases from one host to
another (that is, to one with a different IP address and host name). As an
example of when this would be done, consider the case where Host A (where
LDAP and Solid databases currently reside) needs to be replaced. In this case,
the information on Host A can be transferred to Host B. Then, when Host A is
operational again, the configuration on Host A can be restored from Host B.

Notes:
Power down the Shasta GGSN 0

If the Shasta GGSN chassis must be powered down, use the following
procedure.
1. Use the shutdown command to halt the Shasta GGSN system:
shutdown
2. Set the circuit breaker at the rear of the chassis to the “off” position.
3. If using an optional AC power shelf, set the two switches at the front of
the shelf to the “off” position, shown as “0” on the switches.
Warning: The chassis can be powered by dual (or redundant) power feeds.
Ensure that the circuit breaker at the rear of the chassis is set to “off” before
installation or while servicing the unit.
While a GGSN shuts down, the software performs these steps:

• Negative replies to messages from the SGSN causes a round-robin to the
next available GGSN.
• GGSN no longer accepts new data sessions.
• GGSN tears down tunnel with SGSN.
Likewise, when a GGSN starts up, the software initializes in this manner:
• CMC is loaded with software image during power-up
• CMC forwards software image to other cards
• after system initialization, the SGSN initiates the setup of the tunnel with
the GGSN

Notes:
Troubleshooting overview 0
This is the general approach one would take to troubleshooting problems that
may be related to the Shasta GGSN:
1. Troubleshoot the Shasta GGSN equipment (by means of local and on-line
testing). You may find these tools helpful, among others:
— the SCS client (logs, diagnostics, alarms)
— the CLI
— hardware indicators on the chassis and circuit packs
2. Troubleshoot the Gn link (IP and ATM). You may find these tools helpful,
among others:
— Ping utility
— the CLI
3. Troubleshoot the Gi link (IP). You may find these tools helpful, among
others:
— Ping utility
— the CLI
An excellent troubleshooting resource is the Shasta 5000 Broadband Service

Node Troubleshooting Guide, Part No. 01462.
Appendix A in NTP 411-5221-927, Shasta GGSN Procedures Reference

Manual, contains a good overview of troubleshooting methodologies for the
Shasta GGSN.

Notes:
Find technical assistance 0

To get help, follow one or more of these methods:
• If you purchased a service contract for your Nortel Networks product
from a distributor or authorized reseller, contact the technical support staff
for that distributor or reseller for assistance.
• Visit the Nortel Networks web site at www.nortelnetworks.com and select
Customer Support - this will provide access to phone numbers, software
downloads, documentation, and much more
• send e-mail to shsupprt@nortelnetworks.com or
shtech@nortelnetworks.com

Notes:

test
Family Product Manual Contacts Copyright Confidentiality Legal statements DocInfo
GPRS 4.0 & UMTS 2.0

Shasta GGSN
To order documentation from Nortel Networks Global Wireless Knowledge Services, call
(1) (877) 662-5669
To report a problem in this document, call

(1) (877) 662-5669
or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at
http://www.nortelnetworks.com/td
Copyright  2000-2002 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its
employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the
same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly
authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
Contivity, Shasta and Nortel are trademarks of Nortel Networks. All other trademarks are the property of their respective owners.
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
Course number: Course UM642
Product release: GGSN 2.0
Document version: Standard 03.05
Date: September 2002
Originated in the United States of America and Canada

Shasta GGSN: OA&M - Student Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Shasta GGSN: OA&M - Student Guide

Uploaded by

Copyright:

Available Formats

Course UM642

GPRS 4.0 & UMTS 2.0

GGSN 2.0 Standard 03.05 September 2002

Course number: Course UM642

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright  2000-2002 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

Course UM642 Standard 03.05 September 2002For training purposes only

June 2002, Preliminary 3.04

May 2002, Preliminary 3.03

February 2002, Standard 2.03

January 2002, Standard 2.02

November 2001, Preliminary 2.01

September 2001, Preliminary 1.02

May 2001, Preliminary 1.01

Course UM642 Standard 03.05 September 2002For training purposes only

Course UM642 Standard 03.05 September 2002For training purposes only

About this course

Exercise Starting page

Items of prerequisite knowledge 0

test and/or equivalency test will be used to determine your incoming

Item # Description Importance

1 understand layout of GPRS or UMTS networks, by one or more of these: Essential

2 understand roles of GGSN in GPRS network, by one or more of these: Essential

3 understand basic functions of a BSN - such as perform aggregation, apply Desirable

4 have a working knowledge of the English language in order to effectively Essential

5 understand the Windows environment on a PC enough to launch an Essential

6 understand IP and networking fundamentals sufficiently to: Essential

7 understand data communications fundamentals enough to be familiar with Essential

9 understand the underlying wireless technology of GSM or UMTS networks Desirable

Course UM642 Standard 03.05 September 2002For training purposes only

Table 1: Course UM642, prerequisite knowledge (continued)

Item # Description Importance

11 understand the VxWorks environment enough to issue the commands Desirable

Item # Description Course module

1 describe roles of GGSN in GPRS network 2

2 list three basic access models 2

3 describe key functions and features of Shasta GGSN 2

4 list and describe IP services enabled by Shasta GGSN 2

5 describe the various types of tunneling connections 2

6 understand interaction between SCS and the network management 2

7 understand remote-access architectures 2

8 understand transparent and non-transparent access 2

9 understand load-balancing capabilities of the Shasta GGSN 2

10 understand redundancy capabilities of the Shasta GGSN 2

11 understand what utilities are needed in operations and provisioning 3

12 understand file architecture of iSOS storage, directories (such as to 3

14 understand differences between SCS and CLI interfaces (what are 3

15 describe the roles of “device owner” 4

Table 2: Course UM642, concepts reviewed or taught in class (continued)

Item # Description Course module

17 describe the management capabilities of the SCS 4

18 describe the diagnostic capabilities of the SCS 7

19 describe the diagnostic capabilities of the CLI 7

21 know the meaning of hardware indicator lights and displays 7

22 how to find out about Nortel Networks technical bulletins and 7

Task # Description Course module

1 acquire, install/update LDAP and SCS server software, on-site or 3

2 acquire, install/update Shasta GGSN software, on-site or remotely; 3

3 use the SCS client interface - know how to navigate 3

5 use on-line help in SCS 3

6 use on-line help in CLI 3

8 add a GGSN to an SCS region 4