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

PDF

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

BGP RPKI-based origin validation on inbound iBGP prefixes

Updated: June 9, 2026

Want to summarize with AI?

Log in

Describes how BGP RPKI-based origin validations for iBGP updates strengthen internal BGP route security and help prevent propagation of invalid prefixes within an autonomous system.

A BGP Resource Public Key Infrastructure (RPKI)-based origin validation on Inbound Internal Border Gateway Protocol (iBGP) prefixes is a BGP security feature that

  • enables RPKI origin-AS validation for inbound iBGP route updates,

  • provides the validation state to routing policies, allowing administrators to filter prefixes marked as invalid, and

  • integrates with Cisco IOS XR BGP configuration, supporting global, VRF, or neighbor-level deployment for flexible enforcement.

You enable validation by configuring bgp origin-as validation allow-inbound-ibgp command in your BGP context, which references RPKI ROA data to assess origin-AS authorization for each prefix within internal routes.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

BGP RPKI-based origin validation on Inbound iBGP prefixes

 Release 26.2.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:Q100, Q200, P100])

You can now enhance internal routing security by validating iBGP-learned routes against RPKI origin-AS data. This provides validation states that can be used in routing policies to filter invalid routes, preventing the propagation of unauthorized prefixes within your network.

Key options and limitations for BGP RPKI-based origin validations for iBGP updates

Describes configuration choices, and important distinctions relevant to RPKI-based iBGP origin validations in Cisco IOS XR.

Main configuration options include:

  • Activating validation globally, per VRF, or per iBGP neighbor to target specific iBGP sessions

  • Disabling validation on selected neighbors using origin-as validation disable for flexibility

  • Using ROA databases and integrating with existing route policies

The following table compares iBGP and External Border Gateway Protocol (eBGP) origin validations:

Key limitations and requirements include:

  • Prefixes are validated against RPKI data, allowing administrators to configure routing policies that drop invalid prefixes while accepting those with a valid or not-found status.

  • Validation can be disabled per-neighbor for operational reasons

  • Not applied to outbound policies for eBGP neighbors

  • Requires Cisco IOS XR Release 26.2.1 or later

Note

TIP: Keep RPKI ROA data up to date to ensure accurate internal validation and to prevent acceptance of invalid or hijacked prefixes.

Restrictions for BGP RPKI-based origin validation on inbound iBGP prefixes

Provides information about Cisco platforms supporting BGP RPKI-based origin validation for iBGP updates. Details common operational restrictions for deployment and use.

The following list explains operational limitations and restrictions for deployment of BGP RPKI-based origin validation for iBGP updates:

  • Requires Cisco IOS XR Release 26.2.1 or later for feature use.

  • Validation is applied only to prefixes received via iBGP.

  • This feature utilizes a flexible policy mechanism that requires explicit configuration to enforce security. Because the feature does not automatically drop routes, you must define a routing policy to act upon the 'valid,' 'invalid,' or 'not-found' states assigned to each prefix. Consistent with eBGP inbound RPKI validation, this requirement ensures that prefix acceptance and installation in the BGP table are strictly governed by your defined security policies, necessitating that you explicitly reject 'invalid' prefixes to prevent their propagation while accepting those with 'valid' or 'not-found' status.

  • Validation can be selectively disabled on a per-neighbor basis using the origin-as validation disable command.

How BGP RPKI-based origin validation works for inbound iBGP prefixes

BGP RPKI-based origin validation for iBGP updates is a security process that verifies the authenticity of route prefixes learned from iBGP neighbors within an autonomous system. This process prevents propagation of iBGP routes with invalid Route Origin Authorization (ROA) status and helps safeguard the internal routing infrastructure.

  • Applies to BGP routers running Cisco IOS XR Release 26.2.1 or later that have access to current RPKI ROA data.

  • Validation can be configured at the global, VRF, or per-neighbor scope for iBGP sessions.

  • Administrators may disable validation for specific iBGP neighbors if required by operational considerations.

Summary

The key components involved in the process are:

  • BGP process: Validates the origin-AS of prefixes in iBGP updates using RPKI-based origin validation, following configuration settings.

  • RPKI ROA database: Supplies authoritative records to assess the ROA validity of each route prefix.

  • Administrator: Configures, manages, and, where necessary, exempts specific neighbors or sessions from origin validation.

Once iBGP RPKI origin validation is enabled, the router compares each iBGP-learned prefix against the RPKI ROA database. By default, this process only assigns a validation state—valid, invalid, or not-found—to the prefix. The router does not automatically drop prefixes based on this state; if filtering or specific handling is required, the administrator must explicitly configure a routing policy using an RPL (Routing Policy Language) or other BGP knobs to accept or drop routes based on their validation results.

Workflow

These stages describe how BGP RPKI-based origin validation operates for iBGP updates within an autonomous system:

  1. Stage 1: Enabling the capability The administrator defines the scope where RPKI origin validation should be applied. At this stage, no validation checks are performed; the administrator is simply enabling the feature on the router. Action: Apply bgp origin-as validation allow-inbound-ibgp within the appropriate address-family context. Result: The router is now configured to perform validation on future iBGP updates.
  2. Stage 2: Performing the validation This stage occurs dynamically when the router receives an iBGP update. The router uses the configuration enabled in Stage 1 to process the incoming prefix. Action: The router compares the prefix’s origin-AS against the RPKI ROA database and assigns a validation state (Valid, Invalid, or Not-found). Result: The prefix is tagged with a validation state, which is then available for policy enforcement in the next stage.
  3. Stage 3: Defining the outcome (Optional) The router does not automatically drop prefixes marked as 'Invalid.' To enforce security, the administrator must configure a routing policy to act upon the validation state. Action: Apply a route-policy to the BGP neighbor or address-family that denies prefixes with an 'Invalid' validation state Result: Once the policy is applied, prefixes marked as 'Invalid' are dropped at ingress, while 'Valid' and 'Not-found' prefixes are accepted and eligible for internal propagation.
  4. Stage 4: Defining exclusions The administrator may configure exceptions, such as disabling origin validation for selected iBGP neighbors where required. Action: Apply origin-as validation disable within the relevant neighbor address-family context to exempt specific sessions from validation. Allowing exceptions supports maintenance events, migration plans, or selective testing. Result: Configured neighbors are exempted from origin validation checks.
  5. Stage 5: Maintaining accuracy The router monitors ROA data updates and triggers revalidation for affected prefixes to maintain security accuracy. Revalidation occurs automatically when the ROA database changes. This ongoing step ensures that routing decisions always reflect the latest, authoritative RPKI state. Result: The BGP routing table stays accurate and compliant with current RPKI validations.

Result

BGP RPKI-based origin validation for iBGP updates prevents acceptance and propagation of prefixes with invalid ROA status, helping maintain routing integrity and compliance within the autonomous system.

What’s next

For further configuration steps and troubleshooting, see related topics about configuring and validating BGP RPKI-based origin validation for iBGP updates.

Configure BGP RPKI-based origin validation for iBGP updates

This task enables RPKI origin validation for iBGP-learned prefixes on Cisco IOS XR Release 26.2.1 or later. Ensure the router has access to current RPKI ROA data before proceeding. You can enable validation globally, per VRF, or per-neighbor to suit your network design. Document any exceptions where validation is disabled for operational or troubleshooting purposes.

This task is for IOS XR routers acting as iBGP speakers within an AS where RPKI origin validation is mandated by regulatory, security, or organizational policy.

You can enable origin validation globally, per VRF, or on a per-neighbor basis to suit network design and operations. Disabling validation for certain neighbors may be required for exceptions or troubleshooting.

Before you begin

Before you begin, ensure the following prerequisites are met:

  • The router runs Cisco IOS XR Release 26.2.1 or later.

  • The router can reach up-to-date RPKI ROA data for valid route validation.

  • BGP neighbors and VRFs are configured as needed to determine validation scope.

Follow these steps to configure BGP RPKI-based origin validation for iBGP updates.

Procedure

1.

Enable iBGP RPKI validation globally for the IPv4 unicast address family.

Example:


Router(config)# router bgp 65001
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# bgp origin-as validation allow-inbound-ibgp
Router(config-bgp-af)# commit

This enables origin-AS validation for all inbound iBGP prefixes at the global BGP-level.

Global iBGP RPKI validation is active for inbound iBGP routes in the IPv4 unicast address-family.
2.

Enable iBGP RPKI validation for a specific VRF.

Example:


Router(config)# router bgp 65001
Router(config-bgp)# vrf VRF1
Router(config-bgp-vrf)# address-family ipv4 unicast
Router(config-bgp-vrf-af)# bgp origin-as validation allow-inbound-ibgp
Router(config-bgp-vrf-af)# commit

This applies origin-AS validation to iBGP prefixes for a particular VRF only.

iBGP RPKI validation is enforced for inbound updates within the specified VRF or VRFs.
3.

Disable origin validation for a specific iBGP neighbor.

Example:


Router(config)# router bgp 65001
Router(config-bgp)# neighbor 192.0.2.9
Router(config-bgp-nbr)# address-family ipv4 unicast
Router(config-bgp-nbr-af)# origin-as validation disable
Router(config-bgp-nbr-af)# commit

Excludes a specific iBGP neighbor from validation. Use this step only when required by operational policy or troubleshooting.

  • Remove origin-as validation disable to re-enable validation for the neighbor.

  • Document the justification for any neighbor removed from validation.

The specified neighbor is now excluded from RPKI origin validation for iBGP prefixes as configured.

When configuration is complete, iBGP updates are validated using current RPKI ROA data. Only prefixes with valid or not-found ROA status are accepted. Invalid prefixes are dropped from internal BGP routing, strengthening AS security and preventing route hijacks.