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

PDF

BGP Accept Own

Updated: February 28, 2026

Want to summarize with AI?

Log in

Overview

Describes BGP Accept Own feature, covering preference mechanisms in best path selection, processing of Accept Own routes in BGP VPN configurations, and step-by-step procedures to enable BGP Accept Own in deployments.

A BGP Accept Own mechanism is a BGP routing feature that

  • allows a BGP speaker to accept VPN routes that it originally advertised but receives back from a route-reflector

  • uses the special ACCEPT_OWN community attribute to bypass standard self-origination filters such as ORIGINATOR_ID and NEXTHOP checks, and

  • enables centralized control of route imports across VRFs in MPLS VPN environments without requiring configuration changes on provider edge routers.

Default BGP route rejection behavior:

By default, according to BGP protocol (RFC 4271), a BGP speaker rejects routes it originated if they are returned by a route-reflector.

BGP Accept Own:

The BGP Accept Own feature changes this behavior: when the ACCEPT_OWN community is attached to a prefix (by a route-reflector via an outbound route-policy), it signals the receiving router to accept the reflected route even if it originally advertised that prefix. This is especially valuable in MPLS VPN extranets, where route import/export must be managed centrally.

Use case: Extranet auto-configuration in MPLS VPNs:

One primary use case is auto-configuration of extranets within MPLS VPNs. Conventionally, controlling route imports between VRFs for extranets requires updating import route-targets or policies on each PE router. With BGP Accept Own, route-reflectors can manage which prefixes are imported between VRFs without additional PE configuration. This approach makes operations more scalable and flexible.

Route-reflector handling and community propagation

Route-reflectors attach the ACCEPT_OWN community when advertising selected prefixes to the originating PE. The addition of this community should be limited to outbound policies targeting only the originator, to avoid unnecessary propagation. The InterAS route-reflector may also adjust the set of route targets (RTs) when sending routes with the ACCEPT_OWN community. This enables precise control over which VRFs receive the reflected routes.

Preference for Accept Own community in best path selection

Once the Accept Own community is attached to a route and propagated by a route reflector, remote PE routers apply these best path selection rules.

  • The best path algorithm prefers a route that contains the Accept Own community over one that does not.

  • This preference is evaluated immediately before the IGP metric comparison step in the best path selection process.

  • If a remote PE receives an Accept Own path from one route reflector and a non-Accept Own path from another, and both paths are otherwise identical, it selects the Accept Own path.

  • After a path is selected, the import process operates on the Accept Own path.

This behavior ensures that when multiple otherwise identical routes exist, routes with the Accept Own community are consistently preferred during best path selection on remote PEs.

How Accept Own routes are processed in BGP VPN configurations

Summary

The key components involved in the process are:

  • Customer edge (CE) router: A router that originates the desired prefix to the provider network.

  • Provider edge (PE) router: A router that owns both the customer VRF and service VRF, participates in BGP VPN address families, and communicates with route reflectors.

  • Intra-AS route reflector (IntraAS-RR): A route reflector (RR) that reflects routes within the same autonomous system.

  • Inter-AS route reflector (InterAS-RR): An RR that adds the ACCEPT_OWN community and updates route targets before reflecting the route further.

A customer prefix is advertised from the CE to the PE, then reflected through multiple route reflectors. During this process, route targets and the ACCEPT_OWN community are added. The PE ultimately installs the prefix in the service VRF with updated attributes, enabling precise control over route import between VRFs.

Workflow

Figure 1. BGP Accept Own configuration example

These stages describe how Accept Own routes are processed in BGP VPN configurations:

  1. Prefix origination: The CE router advertises prefix X to the PE.
  2. Customer VRF installation: The PE installs prefix X in the Customer VRF as (RD1:X).
  3. Initial advertisement to route reflector: The PE advertises prefix X to the IntraAS-RR as (RD1:X, RT1).
  4. Inter-cluster reflection: The IntraAS-RR sends the route to the InterAS-RR as (RD1:X, RT1).
  5. Community and route target update: The InterAS-RR attaches RT2 to prefix X on inbound and adds the ACCEPT_OWN community on outbound, then advertises the route to another IntraAS-RR.
  6. Reflection back to PE: The second IntraAS-RR advertises the updated prefix to the PE.
  7. Service VRF installation: The PE installs prefix X in the Service VRF with new route targets and the ACCEPT_OWN community (RD2:X, RT1, RT2, ACCEPT_OWN).

Result

The Accept Own process allows the same PE to import its own originated VPN prefixes into a different VRF. This supports extranet configurations with policy-driven control managed by the route reflector, without requiring modification of import policies or route targets on the PE.

Configure BGP Accept Own

Enable the BGP Accept Own feature so that the router accepts self-originated VPN routes containing the Accept_Own community attribute.

Before you begin

  • Collect the required neighbor IP address, remote autonomous system number, and determine which address-family (VPNv4 or VPNv6) requires Accept Own.

Procedure

1.

Enter BGP configuration mode, specify the BGP neighbor, and enable Accept Own for the neighbor.

Example:

Router# configure
Router(config)# router bgp 100
Router(config-bgp)# neighbor 192.0.2.3
Router(config-bgp-nbr)# remote-as 100
Router(config-bgp-nbr)# update-source Loopback0
Router(config-bgp-nbr)# address-family vpnv6 unicast
Router(config-bgp-nbr-af)# accept-own
2.

(Optional) Use the inheritance-disable keyword to prevent inheritance of Accept Own from parent configuration.

Example:


Router(config-bgp-nbr-af)# accept-own inheritance-disable

This example shows how to configure BGP Accept Own on a PE router.

router bgp 100
neighbor 10.1.1.1
remote-as 100
update-source Loopback0 address-family vpnv4 unicast
route-policy pass-all in accept-own
route-policy drop_111.x.x.x out
!
address-family vpnv6 unicast route-policy pass-all in accept-own
route-policy drop_111.x.x.x out
!
!

This example shows an InterAS-RR configuration for BGP Accept Own.

router bgp 100
neighbor 192.0.2.45
remote-as 100
update-source Loopback0 address-family vpnv4 unicast
route-policy rt_stitch1 in route-reflector-client route-policy add_bgp_ao out
!
address-family vpnv6 unicast route-policy rt_stitch1 in route-reflector-client route-policy add_bgp_ao out
!
!
extcommunity-set rt cs_100:1 100:1
end-set
!
extcommunity-set rt cs_1001:1 1001:1
end-set
!
route-policy rt_stitch1
if extcommunity rt matches-any cs_100:1 then set extcommunity rt cs_1000:1 additive
endif
end-policy
!
route-policy add_bgp_ao
set community (accept-own) additive end-policy
!