Procedures that are frequently done benefit from a MOP by serving as a guideline for new engineers. Infrequently done procedures benefit by having a detailed reminder of what to, and not, do.

Read on for those details.

1    Procedure

1.     Copy all screen output to a file by activating putty terminal logging.
2.     Save a copy of the current PDSN configuration.
   [local]pdsn1# show configuration<CR>
3.     Delete and re-add IP Subpool
   [local]pdsn1# configure
[local]pdsn1(config)# context dest
[dest]pdsn1(config-ctx)# no ip pool evdo
[dest]pdsn1(config-ctx)# ip pool evdo 10.253.252.1 255.255.252.0 private 0
4.     Save new configuration to fileAfter configuration has been changed save the configuration.  See PDSN 05 NTP NN20000197.03.08 page 92 for full details of saving the configuration.
   [local]pdsn1(config)# save configuration /flash/production.18711.20080807.cfg <CR>

   Current files can be viewed using this command

   [local]pdsn1# dir /flash

5.     Set the new boot priority

Use the sequentially next smallest priority number based upon the output of the show boot command.

Use the same image as in the output of the show version command.

Use the configuration file from step 4)

[local]pdsn1(config)# boot system priority 8 image /flash/production.18711.st16.bin config /flash/production.18711.20080807.cfg <CR>

Exit the configuration mode.

[local]pdsn1(config)# end

6. 6)    After saving the changes, sync the files between the active and inactive PDSN cards.

[local]pdsn1(config)# card spc synchronize filesystem all <CR>

BACKOUT PROCEDURE

If a given change procedure fails here are steps to roll back to the stable configuration that existed prior to beginning the upgrade.

Enter configuration mode

[local]pdsn1# config<CR>

Delete the previously added pool called <pool name>.

[local]pdsn1(config)# no ip pool evdo<CR>

After data-fill changes:  If the shelf configuration is acceptable type the save configuration command:

[local]pdsn1(config)# save configuration /flash/system.20080807.cfg<CR>

After saving the changes, sync the files between the active and inactive cards.  The card spc synchronize command synchronizes the files to the standby SPC:

[local]pdsn1(config)# card spc synchronize filesystem all <CR>

END PROCEDURE

• Content Billing via bearer packet inspection
• Supported on PDSN for Simple IP, HA for Mobile IP
• Protocol Analyzers supported: HTTP, IP, TCP, UDP, WAP 1.x & 2.0, RTSP, RTP, POP3, MMS, SMTP, WTP,WSP, FTP, TFTP, ICMP, SIP, etc.
• integration with 3rd-party prepaid billing applications

Configuring ECS to analysyze these protocols uses a rules-based approach to instruct a protocol analyzer stack to evaluate a packet stream.  The resulting output can be piped to a charging engine that allows sophisticated actions to be taken against the stream, including interfacing with a prepaid billing application. The billing and accounting capability allows the operator to interface with a RADIUS or AAA server for finer control of network services.  An interface to the Camiant Policy Server is also supported.

An adjunct storage server also can be installed for longer term storage or to allow downstream applications to access the billing records produced by ECS.  Starent says deeper packet inspectio, into higher layers of the protocol stack, is on the product development roadmap for a future release.

The purpose of this Method Of Procedure (MOP) is to add ranges of IP Addresses, called “pools”, to the Starent 16000 PDSN. An IP address from an IP pool is assigned to a subscriber by the PDSN when a data session is initiated.

Procedure

Begin this procedure by creating a backup of the PDSN configuration file. Use the copy command to create a new configuration file.

[local]pdsn1# copy /flash/system.cfg /flash/system.backupfile.cfg <CR>

The file called system.backupfile.cfg is created as a contingency in the event a problem occurs during execution of this method.

Begin the actual procedure. Enter configuration mode.

[local]pdsn1# configure<CR>

Enter the context called dest.

[local]pdsn1 (config)# context dest<CR>

Enter the command to add the IP range.

[dest]pdsn1(config-ctx)# ip pool <pool> <start> <netmask> private 0

Where pool is the name you want to assign to this range of IP addresses, start is the first IP address in the range being added, and netmask is the netmask which describes the entire range being added.

For example, if 2 contiguous class C addresses are added, 10.252.254.0 and 10.252.255.0, use this command:

[dest]pdsn1(config-ctx)# ip pool <pool> 10.252.254.1 255.255.254.0 private 0<CR>

In this command private means the IP addresses will only be assigned from this pool to subscribers having an AAA profile which calls this pool.

This is the preferred form of this command because in addition to adding the pool correctly on the PDSN it also causes only a single entry to be created in the connecting router’s OSPF routes table.

There is another form of this command which uses the range option rather than a netmask. This other form is better avoided when possible because using it will cause the to create many entries in the connecting router’s OSPF routes table. Perhaps as many as 8 entries per class C address range. Use of this form cannot be avoided when the netmask cannot be created with contiguous set bit positions. Take this into consideration if discretion can be exercised when choosing specific IP address ranges to add. Careful choices can greatly reduce the length and complexity of the OSPF routes table.
Continue with the procedure by exiting the dest context.

[dest]pdsn1(config-ctx)# exit<CR>

This returns the configuration prompt.

[local]pdsn1(config)#

After data-fill changes save the configuration:

[local]pdsn1(config)# save configuration /flash/system.cfg <CR>

After saving the changes, sync the files between the active and inactive cards. Type the card spc synchronize command to synchronize the files to the standby SPC:

[local]pdsn1(config)# card spc synchronize filesystem all <CR>

Compares the files on the two SPCs and determine which files need to be synchronized between the active SPC in slot 8 and the standby SPC in slot 9.

Roll-Back Procedure

Commands:

Enter configuration mode

[local]pdsn1# config<CR>

Delete the previously added IP pool called pool

[local]pdsn1(config)# no ip pool <pool> <CR>

After data-fill changes: If the shelf configuration is acceptable type the save configuration command:

[local]pdsn1(config)# save configuration /flash/system.cfg<CR>

After saving the changes, sync the files between the active and inactive cards. Type the card spc synchronize command to synchronize the files to the standby SPC:

[local]pdsn1(config)# card spc synchronize filesystem all<CR>

Compare the files on the two SPCs and determine which files need to be synchronized between the active SPC in slot 8 and the standby SPC in slot 9.

1. Login to the PDSN to monitor the test data session
2. Turn-on screen logging in putty or whatever terminal emulator you use.

Give the log file a helpful name, as you might want to refer back to it later. There might be many test attempts so consider using a file naming convention that describes what the test was for, when it was done, and whether or not is was successful. Success or failure of the test could be added to the filename after the test completed, of course.

3. Initiate a monitor command

[local]pdsn1# monitor subscriber msid 000003036995136

This command uses the MIN of the test handset, preceded by 5 zeros. The monitor command has many options, so investigate for yourself what works best. Increase the verbosity of output from the monitor command by entering from 1 to 4 “+” signs (plus symbol) on the command line.

4. Make a data call from the test handset.

If you are making frequent changes to the PDSN ACL or the AAA profile for this handset it is a good idea to power-cycle the handset before every test call to clear any previous data session. Failure to do so can lead to unpredictable and probably confusing test results.

5. After the test completes turn off logging in your terminal emulator.

If the test was successful note that in the name of the log file according to your naming convention. Then archive the log file. This procedure is completed. If the test was not successful, read on.

6. Dump handset and PDSN configuration data.

For the test handset use this command or a variation:

show subscriber full username <username>

where <username> is frequently of the form <MDN>@<yourdomain.com>. Your network will have its own form of username. This command prints various statistics about the test handset. This outpu, too, could be logged for later reference or analysis.

7. Depending on the nature of the failure, increased logging might be helpful

This is not commonly done, but might help. First a log rule must be put into the ACL being tested. See NN20000-197 page 276, or the Starent documentation as appropriate. This can be quite verbose so evaluate if it appropriate to use this command at all in your network, or consider to do this testing at a period of low data traffic.

After the log rule has been added, enable logging:

logging filter active facility acl-log level debug

Then to start logging:

logging active

To stop logging:

no logging active

That concludes the basic test procedure. Now comes the heavy lifting of analyzing all the data to determine what might be causing the error. Make a change trying to correct it, then repeat this test. I recommend logging every test call, and saving all log files until testing is 100% completed and the products being developed are in service before deleting them. Good luck!

Nortel has proposed flushing the OSPF cache on the PDSN with this command:

clear ip ospf process

After the command has been entered, we’ll monitor use of the use of the erring address space to see if data sessions having an IP Address above .128 succeed.