[183216] in North American Network Operators' Group
Re: Peering + Transit Circuits
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Aug 18 19:12:27 2015
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
Date: Tue, 18 Aug 2015 19:12:23 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Assume you and I are at an IX and peer. Suppose I send you traffic for =
Comcast. I can do this, even if you do not send me prefixes for Comcast. =
It requires me to manually configure things, but I can do it.
Put another way, you said "We will trust everything coming in=E2=80=9D. =
I am saying that perhaps you should not.
As Comcast is not one of your customers, you will have to send the =
packets out your transit provider. You do not get paid when I give you =
the packets, and you probably pay your transit provider to get to =
Comcast. So I have gotten something for free, and you are paying for it =
- i.e. stealing.
Normally a router gets a packet and sends it on its way without looking =
at the source. However, if you have a router at the IX which has _only_ =
peer routes and your routes, that solves the problem. If I send you a =
packet for Comcast, your peering router will drop it and send an ICMP =
Network Unreachable. No filters to manage, no RIRs to sync, nothing to =
code, etc.
There are evil ways around this if you do not configure your router =
properly (e.g. send you a prefix for Comcast with next-hop set to inside =
your network). But standard network hygiene will stop those.
And as has been stated, this doesn=E2=80=99t have anything to do with =
URPF either. (Not sure why Nick brought that up, he=E2=80=99s smart =
enough to know what URPF is and runs an exchange himself, so I think he =
just brain-farted. Happens to us all.)
Hope that made it more clear.
--=20
TTFN,
patrick
> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal@snappytelecom.net> =
wrote:
>=20
> Let me start backwards...=20
>=20
> To me 'peering' is sharing internal routes and downstream customer =
routes,and not external ones.
> IP transit is all of the external routes including internal routes =
& downstream customer routes
>=20
>=20
> Having said that..... if one is control of what IP Prefixes get =
advertised to whom... how exactly someone (peers) 'steal' transit ?
> (If one is not managing the filters well then yes it is possible, but =
that would be a configuration error ?)
>=20
>=20
> Maybe I am naive, to my Peering routes (relationships) are a subset of =
IP Transit Routes (relationships)
>=20
> Based on above belief...
>=20
> Then Item # 3, becomes the choice of the OP.... where one can make one =
of two starting assumptions... We will trust everything coming in and =
change what we don't like... or We will not trust anything coming in, =
and change (accept) what we like.
>=20
> Items # 1 & 2, would be a function of network design, technical =
requirements (maintenance window) etc etc.. easier to deal with a =
distributed edge vs all in one when one has to bring anything down for =
any reason..
>=20
> I am open to learning and being corrected if any of the above is wrong =
!
>=20
>=20
> Faisal Imtiaz
> Snappy Internet & Telecom
>=20
> ----- Original Message -----
>> From: "Tim Durack" <tdurack@gmail.com>
>> To: cisco-nsp@puck.nether.net, "nanog list" <nanog@nanog.org>
>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>> Subject: Peering + Transit Circuits
>=20
>> 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
>> --
>> Tim:>
