Our Network

Valve operates the network AS32590, which hosts our Steam gaming platform. Our network consists of globally-distributed game servers and content download servers. We operate several dozen points-of-presence (“PoPs”) around the world, and we are present many internet exchanges (IXPs) and private interconnection facilities, all of which are listed on our PeeringDB page.

AS32590 delivers two main types of traffic: high-volume CDN traffic (“content”), namely video game downloads, and relatively lower-volume but latency-sensitive “interactive” traffic, including gameplay data, user sessions, etc. As a rough guideline, over 95% of our delivered traffic is “content”, while less than 5% is “interactive”. Similarly, our traffic balance is roughly 95% outbound from AS32590, 5% inbound to AS32590.

Independent PoPs

Each Valve PoP has its own set of servers. A given PoP may host content servers, game servers, or both.

Each Valve PoP only advertises IP prefixes unique to that location. The IP prefixes advertised to peers (of any kind) from a given PoP are completely local to that PoP. We do not use BGP Anycast. We provide an RFC 8805 Geofeed CSV, mapping our advertised IP prefixes to our geographic PoPs. Steam clients will probe real-time conditions to find the best entry point into our network.

Each Valve PoP routes traffic independently. Prefixes learned from peers in a given PoP stay local to that PoP, and do not influence traffic sourced from servers in other PoPs.

Users are directed to the best Valve PoP. Requests from users for AS32590 are directed to a particular geographic PoP by a variety of techniques, depending on the location of the user, the type of traffic being requested, the client application making the request, and the capacity of each PoP at that moment. By default, clients attempt to direct requests to the most-appropriate PoP, to minimize latency and to maximize performance for the user, as capacity allows.

If you believe there is an issue or inaccuracy with the mapping of user requests to specific Valve PoPs, you can contact us at peering@valvesoftware.com. Include the source IP prefix of the user(s), their geographic information, and your AS information to investigate.

Peering Policy

Valve maintains an Open peering policy.

All of our peering information is available at our PeeringDB page.

To peer with Valve, you must meet these requirements:

IXP Peering

We are present at many Internet Exchanges and peer with the route servers at all IXPs we are present at. We are always keen to support more IXPs, especially not-for-profit IXPs. If there is an IXP that is reachable from one of our locations and we’re not there, get in touch with us at peering@valvesoftware.com. We are also happy to support people setting up new peering ecosystems, especially in under-served markets.

If you are peered with the route servers at a shared IXP, then you should receive all of our local routes (and vice versa), and likely do not need to peer with us directly. In most cases, peering with the IXP route servers is all you need to do. If necessary, we support bi-lateral peering sessions at IXP locations with networks that we exchange a reasonable amount of traffic with (>100Mb/s), depending on the IXP location. We advertise the same prefixes to all peers, whether via bi-lateral peering or via route server, so bi-lateral sessions will not change your latency to us.

If you meet these requirements, and wish to peer with Valve, configure sessions on your routers using our PeeringDB information. Then email us at peering@valvesoftware.com. Tell us your ASN, and the location(s) where you would like to peer. At many locations, we have two or more connections to an IXP. Please peer with all of our connections to that IXP.

PNI Peering

We support settlement-free peering via private network interconnects (PNIs) at the locations listed in our PeeringDB page, or reachable by a standard cross-connect (XC) from one of those locations.

PNIs are available for peers with whom we exchange at least 10Gb/s of traffic. Networks with lower amounts of traffic should join the same IXPs as us.

We only support 100G and 400G ports for PNIs; no new 10G PNIs will be provisioned. We prefer 100G-LR1 optics for 100G connections. This is much more efficient on modern high capacity routers. We can support 100G-LR4 optics in some but not all locations. We support 400G-LR4 for 400G connections.

We typically request an additional (or larger) PNI when traffic levels reach 50% utilization. We split costs by taking turns on which side orders each cross-connect and provides IPs, and which side provides the LOA.

If you meet these requirements, and wish to set up a PNI, email us at peering@valvesoftware.com.

Peering Technical Details

There is no service level agreement (SLA) for our peering connections, nor any guarantee that traffic will be always exchanged via a peering connection. We may perform network maintenances without notification.

We configure all new PNIs as LAGs using LACP, even single connections, to allow for easy expansion and troubleshooting. If we have two individual connections at a location, each will be configured as its own single-member LAG with LACP.

We do not support MD5 for new BGP sessions, including PNI sessions. We do not support MED.

For egress traffic, each Valve PoP prefers routes learned via PNI first, via IXP second, and via transit last. For routes not learned via peering (i.e. only via transit), AS path length may or may not be considered, depending on the traffic type and network capacity at the PoP.

SteamCaches

Valve operates a SteamCache program, where ISPs or IXPs can host one or more SteamCaches. SteamCaches are servers which act as caches for Steam content traffic and are deployed within an ISP or IXP network. SteamCaches can reduce traffic between an ISP and Valve by up to 90%, and can increase download performance for Steam users.

For more information, check out our SteamCache page.

Note: we are not able to support caches in all countries.

FAQ

Do I need to peer with Valve?

Probably not. If you are connected to one of the same IXPs as us, and you are peering with the route server, you will see our prefixes, and we will route to you via that IXP. If you don’t peer with the route servers, or you wish to announce more specific prefixes, then bi-lateral peering might be a good idea. Bi-lateral peering on its own will not change latency if you already peer with the route server.

But you only announce a few prefixes via the route server - will you announce more prefixes via a bi-lateral session?

No. We announce the same prefixes via bi-lateral sessions as we do via the route server. These are the local prefixes for that PoP.

Why don’t you announce all prefixes via peering?

Our network design is to only announce the local prefixes at each site, and then clients will probe real-time conditions to find the best entry point to our network. We do not need to announce all prefixes at all sites. It will not improve client latency.

Why are you not at “my favourite IXP”?

We are always keen to support more IXPs, especially not-for-profit IXPs. We join most IXPs that are reachable from the locations we are present at. If there is an IXP that is reachable from one of our locations and we’re not there, get in touch with us. Maybe we can join. We are also happy to support people setting up new peering ecosystems, especially in under-served markets.

Why does some traffic come from other locations? Why doesn’t it all come via our peering and/or PNI?

Our network will attempt to deliver content from the closest PoP to your users. Occasionally one PoP may be overloaded, and content will be delivered from other nearby PoPs. There are also times when our CDN rules may need updating. If you think you are getting too much content from the “wrong” location, get in touch with us at peering@valvesoftware.com and we can check.

Note: there will always be a small amount of traffic from other locations as clients probe the best path to our relays. In some network topologies, your clients may find a better path to our network via transit connections rather than via peering.

If there is congestion on our PNIs or peering links, we will de-prioritise content traffic, pushing that towards transit paths. We will keep gaming traffic on PNIs and peering.

I really want a 10G PNI in Ashburn!

We are sorry, but we are no longer able to add new 10G PNIs. Given the relative cost of transit and cross-connects, along with the costs of 10G access on 100G/400G-dense routing platforms, it is not practical to connect at 10G. If you don’t have enough traffic to justify a 100G PNI, join one of the IXPs we are at. You will also benefit from getting access to other networks at those IXPs.

Please fix the latency between Lima and Virginia

Unfortunately the laws of physics apply to us. We can’t change the distance between Lima and Virginia. This is why we have game servers distributed around the world, to get them closer to users. Our network of SDRs also helps with finding the best possible combination of entry point to our network and game servers.

What about CDN nodes? Can I host one?

If you think you have enough traffic, and are willing to host one or more SteamCaches, get in touch and we can work out the details.

I want to run my own game server

For some games, you can run your own “community” dedicated game servers. We can not run official game servers in every possible location. This would fragment the player base, reduce player diversity and affect matchmaking.

Do you have a list of all Steam IP ranges, for adding to firewall filters?

Yes, our IP lists are available here:

You can check the Steam Support page for details on ports and domain names used as well.