SDK Installation and Setup Guide - Oracle · You can submit, update, and review service requests...

Migration Guide

Fourth EditionDecember 2008

Oracle Communications IP Service Activator™ Version 5.2.4

Copyright © 1997, 2008, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee’s responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Migration Guide – Fourth Edition Contents

Contents

Preface .................................................................................... v

About this document .................................................................................. v

Before contacting Oracle Global Customer Support (GCS) ............................... v

Contacting Oracle Global Customer Support (GCS) ....................................... vi

Downloading products and documentation ................................................... vi

Downloading a media pack ................................................................... vi

Service Activator publications ................................................................... vii

............................................................................................................ vii

Chapter 1 Pre-Migration Tasks .......................................................... 1

Pre-migration checklist ..............................................................................1

Adding network processor proxies to domains ..........................................2

Turning off maintenance mode warning messages ....................................2

User permissions ..................................................................................3

Chapter 2 Migration .......................................................................... 5

Migrating from the GUI ..............................................................................5

Migrating from the command line ................................................................8

Migration report ................................................................................. 11

Post-migration tasks ................................................................................ 12

Appendix A Rollback ....................................................................... 13

Reverting to the original configuration ........................................................ 13

Appendix B Equivalence Logic ......................................................... 15

Cisco Cartridge - QoS configuration ........................................................... 15

QoS ID Equivalence Logic Summary ..................................................... 15

Cisco Cartridge – VPN configuration ........................................................... 17

Service Activator 5.2.4 iii

Contents Migration Guide – Fourth Edition

Route-Maps ....................................................................................... 17

VRF .................................................................................................. 17

Index ..................................................................................... 19

iv Service Activator 5.2.4

Migration Guide – Fourth Edition Preface

Preface

About this documentThis document outlines the tasks involved in migrating QoS device configurations from the Service Activator device driver to cartridges.

This document is intended for new deployments of Service Activator cartridges, with networks currently managed by the device driver. If you are migrating new services not currently managed by Service Activator into an existing deployment of Service Activator, contact your Oracle Global Customer Support representative.

This guide consists of the following chapters and appendices:

Pre-Migration Tasks

Migration

Rollback

Equivalence Logic

Before contacting Oracle Global Customer Support (GCS)

If you have an issue or question, Oracle recommends reviewing the product documentation and articles on MetaLink in the Top Technical Documents section to see if you can find a solution. MetaLink is located at http://metalink.oracle.com.

In addition to MetaLink, product documentation can also be found on the product CDs and in the product set on Oracle E-Delivery.

Within the product documentation, the following publications may contain problem resolutions, work-arounds and troubleshooting information:

— Release Notes

— Oracle Installation and User's Guide

— README files

Service Activator 5.2.4 v

http://metalink.oracle.com

Contacting Oracle Global Customer Support (GCS) Migration Guide – Fourth Edition

Contacting Oracle Global Customer Support (GCS)You can submit, update, and review service requests (SRs) of all severities on MetaLink, which is available 24 hours a day, 7 days a week. For technical issues of an urgent nature, you may call Oracle Global Customer Support (GCS) directly.

Oracle prefers that you use MetaLink to log your SR electronically, but if you need to contact GCS by telephone regarding a new SR, a support engineer will take down the information about your technical issue and then assign the SR to a technical engineer. A technical support representative for the Oracle and/or former MetaSolv products will then contact you.

Note that logging a new SR in a language other than English is only supported during your local country business hours. Outside of your local country business hours, technical issues are supported in English only. All SRs not logged in English outside of your local country business hours will be received the next business day. For broader access to skilled technical support, Oracle recommends logging new SRs in English.

Oracle GCS can be reached locally in each country. Refer to the Oracle website for the support contact information in your country. The Oracle support website is located at http://www.oracle.com/support/contact.html.

Downloading products and documentationTo download the Oracle and/or former MetaSolv products and documentation, go to the Oracle E-Delivery site, located at http://edelivery.oracle.com.

You can purchase a hard copy of Oracle product documentation on the Oracle store site, located at http://oraclestore.oracle.com.

For a complete selection of Oracle documentation, go to the Oracle documentation site, located at http://www.oracle.com/technology/documentation.

Downloading a media pack

To download a media pack from Oracle E-Delivery

1. Go to http://edelivery.oracle.com.

2. Select the appropriate language and click Continue.

3. Enter the appropriate Export Validation information, accept the license agreements and click Continue.

4. For Product Pack, select Oracle Communications Applications.

5. For Platform, select the appropriate platform for your installation.

vi Service Activator 5.2.4

http://www.oracle.com/support/contact.html

http://edelivery.oracle.com

http://oraclestore.oracle.com

http://www.oracle.com/technology/documentation

http://edelivery.oracle.com

Migration Guide – Fourth Edition Service Activator publications

6. Click Go.

7. Select the appropriate media pack and click Continue.

8. Click Download for the items you wish to download.

9. Follow the installation documentation for each component you wish to install.

Service Activator publicationsThe Service Activator documentation suite includes a full range of publications. Refer to the Service Activator Release Notes for more information.

Service Activator 5.2.4 vii

Migration Guide – Fourth Edition

viii Service Activator 5.2.4

Migration Guide – Fourth Edition Pre-Migration Tasks

Chapter 1

Pre-Migration Tasks

This chapter outlines the tasks you must complete before performing the migration.

Pre-migration checklistBefore performing the migration, ensure:

Service Activator is upgraded to version 5.2.4 - see the Service Activator Setup Guide for instructions on installation and upgrade

The MIPSA registry file, capabilities files and options are all customized - see the Service Activator Setup Guide for instructions

Network processor and cartridges are installed and running

Legacy device drivers and proxies are running

Network processor proxies are added to domains - see Adding network processor proxies to domains on page 2

Network processor parameter “warnInOfflineMaintenanceMode” is set to “false” - see Turning off maintenance mode warning messages on page 2

All concretes on the devices are installed - if a concrete cannot be installed, it must be removed from the device in order for the migration to be successful.

IMPORTANT: Service Activator will not migrate disabled concretes.

The Unmanaged Action field is set to “Leave” (under the Tools menu, on the Options page)

If you have used the Cisco Device Driver to configure EBGP update source commands, you must manually update each affected site by performing the following steps:

In the Service Activator GUI, go to Site Properties — EBGP window, for each affected site

Service Activator 5.2.4 1

Pre-Migration Tasks Migration Guide – Fourth Edition

In the Update Source field, select “Default” from the Source Interface drop-down list

This ensures the update source commands are set correctly before migration, which allows the network processor to properly manage the update source configuration after the migration is complete.

Policing rules on different interfaces do not use ACLs with the same classifications — any policing rules using ACLs with the same classifications should be changed to a different ACL value to be correctly validated by the network processor

Any faults on the devices are fixed

Any abandoned configurations on the devices are removed

Service Activator can connect to the devices

Adding network processor proxies to domainsPerform this procedure for each domain for which you will be migrating devices to cartridges.

To add the network processor proxies to domains:

1. From the Service Activator GUI, go to the Window menu and select Global Setup.

2. Right-click on the domain and select Properties.

3. Select the Proxy Agent page.

4. Select the checkbox for the network processor proxy. Leave any device driver proxy checkboxes selected.

5. Click OK, and then click the Commit button.

Turning off maintenance mode warning messagesThe parameter “warnInOfflineMaintenanceMode” in the network processor default.properties file is set to “true” by default. You must set this parameter value to “false” during the migration, to reduce the number of warning messages that appear, which can be safely ignored.

To set the “warnInOfflineMaintenanceMode” parameter to “false”:

1. Go to: <SERVICE_ACTIVATOR_HOME>/Config/networkProcessor/com/metasolv/serviceactivator/networkprocessor

2. Open the default.properties file for editing.

3. Change the “warnInOfflineMaintenanceMode” parameter value to “false”, then save and close the file.

2 Service Activator 5.2.4

Migration Guide – Fourth Edition Pre-Migration Tasks

4. Re-start Service Activator for the changes to take effect: go to the Service Activator server and execute the command ipsacm stop and then ipsacm start.

5. Now warning faults will not be raised in Offline Maintenance (File Interface) command delivery mode during migration operations. After your migration is complete, you can set the “warnInOfflineMaintenanceMode” parameter value to “true”.

User permissionsBy default, only Service Activator super users have the proper permissions to perform a migration. However, an administrator can grant execute permissions to other users so that they can perform migration (Device Migrate and Audit Device actions). For more information on granting user permissions, see the Service Activator Administrator's Guide.


Pre-Migration Tasks Migration Guide – Fourth Edition


Migration Guide – Fourth Edition Migration

Chapter 2

Migration

This chapter describes the process of migrating data from the Service Activator device driver to the cartridges. This chapter explains how to perform the migration from the Service Activator GUI as well as from the command line, and describes post-migration steps.

Any device managed by the Service Activator device driver can be migrated to any network processor proxies. This allows you to determine how many devices will be managed by the cartridges, depending on your server configuration and capacity (CPU and memory).

Migrating from the GUIUse this procedure to perform the migration using the Service Activator GUI.

To migrate data from the Service Activator device driver to cartridges:

1. From the Service Activator GUI, perform one of the following actions:

— If the device you want to migrate is currently managed, you must un-manage it, then re-manage it

— If the device you want to migrate is currently un-managed, you must manage it, then un-manage it

This ensures the configuration on the device and the corresponding configuration in Service Activator are properly re-synchronized.

2. If the device you want to migrate is currently managed, you must un-manage it:

— Right-click on the device and select Un-manage

— Click the Commit button

3. Move the device management from the proxy agent to the network processor:

— Right-click on the device and select Properties


Migration Migration Guide – Fourth Edition

— Select the Management page

— In the Proxy Assignment drop-down list, select the network processor proxy

— Click OK and then click the Commit button

4. Re-set the device capabilities:


— Select the Capabilities page

— Click the Reset Device Capabilities button

— In the confirmation popup, click Yes


5. Re-discover the device to get the new capabilities from the network processor:

— Right-click on the device and select Discover

6. Manage the device and set it to Offline Maintenance mode:



— In the Device State panel, select Offline Maintenance from the drop-down list

— In the Command Delivery field, click the Manage button


IMPORTANT: Ensure all concretes on the device are installed before performing the next step. If any concretes are not installed, you must investigate and fix any errors so that all concretes are installed before performing the next step. See the Service Activator Online Help for information on troubleshooting and system messages.

7. Run a device audit:


— Select the Audit/Migrate page

— Click the Initiate Audit button

When the audit is finished, click Detach Audit. Then right-click in the new window that appears, choose Select All and copy-paste the text to another application or file.

8. Replace any manual configurations:

— Banners - created with configuration policies in Service Activator. Create a banner configuration policy at the network level or the device level and



apply it to the device you are migrating. Ensure the banner configuration policy concrete is installed.

— CDK scripts - replaced by configuration policies. CDK scripts were used with the device driver but with the migration to the network processor, configuration policies are used instead. When you are replacing your CDK scripts with configuration policies, ensure you are mapping to the correct policy type. After all of your CDK scripts are replaced by the proper configuration policies, ensure you disable and/or delete the CDK scripts. In some cases, CDK scripts do not need to be replaced by configuration policies because the functionality has been added to Service Activator. For example, the action of copying the running configuration to the startup configuration is now performed by Service Activator with the parameter “saveRunningConfig” in the default.properties file, located in <SERVICE_ACTIVATOR_HOME>/Config/networkProcessor/com/metasolv/serviceactivator/networkprocessor. This parameter is set to “true” by default but you can change it to “false” if you do not want Service Activator to copy the running configuration.

See the Service Activator Online Help for information on installing configuration policies.



— Select the Audit/Migrate page

— Click the Initiate Audit button

When the audit is finished, click Detach Audit. Then right-click in the new window that appears, choose Select All and copy-paste the text to another application or file.

IMPORTANT: If the device you are migrating has no configuration installed by the device driver, then you can skip steps 9, 10 and 11 and proceed to step 12.

10. Execute a migrate preview:

— From the Audit/Migrate page, select the Preview Only checkbox

— Click Migrate

11. Compare the migrate preview output to the device audit output from step 6:

— If there are no discrepancies between the migrate preview output and the device audit output then there is no need to migrate. Therefore, you do not need to continue with this procedure.

— If the auto-generated names and IDs are the only discrepancies between the migrate preview output and the device audit output, you can safely migrate.



— If there are other discrepancies, you must investigate them before continuing.

— If you received messages stating there are faults on device, you can choose to proceed with the migration or stop. For example, warning faults that can be safely ignored.

12. Execute the migration:

— From the Audit/Migrate page, de-select the Preview Only checkbox

— Click Migrate


When the migration is finished, a report will appear. Review the report to verify the migration details. If the report contains no conflicts or missing configurations, then the migration was successful. If there is red or blue text, these issues need to be analyzed and resolved.

13. Once the migration is successfully completed, set the device to Online mode and either Manage or Un-manage it:



— In the Device State panel, select Online from the drop-down list

— In the Command Delivery field, click the Manage or Un-manage button


The migration is now complete.

Migrating from the command lineUse this procedure to perform the migration at the command line level.

You can also write a script to perform the migration, using Java (OJDL) or Python.

To migrate data from the Service Activator device driver to cartridges:

1. Perform one of the following actions:

— If the device you want to migrate is currently managed, you must un-manage it, then re-manage it

— If the device you want to migrate is currently un-managed, you must manage it, then un-manage it

This ensures the configuration on the device and the corresponding configuration in Service Activator are properly re-synchronized.



2. If the device you want to migrate is currently managed, you must un-manage it:

— Log in to the Service Activator Integration Manager CLI

— Locate the device you want to migrate using the find command

— Execute the command: unmanage [<device id>]

— Execute the commit command

3. Move the device management from the proxy agent to the network processor:


— Locate the device you want to migrate and locate the proxies using the find command

— Un-link the device from the proxy agent and link to the network processor.

For example:

unlink [<proxy agent id>] [<device id>]

link [<network processor id>] [<device id>]





— Execute the command: resetCapability [<device id>]


5. Re-discover the device to get the new capabilities from the network processor:



— Execute the command: discover [<device id>] Type=4

6. Manage the device and set it to Offline Maintenance mode:



— Execute the command: manage [<device id>]

— Execute the command:

modify [<device id>] CommandDeliveryMode=OfflineMaintenance


7. Replace any manual configurations:



— Banners - created with configuration policies in Service Activator. Create a banner configuration policy at the network level or the device level and apply it to the device you are migrating. Ensure the banner configuration policy concrete is installed.

— CDK scripts - replaced by configuration policies. CDK scripts were used with the device driver but with the migration to the network processor, configuration policies are used instead. When you are replacing your CDK scripts with configuration policies, ensure you are mapping to the correct policy type. After all of your CDK scripts are replaced by the proper configuration policies, ensure you disable and/or delete the CDK scripts. In some cases, CDK scripts do not need to be replaced by configuration policies because the functionality has been added to Service Activator. For example, the action of copying the running configuration to the startup configuration is now performed by Service Activator with the parameter “saveRunningConfig” in the default.properties file, located in <SERVICE_ACTIVATOR_HOME>/Config/networkProcessor/com/metasolv/serviceactivator/networkprocessor. This parameter is set to “true” by default but you can change it to “false” if you do not want Service Activator to copy the running configuration.

See the Service Activator Online Help for information on installing configuration policies.


— Log in to the Service Activator server

— Execute the command: auditdevice <IP address of device>

IMPORTANT: If the device you are migrating has no configuration installed by the device driver, then you can skip steps 8, 9 and 10 and proceed to step 11.

9. Execute a migrate preview:


— Execute the command: auditdevice -migrate -preview <IP address of device>

10. Compare the migrate preview output to the device audit output from step 6:

— If there are no discrepancies between the migrate preview output and the device audit output then there is no need to migrate. Therefore, you do not need to continue with this procedure.

— If the auto-generated names and IDs are the only discrepancies between the migrate preview output and the device audit output, you can safely migrate.

— If there are other discrepancies, you must investigate them before continuing.



— If you received messages stating there are faults on device, you can choose to proceed with the migration or stop. For example, warning faults that can be safely ignored.

11. Execute the migration:


— Execute the command: auditdevice -migrate <IP address of device>

12. Once the migration is successfully completed, either Manage or Un-manage the device and set it to Online mode:



— Execute one of the following commands:

manage [<device id>]

OR

unmanage [<device id>]

— Execute the command:

modify [<device id>] CommandDeliveryMode=Online


The migration is now complete.

Migration reportWhen the migration is finished, a report is created in:

<SERVICE_ACTIVATOR_HOME>/AuditTrails/reports

The file name format for the report is:

audit.<IP address of device>.<date>.xml

For example:

audit.10.13.5.67.20070320-165217.xml

Review the report to verify the migration details. If the report contains no conflicts or missing configurations, then the migration was successful. If there is red or blue text, these issues need to be analyzed and resolved.



Post-migration tasksThis section explains the tasks that you must perform after completing the migration.

After you have migrated all your devices from device drivers to cartridges, perform the following tasks:

1. Clean up leading or trailing spaces in certain policy names:

Leading and trailing spaces should not be entered in policy-map names, and in class-map names which will be configured on the device. EIGRP route-map names should not contain any spaces at all.

If a Cisco device has configuration commands installed by a pre-Service Activator 5.2.4 version of the Service Activator Cisco device driver, it may fail validation.

Example: In a pre-Service Activator 5.2.4 version of Service Activator, if you installed an MQC PHB with a configured policy-map name of " myPolicyMap", then when the device is in a managed state in Service Activator 5.2.4, a validation fault is raised against the MQC PHB. You should remove the leading spaces from the configured name. When this is done, Service Activator configures a new policy-map on the device. You must manually remove the policy-map with the spaces (e.g. " myPolicyMap") from the device. Similarly, correct any pre-existing class-map names which have leading spaces in the name.

2. Remove the device driver proxy assignment from each domain:

— From the Service Activator GUI, go to the Window menu and select Global Setup

— Right-click on the domain and select Properties

— Select the Proxy Agent page

— Un-select the checkboxes for the device driver proxies. Leave the network processor proxy checkboxes selected.

— Click OK, and then click the Commit button

Perform this procedure for each domain for which you will be removing device driver proxies.

3. Go to the cman.cfg file in <SERVICE_ACTIVATOR_HOME>/Config and comment out the proxy-agent and device-driver entries on each server, then save the file.

4. Re-start Service Activator by going to the Service Activator server and executing the command ipsacm stop and then ipsacm start.


Appendix A- Rollback

Rollback

During the migration, discrepancies can arise for various reasons and you may wish to revert back to the original configuration. These reasons can include:

Network errors

Incorrect data or configuration files

Incorrect data imported into Service Activator, requiring modifications to an upstream system or process

Reverting to the original configurationThis procedure describes how to revert the configuration back to the device driver, if there were issues during the migration.

To revert to the original configuration:

1. Disable any configurations, such as banner configuration policies, that you created in Service Activator to replace manual configurations.

2. Delete the network processor device cache:


— Execute the following command to get the device ID:

npAdmin.sh list_lds all <IP address of device>

— Execute the following command to delete the device model:

npAdmin.sh delete_lds <device id> all all

3. From the Service Activator GUI, un-manage the device:

— Right-click on the device and select Un-manage


Rollback Migration Guide - Fourth Edition

— Click the Commit button

4. Move the device management from the network processor to the proxy agent:



— In the Proxy Assignment drop-down list, select the proxy agent that was managing the device previously




— Select the Capabilities page

— Click the Reset Device Capabilities button



6. Re-discover the device to get the new capabilities from the proxy agent:

— Right-click on the device and select Discover

7. As a preview step, set the device state to Offline Maintenance and then manage the device:



— In the Device State panel, select Offline Maintenance from the drop-down list

— In the Command Delivery field, click the Manage button


8. Verify that no new configuration has been added to or removed from the device by the device driver, then set the device state to Online:



— In the Device State panel, select Online from the drop-down list


9. Fix the error that caused you to perform the rollback. After fixing the error, perform the migration procedure again.


Appendix B

Equivalence Logic

This section explains the logic used to map the names and IDs during the migration process. The identifiers are the auto-generated names and IDs that you are migrating. The equivalence for both QoS and VPN are provided in this section.

Cisco Cartridge - QoS configurationThis section describes the QoS identifiers, including Cisco device driver auto generated names and IDs. Every type of identifier is associated with a description of the equivalence and migration logic used in the migration process.

QoS ID Equivalence Logic Summary

ACL Numbers and ACL Names

For each ACL to be migrated in the device model, the cartridge checks the current router configuration for ACL instances. In order for an ACL in the device model to be deemed equivalent to an ACL in the running configuration, the following criteria must be met:

The parameter values listed below are the ones looked at during the migration. They must match in both the device model ACL and the router configuration ACL, for each rule. The order of the rules in each ACL must also be the same.

— ACL action (permit or deny)

— IP protocol

— source IP address

— source address mask

— source port


Equivalence Logic Migration Guide - Fourth Edition

— destination IP address

— destination address mask

— destination port

When Service Activator matches ACLs during migration, if it encounters ACLs that do not match, it will not migrate them.

The ACL on the router must be associated directly or indirectly (via class-map) to the same set of interfaces, and the same traffic direction (inbound or outbound), as the ACL in the Service Activator device model.

Map-class

For each map-class to be migrated in the device model, the cartridge checks the current router configuration for map-class instances. In order for a map-class in the device model to be deemed equivalent to a map-class in the running configuration, the map-class on the router must be directly associated to the identical set of interfaces in the Service Activator device model.

VC-class

For each VC-class to be migrated in the device model, the cartridge checks the current router configuration for VC-class instances. In order for a VC-class in the device model to be deemed equivalent to a VC-class in the running configuration, the VC-class on the router must be directly associated to the identical set of interfaces or VCs in the Service Activator device model.

Class-map

For each class-map to be migrated in the device model, the cartridge checks the current router configuration for class-map instances. In order for a class-map in the device model to be deemed equivalent to a class-map in the running configuration, the following criteria must be met:

The parameter values listed below are the ones looked at during the migration. They must match in both the device model class-map and the router configuration class-map, for each rule. The order of the rules in each class-map may or may not be important, depending on the situation - with the match-any value, the order of rules does not matter, but for the match-all value, the order of rules must be the same for each class-map.

— access group

— class map

— DSCP

— MPLS (experimental and topmost)

— precedence


Migration Guide - Fourth Edition Equivalence Logic

— any

Service Activator will also look at negated match results during the migration. (If the parameter “not” is placed in front of any of the values listed above).

The class-map on the router must be directly associated to the identical set of interfaces in the Service Activator device model.

Policy-map

For each policy-map to be migrated in the device model, the cartridge checks the current router configuration for policy-map instances. In order for a policy-map in the device model to be deemed equivalent to a policy-map in the running configuration, the policy-map on the router must be directly associated to the identical set of interfaces in the Service Activator device model.

Cisco Cartridge – VPN configuration

Route-Maps For each route-map to be migrated in the device model, the cartridge checks the current router configuration for route-map instances. In order for a route-map in the device model to be deemed equivalent to a route-map in the running configuration, the route-map on the router must be associated directly or indirectly (via BGP address-family) to the same set of interfaces, and the same traffic direction (inbound or outbound), as the route-map in the Service Activator device model.

VRFFor each vrf to be migrated in the device model, the cartridge checks the current router configuration for vrf instances. In order for a policy-map in the device model to be deemed equivalent to a vrf in the running configuration, the vrf on the router must be directly associated to the identical set of interfaces in the Service Activator device model.


Equivalence Logic Migration Guide - Fourth Edition


Migration Guide – Fourth Edition Index

Index

Aabout this document v

Ccommand line, migrating from 8customer support v

Ddocument, about vdocumentation

downloading viService Activator vii

Eequivalence logic mapping 15

GGUI, migrating from 5

Mmapping, equivalence logic 15migrating

from the command line 8from the GUI 5

migration 5report 11rollback 13

Ppermissions, user 3post-migration tasks 12pre-migration tasks 1products

downloading vi

Rreport, migration 11rollback, migration 13

Ssupport

customer v

Ttasks

post-migration 12pre-migration 1

Uuser permissions 3


Index Migration Guide – Fourth Edition


SDK Installation and Setup Guide - Oracle · You can submit, update, and review service requests...

Documents

Transcript of SDK Installation and Setup Guide - Oracle · You can submit, update, and review service requests...