IP Transit

Connect your network to Internet

IP Transit via direct interconnection or IP-IP tunnel. Technical support from study to production.

≥ 50 Gbps
Capacity
AS215599
Our network
< 1ms
Paris latency
99.99%
SLA

What we offer

Two connection modes depending on your geographic and technical situation.

Direct Interconnection

Physical cross-connect in our partner datacenters or via European IXs.

Copper/fiber cross-connectLatency < 1ms

IP-IP Tunnel

When physical interconnection is not possible, secure tunnel to your infrastructure.

GRE / IP-IP / WireGuardOptional encryptionSetup < 24h

DDoS Protection

Mitigation included on all our transits. Your traffic is protected by default.

Up to 10 TbpsDetection < 3sZero downtime

How it works

01
Study

Analysis of your infrastructure and needs.

02
Proposal

Recommended architecture and capacity.

03
Deployment

Cross-connect or tunnel, BGP config.

04
Production

Continuous monitoring, dedicated support.

For whom ?

Hosters

Diversify your transit mix

Gaming

Optimized latency to EU players

ISP / Operators

Complete your peering policy

FAQ - Frequently Asked Questions

It is the service that connects your network to the rest of the Internet. Your transit provider announces your prefixes worldwide and carries your traffic both ways. Without it, your addresses exist but nobody knows how to reach them.
The Zkillu network, AS215599, delivers at least 50 Gbit/s of transit capacity, with latency under 1 ms from Paris and a 99.99% availability commitment. Capacity is then scaled up according to your actual consumption.
Yes. The service is designed for you to announce your own prefixes with your ASN, over a BGP session. That is the main use case: an operator, a host or a company that owns its addresses and wants to choose where they exit.
You can start without one. Addresses are then provided and announced from our network. Getting your own ASN from the RIPE becomes relevant the day you want multiple transit providers and want to keep your addresses when changing carrier.
You send us your ASN, your prefixes and your routing objects, we configure the session on our side, and the connection comes up. The longest part is not technical: it is updating your objects in the RIR database, without which filtering will reject your announcements.
Yes, and that is good news. Filtering policies govern what each customer may announce, which protects network stability and stops one customer's misconfiguration from spreading to the others. Your announcements must therefore match your declared objects.
Yes. Transit is used with a dedicated server, a colocation rack or infrastructure already in place. Many customers combine both: their hardware in our datacenter, and their own addressing announced on top.
Bandwidth is stable and sized over multi-carrier links, which avoids depending on a single upstream provider. The exact level is set at quotation, based on your average traffic and your peaks.
Yes, the service scales in bandwidth and capacity. That is the normal way to run it: size on observed traffic, then adjust. Starting tight and growing beats oversizing from the outset.
Companies, hosts, service providers and operators running their own network. If you do not know what a BGP session is, IP transit is probably not what you need: a dedicated server or a VPS will serve you better.
Yes, both IPv4 and IPv6 are carried. Announcing your prefixes in both families is the recommended setup, and IPv6 avoids the growing scarcity and cost of IPv4.
Our support assists with configuration and operation. On transit, incidents are rarely outright failures: they are routes that do not appear where expected, and that is diagnosed together, with the routing tables in front of you.
Need help?Available now

We're here to unlock your project.

Tell us where you are, we'll respond in minutes and launch the rocket.