Capacity with headroom
Enough backbone and uplink that peak traffic and an attack do not congest the path; real, diverse capacity, not a marketing number.
Infrastructure · Network
A network judged by what it does for you.
A good hosting network is not one impressive number; it is route diversity across several carriers and direct peering, reputation-checked clean IP space that protects your email, dual-stack IPv4 and IPv6, anycast, and always-on DDoS absorption. VV Internet Hosting runs a multi-homed backbone with strong, diverse paths and clean addressing, and gives honest advice on when a premium network actually matters and when standard connectivity is plenty.
In short
- Route diversity beats a logo. Several transit carriers plus direct peering route around any single upstream's bad day.
- Clean IPs are the network half of deliverability. Reputation-checked space, kept clean by active abuse handling, decides whether mail lands.
- Dual-stack, because the internet still needs it. IPv6 is growing but under half of traffic; IPv4 stays essential, and clean IPv4 is a real asset.
- Anycast and DDoS absorption are built in. Resilient DNS and edge mitigation you benefit from without managing.
- Honest about reach. We are a strong regional backbone, not a global CDN, and we will say which you actually need.
The fundamentals
What makes a hosting network good?
Six things, and not one of them is a single headline figure. A network is good when the paths your traffic actually takes are diverse, uncongested, and trusted.
Route diversity
Multiple transit carriers plus direct peering, so one upstream's bad day reroutes instead of taking you offline.
Clean IP space
Reputation-checked addresses kept clean by active abuse handling — the network half of email deliverability.
Low, consistent latency
Short paths to the networks your users and the mailbox providers live on, with steady tail latency.
DDoS absorption
Always-on mitigation sized to absorb attacks at the edge before they reach a server.
Dual-stack IPv4 + IPv6
Both protocols, because the internet still needs IPv4 while IPv6 grows.
How do you measure a network — what should you look at?
By the things that show up in production, not the brochure. Latency and its consistency come first — not just the average round-trip to a few cities, but the jitter and the worst case, because a path that is fast on average and erratic under load still breaks real-time work. A looking glass that lets you trace routes from the network itself tells you more than any capacity claim, since you can see the actual paths and their length to the destinations you care about.
After latency come the things that are easy to hide. How many transit providers and exchange peerings are there really, and are they diverse enough that one failure reroutes? How is abuse handled — quickly and automatically, or slowly and by hand, which is what lets a neighbour's bad behaviour drag a whole block onto a blocklist? What does the SLA actually commit to, and what does it quietly exclude? We would rather you ask those questions than be impressed by a number, and we answer them plainly.
None of this requires you to be a network engineer. The short version is to look for diversity, clean reputation, and honest operations, and to be sceptical of any single headline figure presented as proof. A good network is boring in the best way: it does the same thing every day, and you stop thinking about it.
Transit or peering — what carries your traffic?
Both, and the mix is the point. Transit buys access to the whole internet routing table from an upstream; peering exchanges traffic directly with another network, often settlement-free at an internet exchange. Good networks use both — transit for reach, peering for the shortest, cheapest path to common destinations. A network that leans only on a single large carrier inherits that carrier's bad days; one that blends several upstreams with direct exchange peering can route around a problem before you notice it.
This is why the Tier-1 label matters less than people think. A blend of carriers with route diversity usually beats a single 'Tier-1' label. Multi-homing across several upstreams and direct peering gives more resilient, lower-latency paths than one provider, however large. The carriers in that blend are names like Lumen, Cogent, NTT, GTT, Arelion and others, reached over a backbone built from 10G, 100G, and increasingly 400G and 800G coherent optics; the headline capacity number matters less than whether it is real, diverse, and uncongested on your paths.
Cost sits underneath all of this and keeps falling. IP transit in 2026 runs roughly $0.03–$3.00 per Mbps, dropping under $0.10 in competitive US and EU markets on larger commits and exceeding $1.00 where competition is thin; per-Mbps prices keep eroding year over year. We size capacity to real traffic rather than a vanity number — Size a commit from three to six months of real traffic peaks plus a 20–30% buffer, not from a vanity capacity number — over-committing wastes budget on idle bandwidth. The savings are not the headline; resilient, uncongested paths are.
One practical point sits behind the blend: capacity has to have headroom. A link that runs at ninety-five percent on a normal evening has nothing left for a spike or the rerouted load when a neighbour fails, and that is when congestion turns into slow pages and timed-out connections. We provision the backbone and the uplinks to carry peak plus the failure case, so the busy hour and the bad day both look ordinary from the outside.
Clean IP space, and why it decides your email
Here is where the network stops being abstract and starts affecting your inbox placement directly. An IP address carries a reputation. Blocks with spam, abuse, or blocklist history trade at a discount and, more importantly, place mail in spam and trip security filters. Clean, consistently-used space is the foundation under good email deliverability and hosting trust. You can configure a mail server perfectly and still land in spam if the address it sends from carries someone else's history.
The market understands this now. The market now prices a 'clean IP' premium explicitly: reputation-checked blocks lease and sell for more because routing and abuse history are part of the asset. And reputation is not a property you buy once; Reputation is kept clean by operations, not luck: monitoring blocks daily, handling abuse quickly, and keeping the same space in consistent use so providers learn to trust it. When we assign space to a sending host, it is space with a clean history that we keep clean, which is the quiet half of the deliverability work described on its own page. See deliverability →
There is a reason this lives on the network page as much as the email one. A sending host inherits whatever reputation its address already carries, so the cleanest mail configuration in the world cannot rescue space that arrived pre-damaged. Treating addressing as part of deliverability — assigning clean blocks, isolating senders from each other, and never letting one customer's mistake pollute another's space — is a network discipline, and one of the quiet reasons our mail platform places well.
IPv4 or IPv6 — do you still need both?
For now, both. IPv6 adoption keeps growing but remains below half of global traffic, so dual-stack is the norm: IPv6 for the future, IPv4 retained for compatibility, third-party integrations, and email deliverability — expected to stay necessary for years. The IPv4 free pool is effectively exhausted; new space comes from a secondary market across the five RIRs (ARIN, APNIC, RIPE NCC, LACNIC, AFRINIC). That exhaustion is why clean IPv4 space is a priced, traded asset rather than something a provider hands out freely.
The numbers tell the story of scarcity. Buying runs roughly $15–$50 per address (a /24 of 256 addresses is on the order of $7,000–$11,000), varying by block size, region, and reputation. Leasing clusters around $0.30–$0.50 per address per month (a /24 roughly $80–$150), with APNIC space at a premium. We run dual-stack on every server — IPv6 enabled for the future, IPv4 reachable for the present — so your services work for every visitor and every mailbox provider regardless of which protocol they speak. The point is not to take sides in a protocol debate; it is to be reachable.
Reachability has a forward-looking edge too. IPv6 removes the scarcity problem entirely for the parts of your traffic that can use it, and enabling it now means you are not scrambling later as more networks turn it on by default. Running both is not hedging; it is meeting the internet where it actually is during a transition that has already lasted longer than anyone predicted and will run a while yet.
Routing
Anycast, BGP, and how a path fails safely
Resilience is a routing property, not a marketing one. The picture below is what multi-homing looks like: more than one way out, so a single failure reroutes instead of taking you down.
BGP is how networks advertise their routes to each other; multi-homing with sensible BGP policy is what lets a single uplink fail without taking your traffic down. Anycast announces the same address from many locations so each user reaches the nearest one; it is how resilient DNS and large-scale DDoS absorption are built, since attack and query traffic are spread across sites rather than funnelled to one. Together those two ideas — many paths out, and the same address answered from the nearest place — are most of how a network stays up under both ordinary failures and deliberate attacks. The terminal below is a real shape of it: an edge router holding two transit sessions and an exchange peering at once, each carrying the full or partial table, any one of which can drop without an outage.
The same diversity that survives a failure also resists an attack, which is why routing and security are not separate projects here. A flood arriving over one path can be shifted, scrubbed, or dropped at the edge while legitimate traffic keeps flowing over the others, and anycast spreads a large attack across sites instead of letting it concentrate on one. Designed together, routing and mitigation make the network hard to knock over by accident or on purpose.
edge1# show ip bgp summary
BGP router identifier 203.0.113.1, local AS number 64500
Neighbor AS Up/Down State/PfxRcd
198.51.100.2 3356 31w2d 986214 # transit — carrier A
198.51.100.6 174 24w5d 985880 # transit — carrier B
80.249.208.1 6695 18w0d 142037 # peering — internet exchange
# two transits plus exchange peering — a path can fail without you noticingRedundancy and the SLA
Resilience is built from the unglamorous parts. Power comes from more than one feed with battery and generator behind it; cooling is sized with a spare unit so a failure does not cook a rack; uplinks run to more than one carrier so a cut fibre reroutes. None of it is visible when it works, which is exactly the point — redundancy is the absence of incidents you never hear about.
Out-of-band management rides its own network, separate from the traffic path, so we can reach a server to fix it even when its main link is the thing that is broken. Maintenance is scheduled into announced windows rather than sprung on you, and the SLA puts numbers on what we commit to instead of leaving it to good intentions. We would rather promise what we can hold to and meet it than publish an impressive figure with a page of exclusions underneath.
The honest caveat is that no infrastructure is perfect, and anyone claiming a flawless record is selling something. What a serious operator offers is depth — more than one of everything that matters, and a team that has rehearsed the failure — so that when a part does fail, it is a non-event rather than your outage.
DDoS absorption at the edge
Capacity and routing are also the foundation of attack resilience. Because an attack is, in the end, traffic, a network with real headroom and many paths can absorb a great deal of it before anything reaches a server. We run always-on mitigation at the edge that scrubs hostile traffic inline rather than waiting for someone to flip a switch during an incident, so the common floods are handled without you noticing.
That is the network's part of the story; the dedicated protection layer — how detection works, what scale we absorb, and where the honest limits sit — has its own page. The two are designed together, because mitigation that is not built into the routing is mitigation that arrives late. See DDoS protection →
It is worth being clear about scale and honesty here, which is why the dedicated page exists: we tell you what size of attack we absorb and where the limits are, rather than implying infinite capacity. Most attacks a normal business sees are well within what an edge with real headroom handles quietly; the rare extreme case is a conversation we would rather have in advance than during an incident.
Do you actually need a premium network?
Not always, and we will say so. A small, low-traffic site is well served by standard connectivity, and paying for diverse transit and curated peering it will never stress is wasted money. The network earns its keep when one of a few things is true: you send email at volume and reputation decides your revenue, latency is part of what you are selling, or your traffic is high enough that a single-carrier outage or a moment of congestion would cost you real customers.
When those are true, the difference is not subtle — clean addresses that keep mail in the inbox, paths that stay short and uncongested, and an edge that shrugs off attacks are the difference between a platform you trust and one you babysit. When they are not, we will put you on solid standard connectivity and spend the effort where it actually moves your numbers. The honest goal is a network matched to your workload, not the longest line on an invoice.
This honesty cuts both ways, and it is worth saying plainly: we will also tell you when you have outgrown standard connectivity and are quietly losing mail or customers to congestion you have stopped noticing. The point is to match the network to the moment you are in, and to revisit it as you grow, rather than to sell you the top tier on day one or leave you on the bottom one a year too long.
Where the servers sit: regions and data residency
Where a server physically sits is part of the network, not a detail beside it. Latency is set largely by distance, so a host near your users and near the mailbox providers you send to is simply faster, and routing quality between regions decides how fast the rest of the world reaches it. We place servers in the regions that match your audience rather than wherever capacity happens to be cheapest that month.
Residency is the other half. Running in a known region on single-tenant hardware makes it a fact, not a hope, that data stays where your obligations require — which matters under the regimes tightening across Europe and beyond. We keep the region yours to choose, document where things run, and do not quietly move workloads to chase margin. The network and the geography are decided together, because a fast path to the wrong jurisdiction is not actually a win.
This is also why we are upfront about where we are not. If your users sit in a region we do not serve well, we will say so and help you find the right home rather than route their traffic the long way around and call it global. Honesty about geography is part of honesty about the network, and it saves you from a latency problem dressed up as a feature.
What we run, and what we will not claim
We run a multi-homed backbone — several transit carriers blended with direct peering at major exchanges — with reputation-checked clean IP space we monitor and keep clean, dual-stack IPv4 and IPv6 on every server, anycast DNS, and always-on DDoS absorption, in the regions we operate. Out-of-band management rides a separate network, and the routing is built so a single upstream failure reroutes rather than drops.
What we will not claim is to be a hyperscale global CDN with a point of presence on every continent. We are a strong, diverse regional backbone with excellent routes to where our customers and the major mailbox providers actually are. When your content genuinely needs to sit milliseconds from users everywhere, a dedicated CDN in front of our origin is the right answer, and we will tell you that rather than oversell our map. The point of the network is reachable, trusted, resilient delivery measured against your real traffic — not a longer list of flags on a marketing page.
And because the network underpins everything else we sell, it is not an add-on you negotiate separately: the clean addressing that helps your mail, the diverse routing that keeps your servers reachable, and the edge that absorbs attacks come with the machine rather than as a line item designed to be upsold. Good infrastructure should make the network boring, and that is what we are aiming for.
Questions
The network, answered plainly
The questions that come up before a workload moves.
What makes a hosting network good?
Real capacity with headroom, route diversity across several carriers plus direct peering, reputation-checked clean IP space, low and consistent latency, always-on DDoS absorption, and both IPv4 and IPv6. A single impressive number — a big backbone figure or a Tier-1 logo — tells you little on its own; what matters is whether the paths your traffic actually takes are diverse, uncongested, and trusted.
Transit or peering — what is the difference?
Transit buys access to the entire internet routing table from an upstream carrier, which gives you reach to everywhere. Peering exchanges traffic directly with another network, often without cost at an internet exchange, which gives you the shortest path to common destinations. Good networks use both: transit for universal reach, peering for speed and resilience to the places your users and the mailbox providers live.
Why does clean IP space matter for email?
Because an IP address carries a reputation. Addresses with a history of spam, abuse, or blocklist entries place mail in the spam folder and trip security filters regardless of how well your server is configured. Clean, reputation-checked space that is used consistently and kept clean through active abuse handling is the network half of email deliverability — and it is exactly the space we assign to sending hosts.
Do I still need IPv4, or is IPv6 enough?
You need both for now. IPv6 adoption keeps growing but is still below half of global traffic, so dual-stack is the norm: IPv6 for the future and IPv4 retained for compatibility, third-party integrations, and email deliverability. The IPv4 free pool is exhausted, which is why clean IPv4 space is a real, priced asset, and we run both protocols on every server.
What is anycast and do I need it?
Anycast announces the same address from many locations so each user reaches the nearest one. It is how resilient DNS and large-scale DDoS absorption work, because traffic spreads across sites instead of funnelling to one. You benefit from it in our DNS and mitigation whether or not you ever think about it; most workloads do not need to run their own anycast.
How do you keep IP reputation clean?
By operating it rather than hoping. We monitor blocks for listings, handle abuse reports quickly, keep address space in consistent use so providers learn to trust it, and assign sending hosts space with a clean history. Reputation is earned and maintained continuously, which is why it is part of network operations and not a one-time setup.
Is your network a global CDN?
No, and we will not pretend otherwise. We run a multi-homed backbone with strong routes to the networks our customers and the major mailbox providers use, in the regions we operate. For content that must be milliseconds from every continent, a dedicated CDN in front of our origin is the right tool, and we will tell you when that is the case rather than overstate our reach.
When do I actually need a premium network?
When you send email at volume and reputation matters, when latency is part of your product, or when traffic is high enough that congestion or a single-carrier outage would cost you. A small, low-traffic site is well served by standard connectivity. We would rather match the network to your workload than sell capacity and routes you will not use.
Tell us where your traffic goes.
Who your users and recipients are, how much you send, and how much an outage costs you — and we will match the network to it, honestly.