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

PDF

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

RCC-based encapsulation ID checks

Updated: September 8, 2026

Want to summarize with AI?

Explains the RCC-based encapsulation ID checks feature, which validates the encapsulation ID data and also the existing route data between RIB and FIB databases.

RCC-based encapsulation ID check is a diagnostic feature for IOS XR on Cisco 8000 routers that

performs read-only verification of the Encap ID data between RIB and FIB
compares encapsulation ID (encap ID) allocation, references, and content on Routing Information Base (RIB), and
increases the number of consistency checks performed between RIB and FIB databases by accounting for Encap IDs.

Table 1. Feature History Table
Feature Name	Release Information	Description
RCC-based encapsulation ID checks	Release 26.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC:Q200]) ; Modular Systems (8800 [LC ASIC: Q200, P100]) This enhancement provides better visibility into system-wide consistency verification and improves the RCC (Route Consistency Checker) output by reflecting a broader set of validation checks, giving better visibility into what RCC has verified across the system. RCC now accounts for Encap ID consistency verification on the RIB, increasing the number of consistency checks between RIB and FIB databases on nodes.

RCC-based encapsulation ID checks

The RCC-based encapsulation ID checks enhancement extends the RCC feature to improve visibility into consistency checks between the RIB and FIB databases. Previously, the Checks Performed field reflected only the number of prefixes verified. With this enhancement, the field also includes the number of Encap IDs present on RIB and FIB databases, providing a more accurate representation of the system verification.

The RCC-based encapsulation ID checks functionality performs a read-only, cross-layer comparison and reports issues such as:

Encap IDs present in one layer but missing in another
Encap ID content mismatches across layers
Stale encap references
IPv6 route count divergence

Benefits of RCC-based encapsulation ID checks

Detects silent or inconsistent encap ID state between the RIB and FIB.
Identifies silent forwarding issues caused by stale or mismatched encap references and reduces the time required to identify cross-layer FIB inconsistencies.
Reduces troubleshooting time by replacing manual cross-layer comparison with a single diagnostic workflow.
Helps support engineers to quickly isolate affected layers, objects, and inconsistency types.
Identifies IPv4 and IPv6 summary divergence across FIB layers.

How the RCC-based encapsulation ID checks work

Summary

The key components involved in the process are:

RCC checker: Orchestrates the workflow by collecting state, comparing cross-layer data, evaluating mismatches, and generating the final report.
RIB: Provides the corresponding encap ID and route summary state for cross-layer comparison.
Encap ID state information: Includes allocation status, references, and associated content for each encap ID. The checker uses this data to detect missing entries, stale references, and content mismatches.
Route summary counters: Include IPv4 route and IPv6 counts collected from each layer.
Configured divergence threshold: Defines the limit above which route count differences are flagged as inconsistencies.
Object identifiers: Include encap IDs and prefixes, that help pinpoint the exact object affected by an inconsistency.
Structured inconsistency report: Presents the result in CLI or JSON format with the affected layer, object identifier, inconsistency type, and suggested follow-up action.

The RCC-based encapsulation ID feature ensures the integrity of forwarding information by analyzing state across multiple network software layers and reporting inconsistencies.

Workflow

These stages describe how the RCC-based encapsulation ID feature works:

The RCC checker triggers a scan. This signals RIB that an RCC scan is triggered.
The RIB downloads its database to FIB using the lower priority BCDL so that normal traffic is not impacted due to scan.
The FIB receives the RIB database, compares the RIB database with its own database, detects inconsistencies, error type, and all.
Shares the results back to the RCC checker for display.
The RCC checker reports each detected inconsistency with the affected layer, object identifier, inconsistency type, and suggested follow-up action.

Result

When an encap ID exists in one layer but is missing or different in another layer, the checker reports the mismatch. When the route counts do not match across layers, the checker reports the count divergence.

Restrictions for RCC-based encapsulation ID checks

When performing the RCC-based encapsulation ID checks, ensure that you follow these restrictions:

The checker is read-only and does not modify FIB state or repair inconsistencies.
Encap ID inconsistencies are not re-verified.

Configure cross-layer encapsulation and route consistency

This task helps enable the background scan for the RCC-based encapsulation ID checks between RIB and FIB databases and verify the respective Checks Performed output.

Before you begin

Ensure you have access to the Cisco 8000 router.
Confirm that you have permission to run diagnostic show commands.

Follow these steps to perform cross-layer encap ID and route summary consistency checks:

Procedure

Enter the rcc ipv4 unicast enable command to enable the background scan for IPv4 to automatically check and report encapsulation ID errors.
Example:
```
Router(config)# rcc ipv4 unicast enable
```
Use the rcc ipv6 unicast enable command to enable the scan for IPv6.

Execute the show rcc ipv4 unicast statistics to review the statistics of the background scans.

Example:

Router# show rcc ipv4 unicast statistics
Fri Aug 14 08:07:33.471 UTC

Background Scan Summary
=======================


Scan enabled:           True             Last scan-id:  64
Configured period:      15000            Current period: 15000

Paused By:
  route churn:False  on-demand scan:False  error scan:False

Last data sent: 0 entries                Damping percent:       70
Default route churn:    100              Current route churn:   0
Route churn last calculated at           Fri Aug 14 08:07:33 2026
Logs last cleared at                     Never

Scan paused by ISSU                      False

Logs stored for background scan ids:  60  61  62  63  64

Scan Logs
=========
Legend:
        ? - Currently Inactive Node, ! - Non-standard SVD Role
        * - Node did not reply
        PI-DLB - PI Destination based Load-Balancing (uni-path)

Scan ID: 60      Error log entries: 0    Status: Done
Start: Fri Aug 14 08:00:25 2026          End: Fri Aug 14 08:00:55 2026
   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0


---------------------------------------------------------------------------

Scan ID: 61      Error log entries: 0    Status: Done
Start: Fri Aug 14 08:02:00 2026          End: Fri Aug 14 08:02:30 2026
   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0


---------------------------------------------------------------------------

Scan ID: 62      Error log entries: 0    Status: Done
Start: Fri Aug 14 08:03:35 2026          End: Fri Aug 14 08:04:05 2026
   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0


---------------------------------------------------------------------------

Scan ID: 63      Error log entries: 0    Status: Done
Start: Fri Aug 14 08:05:10 2026          End: Fri Aug 14 08:05:40 2026
   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0


---------------------------------------------------------------------------

Scan ID: 64      Error log entries: 0    Status: Done
Start: Fri Aug 14 08:06:45 2026          End: Fri Aug 14 08:07:15 2026
   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0


---------------------------------------------------------------------------

End of Logs

Encap IDs are not validated on the active RP because the active RP is the source that generates them. As a result, the checks reported for 0/RP0/CPU0 reflect only prefix verification. Therefore, 0/RP0/CPU0 shows fewer checks performed than the other nodes.

Execute the show rcc ipv4 unicast statistics summary command to view a high-level summary of the most recent RCC background scans.

Example:

Router# show rcc ipv4 unicast statistics summary
Fri Aug 14 08:08:58.502 UTC

Background Scan Summary
=======================

Scan enabled:           True             Last scan-id:  65
Configured period:      15000            Current period: 15000

Paused By:
  route churn:False  on-demand scan:False  error scan:False

Last data sent: 0 entries                Damping percent:       70
Default route churn:    100              Current route churn:   0
Route churn last calculated at           Fri Aug 14 08:08:58 2026
Logs last cleared at                     Never

Scan paused by ISSU                      False

Logs stored for background scan ids:  61  62  63  64  65

The number of consistency checks now include Encap ID checks.

RCC on-demand scan

The RCC on-demand scan enables immediate verification of routing consistency across all nodes in the system. By running the appropriate command, you can check which nodes participated in the scan, how many checks were performed, and whether any errors occurred.

This example shows how an on-demand scan is performed.

Router# show rcc ipv4 unicast all
Fri Aug 14 08:11:56.268 UTC
Sending scan initiation request to IPv4 RIB ... done
....................complete (max time 600 seconds)..
Scan Completed
Collecting scan results from FIBs (max time 30 seconds)... done
Number of nodes involved in the scan: 4
Number of nodes replying to the scan: 4

Legend:
        ? - Currently Inactive Node, ! - Non-standard SVD Role
        * - Node did not reply
        PI-DLB - PI Destination based Load-Balancing (uni-path)

   Node                 Checks Performed                Errors

   0/RP1/CPU0               1671                             0
   0/0/CPU0                 1671                             0
   0/1/CPU0                 1671                             0
   0/RP0/CPU0                595                             0

By reviewing the scan output, you can immediately confirm the consistency status of routing tables and identify any nodes that require attention.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.