eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent BGP Roles — OTC Attributes, Route Leaks and Safe Propagation

—

by

eduKate Asia

A BGP route leak occurs when a network advertises reachability beyond the relationships that permit it. RFC 9234 tackles this with two coordinated mechanisms: neighbouring networks can confirm their Provider, Customer, Peer or route-server roles when a BGP session begins, and a route can carry an Only to Customer (OTC) attribute that restricts where it may travel next. For a networked AI agent, the practical lesson is that an apparently reachable service is not proof that the Internet path to it follows the intended routing policy.

The short answer is to distinguish a correct destination from a permitted route. BGP Roles make neighbouring autonomous systems check their relationship; OTC gives downstream routers an explicit clue that a learned prefix must not be passed back uphill or sideways. The method can prevent several common route-leak patterns or make leaked updates ineligible. It does not encrypt traffic, prove an origin’s authorization, authenticate every forwarding hop, or establish that artificial superintelligence exists.

This guide follows the May 2022 IETF specification, RFC 9234, and the earlier route-leak classification in RFC 7908. It uses an original, expressly hypothetical network with documentation-only addresses and private-number autonomous systems. Every numerical count below is a worked illustration, not a measurement of deployment or real-world incident rates. The aim is to help a reader follow UPDATE handling, diagnose a routing-policy mistake, and decide where human supervision of automated network operations is essential.

In this guide:

Why a valid destination can still take the wrong path

Imagine an automated research service fetching a document from an institution it trusts. The URL is correct, the institutional service is real and the server might even present a valid TLS certificate. The packets still need interdomain routes. A small network can accidentally advertise a prefix learned from one upstream provider to another upstream provider, turning itself into a transit path that nobody intended. The chosen path may become longer, overloaded, unstable or poorly observed. Application credentials alone do not reveal that change.

The Border Gateway Protocol, or BGP, exchanges reachability between autonomous systems. An autonomous system, abbreviated AS, is a routing domain identified by an autonomous system number, or ASN. Its neighbours decide which routes to accept, prefer and propagate. This exchange is not a universal statement that every path is contractually or operationally permitted. Policies ordinarily reflect customer–provider and peer relationships. A router can learn a usable route and nevertheless be wrong to advertise it to a particular neighbour.

RFC 7908 describes several kinds of route leaks, including a multihomed customer passing one provider’s route to another, two peers passing a route through a third peer, and leaking a peer’s routes to a transit provider. A leak is fundamentally a scope violation: a routing announcement escaped a domain where it was meant to circulate. It need not involve a forged origin ASN. That distinction matters because an origin-validation check can say that the origin is authorized while the intermediate propagation remains against policy.

An AI system choosing tools or endpoints benefits from noticing the distinction, but its model predictions cannot substitute for a router’s routing table, operator policy and independently collected telemetry. If an agent notices abnormal latency, it may ask for a network check, compare geographically independent probes and flag an uncertain dependency. It must not infer from a single slowdown that a route leak happened. Congestion, DNS answers, origin-server incidents and transit failures can produce similar outward symptoms.

Start with the five roles and one simple export rule

RFC 9234 names five local roles for normal eBGP relationships: Provider, Customer, Peer, Route Server (RS), and Route Server Client (RS-Client). These describe the relationship as seen from one end of a session. When network A sells transit to network B, A sees itself as Provider and B sees itself as Customer. At a lateral peering arrangement, both see Peer. A route server and its client have their own reciprocal pair, rather than being mistaken for two peers or a normal provider–customer contract.

The central export intuition is sometimes called valley-free routing. A customer may advertise its own prefixes and its customers’ routes towards a provider or peer. A provider may announce available routes to customers, subject to additional local policy. A peer normally does not offer to carry another peer’s or its provider’s routes to yet another peer or provider. These statements describe which propagation is permitted in the model, not which advertisements any commercial operator is obliged to send. A restrictive prefix filter can exclude further routes.

For example, suppose AS64511 has one upstream transit provider, AS64520, and its own downstream client, AS64512. AS64511 can ordinarily announce its local prefix and routes from AS64512 to AS64520. If AS64511 learns a distant prefix from AS64520, sending that provider-learned route to another provider would violate the ordinary customer export constraint. The role of the neighbour receiving a route is therefore as important as the identity of its origin.

The route server terms are frequently misunderstood. A route server at an Internet exchange helps its clients exchange announcements without acting exactly like an ordinary transit provider in the data plane. The Route Server role may propagate available routes to its RS-Clients under the standard’s model, whereas an RS-Client may ordinarily send its locally originated or customer-learned routes to the route server. Treating these roles as interchangeable with Peer can create an incorrect export policy.

What the BGP OPEN capability actually checks

BGP neighbours establish a session and exchange OPEN messages before normal routing updates. RFC 9234 defines BGP Role Capability code 9. The capability has a one-octet role value. The standard assigns value 0 to Provider, 1 to RS, 2 to RS-Client, 3 to Customer and 4 to Peer. These are protocol labels for the speaker’s local role, not priority rankings, security scores or route weights.

Corresponding pairs are constrained: Provider must pair with Customer; Customer with Provider; RS with RS-Client; RS-Client with RS; and Peer with Peer. Suppose AS64520 configures its neighbour AS64511 as a customer while AS64511 declares its own role as Peer. Those assertions do not match. Where both exchange the capability, a speaker must reject the connection with a Role Mismatch notification, OPEN error code 2 and subcode 11. This is intended to prevent silent disagreement about the business-shaped policy model.

Receipt of the capability is not itself the check. The two advertised values must form an allowed pair, and the local configuration must describe the real intended relation. Two operators who mistakenly agree that a provider–customer link is a peer relationship can still make an incorrect policy choice. The negotiation confirms agreement between declared roles; it cannot independently inspect contracts, the organization’s intent or whether the networks have several exceptional prefix-specific arrangements.

Backward compatibility matters. If a role-capable speaker sends the capability but the other does not return it, RFC 9234 ordinarily says to continue rather than break the session, using the locally configured role for OTC procedures. An operator can choose stricter behaviour that requires a role response, but making strict mode the automatic default is discouraged because software changes or gradual deployment can unexpectedly prevent connectivity. Monitoring session capability negotiation is therefore different from forcing all old neighbours offline.

A practical inventory should record each eBGP neighbour, the locally intended role, the partner’s expected reciprocal role, whether role capability appeared, whether the pair matched, and whether a strict-mode requirement was knowingly agreed. That record is useful before an outage because it turns a vague claim that BGP broke into a falsifiable diagnosis: no OPEN? role mismatch? capability missing? or UPDATE rejected later because of OTC? These are different states with different repairs.

What the Only to Customer attribute means

BGP Roles deal with how two neighbours describe a session. The OTC attribute deals with the route advertisement itself. RFC 9234 defines OTC as optional and transitive BGP Path Attribute code 35 with a four-octet value containing an ASN. The compact value helps routers decide whether a route has crossed a relationship boundary after which its further travel should be limited to customers. The value is not an expiry timestamp, certificate, traffic classification or a signed statement of origin legitimacy.

The key moment is when a route ceases travelling only from customers towards providers and begins travelling sideways to a peer, through a route server, or downwards to a customer. When the advertised route has no OTC yet, the specified procedures can attach an ASN that marks that turning point. Later compliant hops preserve the value unchanged. In ordinary terms: after the marker appears, do not send the marked route uphill to a provider or sideways to a peer or route server.

There are important details behind that simplification. A network receiving a route from a Provider, Peer or RS without OTC must add OTC with the ASN of that remote neighbour. On transmission to a Customer, Peer or RS-Client, a network that is about to advertise a route lacking OTC must add OTC with its own ASN. Either action can make early deployments more robust even when an adjacent network has not yet implemented the new behaviour.

OTC does not identify a particular document fetch, model query or application user. It belongs to interdomain routing announcements, not the HTTP request. A model cannot read an OTC field from a URL, and a network monitoring dashboard cannot infer the actual application payload from the field alone. The appropriate connection to automated agents is operational: a system relying on network services should be prepared for routing-policy faults and should escalate them to systems and people with access to authoritative routing evidence.

Three ingress checks: what happens when a route arrives

On receipt from a Customer or RS-Client, if the route already carries OTC, RFC 9234 requires the receiving router to consider it ineligible. Why? A marked route was already meant to continue only downwards. A customer advertising it uphill is now violating that direction, so the upstream network should not treat it as a candidate for its local routing selection. Ineligible has a specific BGP meaning; it does not necessarily mean the neighbour session itself is torn down.

For a route received from a Peer, the OTC value has an extra consistency check. If OTC exists but does not equal the remote peer’s ASN, the route must be ineligible. A peer presenting an OTC value from someone farther away is evidence that a marked route passed sideways again. If the value does equal the remote peer’s ASN, that particular test does not disqualify the route, although other routing policies and validity checks still apply.

For routes received from a Provider, Peer or RS without OTC, the compliant receiver inserts OTC using the ASN of that remote AS. Think of it as restoring the marker at the trust boundary when the sending side omitted one. This behaviour explains why partial deployment can still detect a subsequent leak: a compliant receiver has enough local role knowledge to mark the imported route even when the neighbour has not adopted RFC 9234.

Do not turn these rules into a simplistic rule that every route carrying OTC is invalid. A router may legitimately accept an OTC-marked route from its provider and send it to its own customers. The forbidden directions depend on the local relationship. The distinction between a route being eligible on receipt and eligible for particular onward advertisements is precisely what a useful troubleshooting flow must preserve.

Two egress checks: what a router may announce next

Before a router sends an UPDATE to a Customer, Peer or RS-Client, it checks for an OTC attribute. If the attribute is absent, the router must attach OTC with its own ASN. This can occur even though the original route came from a customer and was acceptable to share with a peer; the marker records that the route is now entering the restricted portion of its permitted propagation path.

If OTC is already present, the router must not advertise that route to Providers, Peers or route servers. By contrast, sending the marked route to ordinary customers can remain permitted under the RFC’s mechanism and any stricter local export filters. Once attached, OTC must stay unchanged. A network that rewrites the value to make a prohibited peer advertisement appear newly sourced would defeat the intended signal.

Here is a simple distinction. A customer-originated prefix travelling from customer AS64510 to provider AS64520 can be announced upward without an OTC field if normal export policy allows it. When AS64520 then sends that prefix to peer AS64540, OTC=64520 is attached. Peer AS64540 can send it to its customers but not to another peer or its provider. The prefix’s origin did not change; the allowed direction of further propagation did.

The standard’s ingress and egress procedures are narrowly scoped to IPv4 unicast and IPv6 unicast, using AFI 1 or 2 with SAFI 1. Do not assume they automatically apply to every VPN, multicast, labelled address family or internal routing convention. Special situations including AS confederations, private AS-number arrangements and migrations require attention to the exact RFC conditions, not casual extension of the most familiar diagram.

A worked six-network example using documentation addresses

Consider an invented network containing origin AS64510, its provider AS64520, peer AS64540, downstream customer AS64550 of AS64540, further customer AS64551 of AS64550, and upstream provider AS64560 of AS64550. All AS numbers here are illustrative private-range numbers. The prefix 192.0.2.0/24 belongs to the documentation range, not to a real service being advertised on the public Internet. None of the following packet paths is a claim about an observed operator.

First, origin AS64510 tells its provider AS64520 about 192.0.2.0/24. Under normal local-origin export policy, that advertisement is allowed, assuming the relationship and all other filters are correct. There is no reason for AS64510 to add OTC solely because it sent an originated prefix towards its provider. Whether the prefix origin is cryptographically authorized is an entirely separate origin-validation question.

Second, AS64520 offers the learned route to peer AS64540. Both ends agree their role is Peer. At egress, AS64520 attaches OTC=64520 if the field is absent. At ingress, AS64540 sees the OTC value equal to the ASN of its remote peer, AS64520. This passes the special peer-ingress test. The route remains a candidate, subject to normal route selection and any further filters.

Third, AS64540 advertises the route to its customer AS64550. It must carry the same OTC value, 64520. AS64550 is allowed to receive the marked route from its provider, AS64540. It may pass that route to one of its own customers under ordinary customer-facing rules. Notice that neither the subsequent speaker’s ASN nor the destination prefix changes the existing OTC marker.

Fourth, imagine AS64550 is multihomed and tries to export the same marked route to a different transit provider, AS64560. A compliant AS64550 refuses this egress because the route already has OTC. If that local protection is absent, AS64560 has another opportunity: it recognizes the route as coming from its customer AS64550 with an OTC field and must make it ineligible. This is a two-stage defence, not two different mathematical proofs that the prefix is malicious.

Fifth, imagine AS64540 tries to send the same marked route sideways to another peer, AS64570. A compliant sender blocks the egress. If a noncompliant sender transmits the attribute unchanged, AS64570 receives a peer update with OTC=64520 although the remote peer is AS64540. The peer-ingress equality check fails, so the candidate is ineligible. A sender that deliberately strips or tampers with OTC can undermine this protection; the attribute is not a cryptographic signature.

The operative distinction is visible in both prohibited cases. The receiver is checking something about the relationship and how the route travelled, not whether 192.0.2.0/24 resolves to a useful web server. Likewise, a machine-learning traffic optimiser may rank transit paths for cost or latency but must not overwrite the administrative constraints that stop a peer-learned route becoming unapproved transit. Better prediction cannot replace an export policy.

Counted casework: seven attempted advertisements

For a hand-checkable exercise, start with exactly seven proposed transmissions, not seven measured Internet incidents. Case one is local origin AS64510 to provider AS64520, permitted subject to other controls. Case two is AS64520 to peer AS64540, permitted with OTC set to 64520. Case three is AS64540 to customer AS64550, permitted while preserving OTC. Case four is AS64550 to its own customer AS64551, permitted if that customer relation really exists and the usual filters allow the prefix.

Case five is AS64550 to provider AS64560 while carrying OTC=64520: prohibited. Case six is AS64540 to another peer AS64570 while carrying OTC=64520: prohibited. Case seven is an incorrectly configured AS64540 sending an unmarked provider-learned route to AS64570. That last case is not made safe by absence of OTC; the ordinary export rule still forbids it, and a role-aware compliant ingress peer that receives an unmarked update adds OTC with the neighbour’s ASN, helping constrain future propagation.

The denominator is seven hypothetical proposed announcements. Four are allowed under the stated relationship conditions, two are immediately prohibited by the marked-OTC egress rule, and the seventh is prohibited by the foundational export policy even though an OTC marker is missing. The count is therefore four permitted out of seven and three disallowed out of seven. It is not a success-rate estimate or evidence that protection automatically blocks three-sevenths of real leaks.

Now change only one premise: suppose AS64540 has a customer-originated route from its own downstream client, without any earlier OTC marker. It can announce that route to a peer and must add OTC=64540 when doing so. A receiving peer that checks equality against remote ASN 64540 will not disqualify the route solely because OTC is present. The subsequent peer still cannot pass it to an additional peer or provider. This changed route source tests whether the reader understands the relationship boundary rather than memorising one fixed ASN.

A second changed premise is that AS64560 receives AS64550’s bad update without an OTC value because a noncompliant intermediary removed it. The incoming provider cannot prove the route leaked merely from a missing marker. It needs its import filters, neighbour/customer-cone records, path telemetry and other protections. This is why a useful test suite must include intentional attribute deletion and unexpected old implementations as well as happy-path propagation.

Different symptoms demand different diagnoses

If an eBGP session refuses to establish, inspect the OPEN negotiation before blaming OTC. Check the configured local role, the received reciprocal role, role capability support, strict-mode setting and any Role Mismatch notification. A provider declaring Provider while the neighbour declares Peer is an OPEN-stage disagreement. It is not an UPDATE carrying a wrong attribute length or a dropped HTTP request. The repair is to establish the intended relationship and correct configuration on the appropriate side.

If the session is healthy but certain routes disappear from the eligible candidate set, inspect UPDATE handling. Determine whether an OTC field was present, the neighbour’s local role, the remote ASN and whether the arrival was from Customer, RS-Client or Peer. With a peer, compare OTC to that peer’s ASN; with a customer, any OTC at ingress invokes the standard’s disqualification rule. Record whether a candidate was made ineligible rather than reporting a blanket physical link failure.

If the attribute length is malformed, RFC 9234 uses the BGP error-handling approach called treat-as-withdraw, referring to RFC 7606. This is a specific response to a malformed UPDATE attribute, not permission for an operator to delete the marker and continue exporting the offending route. Because treat-as-withdraw itself may affect forwarding, consider the network’s failure mode, alerts and rollback plan. Changes to parsing, export filters and route selection should be verified in a laboratory or staged environment.

If a traceroute looks unusual but BGP sessions and OTC checks look correct, investigate independently. Traceroute probes may follow different forwarding paths, be rate-limited or omit some routers; application-layer delay can originate elsewhere. Correlate route collectors, RIB history, neighbour logs, origin validation, prefix filters and observed customer impact. An AI diagnostic assistant should explicitly distinguish an observation from its inferred cause and preserve uncertainty until appropriate evidence supports a repair.

How to introduce roles without breaking old neighbours

A careful rollout begins with a verified relationship inventory. Operators should know who provides transit, who buys it, who peers laterally, which sessions connect to route servers, and whether any connection has exceptional prefix-specific rules. Because the BGP Role describes the relationship as a whole, applying one role to a genuinely mixed session may be wrong from the beginning. The inventory should come from agreement with counterparties and configuration review, not automatically inferred from routing-path appearance.

Next, compare device and software support, role capability negotiation, expected peer behaviour, and any platform limitations. Build cases for matching Provider/Customer, matching Peer/Peer, RS/RS-Client, missing capabilities, mismatched values and duplicate inconsistent capabilities. A backward-compatible neighbour that does not negotiate a role must not be treated as proof that all OTC protections vanished; the locally configured relationship can still guide ingress and egress procedures.

Use low-risk monitored rollout windows and explicit change records. Establish session baselines, routes accepted, routes rejected, prefix counts and the forwarding impact of newly ineligible candidates. Sample representative peers and customers. Do not turn on strict mode for every peer merely because the capability exists. A change may be formally correct under the RFC yet operationally surprising where old software, undocumented relationships or mislabelled business arrangements remain.

After rollout, retain rollback conditions and alert ownership. A reduction in advertisements might reflect proper route-leak prevention, but an unexplained sudden reduction might equally indicate a wrongly declared role. Check the affected relationship and prefixes rather than simply removing OTC to restore route volume. An unreviewed emergency bypass could transform a recoverable connectivity mistake into a wider leak.

Route servers and the limits of a simple peer diagram

Route-server arrangements introduce a common transfer challenge. An Internet exchange route server commonly distributes routing information among participants while not necessarily carrying the customers’ data traffic. RFC 9234 therefore has explicit RS and RS-Client roles. The route server may announce available routes to its clients, while a client ordinarily announces locally originated or customer-learned routes to the server. These are not simply Peer/Peer declarations with a friendlier name.

The OTC rules explicitly mention both sides. An RS-Client receiving a route from an RS without OTC adds the ASN of the route server as required. A route with OTC received from an RS-Client is ineligible at the route server. An RS that sends an unmarked route to its RS-Client inserts OTC with its own ASN under the egress procedure. These particular checks use the administrative relationship, not an assumption that the route server is a normal transit ISP.

A wrong route-server role can therefore produce unexpectedly missing announcements even when every involved ASN and prefix looks plausible. Engineers should test the specific incoming and outgoing role labels in the exchange environment and confirm whether the path is already OTC-marked. Avoid copying conventional lateral peer templates into a route-server session without verifying the semantics of each advertised route and the implementation’s actual support.

There is a broader design lesson for automated systems. A routing protocol has a vocabulary for roles because seemingly similar connections permit different operations. Application agents also need explicit role, permission and trust-boundary descriptions, but the two layers are not interchangeable. A document-search bot should not declare itself a route server, and a route server cannot grant the bot permission to expose customer data. Technical metaphors are useful only while keeping the real protocol boundaries intact.

What if the same two networks have mixed relationships?

A complex peering relationship is one in which the two ASes have more than one role depending on prefixes or services. For example, one network might buy transit for a selected subset while also peering laterally for another subset. RFC 9234 instructs operators not to configure a BGP Role on an eBGP session with such a complex relationship. The protocol’s single role would not faithfully capture the actual routing policy.

If the mixed relationship can be separated into multiple eBGP sessions, each with a normal and clearly defined role, the RFC recommends assigning roles to those sessions. Otherwise, operators may need per-prefix policies; that alternative loses the in-band reciprocal role confirmation that applies to the simple relationships. This is not a defect to hide with a guessed role. It is a scope limit to document before the change.

A useful pre-change interview asks: does every advertised prefix on this session follow the same Customer, Provider, Peer, RS or RS-Client policy? Can any prefix legitimately take the other relationship? Is the remote operator expecting the same classification? If the answers are mixed or disputed, the correct immediate action is not to enforce a simplistic role. Record the exception, design an appropriate split or filtering plan and obtain reciprocal agreement.

In a network with hundreds of connections, auto-classifying every link from traffic direction would be tempting. That is unreliable because commercial and routing relationships do not necessarily align with observed byte counts, and the RFC’s terminology does not require proving monetary payment. Automation can suggest inventory discrepancies but should request confirmation rather than independently rewrite peering roles on production routers.

What OTC solves that origin validation does not

RPKI Route Origin Validation and OTC ask different questions. Origin validation compares an announced prefix and origin ASN against verified route-origin authorization information. RFC 9234 asks whether a learned route is being propagated through permitted relationships. A perfectly authorized prefix can be leaked from one provider to another. Conversely, an OTC-consistent route can still have a bogus origin claim. Treating either check as a complete substitute for the other leaves a different class of routing mistake unanswered.

The eduKate article Agent RPKI Route Origin Validation — ROAs, VRPs and Safe BGP Routing explains the origin side in depth. Read it as a complement, not a repetition of the same mechanism. An operator may run origin validation, prefix and AS-path filters, route leak controls, session protections, network telemetry and conservative application error handling together. Each has its own evidence, scope and possible false operational assumptions.

OTC is not cryptographically protected end-to-end. RFC 9234 explicitly notes that removing the field or changing its value can make subsequent leak detection harder. A malicious AS on the path might deliberately tamper with it. The capability agreement also does not validate every contract or force all interdomain networks to deploy the feature. A method that improves default propagation safety should not be advertised as a complete solution to global BGP trust.

Nor does routing policy provide confidentiality for an application payload. Transport authentication and encryption, DNS security, credentials and authorization have distinct purposes. An AI service may need both routing-policy observability and application security. When modelling threat scenarios, separate accidental bad export, deliberate OTC removal, origin impersonation, session disruption, and compromised application credentials. Combining them into one vague category called unsafe network would produce poor diagnosis and inappropriate remediation.

A practical failure test and repair sequence

Start in a non-production or tightly controlled change environment with an explicit map of neighbouring ASNs and intended relationships. Use documentation prefixes, not accidentally live global routes. Record at least the remote ASN, local role, expected reciprocal role, current capability advertisement, direction of each proposed route, original OTC presence and value, and the expected eligible or ineligible outcome. This creates a reproducible contract for testing a router implementation or a configuration change.

Test a normal Provider/Customer capability pair and an ordinary Peer/Peer pair before attempting fault injection. Deliberately introduce an inconsistent pair in the laboratory and confirm the correct Role Mismatch behaviour. Next test an unsupported peer with no capability and document whether the local device continues in a compatible mode. Finally test strict mode only where it was specifically authorized, including its failure when the remote capability is absent.

For UPDATE processing, test a provider-learned unmarked route and confirm that the receiving compliant network adds OTC equal to the provider’s ASN. Test a peer-learned marked route with OTC equal to the peer ASN, then deliberately change the value to another ASN and confirm ineligibility. Test an OTC-marked route arriving from a customer and confirm ineligibility. Test an OTC-marked route being prepared for export to a provider or peer and confirm that no announcement is made.

Include negative and boundary tests. A malformed OTC length is not a normal four-octet value and should trigger the specified error handling. A route legitimately going from provider to customer while carrying OTC should not be rejected merely because OTC exists. An address family outside the defined IPv4/IPv6 unicast scope should not quietly inherit procedures the RFC does not specify. A complex peering session must not be made artificially normal by a default guess.

When results differ, diagnose in order. First verify the physical and protocol session state, including role capability exchange. Second check inbound route and attributes. Third check candidate eligibility and best-path selection. Fourth check outbound filtering and export rules. Fifth correlate the result with customer observations. A failure in step three should not be repaired by disabling encryption at the application layer, and a failure in step one should not be repaired by stripping attributes from unrelated UPDATE messages.

Every repair should identify a specific violated expectation and include a rollback plan. If a production session drops because strict mode was enabled before reciprocal support was confirmed, the repair may involve restoring the agreed compatible posture while carefully validating roles. If a route is correctly rejected as a leak, the repair lies with the upstream export policy, not with the detecting router’s decision to ignore OTC. Keep evidence of the rejected update so that the cause can be discussed with the responsible operator.

Where an AI agent helps, and where a human must decide

An operational agent can organize evidence without being a routing authority. It can read permitted inventory records, compare role pairs, annotate a sequence of BGP events, and produce a proposed diagnosis that engineers can verify. In an incident, it can distinguish role mismatch from a prefix withdrawn under treat-as-withdraw, and compare the BGP picture with service metrics. Its strongest contribution is reducing the time required to assemble relevant, time-stamped facts, not bypassing administrative change control.

An agent should keep a strict line between observation, inference and action. It may observe that a customer-facing BGP session accepted fewer prefixes after a configuration change. It may infer that role or OTC handling is worth checking. It should not conclude that the neighbour is malicious or immediately rewrite export filters. Before applying a network change, require a named human owner, an approved configuration diff, a documented blast radius, a monitored maintenance window and a tested rollback.

For high-impact actions, protect credentials and restrict tool calls to scoped operations. A troubleshooting assistant might have read-only access to route tables and change tickets while needing separate approval to alter live BGP neighbours. Logging should preserve the relevant prefixes and role decisions without exposing unrelated customer secrets. A model-generated diagnostic can be a useful input to a change review but cannot certify that a route policy is commercially or legally correct.

The word superintelligence in this series is a subject of inquiry, not a claim about existing deployed artificial superintelligence. Today’s tool-using systems may assist with network understanding, but their outputs need verification. A stronger hypothetical future system would still need to respect the formal BGP role semantics and the real administrative authority of network operators. More sophisticated reasoning does not grant permission to change another organization’s routing policy.

Changed-context transfer problem: a provider becomes a peer

Here is a harder fictional exercise. AS64580 is initially a Customer of AS64590. It receives a remote prefix from AS64590 with OTC=64590. AS64580 has its own downstream customer AS64581. Under the defined normal relations, AS64580 may propagate the marked route to AS64581, keeping OTC unchanged. It must not advertise the marked route to another provider. These conclusions follow from the attribute and role, not the prefix’s popularity or importance.

Now suppose AS64580 and AS64590 renegotiate to become ordinary lateral Peers on the same eBGP session. Their BGP Role declarations should change from Customer/Provider to Peer/Peer after they agree on policy. The pre-existing route with OTC=64590 can still pass the peer ingress comparison at AS64580 because the remote peer ASN is exactly 64590. But if a route arrives from AS64590 with OTC=64570, AS64580 must mark it ineligible: a marked route from a different earlier AS should not be passed sideways again.

Next add a hidden constraint: half their prefixes still follow the original transit-provider arrangement, while the other half are newly peered. This has become a complex relationship. A single Peer role on the shared session would misstate the actual policy, and a single Customer role would misstate the lateral portion. RFC 9234 does not allow BGP Roles on that complex session. The safe design question is whether the two classes can be separated into normal-role sessions or need independently reviewed per-prefix filters.

Finally let the remote partner stop sending the role capability after a software update. A locally configured role may still guide the RFC’s OTC procedures in compatible mode; automatic strict-mode refusal is not necessarily the right operational response. The correct change-review question is whether strict matching had been agreed and whether the role inventory is still valid. This problem combines changing business relations, attribute values, incomplete rollout and human change authority; solving only the arithmetic of ASN equality would not be enough.

To self-check, explain why an OTC value of 64590 is acceptable from peer AS64590 but a value of 64570 is not; explain why customer export remains different from peer export; and explain why a partly peered, partly transit relationship cannot simply inherit the same role. A correct explanation should also identify what data it cannot determine: the exact legitimate prefixes, contracts and actual traffic path without the operators’ specific records.

Limits, sources and a reader’s verification checklist

The IETF specification here is RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, published in May 2022. Its Sections 3 through 6 define the relationships, capability pairs and OTC processing, and Section 8 discusses failure and security limitations. For the types of mistakes the mechanism is meant to prevent, see RFC 7908: Problem Definition and Classification of BGP Route Leaks. For fundamental BGP behaviour and eligibility terminology, consult RFC 4271. These are source specifications, not marketing performance claims.

A responsible check uses authoritative operator configuration and current router documentation alongside the RFC. Software support and default policies may change; this article does not assert a deployment percentage, promise that any vendor enables roles automatically, or guarantee an individual path is safe. Even when Role negotiation and OTC are correct, other route selection criteria, local filters, misconfigurations and deliberate adversaries remain. Where a route affects production services, obtain a second review from the accountable network team.

If you remember only one operational distinction, make it this: origin validation asks who may originate the route; BGP role and OTC handling ask where the learned route may travel next. A networked AI assistant should answer both questions only from appropriate evidence, escalate uncertain cases, and leave changes to authorised controls. This is how a useful technical explanation becomes a disciplined decision rather than a confident-looking but unsupported command.

Frequently asked questions

Does an OTC attribute prove the prefix belongs to the announcing AS?

No. OTC concerns permissible propagation after a relationship boundary. Origin authorization is a different question addressed by RPKI origin validation and other policies. A route can have a correct OTC treatment while carrying a faulty origin, or a valid origin while being passed to an impermissible peer. A good incident report records both checks without substituting one for the other.

Must a router reject every route that already contains OTC?

No. A marked route received from a provider may be usable and can often be passed to customers while preserving OTC. The RFC requires ineligibility for OTC received from a Customer or RS-Client, and applies a peer ASN comparison for OTC received from a Peer. The direction and role matter. A rule that simply drops all OTC-marked routes can cause unnecessary connectivity problems.

What if both BGP neighbours declare Peer, but they really have a transit relationship?

The capability check confirms reciprocal declarations, not the actual administrative intent. Peer/Peer matches syntactically, but a mistaken shared classification may still impose the wrong export constraints. Correct it through verified neighbour agreements and configuration review. A machine learning model cannot reliably infer a contractual routing relationship merely from path lengths or traffic volume.

What happens if the remote router does not support BGP Role Capability?

The RFC’s compatibility behaviour ordinarily allows the session to proceed with the locally configured role still used for OTC handling. An explicitly configured strict mode can require a capability response, but operators must evaluate compatibility and potential session failure. Absence of a role capability is not the same thing as a role mismatch between two peers that both advertised roles.

Can the OTC field be changed or removed by a malicious intermediary?

Yes, it is not an end-to-end signed origin certificate. Tampering can reduce the ability of later routers to detect a leak. The RFC therefore complements, rather than replaces, good neighbour filters, routing observation, origin controls and governance. Do not claim that an OTC-marked update proves every intermediate AS obeyed all rules.

What does Role Mismatch code 2, subcode 11 refer to?

It is the specified OPEN Message error used when exchanged BGP Role capabilities do not form an allowed relationship pair, and also in specified strict-mode failure conditions. It helps diagnose session establishment. It is not the same as treating an UPDATE with a malformed OTC length as withdrawn, and it is not an HTTP status code.

Why is a Route Server not just another Peer?

Route servers have a specialised relationship at exchanges and their own RS/RS-Client capability pair. Their route exchange need not resemble the data transit of a provider or the lateral relationship of a normal peer. Correct classification changes how received and outbound OTC attributes are interpreted. Copying a peer template without checking exchange requirements is risky.

Does RFC 9234 apply automatically to VPN routes and multicast?

No. Its standard ingress and egress OTC procedures apply to IPv4 unicast and IPv6 unicast, with AFI 1 or 2 and SAFI 1. Extending them automatically to other address families is not justified by the RFC. Engineers should consult the appropriate protocol specification and implementation requirements for those families.

How can someone practise these ideas without touching a live network?

Build a tabletop matrix with local and remote roles, whether OTC exists, its four-octet ASN value, the source relationship and the intended destination relationship. Predict eligibility and allowed exports for each row, then compare to the RFC. Use fictional AS numbers and documentation prefixes. This tests reasoning without changing a production router.

Why include network routing in a series about AI and superintelligence?

Tool-using AI applications depend on real networks, identifiers and permissions. Understanding the difference between a correct endpoint and a permitted routing path helps people question failure diagnoses and avoid unsafe automation. The chapter explains an existing network standard that may support reliable present-day systems; it does not imply that artificial superintelligence already exists or controls BGP.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading