[195269] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: BGP peering question

daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Jul 11 15:24:09 2017

X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
Date: Tue, 11 Jul 2017 15:24:05 -0400
In-Reply-To: <1d29ab62-db05-2a89-1426-4f9360cfebc0@globalvision.net>
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

> Then you need to decide if you want to be a hop between those two =
peers or if you want them to serve you only. You can change your routing =
so that both providers know of your routes but you are not sharing =
routes between the two providers.

The definition of =E2=80=9Cpeering=E2=80=9D to most ISPs would =
definitely not include becoming a =E2=80=9Chop=E2=80=9D between two =
peers. Most networks would de-peer you if you sent their prefixes to =
another peer.

--=20
TTFN,
patrick

> On Jul 11, 2017, at 2:40 PM, Ethan E. Dee <edee@globalvision.net> =
wrote:
>=20
> Considering the wording you use, I would include this,
>=20
> 'Peering' is not always necessary. If you can get an upstream provider =
to give you a pack of IP's and it is sufficient to just use them as a =
gateway instead of setting up peering that would be preferred.
>=20
> If you decide you want to have multiple upstream providers or hit some =
kind of speed cap is when I would probably peer with someone else. So =
that you can keep your IP space but share it across a redundant =
connection from a different provider.
>=20
> Then you need to decide if you want to be a hop between those two =
peers or if you want them to serve you only. You can change your routing =
so that both providers know of your routes but you are not sharing =
routes between the two providers.
>=20
> BGP is an enormous protocol and extremely scalable so there is alot to =
consider before you even decide if you want to peer.
>=20
> Because it can sometimes be a headache to setup.
>=20
>=20
> On 07/11/2017 02:17 PM, Bob Evans wrote:
>> There is one more thing to consider based on your app or content =
latency
>> criteria needs. Do you provide a service that performs better with =
low
>> latency - such as live desktop, live video/voice. You may wish to =
peer to
>> have more control and more direct  path to your customer base. If you
>> identify your customer base in a specific region - then explore the =
best
>> peering exchange points to utilize in that region. This can help you
>> reduce your packet hop count/ deliver time, etc. etc..
>>=20
>> Thank You
>> Bob Evans
>> CTO
>>=20
>>=20
>>=20
>>=20
>>> On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
>>> craigwashington01@hotmail.com> wrote:
>>>=20
>>>> Newbie question, what criteria do you look for when you decide that =
you
>>>> want to peer with someone or if you will accept peering with =
someone
>>>> from
>>>> an ISP point of view.
>>>=20
>>> I assume you mean "reciprocal peering" in the sense of shortcut from =
your
>>> customers to their customers rather than the more generic sense that =
any
>>> BGP neighbor is a "peer".
>>>=20
>>> 1. What does it cost? If you and they are already on an IX peering =
switch
>>> or you're both at a relaxed location where running another cable =
carries
>>> no
>>> monthly fee, there's not much down side.
>>>=20
>>> 2. Is the improvement to your service worth the cost? It's not worth
>>> buying
>>> a data circuit or cross-connect to support a 100kbps trickle.
>>>=20
>>> 3. Do you have the technical acumen to stay on top of it? Some kinds =
of
>>> breakage in the peering link could jam traffic between your =
customers and
>>> theirs. If you're not able to notice and respond, you'd be better =
off
>>> sending the traffic up to your ISPs and letting them worry about it.
>>>=20
>>> If the three of those add up to "yes" instead of "no" then peering =
may be
>>> smart.
>>>=20
>>> Regards,
>>> Bill Herrin
>>>=20
>>>=20
>>> --
>>> William Herrin ................ herrin@dirtside.com  bill@herrin.us
>>> Dirtside Systems ......... Web: <http://www.dirtside.com/>
>>>=20
>>=20
>=20
> --=20
> Ethan Dee
> Network Admin
> Globalvision
> 864 704 3600
> edee@globalvision.net
>=20
> For Support:
> Gv-support@globalvision.net
> 864 467 1333
>=20
> For Sales:
> Sales@globalvision.net
> 864 467 1333


home help back first fref pref prev next nref lref last post