[183198] in North American Network Operators' Group
Re: Peering + Transit Circuits
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Aug 18 13:29:43 2015
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
Date: Tue, 18 Aug 2015 13:29:35 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Aug 18, 2015, at 1:24 PM, William Herrin <bill@herrin.us> wrote:
> On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack <tdurack@gmail.com> wrote:
>> Question: What is the preferred practice for separating peering and =
transit
>> circuits?
>>=20
>> 1. Terminate peering and transit on separate routers.
>> 2. Terminate peering and transit circuits in separate VRFs.
>> 3. QoS/QPPB (
>> =
https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPol=
icyEnforcement.pdf
>> )
>> 4. Don't worry about peers stealing transit.
>> 5. What is peering?
>>=20
>> Your comments are appreciated.
>=20
>=20
> If you have a small number of peers, a separate router carrying a
> partial table works really well.
To expand on this, and answer Tim=E2=80=99s question one post up in the =
thread:
Putting all peer routes on a dedicated router with a partial table =
avoids the =E2=80=9Csteal transit=E2=80=9D question. The Peering router =
can only speak to peers and your own network. Anyone dumping traffic on =
it will get !N (unless they are going to a peer, which is a pretty =
minimal risk).
It has lots of other useful features such as network management and =
monitoring. It lets you do maintenance much easier. Etc., etc.
But mostly, it lets you avoid joining an IX and having people use you as =
a backup transit provider.
--=20
TTFN,
patrick
