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