[183217] in North American Network Operators' Group
Re: Peering + Transit Circuits
daemon@ATHENA.MIT.EDU (Faisal Imtiaz)
Tue Aug 18 19:26:19 2015
X-Original-To: nanog@nanog.org
Date: Tue, 18 Aug 2015 23:26:14 +0000 (GMT)
From: Faisal Imtiaz <faisal@snappytelecom.net>
To: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Thank you for the explanation..
However wouldn't a few other other attributes of the traffic show up .
e.g. you would have asymmetric traffic.. going out via us, but coming bac=
k via a totally another path ?
BTW, my comment "We will trust everything coming in" was in ref. to QOS tag=
s.
>>>> 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 C=
omcast,
>>>> your peering router will drop it and send an ICMP Network Unreachable.
In this scenario, the peering router is feeding routes to a Route Reflector=
?=20
and not taking in full routes from the route reflector ?
>>>But standard network hygiene will stop those.
If there are any resources you could point to for these, I would be much ob=
liged..
Thanks
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net
----- Original Message -----
> From: "Patrick W. Gilmore" <patrick@ianai.net>
> To: "nanog list" <nanog@nanog.org>
> Sent: Tuesday, August 18, 2015 7:12:23 PM
> Subject: Re: Peering + Transit Circuits
> Assume you and I are at an IX and peer. Suppose I send you traffic for Co=
mcast.
> I can do this, even if you do not send me prefixes for Comcast. It requir=
es me
> to manually configure things, but I can do it.
>=20
> Put another way, you said "We will trust everything coming in=E2=80=9D. I=
am saying that
> perhaps you should not.
>=20
> As Comcast is not one of your customers, you will have to send the packet=
s out
> your transit provider. You do not get paid when I give you the packets, a=
nd 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.
>=20
> Normally a router gets a packet and sends it on its way without looking a=
t the
> source. However, if you have a router at the IX which has _only_ peer rou=
tes
> and your routes, that solves the problem. If I send you a packet for Comc=
ast,
> your peering router will drop it and send an ICMP Network Unreachable. No
> filters to manage, no RIRs to sync, nothing to code, etc.
>=20
> There are evil ways around this if you do not configure your router prope=
rly
> (e.g. send you a prefix for Comcast with next-hop set to inside your netw=
ork).
> But standard network hygiene will stop those.
>=20
> And as has been stated, this doesn=E2=80=99t have anything to do with URP=
F either. (Not
> sure why Nick brought that up, he=E2=80=99s smart enough to know what URP=
F is and runs
> an exchange himself, so I think he just brain-farted. Happens to us all.)
>=20
> Hope that made it more clear.
>=20
> --
> TTFN,
> patrick
>=20
>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal@snappytelecom.net> wr=
ote:
>>=20
>> Let me start backwards...
>>=20
>> To me 'peering' is sharing internal routes and downstream customer route=
s,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 advertis=
ed to
>> whom... how exactly someone (peers) 'steal' transit ?
>> (If one is not managing the filters well then yes it is possible, but th=
at would
>> be a configuration error ?)
>>=20
>>=20
>> Maybe I am naive, to my Peering routes (relationships) are a subset of I=
P
>> Transit Routes (relationships)
>>=20
>> Based on above belief...
>>=20
>> Then Item # 3, becomes the choice of the OP.... where one can make one o=
f two
>> starting assumptions... We will trust everything coming in and change wh=
at we
>> don't like... or We will not trust anything coming in, and change (accep=
t) what
>> we like.
>>=20
>> Items # 1 & 2, would be a function of network design, technical requirem=
ents
>> (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 tra=
nsit
>>> 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-Peering=
PolicyEnforcement.pdf
>>> )
>>> 4. Don't worry about peers stealing transit.
>>> 5. What is peering?
>>>=20
>>> Your comments are appreciated.
>>>=20
>>> --
> >> Tim:>
