Network and connectivity

How your Odoo reaches the Internet

Your environment is not published piece by piece. All traffic enters through a single entry gateway, which terminates encryption and routes each request to the right application. How that gateway fits into the rest of the platform is covered in Architecture; what is exposed and what is not, in Network security.

This page is about what sits below that gateway: which paths the traffic takes between your people's browsers and the data center.

The autonomous system, and why we tell you about it

The Internet is not one network, but thousands of networks that agree to route traffic between them. Each of those networks is an autonomous system (AS), identified by a public number.

The network underpinning your environment is operated under AS3262, the autonomous system of Sarenet, the same provider that hosts compute and storage (see Hosting). Sarenet is an operator with its own data centers in Spain, not a reseller of somebody else's cloud.

We give you the number for a practical reason: everything that follows —where that network is connected, with what capacity, under what policy— is on public record, in registries we do not control. You don't have to take our word for it. You can check it.

Presence at internet exchange points

When two networks exchange traffic through third parties, every intermediate hop adds distance and time. An internet exchange point (IXP) is a facility where many networks connect directly to each other: traffic between two of them goes straight across, with no detour. Fewer hops, a shorter path, less latency.

The network is present at three exchange points, in Madrid and Barcelona:

Exchange point	Where	Capacity	IPv4 / IPv6	Route server	Networks connected
ESpanix Madrid, low network	Madrid	100 Gbps	both	yes	160
ESpanix Madrid, high network	Madrid	100 Gbps	both	yes	56
CATNIX	Barcelona	10 Gbps	both	no	53

What matters most, and almost nobody explains

The column that decides is not capacity, it is the route server. Being connected to an exchange point's route server means exchanging traffic with every network that is also connected to it, without negotiating an agreement with each one separately. That is where the value is: a presence with a route server and 160 networks on the other side opens more short paths than a large port without one.

An open peering policy

A network decides who it exchanges traffic with and on what terms, and that decision is declared publicly. It determines who finds it easy to reach you.

PeeringDB records the AS3262 policy as open (Open): no contract required and no traffic ratio requirement.

In plain terms: the network does not turn down an exchange that would shorten the path just because the other side sends it more traffic than it receives. Plenty of large operators do exactly that, and it is the usual reason a path takes a detour it did not need to take.

The rest of what the same record declares:

Traffic: between 50 and 100 Gbps, with a balanced ratio between what comes in and what goes out.
Advertised route set: AS-SARENET.

Reaching the rest of the Internet

Direct exchange does not cover the whole Internet: it only reaches the networks present at those exchange points. For everything else there is contracted transit.

Why we name no operators

Any autonomous system's neighbouring networks can be observed in the public BGP tables. But an observed adjacency is not a declared agreement, and this page is not the place to treat one as if it were the other. What the network itself does declare —its presences, its capacities and its policy— is what you see above. If you need more detail for an assessment, ask and we will handle it in writing.

Ten interconnection facilities, all in Spain

Beyond the exchange points, the network has a physical presence at ten interconnection facilities. All of them are on Spanish soil:

Madrid: Espanix Datacenter, Digital Realty MAD1-2, Digital Realty MAD3, Digital Realty MAD4, Equinix MD1, Equinix MD2 (Alcobendas).
Barcelona: Equinix BA1, Templus BCN01 (L'Hospitalet de Llobregat).
Paterna (Valencia): NIXVAL.
Derio (Bizkaia): Telxius.

Data residency also rests on the network layer

Where the disk is, is half the answer. The other half is which way the traffic travels to get to it. If all of the network's interconnections are in Spain, the usual path does not leave Spain either. See Data residency.

What we add on top

The cable sets the floor: below a certain latency you do not go, distance rules. Above that floor something else decides, and there we do step in: how many bytes we send, and how many times we send them.

Brotli compression on the Odoo program and the stylesheets, which are by far the heaviest part of a cold load. The farther away or the slower the connection, the more that difference shows.
HTTP/2, which brings all those pieces over a single connection instead of opening one per file.
TLS 1.3, which encrypts while setting up the connection with fewer round trips.
Version-named files with long expiry. Each version has its own name, so the browser can keep it for a long time with no risk of serving something stale. The second visit downloads considerably less than the first.
Per-origin request rate limiting always on, in every environment and not just production, with or without a contracted application firewall (see Network security).

How we check latency, and where the numbers are

A network is judged by what it actually takes, not by its topology. So there is a journey of 21 real Odoo requests —a cold load, opening a module, paging and sorting, searching, a report, an export, a PDF— repeated from 44 cities across 37 countries.

The method is in plain sight, and it has a quirk worth knowing how to read: the probe opens a new connection on every request, so it pays name resolution, encryption and connection each time. That is exactly what an integration calling in isolation does, but not what someone with Odoo open in front of them does. So both readings are published —what the probe returned, and what is left once those round trips a browser no longer pays are taken off— side by side, with the arithmetic that leads from one to the other explained on the page itself.

The results do not live here. This trust center describes the network and the method; the city-by-city breakdown, with the source behind every perception threshold, is published separately so you can repeat it or argue with it: https://www.dyncloud.es/en/connectivity/.

What we do not claim

A trust center is worth as much for what it rules out as for what it states:

We do not say which specific networks traffic is exchanged with. The policy is open and the presences are public; the list of agreements is not something we publish.
We do not promise a latency figure. What the connectivity page publishes is the result of a measurement journey, and a measurement journey is not a service commitment. Service levels are agreed in the contract.
If the network changes, or the journey changes, the result changes. That is why the method is published next to the numbers, and not here.

How to check it without trusting us

Everything above is on a public record we do not administer:

https://www.peeringdb.com/asn/3262

How to read it: the autonomous system's entry lists its exchange points with the capacity of each port and whether it is connected to the route server, its interconnection facilities with their locations, and, under peering, the policy, the advertised route set and the declared traffic. Compare that entry with this page. If anything does not add up, tell us.