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: supp...@snappytelecom.net ----- Original Message ----- > From: "Bob Evans" <b...@fiberinternetcenter.com> > To: "Faisal Imtiaz" <fai...@snappytelecom.net> > Cc: "Patrick W. Gilmore" <patr...@ianai.net>, "nanog list" <nanog@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: 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:>