Re: Peering + Transit Circuits

["Patrick W. Gilmore" <patrick () ianai net>]

On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz <faisal () 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" <patrick () 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 <faisal () 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 () gmail com>
> > > > To: cisco-nsp () 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:>