SDX 6.4.0 Release Notes > Migration

Migration

This section provides information about migrating from earlier SDX software releases to SDX Release 6.4.0.

Migrating Data

An SDX deployment has a distributed architecture that can include many components, such as JUNOSe routers, JUNOS routing platforms, LDAP directories, VTAs, ACPs, business-to-business partner applications, or OSS applications. As a result, you must address many considerations in the migration process.

This section describes data migration for these components:

• LDAP directory server—See LDAP Directory Data Migration.
• SAE data (including router and session data)—See SAE Data Migration.
• External SDX applications—See Application Data Migration.
• SNMP trap receivers—See SNMP Trap Receiver Migration.
• PCMM environment—See PCMM Environment Migration.

The data migration from Release 6.3.x to Release 6.4.0 is fully supported. Data migration from the other supported releases to Release 6.4.0 requires restarting the SDX client on the JUNOSe router. See SAE Data Migration for more information about this case.

LDAP Directory Data Migration

Use the migration procedures described in SDX Getting Started Guide, Chapter 12, Upgrading the SDX-300 Software to migrate directory data for OpenLDAP, Sun ONE Directory Server (iPlanet), or DirX from an earlier SDX software release to SDX Release 6.4.0.

NOTE: If you are using the Oracle Internet Directory, see the Oracle Internet Directory documentation for further details about installation, migration, or replication of the Oracle Internet Directory.

Using Mixed Releases

In certain cases, you might need an SDX LDAP directory environment that contains mixed releases so that the SDX deployment can use LDAP information from the LDAP directory of an earlier SDX release. This mixed environment might be useful for minimizing data entry or for minimizing the number of hosts required to perform data migration.

Contact Juniper Networks Professional Services to determine whether your migration scenario requires a mixed environment and how to set up this environment.

To set up this environment, follow these general guidelines:

1. Follow the normal SDX migration procedure.
2. Rename o=umc to o=umc_<current_release>, where <current_release> is the SDX release number being installed. For example, the new name for Release 6.4.0 is o=umc_640. When renaming, keep in mind that o=umc is changed to o=umc_<current_release>, so the data in the directory must be adjusted accordingly. We suggest exporting the data into an LDIF file, using the UNIX sed command to search for and replace all o=umc occurrences with o=umc_<current_release> (should be case-insensitive).

Depending on the size of your user database (entries under o=Users, o=umc), decide whether you want to duplicate these entries under o=umc_<current_release> or whether you want to reuse the o=Users, o=umc entries in your SDX 6.4.0 components.

3. Create a new database under o=umc to hold the data from the previous release.
4. Import the previous release data to the o=umc subtree of the database created in Step 3.
5. Set up replication following the instructions provided by your directory vendor.
6. Configure the new 6.4.0 SAE to use the o=umc_640 subtree.

SAE Data Migration

In addition to LDAP directory data, the SAE uses other sources of information that are stored in external data repositories supported by a particular release. These data repositories are:

• JUNOSe router
• JUNOS routing platform
• PCMM device
• Session store

Table 1 provides information about the repository, the data stored, and the associated SDX releases.

Table 1: External Data Repositories

Repository	Data	SDX Release
JUNOSe router	Policies User and service sessions	4.3.0 and later Releases before 6.4.0
JUNOS routing platform	Policies User and service sessions	5.0.0 and later Releases before 6.4.0
PCMM device	Policies User and service sessions	6.1.0 and later None
Session store	Interface, user, and service sessions	6.1.0 and later

Because the SAE synchronizes data, you must assess these repositories when data is migrated in an SAE failover scenario.

In this release, the SAE can handle the substitution format used in releases before Release 5.0.0. This feature is especially useful when the old substitution format is being used in the following areas:

• Substitutions under the o=Users, <base> tree in the directory
• Substitutions provided in the SAE by the SAE CORBA remote interface
• Substitutions in the routers or session store

Components using the old substitution format can migrate to the new format over time because the SAE can be configured to accept the old format.

By default, the SAE tries to accept the old format. If you do not want the SAE to accept the old format, set the net.juniper.smgt.lib.subst.acceptOldFormat configuration property to false.

SAE Failover Considerations

In a redundant SAE scenario, a network device can always fail over to an SAE version that is equal to or later than the original SAE version. However, a device is not guaranteed to fail over to an SAE version that precedes the original SAE version. For example, a JUNOS routing platform being managed by an SAE version 5.0.0 can fail over to an SAE version 6.4.0, but a JUNOS routing platform being managed by an SAE version 6.4.0 cannot fail over to an SAE version 5.0.0.

NOTE: When JUNOSe routers being managed by an earlier SAE version (using the UMCssp package) fail over to an SAE 6.4.0, the session enhancements made to the UMCsae version require restarting the SDX client on the router. Otherwise, user and service sessions cannot be recovered by the new SAE.

Application Data Migration

This note applies if you are using a custom application, such as a portal or plug-in, to provision subscriber and service sessions. If you are upgrading to SDX Release 6.4.0 and you previously migrated your data to the new parameter substitution format introduced in SDX Release 5.0.0, but you have not updated the application to use the new parameter substitution format, SDX Release 6.4.0 will not properly handle stored session objects. To correct this problem, you need to:

1. Modify your applications to use the SDX Release 6.1.0 substitution format.
2. Migrate the data in all session objects in the active SDX system to use the Release 6.1.0 substitution format.

Reference: TIC10388

SNMP Trap Receiver Migration

This note applies if you configured trap receivers in the directory. If you are upgrading to SDX Release 6.4.x, the SDX SNMP agent now relies on the master agent to send traps. SDX Release 6.4.x will ignore any trap receivers configured in the directory. You must configure trap receivers for your master agent. See the master agent documentation for more information.

PCMM Environment Migration

This note applies if you are migrating from a PCMM I02 to a PCMM I03 environment. If you are upgrading to SDX Release 6.4.0, the JPS now complies with the PacketCable Multimedia Specification (PKT-SP-MM-I03-051221), or PCMM I03. The JPS provides an upgrade path from a PCMM I02 to a PCMM I03 environment because it can still communicate with PCMM I02 devices while it supports the PCMM I03 synchronization messages.

NOTE: You can migrate only from SDX Release 6.3.0p4 using this procedure.

To upgrade from a PCMM I02 to a PCMM I03 environment:

1. Migrate the application managers (SAEs) from PCMM I02 to PCMM I03.

1. Install the PCMM I03 SAEs and fail over from the PCMM I02 SAEs to the PCMM I03 SAEs.
2. Remove the PCMM I02 SAEs.

2. Migrate the policy servers (JPSs) from PCMM I02 to PCMM I03.

1. Install the PCMM I03 JPSs, and reconfigure the SAE to use them. The new PCMM I03 JPS will perform PCMM I03 synchronization while connected to PCMM I02 CMTSs and/or PCMM I03 CMTSs.
   

   NOTE: Although the PCMM I03 JPS supports synchronization with PCMM I02 CMTS devices, complete synchronization in a mixed environment can affect performance. To control synchronization in a mixed environment, you can modify the syncDespitePreI03Pep and useSsqSscWithPreI03Peps parameters.

   
   
2. Remove the PCMM I02 JPSs.

3. Migrate the CMTSs from PCMM I02 to PCMM I03.

Policy and Substitution Data Changes

This section describes the policy and substitution data format changes. These formats were introduced in the UMCsae package in SDX Release 5.0.0.

Data Migration of JUNOSe Policies

This section describes changes that are made to data in JUNOSe policies when you upgrade your SDX software from Release 4.3 or earlier to Release 6.0.x or later. The migration script makes these changes.

• Parameter values under the o=umc subtree that are using the earlier parameter syntax are converted to the new parameter syntax.

Note that the migration operation evaluates all objects that contain parameters in the o=umc subtree, which is the root of the directory; the duration of the migration depends on the number of entries in the subtree.

• Parameter values used to begin with a question mark. The question marks are removed during migration.

For example: destinationIpMask: ?user_ipMask is now
destinationIpMask: user_ipMask

• There is a new attribute called policyRole. During migration, JUNOSe policies are assigned policyRole=JUNOSe.
• The ingress attribute is removed and replaced with the applicableList attribute. Data is converted as follows:

• If ingress=false, the applicableList value is set to output.
• If ingress= true, the applicableList value is set to input.

• The copsVersion attribute is removed from all policies.
• If rate-limit attributes (for example, exceedAction, conformedAction) are set to filter or forward, parentheses are appended to the existing value. For example, committedAction=forward is changed to committedAction=forward().
• QoS profile names have been removed from traffic-class actions. There is a new action for QoS profiles, called QoS attachment profiles. During migration, qosProfileName attributes are removed from TrafficClass objects, and a QosAttachment object is created. The qosProfileName attribute is added to the new QosAttachment object.
• If the parameterDefinition attribute is type 20 (which is packetOperation) and it has a default value, the default value is examined. If the default value is either filter or forward, parentheses are appended to it. If the default value starts with a question mark, the question mark is removed.

For example, parameterDefinition: pOp1|20||||filter||false| is changed to parameterDefinition: pOp1|20||||filter()||false|

parameterDefinition=pOp|20|||||?pOp1|true| is changed to parameterDefinition: pOp|20|||||pOp1|true|

• A new object class, scheduleAuxClass, has been added to the persistentSession and serviceSchedule object classes. The scheduledEvent attribute is moved from persistentSession, and serviceSchedule objects are moved to the new scheduleAuxClass object class.
• The time-specification portions of the scheduledEvent attributes have been modified by appending another asterisk for the effective period.

For example:

dn: scheduleName=Schedule1, o=Services, o=umc
scheduledEvent: * * * * * 2005 *|* * * * * 2007 *|[* * * * * 2005 *..* * * *
* 2030 *;* * * 5 * 2005 *]|deny Audio-Silver|

is changed to

dn: scheduleName=Schedule1, o=Services, o=umc
scheduledEvent: * * * * * 2005 * *|* * * * * 2007 * *|[* * * * * 2005 * *..* * * * * 2030 * *;* * * 5 * 2005 * *]|deny Audio-Silver|
objectClass: serviceSchedule

Migrating Substitutions in Policies

This section describes how to convert substitutions from the old format to the following new syntax:

[ ! ]<parameterName>[ :<role>]*=[<expression>] 

[ //<comment> ] 

For more information about substitutions, see SDX Services and Policies Guide, Chapter 7, Defining and Acquiring Values for Parameters.

In particular, note these changes:

• For fixed values, move the exclamation point (!) to the beginning of the substitution.
• For variables requiring quotes, search for embedded special characters, and replace them with the dollar sign ($) followed by the unicode of the character in hexadecimal format.
• For strings of the format $'<string>' or $<string>, replace with "<string>".
• For descriptions of the format "-><description>" or "->'<description>'", replace with //<description>.
• For the following operators, make these replacements:

• /\ by &
• \/ by |
• \ by ~
• rem and mod by %
  Note that mod (which is no longer supported) is subtly different when used with negative inputs.
• x//y by floor(x/y)
  

  NOTE: You must change this substitution because the old format is incompatible with the new format.

  
  
• Interface specifications need to be enclosed by braces ({}).
• For quoted values on the right side of the equal sign (=), replace single quotes with double quotes.
  

  NOTE: You must change this substitution because the old format is incompatible with the new format.