netcup Network Architecture, 2 TB Fair-Use Policy & Linux BBR Tuning
- Global Backbone: Powered by Anexia AS197540 with direct peering at DE-CIX, AMS-IX, VIX, SwissIX, and Equinix
- Unmetered Port Speeds: Root Servers feature 2.5 Gbps NICs and VPS plans feature 1 Gbps NICs with IPv4 + /64 IPv6 included
- 2 TB / 24h Fair-Use Rule: Exceeding 2 TB outbound in a rolling 24-hour window temporarily shapes the port to 200 Mbps until rolling usage drops
- High-BDP Optimization: Enabling BBR (fq + bbr) and increasing rmem/wmem to 64 MB boosts intercontinental single-thread speeds by 2x–5x
- Edge Best Practice: Pair your netcup origin with a CDN or WireGuard/Cloudflare Tunnel for global low-latency delivery
Table of Contents10 sections
When evaluating a cloud server or dedicated-core Root Server, raw CPU and NVMe numbers only tell half the story—network peering, traffic policies, and TCP stack tuning determine how fast your applications feel in production.
Many users see "2.5 Gbps Port" and "Unmetered Traffic" on netcup's specification sheets and wonder how the network performs globally and whether there are hidden bandwidth caps. This guide examines netcup's underlying AS197540 backbone, explains the 2 TB / 24-hour fair-use traffic shaping mechanism, and provides a production-ready Linux BBR + TCP buffer sysctl configuration for transatlantic and intercontinental links.
1. Backbone Architecture & Global Peering (AS197540)#
Rather than relying on budget single-homed resellers, netcup runs directly on the international network backbone of its parent company, Anexia (AS197540 / AS34225):
- Major Internet Exchange Points (IXPs):
Direct high-capacity peering at DE-CIX Frankfurt (one of the largest IXPs in the world), AMS-IX Amsterdam, VIX Vienna, SwissIX Zurich, LINX London, Equinix Ashburn, and Equinix/SGIX Singapore.
- Regional & Intercontinental Latency Benchmarks:
- Intra-Europe (Nuremberg to Frankfurt, Amsterdam, Vienna, Zurich): 3 ms – 10 ms
- Western & Northern Europe (London, Paris, Milan, Stockholm): 12 ms – 22 ms
- Transatlantic (Nuremberg/Amsterdam to US East Coast): 75 ms – 85 ms
- North America (Manassas
MNZto New York/Toronto/Chicago): 8 ms – 28 ms - Asia-Pacific (Singapore
SINto ASEAN/Tokyo/Sydney): 15 ms – 65 ms
2. International Routing Characteristics (Europe, Americas & APAC)#
Because netcup serves a diverse global engineering audience, understanding how traffic routes across continents helps you architect resilient deployments:
1. Europe, UK, Middle East & Africa (EMEA)#
- Routing Path: Direct bilateral peering at DE-CIX, AMS-IX, and VIX with major consumer and business ISPs (Deutsche Telekom, Vodafone, Liberty Global, BT, Orange, Swisscom, Init7).
- Performance: Near-zero packet loss and single-digit to low-double-digit millisecond latency. Both
1 Gbps(VPS) and2.5 Gbps(Root Server) ports easily saturate line rate.
2. North & South America#
- Routing Path: Direct transatlantic wavelengths between Frankfurt/Amsterdam/London and New York/Ashburn, plus native local peering from the Manassas (
MNZ) datacenter. - Performance:
8–25 mson the US East Coast (~65 msto the US West Coast) fromMNZ, or~80 msfrom Nuremberg. High-bandwidth transfers between EU and US nodes benefit significantly from TCP window scaling (detailed in Section 4).
3. Asia-Pacific & Mainland China#
- APAC Regional Peering: From Singapore (
SIN), traffic routes directly via Equinix SG and SGIX to Southeast Asia, Japan, India, and Australia (15–60 ms). - Mainland China Note: netcup uses standard international Tier-1 transit (Telia/Arelion, Cogent, NTT, GTT) and does not purchase specialized China-only premium circuits (such as CN2 GIA or CUII 9929). From Nuremberg (
NUE), traffic reaches China directly via Frankfurt (180–220 ms), whereas Singapore (SIN) to mainland China may route via the US or Europe. For global web applications serving Asian users, placing a CDN (such as Cloudflare) in front of your netcup server caches static assets at the edge and eliminates intercontinental round-trip overhead.
3. The 2 TB / 24h Outbound Fair-Use Traffic Policy Explained#
All current netcup VPS and Root Server G12.5 plans advertise "Traffic: Unlimited / Unmetered" at €0.00 per TB. However, netcup enforces an automated, transparent Fair-Use Traffic Shaping Policy in its Acceptable Use Policy (AUP):
How the Trigger Works#
If a server's outbound traffic exceeds 2 TB within a rolling 24-hour window (equivalent to sustaining ~185 Mbps continuously for 24 hours straight), the network port is automatically throttled to 200 Mbps.
- Automatic Recovery (No Extra Charges):
- You are never billed for overage traffic, and your server is never suspended for hitting 2 TB/day.
- Even while throttled to
200 Mbps, a server can still push nearly 2 TB per day (~60 TB per month). - As soon as your rolling 24-hour outbound volume drops back below the 2 TB threshold, the system automatically restores your full 1 Gbps or 2.5 Gbps port speed.
- Which Workloads Trigger Throttling?
- High-volume public BitTorrent seedboxes, uncached video streaming origins, or public mirror servers pushing multi-terabyte daily egress.
- Which Workloads Are Never Affected?
- Production SaaS apps, e-commerce stores, Nextcloud instances, mail servers, game servers, Git repositories, and daily encrypted offsite backups (
restic/borg). Even pushing 100–300 GB per day stays far below the 2 TB / 24h threshold.
- Production SaaS apps, e-commerce stores, Nextcloud instances, mail servers, game servers, Git repositories, and daily encrypted offsite backups (
4. Production Linux Kernel Tuning: TCP BBR + High-BDP Buffers#
On intercontinental links (such as Europe to North America at 80 ms RTT, or Europe to Asia at 160–200 ms RTT), the Bandwidth-Delay Product (BDP) is high. Traditional Linux congestion control (cubic) and conservative default socket buffers (rmem / wmem) restrict single-connection throughput and halve the congestion window on the slightest packet loss.
Enabling Google TCP BBR (fq + bbr) alongside 64 MB maximum TCP buffers allows a single SSH, HTTPS, or WireGuard stream to saturate high-speed ports across oceans.
Apply the Production Sysctl Configuration (Debian 12 / Ubuntu 24.04)#
Run the following block as root:
cat << 'EOF' > /etc/sysctl.d/99-network-bbr.conf
# Enable Fair Queueing packet scheduler and Google BBR congestion control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# Increase TCP socket buffers for high-BDP intercontinental links (up to 64 MB)
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# Enable window scaling, selective acknowledgments, and TCP Fast Open
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fastopen = 3
# Optimize connection queues and socket backlog for high-concurrency servers
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_fin_timeout = 15
EOF
# Reload sysctl parameters immediately without rebooting
sysctl --system
Verify Your Configuration#
# Confirm active congestion control (must output: bbr)
sysctl net.ipv4.tcp_congestion_control
# Confirm packet scheduler (must output: fq)
sysctl net.core.default_qdisc
# Verify the tcp_bbr kernel module is loaded
lsmod | grep bbr
With BBR and expanded socket buffers active, single-stream transatlantic and intercontinental transfers typically achieve a 2x to 5x throughput boost!