Question on peering strategies

Reza Motamedi motamedi at cs.uoregon.edu
Mon May 16 20:06:16 UTC 2016


Hi Nick,

Thanks for the reply.

Let me clarify another issue first, since I thought the colo's business
model is different at least in the US. So if AS-a puts its router in
Equinix, it should pay the same amount in the following two scenario (only
considering the interconnection cost and not the rent for racks and remote
hands and ....)?
1) AS-a only connects to the IX and establishes all inter-AS connections
through the IX.
2) AS-a connects to the IX, in addition to privately connecting to bunch of
other colo customers (these private connections can be either transit or
settlement-free peerings).
My understanding was that colos in the US charge per cross connect, so the
more you connect privately, the more you pay. This article may be old, but
I don't think much has changed:
https://www.telegeography.com/press/press-releases/2015/02/26/colocation-cross-connect-price-disparities-remain-between-u-s-europe/index.html

With respect to my second question, I was asking if is practical/reasonable
to keep both the connection types to same network (say AS-b) at the same
time, i.e., connect privately over a cross-connect and keep the public
connection over the IX.



Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Mon, May 16, 2016 at 11:10 AM, Nick Ellermann <nellermann at broadaspect.com
> wrote:

> Reza,
> You maybe overthinking this one a bit. The economics are something to
> consider, however all public exchanges have different economics. With
> Equinix you pay pretty much a flat rate for a single 1Gbps/10Gbps link that
> includes the cost of facility cross-connect and public exchange access.  It
> is a nice one to many connection for all those various network and content
> networks your end users would appreciate direct connectivity. Depending on
> the public exchange you either have a single BGP session or a BGP session
> per network you are peering. Really after that, it's just BGP routing and
> route management. You do need to be careful about not being too overly
> dependent on a single public switch link, in some cases like at Equinix you
> may want multiple connections to redundant public exchange switches at that
> site. There is a balance you want to seek of number of paid upstream
> network transit providers you are connected to versus how many direct
> peering arrangements you have setup. It's not usually practical for a
> smaller network to have loads of BGP peers.  There are lots of good
> articles online about this fine balance and some good advice from
> experienced network operators.
>
> To your later questions. For your simple example, if AS-a and AS-b were
> both already on the public IX, and the link wasn't too overly critical then
> using the public IX switch maybe a good first step. However as that
> relationship matures, they most likely in a real world example may look to
> split the cost of the private cross-connect. If it was mutually beneficial.
> There is much more to public peering and transit than the technical
> conversation. Most of the larger networks on the public switches won't peer
> privately with anyone or only with extremely larger networks. To get a
> provider such as this to peer both privately and on the public exchange is
> not a technical issue, it's more of a business overhead and management
> issue.
> If you have a couple of quality upstream transit providers, they will be
> excellent failovers to a public switch outage.  Plan for the public switch
> to have as many problems as any upstream provider.
>
>
> Sincerely,
> Nick Ellermann – CTO & VP Cloud Services
> BroadAspect
>
> E: nellermann at broadaspect.com
> P: 703-297-4639
> F: 703-996-4443
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org]
> On Behalf Of Reza Motamedi
> Sent: Monday, May 16, 2016 1:46 PM
> To: nanog at nanog.org
> Subject: Question on peering strategies
>
> Dear Nanogers,
>
> I have a question about common/best network interconnection practices.
> Assume that two networks (let's refer to them as AS-a and AS-b) are
> present in a colocation facility say Equinix LA. As many of you know,
> Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct
> 1) using private cross-connect
> 2) through the public IXP's switching fabric.
> Is it a common/good practice for the two networks to establish connections
> both through the IXP and also using a private cross-connect?
>
> I was thinking considering the cost of cross-connects (my understanding is
> that the colocation provider charges the customers for each cross-connect
> in addition to the rent of the rack or cage or whatever), it would not be
> economically reasonable to have both. Although, if the cross-connect is the
> primary method of interconnection, and the IXP provides a router-server the
> public-peering over IXP would essentially be free. So it might makes sense
> to assume that for the private cross-connect, there exists a back-up
> connection though the IXP. Anyway, I guess some discussion may give more
> insight about which one is more reasonable to assume and do.
>
> Now my last question is that if the two connections exist (one private
> cross-connect and another back-up through the IXP), what are the chances
> that periodically launched traceroutes that pass the inter-AS connection in
> that colo see both types of connection in a week. I guess what I'm asking
> is how often back-up routes are taken? Can the networks do load balancing
> on the two connection and essentially use them as primary routes?
>
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon
>


More information about the NANOG mailing list