Traffic geography
Where users, offices, data sources and dependent APIs are located.
Network
Bandwidth is a requirement to define, not a badge to display.
For dedicated and GPU servers, network design should reflect real traffic direction, user geography, transfer volume, public IP requirements and latency-sensitive dependencies.
Quick answer
Specify local versus international traffic, expected sustained and peak transfer, inbound/outbound pattern, public IPv4 needs, required ports and important remote regions. Then test representative paths rather than relying on a single nominal port-speed number.
Network brief
What a useful network requirement includes
Traffic pattern
Inbound/outbound balance, sustained transfer, bursts and whether large datasets move regularly.
Addressing
Number of public IPs, reverse DNS, allowlisting and any routed-subnet or network-segmentation need.
Latency targets
Identify the routes where latency matters and how you will measure acceptance.
Diagnostics
Publish test endpoints only when designated for public use
The package leaves test IP / looking-glass values unconfigured. Populate them only after SERVER1 designates safe public diagnostic resources.
Looking Glass
Expose safe diagnostics and protect them with sensible limits.
MTR / traceroute
Use route tools as evidence, but remember some transit hops deprioritise probe traffic.
Application test
The strongest acceptance test is often the real application flow from representative client networks.
FAQ
Questions to settle before deployment or onsite work
Internet paths can change and depend on multiple networks. For a business-critical target, define measurement points and a contractual requirement rather than relying on a generic marketing statement.
IP allocation is service- and availability-dependent. State the number and use case in the request so current options can be confirmed.
Technical request
Describe the hardware or onsite task
For faster scoping, include the equipment, location, requested action, maintenance window, urgency and any stop conditions.
Turn the requirement into an executable scope.
Send the hardware, workload or onsite task. We will separate assumptions from confirmed availability before anything is deployed or touched.