Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[CSO] Understanding RMA workflow



Article ID: KB35041 KB Last Updated: 18 Sep 2019Version: 1.0

This article explains Contrail Service Orchestration RMA, which stands for Return Materials Authorization.

Sometimes, due to hardware failure, a device managed by CSO needs to be returned to the vendor for repair or replacement. The faulty device will be replaced by a new device and the new device becomes operational with the same configuration state of the old device.


High Level Approach

Steps taken to achieve a successful RMA operation on a device:

  1. Preserve user entered information associated with the device
  2. Save stage-2 abstract configuration of the device
  3. Save service chain instances of the device
  4. Recall the device
  5. Ship new device
  6. Activate new device
  7. Re-deploy saved configurations on the new device.
  8. Instantiate service chains on the new devic

RMA workflows

There are three main workflows that implement the steps required to RMA a device:

RMA device

What RMA device workflow does:

  1. Device have already been provisioned and is in PROVISIONED state
  2. Saves current device management state
  3. Makes a backend call to change the state of topo and ems device objects and puts the device in RMA state
  4. This state is a pre condition for the next workflow (Grant RMA)

Grant RMA

Tasks performed in Grant RMA workflow:
  1. Device management state is already in RMA state
  2. Backs up stage-2 abstract config of the device
  3. Backs up service chain instances of the device
  4. Recalls the device
  5. Ships new device
  6. New device becomes in EXPECTED state ready to be activated

Activate device:

Activate device workflow is extended:

  1. Activating a new device follows the current activation workflow
  2. As part of activation, new device goes through ZTP
  3. At the end of the ZTP, device is checked to see if it is activated because of RMA
  4. Extend the ZTP workflow with additional tasks to:
    1. Restore and redeploy backed up stage-2 abstract configs
    2. Restore backed up service chain instances and recreate them on the new device
  5. Device becomes in PROVISIONED statep


  • If device is detected as bad: RMA flag can be raised in the device from Site page, then in Grant RMA step configs will be backed up.
  • If device is completely failed and not reachable: RMA flag can be raised in the device from Site page and config will be backed up from backed.
  • Manual/direct config on the device CLI will not be backed.
  • License and signatures needs to be pushed manually.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search