Peering + Transit Circuits

[faisal at snappytelecom.net (Faisal Imtiaz)]

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 ?

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:>