Many customers route traffic to us over the public Internet. Given the way our network is architected and our policies, most of this comes to us over peering. If you have equipment with almost any host there’s a very good chance we peer with them. This means in most cases “public Internet” means a direct path between your host and us. This puts us and you well ahead of competitors who have their SBCs in distant exchanges deep within a complicated commodity IP network that (given somewhat restrictive peering policies) can usually only be reached over public transit. Thus, your calls take a long and meandering path, fighting their way through porn and cat pictures along the way.
However, when we talk about ‘peering’ we usually mean via LINX, LonAP or one of the regional exchanges. We’re members of a peering exchange at every core site we have. Here’s the rub though: the economics of peering are such that the price per Mb of port-speed are much higher than for transit unless you’re in the 100Gb arena.
As a result of this, when we speak to other tier2 networks, the consistent message is that none of us have peering exchange ports as big as we’d like to comfortably contain the average volumetric attack. Of course, you could never have enough to contain every size of attack but the more capacity at your disposal in the right place, the greater the chance of winning – the simple fact is once the pipe is full, you’ve lost and you have an outage. Therefore the standard playbook for dealing with an attack is to shut down the peering exchange ports thus forcing all traffic through larger transit ports where it can hopefully be accommodated.
The upshot of this for you is that with the best intent in the world, your host may have no choice but to force traffic to us out over transit, undermining all of the good peering connectivity we’ve enjoyed before. This may not help of course and they may still see saturation on their transit ports, or even deeper within the network, e.g. you’re connected to the same top-of-rack switch as the victim. From there there is not much that can be done other than apologise to your customers.
Let us also not pretend: the attack could be against us. Network-side voice calls all arrive with and leave us over TDM so would be unaffected, but if we shut down our peering ports all IP traffic to/from you would be coming in over transit. We’ve generally scaled our transit ports far far ahead of our peering ports but with a reasonable sized attack there could be congestion or service outage from the perspective of the “public Internet”.
Sadly, the DDoS threat is not diminishing and whilst having greatly over-sized transit ports continues to get cheaper, peering exchange prices are not making the same order of magnitude leap despite bags of latent capacity being there. We therefore find that peers are increasingly wanting to run private connectivity into one or more of our sites despite traffic levels being low and us already having many public peering exchange sessions carrying it. This way when they have to shut down their peering exchange port in order to deal with a situation, their traffic to and from us is unaffected. Even if they lose all off-net connectivity they still have voice service through us.
For the many customers who are ISPs we want to strongly encourage this approach – run a cable into us at a mutual site and we’ll happily peer privately. We do not charge for this as there’s a mutual benefit.
But what if you’re not an ISP and co-locate with someone else? Well we could offer you co-location but, to be honest, it is not our business and you’re likely better served where you are. Your simplest approach is to ask your host to peer privately with us, or perhaps show them this blog. They may need to charge you for set-up but they equally might not as they or other customers may well be doing business with us and benefit from it. This won’t save you from the top-of-rack / noisy neighbour scenario above but it will mean that whatever happens to their (or our) peering exchange ports or even transit ports, traffic between us will flow directly and stands a much better chance of being unaffected.
Finally, if they’re unwilling or unable to do this then you might ask about you being able to cable directly to us. This way you could keep them as the “outside” public Internet but configure your “inside” interfaces to face us over the private cross-connect. We’ve done just this for some high profile customers and can put ACLs in place to ensure no nefarious public traffic finds it’s way to your internal interface through us. We can of course also help with direct fibre to your customer sites, thus keeping their traffic entirely on-net.
The goal here is not to sell you anything, especially if you’re happily buying good services from one of our many peers who specialise in hosting. Instead, in a world where many business critical services run over the public Internet, and many see “the cloud” as absolution from responsibility, we want to encourage you to think about how your service would be affected if “the Internet” at your end or ours were disrupted. There are some simple steps you can take now to put you well ahead of the pack if, or most likely when something happens.
For more information on our network locations please see our datasheet.
