Founder & President
When looking at internet providers for your business (especially in the day in age of VPN, SDWAN and Cloud services), it is important to understand where your physical network communicates to other networks, often called “peering”.
For example, if a client has Lumen services at their offices for primary IP and in their remote offices, they are using Spectrum, Comcast, Cogent and AT&T services. These are not the same network, so, how do they communicate? The networks communicate through internet exchanges where the internet traffic converges and passes traffic back and forth, or, at “peering points”.
Some of the primary peering points where internet providers converge in the US include Chicago, NYC, LA, Dallas or Miami. There are also secondary peering points throughout the US where fewer networks may converge to connect regional internet providers and traffic in Denver, Ashburn, Houston, Atlanta, Kansas City, Detroit, Seattle and Ashburn, to name a few.
The importance of traffic
Traditionally the exchange of traffic is at no cost to either Internet provider, because the traffic between the two typically offsets the other (settlement free peering). However, if traffic being passed is heavily skewed in a certain direction, Internet providers will require payment to accept traffic or throttling may occur. This is important to consider when choosing an Internet provider as you do not want your traffic to be throttled or not passed due to an Internet provider conflict.
When deploying SDWAN, VPN, SaaS and Cloud services, understanding how your traffic is being handed off to a disparate carrier is vital to the health of an application. The originating carrier wants to hand off the traffic as soon as they can to the closest peering point thereby minimizing their network congestion. Therefore, where your data is peered is significantly important.
For example, if you have two offices in Dublin OH communicating over VPN and using different internet providers, your traffic may be traversing to Chicago, IL or Dallas, TX before returning to Dublin OH to communicate.
This will create additional latency, hops and complexity to the communication. The same scenario goes for Cloud services. If you are using a CCaaS or UC provider without a regionalize calling solution, who has their primary nodes in Dallas and Seattle, your traffic will traverse to the closest peering points (which may be in Chicago or Ashburn) and then across the US to communicate with the primary CCaaS or UC nodes.
Creating routes
We have often done trace routes on IP addresses to see how many hops it takes to reach a destination. When completing a hop trace route, you will see the peering points along the way for your packets to reach a destination. At times, tables that route traffic can loop your traffic multiple times before peering with other providers.
Clients should utilize Internet providers who keep their routes clean and efficient to benefit from faster connections and lower latency. In the day in age of mergers and acquisitions of Internet providers, we have seen the merging of networks cause massive issues with latency and traffic due to inefficient routes due to incorrect or overly complex tables. It is possible to hard code your peering or routing requests, so your traffic is not getting caught in a bad routing table or peering situation.
Internet is just not internet. It is important to consider who your provider is, who they peer with, if they pay for peering, and where they peer, before implementing an internet solution.