Peering + Transit Circuits

Faisal Imtiaz faisal at snappytelecom.net
Wed Aug 19 00:16:13 UTC 2015


Hi Bob,
Your point is completely understood...
so the next question becomes what are these best practices methods ?

:)

Faisal Imtiaz
Snappy Internet & Telecom

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
> From: "Bob Evans" <bob at FiberInternetCenter.com>
> To: "Faisal Imtiaz" <faisal at snappytelecom.net>
> Cc: "Patrick W. Gilmore" <patrick at ianai.net>, "nanog list" <nanog at nanog.org>
> Sent: Tuesday, August 18, 2015 7:36:00 PM
> Subject: Re: Peering + Transit Circuits

> Thank You
> Bob Evans
> CTO
> 
>> 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
>> back via a totally another path ?
> 
> Patrick is correct in the approach you should take. If you don't have much
> traffic to being with - yes, you are correct that you'll notice a bounce.
> However, you should build a network so that your average traffic level can
> grow without having to check things manually. The more you automate the
> more you and your network are worth. This way you can simply upgrade ports
> at IX locations in a second without worrying about traffic levels and
> having to establish new or change existing policies.
> 
> Thank You
> Bob Evans
> CTO
> 
>>
>> BTW, my comment "We will trust everything coming in" was in ref. to QOS
>> tags.
>>
>>>>>> 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.
>>
>> In this scenario, the peering router is feeding routes to a Route
>> Reflector ?
>> 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
>> obliged..
>>
>>
>> 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 at Snappytelecom.net
>>
>> ----- Original Message -----
>>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>>> To: "nanog list" <nanog at 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
>>> 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�. 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’t have anything to do with URPF
>>> either. (Not
>>> sure why Nick brought that up, he’s 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.
>>>
>>> --
>>> TTFN,
>>> patrick
>>>
>>>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net>
>>>> wrote:
>>>>
>>>> Let me start backwards...
>>>>
>>>> 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
>>>>
>>>>
>>>> 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 ?)
>>>>
>>>>
>>>> Maybe I am naive, to my Peering routes (relationships) are a subset of
>>>> IP
>>>> Transit Routes (relationships)
>>>>
>>>> Based on above belief...
>>>>
>>>> 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.
>>>>
>>>> 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..
>>>>
>>>> I am open to learning and being corrected if any of the above is wrong
>>>> !
>>>>
>>>>
>>>> Faisal Imtiaz
>>>> Snappy Internet & Telecom
>>>>
>>>> ----- Original Message -----
>>>>> From: "Tim Durack" <tdurack at gmail.com>
>>>>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>>>>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>>>>> Subject: Peering + Transit Circuits
>>>>
>>>>> Question: What is the preferred practice for separating peering and
>>>>> transit
>>>>> circuits?
>>>>>
>>>>> 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-PeeringPolicyEnforcement.pdf
>>>>> )
>>>>> 4. Don't worry about peers stealing transit.
>>>>> 5. What is peering?
>>>>>
>>>>> Your comments are appreciated.
>>>>>
>>>>> --
>>> >> Tim:>



More information about the NANOG mailing list