This represents a major milestone that culminates three years of preparation and is part of our broader strategy to maintain complete control over our Paris region’s network infrastructure.
Why We Made This Change
In Clever Cloud’s early years, we delegated network responsibility to partners. This approach made sense: it allowed us to accelerate development, focus on cloud services, and avoid investing in expertise we hadn’t yet mastered. But as our infrastructure grew, the limitations of this dependency became clear. We had no control over strategic decisions — how traffic was routed across the Internet, which paths our packets took, or how quickly we could respond to failures. Every modification, every incident required the involvement of a third party.
We decided to take this responsibility back. In doing so, we gained several concrete advantages. We optimize costs through direct management of our transit and peering relationships. We define our own routing policy instead of following an intermediary’s constraints. We resolve incidents ourselves, without waiting for external providers. And we achieve complete control of our network stack — the same way we progressively took control of our servers and datacenters over the past few years.
But this transition isn’t just about our operational independence. It brings immediate, tangible benefits for you. The most critical is resilience. Previously, all traffic was routed through a single provider. Any incident on their side impacted every service we offered. We now maintain four upstream providers across three datacenters in the Paris area. When one link fails — and it has happened over the past year — traffic automatically shifts to available alternatives without customer-impacting interruption. We can even withstand the simultaneous loss of multiple transit links.
Beyond redundancy, we gain control over routing itself. We now decide how your traffic reaches its destination. This allows us to optimize paths for lower latency and better performance, and to adjust those decisions based on your specific needs and our network topology. We respond to congestion, to changing conditions, and to your requirements in real time.
Finally, there is the question of operational responsibility. Network issues no longer require us to wait for an external provider to acknowledge and resolve them. Public network failures fall directly under our responsibility — we detect them, analyze them, and fix them ourselves. This directly reduces the time between problem and resolution, which means less downtime and better reliability for our customers.
Operating Your Own Network on the Internet
To operate as an independent network on the Internet, organizations must work with a Regional Internet Registry (RIR). RIRs are responsible for allocating and managing IP addresses and AS numbers within specific geographical regions.
There are five RIRs worldwide:
- RIPE NCC — Europe, Central Asia, and the Middle East
- ARIN — North America (United States, Canada, and the Caribbean)
- LACNIC — Latin America and the Caribbean
- APNIC — Asia-Pacific region
- AFRINIC — Africa
For Clever Cloud, since our infrastructure is primarily in Europe, we work with RIPE NCC (Réseaux Internet Publics Européens).
Allocated Address Space
As a member of a RIR, organizations receive allocations of both IPv4 and IPv6 address space. For RIPE NCC members, this typically includes a /24 block of IPv4 addresses (depending on the availability of such a block) and a /29 block of IPv6 addresses. These allocations are managed under your membership and can be used to operate your network globally.
Creating Our Autonomous System
The groundwork for this transition began several years ago. In 2019, we created our RIPE NCC account to become a LIR (Local Internet Registry). This gave us access to a /24 IPv4 block (91.208.207.0/24) and a /29 IPv6 block (2a0f:d0c0::/29).
Then, in 2022, we registered our Autonomous System Number (ASN) with the Regional Internet Registry for our region. Our AS number is AS213394. Here is the aut-num object:
> whois AS213394
aut-num: AS213394
as-name: CleverCloud
org: ORG-CCS42-RIPE
import: from AS29075 accept ANY
import: from AS3257 accept ANY
import: from AS3356 accept ANY
import: from AS43424 accept ANY
export: to AS29075 announce AS213394:AS-CLVRCLD
export: to AS3257 announce AS213394:AS-CLVRCLD
export: to AS3356 announce AS213394:AS-CLVRCLD
export: to AS43424 announce AS213394:AS-CLVRCLD
admin-c: QA171-RIPE
tech-c: QA171-RIPE
status: ASSIGNED
mnt-by: RIPE-NCC-END-MNT
mnt-by: mnt-fr-clvrcldnet-1
created: 2022-11-28T08:24:23Z
last-modified: 2025-02-25T16:36:15Z
source: RIPEAn Autonomous System Number (ASN) is a unique identifier for networks on the Internet. It’s required to announce routes via BGP — the protocol that makes inter-network routing possible. Creating an AS early on allowed us to plan for this eventual transition and prepare the necessary infrastructure in advance.
Now that we have an ASN, we can start announcing our prefixes to other networks on the Internet using the BGP protocol.
The Role of the RIPE Database
The RIPE NCC maintains a public database of routing objects (like the aut-num object above). Among these objects are route objects, which specify which AS is authorized to announce a particular IP prefix. In practice, these entries are primarily used by network operators and transit providers to build routing policy and filters (IRR-based filtering) to accept or deny announcements from their peers. This is one way to try to prevent BGP hijacks. By applying those filters to the routes you receive from your peers, you can limit the propagation of a prefix that originates from the wrong ASN.
Let’s say that Org A owns 192.0.2.0/24 and announces it to Transit X. Transit X applies a filter on routes learned from Org A to only accept the IP prefixes that Org A has in its RIR database. This way, if Org A starts announcing a prefix it doesn’t own (let’s say our public prefix, 91.208.207.0/24), then Transit X is supposed to reject that route. This helps prevent the bad route from being propagated and traffic from being forwarded to the wrong entity.
However, not all networks implement IRR filtering. Better mechanisms like ROA (Route Origin Authorization) exist to address this gap.
The BGP Protocol: How the Internet Routes Traffic
To understand how we announce our prefixes on the Internet, it’s essential to understand BGP — the Border Gateway Protocol. BGP is the de facto standard routing protocol of the Internet. It allows networks (Autonomous Systems) to exchange information about which IP prefixes they own and how to reach them.
BGP works in both directions. When we announce to our peers and transit providers “we own 91.208.207.0/24”, this announcement travels through the Internet from network to network. Each network that forwards our announcement prepends its own AS number to the AS_PATH — a list showing the sequence of networks a packet traverses to reach us. For example, OVHcloud (AS16276) sees the path [AS29075, AS213394]: traffic goes through one of our transit providers (AS29075), then reaches us (AS213394). Each network that forwards the announcement updates it this way, building a complete path. Here’s an example using the OVHcloud Looking Glass service:
> show route for 91.208.207.0/24 all
91.208.207.0/24 via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 29075 213394
BGP.next_hop: 172.18.16.0
BGP.med: 161
BGP.local_pref: 40
BGP.community: (0,0) (29075,18000) (65535,65281)
BGP.23 [t]: 00 00 b8 6e
via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]At the same time, we receive announcements from other networks about their prefixes and the paths to reach them. This builds the opposite view: when we need to send traffic outbound, we know which path to take to reach any given destination. Here’s an example with one of OVHcloud prefixes:
> /routing/route/print detail where dst-address=5.39.0.0/17 and active
Ab afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"
bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igpHere the network path OVHcloud uses to reach us is different from the one we use to reach them.
The Migration Process
Our IP prefixes were entirely managed by our historical provider. While we legally owned the addresses, we delegated the technical responsibility of announcing them to the Internet to this single provider. This meant:
- Our provider’s AS (AS43424) was listed as the origin of our prefixes in the Internet routing tables
- All traffic destined for our services or outgoing to the Internet had to flow through their infrastructure
Clever Cloud Services | | all inbound/outbound traffic v Historical Provider (AS43424) | | originates: 91.208.207.0/24 (origin AS43424) v Internet
We now want our ASN to be the origin of the announcements. To migrate safely, we planned a three-step migration. The requirements were simple: we could not accept any customer-impacting interruption.
Migrating a prefix between ASNs
To migrate a prefix from one AS to another, we needed to modify its route object in the RIPE database. The procedure was straightforward but required careful timing.
First, we created a second route object in the RIPE database for our 91.208.207.0/24 prefix. Now both ASNs were registered as authorized to announce the same prefix — both our historical provider’s AS and our own AS (213394).
These routing objects are publicly queryable via the whois command or through the RIPE web interface. For example, running whois -h whois.ripe.net -T route 91.208.207.0/24 returns both registered objects:
❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'
route: 91.208.207.0/24
mnt-by: mnt-fr-clvrcldnet-1
descr: CleverCloud subnet
origin: AS213394
created: 2025-01-15T10:29:14Z
last-modified: 2025-01-15T10:29:14Z
source: RIPE
% Information related to '91.208.207.0/24AS43424'
route: 91.208.207.0/24
mnt-by: mnt-fr-clvrcldnet-1
mnt-by: MAGICRETAIL-MNT
descr: CleverCloud subnet
origin: AS43424
created: 2020-02-13T09:06:33Z
last-modified: 2020-02-13T09:06:48Z
source: RIPEOnce this second route object was registered and propagated across the Internet (i.e., network operators pulled an up-to-date version of the RIPE database to build their routing filters), our new transit providers could see that our ASN was authorized to announce this prefix. At that point, we could begin announcing the prefix through our own infrastructure.
If we didn’t create that route object, our route announcement might have been rejected and we could have been flagged as BGP hijackers.
Announcing Through Our Historical Provider
Once the second route object was propagated, we performed the first step during the night of January 16, 2025: we began announcing the prefix ourselves via BGP to our historical provider. This was still using the same transit path, but now with Clever Cloud AS213394 originating the announcements instead of our historical provider. Our historical provider continued to relay the prefix, but now received it from us rather than announcing it directly.
Clever Cloud Services (AS213394) | | originates: 91.208.207.0/24 (origin AS213394) v Historical Provider (AS43424) | | re-announces: 91.208.207.0/24 (origin AS213394) v Internet
This first phase served as validation — if any issues arose, we could quickly revert without impacting other transit paths.
Announcing Through Our Own Transits
A few days later, during the night of January 21, 2025, we took the final step: we began announcing the prefix through our own dedicated transit connections.
Clever Cloud Services (AS213394) | | originates: 91.208.207.0/24 (origin AS213394) | +---+---+---+ | | | | v v v v T1 T2 T3 HP (Transit providers + historical provider) | | | | +---+---+---+ | v Internet
We now announce our prefixes directly to four upstream providers (three transit providers, T1/T2/T3, plus our historical provider HP). Traffic flows across all paths, and we have full control over routing decisions and redundancy.
Throughout both phases, we observed no customer-impacting interruption. The BGP protocol’s built-in redundancy and the gradual nature of the transition ensured that traffic flowed smoothly regardless of which path was preferred at any given moment.
Complete Internet Routing Visibility
As part of Phase 2, our three primary transit providers began sending us a “full view” of the Internet’s routing table. This is the complete set of all publicly announced IPv4 and IPv6 prefixes — roughly ~1 million IPv4 routes and ~220,000 IPv6 routes.
A full view gives us unprecedented visibility into how the Internet is structured and allows us to make sophisticated routing decisions. Rather than relying on a single provider’s perspective, we now see all available paths to reach any destination on the Internet.
With this information, we are able to:
- Choose optimal paths for our outbound traffic based on our network topology and preferences
- Implement traffic engineering to direct flows through specific transit providers
- Respond dynamically to network conditions and congestion
- Balance load across our four transit connections based on real-time routing data
This fine-grained control over our routing policy is a direct result of operating our own AS and managing our own announcements — exactly the kind of operational independence we sought when we began this transition.
One Year Later
Nearly a year into operating our own network announcements, the transition has proven successful. We have experienced no major incidents, and our infrastructure has proven resilient. When minor issues have occurred — such as packet loss through a specific transit provider or the temporary loss of a transit link — traffic has automatically rebalanced across our remaining connections. We have been able to detect and respond to these issues directly, without waiting for a third-party provider to take action. Our customers experienced no customer-impacting interruption. This ability to own our problems and resolve them quickly is perhaps the greatest benefit we’ve gained.
What’s Next
This transition is far from finished. We have several roadmap items ahead of us:
- Increased network capacity to handle growing traffic demands
- BGP peering with other networks to optimize traffic locally without paying for transit
- ROA (Route Origin Authorization) deployment to cryptographically sign our route announcements and prevent unauthorized parties from hijacking our prefixes
- RPKI (Resource Public Key Infrastructure) validation to ensure the legitimacy of announcements we receive from other networks and protect against prefix hijacking attacks
- IPv6 expansion, both inbound (accepting IPv6 traffic) and outbound (sending IPv6 traffic) — a transition we will roll out in phases
Conclusion
In early 2025, Clever Cloud completed its transition to fully independent network operations. We now announce our own IP prefixes through four upstream providers, giving us full authority over how traffic flows in and out of our infrastructure.
For our customers, this translates to better reliability and faster problem resolution in our Paris region. When network issues occur, we handle them directly — and our multi-provider redundancy ensures traffic keeps flowing even when incidents occur.
This milestone is just the beginning. We’re already working on BGP peering to optimize local traffic, ROA signing and RPKI validation to strengthen routing security, and IPv6 expansion to fully embrace dual-stack connectivity. We’re building a network as robust and self-sufficient as the rest of our infrastructure — and we’re excited about what comes next.