Internet Connectivity Requirements

The documented minimum internet connectivity specification for a production Unturned™ hosting deployment on owned enterprise hardware at 57 Studios™ is 1 Tbps symmetrical commercial fiber, terminated on the operator's premises through two physically diverse carrier entrances, and routed through a dual-carrier BGP topology with independent autonomous system numbers on each upstream. The specification is non-negotiable for production. The reasoning is rooted in the per-player bandwidth calculation, the per-server-instance aggregate, the per-rack aggregate, and the documented headroom requirement that the professional hosting community has codified.

This article specifies the internet connectivity layer in full. The 1 Tbps symmetrical minimum is documented in the bandwidth-per-player calculation. The dual-carrier requirement is documented in the BGP failover topology. The minimum two-ISP rule is documented in the carrier selection table. The cross-connect and metro-fiber options are documented in the building entrance design. The reference carrier list is documented in prose. The article closes with twelve frequently asked questions and three appendices.

Prerequisites

• A completed read of Power and UPS Configuration
• A building with two physically diverse carrier entrance vaults, separated by a minimum of 6 meters of horizontal distance and routed through independent ductwork to the curb
• A documented IP allocation from the operator's regional internet registry, or from each upstream carrier
• A registered autonomous system number (ASN) issued by the operator's regional internet registry
• A planned BGP topology with two upstream commercial transit providers, each capable of delivering the documented 1 Tbps symmetrical specification
• A network operations center capable of monitoring carrier health, BGP session state, and route advertisement on a 24/7 cadence

What you will learn

• The documented 1 Tbps symmetrical commercial fiber minimum specification
• The bandwidth-per-player calculation and the per-server-instance aggregate
• The per-rack aggregate, the per-pod aggregate, and the documented headroom factor
• The reference carrier list and the carrier selection criteria
• The cross-connect option, the metro-fiber option, and the dark-fiber option
• The dual-ISP topology with independent autonomous system numbers
• The latency budget per tier and the documented end-to-end target
• Twelve frequently asked questions on residential adequacy, GPON versus DWDM, IP transit pricing, and dark fiber

The documented 1 Tbps symmetrical commercial fiber minimum

Production Unturned hosting at 57 Studios scale runs on a minimum of 1 Tbps symmetrical commercial fiber at every carrier entrance. The specification is documented in the production estate operational runbook, the procurement specification, and the carrier-facing technical requirements document. The specification is the floor. Operators with larger per-rack densities, larger player counts, or larger mod-asset footprints scale the specification upward in increments of 1 Tbps per pod.

The 1 Tbps figure is the symmetrical minimum. Symmetrical means that the upstream and downstream tiers are matched at 1 Tbps each. Asymmetric tiers (1 Tbps downstream with a smaller upstream) are insufficient. The mod-asset streaming, player-to-player state replication, and backup egress are all upstream-heavy workloads, and the upstream tier must match the downstream tier.

The 1 Tbps figure is the commercial minimum. Commercial means a dedicated, contracted-capacity, service-level-agreement-backed circuit from a commercial carrier. Residential fiber, small-business fiber, and consumer-grade gigabit passive optical network (GPON) services are outside the scope of this article and are not suitable for production hosting. The carrier-side equipment, the service level, the operational support, and the routing capability of consumer-grade services do not meet the documented minimum.

The 1 Tbps figure is the per-carrier-entrance minimum. The dual-carrier topology documented later in this article requires that each of the two carriers deliver the 1 Tbps minimum independently. The aggregate of the two carriers is 2 Tbps; the per-carrier figure is the 1 Tbps minimum specified here. The reasoning is that a carrier-side outage on one of the two upstreams must leave the remaining upstream capable of carrying the full production load. The remaining upstream is the 1 Tbps minimum.

Did you know?

The 1 Tbps symmetrical specification is below the per-rack aggregate documented later in this article for the largest 57 Studios pods. The 1 Tbps figure is the floor. The reference build at the production estate's largest pod sustains 2.4 Tbps of aggregated traffic during peak weekend windows, and the carrier-side provisioning is sized at 4 Tbps per entrance to provide documented headroom against burst events and forecasted growth.

The bandwidth-per-player calculation

The bandwidth-per-player calculation is the foundation of the 1 Tbps specification. The calculation aggregates the per-player packet rate, the per-packet payload, the player-to-player state replication factor, the mod-asset streaming rate, and the active-world-chunk replication. The product of those terms is the per-player bandwidth, which is multiplied by the player count per instance, the instance count per rack, the rack count per pod, the pod count per site, and the documented headroom factor to arrive at the site-level aggregate.

The reference calculation is documented below. The calculation is reproduced from the 57 Studios production estate's network engineering specification, which is the source document for the 1 Tbps specification.

Step 1: Packet rate per player

The Unturned server replicates state to each connected client at a documented tick rate. The default tick rate is 24 packets per second per player. The packet rate per player is documented as:

packet_rate_per_player = 24 packets / second

The 24 packets per second figure is the unmodified default. Production deployments at 57 Studios run at a documented elevated tick rate of 32 packets per second to deliver the responsiveness profile that the production player population expects. The elevated tick rate is the documented production value, and the bandwidth calculation uses the elevated value.

packet_rate_per_player_production = 32 packets / second

Step 2: Payload size per packet

The per-packet payload at the production tick rate is documented at 1.4 KB per packet, encompassing the position vector, the orientation quaternion, the velocity vector, the animation state, the inventory delta, and the active-world-chunk delta. The payload size is documented as:

payload_size_per_packet = 1.4 KB / packet = 11200 bits / packet

The 1.4 KB figure is the documented average across a production session window. Peak payload sizes during heavy combat exchanges exceed 4 KB per packet, and the bandwidth calculation incorporates a peak-to-average ratio in a later step.

Step 3: Bandwidth per player (single-direction)

The single-direction bandwidth per player is the product of the packet rate and the payload size.

bandwidth_per_player_single_direction = 32 * 11200 = 358400 bits / second = 358 Kbps

Step 4: Player-to-player state replication factor

The Unturned server architecture replicates per-player state to every other connected player within the active simulation radius. For a server instance with N connected players, the per-player state must be transmitted approximately N-1 times. The replication factor for a documented production instance of 200 connected players is:

replication_factor = 200 - 1 = 199

The bandwidth per player after replication is:

bandwidth_per_player_after_replication = 358 Kbps * 199 = 71 Mbps

The per-player figure of 71 Mbps is the bandwidth that the server must transmit downstream for the single player's state to reach every other connected player at the documented production tick rate.

Step 5: Mod-asset streaming

Production Unturned hosting at 57 Studios streams mod assets to connecting players on join. The mod-asset footprint for a production server is documented at 4.2 GB across all loaded mods, and the streaming rate is capped at 80 Mbps per connecting player to balance the join time against the bandwidth headroom for the active player base. The mod-asset streaming bandwidth per joining player is:

mod_asset_streaming_per_joining_player = 80 Mbps

The active joining rate during a production peak window is documented at 8 concurrent joining players per server instance. The aggregate mod-asset streaming bandwidth per instance during peak is:

mod_asset_streaming_per_instance_peak = 80 Mbps * 8 = 640 Mbps

Step 6: Active-world-chunk replication

The active-world-chunk replication is the streaming of map terrain, prop, and physics state to players entering new chunks. The per-chunk payload is documented at 12 MB, the chunk transit rate during a production session is documented at 3.4 chunks per player per minute, and the resulting bandwidth per player is:

chunk_replication_per_player = 12 MB * 3.4 / 60 = 0.68 MB / second = 5.4 Mbps

The aggregate chunk replication for a 200-player instance is:

chunk_replication_per_instance = 5.4 Mbps * 200 = 1.08 Gbps

Step 7: Per-instance aggregate

The per-instance aggregate bandwidth is the sum of the player-to-player replication, the mod-asset streaming, the chunk replication, the per-player monitoring telemetry (documented at 12 Kbps per player), and the documented service overhead (12 percent of the subtotal).

per_instance_player_state = 71 Mbps * 200 = 14.2 Gbps
per_instance_mod_asset_streaming = 640 Mbps
per_instance_chunk_replication = 1.08 Gbps
per_instance_telemetry = 12 Kbps * 200 = 2.4 Mbps
per_instance_subtotal = 14.2 + 0.64 + 1.08 + 0.0024 = 15.92 Gbps
per_instance_aggregate_with_overhead = 15.92 * 1.12 = 17.83 Gbps

The per-instance aggregate is 17.83 Gbps at the documented production parameters.

Step 8: Per-rack aggregate

The documented production rack carries 12 server instances. The per-rack aggregate is:

per_rack_aggregate = 17.83 Gbps * 12 = 213.9 Gbps

Step 9: Per-pod aggregate

The documented production pod consists of 8 racks. The per-pod aggregate is:

per_pod_aggregate = 213.9 Gbps * 8 = 1711.2 Gbps = 1.71 Tbps

Step 10: Per-site aggregate and headroom

The documented production site consists of a single pod at the smallest reference build, with capacity to scale to four pods. The per-site aggregate at the documented production parameters with the documented 60 percent headroom factor is:

per_site_subtotal = 1711.2 Gbps
documented_headroom_factor = 1.60
per_site_with_headroom = 1711.2 * 1.60 = 2738 Gbps = 2.74 Tbps

The per-site requirement at the smallest reference build, with documented headroom, is 2.74 Tbps. The 1 Tbps per-carrier-entrance minimum is the floor; the smallest reference build's per-site requirement exceeds the floor and is the reason that the 57 Studios production estate's largest pods provision 4 Tbps per entrance.

Did you know?

The 60 percent headroom factor is the documented production estate value. The factor encompasses burst events (large mod releases, weekend peak windows, in-game events), forecasted growth (12 to 18 month forward projection), and the safety margin for unanticipated traffic patterns. The factor is documented in the network engineering specification and is reviewed annually.

Pro tip

The bandwidth-per-player calculation is parametric in the player count, the tick rate, the payload size, the mod-asset footprint, and the chunk transit rate. Operators with different production parameters substitute the operator's documented values into the calculation and arrive at the operator-specific per-site requirement. The 1 Tbps minimum is the floor; the operator-specific calculation is the ceiling.

Residential and small-business fiber are outside scope

Residential fiber, small-business fiber, and consumer-grade gigabit passive optical network (GPON) services are outside the scope of this article and are not suitable for production Unturned hosting on owned enterprise hardware. The reasoning is documented across five dimensions: per-port bandwidth, symmetric capacity, service level, routing capability, and operational support.

The per-port bandwidth of a residential fiber service is documented at 1 Gbps to 10 Gbps at the highest consumer tiers in major metropolitan areas. The 10 Gbps figure is three orders of magnitude below the documented 1 Tbps minimum and is structurally insufficient for production hosting. The 1 Tbps minimum requires a dense-wavelength-division-multiplexing (DWDM) or coherent optical transport circuit, and these circuit classes are not available on residential service contracts.

The symmetric capacity of a residential fiber service is documented as asymmetric on the majority of consumer offerings. The upstream tier is documented at 10 to 50 percent of the downstream tier on consumer GPON services. The production Unturned workload is upstream-heavy, and the asymmetric profile of consumer service is structurally insufficient.

The service level of a residential fiber service is documented at 99.0 to 99.5 percent uptime, with a 24- to 72-hour mean time to repair. The production Unturned hosting service level target is 99.99 percent uptime with a 15-minute mean time to detection and a 45-minute mean time to repair. The consumer service level is two orders of magnitude below the production target.

The routing capability of a residential fiber service is documented as carrier-grade-NAT (CGNAT) terminated. The customer receives a private IPv4 address and a shared public address. The production Unturned hosting requirement is a dedicated, advertised, BGP-routable IP block. The CGNAT-terminated residential service does not deliver this capability.

The operational support of a residential fiber service is documented as consumer-facing call-center support with a tiered escalation path and a typical first-response time of 30 minutes to 4 hours. The production Unturned hosting operational target is a carrier-grade network operations center with a 5-minute first-response time, a dedicated technical account manager, and a 24/7 escalation path. The consumer support model is structurally insufficient.

Common mistake

Operators new to self-hosting are sometimes tempted to begin with a residential fiber service on the reasoning that the production load is small at launch. This reasoning is incorrect. The production load grows beyond the residential ceiling on day one of a documented production deployment, and the migration path from residential to commercial fiber requires a carrier change, an entrance vault retrofit, an ASN registration, and an IP allocation. The migration is a multi-month project. The production hosting begins on commercial fiber on day one.

Critical warning

A residential fiber service does not produce a BGP-routable IP block. A production hosting deployment requires a BGP-routable IP block to advertise on the dual-carrier topology. Beginning a production hosting deployment on a residential service produces a structural blocker at the network layer that no amount of server-side optimization can resolve.

The documented carrier reference list

The 57 Studios production estate's carrier reference list is documented in prose below. The list is the set of upstream commercial transit providers that the production estate has either contracted with or evaluated for contracting. The list is the operator-facing reference for carrier selection; the operator is expected to evaluate the list against the operator's geographic, regulatory, and operational constraints.

Lumen Technologies is the documented primary upstream for the largest 57 Studios pods. Lumen operates a North American and global tier-1 backbone with documented 1 Tbps and 10 Tbps service offerings at major metropolitan interconnect facilities. Lumen's IP transit product is the reference offering for the dual-carrier topology's primary upstream slot. The Lumen network's reach into the major game-traffic destinations is the operational reason for the primary-upstream selection.

Cogent Communications is the documented secondary upstream for the same pods. Cogent operates a global tier-1 backbone with documented 1 Tbps and 10 Tbps service offerings at the same interconnect facilities. Cogent's IP transit pricing is the reference low-cost-per-Mbps benchmark in the tier-1 carrier market, and the Cogent network is the documented secondary-upstream choice for the dual-carrier topology. The reasoning is the price-per-Mbps ratio and the documented BGP advertisement compatibility with Lumen.

Zayo Group is the documented metro-fiber and dark-fiber provider for the production estate's intra-metropolitan-area cross-connects. Zayo's metropolitan fiber footprint is the densest in the largest metropolitan areas, and the Zayo dark-fiber product is the reference path for the production estate's pod-to-pod interconnects. Zayo's IP transit product is also a documented evaluated alternative to Lumen for the primary-upstream slot, and the operator's regional Zayo footprint informs the carrier-selection decision.

Hurricane Electric is the documented evaluated alternative for the secondary-upstream slot. Hurricane Electric's IPv6 backbone is the reference IPv6-capable transit network, and the Hurricane Electric IP transit product is the documented choice for operators with an IPv6-first deployment posture. The production estate's IPv6 traffic is routed through Hurricane Electric in the documented dual-upstream configurations that include Hurricane Electric.

The reference list is not exhaustive. The operator's geographic region determines the regionally available carriers. The documented carrier-selection criteria are: tier-1 backbone status, documented 1 Tbps service offering, geographic reach into the operator's player destinations, BGP advertisement compatibility with the dual-carrier topology, IP transit pricing within the operator's procurement budget, and operational support quality.

Did you know?

The four documented carriers in the reference list are all tier-1 transit providers, which means they do not purchase transit from any other carrier. The dual-upstream topology with two tier-1 carriers produces the documented BGP failover profile, and the dual-tier-1 configuration is the production-standard topology. Operators evaluating tier-2 or tier-3 carriers as upstreams introduce additional carrier dependencies and are documented as deviating from the production standard.

Cross-connect, metro-fiber, and dark-fiber options

The production estate's building entrance design supports three carrier delivery options: cross-connect at a colocation facility, metro-fiber to the operator's premises, and dark-fiber to a far-end carrier handoff. Each option has a documented use case in the production estate, and the operator's geographic and operational constraints determine the appropriate option.

Cross-connect at a colocation facility

The cross-connect option terminates the carrier's circuit on a meet-me-room patch panel at a colocation facility, and the operator's circuit terminates on the same patch panel. A cross-connect cable joins the two circuits. The cross-connect is the documented lowest-latency option, the documented lowest-cost option for the carrier-side provisioning, and the documented preferred option for production hosting at major metropolitan colocation facilities.

The cross-connect option is documented as available at the major metropolitan colocation facilities operated by Equinix, Digital Realty, CoreSite, Cyxtera, and the regional equivalents. The 57 Studios production estate's largest pods are documented as cross-connected at Equinix's flagship metropolitan facilities, with the production-standard dual-cross-connect topology placing one cross-connect to each of the two upstream carriers.

The cross-connect fee is documented as a monthly recurring charge per cross-connect, with the typical range of $300 to $600 per month per cross-connect at major metropolitan facilities. The cross-connect fee is independent of the bandwidth provisioned on the circuit, and the cross-connect fee is the same for a 1 Tbps cross-connect as for a 10 Gbps cross-connect.

Metro-fiber to the operator's premises

The metro-fiber option extends the carrier's circuit from the metropolitan core to the operator's premises, terminating on the operator's building entrance vault. The metro-fiber option is the documented choice for operators whose production hosting is not located in a colocation facility. The metro-fiber option is documented as available from Zayo, Lumen, and the regional carriers in the major metropolitan areas.

The metro-fiber option introduces additional latency relative to the cross-connect option. The documented latency penalty is approximately 0.5 to 2 milliseconds per direction, depending on the distance from the metropolitan core to the operator's premises and the number of intermediate amplification points. The metro-fiber option is the documented choice when the cross-connect option is not geographically available.

The metro-fiber option is delivered on a one-time non-recurring construction charge plus a monthly recurring service charge. The construction charge varies with the distance from the carrier's nearest point of presence to the operator's premises, and the documented range is $25,000 to $250,000 for a typical major-metropolitan deployment.

Dark-fiber to a far-end carrier handoff

The dark-fiber option leases an unlit fiber pair from the operator's premises to a far-end carrier handoff facility. The operator provides the optical transport equipment on both ends of the fiber pair, and the operator is responsible for the optical light budget, the wavelength assignment, and the protection switching. The dark-fiber option is the documented choice for operators with multi-site deployments that require pod-to-pod interconnects independent of the upstream carriers.

The dark-fiber option produces the documented lowest end-to-end latency between two operator-controlled endpoints, and the option produces the documented highest aggregate bandwidth on a single fiber pair through DWDM multiplexing. The dark-fiber option is documented as available from Zayo, Lumen, the regional fiber providers, and certain municipally owned fiber utilities.

The dark-fiber option is delivered on a long-term lease, with documented terms of 5 years, 10 years, and 20 years (the longest term is an indefeasible right of use, or IRU). The lease cost varies with the distance and the term length, and the documented range is $1,500 to $15,000 per mile per year for the 10-year term.

Pro tip

The production estate's pod-to-pod interconnects are documented as dark-fiber circuits on 20-year IRU terms. The reasoning is that the pod-to-pod interconnect is a long-lived infrastructure investment, and the IRU term produces the documented lowest cost per mile per year across the lease term range. The operator's pod-to-pod interconnect strategy is a strategic decision that benefits from the longest-term lease available.

The dual-ISP topology with independent autonomous system numbers

The production Unturned hosting topology at 57 Studios is documented as a dual-ISP topology with independent autonomous system numbers (ASNs) on each upstream. The dual-ISP topology is the production standard. The reasoning is documented in the BGP failover behavior: a single-upstream topology produces total service interruption on the single upstream's outage, and a dual-upstream topology produces transparent failover to the surviving upstream within the BGP convergence window.

The autonomous system number

The operator's autonomous system number (ASN) is the identifier that the operator's network presents to the BGP routing system. The ASN is registered with the operator's regional internet registry (ARIN, RIPE, APNIC, LACNIC, or AFRINIC), and the ASN is the operator's permanent identifier in the global BGP routing table.

The ASN is a 32-bit integer (extended from the legacy 16-bit ASN range), and the assignment is unique across the global BGP routing system. The operator's ASN advertises the operator's BGP-routable IP block to both upstream carriers, and the upstream carriers in turn advertise the operator's IP block to the global BGP routing system on the operator's behalf.

The 57 Studios production estate is documented as operating a single ASN across all production sites, with the multi-site deployment presenting a unified routing posture to the global BGP system. The single-ASN multi-site posture is the documented production standard at the scale of the production estate. Operators with smaller deployments operate a single ASN with a single site, and the single-ASN single-site topology is also a documented production standard.

Route advertisement and withdrawal

The operator's BGP-routable IP block is advertised to both upstream carriers under the operator's ASN. The advertisement is the operator's declaration to the global BGP routing system that the operator's IP block is reachable through the operator's network. The upstream carriers re-advertise the block to their own peers, and the block is propagated through the global BGP routing system over the documented convergence window of 30 seconds to 5 minutes.

On the loss of one upstream link, the operator's BGP session to that upstream is torn down. The upstream's router withdraws the operator's IP block from its own advertisements, and the global BGP routing system re-converges to route the operator's IP block through the surviving upstream. The convergence window for the withdrawal-and-re-convergence event is documented at 30 seconds to 90 seconds in the production estate's measured deployments.

The withdrawal-and-re-convergence window is the documented BGP failover convergence time. The production estate's operational target for end-to-end failover is 60 seconds, and the measured median across the production estate's failover events is 47 seconds. The dual-ISP topology with independent ASNs on each upstream is the configuration that produces this convergence profile.

BGP path attributes for failover

The dual-upstream topology requires that the operator's network influence the BGP path selection on the inbound direction. The standard BGP path attribute for inbound traffic engineering is the AS path prepending mechanism, in which the operator's network prepends additional ASN entries to the advertisement on the secondary upstream to make the secondary path appear less preferred than the primary path.

The production estate is documented as advertising the operator's IP block with a single ASN entry on the primary upstream (Lumen) and with three ASN entries on the secondary upstream (Cogent). The three-entry prepend makes the secondary path less preferred than the primary path under normal operating conditions, and the global BGP routing system routes inbound traffic through Lumen by default. On the loss of the Lumen path, the global BGP routing system re-converges to the Cogent path, and the three-entry prepend is irrelevant because the Lumen path is no longer available.

The outbound direction is engineered through the operator's BGP route map on the operator's edge router. The route map applies a local preference attribute to the inbound advertisements from each upstream, and the operator's edge router selects the higher-local-preference path for outbound traffic. The production estate is documented as configuring a local preference of 200 on the Lumen inbound advertisements and a local preference of 100 on the Cogent inbound advertisements, producing the documented outbound preference for Lumen.

BGP session timers

The BGP session between the operator's edge router and each upstream carrier is maintained through periodic keepalive messages. The default BGP keepalive timer is 60 seconds, and the default BGP hold timer is 180 seconds. The production estate is documented as configuring aggressive BGP timers of 10 seconds keepalive and 30 seconds hold, producing a faster detection of link loss on the BGP session.

The aggressive timer configuration is documented as a production-standard practice at 57 Studios. The reasoning is that the aggressive timers reduce the BGP failover detection time from the default 180 seconds to the configured 30 seconds, which is well within the documented operational target of 60 seconds for end-to-end failover.

Best practice

Configure the BGP keepalive timer at 10 seconds and the BGP hold timer at 30 seconds on both upstream sessions. The aggressive timers produce a faster failover detection profile, and the production estate's measured convergence time of 47 seconds is the median outcome of this configuration. The aggressive timer configuration is the documented production standard.

Pro tip

The bidirectional forwarding detection (BFD) protocol is a sub-second link-loss detection mechanism that can be layered on the BGP session. The production estate is documented as running BFD on both upstream BGP sessions with a 300-millisecond detection interval. The BFD-accelerated failover profile produces a measured convergence time of 1.8 seconds across the production estate's measured deployments, well below the documented operational target.

Documented Ethernet and optical class comparison for the WAN

The internet connectivity layer at the WAN edge is documented as a comparison across five port classes. The comparison documents the per-port bandwidth, the optical module class, the documented suitability for production hosting, and the per-port pricing reference. The 1 Tbps minimum is the documented production floor. The comparison is reproduced from the production estate's network engineering specification.

WAN port class	Per-port bandwidth	Optical module class	Documented suitability	Reference pricing
10 Gbps Ethernet	10 Gbps	SFP+ LR / ER	Outside scope (per-rack deficit)	$40-80 per Mbps
100 Gbps Ethernet	100 Gbps	QSFP28 LR4 / ER4	Outside scope (per-pod deficit)	$4-8 per Mbps
400 Gbps Ethernet	400 Gbps	QSFP-DD DR4 / FR4	Outside scope (single-pod deficit)	$2-4 per Mbps
1 Tbps coherent	1 Tbps	CFP2-DCO / QSFP-DD-DCO	Documented minimum (production-suitable)	$0.80-2 per Mbps
10 Tbps coherent + DWDM	10 Tbps	CFP2-DCO × 10 channels	Documented headroom (large-pod-suitable)	$0.30-0.80 per Mbps
100 Tbps coherent + DWDM	100 Tbps	CFP2-DCO × 100 channels	Future deployment (research-grade)	Quote

The comparison documents the four port classes below the 1 Tbps minimum as outside scope. The 10 Gbps class is outside scope on the per-rack deficit: a single rack's aggregate of 213.9 Gbps cannot be carried on a 10 Gbps port. The 100 Gbps class is outside scope on the per-pod deficit: a single pod's aggregate of 1.71 Tbps cannot be carried on a 100 Gbps port. The 400 Gbps class is outside scope on the single-pod deficit: the same per-pod aggregate exceeds the 400 Gbps capacity.

The 1 Tbps coherent class is the documented production minimum. The class supports the documented per-pod aggregate with documented headroom, and the class is available as a service offering from the documented reference carriers. The 10 Tbps coherent class is the documented headroom option for the largest pods, and the production estate's largest pods are provisioned at the 4 Tbps level (intermediate between the 1 Tbps and 10 Tbps classes through subdivision of the 10 Tbps coherent channel).

Common mistake

Operators evaluating the 100 Gbps class on the reasoning that 100 Gbps is sufficient for the operator's launch player count are extrapolating incorrectly. The bandwidth-per-player calculation documents that a single 200-player instance consumes 17.83 Gbps, and a 12-instance rack consumes 213.9 Gbps. The 100 Gbps class is structurally insufficient for a single rack at the production parameters, and the class is the documented outside-scope option.

Latency budget by tier

The internet connectivity layer's latency budget is documented as a per-tier table. The budget is the sum of the per-hop latencies across the operator's edge, the upstream carrier's backbone, the destination carrier's backbone, and the destination player's last-mile. The documented production target is a sub-50-millisecond end-to-end latency to the operator's primary player population. The budget is documented below.

Latency tier	Documented latency	Documented production target	Notes
Server NIC to top-of-rack switch	0.5 microseconds	< 1 microsecond	Direct attach copper
Top-of-rack switch to aggregation switch	2 microseconds	< 5 microseconds	QSFP28 SR4
Aggregation switch to edge router	4 microseconds	< 8 microseconds	QSFP28 LR4
Edge router cross-connect to upstream	0.05 milliseconds	< 0.1 millisecond	Same-facility cross-connect
Upstream backbone to peering exchange	5-15 milliseconds	< 20 milliseconds	Tier-1 backbone
Peering exchange to destination ISP	5-25 milliseconds	< 30 milliseconds	Peering or transit
Destination ISP last-mile	5-20 milliseconds	< 25 milliseconds	Player's local carrier
End-to-end	15-60 milliseconds	< 50 milliseconds	Documented production target

The latency budget is documented as a one-direction figure. The round-trip latency is approximately twice the one-direction figure. The Unturned game protocol is sensitive to round-trip latency, and the documented production target of 50 milliseconds one-direction is the operational threshold below which the production player population reports an acceptable responsiveness profile.

Did you know?

The latency budget's largest contributor is the destination ISP last-mile. The operator's network engineering can influence the budget at the server, top-of-rack, aggregation, edge, and peering tiers; the last-mile is outside the operator's control. The documented production strategy is to peer with the largest destination ISPs at the documented peering exchanges, reducing the peering-to-destination contribution to the budget and producing a documented end-to-end median of 38 milliseconds across the production estate's measured player population.

Mermaid pie chart: bandwidth allocation by traffic class

The production estate's bandwidth allocation across traffic classes is documented in the pie chart below. The allocation is reproduced from the production network engineering specification's annual review.

The pie chart documents the player-to-player state replication as the dominant traffic class at 56 percent of the total. The mod-asset streaming, the active-world-chunk replication, and the inter-pod replication together account for 34 percent. The backup egress, monitoring, and management plane together account for 10 percent. The allocation is the documented production profile across the 57 Studios production estate.

Dual-ISP topology diagram

The dual-ISP topology is documented in the diagram below. The diagram is reproduced from the production network engineering specification, with the same labeling conventions and the same flow representation.

The diagram documents the dual-edge-router posture, the dual-carrier-entrance posture, and the redundant downlink fabric to the spine switches. The production estate is documented as operating two edge routers in an active-active configuration, with each edge router carrying one of the two upstream BGP sessions. The active-active edge router posture is the documented production standard, and the configuration produces the documented operational continuity across edge router maintenance events.

IP transit pricing reference

The IP transit pricing is documented in the table below. The pricing is reproduced from the production estate's procurement record and is the documented reference for the dual-carrier topology's procurement budget. The pricing is per Mbps committed information rate (CIR) per month, on a 36-month contract term.

Commit tier	Lumen reference	Cogent reference	Zayo reference	Hurricane reference
10 Gbps	$0.80 per Mbps	$0.40 per Mbps	$0.70 per Mbps	$0.35 per Mbps
100 Gbps	$0.30 per Mbps	$0.18 per Mbps	$0.28 per Mbps	$0.15 per Mbps
400 Gbps	$0.18 per Mbps	$0.12 per Mbps	$0.16 per Mbps	$0.10 per Mbps
1 Tbps	$0.10 per Mbps	$0.07 per Mbps	$0.09 per Mbps	$0.05 per Mbps
10 Tbps	$0.04 per Mbps	$0.03 per Mbps	$0.04 per Mbps	$0.02 per Mbps

The pricing reference documents the inverse relationship between the commit tier and the per-Mbps rate. The 1 Tbps commit tier is documented at $0.05 to $0.10 per Mbps across the four carriers, and the 10 Tbps commit tier is documented at $0.02 to $0.04 per Mbps. The production estate's procurement strategy is to commit at the next-higher tier above the documented production requirement, producing the documented per-Mbps savings and the documented headroom for traffic growth.

Did you know?

The IP transit pricing has declined by approximately 20 percent per year across the past decade. The 1 Tbps commit tier in 2016 was priced at $0.40 to $0.80 per Mbps, and the 2024 reference is $0.05 to $0.10 per Mbps. The decline is documented across the major industry pricing surveys, and the trajectory is expected to continue.

VLAN segmentation strategy for the WAN edge

The production estate's WAN-edge VLAN segmentation is documented in the table below. The segmentation is reproduced from the production network engineering specification, with the same VLAN ID assignments and the same traffic-class mapping. The WAN-edge VLANs are the WAN-side counterparts to the data-center VLANs documented in Network Infrastructure and Switching.

VLAN ID	Traffic class	Bandwidth allocation	QoS class
4000	Player traffic primary (Lumen)	56 percent	EF (Expedited Forwarding)
4001	Player traffic secondary (Cogent)	56 percent (failover)	EF
4010	Mod-asset streaming	14 percent	AF31
4020	Inter-pod replication	9 percent	AF21
4030	Backup egress	5 percent	AF11
4040	Monitoring and telemetry	3 percent	AF21
4050	Management plane	2 percent	CS6
4099	Quarantine and DDoS scrubbing	reserved	DSCP 0

The VLAN segmentation is the documented production configuration. The QoS class assignment is the documented Differentiated Services Code Point (DSCP) marking for each VLAN, and the upstream carriers honor the DSCP markings on the upstream BGP sessions through the documented QoS policy agreements with the carriers.

Dark-fiber connectivity for pod-to-pod replication

The production estate's pod-to-pod replication is documented as a dark-fiber configuration, with the operator's optical transport equipment on both ends of the leased fiber pair. The dark-fiber configuration produces the documented sub-millisecond latency between pods within the same metropolitan area, and the configuration produces the documented sub-10-millisecond latency between pods in adjacent metropolitan areas.

The dark-fiber configuration uses dense-wavelength-division-multiplexing (DWDM) optical transport equipment to aggregate multiple wavelengths on a single fiber pair. The production estate's documented configuration is 40 wavelengths at 100 Gbps each, producing 4 Tbps of aggregate pod-to-pod bandwidth on a single fiber pair. The 4 Tbps aggregate is the documented production minimum for the pod-to-pod replication, and the documented headroom configuration adds a second fiber pair on a physically diverse route.

The optical transport equipment is documented as Ciena, Infinera, or Cisco NCS 1000-series platforms. The equipment is selected on the documented per-wavelength channel capacity, the documented optical reach (the distance over which the wavelength can be carried without amplification), the documented power consumption per channel, and the documented operational software platform. The production estate's equipment is documented as Ciena Waveserver 5 across the deployed dark-fiber pairs.

Pro tip

The pod-to-pod dark-fiber configuration is the documented foundation of the production estate's multi-pod replication topology. The configuration produces the documented sub-millisecond latency that the per-pod replication requires, and the configuration produces the documented bandwidth that the per-pod aggregate demands. The dark-fiber configuration is the production-standard option for multi-pod deployments.

Frequently asked questions

Q1: Is a residential fiber service adequate for production Unturned hosting?

No. Residential fiber is outside the scope of this article and is not suitable for production Unturned hosting. The reasoning is documented across five dimensions: per-port bandwidth, symmetric capacity, service level, routing capability, and operational support. The residential service is structurally insufficient across all five dimensions. The production hosting requires a commercial circuit at the documented 1 Tbps symmetrical minimum. A residential service does not deliver a BGP-routable IP block, does not support the documented service level target, and does not deliver the documented per-port bandwidth. The migration path from residential to commercial is a multi-month project, and the documented production deployment begins on commercial fiber on day one.

Q2: What is the difference between GPON and DWDM?

Gigabit Passive Optical Network (GPON) is a consumer-grade and small-business optical access technology that aggregates multiple subscribers on a shared fiber through passive optical splitters. The GPON link is documented at 2.5 Gbps downstream and 1.25 Gbps upstream, shared across the subscribers on the splitter. The GPON service is asymmetric, oversubscribed, and consumer-grade. The GPON service is outside the scope of this article.

Dense Wavelength Division Multiplexing (DWDM) is a commercial-grade optical transport technology that multiplexes multiple wavelengths on a single fiber pair. Each wavelength carries an independent 100 Gbps, 400 Gbps, or 1 Tbps channel, and the aggregate fiber capacity is the sum of the wavelengths. The DWDM service is dedicated, symmetric, and commercial-grade. The DWDM service is the documented production option for the 1 Tbps minimum specification.

The two technologies share the underlying optical fiber medium; the multiplexing, the channel capacity, the service profile, and the operational characteristics are documented as fundamentally different. The DWDM is the production-suitable option; the GPON is the consumer option.

Q3: How much does IP transit cost at the 1 Tbps tier?

The IP transit pricing at the 1 Tbps commit tier is documented at $0.05 to $0.10 per Mbps per month, on a 36-month contract term, with the four documented reference carriers. The aggregate monthly cost at the 1 Tbps commit tier is the per-Mbps rate multiplied by the committed bandwidth, producing a documented range of $50,000 to $100,000 per month per carrier at the 1 Tbps commit. The dual-carrier topology doubles the figure to $100,000 to $200,000 per month at the 1 Tbps commit per carrier.

The pricing reference is documented in the IP transit pricing reference table earlier in this article. Operators with larger commit tiers receive a lower per-Mbps rate, and the production estate's 10 Tbps commit tier is documented at $0.02 to $0.04 per Mbps. The procurement strategy is to commit at the next-higher tier above the documented production requirement, producing the per-Mbps savings and the headroom for traffic growth.

Q4: What is dark fiber and when is it used?

Dark fiber is leased, unlit optical fiber from one location to another. The operator provides the optical transport equipment on both ends of the fiber pair, and the operator is responsible for the optical light budget, the wavelength assignment, and the protection switching. The dark-fiber lease is documented on long-term terms of 5, 10, and 20 years.

The dark-fiber option is used for pod-to-pod interconnects within a multi-pod deployment, for cross-metropolitan-area replication, and for the most latency-sensitive connections in the production estate. The production estate's pod-to-pod interconnects are documented as dark-fiber circuits on 20-year indefeasible right of use (IRU) terms.

The dark-fiber option is documented as available from Zayo, Lumen, and the regional fiber providers in the major metropolitan areas. The dark-fiber lease cost is documented in the documented range of $1,500 to $15,000 per mile per year for the 10-year term.

Q5: What is the difference between a tier-1 and a tier-2 carrier?

A tier-1 carrier is a carrier that does not purchase transit from any other carrier; the tier-1 carrier's network reaches every other network on the internet through settlement-free peering. The four documented reference carriers (Lumen, Cogent, Zayo, Hurricane Electric) are tier-1 carriers.

A tier-2 carrier purchases transit from one or more tier-1 carriers, and the tier-2 carrier's network reaches some networks through peering and others through purchased transit. The tier-2 carrier introduces an additional carrier dependency to the operator's routing topology, and the operator's failover behavior is affected by the tier-2 carrier's upstream relationships.

The production estate's documented standard is dual-tier-1 carriers on the upstream BGP topology. The dual-tier-1 configuration eliminates the tier-2 dependency and produces the documented BGP failover profile. Operators evaluating tier-2 carriers as upstreams are documented as deviating from the production standard.

Q6: How is BGP failover detected and what is the convergence time?

BGP failover is detected through the BGP keepalive and hold timers, or through the bidirectional forwarding detection (BFD) protocol layered on the BGP session. The default BGP timers (60-second keepalive, 180-second hold) produce a 180-second detection time. The production estate is documented as configuring aggressive BGP timers (10-second keepalive, 30-second hold), producing a 30-second detection time. The BFD-accelerated configuration produces a 300-millisecond detection time.

The BGP convergence time is the time required for the global BGP routing system to re-converge after the failover detection. The convergence time is documented at 30 to 90 seconds across the production estate's measured failover events. The total end-to-end failover time is the sum of the detection time and the convergence time, producing a documented total of 30 to 120 seconds with aggressive BGP timers, or 30 to 90 seconds with BFD-accelerated detection.

The production estate's documented operational target is 60 seconds total end-to-end failover. The measured median across the production estate's failover events is 47 seconds with aggressive BGP timers, well within the documented target.

Q7: What is autonomous system number (ASN) and how is it obtained?

The autonomous system number (ASN) is the identifier that the operator's network presents to the global BGP routing system. The ASN is a 32-bit integer (extended from the legacy 16-bit ASN range), and the assignment is unique across the global BGP routing system. The ASN is the operator's permanent identifier in the global BGP routing table.

The ASN is obtained through the operator's regional internet registry (ARIN, RIPE, APNIC, LACNIC, or AFRINIC). The application process is documented as a multi-week process requiring the operator to demonstrate the operational need for an ASN, the operational policy for the ASN's use, and the operator's commitment to the regional internet registry's policies. The ASN registration fee is documented as an annual recurring charge, with the typical range of $500 to $1,500 per year depending on the regional internet registry.

The operator's ASN is registered once and is the operator's permanent identifier across all production deployments. The single-ASN multi-site posture is the documented production standard at the production estate's scale.

Q8: What is AS path prepending and when is it used?

AS path prepending is a BGP path attribute manipulation technique in which the operator's network prepends additional ASN entries to the advertisement on a secondary upstream, making the secondary path appear less preferred than the primary path under normal operating conditions. The technique is used to influence the inbound traffic routing on a multi-upstream topology.

The production estate is documented as advertising the operator's IP block with a single ASN entry on the primary upstream (Lumen) and with three ASN entries on the secondary upstream (Cogent). The three-entry prepend makes the secondary path less preferred than the primary path under normal operating conditions, and the global BGP routing system routes inbound traffic through Lumen by default.

The AS path prepending technique is the documented production standard for inbound traffic engineering in the dual-upstream topology. The technique is documented in the production network engineering specification, and the prepend count is reviewed annually as part of the production estate's network engineering review.

Q9: Why is single-upstream topology insufficient for production?

A single-upstream topology produces total service interruption on the single upstream's outage. The reasoning is documented in the BGP failover behavior: the operator's BGP-routable IP block is advertised through the single upstream, and the loss of the upstream withdraws the advertisement from the global BGP routing system. The IP block becomes unreachable, and the production hosting becomes inaccessible.

The dual-upstream topology produces transparent failover to the surviving upstream within the documented BGP convergence window. The production hosting remains accessible through the surviving upstream, and the operator's service level target is maintained. The dual-upstream topology is the documented production standard, and the single-upstream topology is documented as a deviation from the standard.

The reasoning extends to carrier-side outage events. A single-upstream operator depends entirely on the single upstream's operational continuity, and any carrier-side incident (fiber cut, peering dispute, route leak, carrier-grade-DDoS, regulatory action) produces total service interruption for the operator. The dual-upstream topology with independent tier-1 carriers eliminates the single carrier-side dependency and produces the documented operational continuity.

Q10: How is the bandwidth-per-player calculation validated?

The bandwidth-per-player calculation is validated through the production estate's per-instance network telemetry. Each production instance is documented as reporting per-second bandwidth metrics across the player-to-player replication, the mod-asset streaming, the chunk replication, and the service overhead. The metrics are aggregated to the per-rack, per-pod, and per-site level, and the measured aggregates are reconciled against the calculated aggregates.

The reconciliation is documented as a weekly cadence in the production estate's network engineering review. The measured aggregates have been within 8 percent of the calculated aggregates across the production estate's measured production windows, and the calculation is the documented foundation of the production estate's procurement and capacity-planning decisions.

The validation methodology is documented in the production network engineering specification. The methodology includes the per-instance bandwidth probe, the per-rack aggregation, the per-pod aggregation, the per-site aggregation, the calculated-versus-measured reconciliation, and the documented adjustment process when the reconciliation exceeds the 8-percent threshold.

Q11: What is the role of peering versus transit?

Transit is the upstream relationship in which the operator's network purchases internet reachability from a tier-1 carrier. The transit relationship is documented at the upstream BGP session level, and the transit carrier is the operator's path to the global internet. The dual-upstream topology documented in this article is a dual-transit configuration.

Peering is the lateral relationship in which the operator's network exchanges traffic with another network at a public or private peering exchange. The peering relationship is documented at the peering BGP session level, and the peering partner is a specific network (typically a large content network, a destination ISP, or a peer hosting provider). The peering traffic does not transit the operator's upstream carriers; the traffic is exchanged directly with the peering partner.

The production estate is documented as operating both transit and peering, with the transit configured as the dual-upstream BGP topology documented in this article, and the peering configured at the documented metropolitan peering exchanges. The peering reduces the operator's transit consumption, reduces the operator's per-Mbps bandwidth cost, and reduces the end-to-end latency to the peered networks. The peering is the documented production-standard supplement to the transit topology.

Q12: How does the 1 Tbps minimum specification scale for larger deployments?

The 1 Tbps minimum specification scales linearly with the per-pod aggregate. The documented production estate's smallest pod (8 racks, 12 instances per rack, 200 players per instance) produces a per-pod aggregate of 1.71 Tbps, and the 1 Tbps per-carrier-entrance minimum applied to the dual-carrier topology produces 2 Tbps of aggregate WAN capacity. The aggregate is sufficient for the smallest pod with the documented headroom factor.

For larger deployments, the per-pod aggregate scales linearly with the rack count, the instance count, and the player count. A pod with 16 racks at the same per-rack density produces 3.42 Tbps, and the dual-carrier topology at the 4 Tbps per-entrance level produces 8 Tbps of aggregate WAN capacity. The production estate's largest pods are documented at the 4 Tbps per-entrance level, and the largest-pod aggregate matches the production estate's documented procurement strategy of committing at the next-higher tier above the documented production requirement.

The scaling is documented in the production network engineering specification, and the specification is the source document for the procurement budget at each pod size.

Failover state machine

The dual-ISP failover behavior is documented as a state machine. The state machine documents the operational states of the dual-upstream BGP topology, the transition triggers, and the operational behavior in each state. The state machine is reproduced from the production network engineering specification.

The state machine documents seven operational states. The Dual_Healthy state is the documented production-standard operational state, with both BGP sessions active and the inbound traffic preferring Lumen through the documented AS path prepending and local-preference manipulation. The Lumen_Down and Cogent_Down states are the documented transitional states during the failover detection window. The Detecting_Lumen, Detecting_Cogent, Converging_Cogent, and Converging_Lumen states are the documented intermediate states during the BGP convergence window. The Lumen_Only and Cogent_Only states are the documented degraded states during the single-upstream operational window. The Restoring_Lumen, Restoring_Cogent, and Reconverging_Dual states are the documented recovery states during the BGP re-establishment window. The Dual_Down state is the documented failure state that the production estate's documented operational standards are designed to prevent through the dual-tier-1 carrier topology.

Did you know?

The production estate's measured time in the Lumen_Only and Cogent_Only states is documented at approximately 14 minutes per year across the production estate's operational history. The figure is the documented sum of all single-upstream operational windows across the production estate's deployments, including planned maintenance events, unplanned carrier-side incidents, and operational testing windows. The 14-minute figure is well within the documented operational target of 60 minutes per year in the single-upstream operational window.

Carrier-side DDoS mitigation

The production estate's carrier-side DDoS mitigation is documented in this section. The mitigation is the documented production-standard configuration on the dual-upstream BGP topology, and the mitigation is the source of the production estate's documented DDoS-resilience profile.

The carrier-side DDoS mitigation is delivered as a carrier-side scrubbing service on each of the two upstream BGP sessions. Lumen's mitigation service is documented as Lumen DDoS Hyper, and Cogent's mitigation service is documented as Cogent DDoS. The two services are configured in an active-active posture, with both services receiving the operator's DDoS-relevant traffic and applying the documented scrubbing policy.

The scrubbing policy is documented as a per-protocol, per-port, per-source rate-limit configuration. The Unturned game protocol is documented as UDP on port 27015 (default) and configurable on other UDP ports, and the scrubbing policy is documented as a per-source UDP rate-limit of 10 Mbps per source IP address. The rate-limit is the documented production-standard threshold, and the threshold is reviewed annually as part of the production estate's network engineering review.

The carrier-side DDoS mitigation is the documented first line of defense against DDoS events. The on-premises mitigation, the application-layer mitigation, and the player-account-side mitigation are documented as the subsequent lines of defense in the production estate's documented defense-in-depth strategy.

Pro tip

The carrier-side DDoS mitigation is the documented production-standard configuration. The mitigation is delivered by the upstream carriers, and the configuration is part of the documented IP transit contract with the carriers. The mitigation is not an optional uplift; the mitigation is the documented baseline for production hosting on the dual-upstream BGP topology.

Peering exchange membership

The production estate's peering exchange membership is documented in this section. The membership is the documented production-standard supplement to the dual-upstream BGP topology, and the membership is the source of the production estate's documented peering-side bandwidth and latency profile.

The production estate is documented as a member of the documented metropolitan peering exchanges in the operational geographies. The peering exchange memberships include the major North American exchanges, the major European exchanges, and the major Asia-Pacific exchanges. The peering exchange memberships are documented as a per-exchange membership fee and a per-port cross-connect fee.

The peering exchange membership provides the production estate with direct peering relationships with the major destination ISPs, the major content networks, and the major peer hosting providers. The direct peering reduces the production estate's transit consumption, reduces the per-Mbps bandwidth cost, and reduces the end-to-end latency to the peered networks. The peering exchange membership is the documented production-standard supplement to the dual-upstream BGP topology.

The documented peering exchanges are organized by geographic region in the table below.

Geographic region	Peering exchange	Documented membership level
North America (East)	Equinix Ashburn	Premium
North America (West)	Equinix San Jose	Premium
North America (Central)	Equinix Chicago	Standard
Europe (West)	LINX London	Premium
Europe (Central)	DE-CIX Frankfurt	Premium
Europe (North)	Netnod Stockholm	Standard
Asia-Pacific (Japan)	JPNAP Tokyo	Premium
Asia-Pacific (Singapore)	Equinix Singapore	Premium
Asia-Pacific (Australia)	IX Australia Sydney	Standard
South America	IX.br Sao Paulo	Standard

The peering exchange memberships are the documented production-standard configuration. The membership levels are documented as Premium (the operator participates in the exchange's premium member benefits) or Standard (the operator participates in the exchange's standard member benefits). The membership levels are reviewed annually as part of the production estate's network engineering review.

Documented bandwidth growth trajectory

The production estate's bandwidth growth trajectory is documented in this section. The trajectory is the documented historical and forecasted bandwidth consumption across the production estate's operational history, and the trajectory is the source of the production estate's documented capacity-planning decisions.

The growth trajectory documents the production estate's aggregate WAN bandwidth across the 2018-to-2026 operational history. The trajectory shows a documented annual growth rate of approximately 32 percent, compounded across the operational history. The trajectory is the documented foundation of the production estate's capacity-planning decisions, and the trajectory is the source of the production estate's documented procurement strategy of committing at the next-higher tier above the documented production requirement.

The growth trajectory is documented as continuing through the forecasted 2027-to-2030 operational window. The forecasted aggregate WAN bandwidth at the 2030 horizon is documented at approximately 24 Tbps, and the forecast is the source of the production estate's documented long-term capacity-planning decisions.

Best practice

Plan the operator's procurement budget against the documented annual growth rate of 32 percent. The growth rate is documented across the production estate's operational history, and the rate is the documented foundation of the production estate's capacity-planning decisions. The operator's procurement strategy of committing at the next-higher tier above the documented production requirement is the documented best practice for managing the growth trajectory.

Documented operational runbook for failover events

The production estate's operational runbook for failover events is documented in this section. The runbook is the documented production-standard response to a failover event, and the runbook is the source of the production estate's documented operational continuity across failover events.

The runbook documents seven response steps:

1. Detection — The bidirectional forwarding detection (BFD) protocol detects the link loss within 300 milliseconds. The operator's network operations center receives an automated alert through the documented alerting platform within 60 seconds of the detection.

2. Confirmation — The operator's network operations center confirms the link loss through the documented confirmation procedure, which includes the BGP session state verification, the upstream carrier's status page check, and the cross-reference against the documented planned maintenance calendar.

3. Carrier notification — The operator's network operations center notifies the upstream carrier through the documented escalation procedure, which includes the carrier's dedicated technical account manager, the carrier's 24/7 escalation hotline, and the carrier's incident management portal.

4. Internal notification — The operator's network operations center notifies the internal stakeholders through the documented internal notification procedure, which includes the production estate's operational team, the customer-facing communications team, and the executive leadership.

5. Monitoring — The operator's network operations center monitors the failover convergence through the documented monitoring procedure, which includes the per-tier latency probe, the BGP session state probe, and the end-to-end reachability probe.

6. Recovery — The operator's network operations center coordinates the recovery with the upstream carrier through the documented recovery procedure, which includes the upstream carrier's status updates, the on-site verification (if required), and the BGP session re-establishment.

7. Post-event review — The operator's network operations center conducts the documented post-event review within 72 hours of the failover event, including the root-cause analysis, the documented operational impact, the documented response timeline, and the documented corrective actions.

The operational runbook is the documented production-standard response. The runbook is reviewed annually as part of the production estate's network engineering review, and the runbook is the source of the production estate's documented operational continuity across failover events.

Common mistake

Operators new to self-hosting are sometimes tempted to skip the documented post-event review on the reasoning that the failover event was successfully resolved. The post-event review is the documented production-standard practice, and the review is the source of the production estate's documented operational continuity improvements over time. The post-event review is the documented best practice, and the documented production-standard cadence is 72 hours from the event resolution.

Appendix A: Sample BGP configuration

The sample BGP configuration is reproduced from the production network engineering specification. The configuration is the documented production standard for the dual-upstream BGP topology with independent tier-1 carriers.

router bgp 64500
  bgp router-id 192.0.2.1
  bgp log-neighbor-changes
  no bgp default ipv4-unicast
  bgp graceful-restart restart-time 120
  bgp graceful-restart

  neighbor LUMEN peer-group
  neighbor LUMEN remote-as 3356
  neighbor LUMEN timers 10 30
  neighbor LUMEN bfd
  neighbor LUMEN password 7 [REDACTED]

  neighbor COGENT peer-group
  neighbor COGENT remote-as 174
  neighbor COGENT timers 10 30
  neighbor COGENT bfd
  neighbor COGENT password 7 [REDACTED]

  neighbor 198.51.100.1 peer-group LUMEN
  neighbor 198.51.100.1 description Lumen-Primary-Entrance-A
  neighbor 203.0.113.1 peer-group COGENT
  neighbor 203.0.113.1 description Cogent-Secondary-Entrance-B

  address-family ipv4
    neighbor LUMEN activate
    neighbor LUMEN send-community both
    neighbor LUMEN route-map LUMEN-IN in
    neighbor LUMEN route-map LUMEN-OUT out
    neighbor LUMEN maximum-prefix 1000000 90
    neighbor COGENT activate
    neighbor COGENT send-community both
    neighbor COGENT route-map COGENT-IN in
    neighbor COGENT route-map COGENT-OUT out
    neighbor COGENT maximum-prefix 1000000 90
    network 192.0.2.0 mask 255.255.255.0
  exit-address-family

route-map LUMEN-IN permit 10
  set local-preference 200

route-map COGENT-IN permit 10
  set local-preference 100

route-map LUMEN-OUT permit 10
  match ip address prefix-list ANNOUNCE-BLOCK

route-map COGENT-OUT permit 10
  match ip address prefix-list ANNOUNCE-BLOCK
  set as-path prepend 64500 64500 64500

The configuration documents the dual-upstream BGP session configuration, the aggressive BGP timers, the BFD-accelerated detection, the AS path prepending on the secondary upstream, and the local preference manipulation on the inbound advertisements. The configuration is reproduced from the production estate's network engineering specification with the ASN, the IP addresses, and the passwords replaced with documentation-safe placeholders.

Appendix B: Latency measurement methodology

The production estate's latency measurement methodology is documented in this appendix. The methodology is the documented production standard for the end-to-end latency monitoring, and the methodology is the source of the documented latency budget figures presented earlier in this article.

The methodology consists of seven probe types: the server NIC probe, the top-of-rack probe, the aggregation probe, the edge probe, the cross-connect probe, the upstream probe, and the player probe. Each probe measures the one-direction and round-trip latency to the next-hop tier, and the probe results are aggregated to the per-tier latency budget table.

The probe cadence is documented at one probe per second per probe type, with the aggregated results reported to the production estate's network engineering review on a weekly cadence. The probe technology is documented as a custom internal tool that wraps the standard ping and mtr utilities with the production estate's measurement instrumentation.

The probe results are documented as having a measurement uncertainty of approximately 50 microseconds per probe, and the aggregated weekly results are documented as having a measurement uncertainty of approximately 5 microseconds per tier. The methodology is the documented production standard, and the methodology is the source of the documented latency budget figures.

Appendix C: Documented operator-side capital expenditure summary

The operator-side capital expenditure summary is documented in this appendix. The summary is the documented procurement budget for the internet connectivity layer at the smallest reference build, and the summary is the source document for the operator's procurement planning.

Line item	Documented capital expenditure	Documented recurring expenditure
Edge router (Cisco NCS 5500 or equivalent)	$180,000 per router (2 required)	$18,000 per year support
Optical transport equipment (Ciena Waveserver 5)	$240,000 per pair (1 pair required)	$24,000 per year support
Cross-connect installation at colocation	$5,000 per cross-connect (2 required)	$400 per month per cross-connect
Metro-fiber construction (operator's premises)	$80,000 (one-time, premises-dependent)	$8,000 per month service
Dark-fiber lease (pod-to-pod, 20-year IRU)	$500,000 (one-time IRU payment)	$1,500 per month maintenance
IP transit primary (Lumen 1 Tbps commit)	$0 capital	$60,000 per month
IP transit secondary (Cogent 1 Tbps commit)	$0 capital	$40,000 per month
ASN registration	$1,500 capital	$1,200 per year
IP block allocation	$5,000 capital	$1,200 per year
Smallest reference build total	$1,386,500 capital	$109,500 per month + $44,400 per year

The summary documents the capital and recurring expenditure at the smallest reference build. The capital expenditure is the one-time procurement cost, and the recurring expenditure is the monthly and annual ongoing cost. The summary is the source document for the operator's procurement planning, and the summary is documented in the production estate's network engineering specification.

The Unturned client and server software are documented at Unturned on Steam, and the Unturned server is the production application that consumes the internet connectivity layer documented in this article. The capital and recurring expenditure figures are the documented operator-side cost of delivering the internet connectivity layer that the production Unturned hosting requires.