{"id":196,"date":"2026-08-13T00:00:00","date_gmt":"2026-08-12T20:30:00","guid":{"rendered":"https:\/\/www.anynet.ir\/blog\/%d8%a2%d9%85%d9%88%d8%b2%d8%b4-bgp-%d9%88-%d9%82%d8%a7%d8%a8%d9%84%db%8c%d8%aa-only-to-customer-otc-%d8%af%d8%b1-rfc-9234-%d8%a8%d8%b1%d8%a7%db%8c-cisco-ios-xr-en\/"},"modified":"2026-10-19T09:53:20","modified_gmt":"2026-10-19T06:23:20","slug":"%d8%a2%d9%85%d9%88%d8%b2%d8%b4-bgp-%d9%88-%d9%82%d8%a7%d8%a8%d9%84%db%8c%d8%aa-only-to-customer-otc-%d8%af%d8%b1-rfc-9234-%d8%a8%d8%b1%d8%a7%db%8c-cisco-ios-xr-en","status":"publish","type":"post","link":"https:\/\/www.anynet.ir\/blog\/en\/%d8%a2%d9%85%d9%88%d8%b2%d8%b4-bgp-%d9%88-%d9%82%d8%a7%d8%a8%d9%84%db%8c%d8%aa-only-to-customer-otc-%d8%af%d8%b1-rfc-9234-%d8%a8%d8%b1%d8%a7%db%8c-cisco-ios-xr-en\/","title":{"rendered":"RFC 9234 BGP Only-to-Customer (OTC) on IOS XR"},"content":{"rendered":"
<\/div>\n
\n
<\/div>\n
<\/div>\n<\/div>\n
\n
\n
\n

1. Introduction<\/h2>\n

1.1 Overview<\/h3>\n

Defined in RFC 9234, the BGP Only-to-Customer (OTC) attribute helps prevent and detect route leaks between Autonomous Systems (ASes), reducing the risk that an AS unintentionally provides transit between its Providers or Peers. OTC applies route-leak rules based on the BGP Role of each eBGP session. The operator configures the role from the perspective of the local AS. The neighbor configures its own role for the same session. For example, one side uses Provider and the other side uses Customer.<\/p>\n

OTC is complementary to Autonomous System Provider Authorization (ASPA), which is featured in the next XRdocs BGP tutorial, but does not replace it. OTC does not replace route policy, prefix filtering, or Resource Public Key Infrastructure (RPKI) Route Origin Validation either, because these features have different purposes. Route Origin Validation checks whether a Route Origin Authorization (ROA) permits an AS to originate a prefix. OTC uses the configured BGP Roles to prevent or detect advertisements in a direction that is not allowed.<\/p>\n

1.2 What is OTC?<\/h3>\n

Only-to-Customer (OTC) is an optional transitive BGP path attribute used for route-leak prevention and detection. It uses path attribute type code 35<\/code> and carries one four-octet AS number.<\/p>\n

When an eBGP router advertises a prefix to a downstream Customer, it marks the prefix with OTC. If an eBGP neighbor receives the OTC-marked route from its downstream Customer, it identifies the route as a route leak.<\/p>\n

\"OTC<\/p>\n

Figure 1. OTC marks a Customer-facing route and prevents an advertisement to another Provider.<\/em><\/p>\n

1.3 OTC local roles<\/h3>\n

OTC uses a local role for each eBGP session. The role defines the relationship of the local AS with the remote AS.<\/p>\n

The BGP Role Capability carries the configured local role. It uses capability code 9<\/code>. The eBGP neighbors exchange this capability in their BGP OPEN messages when the session starts. Each neighbor sends its own local role.<\/p>\n

The following table shows all OTC local roles and their meanings:<\/p>\n\n\n\n\n\n\n\n\n\n
Local role<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
Provider<\/td>\nThe local AS provides transit to the remote AS.<\/td>\n<\/tr>\n
Customer<\/td>\nThe local AS receives transit from the remote AS.<\/td>\n<\/tr>\n
Peer<\/td>\nThe two ASes exchange selected routes without providing transit to each other.<\/td>\n<\/tr>\n
Route Server (RS)<\/td>\nThe local system is a Route Server.<\/td>\n<\/tr>\n
Route Server Client (RS-Client)<\/td>\nThe local AS is a client of a Route Server.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The following local and remote role pairs are valid:<\/p>\n\n\n\n\n\n\n\n\n\n
Local role<\/th>\nRemote role<\/th>\n<\/tr>\n<\/thead>\n
Provider<\/td>\nCustomer<\/td>\n<\/tr>\n
Customer<\/td>\nProvider<\/td>\n<\/tr>\n
Peer<\/td>\nPeer<\/td>\n<\/tr>\n
Route Server<\/td>\nRoute Server Client<\/td>\n<\/tr>\n
Route Server Client<\/td>\nRoute Server<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Provider and Customer are a valid pair. For a Peer relationship, both routers use the Peer role. Provider and Peer are not a valid pair because the roles do not match.<\/p>\n

If both neighbors send the capability, the two roles must form a valid pair. If only one neighbor sends it, the result depends on whether loose or strict mode is used. Section 1.4 explains both modes.<\/p>\n

1.4 Loose and strict modes<\/h3>\n

OTC supports two modes for checking the roles exchanged between eBGP neighbors: loose mode and strict mode.<\/p>\n

Loose mode does not require the remote neighbor to send the BGP Role Capability. If only one neighbor sends the capability, the eBGP session can still be established. The OTC-enabled neighbor uses its configured local role for OTC processing. The remote role is inferred from the local role. For example, local role Provider implies remote role Customer. An inferred role does not confirm the configuration on the remote neighbor.<\/p>\n

Strict mode requires the remote neighbor to send the BGP Role Capability. In both modes, the two roles must form a valid pair when both neighbors send the capability. A missing capability in strict mode or an invalid role pair causes a Role Mismatch Notification (OPEN Message Error, code 2<\/code>, subcode 11<\/code>). In both cases, the eBGP session does not come up.<\/p>\n

\"A<\/p>\n

Figure 2. BGP Role Capability exchange between a Provider and a Customer in strict mode.<\/em><\/p>\n

The routers exchange their roles only when the session starts. A change to the configured OTC role resets the eBGP session. The routers then send new OPEN messages with the new roles.<\/p>\n

2. IOS XR implementation<\/h2>\n

The OTC feature described in this guide is supported starting with Cisco IOS XR Release 26.4.1. General BGP Route Server functionality is not supported in IOS XR, so the route-server<\/code> local role is not configurable. The Route Server rows in the tables that follow describe the behavior defined by RFC 9234.<\/p>\n

2.1 Configuring OTC roles<\/h3>\n

To enable OTC on an IOS XR eBGP session, configure otc-local-role<\/code> under the BGP neighbor configuration. The value defines the local role toward that neighbor. Configure each end from its own point of view. For a Provider-to-Customer relationship, the Provider uses local role provider<\/code>, and the Customer uses local role customer<\/code>.<\/p>\n

The configuration examples use AS numbers 65540<\/code>, 65545<\/code>, and 65550<\/code> from the RFC 5398 range reserved for documentation.<\/p>\n

Configuration example:<\/p>\n

router bgp 65540\n<\/span> neighbor X.X.X.X\n<\/span> remote-as 65545\n<\/span> otc-local-role { customer | provider | peer | route-server-client} [strict<\/mark>]\n<\/span><\/code><\/pre>\n
\"Topology<\/p>\n
Figure 3. OTC local roles on a Provider-to-Customer eBGP session.<\/em><\/p>\n
R1 is configured as Provider toward R2:<\/p>\n
router bgp 65545\n<\/span> neighbor 10.10.10.2\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R2 is configured as Customer toward R1:<\/p>\n
router bgp 65540\n<\/span> neighbor 10.10.10.1\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R3 is configured as Customer toward R5:<\/p>\n
router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R5 is configured as Provider toward R3:<\/p>\n
router bgp 65550\n<\/span> neighbor 11.11.11.3\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
2.2 Basic role verification<\/h3>\n
Use the detailed neighbor command on both routers. The following R1 output verifies the Provider-to-Customer role pair:<\/p>\n
RP\/0\/0\/CPU0:R1# show bgp neighbor 10.10.10.2 detail\n<\/span>BGP neighbor is 10.10.10.2\n<\/span> Remote AS 65540, local AS 65545, external link\n<\/span> Remote router ID 192.168.0.2\n<\/span> BGP state = Established\n<\/span> OTC Local Mode: Loose<\/mark>\n<\/span> OTC Local Role: Provider<\/mark>\n<\/span> OTC Remote Role: Customer (received)<\/mark>\n<\/span>Neighbor capabilities: Adv Rcvd\n<\/span> 4-byte AS: Yes Yes\n<\/span> Address family IPv4 Unicast: Yes Yes\n<\/span> OTC Role: Yes Yes\n<\/span><\/code><\/pre>\n
The local and remote roles must form a valid pair. received<\/code> means that the neighbor sent its role. Yes\/Yes<\/code> means that both routers sent the BGP Role Capability.<\/p>\n
2.3 Loose mode configuration and output<\/h3>\n
Loose mode is the default, so no additional keyword is required. In this example, R3 is configured as Customer toward R5, but no OTC role is configured on R5 toward R3.<\/p>\n
router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
If R5 does not send a BGP Role, R3 can keep the session up. R3 shows the remote role as inferred:<\/p>\n
RP\/0\/0\/CPU0:R3# show bgp neighbor 11.11.11.4 detail\n<\/span>BGP neighbor is 11.11.11.4\n<\/span> Remote AS 65550, local AS 65540, external link\n<\/span> Remote router ID 11.11.11.4\n<\/span> BGP state = Established\n<\/span> OTC Local Mode: Loose\n<\/span> OTC Local Role: Customer\n<\/span> OTC Remote Role: Provider (inferred)<\/mark>\n<\/span>Neighbor capabilities: Adv Rcvd\n<\/span> 4-byte AS: Yes Yes\n<\/span> Address family IPv4 Unicast: Yes Yes\n<\/span> OTC Role: Yes No\n<\/span><\/code><\/pre>\n
Loose mode can apply OTC processing when only one router advertises the BGP Role Capability. A missing capability means that the neighbor has no local role configured, which is not necessarily the same as the neighbor not supporting BGP Roles. The configured local role controls OTC processing on R3.<\/p>\n
2.4 Strict mode configuration and session reset<\/h3>\n
Strict mode is configured locally. It requires the remote eBGP neighbor to send the BGP Role Capability. The advertised roles must form a valid pair. In this example, strict mode is configured on both neighbors.<\/p>\n
R1 configuration:<\/p>\n
router bgp 65545\n<\/span> neighbor 10.10.10.2\n<\/span> otc-local-role provider strict<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R2 configuration:<\/p>\n
router bgp 65540\n<\/span> neighbor 10.10.10.1\n<\/span> otc-local-role customer strict<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
After the configuration is committed, IOS XR resets the eBGP session. The reset is required because the neighbors exchange their roles in the BGP OPEN message.<\/p>\n
%ROUTING-BGP-5-ADJCHANGE: neighbor 10.10.10.2 Down - OTC local role changed (CEASE notification sent - configuration change)\n<\/span>%ROUTING-BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up\n<\/span><\/code><\/pre>\n
After the session comes up, verify the mode and roles:<\/p>\n
RP\/0\/0\/CPU0:R1# show bgp neighbor 10.10.10.2 detail\n<\/span>BGP neighbor is 10.10.10.2\n<\/span> Remote AS 65540, local AS 65545, external link\n<\/span> Remote router ID 192.168.0.2\n<\/span> BGP state = Established\n<\/span> OTC Local Mode: Strict<\/mark>\n<\/span> OTC Local Role: Provider<\/mark>\n<\/span> OTC Remote Role: Customer (received)<\/mark>\n<\/span>Neighbor capabilities: Adv Rcvd\n<\/span> 4-byte AS: Yes Yes\n<\/span> Address family IPv4 Unicast: Yes Yes\n<\/span> OTC Role: Yes Yes\n<\/span><\/code><\/pre>\n
In strict mode, the session does not come up if the remote capability is missing. In either mode, the session does not come up if the roles do not form a valid pair. For example, changing R2 to Provider while R1 is also Provider creates a mismatch:<\/p>\n
router bgp 65540\n<\/span> neighbor 10.10.10.1\n<\/span> otc-local-role provider strict<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R1 reports the resulting mismatch:<\/p>\n
RP\/0\/0\/CPU0:R1# show bgp neighbor 10.10.10.2 detail | include \"Last reset\"\n<\/span> Last reset 00:00:06, due to BGP Notification sent: OTC role mismatch<\/mark>\n<\/span><\/code><\/pre>\n
2.5 OTC rules<\/h3>\n
The OTC rules define how a router processes the OTC attribute based on the role of the eBGP neighbor. Three ingress rules apply when a route is received. Two egress rules apply when a route is advertised. The rules define when OTC is added, when a route becomes ineligible, and when a route must not be advertised.<\/p>\n\n\n\n\n\n\n\n\n\n
Rule<\/th>\nDirection<\/th>\nCondition<\/th>\nRequired action<\/th>\n<\/tr>\n<\/thead>\n
IR1<\/td>\nIngress<\/td>\nOTC is present on a route from a Customer or RS-Client.<\/td>\nThe leaked path is not accepted for BGP route selection and is not advertised to other BGP neighbors.<\/td>\n<\/tr>\n
IR2<\/td>\nIngress<\/td>\nOTC is present on a route from a Peer, and OTC is not equal to the remote AS number.<\/td>\nThe leaked path is not accepted for BGP route selection and is not advertised to other BGP neighbors.<\/td>\n<\/tr>\n
IR3<\/td>\nIngress<\/td>\nOTC is absent on a route from a Provider, Peer, or RS.<\/td>\nAdd OTC with the remote AS number.<\/td>\n<\/tr>\n
ER1<\/td>\nEgress<\/td>\nOTC is absent on a route sent to a Customer, Peer, or RS-Client.<\/td>\nAdd OTC with the local AS number.<\/td>\n<\/tr>\n
ER2<\/td>\nEgress<\/td>\nOTC is present on a route sent to a Provider, Peer, or RS.<\/td>\nDo not advertise the route.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
RFC 9234 applies these ingress and egress procedures only to the IPv4 and IPv6 unicast address families (AFI 1 and AFI 2 with SAFI 1). They are not applied to other address families by default. Once OTC has been set, its value is preserved unchanged.<\/p>\n
2.5.1 Ingress Rule 1 (IR1)<\/h4>\n
When a prefix with OTC is received from a Customer or RS-Client, it is identified as a route leak. The leaked path is not accepted for BGP route selection and is not advertised to other BGP neighbors.<\/p>\n
R4 and R3 are configured as Providers. R5 is configured as Customer only toward R3; no OTC role is configured on R5 toward R4:<\/p>\n
! R5\n<\/span>router bgp 65550\n<\/span> neighbor 11.11.11.3\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span>! R4\n<\/span>router bgp 65540\n<\/span> neighbor 12.12.12.4\n<\/span> otc-local-role provider<\/mark>\n<\/span> address-family ipv4 unicast\n<\/span> soft-reconfiguration inbound always<\/mark>\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span>! R3\n<\/span>router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
\"R4<\/p>\n
Figure 4. R4 identifies an OTC-marked route received from Customer R5 as a route leak.<\/em><\/p>\n
R5 sends an OTC-marked prefix to R4. R4 receives the prefix from its Customer and identifies it as a route leak. The path is not accepted or advertised to another BGP neighbor.<\/p>\n
The lab deliberately allowed the same AS to be received again so the leak could be reproduced. allowas-in<\/code> was enabled on R4 under the neighbor address family, and R5 disabled the outbound AS_PATH<\/code> loop check:<\/p>\n
! R4\n<\/span>router bgp 65540\n<\/span> neighbor 12.12.12.4\n<\/span> address-family ipv4 unicast\n<\/span> allowas-in\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span>! R5\n<\/span>router bgp 65550\n<\/span> address-family ipv4 unicast\n<\/span> as-path-loopcheck out disable\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
\n
Note:<\/strong> These loop-prevention exceptions are only for lab testing and should not be used in a production network.<\/p>\n<\/blockquote>\n
The neighbor counters and BGP debug identify IR1 as the rejection reason:<\/p>\n
RP\/0\/0\/CPU0:R4# show bgp ipv4 unicast neighbors 12.12.12.4 detail | include \"OTC ingress|denied\"\n<\/span> Exact no. of prefixes denied: 56<\/mark>\n<\/span> Cumulative no. of prefixes denied: 112\n<\/span> By OTC ingress rule 1: 112, By OTC ingress rule 2: 0<\/mark>\n<\/span>RP\/0\/0\/CPU0:R4# debug bgp update in\n<\/span>Prefix 18.18.18.0\/24 received from 12.12.12.4 DENIED due to OTC ingress rule 1: route leak from Customer\/RS-Client<\/mark>\n<\/span><\/code><\/pre>\n
The route can appear as received-only<\/code> when inbound soft reconfiguration stores it. The route must not become eligible.<\/p>\n
RP\/0\/0\/CPU0:R4# show bgp 18.18.18.0\/24 detail\n<\/span>Paths: (3 available, best #1)\n<\/span> Path #2: Received by speaker 0\n<\/span> Not advertised to any peer\n<\/span> 65550 65540, (received-only)<\/mark>\n<\/span> 12.12.12.4 from 12.12.12.4 (11.11.11.4)\n<\/span> Origin incomplete, localpref 100, valid, external\n<\/span> OTC-AS: 65540\n<\/span><\/code><\/pre>\n
2.5.2 Ingress Rule 2 (IR2)<\/h4>\n
When a prefix with OTC is received from a Peer, the OTC AS number must be equal to the remote Peer AS number. If the values are different, the prefix is identified as a route leak and becomes ineligible.<\/p>\n
For this test, R4 uses the local Peer role in loose mode and R5 does not advertise a BGP Role toward R4. R4 therefore applies Peer ingress processing to the route received from R5:<\/p>\n
! R4\n<\/span>router bgp 65540\n<\/span> neighbor 12.12.12.4\n<\/span> otc-local-role peer<\/mark>\n<\/span>!\n<\/span>!\n<\/span>! R5\n<\/span>router bgp 65550\n<\/span> neighbor 12.12.12.5\n<\/span> no otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
\"R4<\/p>\n
Figure 5. R4 rejects a Peer route because OTC does not equal remote AS 65550.<\/em><\/p>\n
R5 advertises a path whose OTC value is 65540<\/code>. Because R5 is in remote AS 65550<\/code>, R4 rejects the path under IR2:<\/p>\n
RP\/0\/0\/CPU0:R4# show bgp ipv4 unicast neighbors 12.12.12.4 detail | include \"OTC ingress|denied\"\n<\/span> Exact no. of prefixes denied: 56\n<\/span> Cumulative no. of prefixes denied: 56\n<\/span> By OTC ingress rule 1: 0, By OTC ingress rule 2: 56<\/mark>\n<\/span>RP\/0\/0\/CPU0:R4# debug bgp update in\n<\/span>Prefix 18.18.18.0\/24 received from 12.12.12.4 DENIED due to OTC ingress rule 2: OTC AS mismatch from Peer<\/mark>\n<\/span>RP\/0\/0\/CPU0:R4# show bgp 18.18.18.0\/24 detail\n<\/span>Paths: (3 available, best #1)\n<\/span> Path #2: Received by speaker 0\n<\/span> Not advertised to any peer\n<\/span> 65550 65540, (received-only)\n<\/span> 12.12.12.4 from 12.12.12.4 (11.11.11.4)\n<\/span> Origin incomplete, localpref 100, valid, external\n<\/span> OTC-AS: 65540<\/mark>\n<\/span><\/code><\/pre>\n
If the OTC AS number is not equal to the remote AS number, 65550<\/code>, the route becomes ineligible. A route with OTC-AS: 65550<\/code> passes the IR2 rule.<\/p>\n
2.5.3 Ingress Rule 3 (IR3)<\/h4>\n
When a prefix without OTC is received from a Provider, Peer, or RS, the receiving router adds OTC. The OTC AS number is set to the remote AS number.<\/p>\n
R2 is configured with the local Customer role toward R1. No OTC role is configured on R1. In loose mode, R2 therefore infers R1’s remote role as Provider. R1 sends the route without the OTC attribute:<\/p>\n
router bgp 65540\n<\/span> neighbor 10.10.10.1\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span>! R1 has no configured OTC role toward R2.\n<\/span><\/code><\/pre>\n
\"R2<\/p>\n
Figure 6. R2 adds remote AS 65545 to an unmarked route received from Provider R1.<\/em><\/p>\n
The R2 BGP table confirms that IR3 stored the AS number of the inferred Provider in OTC:<\/p>\n
RP\/0\/0\/CPU0:R2# show bgp 192.168.0.1\/32 detail\n<\/span>Paths: (1 available, best #1)\n<\/span> 65545\n<\/span> 10.10.10.1 from 10.10.10.1 (10.10.10.1)\n<\/span> Origin incomplete, metric 0, localpref 100, valid, external, best, group-best\n<\/span> OTC-AS: 65545<\/mark>\n<\/span><\/code><\/pre>\n
The UPDATE arrived without OTC. The stored route contains the remote AS number 65545<\/code>. This confirms that R2 applied the IR3 rule. If OTC is already present, the router does not change its value.<\/p>\n
2.5.4 Egress Rule 1 (ER1)<\/h4>\n
When a prefix is advertised to a Customer, Peer, or RS-Client, add the OTC attribute if it is not present. Set the OTC AS number to the local AS number.<\/p>\n
R3 is configured as Provider toward R5, and R5 is configured as Customer toward R3:<\/p>\n
! R3\n<\/span>router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span>! R5\n<\/span>router bgp 65550\n<\/span> neighbor 11.11.11.3\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
\"R3<\/p>\n
Figure 7. R3 adds its local AS number before it sends the route to Customer R5.<\/em><\/p>\n
No OTC role is configured on the R1-R2 session for this test, so the prefix reaches AS 65540 without OTC and no ingress rule marks it. When R3 advertises the prefix to its Customer R5, ER1 adds OTC with the local AS number of R3. R5 receives the prefix with OTC-AS: 65540<\/code>.<\/p>\n
\n
Note:<\/strong> If R2 kept the Customer role used in the IR3 example, R2 would add OTC-AS: 65545<\/code> on ingress. R3 would then preserve that value instead of adding its own, because ER1 only adds OTC when the attribute is absent.<\/p>\n<\/blockquote>\n
The route output on R5 shows the complete AS path and OTC value:<\/p>\n
RP\/0\/0\/CPU0:R5# show bgp 192.168.0.1\/32 detail\n<\/span>Paths: (2 available, best #1)\n<\/span> 65540 65545<\/mark>\n<\/span> 11.11.11.3 from 11.11.11.3 (192.168.0.3)\n<\/span> Origin incomplete, localpref 100, valid, external, best, group-best\n<\/span> OTC-AS: 65540<\/mark>\n<\/span><\/code><\/pre>\n
OTC is added to the route advertised from R3 to R5. The route stored on R3 does not have to contain OTC.<\/p>\n
2.5.5 Egress Rule 2 (ER2)<\/h4>\n
When a prefix with OTC is advertised to a Provider, Peer, or RS, the advertisement is blocked. This prevents the local AS from becoming a transit AS by mistake.<\/p>\n
R3 and R4 are configured as Providers toward R5. R5 is configured as Customer toward both routers:<\/p>\n
R3 configuration:<\/p>\n
router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R5 configuration:<\/p>\n
router bgp 65550\n<\/span> neighbor 11.11.11.3\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span> neighbor 12.12.12.5\n<\/span> otc-local-role customer<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R4 configuration:<\/p>\n
router bgp 65540\n<\/span> neighbor 12.12.12.4\n<\/span> otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
R3 advertises the prefix to Customer R5 with OTC-AS: 65540<\/code>. Egress Rule 2 prevents R5 from advertising the OTC-marked prefix to its other Provider, R4.<\/p>\n
\"Egress<\/p>\n
Figure 8. R5 does not advertise an OTC-marked route to its other Provider, R4.<\/em><\/p>\n
Confirm that R5 has received the OTC-marked route from R3. R5 can still use the route, but ER2 prevents it from advertising the route to R4:<\/p>\n
RP\/0\/0\/CPU0:R5# show bgp 192.168.0.1\/32 detail\n<\/span>Paths: (2 available, best #1)\n<\/span> Not advertised to any peer\n<\/span> Path #1: Received by speaker 0\n<\/span> Not advertised to any peer\n<\/span> 65540 65545\n<\/span> 11.11.11.3 from 11.11.11.3 (192.168.0.3)\n<\/span> Origin incomplete, localpref 100, valid, external, best, group-best\n<\/span> OTC-AS: 65540<\/mark>\n<\/span> Path #2: Received by speaker 0\n<\/span> Not advertised to any peer\n<\/span> 65540 65545\n<\/span> 12.12.12.5 from 12.12.12.5 (192.168.0.5)\n<\/span> Origin incomplete, localpref 100, valid, external\n<\/span> OTC-AS: 65540\n<\/span><\/code><\/pre>\n
Path #1 is the best path received from R3, so R5 can install and use it. Both paths carry OTC-AS: 65540<\/code>, confirming that they are OTC-marked. Not advertised to any peer<\/code> shows that R5 does not advertise the OTC-marked path to its other Provider, R4. This is the expected ER2 behavior.<\/p>\n
2.6 OTC rules table<\/h3>\n
The following table covers all combinations, with and without OTC, when both roles are configured or one role is inferred in loose mode. The first column describes the route before egress processing. Configured<\/code> means that the router has a local role and applies the OTC rules. Inferred<\/code> means that the other router derives this missing role from its own configured role; the router with the inferred role does not apply role-based OTC processing.<\/p>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
OTC present?<\/th>\nSender role<\/th>\nReceiver role<\/th>\nSender action<\/th>\nReceiver action<\/th>\n<\/tr>\n<\/thead>\n
No<\/td>\nProvider (configured)<\/td>\nCustomer (configured)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nAccept the route with OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nProvider (configured)<\/td>\nCustomer (configured)<\/td>\nAdvertise and preserve OTC.<\/td>\nAccept the route with OTC unchanged.<\/td>\n<\/tr>\n
No<\/td>\nProvider (configured)<\/td>\nCustomer (inferred)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nNo role-based ingress action; receive the route with OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nProvider (configured)<\/td>\nCustomer (inferred)<\/td>\nAdvertise and preserve OTC.<\/td>\nNo role-based ingress action; receive the route with OTC.<\/td>\n<\/tr>\n
No<\/td>\nProvider (inferred)<\/td>\nCustomer (configured)<\/td>\nNo role-based egress action; advertise without OTC.<\/td>\nAdd the remote Provider AS number as OTC (IR3).<\/td>\n<\/tr>\n
Yes<\/td>\nProvider (inferred)<\/td>\nCustomer (configured)<\/td>\nNo role-based egress action; advertise with OTC unchanged.<\/td>\nAccept the route with OTC unchanged.<\/td>\n<\/tr>\n
No<\/td>\nCustomer (configured)<\/td>\nProvider (configured)<\/td>\nAdvertise without adding OTC.<\/td>\nAccept the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nCustomer (configured)<\/td>\nProvider (configured)<\/td>\nDo not advertise the route (ER2).<\/td>\nIf received contrary to ER2, make the route ineligible (IR1).<\/td>\n<\/tr>\n
No<\/td>\nCustomer (configured)<\/td>\nProvider (inferred)<\/td>\nAdvertise without adding OTC.<\/td>\nNo role-based ingress action; receive the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nCustomer (configured)<\/td>\nProvider (inferred)<\/td>\nDo not advertise the route (ER2).<\/td>\nNo route is received.<\/td>\n<\/tr>\n
No<\/td>\nCustomer (inferred)<\/td>\nProvider (configured)<\/td>\nNo role-based egress action; advertise without OTC.<\/td>\nAccept the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nCustomer (inferred)<\/td>\nProvider (configured)<\/td>\nNo role-based egress action; advertise with OTC unchanged.<\/td>\nMake the route ineligible (IR1).<\/td>\n<\/tr>\n
No<\/td>\nPeer (configured)<\/td>\nPeer (configured)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nAccept the route because OTC equals the remote AS.<\/td>\n<\/tr>\n
Yes<\/td>\nPeer (configured)<\/td>\nPeer (configured)<\/td>\nDo not advertise the route (ER2).<\/td>\nIf received contrary to ER2, accept only when OTC equals the remote Peer AS; otherwise, make it ineligible (IR2).<\/td>\n<\/tr>\n
No<\/td>\nPeer (configured)<\/td>\nPeer (inferred)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nNo role-based ingress action; receive the route with OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nPeer (configured)<\/td>\nPeer (inferred)<\/td>\nDo not advertise the route (ER2).<\/td>\nNo route is received.<\/td>\n<\/tr>\n
No<\/td>\nPeer (inferred)<\/td>\nPeer (configured)<\/td>\nNo role-based egress action; advertise without OTC.<\/td>\nAdd the remote Peer AS number as OTC (IR3).<\/td>\n<\/tr>\n
Yes<\/td>\nPeer (inferred)<\/td>\nPeer (configured)<\/td>\nNo role-based egress action; advertise with OTC unchanged.<\/td>\nAccept only when OTC equals the remote Peer AS; otherwise, make it ineligible (IR2).<\/td>\n<\/tr>\n
No<\/td>\nRS (configured)<\/td>\nRS-Client (configured)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nAccept the route with OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nRS (configured)<\/td>\nRS-Client (configured)<\/td>\nAdvertise and preserve OTC.<\/td>\nAccept the route with OTC unchanged.<\/td>\n<\/tr>\n
No<\/td>\nRS (configured)<\/td>\nRS-Client (inferred)<\/td>\nAdd the local AS number as OTC (ER1).<\/td>\nNo role-based ingress action; receive the route with OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nRS (configured)<\/td>\nRS-Client (inferred)<\/td>\nAdvertise and preserve OTC.<\/td>\nNo role-based ingress action; receive the route with OTC.<\/td>\n<\/tr>\n
No<\/td>\nRS (inferred)<\/td>\nRS-Client (configured)<\/td>\nNo role-based egress action; advertise without OTC.<\/td>\nAdd the remote RS AS number as OTC (IR3).<\/td>\n<\/tr>\n
Yes<\/td>\nRS (inferred)<\/td>\nRS-Client (configured)<\/td>\nNo role-based egress action; advertise with OTC unchanged.<\/td>\nAccept the route with OTC unchanged.<\/td>\n<\/tr>\n
No<\/td>\nRS-Client (configured)<\/td>\nRS (configured)<\/td>\nAdvertise without adding OTC.<\/td>\nAccept the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nRS-Client (configured)<\/td>\nRS (configured)<\/td>\nDo not advertise the route (ER2).<\/td>\nIf received contrary to ER2, make the route ineligible (IR1).<\/td>\n<\/tr>\n
No<\/td>\nRS-Client (configured)<\/td>\nRS (inferred)<\/td>\nAdvertise without adding OTC.<\/td>\nNo role-based ingress action; receive the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nRS-Client (configured)<\/td>\nRS (inferred)<\/td>\nDo not advertise the route (ER2).<\/td>\nNo route is received.<\/td>\n<\/tr>\n
No<\/td>\nRS-Client (inferred)<\/td>\nRS (configured)<\/td>\nNo role-based egress action; advertise without OTC.<\/td>\nAccept the route without OTC.<\/td>\n<\/tr>\n
Yes<\/td>\nRS-Client (inferred)<\/td>\nRS (configured)<\/td>\nNo role-based egress action; advertise with OTC unchanged.<\/td>\nMake the route ineligible (IR1).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
The two roles cannot both be inferred on the same session. At least one router must have a configured local role before it can infer the remote role. Inferred<\/code> is a local display convention: no Role Capability was received, and the unconfigured neighbor does not apply OTC processing of its own. An inferred role does not confirm the configuration or behavior of the remote neighbor.<\/p>\n
3. RPL: OTC role per prefix<\/h2>\n
The otc-local-role<\/code> configured under a neighbor is the default role for all prefixes on the eBGP session. Routing Policy Language (RPL) can override the default role for prefixes matched by a route policy. This allows different prefix groups on the same session to use different OTC processing. An inbound route policy selects the local role used by the ingress OTC rules for each matched prefix. An outbound route policy selects the local role used by the egress OTC rules.<\/p>\n
The override applies to local OTC processing only. The BGP Role Capability is still negotiated once per session, so a per-prefix role is not verified with the neighbor. RFC 9234 Section 6 describes this trade-off: BGP Roles must not be configured on a session with a Complex peering relationship, and an operator who instead uses per-prefix policies has no in-band way to check that both ends agree.<\/p>\n
3.1 Configuration<\/h3>\n
The RPL attach point is under the neighbor address-family configuration. A route policy can be attached inbound or outbound:<\/p>\n
router bgp (local-as-number)\n<\/span> neighbor (neighbor-address)\n<\/span> address-family (ipv4-or-ipv6) unicast\n<\/span> route-policy (route-policy-name) (in-or-out)<\/mark>\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
The RPL action supports these local roles and is used inside a route policy:<\/p>\n
route-policy otc_out\n<\/span> if...\n<\/span> set otc-local-role { customer | provider | peer | route-server-client}<\/mark>\n<\/span> else\n<\/span>...\n<\/span> endif\n<\/span>end-policy\n<\/span><\/code><\/pre>\n
An outbound set otc-local-role<\/code> action selects the local role used for Egress Rule 1 and Egress Rule 2. For a matched prefix, the RPL role takes precedence over the otc-local-role<\/code> configured under the neighbor.<\/p>\n
The following example shows how RPL changes the neighbor role for one prefix. R5 has the local Customer role toward both R3 and R4. This is the default role for prefixes that do not match the policies. For 192.168.0.1\/32<\/code>, the inbound policy changes R5’s local role from Customer to Provider when R5 receives the route from R3. The outbound policy changes the role from Customer to Peer when R5 sends the route toward R4.<\/p>\n
\"A<\/p>\n
Figure 9. A route policy overrides the neighbor-level Customer role on R5 for one prefix.<\/em><\/p>\n
Step 1: Check the default roles and behavior<\/h4>\n
R5 has the neighbor-level Customer role toward both routers:<\/p>\n
RP\/0\/0\/CPU0:R5# show running-config formal | include otc\n<\/span>router bgp 65550 neighbor 11.11.11.3 otc-local-role customer<\/mark>\n<\/span>router bgp 65550 neighbor 12.12.12.5 otc-local-role customer<\/mark>\n<\/span><\/code><\/pre>\n
Before the RPL policies are attached, the OTC-marked paths are not advertised because R5 uses its default Customer role:<\/p>\n
RP\/0\/0\/CPU0:R5# show bgp 192.168.0.1\/32\n<\/span>Paths: (2 available, best #1)\n<\/span> Not advertised to any peer\n<\/span> Path #1: Received by speaker 0\n<\/span> Not advertised to any peer<\/mark>\n<\/span> 65540 65545\n<\/span> 11.11.11.3 from 11.11.11.3 (192.168.0.3)\n<\/span> Origin incomplete, localpref 100, valid, external, best, group-best\n<\/span> OTC-AS: 65540\n<\/span> Path #2: Received by speaker 0\n<\/span> Not advertised to any peer<\/mark>\n<\/span> 65540 65545\n<\/span> 12.12.12.5 from 12.12.12.5 (192.168.0.5)\n<\/span> Origin incomplete, localpref 100, valid, external\n<\/span> OTC-AS: 65540\n<\/span><\/code><\/pre>\n
Step 2: Remove the Provider role on R3<\/h4>\n
Remove R3’s neighbor-level Provider role:<\/p>\n
router bgp 65540\n<\/span> neighbor 11.11.11.4\n<\/span> no otc-local-role provider<\/mark>\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
If this role is not removed, R3 adds OTC before it sends the route to R5. R5 then receives an already-marked route, and the test does not clearly show the inbound RPL action.<\/p>\n
Step 3: Configure and attach the RPL policies<\/h4>\n
OTC_complex_pfx<\/code> selects 192.168.0.1\/32<\/code>. The inbound policy makes R5 use local role Provider for that prefix when it is received from R3. The outbound policy makes R5 use local role Peer for the same prefix when it is advertised toward R4:<\/p>\n
prefix-set OTC_complex_pfx\n<\/span> 192.168.0.1\/32<\/mark>\n<\/span>end-set\n<\/span>!\n<\/span>route-policy OTC_complex_in\n<\/span> if destination in OTC_complex_pfx then\n<\/span> set otc-local-role provider<\/mark>\n<\/span> else\n<\/span> pass\n<\/span> endif\n<\/span>end-policy\n<\/span>!\n<\/span>route-policy OTC_complex_out\n<\/span> if destination in OTC_complex_pfx then\n<\/span> set otc-local-role peer<\/mark>\n<\/span> else\n<\/span> pass\n<\/span> endif\n<\/span>end-policy\n<\/span>!\n<\/span>router bgp 65550\n<\/span> neighbor 11.11.11.3\n<\/span> address-family ipv4 unicast\n<\/span> route-policy OTC_complex_in in<\/mark>\n<\/span>!\n<\/span>!\n<\/span> neighbor 12.12.12.5\n<\/span> address-family ipv4 unicast\n<\/span> route-policy OTC_complex_out out<\/mark>\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
The policy applies these rules:<\/p>\n\n\n\n\n\n\n\n\n
Direction and neighbor<\/th>\nMatch<\/th>\nEffective local role<\/th>\nRoute treatment<\/th>\n<\/tr>\n<\/thead>\n
Inbound from R3 (11.11.11.3<\/code>)<\/td>\n192.168.0.1\/32<\/code><\/td>\nProvider<\/td>\nR5 treats R3 as a Customer for this prefix. The unmarked route is accepted without adding OTC.<\/td>\n<\/tr>\n
Outbound to R4 (12.12.12.5<\/code>)<\/td>\n192.168.0.1\/32<\/code><\/td>\nPeer<\/td>\nR5 treats R4 as a Peer, adds OTC-AS: 65550<\/code>, and advertises the route.<\/td>\n<\/tr>\n
Inbound from R3 (11.11.11.3<\/code>)<\/td>\nAny other prefix<\/td>\nCustomer (neighbor default)<\/td>\nR5 treats R3 as a Provider. If OTC is absent, R5 adds OTC-AS: 65540<\/code>.<\/td>\n<\/tr>\n
Outbound to R4 (12.12.12.5<\/code>)<\/td>\nAny other prefix<\/td>\nCustomer (neighbor default)<\/td>\nR5 treats R4 as a Provider. ER2 blocks the OTC-marked route.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
After the policies are attached, verify both a non-matching prefix and the matching prefix. The non-matching prefix 192.168.1.1\/32<\/code> still uses the default Customer role and is not advertised. The matching prefix 192.168.0.1\/32<\/code> uses the RPL roles and is advertised toward R4:<\/p>\n
RP\/0\/0\/CPU0:R5# show bgp 192.168.1.1\/32 detail\n<\/span>Paths: (2 available, best #1)\n<\/span> Not advertised to any peer<\/mark>\n<\/span>RP\/0\/0\/CPU0:R5# show bgp 192.168.0.1\/32\n<\/span>Paths: (2 available, best #1)\n<\/span> Advertised IPv4 Unicast paths to peers (in unique update groups):<\/mark>\n<\/span> 12.12.12.5\n<\/span> Path #1: Received by speaker 0\n<\/span> 65540 65545\n<\/span> 11.11.11.3 from 11.11.11.3 (192.168.0.3)\n<\/span> Origin incomplete, localpref 100, valid, external, best, group-best\n<\/span><\/code><\/pre>\n
Step 4: Verify the outbound attributes<\/h4>\n
Normal eBGP processing prepends the R5 AS number 65550<\/code> to the AS path. The Peer role selected by the outbound policy then causes ER1 to add OTC-AS: 65550<\/code>:<\/p>\n
RP\/0\/0\/CPU0:R5# show bgp advertised neighbor 12.12.12.5\n<\/span>192.168.0.1\/32 is advertised to 12.12.12.5\n<\/span> Path info:\n<\/span> neighbor: 11.11.11.3 neighbor router id: 192.168.0.3\n<\/span> valid external best\n<\/span> Attributes after inbound policy was applied:\n<\/span> next hop: 11.11.11.3\n<\/span> origin: incomplete neighbor as: 65540\n<\/span> aspath: 65540 65545\n<\/span> Attributes after outbound policy was applied:\n<\/span> next hop: 12.12.12.4\n<\/span> origin: incomplete neighbor as: 65540\n<\/span> aspath: 65550 65540 65545<\/mark>\n<\/span> OTC-AS: 65550<\/mark>\n<\/span><\/code><\/pre>\n
The output confirms that RPL overrides the neighbor-level OTC role only for the selected prefix. R4 still applies its own configured local role on ingress, so its role determines whether the received route is accepted.<\/p>\n
4. Preserving OTC across networks<\/h2>\n
RFC 9234 requires that, once the OTC attribute has been set, it is preserved unchanged. The attribute tells each downstream eBGP neighbor that the route may be advertised only to Customers. If OTC is removed or changed, another eBGP neighbor may advertise the route to a Provider or Peer and create a route leak. Removing it also hides the information that other networks use to detect the leak. For this reason, filtering or modifying OTC weakens the protection provided by RFC 9234, as explained in Cloudflare’s article on the RFC 9234 BGP role model<\/a>.<\/p>\n
<\/svg><\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
1. Introduction 1.1 Overview Defined in RFC 9234, the BGP Only-to-Customer (OTC) attribute helps prevent and detect route leaks between Autonomous Systems (ASes), reducing\u2026<\/p>\n","protected":false},"author":1,"featured_media":194,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[130,69,37],"tags":[],"class_list":["post-196","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bgp-en","category-iosxr-en-en","category-security-en"],"_links":{"self":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/comments?post=196"}],"version-history":[{"count":1,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/196\/revisions"}],"predecessor-version":[{"id":198,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/196\/revisions\/198"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/media\/194"}],"wp:attachment":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/media?parent=196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/categories?post=196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/tags?post=196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}