On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz <fai...@snappytelecom.net> wrote: > > 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 ?
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’ll 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. > >>>>> 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 ? 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’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’t have my references with me. There’s 10K+ people on this list, I’m sure someone else has a list they like. :) -- TTFN, patrick > ----- Original Message ----- >> From: "Patrick W. Gilmore" <patr...@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 >> 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 <fai...@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" <tdur...@gmail.com> >>>> To: cisco-...@puck.nether.net, "nanog list" <nanog@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:>
