Deploying_MobileNext.pdf

Juniper Mobile Infrastructure

Data traffic is overwhelming today’s

mobile networks, but the MobileNext

Broadband Gateway provides a con-

verged user plane function in an open

mobile core. All you need is a MX240

or higher, a few hundred thousand

smartphone subscribers, and this book.

By Joseph Naughton

DAY ONE: CONFIGURING THE MOBILENEXT BROADBAND GATEWAY

Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the complete library at www.juniper.net/books.

Published by Juniper Networks Books

DAY ONE: CONFIGURING THE MOBILENEXT BROADBAND GATEWAY

ISBN 978-1936779505

9 781936 779505

5 1 8 0 0

07100151

The primary goal of Juniper’s MobileNext Broadband Gateway (MBG) is to take the in-dustry to a new level in user plane scalability and performance, one focused on sup-porting the heavy signaling load generated by smartphones. With 100 million smart-phones now being sold worldwide every calendar quarter, scalability is a priority.

The MBG can be a Gateway GPRS Support Node (GGSN), a PDN Packet Data Network Gateway (PGW), or a combination of both running on the MX Series platform. Day One: Configuring the MobileNext Broadband Gateway is specifically aimed at the Mobile Pack-et Core, and here the author deftly showcases the MBG in a series of follow-along tu-torials that teach you how to configure and troubleshoot a basic MBG setup in a single day. Get ready for the smartphone-centric future where services, scalibility, and speed can be tweaked and configured whenever you need to with the MobileNext Broadband Gateway.

IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO: Configure and implement a GGSN/PGW solution on the MX Series platform.

Connect a Mobile UE through your existing Mobilepacket Core setup.

Run a series of commands to verify the health of the system.

“If you are a packet core engineer who wants to understand the Juniper MobileNext products,

or a Junos specialist who likes to get new ideas on how to use Junos and the MX platform in

the mobile world - choose this book as a starting point. Not only will it answer most of your

questions but it also covers the straightforward configuration of the MobileNext BroadBand

Gateway and EPC core. It’s the one book you need.”

Matti Samuli Penttilä, Technology Manager, Elisa Corporation

http://www.juniper.net/books

Day One: Configuring the MobileNext

Broadband Gateway

By Joseph Naughton

Juniper Mobile Infrastructure

Chapter 1 : MobileNext Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2 : Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Chapter 3 : GGSN Mobility Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Chapter 4: Advanced Configuration Techniques . . . . . . . . . . . . . . . . . . . . . . . .71

Chapter 5: System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 6: Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

© 2012 by Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. Junose is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

Published by Juniper Networks BooksAuthor: Joseph NaughtonTechnical Reviewers: Apurva Mehta, Sridhar Mani, Guy Davies, Venkatesh Gota, and Scott FlorenceEditor in Chief: Patrick AmesEditor and Proofer: Nancy KoerbelJ-Net Community Manager: Julie Wider

About the AuthorJoseph Naughton has fifteen years experience supporting solutions in the networking industry. He is the Technical Lead in JTAC for the MobileNext product portfolio at Juniper Networks. Prior to supporting the best of breed Mobile Packet Core products, he has supported policy solutions, including SRC and Steel Belted RADIUS, the BRAS line, and in a former life, VPNs, firewalls, and Shiva’s Lan Rover products.

Author’s AcknowledgmentsI must give accolades to Patrick Ames who had to climb mountains to help get this book published, and it should be noted that Guy Davies made many passes through the technical material and without his insight some errors may have made it to press.

ISBN: 978-1-936779-50-5 (print)Printed in the USA by Vervante Corporation.

ISBN: 978-1-936779-51-2 (ebook)

Version History: v1 July 2012 2 3 4 5 6 7 8 9 10 #7100151-en

This book is available in a variety of formats at: www.juniper.net/dayone.

Send your suggestions, comments, and critiques by email to [email protected].

ii

www.juniper.net/dayone

www.juniper.net/dayone

mailto:[email protected]

Welcome to Day One

Day One books help you to quickly get started in a new topic with just the information that you need on day one. The Day One series covers the essentials with straightforward explanations, step-by-step instruc-tions, and practical examples that are easy to follow, while also provid-ing lots of references on where to learn more. A second series, This Week, which covers more advanced topics that might be presented in a week-long training session, is also available.

Both the Day One and This Week book series are available at:

� Download a free PDF edition at http://www.juniper.net/dayone.

� Get the eBook edition for iPhones and iPads from the iTunes Store. Search for Juniper Networks Books.

� Get the eBook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device's Kindle app and going to the Kindle Store. Search for Juniper Networks Books.

� Purchase the paper edition at either Vervante Corporation (www.vervante.com) or Amazon (www.amazon.com) for between $12-$28, depending on page length.

� Note that Nook, iPad, and various Android apps can also view PDF files.

� If your device or eBook app uses .epub files, but isn't an Apple product, open iTunes and download the .epub file from the iTunes Store. You can then drag and drop the file out of iTunes onto your desktop and sync with your .epub device.

iii

iv

What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic administrative functions of the Junos operating system, including the ability to work with operational commands and to read, understand, and change Junos configurations.

This book makes a few assumptions about your network knowledge, your understanding of the MX Platform, and working with Junos. If you do not meet the following assumptions, portions of this book and its tutorials may be difficult to comprehend.

Finally, you should have a good understanding of GSM and LTE.

After Reading This Book, You’ll Be Able To...

� Configure and implement a GGSN/PGW solution on the MX Series platform.

� Connect a Mobile UE through your existing Mobilepacket Core setup.

� Run a series of commands to verify the health of the system.

Chapter 1

MobileNext Architecture

Peering Into the MobileNext Specific Hardware . . . . . . . . . . . . . . . . . . . . . . . . 7

Mobile MX Processes and Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

How the MBG Handles Subscribers (Steering) . . . . . . . . . . . . . . . . . . . . . . . . . 11

MBG Resource Management Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 DayOne:ConfiguringtheMobileNextBroadbandGateway

Welcome to Juniper Network’s Mobile Packet Core. If you are new to this exciting new technology, that many just call Mobility, welcome. Even if you are not new to Mobility, welcome anyway. There are some wonderful aspects of Juniper’s Mobile Packet Core that you should find most interesting, if not revolutionary.

This book is specifically aimed at Juniper Networks Mobile Broad-Band Gateway (MBG) products comprised in the Mobile Packet Core. The MBG can be a Gateway GPRS Support Node (GGSN), a PDN Packet Data Network Gateway (PGW), or a combination of both running on the MX Series platform. The MBG can also be a Serving Gateway (SGW) node, but that type of deployment goes beyond the confines of this book.

Figure 1.1 illustrates a general Mobile Packet Core deployment with the MBG at the center acting as a GGSN.

Mobile stations

SGSN

SGSN

GGSN

Charginggatewayserver

Charginggatewayserver

Gninterface

Gninterface

Giinterface

Giinterface

Gninterface

Ga interfaces

IP networks

Operations and management

interfaces

Operations andmanagement

entity

Corenetwork

Internet

Operations andmanagement

entity

Corporatenetwork

Figure 1.1 A Typical Deployment for Juniper’s Mobile Packet Core Solution

By the time you’ve gone through this book you should be familiar enough with the configuration, logging, and tools on MBG that you will be able to configure and troubleshoot a basic MBG setup. To this end, the book refers to an imaginary operator called Massachusetts Telecom (Mass Telecom), a small regional mobile service provider who would like to deliver world-class mobile services. Appropriately,

Chapter1:MobileNextArchitecture 7

Massachusetts Telecom reviewed the legacy solutions of other vendors and decided on the Juniper Mobile Broadband Gateway solution. This book should be interesting enough to hold your attention yet detailed enough to allow you to understand the design solution and be comfort-able setting up the MBG in a day, just like Massachusetts Telecom did.

NOTE This book refers to the MBG as a GGSN when it is in the 3G-world and as a PGW when it is in the 4G/LTE-world.

ALERT! This book assumes you know the basics of the MX platform, the Junos OS, and 3G/4G technologies. It explains and spells out some of the basics but is designed to get you familiar with Juniper’s MBG product and not as a training manual for the MX, the Junos OS, or the basics of GSM and LTE mobile technologies.

MORE? The Day One library has over two dozen books about using and working with the Junos OS, as well as configuring and deploying Juniper network devices such as the MX Series, freely available at http://www.juniper.net/books.

MOBILE TIP While you should understand the basics of GSM and LTE technologies before you begin this book, tips do show up throughout explaining mobile standards whenever a technology overview is needed to fully understand a given section of the material.

Peering Into the MobileNext Specific Hardware

Before setting up the MX chassis, before configuring an APN or setting up the Gi interface, and before all that other fun mobility stuff, it would be wise to understand what MobileNext means to the MX from an architectural perspective, and what the MX means to MobileNext. What does our mobile code add to the MX? How does it use the MX? This may seem like a deep dive when you are antsy to roll up your sleeves and get at the terminal, but it’s actually a great place to start.

NOTE This is a good time to reaffirm that the MBG runs only on the MX240, MX480, and MX960 platforms.

MXLineCards

It is important to understand that when the MX is acting as a MBG you cannot use the same old line cards that you may have always used with an MX chassis. The first supported cards for the Mobile Broadband


Gateway are the enhanced MS-DPC cards, called MX-MOB-SDPC, which are the service cards. This MS-DPC adds significantly more memory - 16GB - than the standard MS-DPC, so it can manage a larger number of subscribers.

The MS-DPCs PICs can be used as a Session PIC (SPIC) from which the subscriber is stored and managed, or it can be used as a Service PIC, from which Mobile Applications like HTTP HE (Header En-hancement) are run. When used as a SPIC the MS-DPC cards are the GTP-C control plane anchor points.

At this time it should also be pointed out that the MBG requires at least one MS-DPC SPIC to be available to manage subscribers. With-out this SPIC the MBG is not a MBG.

NOTE This book does not go into any details on the Service PIC.

As for the interface cards, the Mobile Broadband Gateway supports using the enhanced MPCs. There is a fixed 16-port card, with each port being a 10GE interface. This card has 4 PFEs (Packet Forwarding Engine). There is also the non-fixed port card that can take a slew of different MICs (Modular Interface Cards). This type of card has two PFEs.

The MPCE card’s PFEs are the anchor point, also known as anchor pfe (apfe) for GTP-U traffic off the Gn interface on a GGSN and S5/S8 interface on the P-GW.

VerifyingtheCards

So now that you know everything about running Junos MobileNext code on the MX platform using these enhanced interface and service cards, how do you know if you have the correct cards? Easy. From within the Junos CLI run the command show chassis hardware to see if the enhanced boards are present. For example, the enhanced MPC interface card with 16 10GB ports will display as MPCE not MPC:

root@GGSN-960> show chassis hardware Item Version Part number Serial number Description....FPC 0 REV 06 750-036284 YZ6730 MPCE 3D 16x 10GE

The enhanced MS-DPC service cards, display as MS-DPCE:

root@GGSN-960> show chassis hardware Item Version Part number Serial number Description....FPC 2 REV 05 750-036585 ZB9763 MS-DPCE


NOTE The version, part, and serial numbers may differ on the cards seen in other MX devices, and that is fine, as long as the description shows them as being enhanced.

If the cards do not show as enhanced they cannot be used in our Mobile setup. Note that you can still use non-enhanced cards in a MX chassis being used as a GGSN or PGW that is running the required number of enhanced cards, as long as the non-enhanced cards are being used for a non-mobile function.

NOTE Another component you have the option to use in the MBG is the Juniper SSD card that installs on the RE. This card is used to store charging records.

Mobile MX Processes and Terms

Next up, let’s look at a few of the processes that run on the MX and are unique to our mobile solution. This way, when the processes are mentioned later on in the book you’ll know what they do, and can refer back to this section if necessary.

� MobileD: This process manages the mobility CLI commands. If this process dies no mobile commands can be run from the CLI. It also hosts the AAA and IP assignment functions.

� Mobile-SMD: This process runs on the SPICs. All the mobility applications are managed by this process.

� ChargeD: This is the Charging Daemon. It manages the creation of call detail records (CDRs) and the sending of these records to a Charging Gateway, AAA server, or even storing them locally on the Solid State Drive (SSD). It should be mentioned that the SSD resides on the RE.

� rmpsD: This is the Resource Management Process responsible for the division of resources (IP address pools, GTP TEIDs, etc.) and their distribution to each of the SPICs and Anchor PFEs.

� RCM (Resource Controller Module): This process runs on the SPICs and PFE Control Processors. It works hand in hand with the RMM process to obtain resources and to inform the RMM process of current resource utilization. The RMM takes the current load information from the RCM process and pushes it to each SPIC so the local RCM knows which Anchor PFE to use.

� RMM (Resource Management Module): This process runs on the Routing Engine. It manages Mobile Resources and knows the utilization of each Anchor PFE and Anchor SPIC. It also moni-


tors the availability of GTP peers like the SGSN and SGW nodes in the Mobile Packet Core, and assigns resources like TEIDs and source ports to SPICs and PFEs.

FastPathandSlowPath…

Two more terms you need to understand and know when they are used are Fast Path and Slow Path.

� Slow Path refers to traffic that is routed through the UP (User-Plane Processor), also known as the SPIC. This is often referred to as slow path traffic flow.

� Fast Path is traffic that is forwarded from the APFE towards the egress PFE or ingress PFE, without going through the UP. This is referred to as fast path traffic flow.

So, going through the MS-DPC SPIC is slower than going from MPC PFE to MPC PFE, but since some actions need to be processed by the MS-DPC, using the slow path is not always a bad thing. For example, if GTP packets have been fragmented before they arrived at the MBG, use the SPIC to rebuild the packet. Also GTPc packets must use the UP since the subscriber session is managed there.

InlineCharging

An important feature of the MBG is Inline Charging because it is handled on the PFE of the MPC, not the SPIC. This allows the MBG to manage the large number of subscribers it is capable of handling and ensures that the charging for such numbers is accurate. A charging record is maintained on the Anchor PFE for each PDP Context or EPC Bearer. The charging data is periodically sent to the SPIC that is the anchor for the subscribers with whom the PDP context is associated.

NOTE Inline charging is the task of maintaining data for the mobile subscrib-er sessions for billing purposes.

MobileInterface

The last item on this section’s agenda is explaining the MIF acronym that you’ll encounter in subsequent chapters. The Mobile Interface (MIF) is just an interpretation of the logical interface architecture (IFL). Once a packet is associated with a subscriber record, an interface template (MIF-IFL) consults the subscriber record to identify the proper packet forwarding, filtering, rate-limiting, queuing, and accounting behavior.


The MIF is tied to the APN configuration, which is covered in the configuration section of this book.

How the MBG Handles Subscribers (Steering)

You could call the next two sections “How Juniper’s MBG Manages Mobile Resources.” Suffice it to say this is really important, and please do review carefully before jumping into configuring your MX.

First, let’s discuss why the MBG needs to steer packets. Steering is a key component in the mobile solution allowing the MBG to efficiently handle a large number of subscribers without overwhelming the routing engine.

NOTE Steering to the MBG involves taking a GTP packet from the Gn or S5/S8 PFE and redirecting it somewhere internally. Steering is also the act of taking a non-GTP packet from the Gi PFE and redirecting it some-where internally when the destination is the mobile subscriber’s device. All of this makes more sense in about twenty pages.

For GTPc packets, the MBG uses the steering mechanism so the PFEs are able to load-balance the PDP context activation messages to all mobile enabled MS-DPCs. All other GTP messages with TEID 0 will be delivered, also known as steered, to one designated MS-DPC. GTP messages with a non-zeroTEID will be assumed to be allocated by a given MS-DPC and should be sent to the appropriate SPIC, managing that session by using the TEID found in the PDP context activation.

GTPu traffic steering, on the other hand, allows the PFE managing the interface to send the traffic to the PFE that is anchoring that session. From the anchor PFE, the GTP packet will be decapsulated and sent to the Gi/SGi interface, or in the case of Gi/SGi to Gn/S5/S8, the traffic will be re-encapsulated. The one exception with GTPu traffic is if the packet is received as fragmented by the GN or S5/S8 PFE. These fragmented packets must first be steered to a SPIC for reassembly. This is the one type of GTPu traffic that takes the slow path.

Now, let’s examine Figures 1.2 and 1.3 to help illustrate subscriber setup.

In the example in Figure 1.2, the MPC’s PFE would select a mobility-enabled MS-DPC to manage the subscriber’s session.

In Figure 1.3, the data traffic arrives on an interface on MPC-1, and then moves to MPC-2, which hosts the anchor PFE before being routed out the Gi interface on MPC-4.


Routing Engines

Fabric

Anchor Anchor

3

14

2

SessionControl

AAA/Diameter

ChargingFirewall

etc.

Session DPC-1 Session DPC-2

SessionControl

AAA/Diameter

ChargingFirewall

etc.

Gn/Gp/S5/S8IP Network

Gi/SGiIP Network

MPC-2 MPC-3MPC-1 MPC-4

User Equipment Servers

Figure 1.2 Steering Example for a PDP Context Activation

To explain the whole steering model in more detail, we need to start by identifying the attributes by which the MBG steers traffic to a particu-lar Session PIC, or Anchor PFE, or Create Session Request for LTE. Note that this steering occurs every time a GTP packet hits an interface on any MPCe that is setup as a Gn, S5/S8 or Gi Interface. There are three definable scenarios where the MBG will steer when GTP packets are involved:

� The MBG will steer on the IMSI (a unique identifier that is associated with a Mobile device ) when the TEID is 0 in a GTP-C packet.

� The MBG will steer on the TEID when the TEID is non 0 in a GTP-C packet.

� The MBG will steer on the TEID in GTP-U packets.


Routing Engines

Fabric

Anchor

6

58

7

SessionControl

AAA/Diameter

ChargingFirewall

etc.

Session DPC-1 Session DPC-2

SessionControl

AAA/Diameter

ChargingFirewall

etc.

Gn/Gp/S5/S8IP Network

Gi/SGiIP Network

MPC-2 MPC-3MPC-1 MPC-4

Anchor

User Equipment Servers

Figure 1.3 Steering Example for GTP-U (aka Data Traffic)

Steering the IMSI When the TEID is 0 in a GTP-c Packet

This scenario is normally the GTP packet type of Create PDP Context Request or Create Session Request for LTE. This GTP packet type, Create PDP Context Request, will be steered from the MPC to an active Session PIC (SPIC) on one of the MS-DPC cards. The selection of the SPIC is based on an IMSI-based hashing algorithm that has been added to the Junos mobility code. This algorithm allows an even distribution among the available SPICs for Create PDP Context Requests and Create Session Requests.

The SPIC that is now processing the Create PDP Context Request assigns a TEID for this Subscriber’s session, if all went well when processing that request.


MOBILE TIP For 3G, a GTP packet type of Create PDP Context Request is just the subscriber attempting to get access to the Mobile Packet Core through the SGSN. If the subscriber attaches to the SGSN successfully and wishes to send data, the SGSN will create the GTP Create PDP Context Request message based on the information it receives from the Radio Access Network (RAN) and send it to the GGSN over the Gn interface.

MOBILE TIP A TEID is a number created by the MBG and its GTP peers, like the SGSN or MME, to identify the GTP tunnel for this PDP context. A subscriber can have multiple PDP contexts, each with a unique TEID. The TEID for the control plane and the TEID for the data plane may be different.

Steering the IMSI When the TEID is non-zero in a GTP-C Packet

After the TEID is assigned to a session by the SPIC, if, at a later point, a GTP-C packet arrives on a Gn or S5/S8 MPC interface with a TEID of non-zero, the MBG will use the TEID to send the packet from the current MPC’s PFE that has taken the packet off the wire, and forward it to the SPIC that is managing the session for further session processing as needed.

Steering the TEID in GTP-U Packets

When a GTPu packet arrives on the GN or S5/S8 interface, the MBG uses the TEID for the data plane to steer it from the PFE that has taken the packet off the wire to the assigned anchor for GTP decapsulation. When data packets arrive on the Gi interface destined for a UE’s IP Address, the system will send it to the assigned anchor PFE for GTP encapsulation.

Note that the anchor PFE actually does more than just encapsulation or decapsulation of the data packet – it also handles proper packet for-warding, filtering, COS rate-limiting, queuing, and accounting behavior.

NOTE Steering happens to every single GTP packet that traverses the MBG. Every GTP packet!

In the next section we will look at these scenarios in more depth.

MBG Resource Management Architecture

Since all the TEIDs the SPICs pass out to each session are considered a resource to the Mobile Broadband Gateway, and since every Mobile session uses TEIDs, let’s look at the resource management architecture of the MBG using the TEIDs as our first example. In order to distribute these TEID resources efficiently, each SPIC on a MS-DPC asks the active


Routing Engine for a chunk of TIEDs, as whimsically shown in Figure 1.4.

MS-DPC Routing EngineI need some TEIDs!

Here, take 1000 thru 2000.RCM RMM

Figure 1.4 Give Me Some TEIDs

For example, the SPIC at 4/0/0 asks for some TIEDs from the Routing Engine, and then it receives TEID 122200 through 123200. This distribution is known by the whole system since the SPIC’s, mobile-enabled PFEs, and the Routing Engines each have a table that notes which TEID resources have been distributed to which SPIC. Now, in this example, only the SPIC at 4/0/0 will be able to assign TEIDs 122200 through 123200 to any mobile sessions that it anchors. No other SPIC on any MS-DPC on this system can use these specific TEIDs to assign to a new session, not even the other SPIC on this same MS-DPC. The one exception to this rule would be if redundancy is set up among SPICs. In this case the secondary SPIC for a pair will use these resources if the primary SPIC goes away for any reason. Redun-dancy among SPICs is explained in detail in a later section of this book.

The SPIC requests these TEID blocks through the local process called Resource Controller Module (RCM) that runs on all mobility-enabled SPICs. The RCMs communicate to the Resource Manager Module (RMM) process, which manages the resources globally. Remember the RMM runs on the active Routing Engine.

In a nutshell, the MGB architecture manages resource assignment by maintaining tables on the Routing Engine via the RMM, as well as on each SPIC and mobility-enabled PFE via the RCM. You will see more of this as the book progresses.

So to review, let’s again ask the question: “But how does the system know how to steer based on the TEID?” Well, when a TEID range is assigned to a SPIC by the Routing Engine, the RMM process also updates another table, which is sent to the mobility-enabled PFEs on each mobility-enabled MPC. This allows a PFE that receives a GTP-C packet from the wire with a TEID of non-zero to know which SPIC is currently managing that session based on the TIED. Remember steering to a SPIC on the TEID is only for GTPc packets, not GTPu. GTPu steers to AFPEs. Control versus data.


AnchoringaSubscriber

By now you should understand how TEIDs are distributed and how the system steers the GTPc packets based on the TEID value, but how does the system/SPIC decide which PFE to anchor the subscriber session that the TEID is also being assigned to? Does the SPIC just randomly ring certain PFEs, asking them to anchor a mobile subscrib-er? No, the PFEs are considered a mobile resource, too, and the RCM process on the SPIC that is bringing up the management of the sub-scriber chooses which Anchor PFE is used for the given subscriber session.

Here is how the PFE resource gets handed out:

1. First choice is given to the PFE that is the egress PFE to reach the peer of the session at the SGSN/S-GW, thus avoiding one extra hop through the fabric for the downstream traffic to the UE (i.e., traffic from Gi to Gn). This information is readily available to the SPIC from the Peer Information Table.

2. If the first choice PFE is already heavily loaded (resources are exhausted on the PFE), the second choice is the PFE that is the next-best egress PFE (ECMP or backup next hop for the route) to reach the session Peer. PFE load information is available to the SPIC via the RMM.

3. If a suitable Gn-facing Anchor-PFE cannot be found, then it considers anchoring the subscriber on a Gi-facing PFE, if such a PFE also serves as an Anchor PFE (APFE). Note that this is only possible if there are very few Gi-facing PFEs. The primary purpose here is to avoid traversal of the fabric to reach the Anchor PFE.

4. Finally, if both first and second choice PFEs are heavily loaded and there is no suitable Gi-facing Anchor PFE, then the least-loaded PFE in the system is chosen as the anchor PFE.

Remember that each APFE in the system that has load attached to it has to tell the system about the resources in use. The RCM process on the PFE tells the RMM process on the Routing Engine about its current load. The system uses this information to help in determining which PFE a SPIC should pick next when a new session is coming online.

PeerInformation

Okay, so you understand that TEIDs and PFEs are mobility resources in the eyes of the MBG. Let’s now look at a more unique resource type, called Peer Information, which is another piece of important informa-tion distributed by the MBG. The RMM process keeps track of the reachability of MBG peer nodes, such as SGSNs and SGWs, and it also


notes the egress PFEs that reach the peers. The Peer Information gets pushed to all the RCMs on the SPICs, allowing the SPICs to use the table when selecting the most efficient APFE for a new subscriber session’s PDP contexts, meaning the PFE with the fewest, passes through the fabric for Gn/S5/S8 to Gi/SGi.

Peer Information works when non-session specific GTP-C messages with a TEID of zero, called GTP Echo requests, are received from a peer node. These messages are processed on a Designated SPIC of the peer. When these messages are received from a new peer (not known to the MBG yet) the ingress PFE forwards them to a Designated SPIC.

NOTE The Designated SPIC is one of the SPICs that the system chooses to handle peer management, otherwise know as path management, to the known peers such as a SGSN or a SGW. This Designated SPIC is responsible for doing complete path management of the peer, including sending and receiving periodic echo messages, and informing all other SPICs in the system about peer reachability, when a peer has not replied to x-number of consecutive echo requests.

SourcePortRanges

The now well-known RMM process also handles allocation of source port ranges, which is another mobility resource of the system, and it does so in a way similar to how it handles TEIDs. It breaks them into ranges and then assigns these ranges in groups to different SPICs. When the SPIC has to communicate with an external mobile applica-tion, it uses this source-port information. Thus, when data arrives back at the MBG from an external mobile application such as a Charging Gateway, a RADIUS server, or a PCRF server, the PFE that receives the packet knows which SPIC is handling the subscriber session based on the source port. This allows the PFE to forward the packet to the appropriate SPIC for processing.

ManagingDHCPResources

DHCP Servers can be used to assign addresses to subscribers terminat-ing on the MBG, acting as a GGSN or a PGW. Since a DHCP Server sends replies back to the client (in this case the MBG) on UDP port 68, and does not use random source ports, the MBG cannot use the source port pools to steer DHCP traffic from the PFE to the SPIC that man-ages the session attached to a given DHCP exchange.

Instead, the MBG uses the Transaction ID (XID) in the DHCP header for steering the reply packets from the DHCP server back to the anchoring SPIC. The PFE that receives the reply knows which SPIC to


use because the anchored SPIC managing the user’s session constructs the XID from a table it has. This table, like other resource tables, is created by the RMM process on the Routing Engine and sent to the SPIC that requires assigning resources at this point in time. The RE also propagates the table down to the PFEs, so they know which SPIC the replies should be sent to.

So, to repeat the process, at the time the DHCP module generates BOOTREQUEST messages, the SPIC relays the message to the DHCP server with a XID from the unique range assigned to the SPIC. Next, as the DHCP server reply message is received by the PFE, it can be steered to the corresponding SPIC based on the XID that is known by each PFE.

NOTE One thing to note about all resources that are managed by the RMM to RCM process is if there is a secondary SPIC configured for the SPIC managing the session, the unique tables are propagated to the second-ary cards. Redundancy can be made to work! We will look at how to configure redundancy in a later section.

AdvancedRequestManagement

Let’s review the basics first. A Create PDP Context Request or Create Session Request is received for a subscriber, who at this point is now known to the MBG by their IMSI. The RCM process on every SPIC and PFE are aware of current resource utilization due to the RMM on the RE gathering stats from every mobility-enabled line card (MS-DPCs and MPCs) and then pushing those stats globally back to all the mobility enabled line cards. This leads the Ingress PFEs on the receiv-ing MPC to know which SPICs cannot be used to manage a new session due to resource limitations. The session now gets directed from the ingress PFE to an available SPIC based on the IMSI hash algorithm. So the Create PDP Context Request or Create Session Request is off to a selected SPIC to get processed, meaning TEIDs assigned, APFE chosen, etc. Nice stuff! But there are other things that can happen when a Create PDP Context Request or Crate Session Request is steered.

For example, when the MBG receives a new Create PDP Context Request for a subscriber, the MBG must be able to delete any existing sessions for the same IMSI, or NSAPI, since that would mean the existing session is a stale, or a hung, session.

MOBILE TIP An Access Point Name (APN) is an information element of a GTP packet providing information on how to reach a network. The NSAPI is an identifier used to identify a PDP context. It is dynamically selected by the Mobile Station (MS).


Also, when the SGSN retransmits a Create PDP Context Request message or the SGW retransmits a Create Session Request, the MBG needs to drop the retransmitted message if the original request message was already processed. This can happen if the response to the peer (SGSN or SGW) was lost, or if the MBG is overloaded and processing slow at that moment.

In addition, there is also a 3G scenario where the MBG receives a MS Info Change Notification Request message for a session. This is not a Create PDP Context Request message, but another type of control message. When the PFE receives this type of message, and it has a TEID of 0, the PFE handles this as a new request and sends it to a SPIC (the PFE does not analyze GTP-C message type, only the TEID).

Now, when a SPIC receives this type of message there is some new processing performed that is not done when a Create PDP Context Request or ECHO Request is received. The SPIC has some advanced GTP processing, it being the service PIC. So the SPIC sees the TEID of 0, but it also sees the message type. The SPIC now looks into its tables to see where the IMSI in the request is currently be managed and forwards the request to the SPIC where the IMSI is currently hosted so the session can get further processing on the correct SPIC.

MOBILE TIP MS Info Change Notification Requests may be sent to the GGSN when an event occurs where the Mobile Subscriber changes its state in some manner, such as a location or tracking area change.

An astute reader might ask how the MBG knows where the IMSI is. The answer is: the data is stored in the IMSI Location Database. On the MBG, after a subscriber session is distributed to the SPIC and the Create PDP Context Request or Create Session request message is processed correctly, the IMSI from the session is then added to the IMSI Location Database. This database is known to the RMM and RCMs processes. Now the IMSI is known by the whole system and the system knows which card is managing the session.

GTP-UDataSessions

Admittedly, there is a lot to this steering of the GTP-C packets and mapping of resources, but so far the discussion has been about control traffic, setting up the GTP-C session, and not about all the data that we expect the system to pass.

After the subscriber’s session/bearer has been created on the MBG via GTP-C steering, GTP-U data sessions will be based on the TEID assigned for the data plane that was passed back to the peer by the


MBG. You know that the Ingress PFE can steer incoming GTPc packets based on the TEID value in the packet, and it also does this for GTP-U packets. Like the TEIDs for GTP-C packets, each SPIC that is setup for mobility also requests some TEID ranges for GTP-U setup.

Let’s rehash this process, but for GTPu this time. Remember that the MBG assigns the TEID that is used for data packets, also known as GTP-U packets. Look at the output for a 3G example in Figure 1.5. You can see in the Create PDP Context Response that a TEID Data I value of 0x14240162 has been assigned in the response. The GTP peer sends this as the TEID in any GTP-U request for this subscriber. It will not send the TEID for the GTP-C response (0x00000102 in this snoop) for anything but further GTP-C processing, if that is needed. To drive it home the TEID is different for GTP-C and GTP-U.

Figure 1.5 GTP-U Snoop

Summary

While it may have seemed like a lot of information to digest, the MobileNext architecture is very well defined and orderly. It has to be in order for it to work at the scale needed. If anything, be thankful you weren’t trying to copy the whiteboard during the meetings when this architecture was deduced.

Reread this chapter if you need to remember some of the session particulars, but if you’re moving on to the MX configurations in the next chapters, it is worth your while to intimately understand how the MBG processes its subscribers.

Chapter 2

Deployment

What’s In Your MX? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Editing the Chassis Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Setting Up the Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Creating a Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


This book assumes you know the basics of how to configure a MX, but because you are probably new to the GGSN/PGW, it covers as much setup information as possible. So expect some turbulence ahead if you have no MX experience – the flight attendants will have to check your seatbelt.

MORE? There are dozens of tutorials on using Junos and on working with the MX Series in the Day One library at http://www.juniper.net/books. And the technical documentation for MobileNext products is both excellent and available online at http://www.juniper.net/techpubs/en_US/release-independent/mobilenext/information-products/path-way-pages/product/index.html.

What’s In Your MX?

First, let’s make sure you know what is in your box. In this book’s example you can see that it’s an MX480 named GGSN-960 because it wishes to be a larger box with an MPCE (16 10GE ports) in Slot 0 and 1. Slots 2 and 4 have the MS-DPC service cards. Slots 3 and 5 have the MPCs, with Slot 5 having one MIC (4 10GE ports) and Slot 3 having no MICs:

root@GGSN-960# run show chassis hardware Hardware inventory:Item Version Part number Serial number DescriptionChassis JN11AC398AFB MX480Routing Engine 0 REV 15 740-013063 9012013202 RE-S-2000CB 0 REV 09 710-021523 ABBH5083 MX SCBFPC 0 REV 06 750-036284 YZ6730 MPCE 3D 16x 10GE CPU REV 10 711-029089 ZA3724 AMPC PMB PIC 0 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ Xcvr 0 REV 01 740-031981 UHQ057R SFP+-10G-LR PIC 1 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ PIC 2 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ Xcvr 0 REV 01 740-013111 62561016 UNKNOWN PIC 3 BUILTIN BUILTIN 4x 10GE(LAN) SFP+FPC 1 REV 06 750-036284 YZ6717 MPCE 3D 16x 10GE CPU REV 10 711-029089 ZA3703 AMPC PMB PIC 0 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ Xcvr 0 REV 01 740-031981 UHQ082E SFP+-10G-LR PIC 1 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ PIC 2 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ PIC 3 BUILTIN BUILTIN 4x 10GE(LAN) SFP+FPC 2 REV 05 750-036585 ZB9765 MS-DPCE CPU REV 02 710-036586 YZ1651 DPC PMB 2GB PIC 0 BUILTIN BUILTIN MS-DPC PIC PIC 1 BUILTIN BUILTIN MS-DPC PICFPC 3 REV 07 750-036286 ZA7845 MPCE Type 2 3D EQ CPU REV 06 711-030884 ZA7473 MPC PMB 2G QXM 0 REV 05 711-028408 ZA8286 MPC QXM

http://www.juniper.net/books

http://www.juniper.net/techpubs/en_US/release-independent/mobilenext/information-products/pathway-pages/product/index.html



Chapter2:SettingUptheMBG 23

QXM 1 REV 05 711-028408 ZA8195 MPC QXMFPC 4 REV 05 750-036585 ZB9763 MS-DPCE CPU REV 02 710-036586 YZ1657 DPC PMB 2GB PIC 0 BUILTIN BUILTIN MS-DPC PIC PIC 1 BUILTIN BUILTIN MS-DPC PICFPC 5 REV 07 750-036286 ZC3842 MPCE Type 2 3D EQ CPU REV 06 711-030884 ZA6137 MPC PMB 2G MIC 0 REV 09 750-028387 JZ8993 3D 4x 10GE XFP PIC 0 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 REV 01 740-014279 723019A00068 XFP-10G-LR PIC 1 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 REV 01 740-011607 AVAA0848M2EDX XFP-10G-LR QXM 0 REV 05 711-028408 ZC3632 MPC QXM QXM 1 REV 05 711-028408 ZC3491 MPC QXMFan Tray Enhanced Left Fan Tray

Editing the Chassis Hierarchy

The first step is to edit the chassis hierarchy. For the MPCE cards in slots 0, 1, 3, and 5, attach the mobility package. If you do not do this, the cards won’t be able to handle the GTP C and GTP U requests from the SGSN/MME/SGW and RAN GTP-U direct tunnel requests. So, if you want to be a GGSN or PGW, set this package up on at least one MPC that will be Gn or S5/S8 facing!

[edit chassis]fpc 0 { forwarding-packages { mobility ggsn-pgw; }}

Do you want those MS-DPC/SPICs to be able to handle any mobile applications? Remember, if you want to be a GGSN or PGW, set up this configuration on at least one MS-DPC PIC. We’ll assume you do want mobile applications, so let’s configure the MS-DPC FPC section as shown here. Note that there are some settings here that can be adjusted and tweaked based on the performance requirements of your MX.

[edit chassis]fpc 2 { pic 0 { adaptive-services { service-package { extension-provider { control-cores 1; data-pollers 1; object-cache-size 512; total-wired-memory 14336; boot-os embedded-junos64; package jservices-mobile;


} } } } pic 1 { adaptive-services { service-package { extension-provider { control-cores 1; data-pollers 1; object-cache-size 512; total-wired-memory 14336; boot-os embedded-junos64; package jservices-mobile; } } } } }

Here are a few notes on some of the options used here (remember these values are default and should normally never have to be changed):

� control-cores specifies the number of cores used for the Junos kernel driven control management. The rest of the cores are used for mobility processing.

� data-pollers state how many kernel threads are used for polling packets.

� total-wired-memory in our case of 14336 is out of the 16G memory on the MS-DPC. We need 14G wired for expected performance.

� data-flow-affinity is how packets are distributed to different software threads to ensure packet flows are processed in the same fashion.

� package jservices-mobile is for running mobility daemons.

ALERT! Note that the following error will occur if the MS-DPCs were not configured correctly under [chassis fpc] hierarchy, causing the jmobile package to not run on any MS-DPC pics:

root@GGSN-960# run show unified-edge ggsn-pgw status error: Client not present

This happens more often than you think when you first configure the unit. If you run any show unified-edge ggsn-pgw command and get the error above, go check the MS-DPC configuration under [chassis] hierarchy first. Then run show chassis fpc x detail to make sure the MS-DPC is in good health.


Setting Up the Interfaces

The next step is to set up the interfaces in the Junos CLI. Since there are dozens of physical interfaces and potentially many logical interfaces, let’s start with the basics:

� One physical interface for the Gn/S5/S8 Interface

� One physical interface for the Gi/SGi Interface

� One MIF to map to an IFL that can be tied to an APN

� One loopback address on which GTP packets will be received for the Gn/S5/S8 interface

� Also set up a management interface

For the example in this book, all the interfaces of the GGSN/PGW sit on the same network. That network is 10.3.x.x/16, and it is shown in Figure 2.1.

SGSN InternetGn201.100.1.5/24

Gi10.3.2.58/24

MIF

Lo0.1201.100.1.6/32

Fxp010.3.219.31/16

Figure 2.1 Sample 3G Network for Chapter 2

Under the [edit interfaces] hierarchy let’s make Slot 0, pic 0, port 0 the GN interface, like this:

xe-0/0/0 { description "GI interface"; unit 0 { family inet { address 10.3.2.58/24; } } }

Slot 5, pic 0, port 0 will be the GI interface:

xe-5/0/0 { description "GN interface";


unit 0 { family inet { address 201.100.1.5/24; } } }

Setting up the management address is one of the most basic MX actions you will ever perform in your Junos life:

fxp0 { unit 0 { family inet { address 10.3.219.31/16; } } }

Our loopback address:

lo0 { unit 1 { family inet { address 201.100.1.6/32; } } }

And last the MIF interface, which we will tie to our first APN:

mif { unit 16000 { } }

Now we will finally set up the redundancy of the MS-DPCs.

There is no section under hierarchy such as EDIT> Service Card > Redundancy, nor is there a Mobile MS-DPC redundancy section. Instead, this configuration is set under the [interfaces] hierarchy using logical interfaces you set up for each of the service card’s PICs.

There is a Junos feature called Aggregated Multiservice interfaces, known as AMS. In this example, two AMS interfaces were created. Remember, the AMS interface is just another logical interface. You should group the PIC on one MS-DPC with the PIC of another. In this example, 2/0/0 is matched with 4/0/0, and 2/1/0 is set with 4/1/0. Note too, that the SPIC interface is called a MAMS under the AMS configu-ration. This stands for Mobile Aggregated Multiservice interface:

ams0 { load-balancing-options { member-interface mams-2/0/0;


member-interface mams-4/0/0; high-availability-options { many-to-one { preferred-backup mams-2/0/0; } } } } ams1 { load-balancing-options { member-interface mams-2/1/0; member-interface mams-4/1/0; high-availability-options { many-to-one { preferred-backup mams-4/1/0; } } } }

When this configuration is set up, you can lose a single mobile-enabled PIC or a whole MS-DPC card without any loss of service. All subscrib-er states stay on the box, meaning your subscribers continue to exist on the network. So if you set this configuration up…and then go take a MS-DPC down, you should see that all is well.

You can also set up redundancy on the MPCE line cards for the anchor PFEs. In the setup we are putting together for Mass Telecom, we will use the MPCE in FPC 0 as the primary. FPC 1 will be secondary in case there is a failure on either one:

apfe0 { anchoring-options { primary-list { fpc-0; } secondary fpc-1; warm-standby; }}

You can configure anchor pfe redundancy to be even be more granular than using the whole FPC. You could create apfe groups using a per-pfe set versus the whole FPC. An example is shown below where one pfe from the MPCE in FPC0 and one pfe from the MPCE in FPC5 have been chosen as primaries. The secondary has been chosen from the MPCE in FPC 2. This PFE will kick in when one of the primaries fail. Note, that there is no particular reason we chose these specific PFEs aside from showing you the flexibility the system allows you:

apfe0 { anchoring-options {


primary-list { pfe-0/0/0; pfe-5/1/0; } secondary pfe-1/0/0; warm-standby; }}

You can always run the following command to see how the mobility-enabled line cards, which are considered clients to the mobility re-source framework, are being used:

root@GGSN-960> show unified-edge ggsn-pgw resource-manager clientsClient State Redundancy role Client type Gatewaypfe-0/0/0 In-Service Primary Anchor-PFE Masstpfe-0/1/0 In-Service Primary Anchor-PFE Masstpfe-0/2/0 In-Service Primary Anchor-PFE Masstpfe-0/3/0 In-Service Primary Anchor-PFE Masstpfe-1/0/0 In-Service Secondary Anchor-PFE Masstpfe-1/1/0 In-Service Secondary Anchor-PFE Masstpfe-1/2/0 In-Service Secondary Anchor-PFE Masstpfe-1/3/0 In-Service Secondary Anchor-PFE Masstms-2/0/0 In-Service Primary Session-PIC Masstms-2/1/0 In-Service Primary Session-PIC Masstms-4/0/0 In-Service Secondary Session-PIC Masstms-4/1/0 In-Service Secondary Session-PIC Masst

You can also run this command to get similar information, but here you also get information on the aggregated groups and what PFEs and PICs have been assigned:

root@GGSN-960> show unified-edge ggsn-pgw system interfaces gateway MasstGateway: Masst Interfaces Members Operational Redundancy State Role ams0 mams-2/0/0 Active Primary mams-4/0/0 Active Secondary ams1 mams-2/1/0 Active Primary mams-4/1/0 Active Secondary apfe0 pfe-0/0/0 Active Primary pfe-1/0/0 Active Secondary pfe-0/1/0 Active Primary pfe-1/1/0 Active Secondary pfe-0/2/0 Active Primary pfe-1/2/0 Active Secondary pfe-0/3/0 Active Primary pfe-1/3/0 Active Secondary


Creating a Routing Instance

It’s now time to create a routing instance for the GI interface. Note that using routing instances is recommended to provide traffic separation and isolation for protection. Simply set the Gi/SGi interface and the Mobile IP interface under a GI_VR routing-instance:

[edit routing-instances GI_VR] interface xe-0/0/0.0; interface mif.16000;

Do not forget to add the instance-type, which is a virtual-router for this setup:

[edit routing-instances GI_VR]instance-type virtual-router;

Let’s see what the routing table looks like for the Gi routing instance:

[edit]root@GGSN-960# run show route table GI_VR.inet.0 GI_VR.inet.0: 4 destinations, 5 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.3.0.0/16 *[Direct/0] 03:52:32 > via xe-0/0/0.010.3.2.58/32 *[Local/0] 03:52:41 Local via xe-0/0/0.011.11.11.11/32 *[Direct/0] 03:55:32 > via mif.16000 [Local/0] 03:55:32 Local via mif.1600015.1.192.0/22 *[Anchor/7] 01:13:01 Private indexed

Now let’s compare it to the main routing table:

[edit]root@GGSN-960# run show route table inet.0 inet.0: 6 destinations, 6 routes (5 active, 0 holddown, 1 hidden)+ = Active Route, - = Last Active, * = Both0.0.0.0/0 *[Static/16] 01:13:37 > to 10.3.0.1 via fxp0.010.3.0.0/16 *[Direct/0] 01:13:37 > via fxp0.010.3.219.31/32 *[Local/0] 03:56:09 Local via fxp0.0

And here is what our whole routing instance looks like:

routing-instances { GI_VR { instance-type virtual-router; access {


address-assignment { mobile-pools { MassT_Pool { family inet { network { 15.0.0.0/14 { range { Range_Name { low 15.0.0.1; high 15.3.255.254; external-assigned; } } } } } default-pool; } } } } interface xe-0/0/0.0; interface mif.16000; }

This routing instance shows something called a mobile-pool. This is the VR that will anchor the IP addresses the GGSN/PGW assign to the clients. The next chapter covers the settings and that will tie all of this together, but now while we’re at this routing instance, let’s put our GN interface into its own virtual router, too:

GN_VR { instance-type virtual-router; interface xe-5/0/0.0; interface lo0.1;

Summary

Okay! The MX is configured in the most basic way but it is useless right now, so don’t get alarmed if you’re following along in your lab or test bed. You have a few routing instances and some interfaces ready, and, well, not much else, but you are ready to be set up as a GGSN or PGW!

Remember, now’s the time to go back over Chapter 2, or Chapter 1, if anything is amiss, or if you don’t quite understand something, because in Chapter 3 you’ll get into the real mobile configuration.

Chapter 3

GGSN Mobility Configuration

IP Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

The Gateway Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Access Point Name (APN) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

The Charging Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

The RADIUS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

QOS / COS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


Chapter 3 is really just a continuation of Chapter 2, but it makes better sense as its own entity since it’s a bit more complex and mobile-focused than Chapter 2. Chapter 3 also goes a step further than Chapter 2 and breaks up the mobility configuration sequence into distinct sections, allowing you to refer to and find those sections at a later time as a reference points:

� IP Address Assignment

� The Gateway

� APNs

� Charging

� Radius

� QoS

� Logs!

One last item before we get started. Remember Mass Telecom? They currently have 1.1 million subscribers whose average 3G download speed is 1.3 Mbps, and they are the carrier who will be with us for the rest of this book.

IP Address Assignment

One of the main features in any basic GGSN, or PGW, is that it can assign an IP address to mobile units. For instance, here’s a reliable quote from Wikipedia: “The GGSN is responsible for IP address assignment and is the default router for the connected user equipment (UE).”

So, let’s begin by setting up an IP Pool range on the MBG for Mass Telecom. Let’s also make it an externally assigned IP range since Mass Telecom will have their RADIUS server assign the IP Addresses. So, let’s begin by setting up an IP Pool range on the MBG for Mass Tele-com. We had just set up that routing instance called GI_VR in the last chapter and there was a pool added to it.

NOTE A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. There can be multiple routing tables for a single routing instance – for example, unicast IPv4, unicast IPv6, and Multicast IPv4 routing tables can exist in a single routing instance. Routing protocol parameters and options control the information in the routing tables.

Here is what the configuration should look like for the IP Pool called MassT_Pool, with some notes about it directly after:

Chapter3:GGSNMobilityConfiguration 33

[edit routing-instances GI_VR access address-assignment]root@GGSN-960# show MassT_Pool { family inet { network { 15.0.0.0/14 { range { Range_Name { low 15.0.0.1; high 15.3.255.254; external-assigned; } } } } } }}

You should note that the external-assigned option has been set. The external-assigned option just means the MBG is not assigning the IP Addresses locally, but instead an outside resource such as a RADIUS server or DHCP will assign them, or they can even be assigned statically by the UE.

Note, too, the range that the IP Pool will cover: from 15.0.0.1 to 15.3.255.254. You must define the range. If you receive an IP address from the external source outside of this range, the Create PDP Context/Create Session request message will be rejected by the MBG.

We should mention the default-pool option here. The default-pool option labels the pool usage as one of the MBG’s default pools, which is used when the APN configuration on the MBG does not explicitly call out a specific pool. We will create a default pool called MassT_Pool_2 as seen below:

[edit routing-instances GI_VR access address-assignment mobile-pools Masst_Pool_2] root@GGSN-960# show family inet { network { 18.0.0.0/24 { range { ranger { low 18.0.0.1; high 18.0.0.254; } } } }}default-pool

It should be noted that when setting up an APN you cannot have a default pool directly tied to it. For example under [edit unified-edge gateways ggsn-pgw MASST apn-services apns masst.com address-as-


signment inet-pool] do not set a pool that contains the default-pool flag or you will receive this error:

[edit unified-edge gateways ggsn-pgw MASST apn-services apns masst.com address-assignment] 'inet-pool' For APN masst.com, referenced pool Masst_Pool_2 in routing-instance GI_VR, cannot be a default-poolerror: configuration check-out failed

You can gather Mobile-IP-Pools in groups to evenly load-balance IP assignment. If you set up a Mobile-IP-Pool group, add two or more Mobile-IP-Pools to that group and then tie that group to an APN. Doing so round-robins the IP Assignment evenly between the pools when the address assignment is handled locally on the MBG, or you can have a mobile pool group with only one mobile pool. It’s a neat way to provide the ability to switch address pools around, without taking the whole APN servicing the pool to maintenance mode. More on maintenance mode in a later section.

NOTE You can use an AAA server such as the Juniper Steel Belted Radius Carrier AAA solution to assign IP addresses. Steel Belted Radius Carrier AAA can weigh the pools using different modules of distribu-tion. You may even be able to use the JavaScript module on the Steel Belted RadiusCarrier AAA server to perform even more flexible IP Pool assignment models. Check the latest Steel Belted Radius Carrier AAA documents for further details.

So for Mass Telecom let’s add a third small pool called MassT_Pool_3, which will be an internally assigned pool, meaning that the MBG will be the one assigning the IP Addresses. This should allow you to see if load balancing works.

Let’s also add the Mobile-IP-Pool group called Mobile_Pool_Group_1 in which the two IP pools MassT_Pool and MassT_Pool_3 are placed. Let’s take a peek:

[edit routing-instances GI_VR access address-assignment]root@GGSN-960# show mobile-pools { MassT_Pool { family inet { network { 15.0.0.0/14 { range { Range_Name { low 15.0.0.1; high 15.3.255.254; external-assigned; } }


} } } } MassT_Pool_3 { family inet { network { 10.3.219.200/30 { range { Range_Name { low 10.3.219.200; high 10.3.219.203; } } } } } }}mobile-pool-groups { Mobile_Pool_Group_1 { MassT_Pool_3; MassT_Pool; }}

The newly added Mobile-IP-Pool Group can now be added to an APN. Do not worry about the actual APN configuration yet, that happens in a few more pages. But to take a peek ahead, here is where you would add the Mobile-IP-Pool Group:

[edit unified-edge gateways ggsn-pgw GGSN1 apn-services apns NScotia address-assignment]root@GGSN-960# show inet-pool { group Mobile_Pool_Group_1;}

Pretend for one moment that the Gateway and APN are also config-ured and Mass Telecom wants to test this and they have six mobile devices coming online. Use the show unified-edge ggsn-pgw sub-scribers command and you can see that this worked. The six sub-scribers were evenly load balanced between the two pools – also, check out the IP addresses:

root@GGSN-960# run show unified-edge ggsn-pgw subscribers IMSI MSISDN Subscriber Peer APN Address Address 302200112233497 26737774 10.3.219.201 10.3.219.32 NScotia 302200112233529 26737776 10.3.219.202 10.3.219.32 NScotia 302200112233465 26737772 10.3.219.200 10.3.219.32 NScotia 302200112233513 26737775 15.4.9.3 10.3.219.32 NScotia 302200112233449 26737771 15.4.9.1 10.3.219.32 NScotia 302200112233481 26737773 15.4.9.2 10.3.219.32 NScotia


To monitor the state of your pools use the show unified-edge ggsn-pgw address-assignment pool command. This snippet shows how useful it is to see how many IP addresses are used in a given pool and if you have allocated enough to meet your use.

Pool: MassT-Pool-3 Total addresses: 500 Addresses in use: 250 Addresses skipped: 0 Address usage (percent): 50 Addresses in aging period: 0 Routing instance: GI_VRPool: MassT_Pool_2 Total addresses: 254 Addresses in use: 0 Addresses skipped: 0 Address usage (percent): 0 Addresses in aging period: 0 Routing instance: GI_VRPool: MassT_Pool Total addresses: 16777214 Addresses in use: 620 Addresses skipped: 336 Address usage (percent): 0. Addresses in aging period: 0 Routing instance: GI_VR

The Gateway Configuration

Next up is the Gateway configuration, which is the very heart of our mobile setup.

Let’s create a gateway called Masst under which we will configure APNs, GTP settings, and other fun mobile stuff.

[edit unified-edge gateways ggsn-pgw Masst]

Let’s set the maximum-bearers to be 2000000. Remember Masst has just over 1 million subscribers and they hope to grow their business.

[edit unified-edge gateways ggsn-pgw Masst] root@GGSN-960# set maximum-bearers 2000000

NOTE It’s generally recommended that you configure a larger number for the GW-level maximum-bearers than you believe is needed. You can then configure lower values at the APN-level for maximum-bearers, an example of which is covered in just a moment. This process allows you to add new APNs in the future without requiring a configuration change at the GW level.


Next, let’s set up the GTP section using the Gn interface for our example, which tells the MBG what loopback interface will anchor all incoming PDP Create Context requests. While some may say, “all roads lead to Rome,” all MPC interfaces that handle GTP requests head to this interface. Note that there are some additional retry/timeout settings to be left alone for now. Unless there are latent network issues between the MBG and its GTP peers, the default settings are typically just fine.

[edit unified-edge gateways ggsn-pgw Masst]gtp { gn { interface lo0.1 v4-address 201.100.1.6; n3-requests 5; t3-response 5; path-management enable; echo-n3-requests 3; echo-t3-response 5; }

Junos permits the following flexible options when configuring the loopback interface under the GTP configuration:

� Single IP address for ALL GTP traffic

� Different IP address for GTP traffic received on different 3GPP interfaces (Gn, S5, S8, and even the Gp interface)

� Different IP addresses for control/GTP-C and data/GTP-U traffic on a single interface (say S5 or Gn)

Remember in our example that MassT chose to configure the loopback on just the 3G GN interface for Control and Data.

Finally, let’s review how to label a subscriber as a home subscriber. By default, every single subscriber that hits the Juniper MBG is seen as being a visitor. As you will see in a few pages, visitors can be blocked from using certain APNs.

To label a subscriber as a home subscriber, configure the home public land mobile network (plmn) section under the gateway. Here is the MCC and MNC that Mass Telecom considers a home subscriber:

[edit unified-edge gateways ggsn-pgw Masst home-plmn]root@GGSN-960# show mcc 310 mnc 909;

The MCC (Mobile Country Code) is 310, which is one of the Mobile Country codes for the United States. The MNC (Mobile Network Code) is 909, which is the hypothetical unique Mobile Network Code for our example carrier Mass Telecom.


So an IMSI of 310909123456789 will be considered a home subscrib-er to the MBG’s network. An IMSI of 310150123456789 will be considered a visitor.

Access Point Name (APN) Configuration

Now it’s time to set up an APN for Mass Telecom. This will be easy. In our example, let’s expect these UEs to all have an APN name hardcod-ed with the string masst.com. Since the APN will be masst.com, let’s call it masst.com:

[edit unified-edge gateways ggsn-pgw Masst]apn-services { apns masst.com {

Next since we limited the MBG to 2000000 subscribers/PDP contexts based on the configuration added under the gateway, this APN, which is Mass Telecom’s main home APN, should be able to use most of those bearers. So maximum-bearers for this APN will be 1500000:

maximum-bearers 1500000;

Mass Telecom does not want any IMSIs, or visitors, that do not belong to this Mobile Network to have access to this APN. No one is going to reconfigure their BlackBerry, set the APN-Name to masst.com, and get on this APN with their non-Mass Telecom sim card! We will set block-visitors:

block-visitors;

Next configure a type for the APN. Wait…a what? What is a type? Okay, good point. Currently you have a few options for types:

� Real This type of APN is where a real service is provided. It can be accessed either by the APN received directly from the UE in the GTPc PDP Context Request or by a redirection from a virtual APN as seen below.

¨ This means the APN name sent from the UE is used, so in this case masst.com.

� Virtual This APN type is used when the GTP Create PDP Context message contains an APN name, but the name must be mapped to an APN the MBG has configured as a real APN. The mapping is done by configuring the service selection profile section (something you’ll do a little later in this book).

¨ This APN type can also map to a real APN through a RADIUS server. The RADIUS server may be configured to return the attribute JNPR-APN-Name in a RADIUS Access Accept packet.


Let’s make life simple for Mass Telecom and choose real as our option. It works for our example because that is the only APN Mass Telecom wants to use and their RADIUS server is not passing back the RADIUS Attribute JNPR-APN-Name.

apn-type real;

Since this is a small regional carrier dealing only in IPV4, the apn-data-type is obvious. (One day they may move to IPV6… one day.)

apn-data-type ipv4;

To tie this APN into an IFL, chose a mobile interface, and since there is only one so far, the choice is easy to make:

mobile-interface mif.16000;

And it’s already been decided to use RADIUS to assign the IP address-es to our UEs:

address-assignment { aaa; }

And here is the AAA profile for use for this APN. Details for this Radius profile setup come later:

aaa-profile MASST_AAA_Profile;

Under the APN section, you can configure the MBG to use an anonymous username, which it will send to the RADIUS server if you are configuring RADIUS for this APN and the UE does not send a username in the Create PDP Context Request Message. If you do not set the anonymous user, and the UE and SGSN do not send over a username, the subscriber/PDP Context activation will fail unless your RADIUS Server is configured to not look at the User-Name and User-Password RADIUS attributes (expect very few RADIUS servers to be configured this way):

anonymous-user { user-name whoami; password "$9$uj9pOEcrevL7-le"; ## SECRET-DATA }

Now let’s review what selection mode to use. The selection mode indicates the origin of the APN and whether or not the Home Location Register (HLR) has verified the user subscription. The selection mode type is represented by the values: 0, 1, 2, or 3, as shown in Table 3.1.


Table 3.1 Selection Mode Values

Selection Mode Value Value (Decimal)

MS or network provided AP, subscription verified 0

MS provided APN, subscription not verified 1

Network provided APN, subscription not verified 2

For future use. Shall not be sent. If received, shall be interpreted as the value “2”

3

Simply put, this field in the Create PDP Context/Create Session request will tell you if the SGSN/MME or the Mobile Equipment assigned the APN string and if the subscriber was verified or not verified. By the way, verified means that the SGSN successfully communicated with the HLR/HSS and that the HLR/HSS verified the subscriber.

Take a look at this Create PDP Context Request message and you can see the Selection Mode is 0.

Figure 3.1 Create PDP Context Request

Mass Telecom likes this feature. They do not want to use no-sub-scribed because they have no desire to reject verified subscribers. What’s more, their SGSNs do not assign the APN. Their handhelds assign the APNs, but there are instances where the HLR may not verify these subscribers, so Mass Telecom still wants to let them in. Here are the options:

root@GGSN-960# set selection-mode ?Possible completions: <[Enter]> Execute this command from-ms Admit MS provided APN, subscription not verified from-sgsn Admit Network provided APN, subscription not verified


no-subscribed Reject subscribed verified Users

And here is what Mass Telecom wants configured:

selection-mode { from-ms; }

Under [edit unified-edge] here is what the whole configuration would look like so far, based on our example Masst plus some Tra-ceoptions that we will talk about in a later section:

gateways { ggsn-pgw MassT { maximum-bearers 2000000; preemption { enable; } gtp { gn { interface lo0.1 v4-address 201.100.1.6; n3-requests 5; t3-response 5; path-management enable; echo-n3-requests 3; echo-t3-response 5; } traceoptions { file gtp.log size 50m; level all; flag all; } } traceoptions { file gateway.log size 50m; level all; flag all; } apn-services { apns masst.com { maximum-bearers 1500000; block-visitors; apn-type real; apn-data-type ipv4; mobile-interface mif.16000; address-assignment { aaa; } aaa-profile MASST_AAA_Profile; anonymous-user { user-name whoami; password "$9$uj9pOEcrevL7-le"; ## SECRET-DATA } selection-mode {


from-ms; } } } system { anchor-pfes { interface pfe-5/1/0; interface pfe-0/0/0; } anchor-spics { interface ams0; interface ams1; } } software-datapath { traceoptions { file softdatapath.log size 50m; flag all; } } } }

ServiceSelectionProfile

This next exercise shows you the Junos feature service selection profile. The use case is not the greatest, but it is simple and should show you how to use the feature.

Let’s assume Mass Telecom has just signed a roaming agreement with a Nova Scotia-based service provider called Nova Scotia Telecom, or Ns-cotia, for short. When subscribers from this telecom head on down to the Massachusetts area, they can come onboard, meaning they can still get data service from Mass Telecom’s RAN/Packetcore. NScotia’s UEs have either the APN of internet123 or Canada. Mass Telecom wants to use just one APN to manage these subscribers, so this use case is going to create a service-selection-profile that will grab any IMSI starting with country code 302 (Canada) and network code 200 (Nscotia Telecom) visiting from Nova Scotia Telecom, and then apply the apn-name NScotia to the subscriber session.

To do this requires setting up a service selection profile on the MBG like this:

[edit unified-edge gateways ggsn-pgw Masst service-selection-profiles]root@GGSN-960# show profile NScotia_profile { term Term1 { from { imsi 302200; }


then { apn-name NScotia; } }}

Next you have to have an entry for the APN name internet123 and Canada that Nscotias UEs send, so let’s add an APN type of virtual and let’s call the service-selection-profile. Virtual APNs still need to use a unique MIF:

apns internet123 { apn-type virtual; mobile-interface mif.15998; service-selection-profile NScotia_profile;} apns Canada { apn-type virtual; mobile-interface mif.14999; service-selection-profile NScotia_profile;}

Now let’s set up the apn NScotia and remember to go back and attach the mobile-interface to the GI_VR routing instance. Mass Telecom expects a low number of roamers from Nscotia, so let’s set the maxi-mum-bearers to 250000. Also, let’s use a new local pool we’ve created called visitor – Mass Telecom wants all visiting subscribers to use this IP range:

apns NScotia { maximum-bearers 250000 apn-type real; mobile-interface mif.15999; address-assignment { inet-pool { pool visitor; } }}

And, for your reference, here is what the visitor pool looks like:

[edit routing-instances GI_VR access address-assignment mobile-pools visitor]root@GGSN-960# show family inet { network { 15.4.0.0/16 { range { rangerName { low 15.4.0.1; high 15.4.255.254; } } } }}


The Charging Configuration

The current roaming agreement that Mass Telecom has with its counterpart up in Nova Scotia is that Mass Telecom will bill NScotia based on the number of subscribers that hit its network in any given month. Hence, Mass Telecom has a Charging Gateway they need the MBG to use for the NScotia APN.

Setting up the Charging Client on the MBG is simple as pie. Take a look:

[edit unified-edge gateways ggsn-pgw Msst charging]root@GGSN-960# show cdr-profiles { CDR_profile_ONe { enable-reduced-partial-cdrs; exclude-ie-options { apn-ni; apn-selection-mode; cc-selection-mode; pgw-plmn-identifier; list-of-service-data; lrsn; network-initiation; node-id; pdn-connection-id; pdppdn-type; rat-type; record-sequence-number; served-pdppdn-address; serving-node-plmn-identifier; } }}trigger-profiles { TriggerProfile_One { exclude { qos-change; rat-change; } offline { volume-limit { 10485760; direction both; } time-limit 600; } }}transport-profiles { TransportProfileOne {


offline { charging-gateways { cdr-release r8; peer-order { peer ChargingOne; } } } }}charging-profiles { ChargingProfile_One { profile-id 101; transport-profile TransportProfileOne; cdr-profile CDR_profile_ONe; trigger-profile TriggerProfile_One; }}gtpp { n3-requests 5; echo-interval 60; t3-response 5; reconnect-time 60; peer ChargingOne { destination-ipv4-address 10.3.219.32; source-interface { xe-5/0/1.0; } destination-port 3386; transport-protocol udp; version v0; }}

Okay, so maybe it’s not so easy. In fact it is quite convoluted, but let’s break it down.

The GTPP section is where you set the GTP prime basics: the reconnect times, the timeout intervals, the port, protocol, and which GTP version to use. Mass Telecom happens to use UDP with GTP version 0 for their GTP Prime connection.

You also set up the CGW (Charging Gateway) under this section.

MOBILE TIP GTP prime uses the same message structure as GTP-C and GTP-U. It is used for carrying charging data from the Charging Data Function (CDF), which is the GGSN/PGW to the Charging Gateway Function (CGF).

And here Mass Telecom has configured a single CGW at 10.3.219.32. The MBG uses the source-interface xe-5/0/1 on the default VR to reach this CGW. Port, transport, and GTP version have also been set here:


gtpp { n3-requests 5; echo-interval 60; t3-response 5; reconnect-time 60; peer ChargingOne { destination-ipv4-address 10.3.219.32; source-interface { xe-5/0/1.0; } destination-port 3386; transport-protocol udp; version v0; }}

Next, set up the Transport Profile. There is not much to this section since currently as of Junos 11.4w2, the MBG only supports offline charging, but it’s here that you set up the cdr-release that the CGW supports and set up the CGW peers that you want to connect to. As stated previously, Mass Telecom has only one CGW. If they add a second one, remember the top configured peer in the order is selected first as the active CGW. When the active CGW goes down, the next peer is selected. If all the charging gateways are down and you have configured local persistent storage, then the CDRs are stored on the Routing Engine if an SSD card is installed.

transport-profiles { TransportProfileOne { offline { charging-gateways { cdr-release r8; peer-order { peer ChargingOne; } } } }}

MOBILE TIP Offline charging is based on CDR file processing and is a Post Paid scenario where subscribers are typically billed at a later time. Online charging is real-time and can tie into service application control. For example, subscribers can find their data thruput downgraded if they use too much in a period of time

The trigger-profiles section is where you determine when a CDR is created for a subscriber session. Mass Telecom has decided to exclude the events qos-change and rat-change from kicking off a CDR. The other trackable events – Location area update for the mobile subscrib-er, IP Address update being deferred, mobile equipment’s time zone changes, and the Public Land Mobile Network changes for the mobile


subscriber – will all create CDR. You can always add these to the exclude section if Mass Telecom feels they do not want to track them. Also Mass Telecom has decided when the user has received or sent 10 Megs of data, a CDR will be created. On top of that, if a CDR has not been created for 10 minutes a CDR will be created. So lots of events can create a CDR record.

trigger-profiles { TriggerProfile_One { exclude { qos-change; rat-change; } offline { volume-limit { 10485760; direction both; } time-limit 600; } }}

Next up is the CDR profile. You can do a few things under this section because Mass Telecom chose to set enable-reduced-partial-cdrs (RPCs). The RPCs should only contain mandatory fields and informa-tion regarding changes in the session parameters relative to the previ-ous CDR. For example, if the user equipment location has not changed, then this information is excluded from the RPC because this information has not changed from the previous CDR. This helps make the CDR records smaller, which Mass Telecom obviously likes, since it makes dealing with their billing records easier.

Mass Telecom has also decided to exclude numerous options that are not needed for their charging model from being placed into the CDR and these exclusions are also configured under the CDR profile, as seen here:

cdr-profiles { CDR_profile_ONe { enable-reduced-partial-cdrs; exclude-ie-options { apn-ni; apn-selection-mode; cc-selection-mode; pgw-plmn-identifier; list-of-service-data; lrsn; network-initiation; node-id; pdn-connection-id; pdppdn-type;


rat-type; record-sequence-number; served-pdppdn-address; serving-node-plmn-identifier; } }}

Here’s a full list of options that you can exclude:

apn-ni Exclude APN network identifier IE in the CDRapn-selection-mode Exclude APN selection mode IE in the CDRcc-selection-mode Exclude charging characteristic selection mode IE in the CDRdynamic-address Exclude dynamic address IE in the CDRlist-of-service-data Exclude list of service data in the CDRlist-of-traffic-volumes Exclude list of traffic volumes in the CDRlrsn Exclude local record sequece number IE in the CDRms-time-zone Exclude MS time zone IE in the CDRnetwork-initiation Exclude network initiation flag in the CDRnode-id Exclude node ID IE in the CDRpdn-connection-id Exclude PDN connection ID IE in the CDRpdppdn-type Exclude PDP or PDN type IE in the CDRpgw-plmn-identifier Exclude PGW PLMN identifier IE in the CDRrat-type Exclude RAT type IE in the CDRrecord-sequence-number Exclude record sequence number IE in the CDRserved-imeisv Exclude served IMEI IE in the CDRserved-msisdn Exclude served MSISDN IE in the CDRserved-pdppdn-address Exclude served PDP context or IP CAN bearer address IE in the CDRserving-node-plmn-identifier Exclude serving node PLMN identifier IE in the CDRstart-time Exclude start time IE in the CDRstop-time Exclude stop time IE in the CDRuser-location-information Exclude user location IE in the CDR

Now let’s tie all these configurations together under a Charging Profile. Let’s also add a profile-id for this charging profile that we’ll call Charg-ingProfile_One (note the GTPP settings are global to the gateway, so while they are tied to Charging, GTPP settings do not go under the Charging Profile):

charging-profiles { ChargingProfile_One { profile-id 101; transport-profile TransportProfileOne; cdr-profile CDR_profile_ONe; trigger-profile TriggerProfile_One; }}

The charging profile called ChargingProfile_One is ready at this point, so let’s add it to the NScotia APN, using the default profile that covers Home, Visiting, and Roaming subscribers.

[edit unified-edge gateways ggsn-pgw Masst apn-services apns NScotia charging]root@GGSN-960# show default-profile ChargingProfile_One;


You could add additional profiles to meet these additional scenarios if you need to be granular:

home-profile Default home profile for the apn roamer-profile Default roamer profile for the apn visitor-profile Default visitor profile for the apn

You could even offer Mass Telecom the ability to assign the Charging Profile from RADIUS or from the SGSN/SGW. But Mass Telecom has chosen to just assign the profile locally, so they do not need to set a selection order:

[edit unified-edge gateways ggsn-pgw Masst apn-services apns NScotia charging]root@GGSN-960# set profile-selection-order ?Possible completions: [ Open a set of values radius Select charging profile sent by radius static Select charging profile locally configured serving Select charging profile sent by SGSN or SGW

Once you have your Charging settings configured you can run a few commands to make sure everything is working:

root@GGSN-960# run show unified-edge ggsn-pgw charging path status Charging Path StatusPeer-Address Peer-Name Local-Address Status Echo10.3.219.32 ChargingOne 10.3.219.72 Connected Enabled

root@GGSN-960# run show unified-edge ggsn-pgw charging path statistics Charging Path Statistics

CGF Address : 10.3.219.32 CGF Server Name : ChargingOne Echo Requests Rx: 0 Echo Responses Tx: 0 Echo Responses Rx: 0 Echo Requests Tx: 4146 Node-Alive Requests Rx: 0 Node-Alive Responses Tx: 0 Version Not Supported Rx: 0 Version Not Supported Tx: 0 Echo Requests timed out : 0 Echo Interval : 60 Down Detection Interval : 10 Reconnect Time Interval : 60 Destination Port : 3386 Pending Queue Size : 0 Path Manager FPC Slot : 2 Path Manager PIC Slot : 0 T3 Response Time Interval : 5 Path Manager Port : 30241 Source Interface Valid : Yes GTPP Header Type : long N3 Requests : 5 Local Address : 10.3.219.72 GTPP Version : V0 Transport Protocol : UDP

Before leaving the charging section and moving on, it should be men-tioned that you can also store CDRs locally on the SSD card in the RE. The CDR files are available for transfer from the /opt/mobility/charging/ggsn/final_log directory. This option may be considered a must for setups that will not use the GA interface to a Charging Gate-way. With this option, you can retrieve the files off the box with a protocol such as FTP or SCP and then clean the files off the box.


Edit in the transport-profiles section. Remember this is under:

unified-edge > gateways > ggsn-pgw > Masst > charging

…and add a new offline> charging gateway field called persistent-storage-order. Its value will be local-storage. Here’s an example:

transport-profiles { TransportProfileOne { offline { charging-gateways { cdr-release r8; peer-order { peer ChargingOne; } persistent-storage-order { local-storage; } } } }}

Next under unified-edge > gateways > ggsn-pgw > Masst > charging let’s add the options for the local CDR storage. Mass Telecom has the following options set:

local-persistent-storage-options { file-age 60; file-size 512; cdrs-per-file 25000; file-format 3gpp; disk-space-policy { water-mark-level1 { percentage 70; notification-level both; } water-mark-level2 { percentage 85; notification-level snmp-alarm; } }}

You can monitor the status of the local storage with this helpful com-mand:

root@GGSN-960# run show unified-edge ggsn-pgw charging local-persistent-storage statistics Gateway: Masst Charging local-persistent-storage Statistics Batch Messages received : 131 Batch Responses sent : 131 Invalid Messages received : 0 Number of temp log files opened : 10 Number of journal files opened : 10 Number of journal files closed : 9


Number of CDR log files closed : 10 Number of CDR files closed due to file-age : 8 Number of CDR files closed due to file-size : 0 Number of CDR files closed due to cdr-count : 0 Abnormal file closures : 2 Normal file closures : 8 Number of CDR log files closed in TS_32_297 format : 0 Number of CDR log files closed in raw asn1 format : 10 Total number of CDRs backed up : 131 Disk Full messages sent : 0 Disk Full resolve messages sent : 0 Number of async IO reqs written : 131 Disk space status : DISK_AVAILABLE Watermark level1 at(MB) : 2276(70%) Watermark level2 at(MB) : 2601(85%) Watermark level3 at(MB) : 2926(90%) Temporary CDR log file StatisticsFile Name: /opt/mobility/charging/ggsn/temp_log/templog_file_2.log Journal file name : /opt/mobility/charging/ggsn/jrnl/jrnl_2.log Current number of CDRs : 11 Current file size(bytes) : 3084 File age trigger(mins) : 60 File size trigger(bytes) : 10485760 CDR count trigger : 0 Global Statistics Disk Offline messages sent : 0 Disk Available messages sent : 0 Number of CDR storage files on disk : 1814 Current storage space in use(MB) : 305 Available storage space on disk(MB) : 2947 Total storage space on disk(MB) : 3252

Note that Mass Telecom did apply watermarks so they are notified if disk space is filling in case their file retrieval is not happening, or the cleanup is not occurring at close enough intervals based on the number of CDRs that get created during peak hours.

This concludes all the processes of the Charging Configuration.

The RADIUS Configuration

At last you finally get to set up RADIUS on the MBG! Though RA-DIUS is optional on the MBG, Mass Telecom wants to use their AAA server, so let’s walk through this setup.

The process requires you to first set up a RADIUS server under the [Ac-cess] hierarchy, which is at the top of the Junos configuration, and to then add it to a network-element group. The network-element group for Mass Telecom uses the same source-interface on the MX as the Charging Gateway.


So far, Mass Telecom has only one RADIUS Server; this is not very practical in the real world but is simple for our testing since you only need one RADIUS server running in your lab. Here’s the configuration:

Access { radius { servers { t1k-16g { address 10.3.219.95; port 1812; accounting-port 1813; secret "$9$.Pz3/CtOIE9C"; ## SECRET-DATA accounting-secret "$9$noT2/p01RhrKMIR"; ## SECRET-DATA allow-dynamic-requests; dynamic-request-secret "$9$B4CISrKM87dbvM"; ## SECRET-DATA source-interface xe-5/0/1; } } network-elements { Network_Element_1 { server t1k-16g priority 1; } } }}

Next, head over to [edit unified-edge aaa]. Here you are going to edit the mobile-profiles and add a profile called Masst_AAA_Profile. Then add the network-element for both authentication and accounting.

NOTE This is the first time you have configured anything under the unified-edge hierarchy that was not directly tied to a gateway configuration. So this configuration would be global to all Gateways configured on this box. Remember Mass Telecom is only setting up a single gateway in this book.

root@GGSN-960# show mobile-profiles { Masst_AAA_Profile { radius { authentication { network-element Network_Element_1; } accounting { network-element Network_Element_1; } } }}

Now let’s edit the masst.com APN by adding the Masst_AAA_Profile to aaa-profile so our Authentication and Accounting requests will get sent to the RADIUS server, and creating an anonymous user. More on the


anonymous user in a minute. First, take a look at the configuration added here to enable the masst.com APN to use RADIUS:

[unified-edge gateways ggsn-pgw masst apn-services apns masst.com]root@GGSN-960# show aaa-profile Masst_AAA_Profile;anonymous-user { user-name whoami; password "$9$uj9pOEcrevL7-le"; ## SECRET-DATA}

Okay, so about that anonymous user. Why add that account here? This was discussed earlier when looking at the Virtual APN type, but now let’s go into a bit more detail. In a RADIUS request the user User-Name must be present.

Per RADIUS RFC 2865: This Attribute indicates the name of the user to be authenticated. It must be sent in Access-Request packets if available.

The RFC states the User-Name attribute must be present, only if available. Yes, most RADIUS servers choke on the lack of the User-Name attribute, so as of this writing the MBG code requires the anonymous-user. What happens if you fail to add it? Well, the GGSN will reject the PDP Context Create request with an “Encoding cause Authentication failure” message added to the GTP log and will not even try to send a Radius Request out. So please… save yourself another headache.

You might ask why can you only use the user-name in the GTP-C message sent in the PDP Context Create request. Look at a snoop sent from the SGSN over the Gn interface to the GGSN and you’ll see the MSIDSN and the IMSI, but no username to identify the client. This is not PPP, or 802.1x, or any other subscriber technology where each subscriber must be identified by a user. This is a mobile solution where the IMSI is the identity for the GGSN. In some carriers’ networks the UE and SGSN may send a username, but remember it is not required.

In the Create PDP Context request you may see a Protocol Configura-tion Option with a PAP or CHAP section. For example look at this snoop in Figure 3.2.


Figure 3.2 Protocol Configuration Options

Okay, Mass Telecom’s SGSN and UEs are using the anonymous user since the SGSN does not send any value. But what can the MBG send to RADIUS, just this hardcoded anonymous string? Does this mean from a GGSN/PGW to RADIUS server point of view, there is only one user per APN, this hardcoded anonymous user? It’s not very flexible, and there’s no ability to utilize different attributes from RADIUS to provision individual subscribers’ sessions. Right?

Wait, stop complaining. The MBG does have options to get around the lack of a RADIUS User-Name being present. You replace the anony-mous username sent in the RADIUS request with any one of these variables:

use-apnname Use APN name for user authenticationuse-imsi Use imsi for user authenticationuse-msisdn Use msisdn for user authentication

RADIUSFeatures

Mass Telecom sells some cool mobile devices. These expensive Mass Telecom devices have a nice high monthly fee and have a hardcoded APN masst.bb that needs to be added to the MBG. This APN will be


similar to the masst.com APN. But Mass Telecom needs to set up this APN to use the individual IMSI as the user-name sent to RADIUS in case they need to return specific RADIUS attributes for a given sub-scriber for unique services, such as setting Ingress and Egress policies. So:

[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.bb]root@GGSN-960# show anonymous-user { use-imsi; password "$9$FngmnApO1RSlKB1"; ## SECRET-DATA

Now Mass Telecom also wants to use their RADIUS server for han-dling accounting information for the APN masst.com and masst.bb. If you dig down, there is a trigger section under the aaa mobile-profiles hierarchy. Mass Telecom wants to send interim accounting updates every 15 minutes and they do not want updates sent when there is a QOS change or a RAT change. Other trackable events – location area update for the mobile subscriber, IP Address update being deferred, mobile equipment’s time zone changes, and the Public Land Mobile Network changes for the mobile subscriber – will all create a new interim accounting packet when that event occurs. Remember, Mass Telecom can always add these as excluded events in the future if they feel tracking them is an unnecessary creation of an accounting record:

[edit unified-edge aaa mobile-profiles Masst_AAA_Profile radius accounting trigger]root@GGSN-960# show no-rat-change;no-qos-change;interim-interval 15;

And here is a snippet of the accounting output from a Juniper Steel Belted RADIUS Carrier AAA server that receives RADIUS packets from the MBG. You can see the Accounting START packet shows the session being created and the Accounting Interims for this session (based on the Acct-Session-ID) come in 15 minutes later due to the accounting trigger above. You can see that the subscriber has been sending GTP-U Data, since the Acct-Input-Octets and Acct-Output-Octets increase.

Date Time

RAS-

Client

Record-

Type

Full-

Name

User-

Name

NAS-IP-

Address

Acct-

Status-

Type

Acct-

Delay-

Time

Acct-

Input-

Octets

Acct-

Output-

Octets Acct-Session-Id

7/20/2011 13:24:44 <ANY> Start WHOAMI whoami 10.3.219.72 1 0 0A03DBFA0C001001

7/20/2011 13:39:46 <ANY> Interim WHOAMI whoami 10.3.219.72 3 0 432674944 13815552 0A03DBFA0C001001


QOS / COS

The last item to configure is QoS. No, wait, this is Junos. It’s CoS, and mobile CoS to be exact.

Play along for a moment and assume the engineers at Mass Telecom are looking at a test subscriber session:

root@GGSN-960# run show unified-edge ggsn-pgw subscribers extensive Subscriber Information: IMSI: 123456789459595 IMEI: None MSISDN: 26737745 Time Zone: None (DST): None Status: Visitor User Location Info: MCC: None MNC: None LAC: 0x0 CI: 0x0 SAC: 0x0 RAC: 0x0 TAC: 0x0 ECI: 0x0 RAT Type: Unknown PDN Session: APN name: masst.com IPv4 Address: 15.4.16.1 IPv6 Address: None Direct Tunnel: Disabled Session Duration: 3:20:32 Local Control address: 10.3.219.250 Remote Control address: 10.3.219.32 TEID Control Local: 0xc001547 TEID Control Remote: 0x100 Addressing scheme: Local Selection mode: sub verified Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 10/0 (FPC/PIC) Session State: Established GTP Version: 1 Serving network: MCC: None MNC :None Bearer: NSAPI/EBI: 5 Charging ID: 0xc001547 Local Data address: 10.3.219.250 Remote Data address: 10.3.219.32 Local TEID: 0x3420b6 Remote TEID: 0xff Bearer State: Established Substate: - Idle Timeout: 0 min(0 -0,0) AAA Interim Interval: 0 min(0 -0,0) Negotiated QoS Parameters: Traffic Class:Interactive ARP: 1 Traffic Handling Priority:3 Transfer Delay :10 MBR Uplink: 128 kbps MBR Downlink :128 kbps GBR Uplink: 128 kbps GBR Downlink: :128 kbps Signaling Indicator :0 Forwarding Class: - Loss Priority: - Requested QoS Parameters: Traffic Class: Interactive ARP: 1 Traffic Handling Priority: 3 Transfer Delay: 10 MBR Uplink : 128 kbps MBR Downlink: 128 kbps GBR Uplink : 128 kbps GBR Downlink: 128 kbps Signaling Indicator: 0 Charging information: Profile ID: 0 State: Init Previous State: Init Profile selection criteria: - Offline charging information: Current service data container sequence number: 0 Current partial record sequence number : 0 Number of CDRs closed : 0


Rating group information: Rating group: 0 Service id: 0 Action ID: 0x0 Trigger profile: 0 Change condition bitmask: 0x0 Action-id-bitmask: 0x0 Signal bitmask: 0x0 Last signal bitmask: 0x0 Last statistics collection time : None collected

Note the bolded output, which is just what the Mass Telecom engi-neers are seeing, too. Is that 128 kbps for their MBR (Maximum Bit Rate)? Is that what QoS is set to? Well actually, on the MBG nothing has been set yet. Let’s look at a snoop in Figure 3.3 to see what is requested in the Create PDP Context request, received from the SGSN, since our example is a 3G test.

Figure 3.3 What is Requested in the Create PDP Context Request?

Okay, as you can see from the SGSN, they are requesting a MBR of 128k. The MBR value should be 5 Mbs from what Mass Telecom requires for this test subscriber who likes HD YouTube videos, which require a pipe larger than 128k. They call in the SGSN/HLR team and have them change what is requested for the QoS settings.

After the change, let’s test a subscriber again and see how it went:

root@GGSN-960# run show unified-edge ggsn-pgw subscribers extensive Subscriber Information: IMSI: 123456789460360 IMEI: 1122334455667791 MSISDN: 26737748 Time Zone: None (DST): None Status: Visitor User Location Info: MCC: None MNC: None LAC: 0x0 CI: 0x0 SAC: 0x0 RAC: 0x0 TAC: 0x0 ECI: 0x0 RAT Type: Unknown PDN Session: APN name: masst.com IPv4 Address: 15.4.56.1 IPv6 Address: None


Direct Tunnel: Disabled Session Duration: 4 Local Control address: 10.3.219.250 Remote Control address: 10.3.219.32 TEID Control Local: 0x14002d2e TEID Control Remote: 0x106 Addressing scheme: Local Selection mode: sub verified Session PIC: 2 /1 (FPC/PIC) Anchor PFE: 10/0 (FPC/PIC) Session State: Established GTP Version: 1 Serving network: MCC: None MNC :None Bearer: NSAPI/EBI: 5 Charging ID: 0x14002d2e Local Data address: 10.3.219.250 Remote Data address: 10.3.219.32 Local TEID: 0x143400a8 Remote TEID: 0x105 Bearer State: Established Substate: - Idle Timeout: 0 min(0 -0,0) AAA Interim Interval: 0 min(0 -0,0) Negotiated QoS Parameters: Traffic Class:Background ARP: 1 Traffic Handling Priority:3 Transfer Delay :10 MBR Uplink: 6976 kbps MBR Downlink :6976 kbps GBR Uplink: 128 kbps GBR Downlink: :128 kbps Signaling Indicator :0 Forwarding Class: - Loss Priority: - Requested QoS Parameters: Traffic Class: Background ARP: 1 Traffic Handling Priority: 3 Transfer Delay: 10 MBR Uplink : 6976 kbps MBR Downlink: 6976 kbps GBR Uplink: 128 kbps GBR Downlink: :128 kbps Signaling Indicator: 0 Charging information: Profile ID: 0 State: Init Previous State: Init Profile selection criteria: - Offline charging information: Current service data container sequence number: 0 Current partial record sequence number : 0 Number of CDRs closed : 0 Rating group information: Rating group: 0 Service id: 0 Action ID: 0x0 Trigger profile: 0 Change condition bitmask: 0x0 Action-id-bitmask: 0x0 Signal bitmask: 0x0 Last signal bitmask: 0x0 Last statistics collection time : None collected

From the bolded output you can see that the SGSN is requesting 6MB and that’s great, but from the MBG/GGSN side this needs to be 5MB as per Mass Telecom’s management team. They do not want to give away too much bandwidth per subscriber. Time for the Mass Telecom GGSN engineers to take control. Let’s go under the unified-edge hierarchy to set the Mobile COS settings.

NOTE It’s important to point out that the Mobile COS settings can be used globally across all gateways since they are set under unified-edge directly, and are not tied directly to a Gateway.


So we will create a simple COS policy profile called Masst_QoS under cos-cac (Class of Service – Call Admission Control). The cos-policy-profile we are creating is simple, since it is just stating any type of traffic, also known as 3G traffic-class or 4G QCI, for both upstream and downstream can have a MBR of 5MB. They have also set low values for GBR (Guaranteed-Bit-Rate) since they are unsure what their peak subscriber rate will be. So below is what their simple COS policy profile looks like:

[edit unified-edge cos-cac cos-policy-profiles]root@GGSN-960# showMasst_QoS { pdp-qos-control { maximum-bit-rate-uplink 5120; maximum-bit-rate-downlink 5120; guaranteed-bit-rate-uplink 256; guaranteed-bit-rate-downlink 256; }}

Let’s test our new QOS/COS settings by attaching the cos-policy-pro-file Masst_QoS we just created to a unified-edge local policy we will call Masst_Policy_One. Unified-edge local policies are just objects that allow you to tie different policies together to define one policy for the Gateway or APN. In a bit we will add other policies under Masst_Poli-cy_One to flesh it out, but for now it will only hold our simple Cos policy:

[edit unified-edge local-policies Masst_Policy_One]root@GGSN-960# show cos-policy-profile Masst_QoS;

Now under the Masst apn hierarchy, attach this local policy:

[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]root@GGSN-960# show local-policy-profile Masst_Policy_One;

It should be noted that we could have attached the profile to the gateway if we wanted the same polices applied to every APN.

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# set local-policy-profile Masst_Policy_One

At this point it should be explained that the default behavior for the pdp-qos-control setting is to downgrade the requested MBR values if they exceed the configured values under the pdp-qos-control. If the requested MBR values are below this configured value, the MBG will honor the requested value and leave it as it is. If no value is set for MBR and GBR, then the system will honor the requested value, regard-less of how high it is, as long as it is within the QoS 3GPP specifica-


tions. So be aware that when the pdp-qos-control is not configured on the MBG you are leaving the bandwidth control in the hands of other nodes in the packet core, like the HLR/HSS and SGSN/MME.

Looking at a GTPv1 example, the requested QoS parameters arriving from the SGSN show the MBR uplink and downlink values as being 8640 kbps, but using the configuration that Mass Telecom wants to apply, the MBG will downgrade the actual negotiated values to 5120 kbps as seen under the negotiated QoS parameters. The GBR value is only 1kbps and since the upgrade flag was not set we honor the requested value of 1 kbps.

root@GGSN-960> show unified-edge ggsn-pgw subscribers extensive

Subscriber Information: IMSI: 123456789463930 IMEI: 1122334455667805 MSISDN: 26737762 Time Zone: None (DST): None Status: Visitor User Location Info: MCC: None MNC: None LAC: 0x0 CI: 0x0 SAC: 0x0 RAC: 0x0 TAC: 0x0 ECI: 0x0 RAT Type: Unknown PDN Session: APN name: masst.com IPv4 Address: 15.4.20.1 IPv6 Address: None Direct Tunnel: Disabled Session Duration: 3 Local Control address: 10.3.219.250 Remote Control address: 10.3.219.32 TEID Control Local: 0xc002d30 TEID Control Remote: 0x122 Addressing scheme: Local Selection mode: sub verified Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 10/0 (FPC/PIC) Session State: Established GTP Version: 1 Serving network: MCC: None MNC :None Bearer: NSAPI/EBI: 5 Charging ID: 0xc002d30 Local Data address: 10.3.219.250 Remote Data address: 10.3.219.32 Local TEID: 0x340d5c Remote TEID: 0x121 Bearer State: Established Substate: - Idle Timeout: 0 min(0 -0,0) AAA Interim Interval: 0 min(0 -0,0) Negotiated QoS Parameters: Traffic Class:Conversational ARP: 1 Traffic Handling Priority:1 Transfer Delay: 80 MBR Uplink: 5120 kbps MBR Downlink: 5120 kbps GBR Uplink: 1 kbps GBR Downlink: 1 kbps Signaling Indicator: 0 Forwarding Class: None Loss Priority: None Requested QoS Parameters: Traffic Class: Conversational ARP: 1 Traffic Handling Priority: 1 Transfer Delay: 10 MBR Uplink : 8640 kbps MBR Downlink: 8640 kbps GBR Uplink : 1 kbps GBR Downlink: 1 kbps Signaling Indicator: 0 Charging information: Profile ID: 0 State: Init Previous State: Init


Profile selection criteria: - Offline charging information: Current service data container sequence number: 0 Current partial record sequence number : 0 Number of CDRs closed : 0 Rating group information: Rating group: 0 Service id: 0 Action ID: 0x0 Trigger profile: 0 Change condition bitmask: 0x0 Action-id-bitmask: 0x0 Signal bitmask: 0x0 Last signal bitmask: 0x0 Last statistics collection time : None collected

The MBG does allow some advanced control over the pdp-qos-control feature by allowing the default behavior to be modified. You can change the default behavior to reject the Create PDP Context Requests if the requested MBR or GBR value is higher than the value set on the MBG. You can also allow the MBG to upgrade the requested MBR and GBR values if they are lower than the configured value on the MBG. Here are the options:

root@GGSN-960# set maximum-bit-rate-uplink 5120 ?Possible completions: <[Enter]> Execute this command reject Reject calls with higher uplink maximum-bit-rate upgrade Override maximum-bit-rate uplink value

Remember, for GTPv1 requests the MBR and GBR values can only be updated if the ‘Upgrade QoS Supported’ bit is sent by the SGSN in the Common Flags IE.

MOBILE TIP Per 3GPP 29.060: “The Upgrade QoS Supported bit field is relevant for a Create PDP Context or Update PDP Context procedure and is used by SGSN to indicate to GGSN whether QoS upgrade in Response message functionality is supported.”

The MBG also allows the administrator of the box to set QoS controls based on the Traffic Class for 3G subscribers and QCI for 4G subscrib-ers. Below is an example of Mass Telecom expanding on their current setup by adding a specific setting for qci 5 and qci 9:

[edit unified-edge cos-cac cos-policy-profiles MASST-QoS pdp-qos-control]root@GGSN-960# show maximum-bit-rate-uplink 5120;maximum-bit-rate-downlink 5120;guaranteed-bit-rate-uplink 254;guaranteed-bit-rate-downlink 254;qci 9 { maximum-bit-rate-uplink 512 reject; maximum-bit-rate-downlink 1024 reject; guaranteed-bit-rate-uplink 256 reject; guaranteed-bit-rate-downlink 256 reject;


}qci 5 { maximum-bit-rate-uplink 2560 upgrade reject; maximum-bit-rate-downlink 5120 upgrade reject; guaranteed-bit-rate-uplink 256; guaranteed-bit-rate-downlink 256;}

Now it should be understood that the MBG simplifies the QOS setup by mapping 3G traffic classes to 4G QCI values. How that mapping occurs is as follows:

1. The Traffic Class Background will map to QCI 9.

2. The Traffic Class Interactive with the Traffic handling Priority set to 3 will equal QCI 8.



5. The Traffic Class Interactive with the Traffic handling Priority set to 1 and the Signialing Indication value set will equal QCI 5.

6. The Traffic Class Streaming will map to QCI 4.

7. The Traffic Class Conversational with Transfer Delay lower than 150ms will map to QCI 3.

8. The Traffic Class Conversational with Transfer Delay greater than or equal to 150ms will map to QCI 2.

9. The Traffic Class Conversational with Source Statistics Descriptor of Speech will map to QCI 1.

Okay, admittedly, that was a simple QoS scenario. So let’s dig a bit deeper and look at a few more features to apply.

The CAC functionality in the MBG, if configured correctly, can help ensure resources are available for services like VoIP, streaming video, or whatever else is prioritized by the provider. CAC can look at system resources availability and the priority of the bearer. Then, using these facts, the CAC policy can downgrade data requests or even reject new bearer requests.

With the number of subscribers it plans to sign up, Mass Telecom expects to be successful enough that a wide-open policy may not be a good idea. Remember, their maximum-bearers for the whole Gateway are set to 2 million. If a decent portion of those subscribers has one bearer active at the same time and their negotiated QoS settings are


5120 for maximum-bit-rate-uplink and maximum-bit-rate-downlink per the cos-policy-profile they set MASST-QoS, well, then they are in potential trouble. So let’s help them out.

First, under the [unified-edge cos-cac] hierarchy, let’s set a band-width-pool. The bandwidth pool will be attached to the same local-policy already bound to the Masst apn, the one that has MASST-QOS assigned to it. Since this is Mass Telecom’s main APN that many of their home users will use, they want to give it plenty of bandwidth, but not so much that it potentially starves their other APNs. So put 100 GB into this pool. Also, let’s use the downgrade-gtp-v1-gbr-bearers option, which means when the bandwidth threshold is reached, any new create or modify PDP context requests arriving on the MBG are downgraded to the Background traffic class. If this option is removed, any new create or modify PDP context requests arriving on the MBG are rejected when the threshold is reached:

gbr-bandwidth-pools { BandWidth_Pool { bandwidth 104857600; downgrade-gtp-v1-gbr-bearers; }}

Now let’s add this new policy to the local policy so it takes effect on our Masst.com APN.

[edit unified-edge local-policies Masst_Policy_One]root@GGSN-960# show cos-policy-profile Masst_QoS;dl-bandwidth-pool BandWidth_Pool;

Next up, Mass Telecom wants to create a resource threshold profile for system thresholds to determine which subscribers will actually gain access to the MBG when resources are becoming scarce. If memory, CPU, or the number of bearers in use is 80% of the system resources, then only Create PDP Context Requests with an ARP (Allocation and Retention Priority) value of 1 for GTPv1 and a priority level of 1 for GTPv2 will be accepted. If the threshold for any of these resources is 60% then Create PDP Context requests for GTPv1 with an ARP value of 2 or lower or a GTPv2 request with a priority level value of 6 or lower will be accepted.

MOBILE NOTE Allocation and Retention Priority is a value used by GGSNs to deter-mine if a Create PDP Context request with a higher priority can take a resource from an existing bearer with a lower priority, a reverse Robin Hood if you will. Note that the Juniper GGSN does not do this, exactly.


Okay, let’s configure this under [unified-edge cos-cac resource-threshold-profiles] and create a resource threshold profile called Masst_threshold:

[edit unified-edge cos-cac resource-threshold-profiles Masst_threshold]root@GGSN-960# show bearers-load { low { percentage 60; priority-level 6; } high { percentage 80; priority-level 1; }}memory { low { percentage 60; priority-level 6; } high { percentage 80; priority-level 1; }}cpu { low { percentage 60; priority-level 6; } high { percentage 80; priority-level 1; }}

Overall the configuration is very simple and straightforward, as you can see. You can set a high and low threshold, which maps to a priori-ty-level.

To be clear, let’s review how the GTPv2 priority level parameters map to GTPv1 ARP parameters. This is done in the same way the MBG simplifies the QOS setup by mapping 3G traffic classes to 4G QCI values:

� Priority level value 1 is ARP 1 in GTPv1



And here’s an example to help you further understand how this works. Look at the changes made to the bearer-load:


[edit unified-edge cos-cac resource-threshold-profiles Masst_threshold]root@GGSN-960# show bearers-load { low { percentage 60; priority-level 9; } high { percentage 80; priority-level 5; }}

Now, when the low threshold is reached, GTPv2 Create PDP Context requests with a priority level of 9 or lower will be admitted by this profile. Based on the GTPv2 priority level mapping to GTPv1 ARP, a priority level of 9 does not map directly to any GTPv1 ARP settings. But since GTPv1 ARP 2 maps to GTPv2’s priority level 6, and 6 is lower than the currently configured priority level 9, GTPv1 Create PDP Context requests with an ARP value of 2 or 1 will be admitted.

Using the same logic, when the new high threshold for bearers-load is reached, GTPv2 Create PDP Context requests with a priority level of 5 or lower will be admitted and GTPv1 Create PDP Context requests with an ARP value of 1 will be admitted.

Time to add this profile to the local profile:

[edit unified-edge local-policies Masst_Policy_One]root@GGSN-960# show cos-policy-profile Masst_QoS;dl-bandwidth-pool BandWidth_Pool;resource-threshold-profile Masst_threshold;

Mass Telecom also wants to define the forwarding class and loss priority for their bearers. Remember how the MBG maps 3G traffic classes map to 4G QCI values before you begin, and then under [unified-edge cos-cac classifier-profiles] create a profile called CLASSIFIER_PROFILE_MBG. Let’s take an example using the qci 1 for conversational, QCI 5 for interactive, and QCI 9 for background. Since a bearer with the traffic class of interactive or the QCI of 5 is considered a decent high priority by Mass Telecom, they want to set the loss priority to be low, and the forwarding class to be expedited. QCI 1, also known as conversational, normally very important for the forwarding class, is set to VOICE and the loss priority is low. Last is QCI 9, also known as background, which is the least important type of traffic. The forwarding class is the lowly BE and loss priority is high.

[edit unified-edge cos-cac classifier-profiles]root@GGSN-960# show CLASSIFIER_PROFILE_MBG { qos-class-identifier 1 forwarding-class VOICE loss-priority low;


qos-class-identifier 5 forwarding-class AF11 loss-priority low; qos-class-identifier 9 forwarding-class BE loss-priority high;}

The forwarding classes that can be chosen are the commonly defined ones set in DiffServ (Differentiated Services), or mainly:

� Best Effort: Typically best-effort traffic

� Expedited Forwarding: Dedicated to low-loss, low-latency traffic

� Assured Forwarding: Gives assurance of delivery under pre-scribed conditions

� Network Control: Maintains backward compatibility with the IP Precedence field

Okay, another profile to add to our local policy Masst_Policy_One:

[edit unified-edge local-policies Masst_Policy_One]root@GGSN-960# show cos-policy-profile Masst_QoS;dl-bandwidth-pool BandWidth_Pool;resource-threshold-profile Masst_threshold;classifier-profile CLASSIFIER_PROFILE_MBG;

So the Masst.com apn is not wide open anymore. The system now has the ability to put on some brakes.

Mass Telecom also wants to enable preemption, which is disabled by default. Preemption in 3G (GTPv1) allows the MBG using the ARP value to help decide if it should accept the Create PDP Context request, or if it should Modify it. In 4G (GTPv2) the PVI and PCI values are used.

Let’s briefly explore preemption and how the MBG works with it. For example, let’s assume that an APN is fully loaded and there is no room for any new subscribers based on the maximum-bearers value being exceeded, or maybe the mobile enabled MS-DPC’s on the system are all 100% full. When a new Create PDP Context request comes in, there may be no suitable candidates to be deleted in the bearer pool. If that is the case, then, the candidate pool is checked to see if there is any about to be deleted candidate bearers that can be used for this bearer.

And to prove the point, let’s assume an end user just roamed out of Mass Telecom coverage (maybe veering off into New Hampshire) so there is now a bearer marked for deletion. A new 3G subscriber in Boston just turned their iPhone on, and the Create PDP Context Request has an ARP value of 3. Now, just slightly after that request comes in but before it can be processed, and given the resource from the bearer pool, another Create PDP Context Request from another


mobile user comes in with an ARP of 2. With preemption enabled, the candidate who is about to be deleted will yield their bandwidth to the new create bearer request, the one with the better ARP value of 2. Since there are no free candidates to associate with the ARP 3 bearer, the create request (for ARP 3) would be failed.

Preemption support is only at the GW level, meaning the preemption candidates that will be maintained for preemption will not be per APN, but will be for the whole gateway. Let’s enable this feature now:

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# set preemption enable

There is another useful command that the MBG has, this one will show you the qos statistics:

root@GGSN-960> show unified-edge ggsn-pgw qos statistics Gateway: MASSTControl plane statistics: Session establishment attempts: 100005 Successful session establishments: 100005 MS/peer initiated session deactivations: 100002 Successful MS/peer initiated deactivations: 100002 Gateway initiated session deactivations: 0 Successful gateway initiated deactivations: 0Data plane global statistics: Source address violation packets: 0 Source address violation bytes: 0 Total packets rcvd with non-existent TEIDs: 0Data plane GTP statistics (Gn/S5/S8): Input packets: 300438 Input bytes: 423691560 Output packets: 534 Output bytes: 29904 Discarded packets: 0 Data plane GTP statistics (Gi): Input packets: 534 Input bytes: 29904 Output packets: 300438 Output bytes: 423691560 Discarded packets: 0

To really get good information on the type of subscriber settings based on QOS you can be more granular with the output of the command:

root@GGSN-960> show unified-edge ggsn-pgw qos statistics ? Possible completions: <[Enter]> Execute this command apn APN name arp GTPv2 ARP Value (1..15) gateway Show subscriber for a gateway gtpv1-arp GTPv1 ARP Value (1..3)


qci Show QCI statisics information (1..9) traffic-class Show statistics for a traffic-class level traffic-handling-priority Traffic handling priority (1..3) | Pipe through a commandroot@GGSN-960> show unified-edge ggsn-pgw qos statistics arp ?Possible completions: <arp> GTPv2 ARP Value (1..15)

root@GGSN-960> show unified-edge ggsn-pgw qos statistics arp 2 Gateway: MASSTControl plane statistics: Gn/S5 signaling msgs rcvd: 0 Gn/S5 signaling msgs sent: 11 Gn/S5 signaling msgs dropped: 0 Gn/S5 signaling bytes rcvd: 0 Gn/S5 signaling bytes sent: 0 Total GTP tunnels created: 0 Session establishment attempts: 22 Successful session establishments: 11 MS/peer initiated session deactivations: 9 Successful MS/peer initiated deactivations: 9 Gateway initiated session deactivations: 0 Successful gateway initiated deactivations: 0 Session Establishments Failed (by GTP cause): Others 0 Service unavailable: 0 System failure: 0 No resources: 0 No address: 0 Service denied: 0 Authentication Fail: 0 APN access denied: 0Data plane GTP statistics (Gn/S5/S8): Input packets: 630 Input bytes: 0 Output packets: 0 Output bytes: 0 Discarded packets: 0 Data plane GTP statistics (Gi): Input packets: 0 Input bytes: 0 Output packets: 0 Output bytes: 630 Discarded packets: 51062

root@GGSN-960> show unified-edge ggsn-pgw qos statistics traffic-handling-priority 2 traffic-class interactive Gateway: MasstControl plane statistics: Gn/S5 signaling msgs rcvd: 0 Gn/S5 signaling msgs sent: 0 Gn/S5 signaling msgs dropped: 0 Gn/S5 signaling bytes rcvd: 0


Gn/S5 signaling bytes sent: 0 Total GTP tunnels created: 0 Session establishment attempts: 0 Successful session establishments: 0 MS/peer initiated session deactivations: 0 Successful MS/peer initiated deactivations: 0 Gateway initiated session deactivations: 0 Successful gateway initiated deactivations: 0 Session Establishments Failed (by GTP cause): Others 0 Service unavailable: 0 System failure: 0 No resources: 0 No address: 0 Service denied: 0 Authentication Fail: 0 APN access denied: 0Data plane GTP statistics (Gn/S5/S8): Input packets: 29026 Input bytes: 1546473 Output packets: 55444 Output bytes: 75631200 Discarded packets: 210 Data plane GTP statistics (Gi): Input packets: 55444 Input bytes: 75631200 Output packets: 29026 Output bytes: 1546473 Discarded packets: 0

Summary

Let’s take a quick inventory of what has been configured so far on the MBG for Mass Telecom:

� The APN (masst.com) handles all the Mass Telecom home subscribers and this APN uses a pool that assigns IP addresses from the 15.0.0.1/14 range.

� There are two virtual APNs for Nscotia roamers (internet123 and Canada) that call a service-selection profile. If the IMSI being used starts with 302200, they are mapped to another APN, NScotia, which uses a pool with a range of 15.4.0.1/16.

� There is another APN, masst.bb, which some Blackberry devices will use that authenticates to RADIUS using the unique IMSI as the user-name for potential unique session settings.

� All APNs that are not virtual, meaning masst.com, masst.bb, and NScotia, map to the routing instance GI_VR.


� Masst.com and masst.bb use RADIUS for authentication and accounting of the session. They also send charging records to the RADIUS server.

� The MBG has been set up to send CDR records to a CGW for the NScotia APN.

� COS and CAC settings have been applied to the masst.com APN. The NScotia and masst.bb APN are still wide open.

Now, let’s really show off MBG running on our MX in Chapter 4.

Chapter 4

Advanced Configuration Techniques

Service Selection Profile with Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Additional Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

GTP Path Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


The advanced techniques in Chapter 4 include use-cases, deeper dives into looking at stats, and analyzing some testing results. It’s a nice quick tour through the MBG, and when done, you should feel very comfortable driving the MBG around. If you’ve made it this far, you’ll be a master of this solution in no time. You’re almost there.

Service Selection Profile with Redirection

Mass Telecom is interested in analyzing and deciding whether to off-load subscribers to a Video Optimization solution versus process-ing the Create PDP Context/Create Session request locally. In addition, the account wants to send all the UEs, excepting iPhones, to the Video Optimization solution. So let’s use the Service-Selection-Profile feature to steer traffic to the receiving IP address (10.3.219.60 ) of the Video Optimization solution by keying off of a variable that distinguishes other mobile devices from the iPhones.

The Junos options to key off of are:

charging-characteristics Match charging characteristics (1..65535)imei Match IMEIimsi Match IMSImaximum-bearers Maximum bearers in the gateway (1..10000000)msisdn Match MSISDNpdn-type peer IP address of the peer creating the sessionpeer-routing-instance Routing instance of the peer creating the session

Let’s begin by looking at how to leverage these options. If the SGSN/MME handling iPhones uses a different Gn/S5/S8 source IP address than the other UE’s, then from the MBG’s point of view, you could use the Routing-Instance or peer. But that option will not work since the Gn/S5/S8 is not selected by the RAN or HLR/HSS, based on the UE type.

The IMSI could work if the iPhones have a different country code or network code, but most likely they would not in any setup. If the IMSI did have any distinguishing numbers for the iPhone you could set up the service-selection-profile like this:

service-selection-profiles { profile Selection_Profile_1 { term Term1 { from { imsi 31011178132; } then { redirect-peer 10.3.219.60; } } }}

Chapter4:AdvancedConfigurationTechniques 73

Here, the example for the country code is 310, the Mobile Network code is 111, and the MSIN starts with 78132.

Now if their BlackBerrys also had IMSIs that are 31011178132*, then this would not work, so the SIM cards would need to be specially pressed for the unit type. And SIM cards are not done like this; you can’t stop a subscriber from moving SIM cards from one mobile UE to another. You've reached another dead end.

A more valid approach may be to see if you can use RADIUS to provision the subscriber’s service, in this case returning the RADIUS Attribute Jnpr-Redir-GW-Addr. This would redirect the subscribers to the Video Optimization server. If the User-Name was uniquely hard-coded on the iPhones, or other mobile devices, this would be easy. For example, if all User-Name attributes that came from iPhones were iphone, it’s easy. If the mobiles all have unique users, this would work, too.

Now let’s consider that Mass Telecom and NScotia may want to send all of the NScotia roaming subscribers back to a GGSN in Nscotia’s mobile packet core and Mass Telecom has to redirect from the GGSN, not the SGSN, for some reason. In the following example, if any IMSI comes from 302200, it’s sent back to a NScotia GGSN, or whatever they want the target to be at the NScotia site. In this example, that would be 20.20.20.22:

service-selection-profiles { profile Selection_Profile_1 { term Term1 { from { imsi 302200; } then { redirect-peer 20.20.20.22; } } }}

Mass Telecom could also create a service selection profile that can be applied to an APN that helps share the load. So if this chassis has limited MS-DPCs, and you feel Mass Telecom may reach their limits, you can have the MBG redirect new PDP Create Requests to another GGSN, for example. Share the load and let the other GGSN establish and manage the session. Just make sure that the other GGSN is not configured to send requests back to this one, or you could run into a scenario where the two GGSNs are passing the same requests back and forth until the from definition clears. Here’s this redirect example:


service-selection-profiles { profile Masst_Rollover { term term1 { from { maximum-bearers 1000000; } then { redirect-peer 10.3.219.78; } } }}

Additional Address Assignment

Now Mass Telecom needs more flexibility for the Masst APN than just having RADIUS assign the IP addresses. They want the UEs to be able to come in with a statically assigned address that will be sent to the MBG in the Create PDP Session Request. For this functionality, add allow-static-ip-address to the configuration.

To do this, go under unified-edge > gateways > ggsn-pgw > Masst > apn-services > apns > masst.com and add:

address-assignment { inet-pool { pool roamer; } allow-static-ip-address;}

Let’s say Mass Telecom also wants to use a DHCP server to assign IP addresses to the masst.bb APN. They just need to add a dhcp proxy section to the Junos configuration and add that to the APN.

To do this, go under the [edit system services dhcp-proxy-client dhcpv4-profiles masst_dhcp_profile] hierarchy:

lease-time 1000;retransmission-interval 4;dhcp-server-selection-algorithm round-robin;bind-interface xe-3/0/2;servers 10.3.2.2 { priority 1;}

Then under [edit unified-edge gateways ggsn-pgw Masst apn-ser-vices apns masst.bb] hierarchy:

address-assignment { dhcp-proxy-client; dhcpv4-proxy-client-profile { profile-name masst_dhcp_profile; }}

There you go. DHCP is working for your APN now.


GTP Path Management

GTP Path Management uses GTP echo messages to ensure that the nodes involved in the GTP tunnel setup are active. And if your MBG is a GGSN, you care about the SGSN being active. If your MBG happens to be a PGW, you care about the SGW and MME.

If path management is enabled, the MBG will send echo requests at a predetermined time to all nodes in its peer list. If the MBG does not get a response back from the peer after a predetermined time, the MBG will consider the peer to be down and unavailable.

� echo-n3-requests is the number of times that the MBG attempts to send an echo-request message before it marks the peer as down.

� echo-t3-response is the number of seconds that the MBG waits for an echo response from a peer gateway before sending the next echo-request.

� echo-interval is the number of seconds the MBG waits before sending the next echo request message after a response to the previous echo request is received.

� n3-requests sets the maximum number of times that the MBG sends a GTP request message to create, update, or delete a PDP context.

� t3-response will set the number of seconds that the MBG waits for a create/update/delete response from a peer before retransmit-ting the message.

Path management simply enables the MBG to send echo requests to peers, or disables the MBG from sending echo requests to peers. When disabled, the MBG still responds to echo requests sent from the peers themselves.

So Mass Telecom wants the Gp and S8 interfaces to use one set of values, and the Gn and S5 interfaces to use another. The reason is that the Gn and S5 interfaces are for nodes that exist in their homePLMN. It is their equipment and their network, so they trust that packets will be delivered timely. They have less faith with packet delivery to a visitingPLMN like NScotia’s network, so they have created values there that match traffic results from Mass Telecom’s homePLMN to NScotia’s visitingPLMN.

Mass Telecom has set the following default. They will affect behavior on the Gp and S8 interfaces. The Gn and S5 have their own sections defined by Masst, and those values will override the defaults.


[edit unified-edge gateways ggsn-pgw Masst gtp]root@GGSN-960# show n3-requests 5;t3-response 6;echo-interval 120;echo-n3-requests 5;echo-t3-response 6;path-management enable;gn { interface lo0.1 v4-address 201.100.1.6; n3-requests 5; t3-response 5; path-management enable; echo-n3-requests 3; echo-t3-response 5;}S5 { interface lo0.1 v4-address 01.100.1.6; n3-requests 5; t3-response 5; path-management enable; echo-n3-requests 3; echo-t3-response 5;}

If Mass Telecom ever needs to, they can define unique settings for the S8 and Gp interfaces, too. They can even leverage the MBG to create different settings for Control versus Data. So, if the SGSN sends all GTPu traffic through a firewall that may potentially cause packet loss, they can define more granular settings that increase just GTP data packets values over GTP control packets. For example:

gn { interface lo0.1 v4-address 201.100.1.6; n3-requests 5; t3-response 5; path-management enable; control { echo-n3-requests 3; echo-t3-response 5; } data { echo-n3-requests 5; echo-t3-response 10; }}

Last, but not least, Mass Telecom wants to set the traffic class for control traffic since they can be sending control traffic to a GGSN in NScotia’s network.

For this, go under [unified-edge gateways ggsn-pgw Masst gtp] and add the following:


control { forwarding-class assured-forwarding; dscp-code-point 10;}

The traffic class can be set to be more granular if you wish, such as under the [unified-edge gateways ggsn-pgw Masst gtp gn control] section.

So, what are the default path management settings if Mass Telecom does not touch this GTP section at all:

echo-n3-requests—The default is 8 times.echo-t3-response—The default is 15 seconds.echo-interval—The default is 60 seconds.n3-requests—The default is 3 times.t3-response—The default is 5 seconds.path-management—Is enabled by default for GTP control packets but disabled for GTP data packets.

There is just one more little item to cover that might be helpful in your production network. You see, Mass Telecom has these old SGSNs. They get overloaded easily and they tend to drop control traffic, which is a very bad thing. So Mass Telecom wants to change the response/requests path management settings just for these devices.

Easy enough with the power of the MBG. Just setup a peer-group under [unified-edge gateways ggsn-pgw Masst gtp] like this:

peer-group Old_Sgsns { routing-instance 1; n3-requests 5; t3-response 10; echo-n3-requests 5; echo-t3-response 10; peer { 201.100.1.87/32; 201.100.1.59/32; 201.100.1.201/32; }}

If you need to check the status of the GSN peers such as the SGSN, SGW, or Node b’s, run this command:

root@GGSN-960> show unified-edge ggsn-pgw gtp peer detail Gateway: Masst Peer Detail:---------------Remote IP Address : 201.100.1.2Local IP Address : 201.100.1.6Routing Instance : 6Interface Type : GnGTP Version : 1RCM Registration Done : yes


Restart Counter Valid : yesRestart Counter Value : 1Sent Restart Counter Value : 7Control Path N3 Request : 3Control Path T3 Timer : 5Control Path Echo N3 Request : 8Control Path Echo T3 Timer : 15Control Path Echo Interval : 60Control Path Management Enabled : noControl Path State : not-trackedData Path Echo N3 Request : 8Data Path Echo T3 Timer : 15Data Path Echo Interval : 60Data Path Management Enabled : noData Path State : not-trackedGTP-C using Short Sequence Number : noDownlink data notif delay Interval : 0CSID Supported : no

You can also get overall GTP statistics:

root@GGSN-960> show unified-edge ggsn-pgw gtp statistics ? Possible completions: <[Enter]> Execute this command detail GTP Cause Stats Included fpc-slot FPC slot number gateway Show statistics for a gateway gtp-all GTP all version statistics gtp-error-ind GTP Error Indication statistics gtp-v0 GTP version 0 statistics gtp-v1 GTP version 1 statistics gtp-v2 GTP version 2 statistics pic-slot PIC slot number

root@GGSN-960> show unified-edge ggsn-pgw gtp statistics gtp-v1 Gateway: Masst

Global Packet Statistics Received Packets Dropped : 0 Packet Allocation Fail : 0 Packet Send Fail : 0 IP Version Error Received : 0 IP Protocol Error Received : 0 GTP Port Error Received : 0 GTP Unknown Version Received : 0 Packet Length Error Received : 0 Unknown Messages Received : 0

GTP Version 1 Statistics:------------------------- Protocol Error : 0 Unsupported Messages Received : 0 T3 Response Timer Expires : 0


Message Type Received Transmitted ----------------------------------------------------------------------------- Total number of messages 210314 210314 Total number of bytes 10058725 9509386 Redirect messages 0 0 Echo Request 0 0 Echo Response 0 0 Version Not Supported 0 0 Create PDP Context Request 110178 0 Create PDP Context Response 0 110178 Update PDP Context Request 0 0 Update PDP Context Response 0 0 Delete PDP Context Request 100136 0 Delete PDP Context Response 0 100136

Summary

There are more advanced techniques of course, and many of them are available at the resources outlined on the last page of this book.

You should now have set up, deployed, configured, and committed your MBG on your MX Series. Wow! And Mass Telecom is pretty happy in their imaginary world.

Before you go, however, take a look at the final chapters. The first is based on general system maintenance focused on the mobile side of the MX and the second is based on troubleshooting the box as you take your lab work onto the shop floor.

Chapter 5

System Maintenance

Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Clearing Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


Maintenance Mode is a feature of the MBG that is required when the administrator of the box needs to make certain changes. What Mainte-nance Mode does is take certain functions offline, so new requests are not accepted while changes are made. The idea is to get the system into a place where no service-affecting changes are made while subscribers are active on the box. So when in maintenance mode the system will not take on new subscribers for the object in question. Once all subscribers have left the system the changes can be made and then you can bring the MBG out of maintenance mode and it will accept requests again with the new changes now in effect. Let’s dig in and see it in action.

Maintenance Mode

The following changes can only be made while in maintenance mode:

� Delete or modify the addresses of certain GPRS tunneling protocol (GTP) interfaces

� Delete or change the type of an access point name (APN)

� Change mobile interface configuration parameters

� Change a mobile interface for an APN

� Delete a charging profile

� Delete or modify a charging data record (CDR) profile or CDR type

� Delete or modify a transport profile

� Delete or modify a trigger profile

� Delete a mobile pool or modify its parameters

Let’s start by putting the whole gateway into maintenance mode:

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# set service-mode maintenanceroot@GGSN-960# commit

Run this command now to see the service-mode status for the Masst gateway:

root@GGSN-960# run show unified-edge ggsn-pgw service-mode Maintenance Mode MM Active Phase - System is ready to accept configuration changes for all attributes of this object and its sub-hierarchies. MM In/Out Phase - System is ready to accept configuration changes only for non-maintenance mode attributes of this object and its sub-hierarchies.

Gateway Name Service ModeMasst Maintenance - In Phase

Chapter5:SystemMaintenance 83

Note the status is In Phase. That means the system is not ready to be in Maintenance Mode yet.

The first thing to check is to see if any subscribers are still active:

root@GGSN-960# run show unified-edge ggsn-pgw status Gateway: Masst Active Subscribers : 1 Active Sessions : 1 Active Bearers : 1 CPU Load (%) : 0 Memory Load (%) : 29

You can see there is one subscriber left and you do not have time to wait for them to stop what they are doing. This whole system is offline and the web browsing habits of one subscriber cannot get in our way! So let’s clear them from the system:

root@GGSN-960# run clear unified-edge ggsn-pgw subscribers gateway Masst

And let’s check to see if the service-mode is now active:

root@GGSN-960# run show unified-edge ggsn-pgw service-mode Maintenance Mode MM Active Phase - System is ready to accept configuration changes for all attributes of this object and its sub-hierarchies. MM In/Out Phase - System is ready to accept configuration changes only for non-maintenance mode attributes of this object and its sub-hierarchies.

Gateway Name Service ModeMasst Maintenance - Active Phase

Okay, we are now good to go. Make your changes, change GTP ip-addresses, change IP pools. Delete APNs. Whatever you need to do. Commit those changes and when you are done with that commit then you can delete the service-mode parameter from the Gateway and commit once more:

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# delete service-mode

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# commit commit complete

Now those subscribers can come back and get serviced by this MBG. Run the show unified-edge ggsn-pgw service-mode command one more time to verify the Service Mode is operational:

root@GGSN-960# run show unified-edge ggsn-pgw service-mode Maintenance Mode MM Active Phase - System is ready to accept configuration changes for all attributes of this object and its sub-hierarchies. MM In/Out Phase - System is ready to accept configuration changes only for non-


maintenance mode attributes of this object and its sub-hierarchies.

Gateway Name Service ModeMasst Operational

The example used here locks down the whole gateway and takes it out of service. The truth is, when performing maintenance on the MBG, the operator may not need to take such extreme measures as locking a whole gateway. For example, they may only need to lock down a given APN or a Charging Profile.

For each feature that needs to be put into maintenance mode you can drill down to the section where that feature is enabled, and put only that feature into maintenance mode:

[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]root@GGSN-960# set service-mode maintenance

[edit unified-edge gateways ggsn-pgw Masst charging charging-profiles CP1]root@GGSN-960# set service-mode maintenance

You can also manually clear the subscribers that use just these features, thus leaving the rest of the MBG to continue functioning in service as normal while taking just this one feature and its subscribers offline:

root@GGSN-960# run clear unified-edge ggsn-pgw subscribers apn Masstroot@GGSN-960# run clear unified-edge ggsn-pgw subscribers charging charging-profile CP1

Clearing Subscribers

There will also be times when subscriber sessions on the box are considered hung. If session-timeout and/or idle-timeout are not set for all the APNs or Path-Management is disabled you may see this occur more frequently. The reason for this is that if the GTPc Delete PDP Context Request or Delete Session request never makes it to the MBG when the UE disconnects, the MBG will have no idea the session should go away.

Check the configuration to see if you have session-timeout and idle-timeout set, and if path management is enabled or not. Remember, you do not need these features to be enabled on the system, but under-standing whether or not they are enabled will give you insight into whether or not your MBG will be susceptible to potential hung sessions.

[unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]inactive session-timeout 24;inactive idle-timeout 60;

Chapter5:SystemMaintenance 85

[unified-edge gateways ggsn-pgw Masst gtp]path-management disablegn { path-management disable;}s5 { path-management disable;}s8 { path-management disable;}

When there are subscribers on the MBG that don’t belong there, you can clear them with the clear unified-edge ggsn-pgw subscribers command. A system administrator can also clear a subscriber that they know is active but needs to be dropped. Clearing a subscriber does cause the MBG to send a GTPc Delete PDP Context/Delete Session Request to the GTP peer, so if the peer is reachable on the network it will process the packet and drop the subscriber on its side. Normally, the MBG’s subscribers are provisioned and managed by RADIUS or a PCRF server. These types of solutions can create Disconnect Messages that are sent to the MBG, which causes the MBG to perform the same task as running the clear unified-edge ggsn-pgw subscribers command.

You can disconnect subscriber sessions individually using the clear unified-edge ggsn-pgw subscribers command, or, if a GTP peer like a SGSN goes down, you can clear all subscribers that belonged to it:

root@GGSN-960# run clear unified-edge ggsn-pgw subscribers ? Possible completions: apn Clear all the subscribers in an APN charging Clear all subscribers for a charging attribute gateway Clear all the subscriber for the gateway imsi Clear a subscriber with a specific imsi msisdn Clear a subscriber with a specific msisdn peer Clear all the subscribers of a specific peer routing-instance Routing instance associated with the subscriber v4-addr Clear a subscriber with matching IPv4 address v6-addr Clear a subscriber with matching IPv6 address

You can even clear every single subscriber that is connected to your gateway.

root@GGSN-960# run clear unified-edge ggsn-pgw subscribers gateway MASST

Chapter 6

Troubleshooting

show unified-edge ggsn-pgw status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

show unified-edge ggsn-pgw gtp peer detail . . . . . . . . . . . . . . . . . . . . . . . . .90

show unified-edge ggsn-pgw statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

show unified-edge ggsn-pgw charging path status . . . . . . . . . . . . . . . . . . . 91

show unified-edge ggsn-pgw subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

show unified-edge ggsn-pgw ip-reassembly statistics . . . . . . . . . . . . . . . . 95

clearing statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Logs! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

Error: Subscriber Rejected, No Resources Available . . . . . . . . . . . . . . . . . . . 99

Error: Encoding Cause Authentication Failure . . . . . . . . . . . . . . . . . . . . . . . . 105

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107


The following troubleshooting techniques are meant to help you get out of the lab and onto the shop floor, but get used to examining them as they are worth their weight in GGSN gold.

show unified-edge ggsn-pgw status

First let’s look at the show unified-edge ggsn-pgw status output. If there is any command to run just for the sake of looking at the state of the box, this is it. You can have someone like Mass Telecom run this to see how many mobile subscribers are on the MX, how many SPICs are up and running, the distribution of subscribers across the SPICS, and what the load is for each SPIC. It is very basic but useful:

[root@GGSN-960# run show unified-edge ggsn-pgw status detail Mobile gateway status of fpc slot: 2 pic slot: 0 State : Backup Active Subscribers : 50 Active Sessions : 50 Active Bearers : 50 CPU Load (%) : 0 Memory Load (%) : 28

Mobile gateway status of fpc slot: 2 pic slot: 1 State : Active Active Subscribers : 50 Active Sessions : 50 Active Bearers : 50 CPU Load (%) : 0 Memory Load (%) : 28

Mobile gateway status of fpc slot: 4 pic slot: 0 State : Active Active Subscribers : 50 Active Sessions : 50 Active Bearers : 50 CPU Load (%) : 0 Memory Load (%) : 28

Mobile gateway status of fpc slot: 4 pic slot: 1 State : Backup Active Subscribers : 50 Active Sessions : 50 Active Bearers : 50 CPU Load (%) : 0 Memory Load (%) : 28

You can see that there are 100 subscribers on the MX. They have been evenly load-balanced across two MS-DPC pics and they have been backed up against two more MS-DPC pics

Let’s take a quick look at the configuration and see how these results came to be. First, under the interfaces hierarchy:

Chapter6:Troubleshooting 89

ams0 { load-balancing-options { member-interface mams-2/0/0; member-interface mams-4/0/0; high-availability-options { many-to-one { preferred-backup mams-2/0/0; } } } } ams1 { load-balancing-options { member-interface mams-2/1/0; member-interface mams-4/1/0; high-availability-options { many-to-one { preferred-backup mams-4/1/0; } } } }

You can see that Mass Telecom has two Aggregated Multiservice (AMS) Interfaces configured, the MS-DPC PIC 2/0/0 and 4/0/0 as one AMS, and MS-DPC PIC 2/1/0 and 4/1/0 as the second AMS. Both 2/0/0 and 4/1/0 are backups.

The two Aggregated Multiservice interfaces are set under the [uni-fied-edge gateways ggsn-pgw Masst system] hierarchy:

system { pfes { interface apfe0; } session-pics { interface ams0; interface ams1; }}

The show unified-edge ggsn-pgw system interfaces gateway Masst command will show the different mobile interfaces, meaning the SPICs and APFEs. You can verify if the interface is in an operating state and if it is a primary or secondary.

root@GGSN-960> show unified-edge ggsn-pgw system interfaces gateway MasstGateway: Masst Interfaces Members Operational Redundancy State Role ams0 mams-2/0/0 Active Primary mams-4/0/0 Active Secondary ams1 mams-2/1/0 Active Primary mams-4/1/0 Active Secondary


apfe0 pfe-0/0/0 Active Primary pfe-1/0/0 Active Primary pfe-5/0/0 Active Secondary pfe-0/1/0 Active Primary pfe-1/1/0 Active Primary pfe-5/1/0 Active Secondary pfe-5/2/0 Active Secondary pfe-0/2/0 Active Primary pfe-1/2/0 Active Primary pfe-0/3/0 Active Primary pfe-1/3/0 Active Primary pfe-5/3/0 Active Secondary

Mass Telecom may have other MS-DPCs in this MX, but as far as their MBG configuration is concerned, they have just the two MS-DPCs and the four PICs between them in use for servicing mobile subscribers. As for the MPCEs, they have three in play, each having four PFEs. One of the MPCEs has been configured as a secondary to the other two MPCEs.

show unified-edge ggsn-pgw gtp peer detail

Here is another command that shows the current status with the GSN peers such as the SGSN, eNodeB, or SGW. The show unified-edge ggsn-pgw gtp peer detail command is very useful!

Peer Detail:---------------Remote IP Address : 155.100.1.11Local IP Address : 201.100.1.6Routing Instance : 6Interface Type : GnGTP Version : 1RCM Registration Done : yesRestart Counter Valid : yesRestart Counter Value : 1Sent Restart Counter Value : 3Control Path N3 Request : 3Control Path T3 Timer : 5Control Path Echo N3 Request : 8Control Path Echo T3 Timer : 15Control Path Echo Interval : 60Control Path Management Enabled : noControl Path State : not-trackedData Path Echo N3 Request : 8Data Path Echo T3 Timer : 15Data Path Echo Interval : 60Data Path Management Enabled : noData Path State : not-trackedGTP-C using Short Sequence Number : noDownlink data notif delay Interval : 0CSID Supported : no


show unified-edge ggsn-pgw statistics

The show unified-edge ggsn-pgwstatistics is a useful command that shows you how many sessions have been established, how many failed, and how much traffic has been sent….along with the data packets that have been discarded.

[edit unified-edge gateways ggsn-pgw Masst]root@GGSN-960# run show unified-edge ggsn-pgw statistics Control plane statistics: Session establishment attempts: 30 Successful session establishments: 5 MS/peer initiated session deactivations: 0 Successful MS/peer initiated deactivations: 0 Gateway initiated session deactivations: 0 Successful gateway initiated deactivations: 0Data plane GTP statistics (Gn/S5/S8): Input packets: 587322 Input bytes: 75177216 Output packets: 31968 Output bytes: 4091904 Discarded packets: 0 Data plane GTP statistics (Gi): Input packets: 31968 Input bytes: 4091904 Output packets: 587322 Output bytes: 75177216 Discarded packets: 60976

As you can see here, 30 GTP-C sessions have been attempted and only five have succeeded. Plus the Gi interface has discarded some packets so there is a problem that needs to be examined. You can also see that no subscribers have deactivated yet.

show unified-edge ggsn-pgw charging path status

Troubleshooting the Charging Gateway is something you may have to do several times, if only because it’s connected to revenue. Run show unified-edge ggsn-pgw charging path status to make sure the status is connected, like this:

Charging Path StatusPeer-Addr Peer-Name Local-Address Status Echo10.3.219.32 ChargingOne 10.3.219.72 Connected EnabledShow unified-edge ggsn-pgw charging path statistics

Now, if you run show unified-edge ggsn-pgw charging path statis-tics you'll get the nitty gritty:


Charging Path Statistics

CGF Address : 10.3.219.32 CGF Server Name : ChargingOne Echo Requests Rx: 0 Echo Responses Tx: 0 Echo Responses Rx: 11 Echo Requests Tx: 19 Node-Alive Requests Rx: 1 Node-Alive Responses Tx: 1 Version Not Supported Rx: 0 Version Not Supported Tx: 0 Echo Requests timed out : 8 Echo Interval : 60 Down Detection Interval : 10 Reconnect Time Interval : 60 Destination Port : 3386 Pending Queue Size : 0 Path Manager FPC Slot : 4 Path Manager PIC Slot : 0 T3 Response Time Interval : 5 Path Manager Port : 30275 Source Interface Valid : Yes GTPP Header Type : long N3 Requests : 3 Local Address : 10.3.219.72 GTPP Version : V0 Transport Protocol : UDP

A few things to notice that are bolded: the NodeAlive request response is a good indication that things are working between the two nodes. There are a few Echo Requests that timed out. You can see the MBG is using GTPPv0 over UDP, and you can see that the Path Manager Port is 30275, which means Echo Requests and responses should use that as the source port (Data Record Transfer Requests will use port 30276 as the source port).

show unified-edge ggsn-pgw subscribers

The show unified-edge ggsn subscribers command is a useful one to see the state of an active subscriber on the MBG. Since the system can be managing millions of subscribers based on the MS-DPC and MPCE card loadout we also have a slew of options to allow you to see what types of subscribers are on the box and to narrow down which sub-scriber types you may want to view out of that potential 8 million.

root@GGSN-960# run show unified-edge ggsn-pgw subscribers ? Possible completions: <[Enter]> Execute this command apn Show subscribers for an APN brief Display brief output (default) charging Show subscribers for charging attribute detail Display detailed output extensive Display extensive output fpc-slot FPC slot number gateway Show subscribers for a gateway gtp-version GTPC version number (0..2) gtpv1-arp Show subscribers for specific GTPv1 ARP (1..3) gtpv2-priority-level Show subscribers for specific GTPv2 priority level imsi Show subscribers for specific imsi msisdn Show subscribers for specific msisdn pdn-type Show subscribers by PDN-Type peer Show subscribers for specific peer pic-slot PIC slot number


qci Show subscribers for specific qci (1..9) roaming-status Show subscribers by roaming-status routing-instance Name of routing instance services Show subscribers by services session-state Show subscribers by state traffic-class Show subscribers at traffic class level v4-addr Show subscribers for matching address v6-addr Show subscribers for matching address

Here is an example displaying just the count, or number of GTPv1 suscribers, who have a PDP Context activated with an ARP value of 1:

root@GGSN-960# run show unified-edge ggsn-pgw subscribers gtpv1-arp 1 | count Count: 15011 lines

The show unified-edge ggsn-pgw subscribers command can show quite a bit about about a subscriber’s session when you use the detail or extensive option (extensive shows you the most information).

root@GGSN-960# run show unified-edge ggsn pgw subscribers imsi 50502410174467 extensive Subscriber Information: IMSI: 50502410174467 IMEI: None MSISDN: 17962533101 Time Zone: GMT (DST): None RAT Type: Unknown Status: Roamer MCC: None MNC: None LAC: 0x0 CI: 0x0 SAC: 0x0 RAC: 0x0 TAC: 0x0 ECI: 0x0 PDN Session: APN name: masst.com IPv4 Address: 16.2.2.145 IPv6 Address: None GTP Version: 1 Session Duration: 22:26:36 Local Control address: 201.100.1.6 Remote Control address: 201.100.1.13 TEID Control Local: 0xc00f8c5 TEID Control Remote: 0xcee1 Addressing scheme: Local Selection mode: sub verified Session PIC: 2 /1 (FPC/PIC) Anchor PFE: 0 /0 (FPC/PIC) Service PIC: None/None (FPC/PIC) Session State: Established Direct Tunnel: Disabled Serving network: MCC: None MNC :None Bearer: Bearer: NSAPI/EBI: 5 Charging ID: 0xc007cc5 Local Data address: 201.100.1.6 Remote Data address: 201.100.1.13 Local TEID: 0x3422e5 Remote TEID: 0xd2c8 Bearer State: Established Substate: - Idle Timeout: 0 min(0 -0,0) AAA Interim Interval: 10 min(10-0,0) Negotiated QoS Parameters: Traffic Class:Conversational ARP: 1 Traffic Handling Priority:1 Transfer Delay: 10 MBR Uplink: 1 kbps MBR Downlink: 1 kbps GBR Uplink: 1 kbps GBR Downlink: 1 kbps Signaling Indicator: 0 Forwarding Class: None Loss Priority: None


Requested QoS Parameters: Traffic Class: Conversational ARP: 1 Traffic Handling Priority: 1 Transfer Delay: 10 MBR Uplink : 1 kbps MBR Downlink: 1 kbps GBR Downlink: 1 kbps GBR Downlink: 1 kbps Signaling Indicator: 0 Charging information: Profile ID: 0 State: Ready Previous State: Accounting Profile selection criteria: - Details: Accounting enabled Offline charging information: Disabled Rating group information: Rating group: 0 Service id: 0 Action ID: 0x1007cc5 Trigger profile: 0 Change condition bitmask: 0x0 Action-id-bitmask: 0x0 Signal bitmask: 0x0 Last signal bitmask: 0x0 Details: Bearer trigger Collection time: Tue Apr 10 22:00:12 2012 Uplink packets: 0 Downlink packets : 0 Uplink bytes: 0 Downlink bytes : 0

Now, let’s use a show command to help explain a question. Mass Telecom asks “Why are all the subscribers being sent to the same APFE(Anchor PFE)?” They feel there are multiple primary APFEs in the system. We will answer this and then use the show unified-edge ggsn subscribers command to show you the truth.

So, if you have a great memory, you will remember from earlier in the book the first choice of APFE is given by the SPIC to the PFE that is the Egress PFE to reach the peer of the session. In this example let’s say the peer is a SGSN. Remember the APFE is chosen like this to minimize the number the of times the fabric has to be traversed.

So we have 19 subscribers active on the MBG, and they all come from the same SGSN in our example. The SGSN is connected to an inter-face on FPC 1.

[edit chassis]root@GGSN-960# run show unified-edge ggsn-pgw subscribers extensive | match "anchor" Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC)


Session PIC: 2 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 4 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 4 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 4 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC) Session PIC: 4 /0 (FPC/PIC) Anchor PFE: 1 /0 (FPC/PIC)

Since each PFE can manage 500,000 subscribers before its resources are exhausted, you would only see sessions start to be distributed to other APFEs in the system if you brought up more than 500,000 sessions from the same SGSN.

show unified-edge ggsn-pgw ip-reassembly statistics

No one wants fragmented GTP packets, but it happens. Now we need to reassemble GTP packets so the system knows how to steer the packet internally. For fragmented GTP packets, the MBG cannot tell a GTPc packet from a GTPu packet, what the GTP packet type is, or what the IMSI may be until reassembly is completed. If you want to see if GTP reassembly is occurring on the system, run the show unified-edge ggsn-pgw ip-reassembly statistics command. It will show you the number of GTP packets that have been reassembled since the GTP statistics were last cleared and it will tell you if the system has dropped any fragmented GTP packets.

root@GGSN-960# run show unified-edge ggsn-pgw ip-reassembly statistics Gateway: MasstIP reassembly statistics: First fragments: 507526 Non-first fragments: 507524 Total fragments: 1015050 Reassembled packets: 507524 Merged packets: 507523 Packets pending reassembly: 2 Timed out packets: 0 Timed out fragments: 0 Exceeded maximum packet length:0Fragments Dropped: Invalid length: 0 Overlap: 0 Duplicate: 0 No buffers: 0 Packet limit exceeded: 0 Total fragments dropped: 0

clearing statistics

A quick word on clearing statistics since this action may be required during the maintenance of the MBG. A system administrator can clear statistics for several mobile applications such as AAA and Charging. They may dig down and clear statistics for a whole gateway or even


individual APNs. There is quite a bit of flexibility on what you can clear since Juniper knows end users may need to clear statistics for certain functionalities yet keep the statistics for others so they can see what has occurred over the lifetime of the box versus what has occurred recently. Lifetime of the box in this context is considered the system uptime.

root@GGSN-960# run clear unified-edge ggsn-pgw ? Possible completions: aaa Clear information related to AAA address-assignment Clear information related to address assignment charging Clear information related to charging gtp Clear Information related to GTP ip-reassembly Clear information related to IP reassembly statistics Clear statistics subscribers Clear subscribersroot@GGSN-960# run clear unified-edge ggsn-pgw gtp statistics gtp-all gateway MASST root@GGSN-960# run clear unified-edge ggsn-pgw gtp statistics ?Possible completions: fpc-slot FPC slot number gateway Clear statistics for a gateway gtp-all GTP all version statistics gtp-v0 GTP version 0 statistics gtp-v1 GTP version 1 statistics gtp-v2 GTP version 2 statistics pic-slot PIC slot number

Logs!

There are a few different control points in the Junos code that you should care about when it comes to enabling logging for that given section. Let’s differentiate between them so you know which section of the configuration is configured to enable that given log file. Note that aside from the call trace feature we will show you, it is not recommended to run the logs we will show you when in production.

GTP Logging

Go under the [edit unified-edge gateways ggsn-pgw Masst gtp] hierarchy:

traceoptions { file masst_gtp.log size 50m; level all; flag all;}

Gateway Logging

Go under the [edit unified-edge gateways ggsn-pgw Masst] hierarchy:


traceoptions { file masst_gateway.log size 50m; level all; flag all;}

Charging Logging

Go under the [edit unified-edge gateways ggsn-pgw Masst charg-ing] hierarchy:

traceoptions { file masst_charging.log size 50m; level all; flag all;}

AAA Logging

Go under the [edit unified-edge aaa] hierarchy:

traceoptions { file masst_aaa.log size 50m; level all; flag all;}

If you must enable these logs in production, set the level and flag to error first. If that is not sufficient, then try the debug all option.

When looking in the /var/logs directory, or wherever you decide to store the logs, the mobile application log filenames will have the MS-DPC slot/pic number for the SPIC that handled the processing of the subscriber appended, as shown here:

-rw-r--r-- 1 root wheel 532492 Jan 4 18:03 charging_log-ms40-rw-r--r-- 1 root wheel 6693 Jan 4 18:03 Masst_ue.log-ms41-rw-r--r-- 1 root wheel 36992 Jan 4 18:03 Masst_ue.log-ms40-rw-r--r-- 1 root wheel 17386646 Jan 4 18:03 Masst_ue.log-ms21-rw-r--r-- 1 root wheel 37838702 Jan 4 18:03 Masst_ue.log-ms20-rw-r--r-- 1 root wheel 344285 Jan 4 18:04 charging_log-ms20-rw-r--r-- 1 root wheel 71288 Jan 4 18:04 masst_gateway.log-ms41-rw-r--r-- 1 root wheel 40109045 Jan 4 18:04 masst_gateway.log-ms40-rw-r--r-- 1 root wheel 480053 Jan 4 18:04 masst_gateway.log-ms21-rw-r--r-- 1 root wheel 6511171 Jan 4 18:04 masst_gateway.log-ms20

Call Trace

The call trace functionality allows you to log all events for a specific IMSI or MSISDN without having to enable the GTP traceoptions. You can run several traces for different IMSI/MSISDNs at the same time:

root@GGSN-960> request unified-edge ggsn-pgw call-trace start imsi 101313783444554 Service PIC Status ms-0/0/0 success ms-10/0/0 success


Here is the command to monitor the trace being run:

root@GGSN-960> request unified-edge ggsn-pgw call-trace show detail Call trace information : Identifier : call_trace_id_1 Trace file : call_trace_id_1_01142012_152946 Status : not-done Create Mask : 0x44 Complete Mask : 0x0 IMSI : 244212003476097 Calls Traced : 0

Here is where you stop the trace. If you have more than one trace running use the all command to stop them all if you need to.

root@GGSN-960> request unified-edge ggsn-pgw call-trace stop all Service PIC Status ms-10/0/0

root@GGSN-960> request unified-edge ggsn-pgw call-trace show Identifier File name Status SPIC Mask SPIC Mask create complete call_trace_id_1 call_trace_id_1_01142012_152946 done 0x44 0x44 {master}

Like all the other files this one will be stored in /var/log. Here is a snippet from log file call_trace_id_1_01142012_152946 showing a PDP Conext being rejected due to an authentication failure. Now, if this call trace was being run for an IMSI that belonged to a subscriber who was complaining that they could not get data service, this is a great place to start. It allows you to see data focused on a single subscriber. In this case, you can start tracing down the issue to see if RADIUS is failing the subscriber for some reason:

Dec 5 16:12:30.1118022 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: Encoding GTP V1 Header Dec 5 16:12:30.1118044 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: Msg Type 17 SeqNumber 584 TEID 302149215Dec 5 16:12:30.1118067 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: Encoding CAUSE IEDec 5 16:12:30.1118088 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: Encoding cause Authentication failureDec 5 16:12:30.1118109 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: ERROR: Non successful cause value(208) sentDec 5 16:12:30.1118131 cpu_id: [6] gtid: [9] tid: [2] app_id: 1 Encode: ENCODED Error Response of length 14 for msg 17

Nov 26 16:20:53.1327494 cpu_id: [5] gtid: [8] tid: [1] app_id: 1 change reporting action not supportedNov 26 16:20:53.1327997 cpu_id: [5] gtid: [8] tid: [1] app_id: 1 Handler returned PASSNov 26 16:20:53.1328020 cpu_id: [5] gtid: [8] tid: [1] app_id: 1 calling afProcessEvent for event=sessUpdate, state=EstablishedNov 26 16:20:53.1328042 cpu_id: [5] gtid: [8] tid: [1] app_


id: 1 i = 0, size = 1, evtProtocolBitmap = 19 info->cause = 0, info->sub_cause = 0Nov 26 16:20:53.1328068 cpu_id: [5] gtid: [8] tid: [1] app_id: 1 calling session-evt handler #0 for state=Established, event=sessUpdate info->cause = 0, info->subcause=0, num_handlers=1

Let’s take a look at some common issues that may be seen in the log files next.

Error: Subscriber Rejected, No Resources Available

Solving issues like this one that may come with scale requires some expert logging troubleshooting. Let’s diverge for a second. Remember GTP logs and Call Trace logs capture information related to the GTP service running on the MS-DPCs. As we stated a few pages back, GTP logs are enabled under the [unified-edge gateways ggsn-pgw Masst gtp] hierarchy, but Juniper recommends you only use the logs when the MBG is not in production:

traceoptions { file Masst_GTP.log size 50m; level all; flag all;}

In the following abridged example from a GTP log, you can see a GTP V1 message type 16 (Create PDP Context Request) that indicates a new subscriber’s bearer request is being sent to the MBG from a SGSN. The error message found at the tail end of the log Encode: Encoding cause No resources available indicates that the MBG was unable to assign an IP address to the subscriber. Take a look:

Jul 14 13:15:46.1218151 gtid: [0] tid: [0] Debug: gtp_dispatcher_parse_rx_pkt is calledJul 14 13:15:46.1219417 gtid: [16] tid: [9] Debug: gtp_preparse_rx_pkt is calledJul 14 13:15:46.1219493 gtid: [16] tid: [9] Debug: gtp_preparse_rx_pkt is complete(success) version(1) msg_type(16)Jul 14 13:15:46.1219609 gtid: [16] tid: [9] Debug: gtp_fullparse_rx_pkt is calledJul 14 13:15:46.1221288 gtid: [16] tid: [9] Decode: Parsing GTPV1 Header Jul 14 13:15:46.1221373 gtid: [16] tid: [9] Track: Rcvd GTPv1 msg type 16 in vrf 6 from pfe-id 20 vpfe-id 0Jul 14 13:15:46.1221457 gtid: [16] tid: [9] ReqTrack: V1 msg 16 Not a redirected responseJul 14 13:15:46.1221534 gtid: [16] tid: [9] ReqTrack: V1 msg 16 Not a tracked responseJul 14 13:15:46.1221620 gtid: [16] tid: [9] Track: Received message len 95Jul 14 13:15:46.1221842 gtid: [16] tid: [9] Track: 32 10 00 57 00 00 00 00 00 04 00 00 02 21 43 65 87 49 06 63 Jul 14 13:15:46.1222027 gtid: [16] tid: [9] Track: f0 0e 01 0f 00 10 00 00 01 05 11 00 00 01 06 14 05 1a 08 00 Jul 14 13:15:46.1222195 gtid: [16] tid: [9] Track: 80 00 02 f1 21 83 00 0a 05 6d 61 73 73 74 03 63 6f 6d 85 00 Jul 14 13:15:46.1222387 gtid: [16] tid: [9] Track: 04 0a 03 db 20 85 00 04 0a 03 db 20 86 00 05 91 62 37 77 84 Jul 14 13:15:46.1222501 gtid: [16] tid: [9] Track: 87 00 0c 01 22 72 0a 73 96 48 48 76 07 48 48


Jul 14 13:15:46.1222572 gtid: [16] tid: [9] Decode: Parsing GTPv1 Create PDP Request MessageJul 14 13:15:46.1222606 gtid: [16] tid: [9] Decode: Parsing GTP IE IMSI (2)Jul 14 13:15:46.1222636 gtid: [16] tid: [9] Decode: IMSI 123:45:6789460360Jul 14 13:15:46.1222664 gtid: [16] tid: [9] Decode: Parsing GTP IE RECOVERY (14)Jul 14 13:15:46.1222693 gtid: [16] tid: [9] Decode: Recovery (Restart Counter) Value = 1Jul 14 13:15:46.1222721 gtid: [16] tid: [9] Decode: Parsing GTP IE SELECTION_MODE (15)Jul 14 13:15:46.1222751 gtid: [16] tid: [9] Decode: Selection Mode IE Value 0Jul 14 13:15:46.1222779 gtid: [16] tid: [9] Decode: Parsing GTP IE ITEID_DATA (16)Jul 14 13:15:46.1222812 gtid: [16] tid: [9] Decode: TEID Value 261 Jul 14 13:15:46.1222840 gtid: [16] tid: [9] Decode: Parsing GTP IE TEID_SIG (17)Jul 14 13:15:46.1222869 gtid: [16] tid: [9] Decode: TEID Value 262 Jul 14 13:15:46.1222896 gtid: [16] tid: [9] Decode: Parsing GTP IE NSAPI_IE (20)Jul 14 13:15:46.1222924 gtid: [16] tid: [9] Decode: NSAPI Value 5Jul 14 13:15:46.1222951 gtid: [16] tid: [9] Decode: Parsing GTP IE CHARGING_CHAR (26)Jul 14 13:15:46.1222980 gtid: [16] tid: [9] Decode: Charging Characteristics value 0800Jul 14 13:15:46.1223010 gtid: [16] tid: [9] Decode: Parsing GTP IE END_USER_ADDR (128)Jul 14 13:15:46.1223040 gtid: [16] tid: [9] Decode: Parsing GTP IE APN (131)Jul 14 13:15:46.1223073 gtid: [16] tid: [9] Decode: Received APN masst.com Jul 14 13:15:46.1223115 gtid: [16] tid: [9] Decode: Parsing GTP IE GSN_ADDRESS (133)Jul 14 13:15:46.1223147 gtid: [16] tid: [9] Decode: GSN Addr 10.3.219.32Jul 14 13:15:46.1223527 gtid: [16] tid: [9] Decode: GSN Addr 10.3.219.32Jul 14 13:15:46.1223566 gtid: [16] tid: [9] Decode: Parsing GTP IE MSISDN (134)Jul 14 13:15:46.1223599 gtid: [16] tid: [9] Decode: MSISDN IE, length 4 TBCD 2673774800000000Jul 14 13:15:46.1223631 gtid: [16] tid: [9] Decode: Parsing GTP IE QOS_V1_PROFILE (135)Jul 14 13:15:46.1223660 gtid: [16] tid: [9] Decode: Decoding V1 Qos IE Jul 14 13:15:46.1223692 gtid: [16] tid: [9] Decode: QOS: delay = 4, reliability = 2,peak_throughput = 7, precedence_class = 2,mean_throughput = 10, traffic_class = 3, delvry_order = 2, del_err_sdu = 3,max_sdu_size = 150, max_bitrate_uplink = 72,max_bitrate_downlink = 72, residual_ber = 7, sdu_err_ratio = 6, transfer_delay = 1,traffic_handl_priority = 3, guaranteed_bitrate_uplink = 72,guaranteed_bitrate_downlink = 72 Jul 14 13:15:46.1223746 gtid: [16] tid: [9] Decode: GTPV1 Packet successfully decodedJul 14 13:15:46.1248436 gtid: [15] tid: [8] Encode: Encoding GTP V1 Header Jul 14 13:15:46.1248464 gtid: [15] tid: [8] Encode: Msg Type 17 SeqNumber 4 TEID 262Jul 14 13:15:46.1248491 gtid: [15] tid: [8] Encode: Encoding CAUSE IEJul 14 13:15:46.1248517 gtid: [15] tid: [8] Encode: Encoding cause No resources availableJul 14 13:15:46.1248544 gtid: [15] tid: [8] Encode: ERROR: Non successful cause value(199) sentJul 14 13:15:46.1248573 gtid: [15] tid: [8] Encode: ENCODED Error Response of length 14 for msg 17Jul 14 13:15:46.1248612 gtid: [15] tid: [8] Track: Sending message len 42Jul 14 13:15:46.1248668 gtid: [15] tid: [8] Track: 45 c0 00 2a 00 03 00 00 ff 11 ef de 0a 03 db fa 0a 03 db 20 Jul 14 13:15:46.1248728 gtid: [15] tid: [8] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00 00 01 06 00 04 00 00 Jul 14 13:15:46.1248759 gtid: [15] tid: [8] Track: 01 c7

The cause of the error message can be several things. First, let’s check to see if it is an IP pool resource issue.


1. The MBG was misconfigured and does not have an access > address assignment > mobile pools setup, or it can also mean you do have the access > address assignment > mobile pools set up, but it may be in maintenance mode.

The show unified-edge ggsn-pgw address-assignment service-mode command will let you know what mode each pool is in:

Routing-Instance Pool Name Service ModeGI_VR MassT-Pool-1 Operational GI_VR default Operational GI_VR roamer Operational

2. It could be the IP POOL(s) you have configured on the MBG have a different range than the IP Pool being used by the RADIUS server (if the APN in use uses RADIUS for authentication and for assigning IP address). Remember, even if the RADIUS server is assigning the IP addresses, Junos needs to map that to an internal pool resource.

3. The cause of this message could also be the UE sending over an IP address that it wants to use, but the APN is not configured to allow user assigned IP addresses. Here is where you would add the capability in the MBG configuration so that the UEs could statically assign their IP Address:

unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]address-assignment { allow-static-ip-address;}

If these three possible scenarios are not the cause of the issue, then you may have run out of IP addresses, meaning the pool is truly exhausted. Remember to run the show unified-edge ggsn-pgw address-assign-ment pool command to see what the state of the pool is resource wise:

root@GGSN-960> show unified-edge ggsn-pgw address-assignment pool Pool: MassT-Pool-1 Total addresses: 262142 Addresses in use: 109 Addresses skipped: 0 Address usage (percent): 0 Addresses in aging period: 0 Routing instance: GI_VR

Pool: default Total addresses: 254 Addresses in use: 0 Addresses skipped: 0 Address usage (percent): 0 Addresses in aging period: 0 Routing instance: GI_VR

Pool: roamer


Total addresses: 16777214 Addresses in use: 14224 Addresses skipped: 0 Address usage (percent): 0. Addresses in aging period: 0 Routing instance: GI_VR

Now if the pools are not the problem you need to ask yourself: What is going on when a subscriber gets rejected due to lack of available resources on the MBG, even though the system has plenty of IP addresses available?

You should check other resources on the MBG. Remember all those policies you created under [unified-edge coscac] such as the total number of bearers you are allowing, or the threshold settings you may have applied? You can set the bearer total at the gateway level and lower at the individual APN level. Let’s see what Mass Telecom has set:

root@GGSN-960> show configuration unified-edge gateways ggsn-pgw Masst maximum-bearers maximum-bearers 2000000;root@GGSN-960> show configuration unified-edge gateways ggsn-pgw Masst apn-services apns masst.com maximum-bearers maximum-bearers 1500000;

And you can check the Threshold configuration here:

root@GGSN-960> show unified-edge cos-cac resource-threshold-profiles Masst_threshold memory low { percentage 30; gtpv1-arp 3;}high { percentage 35; gtpv1-arp 2;}

Now you can run the show unified-edge ggsn-pgw status detail command to see if you have exceeded your maximum-bearer settings or if you have exceeded the cos-cac thresholds.

Gateway: MASST Mobile gateway status:

FPC SLOT: 2 PIC SLOT: 0 State : Active Active Subscribers : 7101 Active Sessions : 7101 Active Bearers : 7101 CPU Load (%) : 2 Memory Load (%) : 31 Mobile gateway status:

FPC SLOT: 2 PIC SLOT: 1


State : Active Active Subscribers : 7123 Active Sessions : 7123 Active Bearers : 7123 CPU Load (%) : 0 Memory Load (%) : 31 Mobile gateway status:

FPC SLOT: 4 PIC SLOT: 0 State : Backup Active Subscribers : 7101 Active Sessions : 7101 Active Bearers : 7101 CPU Load (%) : 2 Memory Load (%) : 31 Mobile gateway status:

FPC SLOT: 4 PIC SLOT: 1 State : Backup Active Subscribers : 7123 Active Sessions : 7123 Active Bearers : 7123 CPU Load (%) : 0 Memory Load (%) : 31

To complete the overview of the ‘Encoding cause No resources avail-able’ message, let’s see what the gateway logs shows when it is encoun-tered in the GTP log.

Here is what you might see in the gateway log if the IP address was sent successfully from the RADIUS Server to the MX, but the Mobile-Pools on the MBG have a different range, or are not set up with the external-assigned flag, so the PDP Context is rejected:

Jul 15 14:56:39.1405937 gtid: [15] tid: [8] Enter evthdl acquire_addressJul 15 14:56:39.1405999 gtid: [15] tid: [8] External address verification: pdn type - 1, source - 2, daf - 0, cause - 0, addr[0] - 15.1.194.25, addr[1] - 0:0:0:0:0:0:0:0Jul 15 14:56:39.1406119 gtid: [15] tid: [8] LAM Assign : lam_find_chunk_in_tree.3983: <<<<< Chunk: 0x5a5b8c6b8, Start IP: 15.1.192.0, Cnt: 1024Jul 15 14:56:39.1406200 gtid: [15] tid: [8] smd_verify_external_address:2275 pfe_index=129Jul 15 14:56:39.1406368 gtid: [15] tid: [8] LAM Assign : lam_find_chunk_in_tree.3983: <<<<< Chunk: 0x5a5b8c6b8, Start IP: 15.1.192.0, Cnt: 1024Jul 15 14:56:39.1406461 gtid: [15] tid: [8] LAM Assign : verify_addr.4138: >>>>> cb_data: 0xd000003, ds_info: 0x0Jul 15 14:56:39.1406564 gtid: [15] tid: [8] LAM Assign : verify_addr.4345: <<<<< err: 12Jul 15 14:56:39.1406728 gtid: [15] tid: [8] smd_verify_external_address:2338 - LAM status: 12, AppFW cause code: AF_IP_ADDR_UNAVAIL (28)Jul 15 14:56:39.1406784 gtid: [15] tid: [8] Handler returned ERROR

Notice the bolded items.


And this is what you would see in the gateway log if the pool that had the range 15.0.0.0/14 was in maintenance mode:

Aug 4 22:08:20.711296 gtid: [12] tid: [6] Enter evthdl acquire_addressAug 4 22:08:20.711315 gtid: [12] tid: [6] External address verification: pdn type - 1, source - 2, daf - 0, cause - 0, addr[0] - 15.0.0.8, addr[1] - 0:0:0:0:0:0:0:0Aug 4 22:08:20.711353 gtid: [12] tid: [6] LAM Assign : lam_find_chunk_in_tree.4009: <<<<< Chunk: 0x0, Start IP: (null), Cnt: 0Aug 4 22:08:20.711380 gtid: [12] tid: [6] smd_verify_external_address:2284 pfe_index=130Aug 4 22:08:20.711407 gtid: [12] tid: [6] LAM Assign : lam_find_chunk_in_tree.4009: <<<<< Chunk: 0x0, Start IP: (null), Cnt: 0Aug 4 22:08:20.711432 gtid: [12] tid: [6] LAM Assign : lam_find_addr_in_pool_prefix_tree.3931: >>>>> Searching for: 15.0.0.8Aug 4 22:08:20.711458 gtid: [12] tid: [6] smd_verify_external_address:2347 - LAM status: 42, AppFW cause code: AF_NO_SERVICE (5)Aug 4 22:08:20.711482 gtid: [12] tid: [6] Handler returned ERRORError: Encoding cause Missing or unknown APN

Another example of a key logging message is a GTP log showing a subscriber come in with an APN that is not locally configured on the MBG:

Jul 18 11:23:28.1566469 gtid: [0] tid: [0] Debug: gtp_dispatcher_parse_rx_pkt is calledJul 18 11:23:28.1567471 gtid: [8] tid: [1] Debug: gtp_preparse_rx_pkt is calledJul 18 11:23:28.1567556 gtid: [8] tid: [1] Debug: gtp_preparse_rx_pkt is complete(success) version(1) msg_type(16)Jul 18 11:23:28.1567687 gtid: [8] tid: [1] Debug: gtp_fullparse_rx_pkt is calledJul 18 11:23:28.1568041 gtid: [8] tid: [1] Decode: Parsing GTPV1 Header Jul 18 11:23:28.1568106 gtid: [8] tid: [1] Track: Rcvd GTPv1 msg type 16 in vrf 6 from pfe-id 20 vpfe-id 0Jul 18 11:23:28.1568151 gtid: [8] tid: [1] ReqTrack: V1 msg 16 Not a redirected responseJul 18 11:23:28.1568215 gtid: [8] tid: [1] ReqTrack: V1 msg 16 Not a tracked responseJul 18 11:23:28.1568291 gtid: [8] tid: [1] Track: Received message len 101Jul 18 11:23:28.1568437 gtid: [8] tid: [1] Track: 32 10 00 5d 00 00 00 00 00 0b 00 00 02 21 43 65 87 49 75 03 Jul 18 11:23:28.1568644 gtid: [8] tid: [1] Track: f0 0e 01 0f 00 10 00 00 01 fa 11 00 00 01 fb 14 05 1a 08 00 Jul 18 11:23:28.1568771 gtid: [8] tid: [1] Track: 80 00 06 f1 21 0a 0a 0a 01 83 00 0b 06 40 6d 61 73 73 74 03 Jul 18 11:23:28.1568941 gtid: [8] tid: [1] Track: 63 6f 6d 85 00 04 0a 03 db 20 85 00 04 0a 03 db 20 86 00 06 Jul 18 11:23:28.1569102 gtid: [8] tid: [1] Track: 71 18 23 12 68 f2 87 00 0c 01 22 72 0a 73 96 48 48 76 07 48 Jul 18 11:23:28.1569162 gtid: [8] tid: [1] Track: 48 Jul 18 11:23:28.1569234 gtid: [8] tid: [1] Decode: Parsing GTPv1 Create PDP Request MessageJul 18 11:23:28.1569291 gtid: [8] tid: [1] Decode: Parsing GTP IE IMSI (2)Jul 18 11:23:28.1569367 gtid: [8] tid: [1] Decode: IMSI 123:45:6789457300.........Jul 18 11:23:28.1570845 gtid: [8] tid: [1] Decode: Missing or Unknown APN @masst.com.


Jul 18 11:23:28.1570873 gtid: [8] tid: [1] Decode: GTPV1 Packet Decoding Unsuccessful Cause 219Jul 18 11:23:28.1570904 gtid: [8] tid: [1] Decode: fullparse: Parse error version(1) cause(219)Jul 18 11:23:28.1570941 gtid: [8] tid: [1] Encode: Encoding GTP V1 Header Jul 18 11:23:28.1570968 gtid: [8] tid: [1] Encode: Msg Type 17 SeqNumber 11 TEID 507Jul 18 11:23:28.1571001 gtid: [8] tid: [1] Encode: Encoding CAUSE IEJul 18 11:23:28.1571028 gtid: [8] tid: [1] Encode: Encoding cause Missing or unknown APNJul 18 11:23:28.1571056 gtid: [8] tid: [1] Encode: ERROR: Non successful cause value(219) sentJul 18 11:23:28.1571085 gtid: [8] tid: [1] Encode: ENCODED Error Response of length 14 for msg 17Jul 18 11:23:28.1571124 gtid: [8] tid: [1] Track: Sending message len 42Jul 18 11:23:28.1571185 gtid: [8] tid: [1] Track: 45 c0 00 2a 00 05 00 00 ff 11 ef dc 0a 03 db fa 0a 03 db 20 Jul 18 11:23:28.1571242 gtid: [8] tid: [1] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00 00 01 fb 00 0b 00 00 Jul 18 11:23:28.1571275 gtid: [8] tid: [1] Track: 01 db Jul 18 11:23:28.1571340 gtid: [8] tid: [1] ReqTrack: Parse error spad type 2 not trackedJul 18 11:23:28.1571385 gtid: [8] tid: [1] Debug: gtp_fullparse_rx_pkt is complete(error)

}

Error: Encoding Cause Authentication Failure

The following GTP log looks fine until you get to the “Encoding Cause Authentication Failure” message. So you look at the RADIUS Server and see no requests reach it. In fact, a trace on the network shows the MBG is not even sending a RADIUS request:

Jul 20 10:30:13.1700517 gtid: [0] tid: [0] Debug: gtp_dispatcher_parse_rx_pkt is calledJul 20 10:30:13.1701947 gtid: [11] tid: [4] Debug: gtp_preparse_rx_pkt is calledJul 20 10:30:13.1702003 gtid: [11] tid: [4] Debug: gtp_preparse_rx_pkt is complete(success) version(1) msg_type(16)Jul 20 10:30:13.1702134 gtid: [11] tid: [4] Debug: gtp_fullparse_rx_pkt is calledJul 20 10:30:13.1702302 gtid: [11] tid: [4] Decode: Parsing GTPV1 Header Jul 20 10:30:13.1702371 gtid: [11] tid: [4] Track: Rcvd GTPv1 msg type 16 in vrf 6 from pfe-id 20 vpfe-id 0Jul 20 10:30:13.1702442 gtid: [11] tid: [4] ReqTrack: V1 msg 16 Not a redirected responseJul 20 10:30:13.1702510 gtid: [11] tid: [4] ReqTrack: V1 msg 16 Not a tracked responseJul 20 10:30:13.1702580 gtid: [11] tid: [4] Track: Received message len 95Jul 20 10:30:13.1702668 gtid: [11] tid: [4] Track: 32 10 00 57 00 00 00 00 00 02 00 00 02 21 43 65 87 49 26 19 Jul 20 10:30:13.1702774 gtid: [11] tid: [4] Track: f0 0e 01 0f 00 10 00 00 00 ff 11 00 00 01 00 14 05 1a 08 00 Jul 20 10:30:13.1702846 gtid: [11] tid: [4] Track: 80 00 02 f1 21 83 00 0a 05 6d 61 73 73 74 03 63 6f 6d 85 00 Jul 20 10:30:13.1702970 gtid: [11] tid: [4] Track: 04 0a 03 db 20 85 00 04 0a 03 db 20 86 00 05 91 62 37 77 85 Jul 20 10:30:13.1703075 gtid: [11] tid: [4] Track: 87 00 0c 01 22 72 0a 73 96 48 48 76 07 48 48


Jul 20 10:30:13.1703126 gtid: [11] tid: [4] Decode: Parsing GTPv1 Create PDP Request MessageJul 20 10:30:13.1703188 gtid: [11] tid: [4] Decode: Parsing GTP IE IMSI (2)Jul 20 10:30:13.1703256 gtid: [11] tid: [4] Decode: IMSI 123:45:6789462910.........Jul 20 10:30:13.1706551 gtid: [11] tid: [4] Decode: GTPV1 Packet successfully decodedJul 20 10:30:13.1706584 gtid: [11] tid: [4] Debug: gtp_fullparse_rx_pkt is complete(success)Jul 20 10:30:13.1708108 gtid: [11] tid: [4] Encode: Encoding GTP V1 Header Jul 20 10:30:13.1708133 gtid: [11] tid: [4] Encode: Msg Type 17 SeqNumber 2 TEID 256Jul 20 10:30:13.1708163 gtid: [11] tid: [4] Encode: Encoding CAUSE IEJul 20 10:30:13.1708188 gtid: [11] tid: [4] Encode: Encoding cause Authentication failureJul 20 10:30:13.1708216 gtid: [11] tid: [4] Encode: ERROR: Non successful cause value(208) sentJul 20 10:30:13.1708244 gtid: [11] tid: [4] Encode: ENCODED Error Response of length 14 for msg 17Jul 20 10:30:13.1708283 gtid: [11] tid: [4] Track: Sending message len 42Jul 20 10:30:13.1708341 gtid: [11] tid: [4] Track: 45 c0 00 2a 00 19 00 00 ff 11 ef c8 0a 03 db fa 0a 03 db 20 Jul 20 10:30:13.1708398 gtid: [11] tid: [4] Track: 08 4b 08 4b 00 16 00 00 32 11 00 06 00 00 01 00 00 02 00 00 Jul 20 10:30:13.1708429 gtid: [11] tid: [4] Track: 01 d0

Notice the bolded line in the log. Now check the configuration for the APN in use. You can see that the anonymous user is inactive within the APN.

[edit unified-edge gateways ggsn-pgw Masst apn-services apns masst.com]lab@GGSN-960# showlocal-policy-profile LOCAL_POLICY_MBG;apn-type real;apn-data-type ipv4;mobile-interface mif.16001;address-assignment { local; inet-pool { pool roamer; }}session-timeout 24;idle-timeout 60;aaa-profile AAA_profile;inactive: anonymous-user { user-name seamus; password "$9$ZcUk.fTz6Ct5T"; ## SECRET-DATA}selection-mode { from-ms;}

The UE and SGSNs are not sending any username/password creden-tials so the MBG will reject the session. Remember the MBG requires a


user name to be sent to the RADIUS server due to the nature of the RADIUS protocol.

Summary

There’s lots of troubleshooting skills in working with the logs. And there’s more help for you at Juniper when you get your MobileNext MBG up and running. So go get cracking on this Mobility solution. It’s awesome and easy to tweak.


What to Do Next and Where to Go

http://www .juniper .net/us/en/products-services/mobile-infrastructure/

These are the Juniper Mobile Infrastructure product portfolio pages.

http://www .juniper .net/us/en/products-services/mobile-infrastructure/packet-core/mobilenext-broadband-gateway/

For more information about the MobileNext Broadband Gateway.

http://www .juniper .net/us/en/local/pdf/datasheets/1000409-en .pdf

And here’s the MobileNext Broadband Gateway data sheet.

http://kb .juniper .net/InfoCenter/index?page=content&cat=MOBILENEXT_BROADBAND_GATEWAY&channel=KB&smlogin=true

This is the knowledge base link for the MobileNet Broadband Gate-way.

http://www.juniper.net/us/en/products-services/mobile-infrastructure/

http://www.juniper.net/us/en/products-services/mobile-infrastructure/packet-core/mobilenext-broadband-gateway/

http://www.juniper.net/us/en/products-services/mobile-infrastructure/packet-core/mobilenext-broadband-gateway/

http://www.juniper.net/us/en/local/pdf/datasheets/1000409-en.pdf

http://kb.juniper.net/InfoCenter/index?page=content&cat=MOBILENEXT_BROADBAND_GATEWAY&channel=KB&smlogin=true

http://kb.juniper.net/InfoCenter/index?page=content&cat=MOBILENEXT_BROADBAND_GATEWAY&channel=KB&smlogin=true

Deploying_MobileNext.pdf

Documents

Transcript of Deploying_MobileNext.pdf