Location of upstream connections & BGP templates

Thu Feb 18 01:19:43 UTC 2010

On Feb 17, 2010, at 7:10 PM, Steve Bertrand wrote:

> Hey all,
> 
> I've got a couple of questions that I'd like operational feedback about.
> .
> 
> Although we're an ISP, we currently are only an access provider. We
> don't yet provide any transit services, but the requirement for us to do
> so may creep up on a very small scale shortly. Nonetheless...
> 
> I'm on the latter stages of transforming our network from flat to
> layered. My thinking is that my 'upstream' connections should be moved
> out of the core, and onto the edge. My reasoning for this is so that I
> can eliminate ACL/filtering etc from the core, and push it ALL out
> toward the edge, keeping the core as fast, sleek and maintenance-free as
> possible. I visualize my transit providers as essentially 'access', not
> part of my core backbone.

One of the challenges is how do you decide if something is "core" vs "access".

If both are the same speed, is there a reason to keep them on different devices?

How do you aggregate your customers if they are the same speed as your "core"?  Are there points of savings?

I don't know if you're doing T1 aggregation or 10GE, so this is hard to speculate, but I honestly would not spend a lot of time talking to people that have different buckets for a device class.  What is "core" today is always edge in the future.

"peering edge"
"customer edge"
"core"

Mean different things to different networks/people.  Some see value, others see excess.

> What do other providers do? Are your transit peers connected directly to
> the core? I can understand such a setup for transit-only providers, but
> I can't see how that makes sense for any provider that provides (mostly)
> access services. I'm looking for feedback from both large and small
> providers, just to gain some perspective.
> 
> Another question, along the same lines, due to recent discussions, I've
> done a great deal of research on BGP templates, and now want to migrate
> to them from peer-group. Before I waste lab time configuring things, I
> just want to ask for feedback based on experience on whether the
> following makes sense/will work for transition:
> 
> - configure template structure
> - 'no' a single neighbour
> - apply templates to neighbour
> - the neighbour comes back up
> - wash, rinse, repeat

I've done some examples of templates/community based route filtering here:

http://puck.nether.net/bgp/

The examples for Cisco and Juniper should help you create a policy that is sane for your network, or at least something to keep you from leaking transit-learned routes to another one of your transits. (This is very common).

- Jared