A permanent license reservation is not a standard activation task. This instruction for PLR license deployment is intended for Cisco environments that cannot maintain a direct connection to Cisco Smart Software Manager, including isolated networks, secure sites, lab environments, and locations with restricted outbound access. The objective is to bind a purchased software entitlement to a specific device while preserving a clear compliance record.

PLR is useful when operational requirements prevent routine cloud-based license reporting. It also introduces a permanent device association that procurement and network operations teams must manage carefully. Before generating any reservation request, confirm that the hardware platform, software release, entitlement type, and organizational licensing policy support PLR.

What a PLR License Does

A Permanent License Reservation, commonly called PLR, reserves eligible Cisco Smart Licensing entitlements for a single product instance. The device generates a request code containing its unique device identifier, or UDI. An administrator submits that request through the applicable Cisco licensing portal and receives an authorization code to install on the device.

After installation, the device reports the reserved license as authorized locally. It does not need continuous communication with Cisco Smart Software Manager to retain that authorization. This is the central advantage for disconnected or highly controlled infrastructure.

The trade-off is equally important: an entitlement reserved through PLR is not available for another device until the reservation is properly returned or released. A replacement router, switch, controller, or security appliance cannot simply inherit the entitlement because it is running the same configuration. The reservation is tied to the original device identity.

Confirm PLR Eligibility Before Procurement

Not every Cisco platform, software image, or license offer supports permanent reservation. Licensing behavior can differ across IOS XE, IOS XR, NX-OS, wireless controllers, and security products. It can also vary by release. Teams should treat PLR eligibility as a required technical specification, not an assumption based on an older deployment.

Validate four items before placing an order or scheduling a change:

• The exact product ID and software version support the required Smart Licensing reservation workflow.
• The purchased entitlement is eligible for permanent reservation and matches the intended license level or feature set.
• The administrator has access to the correct Smart Account and Virtual Account where the entitlement is held.
• The device UDI, serial number, and current licensing state have been recorded before the reservation begins.

For project procurement, this verification prevents a common problem: hardware arrives for an offline site, but the required license is assigned to a different Virtual Account or cannot be reserved under the selected software release. Exact product and entitlement matching matters as much as selecting the correct interface module or power supply.

PLR Compared With Other Licensing Methods

Smart Licensing Using Policy is designed for many connected and periodically connected deployments. It offers flexible reporting and may reduce administrative handling where devices can communicate through approved transport methods. Specific License Reservation, or SLR, is another offline-oriented workflow used on some platforms, but it is not interchangeable with PLR.

PLR is generally selected when the business requires a durable, device-specific authorization for a disconnected system. It should not be used simply because the licensing portal is inconvenient to access. If the network can report license use through approved methods, a less permanent model may offer better flexibility when hardware is refreshed, moved, or redeployed.

PLR License Instructions: A Controlled Workflow

The command syntax differs by product family and software train, so administrators should use the Cisco documentation that corresponds to the exact installed release. The workflow itself remains consistent.

1. Establish the device and entitlement record

Start by collecting the device hostname, product ID, serial number, UDI, software version, management IP address, site, rack or cabinet location, and responsible support team. Record the intended license level and quantity of entitlements required.

Then verify the Smart Account and Virtual Account that contain the purchase. If the entitlement was delivered into the wrong account, correct the ownership or transfer process before generating a reservation request. Attempting to solve account allocation after authorization is installed can create avoidable downtime and audit discrepancies.

2. Generate the reservation request on the device

Using the device CLI or supported management interface, generate a PLR reservation request code. The device packages identifying information and the requested entitlement details into an encrypted or encoded string.

On Cisco platforms, commands may be described as license reservation request generation or permanent reservation request generation. Do not copy a command from a different product family without checking the platform guide. A command valid on an IOS XE router may not apply to NX-OS switching or a controller platform.

Save the full request output exactly as generated. Truncated strings, hidden terminal characters, and transcription errors can prevent authorization creation. For isolated systems, transfer the request through the organization’s approved removable-media or controlled file-transfer process.

3. Create the authorization code in the licensing portal

An authorized licensing administrator submits the reservation request in the relevant Smart Account and Virtual Account. The portal validates the device request against available entitlements and produces an authorization code when capacity is available.

At this point, confirm the quantity being consumed. A device may request multiple licenses for feature tiers, throughput levels, or redundancy roles. The portal transaction should match the approved bill of materials and the deployment design, not merely the number of chassis being installed.

Maintain a record of the authorization transaction, including the account, Virtual Account, device UDI, entitlement name, quantity, date, and approving administrator. This record is necessary when a device later fails or is replaced.

4. Install and verify the authorization code

Transfer the authorization code to the target device and install it using the applicable licensing command or interface. The device should accept the code and show the permanent reservation as authorized.

Verification should include more than a successful command response. Review the local license status, entitlement usage, reservation state, and any error or evaluation indicators. Capture the output in the project record. For production deployments, include this check in the commissioning checklist before the device is handed to operations.

If authorization fails, stop before generating additional requests. Compare the device UDI in the request with the actual hardware, verify the software release, confirm that the authorization code has not been altered, and check that the correct license type was reserved. Repeated requests can complicate entitlement tracking.

Replacement, RMA, and Decommissioning Considerations

PLR requires a documented lifecycle procedure. If a device is being decommissioned, moved out of service, or replaced under an RMA, return or release the reservation according to the supported platform workflow before disposing of the original unit whenever possible. That action makes the entitlement available for reassignment.

Hardware failure changes the process. A failed device may be unable to generate a return code, and the licensing team may need to use the vendor’s recovery or support process to reconcile the reservation. Keep purchase records, serial numbers, support case details, and failure documentation available. These details are particularly important for remote sites where failed hardware may not be immediately recoverable.

Procurement teams should also distinguish between a software entitlement transfer and a hardware replacement purchase. A new chassis does not automatically include reusable licensing rights, and a reused entitlement does not guarantee compatibility with a different product family. Validate both before approving an emergency replacement.

Operational Controls That Prevent Licensing Gaps

PLR works best when network engineering, asset management, and procurement use one source of truth for device identity and entitlement ownership. At minimum, track the UDI, serial number, product ID, software release, Smart Account, Virtual Account, license level, authorization date, and physical location.

For large estates, include PLR status in quarterly infrastructure reviews alongside hardware support status, software lifecycle position, spare inventory, and configuration backups. This is particularly valuable for legacy routers and switches that remain operational in industrial, branch, or restricted-access environments.

A permanent reservation provides stability for disconnected infrastructure, but it is not a substitute for disciplined asset control. Treat each PLR authorization as a managed infrastructure record, and future upgrades, RMA events, and audits become far easier to execute without interrupting network service.

imrank21

I am an enthusiastic tech blogger with 15 years of experience in the technology field. I am passionate about sharing valuable insights and helping people who are interested in technology gain useful and practical information. I am originally from Mumbai, India.