BGP Roles and the Only-to-Customer attribute can help prevent or detect route leaks, but the control begins with an accurate statement of the business relationship. A technically valid configuration built on the wrong relationship can reject a session or propagate the wrong policy signal.
\nIETF RFC 9234 defines BGP Roles negotiated in OPEN messages and the Only-to-Customer, or OTC, path attribute carried in UPDATE messages. The roles describe relationships such as provider, customer, peer, route server, and route-server client. The specification applies its leak-prevention and detection rules to IPv4 and IPv6 unicast address families.
\nWhen the two endpoints advertise incompatible roles, a speaker implementing the specification can treat that as a role mismatch. OTC then carries information that lets compliant speakers identify announcements inconsistent with the expected direction of customer-learned routes. The RFC permits a strict mode that rejects a session when a role is absent, but it discourages enabling strict mode by default because a session can fail after one side receives new software while the other side is not yet configured.
\nRFC 9234 does not discover commercial relationships or repair ordinary import and export filters. It excludes some complex arrangements from its simplified relationship model, and effectiveness depends on implementation and adoption along relevant paths. A successfully negotiated role is not proof that the route policy, IRR objects, RPKI controls, or maximum-prefix settings are correct. Mixed vendor and mixed version environments require their own qualification.
\nBuild a peer register that links each session to its owner, autonomous system, address families, contractual relationship, current import/export policy, and intended BGP Role. Reconcile the classification with the remote party. In a lab or low-risk session, capture OPEN and UPDATE behavior, confirm unknown-attribute handling, and test both valid and intentionally invalid announcements.
\nDeploy observability before enforcement. Start with mismatch and OTC visibility where the platform permits it, then introduce rejection through approved maintenance windows. Keep explicit route filters in place. Do not enable strict mode fleet-wide until the organization has confirmed peer readiness and a session recovery procedure. Record exceptions for relationships that the model cannot represent cleanly.
\nRetain the approved peer register, configuration snapshots, packet captures or decoded OPEN capabilities, controlled route-test results, relevant logs, and rollback timing. Verification should demonstrate that expected routes remain reachable, an invalid relationship or leak pattern produces the planned signal, and a legacy peer continues under the documented exception. Monitor route counts and reachability before, during, and after rollout.
\n