Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

PBR asynchronous INUSE-ACK over SL-API

Updated: June 30, 2026

Want to summarize with AI?

Log in

Describes PBR asynchronous hardware acknowledgment over SL-API and explains its role in providing deterministic, aggregated acknowledgments for NHG programming in Cisco 8000 Series routers.

Policy Based Routing (PBR) asynchronous INUSE-ACK is an acknowledgement model for PBR over Service Layer API (SL-API) that

  • changes how PBR policy programming reports in-use status for Next-Hop Groups (NHG)

  • enables the system to send an INUSE-ACK only after the NHG is confirmed in hardware, and

  • provides external controllers with accurate feedback for traffic.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

PBR asynchronous INUSE-ACK over SL-API

Release 26.2.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100]); Centralized Systems (8600 [ASIC:Q200]) ; Modular Systems (8800 [LC ASIC: Q200, P100])

This feature improves the reliability of PBR readiness signaling over SL-API. The router now returns a fast Sync-Ack for request acceptance and a separate asynchronous INUSE-ACK after it programs the NHG in hardware. This change helps the controller send traffic only after the NHG is ready.

The enhancement allows PBR policies to be programmed in the background without blocking the controller.

Policy Based Routing policies direct traffic based on user-defined criteria, redirecting matched traffic to specified Next-Hop Groups (NHGs). Previously, Cisco IOS XR with SL-API would acknowledge PBR programming before actual hardware programming was complete, which could result in external controllers sending traffic to NHGs not yet viable, causing packet loss.

In previous implementations, PBR sent an early acknowledgment to the controller when it initial programmed a policy on an interface. Actual NHG programming in hardware occurred asynchronously, which could lead to the controller directing traffic to an NHG before hardware resources were ready and cause potential traffic loss.

Starting with Cisco IOS XR Release 26.2.1, with this feature, the router

  • separates request acceptance from final hardware readiness

  • returns a Sync-Ack after it validates the request, and

  • sends the final INUSE-ACK or INUSE-NACK from RIB to SL-API and then from SL-API to controller once the NHG is successfully created in the system.

The final acknowledgment is a reliable indication that the router completed NHG programming in hardware and NHG is ready for traffic.

Benefits of PBR asynchronous INUSE-ACK

This feature provides the following benefits:

  • Prevents the controller from treating request acceptance as programming completion.

  • Gives the controller a reliable signal for when traffic can use the NHG.

  • Aligns PBR more closely with the asynchronous programming model used by other SL-API verticals.

  • Improves visibility into request completion and acknowledgment state.

  • Improves performance and addresses the ability to scale to 8,000 rules per PBR policy, meeting P200 platform scale requirements.

Features of PBR asynchronous INUSE-ACK

PBR asynchronous INUSE-ACK over SL-API delivers several enhancements for policy-based routing operations. The main features are:

  • Redirect NHG acknowledgment: The system sends an acknowledgment only after all interfaces and nodes applying a particular redirect next hop group (NHG) have successfully programmed it in hardware. This prevents premature or inaccurate controller decisions about NHG readiness.

  • Asynchronous programming: NHG objects referenced in a PBR policy are programmed asynchronously in hardware, decoupling the initial policy programming from final hardware completion. Notifications are aggregated to ensure completeness.

  • SL-API integration: This feature extends SL-API programmability by returning a synchronous acknowledgment (SYNC-ACK) immediately after request validation, while actual hardware programming completes in the background.

  • Lossless rule modification: Enhances the "Policy Replace" operation, permitting rule changes in PBR policies without traffic disruption, unlike prior lossy modifications.

  • Performance improvements: Optimizations reduce programming time and increase scale, meeting requirements for larger policies (up to 8,000 rules on supported platforms).

Benefits of PBR asynchronous INUSE-ACK

Using asynchronous PBR INUSE-ACK provides multiple advantages:

  • Prevents false readiness indications for next-hop groups (NHGs) and PBR policies.

  • Supports automation and high-scale deployments with reliable status tracking.

  • Reduces operational risk by avoiding traffic through incomplete hardware paths.

  • Provides visibility into pending and completed PBR programming operations for troubleshooting.

Restrictions for PBR asynchronous INUSE-ACK

When deploying PBR asynchronous INUSE-ACK, observe the following restrictions:

  • Lossless rule modification applies only to policy replace operations.

  • The initial Sync-Ack confirms only that the router accepted the request. It does not confirm successful hardware programming.

  • Supports up to 8000 rules or class-maps per PBR policy on P200 platforms.

  • Only upto 50 operations are stored.

Usage guidelines for PBR asynchronous INUSE-ACK

Follow these guidelines when you deploy the PBR asynchronous INUSE-ACK feature:

  • Treat Sync-Ack as request acceptance only.

  • Wait for the final INUSE-ACK before sending traffic.

  • Send traffic on the NHG only after the router returns the final INUSE-ACK.

  • Use policy replace operations when you need lossless rule modification.

  • Use the platform that matches your scale requirements.

How asynchronous PBR INUSE-ACK works

Summary

The key components involved in the process are:

  • Controller: Initiates PBR requests and expects confirmation of redirect NHG programming.

  • SL-Policy: Validates requests, sends synchronous acknowledgments, and manages asynchronous processing.

  • PBR Execution Agent (PBR-EA): Registers for NHG viability changes and handles programming logic using event notifications.

  • FIB (Forwarding Information Base): Monitors NHG viability and dispatches ECD-based notifications when state changes.

Asynchronous PBR INUSE-ACK is a process designed to reliably acknowledge the programming of redirect next-hop groups (NHG) in hardware, even when NHG viability changes occur after the initial request. This process leverages asynchronous acknowledgments, event notifications, and aggregation to maintain robust network policy enforcement.

Workflow

These stages describe how PBR asynchronous INUSE-ACK works:

  1. The controller sends a PBR request through SL-API.
  2. SL-Policy performs basic validation on the request.
  3. SL-Policy returns a SYNC-ACK to acknowledge the request.
  4. SL-Policy enqueues the request for asynchronous processing.
  5. PBR Execution Agent (PBR-EA) registers with FIB for NHG viability changes using ECD-based notifications.
  6. PBR-EA programs the NHG in the hardware even if the NHG is not actually viable, and sends an ACK or NACK to RIB. -
  7. RIB holds the notification until the NHG is created or viable and sends the ACK or NACK to the controller.

Result

This process ensures that policy-based routing configurations are reliably programmed in hardware and provides robust confirmation (ACK) to the controller when the redirect NHG becomes viable, preventing misconfigurations and ensuring consistent network behavior.

Show commands for PBR asynchronous INUSE-ACK

This table listsprovides you can use to validate and debug PBR asynchronous hardware acknowledgment operations.

Table 2. Show commands for PBR asynchronous INUSE-ACK

Command

Purpose

show service-layer policy requests completed < operation-id | last N >

Displays completed PBR programming request results.

show service-layer policy requests pending

Displays PBR requests that are still pending in the SL-Policy queue.

show hwack-aggregation emsd pending [private]

Displays redirect NHGs that are pending PBR INUSE-ACK aggregation.

show service-layer policy internal database path-groups

Displays path-group state on the SL-Policy side.

show pbr path-group sl-api location all < node id | all >

Displays path-group state on the PBR-EA side.

show tech-support service-layer

Collects service-layer technical support data.

show tech-support pbr

Collects PBR technical support data.

show tech ofa

Collects OFA-related technical support data.

Verify asynchronous PBR HW-ACK

Use this task to confirm the router has completed the request and that the redirect Next Hop Group (NHG) acknowledgment reached the expected state.

Follow these steps to verify asynchronous PBR hardware acknowledgment:

Before you begin

Ensure that you have the operation ID for the request that you want to verify.

Procedure

1.

Run the show service-layer policy requests completed < operation-id | last N > command to verify that the request appears in the completed results.
2.

If the request does not appear as completed, run the show service-layer policy requests pending the command to verify whether the request is still waiting in the SL-Policy processing queue.
3.

Run the show hwack-aggregation emsd pending [private] command to check whether the redirect NHG is still waiting for acknowledgments from one or more producer nodes.
4.

Run the show rib nhg name nhg-name command to verify the final notification sent from RIB to the controller.
5.

Run the show pbr path-group sl-api location all < node id | all > command to verify the path-group state on the PBR-EA side.
6.

Correlate the operation ID, the request state, and the pending acknowledgment state.

You confirm whether the request is complete, whether it is still pending, and whether the redirect NHG is still waiting for acknowledgment aggregation.