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.
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.
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
peerings:
- 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
lawsuits...
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.
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.
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.
