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: supp...@snappytelecom.net ----- 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:>