Location of upstream connections & BGP templates
jared at puck.nether.net
Wed Feb 17 19:19:43 CST 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.
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:
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).
More information about the NANOG