Routing Control Platforms: Centralised Intelligence for BGP
How can a network make routing decisions using a wider view of topology, policy and reachability than any individual router has locally? A Routing Control Platform (RCP) explores one answer: separate the computation of routing decisions from the routers that forward packets.
In a traditional BGP design, routers select paths using the routing information and policies available to them. Route Reflectors improve iBGP scalability, but their path-selection perspective can affect which routes are advertised to clients. An RCP-style architecture combines BGP information with an IGP topology view to compute routing decisions with a broader understanding of the network.
Understand the architecture
Explore how IGP topology, BGP reachability and routing policy feed a control platform that computes route decisions.
Compare routing perspectives
Examine why a Route Reflector and a controller using per-router topology information may choose different exits.
Diagnose incorrect decisions
Correlate topology freshness, IGP costs, BGP state and controller output to identify the cause of a suboptimal route.
Follow the routing decision from architecture to operational verification. Each stage builds on the evidence collected in the previous one.
How a routing decision travels through RCP
Select each stage to follow the control-plane workflow, from network information to packet forwarding.
RCP Architecture: From Network State to Routing Decision
A Routing Control Platform (RCP) is an architectural approach to computing BGP routing decisions with a broader view of network topology, reachability and policy. Rather than relying exclusively on each router's local view, an RCP-style system collects routing information, evaluates it centrally and communicates routing decisions back to routers.
The important distinction is between where a routing decision is calculated and where packets are forwarded. RCP moves part of the route-computation process into a control platform. The routers still perform the actual packet forwarding using their local forwarding information base (FIB).
Can a controller use BGP information and IGP topology to make better-informed routing decisions without becoming a dependency in the normal packet-forwarding path?
1.1 The components of an RCP-style architecture
The original RCP concept separates information collection, route computation and route distribution. Exact component names and implementation details vary, but the following model captures the core responsibilities.
IGP topology view
Collects information about the internal network, including links, reachability and routing metrics. This helps the controller estimate the internal cost from a relevant router to a BGP next hop or external exit.
BGP information
Provides reachable prefixes and path attributes such as AS_PATH, LOCAL_PREF, MED and next-hop information. The available paths depend on BGP propagation, policy and the architecture used to expose routes to the platform.
Route Control Server (RCS)
Combines the available routing information with topology and policy to calculate routing decisions. Depending on the design, it may evaluate decisions from the perspective of particular routers or regions.
Router RIB and FIB
Routers receive and process routing information, install eligible routes and program their local forwarding tables. Their forwarding hardware or software then sends packets toward the selected next hop.
1.2 Follow the route-decision flow
A useful way to understand the design is to trace one destination prefix from discovery to forwarding. The platform needs enough accurate information to make a decision, and the routers need a valid route and resolvable next hop to forward traffic successfully.
1.3 Control plane versus data plane
RCP is not the same as a controller that forwards every packet centrally. It is primarily concerned with the computation and distribution of routing information. Once a router has installed a route and resolved its next hop, packets are normally forwarded locally.
| Function | Control plane | Data plane |
|---|---|---|
| Primary purpose | Learn reachability and determine usable routes. | Forward packets using installed forwarding entries. |
| RCP's role | Correlate BGP information, topology and policy to calculate routing decisions. | Not normally in the packet-by-packet forwarding path. |
| Router's role | Maintain routing protocols and process received routing information. | Resolve the destination against the FIB and forward toward the next hop. |
| Evidence to inspect | BGP routes, attributes, IGP topology, policy and controller state. | Installed route, FIB entry, next-hop resolution and observed traffic. |
1.4 Why the topology view matters
BGP path selection and internal path costs answer different questions. BGP attributes and policy influence which routes are eligible and preferred; IGP information helps establish internal reachability and costs to next hops. An RCP design attempts to use both kinds of information when calculating a decision.
Consider two external exits advertising the same destination. A central platform might know that Exit A is closer to one region while Exit B is closer to another. That information can support more appropriate router-specific decisions, provided the architecture can calculate and distribute those decisions correctly.
This does not mean that the lowest IGP cost always wins. LOCAL_PREF, AS_PATH, MED, next-hop reachability, policy and the implementation's decision process can affect the outcome. Engineers must inspect the full decision chain rather than infer the chosen route from one metric.
1.5 The design's dependency: accurate, current state
Centralised computation creates a strong dependency on the quality and freshness of the information being used. If a link fails but the controller still sees an older topology, it may calculate a route using a path that is no longer available. The resulting problem may appear as a route-selection issue even when the underlying cause is stale state or failed next-hop reachability.
- Topology: Does the controller's view match the current IGP state?
- Reachability: Are the BGP route and its next hop still valid?
- Policy: Are route attributes and policy applied as intended?
- Distribution: Did the target router receive and accept the intended route?
- Forwarding: Does the local FIB reflect the route, and does traffic succeed?
1.6 RCP and Route Reflectors are not interchangeable terms
Route Reflectors address the scaling problem of a full iBGP mesh by reducing the number of required iBGP sessions. However, a reflector generally advertises selected paths according to its BGP decision process and configuration. Clients may therefore not receive every available path, and the reflector's routing perspective may differ from a client's perspective.
RCP was proposed as an alternative architectural approach to route computation and distribution, aiming to combine BGP information with topology knowledge. It should not be treated as a universal replacement for Route Reflectors or as a guarantee of optimal routing. Results depend on the implementation, information available, policies and network design.
RCP separates routing-decision computation from packet forwarding. To understand a route, trace the complete chain: topology and BGP inputs → policy-aware calculation → route distribution → router RIB/FIB → verified traffic outcome. The next section compares the routing perspectives behind RCP and Route Reflectors.
An RCP does not sit in the packet-forwarding path. It builds a broader view of routing and topology, computes policy-aware decisions, and communicates those decisions back to the routers.
The key RCP idea is visibility. Instead of making a routing decision from the limited perspective of one router, the platform combines IGP topology information with BGP reachability and policy information.
Who has the right view of the network?
Choose a routing model to examine how its decision-making perspective can affect exit selection.
Compare Route Reflector and RCP Perspectives
Two routers can reach the same destination but have different internal costs to the available exits. Understanding which routing information is visible—and whose perspective drives the decision—is essential when investigating unexpected BGP paths.
Route Reflectors improve iBGP scalability by reducing the need for a full mesh of internal BGP sessions. A Routing Control Platform takes a different architectural approach: it seeks to combine BGP reachability and policy with a wider view of the IGP topology when calculating routing decisions.
A controller or reflector can only make a decision from the information and policies available to it. To establish whether a route is appropriate, compare the selected BGP path, the relevant router's IGP costs, next-hop reachability and the actual forwarding state.
2.1 What does a Route Reflector see?
In a conventional route-reflector design, clients advertise routes to the reflector, which applies BGP selection and reflection rules. The reflector generally advertises selected paths rather than every path it learns. This reduces control-plane overhead, but it can limit which alternatives are visible to clients.
Fewer iBGP sessions
Route reflection reduces the need for every internal BGP router to peer directly with every other router. This simplifies session management as the network grows.
Selected paths are reflected
Standard route reflection can hide alternatives that were not selected by the reflector. Additional mechanisms or design choices may be needed when greater path diversity is required.
The reflector has its own view
The reflector's BGP decision is made in its own routing context. Its IGP cost to an exit can differ from the cost seen by a client in another part of the network.
Check the receiving router
The reflected route must still be evaluated in the receiving router's context, including its installed next hop, local forwarding state and reachability.
2.2 What does an RCP-style design add?
RCP was proposed to address limitations associated with distributed route computation and route reflection. By combining BGP information with an IGP topology view, a controller can attempt to calculate decisions that account for the internal cost from a particular router or region to an exit.
The goal is not simply to select one globally best exit. In some designs, the appropriate choice differs by router because internal topology and policy differ. A platform that models these differences may be able to make better-informed decisions than one relying solely on a single reflector's perspective.
IGP cost from East: 70
IGP cost from East: 15
Illustrative IGP costs only. If the relevant BGP paths and policy permit these choices, West may favour Exit A while East may favour Exit B. Actual BGP selection is not determined by IGP cost alone.
2.3 Compare the models using evidence
| Engineering question | Route Reflector | RCP-style approach |
|---|---|---|
| What is the routing input? | Received BGP routes, path attributes, local topology and configured policy. | BGP reachability and policy combined with a collected view of IGP topology. |
| How are decisions made? | The reflector applies its BGP decision process to the paths it knows. | The platform calculates decisions using its available routing information and design-specific logic. |
| Can path diversity be limited? | Yes. Conventional reflection may advertise only selected paths. | Potentially different path visibility, depending on how the platform learns and distributes routes. |
| Can topology freshness matter? | Yes. Local IGP state and next-hop reachability affect routing outcomes. | Yes. Stale or incomplete topology information can undermine a calculated decision. |
| What proves the outcome? | Received route, BGP attributes, local route selection and FIB. | Input freshness, computed decision, distributed route, router RIB/FIB and traffic results. |
2.4 Why the shortest internal path may not win
A common troubleshooting mistake is to assume that the router must use the exit with the lowest IGP cost. BGP selection is policy-driven and considers several attributes and decision steps. LOCAL_PREF, AS_PATH, MED, next-hop validity and implementation-specific configuration can influence which route is selected before or alongside internal forwarding considerations.
For example, a higher LOCAL_PREF can cause one path to be preferred even when its exit is farther away in the IGP. That can be intentional: an organisation may prefer a particular transit provider for commercial, security or traffic-engineering reasons. The engineer must first determine the intended policy, then compare the observed decision against it.
2.5 Build a reliable observation checklist
- Route availability: Does the relevant router know the destination prefix?
- Path attributes: Which candidate routes are visible, and what are their LOCAL_PREF, AS_PATH and MED values?
- Router perspective: What are the IGP costs and next-hop reachability from the affected router?
- Reflection or distribution: Was the intended route actually advertised to the client?
- Controller freshness: If RCP is involved, does its topology snapshot reflect the current network?
- Forwarding state: Does the local FIB match the expected route, and can traffic reach the destination?
Do not judge a routing architecture by the route it selects in isolation. Compare the paths it can see, the topology and policy it uses, the router for which the decision is intended, and the resulting forwarding state. In the interactive lab that follows, compare exit selection from different router perspectives before investigating a deliberately incorrect decision in Section 3.
RCP Incident: Why Did One Region Get the Wrong Exit?
A routing incident has been reported. Reachability is healthy, BGP sessions are established, but one region is taking a suboptimal exit. Examine the evidence and identify the real control-plane problem.
Traffic from the West region is exiting through Exit B even though Exit A is significantly closer from the West router's IGP perspective. No BGP session is down.
What is the most likely root cause?
RCP does not simply mean “put BGP in a central box.” The value is the ability to combine network-wide state with the perspective of the router that actually needs the decision. That requires accurate topology visibility. If the controller is stale, the centralised decision process can be consistently wrong even though BGP sessions and basic reachability remain healthy.
A route looks valid—but the chosen exit is wrong
Explore the evidence an engineer should check before changing routing policy.
Why Did One Region Get the Wrong Exit?
A BGP session can be established, a destination prefix can be present, and traffic can still take an unexpected path. When a Routing Control Platform uses topology information to calculate route decisions, an engineer must investigate both the routing inputs and the state from which those decisions were derived.
The critical skill is separating a symptom from its cause. An unexpected exit does not automatically mean that BGP is broken, that the destination is unreachable, or that LOCAL_PREF needs to be changed. The route may have been calculated using an outdated view of the internal network.
One region prefers Exit B even though Exit A is closer according to the current IGP topology. BGP remains established and the destination is available. The controller's topology snapshot is several minutes old. Treat stale state as a hypothesis to verify—not as a conclusion to assume.
3.1 Start with the observed symptom
Imagine a network with two external exits advertising the same destination. The West region currently forwards through Exit B. An engineer's current IGP measurements show a lower cost to Exit A, but the controller still reports Exit B as the selected path.
Unexpected exit selection
Traffic from West uses Exit B even though current topology measurements suggest Exit A is closer. Confirm the actual forwarding path instead of relying only on a dashboard summary.
BGP is still established
The relevant BGP neighbour is up and the destination prefix is available. This makes a completely failed BGP session less likely, but does not rule out route-policy or path-distribution problems.
Current costs differ
West's measured IGP costs are 18 to Exit A and 61 to Exit B. These figures are evidence about internal reachability—not proof that BGP must choose Exit A.
Controller data is stale
The controller's topology snapshot is reported to be nine minutes old. Verify that timestamp and compare it with the actual IGP state and recent topology changes.
3.2 Follow the evidence in a deliberate order
Use a consistent investigation sequence to avoid changing policy before the cause is known. Each check should either support or eliminate a plausible failure mode.
3.3 Distinguish the possible causes
| Possible cause | Evidence to collect | What it tells you |
|---|---|---|
| BGP session failure | Neighbour state, logs, route withdrawal and session history. | A down session can affect route availability, but an established session does not prove that the selected path is correct. |
| Missing route or next hop | Received prefix, next-hop resolution, RIB and FIB entries. | The route may be unavailable or unusable even when other BGP sessions remain up. |
| Policy or BGP attributes | LOCAL_PREF, AS_PATH, MED, import/export policy and candidate-path visibility. | A policy decision may legitimately override an engineer's expectation based on IGP distance alone. |
| Stale controller topology | Snapshot timestamp, topology events, current IGP database and controller refresh status. | The controller may be calculating from an older network state than the routers are using. |
| Distribution or installation problem | Computed decision, advertised route, received route and local FIB. | The intended decision may not have reached the router or may not have been installed as expected. |
3.4 Why stale topology can produce a wrong decision
A topology-aware controller can only calculate from the information it has. If a link changes, a metric is updated or a failure occurs, the controller needs to learn the change and update its model. Until that happens, the controller's estimate of the path to an exit may no longer match the actual network.
This is a consistency problem between the observed network and the model used for route computation. The controller might produce a decision that was reasonable under the old topology but is no longer appropriate under the current one.
The effect depends on the implementation and the failure. A stale snapshot does not always cause an incorrect exit, a forwarding loop or a blackhole. It becomes operationally significant when the outdated information changes the computed decision or leaves a next hop unreachable.
3.5 Remediate the cause, not just the symptom
If evidence confirms that the topology view is stale, the corrective action is to restore accurate information and recalculate the route decision using the platform's supported recovery procedure. Avoid applying a blanket LOCAL_PREF change simply to force the desired exit: that may mask the issue and create unintended results for other regions or destinations.
- Refresh: Restore topology collection or synchronisation and confirm that the controller has received the current state.
- Recompute: Recalculate the route decision with current topology, BGP routes and policy.
- Redistribute: Confirm that the intended routing update reaches the correct router or client.
- Verify installation: Inspect the selected route, next hop and local FIB.
- Verify service: Test the actual traffic path and confirm reachability and performance meet expectations.
3.6 What counts as proof that the incident is resolved?
A green controller status or a successful recalculation is not sufficient on its own. The investigation is complete when the inputs are current, the selected route matches the intended policy and topology, the router installs the expected forwarding entry, and traffic follows the intended path.
Investigate unexpected routing by correlating BGP state, route attributes, current IGP costs, controller topology freshness, route distribution and FIB state. When the controller's view is stale, repair and verify the data pipeline before changing routing policy. The incident lab that follows lets you test this reasoning against the West-region scenario.
Recovery is not proven by a single green status
Select the evidence you have verified. A routing change is complete only when the control-plane decision and forwarding outcome agree.
Correlate and Operate: Validate the Routing Decision
A routing decision is not proven correct simply because a controller calculated a path or a router received an update. Engineers need to connect the network's topology, BGP information, policy decision, installed forwarding state and observed traffic into one evidence chain.
That is the operational challenge behind a Routing Control Platform (RCP). Its value depends not only on the decision logic, but also on the freshness and consistency of the information used to make decisions—and on whether the resulting routes are distributed and installed as intended.
Follow the evidence across the control and data planes
When a region takes an unexpected exit, investigate the complete sequence. A controller may have selected a valid route using an outdated topology snapshot; a router may have received the intended route but rejected it through policy; or the routing table may be correct while forwarding still fails because of a next-hop or downstream connectivity problem.
Correlate symptoms with the right evidence
| Observed symptom | Evidence to correlate | Engineering interpretation |
|---|---|---|
| Unexpected exit selected | IGP costs, BGP attributes, policy, topology timestamp and router perspective | The choice may reflect policy or a different network view—not necessarily a failed session. |
| Route missing from a router | Received updates, import policy, next-hop reachability and routing table | The route may be unavailable, filtered, ineligible or not installed. |
| Route present, traffic fails | FIB entry, resolved next hop, interface state, ACLs and end-to-end probes | Control-plane reachability does not by itself prove successful packet delivery. |
| Repeated path changes | Update history, attribute changes, topology events, timers and policy interactions | Look for interacting decisions or unstable inputs before changing attributes. |
Understand the mechanisms around route selection
Hot-potato routing
Hot-potato routing generally favours the closest eligible exit according to the router's IGP view after higher-priority BGP decision criteria have been considered. Two routers can legitimately choose different exits because their IGP costs differ. A controller's view must therefore match the intended decision perspective; a low IGP cost alone does not override every BGP attribute or policy.
Multipath and BGP Add-Path
BGP multipath can allow multiple eligible paths to be installed or used, subject to implementation and configuration. BGP Add-Path allows multiple paths for a prefix to be advertised to a peer, helping reduce some path-visibility limitations. Neither feature automatically guarantees a better path or removes the need to validate policy, next-hop resolution and forwarding behaviour.
Next-hop tracking and MED
Next-hop tracking helps a router reassess route eligibility when next-hop reachability changes. MED can influence selection between routes from the same neighbouring AS, depending on the comparison rules and policy. In complex designs, interacting MED values, route reflection and changing topology can contribute to repeated path changes—but oscillation is not inevitable. Examine the actual attributes, decision order and update sequence before attributing a problem to MED.
A safe recovery workflow
Once the evidence points to stale or inconsistent topology, avoid making unrelated policy changes just to force a preferred exit. Correct the underlying input first, then confirm each downstream stage.
DetectReconcileRecomputeRedistributeVerify
- Capture the baseline. Record the affected prefix, selected exit, IGP costs, BGP attributes, relevant updates and current RIB/FIB state.
- Reconcile the network view. Confirm that topology data and reachability reflect current link and routing state. Check timestamps and the source of the data.
- Recompute and distribute. Re-evaluate the route using the intended policy and perspective, then verify that the expected decision reaches the affected routers.
- Verify installation. Confirm the route in the router's RIB, resolve the next hop and check the corresponding FIB entry. A received update is not the same as an installed route.
- Test the service and monitor. Use appropriate path probes or traffic tests, watch for unexpected updates or route churn, and retain a rollback path if the change causes regressions.
How do you know the incident is resolved?
Recovery is complete only when the intended route decision is visible, the forwarding entry is installed, the next hop is reachable, traffic behaves as expected and the system remains stable after convergence. Record the before-and-after evidence so that the fix can be explained and repeated—not merely assumed from a green status indicator.
Engineering conclusion · Routing control
From Centralised Routing Intelligence to Verified Forwarding
The Routing Control Platform concept highlights a fundamental challenge in BGP engineering: a route-selection decision is only as reliable as the network information, policy and router perspective behind it.
By combining BGP reachability with IGP topology information, an RCP can calculate routing decisions with a broader view of the network. The operational challenge is ensuring that this view remains accurate, the intended decisions reach the relevant routers, and the resulting forwarding state delivers the expected outcome.
Four engineering principles to take away
The broader lesson for software-defined networking
RCP is a useful architectural case study in separating routing intelligence from packet forwarding. Its ideas remain relevant when evaluating controller-assisted networking, centralised policy, topology-aware path computation and modern network automation. However, an architecture should be judged against its actual implementation, failure handling, scalability and operational requirements—not treated as a universal replacement for established BGP designs.
RCP vs Route Reflector: Which Exit Does Each Router Choose?
Experiment with the network perspective, IGP costs and routing policy. Then run the decision engine to see how a traditional Route Reflector and an RCP can produce different exit choices.
The important difference is network perspective. A Route Reflector provides scalability by reflecting selected routes, while an RCP can calculate the appropriate route for the individual router using broader topology visibility.