Buying IP Bandwidth Across a Peering Exchange

Bill Woodcock woody at pch.net
Tue Nov 25 18:56:06 UTC 2014


On Nov 25, 2014, at 10:47 AM, Colton Conor <colton.conor at gmail.com> wrote:
> I know typically peering exchanges are made for peering traffic between
> providers, but can you buy IP transit from a provider on an exchange? An
> example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple
> providers on the exchange, and buy 5Gbps of IP transit from others on the
> exchange?

Some IXPs have a rule that explicitly disallows this, others encourage it, most don’t care.  I don’t know of any that have a mechanism to enforce a rule prohibiting it.

PCH’s guidance in the IXP formation process is to avoid creating rules which are, practically, unenforceable.  So we generally counsel IXPs against having a rule precluding transit across the switch fabric.  That said, a crossconnect is a _much better idea_.  

> Some might ask why not get a cross connect to the provider. It is cheaper
> to buy an port on the exchange (which includes the cross connect to the
> exchange) than buy multiple cross connects. Plus we are planning on getting
> a wave to the exchange, and not having any physical routers or switches at
> the datacenter where the exchange/wave terminates at. Is this possible?

Yes, it’s possible, but what you describe is a pretty fragile setup.  Lots of common points of failure between peering and transit; places where screwing one up would screw both up.  If all of this is really tangential to whatever you’re doing, and you don’t mind looking a little out-of-step with best practices, and you don’t mind it all being down at once, any time anything breaks, then it may be a reasonable economy.  If you’re planning on actually depending on it, you need to do better engineering, and either spend more money, or allocate your money more conservatively.

Doing everything the cheapest possible way, regardless of the fragility or complexity, is very short-sighted, and is unlikely to be an economy in the long run.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20141125/eb2cfb64/attachment.sig>


More information about the NANOG mailing list