[c-nsp] Peering + Transit Circuits

[Alexandre Snarskii]

On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote:
> Question: What is the preferred practice for separating peering and transit
> circuits?

We are using option 3 (QoS/QPPB) with some modifications:
- being a Juniper shop, we don't have to mess CoS :) 
- customers are very unhappy when you blackhole their traffic :(
So, instead of dropping packets at ingress, we are trying to find if there
is any (less-specific) route pointing to customer and dropping traffic only 
when there are no such routes. To achieve that: customer's routes installed 
not only to global table, but also in semi-transparent vrf with exits over 
customer's interfaces only. Fraudulent traffic is directed to this vrf
and either finds it's way to customer (when your peer is just not able to 
hold full-view with all specifics and uses aggregate routes for routing) 
or gets dropped (when your peer points default route to you...).

Well, there is a potential for suboptimal routing in this scenario:
your customer announces /16 and their branch office announces /24 to
your competitor. Fraudulent traffic to /24 will be forwarded via aggregate 
route first, and then may re-enter your network to reach destination
(traffic from a customer is [mostly] always legitimate, no chance for 
routing loops), but our practice shows no complaints (yet?).

PS: as far as I know, most networks use option 4 (do not worry).

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