[183220] in North American Network Operators' Group
Re: Peering + Transit Circuits
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Aug 18 19:39:35 2015
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
Date: Tue, 18 Aug 2015 19:38:18 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz <faisal@snappytelecom.net> =
wrote:
>=20
> Thank you for the explanation..
>=20
> 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 =
back via a totally another path ?
So? If I am a content provider, my transit has more out than in. If I =
can push some of that outbound traffic through you for free, I=E2=80=99ll =
get the inbound over my transit provider for free since inbound is so =
low.
> BTW, my comment "We will trust everything coming in" was in ref. to =
QOS tags.
>=20
>>>>> 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.
>=20
> In this scenario, the peering router is feeding routes to a Route =
Reflector ?=20
> and not taking in full routes from the route reflector ?
The peering router has routes from the peers (since it peers directly =
with them), and routes from your internal network. Not sure where a =
router reflector comes into this. You can use one, or not, but it=E2=80=99=
s not relevant to which routes the peering router has.
>>>> But standard network hygiene will stop those.
> If there are any resources you could point to for these, I would be =
much obliged..
There are lots, but don=E2=80=99t have my references with me. There=E2=80=99=
s 10K+ people on this list, I=E2=80=99m sure someone else has a list =
they like. :)
--=20
TTFN,
patrick
> ----- 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
>=20
>> 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.
>>=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 =
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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.)
>>=20
>> Hope that made it more clear.
>>=20
>> --
>> TTFN,
>> patrick
>>=20
>>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz =
<faisal@snappytelecom.net> wrote:
>>>=20
>>> Let me start backwards...
>>>=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:>
