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
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
Border/Core/Access is great thinking when your a sales rep for a
vendor that sells under power kit. No reason for it any more.
-jim
Ditto
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 IWhat do other providers do? Are your transit peers connected directly to
the core? I can understand such a setup for transit-only providers, but
--------------------------------------------Border, core, access.
Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else.
This was my thought. However... no fat-finger accidents using Team Cymru
in conjunction with my internal RTBH triggers with uRPF enabled on every
single 'edge' interface 
This was the basis of my original question. I want to keep this setup at
edge-only, and don't want to have to apply it within the core gear.
Core is for moving bits as efficiently as possible: no acls; no filters.
...which is what I visualize, and essentially want.
Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else.
I guess I see 'border' and 'access' as the same. Fat-fingering is
important to me. My pref-list is created long before I turn up a BGP
session to a client, and the peering is tested internally before I allow
them to advertise anything (or I advertise anything to them).
At this point, I only have one _true_ peer that advertises their space
directly to me, and it is tied down to the last bit. I even informed
them that I will perform max path, so they will drop if they break it.
Not scalable for multiple clients, but I've learnt a lot. I need to
learn now how to scale, which is why the second half of my question
dealt with templates.
One template, less chance for me to fat-finger 
Cheers,
STeve
Hi Jim,
Unfortunately, I have a mix of EOL Cisco gear in my network, along with
other random custom-built software routers, HP Procurve switches etc.
To be honest, I am very pleased with what I've learnt over the course of
the last two years with my network re-design/build. In my environment,
the layered approach is working exceptionally well (and my sales skills
would have me recommend a different ISP at the drop of a dime if they
could provide what I couldn't 
Primarily, my transition has led me down the BCP 38 path (and it's
associated techniques/side-effects, specifically automated S/RTBH),
which aside from IPv6, is the most important thing I believe that I
could have accomplished during that time.
It would, however, be interesting to learn how the former drawbacks of
flat networks have evolved, and what new technologies make them
successful once again.
Thanks,
Steve
Of course all designs are limited to the budget you have to build the
network 
Heh, yeah, but it's unbelievable what one can learn on an eBay diet when
they put their entire heart, soul and dedication into it!
Steve
Absolutely. I've worked on networks where I'm was amazed on someday
we held it all together, but that is truly when you learn the most.
-jim
I'm very, very happy that there are people out there who can actually
see that...
Steve