[c-nsp] Peering + Transit Circuits

[Nathan Ward]

Here in New Zealand, peering typically involves very few routes per peer, so we can easily do option 2 without it meaning lots of route bloat across your network.
It is also common that networks only have a couple of transit providers, in which case accepting full routes in to a VRF per transit provider is also acceptable for most equipment. Many providers here only accept a default from transit, which obviously makes it all very easy.
Export routes in to iBGP with a common “Internet” ext-community, and you can import that everywhere you want the full network view to be visible.

A variation I have seen a few times (credit? blame? to Pshem for doing the design when I first saw this) is to generate a default on a very capable router, have it run per-VRF label mode so that incoming packets to that default route do a route lookup rather than ending up going to null, and export that default to a “default route” ext-community which is imported by your less capable routers that can live with sending outbound packets via this box.
Here in New Zealand this works well, because we can import “domestic” routes and the default in to every PE without any problems, even less capable ones. Our single cable system to non-domestic networks terminates in one city (Auckland) so generating that default on routers there works well and doesn’t significantly impact performance.
For this to work well, rt-filter is obviously important.

Something similar may work for networks in other countries, but it depends on the network.

--
Nathan Ward

> On 19/08/2015, at 00:29, Tim Durack <tdurack at gmail.com> wrote:
> 
> 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:>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/