Contents
1. AS197540 Backbone, IXP Peering & Global Transit Profile
netcup operates under AS197540 (netcup GmbH) alongside parent carrier AS42473 (Anexia), backed by 2 Tbps automated DDoS mitigation. Understanding regional routing explains why European origin hosting paired with an Anycast CDN outperforms paying steep location surcharges:
| Region / IXP | Primary Upstream & IXP Peers | Typical RTT from Nuremberg (NUE) | Production Recommendation |
|---|---|---|---|
| Central Europe (DE / AT / NL / CH) | DE-CIX Frankfurt, VIX Vienna, AMS-IX, Deutsche Telekom (DTAG), Arelion (AS1299) | 2 – 12 ms | Direct origin connection — ultra-low jitter for WebSockets, PostgreSQL & WireGuard |
| Cloudflare / Fastly / Bunny Edge | Direct Frankfurt IXP & Private Network Interconnect (PNI) | 1.5 – 3.5 ms | Enable HTTP/3 + Tiered Cache so global visitors hit local POPs with ~2 ms origin pulls |
| North America (US-East / US-West) | Arelion, GTT, Cogent transatlantic fibers (or native Manassas US node) | 82 – 145 ms | Select Manassas (US) for US-only apps, or Nuremberg + Cloudflare Tiered Cache globally |
| East Asia & APAC | Arelion / NTT / Tata European handoff (evening congestion on consumer ISPs) | 155 – 240 ms | Put web origins behind Cloudflare CDN + enable TCP BBR on kernel 6.1+ |
2. Hardened Cloudflare Origin Setup (mTLS + BBR Tuning)
When fronting a VPS 1000 G12.5 or RS 1000 G12.5 with Cloudflare, lock port 443 exclusively to Cloudflare’s IPv4/IPv6 ranges (or Authenticated Origin Pulls) and enable bbr congestion control so long-distance cache misses recover immediately from packet loss:
# Enable TCP BBR + fq qdisc on Debian 12/13 (Kernel 6.1+)
cat <<'EOF' > /etc/sysctl.d/90-netcup-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
EOF
sysctl --system
sysctl net.ipv4.tcp_congestion_controlIn Cloudflare Dashboard, enable SSL/TLS → Full (Strict) with a 15-year Origin CA certificate, turn on Argo Tiered Cache (Free Smart Topology) so APAC/US edge nodes pull through Cloudflare Frankfurt (2 ms from Nuremberg) instead of opening separate transcontinental origin connections, and enable HTTP/3 (QUIC) + 0-RTT.
3. Clean Minimal Debian 12/13 Reinstall Without Losing IPv6 (fe80::1)
netcup’s SCP already provides clean official Debian images, which we recommend first. If you perform a custom netboot or minimal installation via SCP HTML5 VNC / Grml Rescue, inspect your active addresses before wiping the disk and preserve netcup’s static link-local IPv6 gateway (fe80::1):
# Step 1: Record your exact IPv4, gateway and /64 IPv6 prefix BEFORE reinstalling
ip -4 addr show scope global && ip -4 route show default
ip -6 addr show scope global && ip -6 route show default
# Step 2: Static /etc/network/interfaces snippet for clean Debian on netcup KVM
auto ens3
iface ens3 inet dhcp
iface ens3 inet6 static
address 2a03:4000:XXXX:XXXX::1/64
gateway fe80::1Always keep an SCP VNC window open during network restarts — if SSH drops, log straight in via VNC console without triggering rescue mode.
Frequently Asked Questions
How fast is connectivity between netcup Nuremberg and Cloudflare?
netcup AS197540 maintains high-capacity peering and PNI interconnects in Frankfurt (DE-CIX), delivering 1.5–3.5 ms origin fetches between Nuremberg KVM servers and Cloudflare edges.
Why do custom Debian netboot installs lose connectivity on netcup?
Most automated scripts rely on DHCPv6/SLAAC, whereas netcup routes IPv6 statically via the link-local gateway fe80::1 and requires explicit /32 or /22 IPv4 netmask configuration if DHCP times out.
Should I enable TCP BBR on netcup KVM instances?
Yes. Enabling tcp_bbr with fq queue discipline in Debian 12/13 Linux 6.1+ kernels significantly improves long-haul throughput to North America and Asia-Pacific.