Peering + Transit Circuits

Thank You
Bob Evans

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

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. :slight_smile:

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:

I'm sure others will reply as well, but in case it helps someone
googling in years to come...

Let's look at ParasiteNet, a content heavy network with three BGP
  - Transit provider A via 100Mbps
  - Transit provider B via 100Mbps
  - Peer P via 1GBps (who also buys from provider B at 10G)

If ParasiteNet needed to push more than 100Mbps to provider B, they
might be tempted to route the traffic to peer P, even though peer P
didn't advertise those routes.

ParasiteNet gets a free ride if peer P doesn't notice what is going on
(until they need more than 100Mbps inbound).

I've been told of an occurance of this when a private network started
peering with an edu network. Once the link was up, an absurd amount of
traffic went across the link -- all destined for "the Internet" rather
than the edu network.

When the edu network shutdown the link, they were threatened with

Thank you to everyone who has offered different explanations..

Yes, all it take is one party pooper to spoil a good party...

So now the question is (public or private) what is the best practices to protect the network ?


Faisal Imtiaz
Snappy Internet & Telecom

yep, I hit send too soon. The point I intended to make was that ixp
peering in a vrf will only protect you from transit theft, not clandestine
peering. If you want to stop third party organisations at an ixp from
getting peering by installing static routes, then l2 filters are what you need.


My solution is:

1. Don't care.
2. If some peer steal your transit, and it is noticeable amount of
traffic causing some problems for you - investigate and terminate that peer.

You forgot 3. Publicly shame on NANOG so that others will think twice before peering or doing any business with them.

Hi, Max --

We do this.

Makes policy enforcement easier.


There are use-cases, but they would mostly be internal.


Easier policy enforcement for us.

Lowers the chance of you dealing with traffic in ways you don't intend
(although that can always be fixed).

Spreading both commercial and technical risk, depending on whether you
value transit more than peering, or vice versa.

Avoiding kinky things with VRF's.


We don't generally do uRPF at exchange points, for the simple reason
that the router is dedicated (meaning it does not carry a full table),
and peers leaking your routes to the Internet (which breaks uRPF in this
scenario) is a constant scenario.



D/RTBH still works fine.

S/RTBH would be an issue, but one could enable uRPF temporarily for that.


This is what we do, and to make it more interesting, we have 0/0 and
::/0 on these dedicated peering routers pointing to Null0.