Re: Peering + Transit Circuits

["Bob Evans" <bob () FiberInternetCenter com>]

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: Support () Snappytelecom net
>
> ----- 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:>