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