Smart Routing
The controller that decides where your traffic leaves our network, and keeps deciding as capacity and reachability change.
Standard BGP picks a path from what it is told. It does not know that one of your egress ports is at 77 percent while another sits at 38, or that the backbone corridor behind the shorter AS path has no headroom this evening.
Smart Routing does. It is our own controller, built into the control panel, and it holds an ordered preference list per destination profile: private interconnects first, then exchanges, then paid transit. It applies that order continuously, checks that the chosen route is actually usable, and only steps down the list when it has to.
It is not a machine learning experiment and it does not invent strategy. Our engineers write the policy; the controller enforces it faster and more consistently than a person watching graphs could.
An ordered list, applied continuously
Each destination profile carries a priority order. Traffic takes the highest priority egress that is reachable, has capacity, and whose backbone path also has room. If nothing at that level qualifies, it moves down one level, and no further.
The example on the right is the shape of a real profile: direct interconnects with a content network first, the exchanges we meet them on second, paid transit last.
Priority order for one content network
Illustrative. Real profiles are built per customer and per destination network.
Capacity aware, without the churn
Moving traffic is easy. Moving it without causing a second problem is the hard part, so the controller is deliberately conservative.
Meaningful improvement only
A path changes when the alternative is materially better, or when the current one is no longer safe. Marginal gains are left alone.
Movement budgets
Each profile has a limit on how much demand may be shifted in a single operating window, so relief happens gradually.
Hold and recovery
Sustained-pressure and recovery periods stop the controller oscillating around a utilisation threshold.
End-to-end awareness
A remote egress is only chosen when the backbone corridor needed to reach it also has headroom. No solving one problem by creating another.
Unsafe, failed or withdrawn paths are the exception: those move immediately.
Every decision has a record
When we tell you why traffic went a particular way, we are reading it rather than reconstructing it. The controller correlates the BGP route with the interface, the neighbour and the capacity state at the time.
- BGP next-hop, AS path, origin, MED and communities
- Interface and sub-interface addressing, VLAN transport and LAG membership
- ARP and IPv6 neighbour data, matched against the peering record
- Destination-qualified next-hop and origin, with route provenance from BMP
- Current capacity, projected pressure and known backbone state
How a decision is recorded
Example record.
You get the outcome, not the console
Smart Routing is an internal control plane. There is no dial for customers to turn, and that is deliberate: a controller that anyone can override is a controller nobody can reason about.
What reaches you is the result. Traffic that leaves on a direct interconnect when one is available, congestion relieved before it becomes packet loss, and a straight answer when you ask why a route changed.
Shorter paths by default
Direct interconnects are preferred over exchanges, and exchanges over paid transit, wherever the destination is reachable that way.
Pressure handled early
Load is moved while there is still headroom, rather than after a link saturates and your users notice.
Your policy still applies
Communities you set are honoured. Smart Routing chooses within the policy you have asked for, not around it.
Answers, not guesses
Ask the NOC why a prefix took a given path and you get the recorded decision with the evidence behind it.
Ask us how your traffic would route
Tell us the destinations that matter to you and we will show you where they leave our network today, and what the profile for them would look like.