[c-nsp] RTBH at the access edge
Justin Shore
justin at justinshore.com
Mon Apr 14 10:58:08 EDT 2008
Since it's a slow Monday I've found time to work on my RTBH deployment.
I currently have the RTBH trigger router in an iBGP mesh with the core
routers at each POP and the border routers.
The last main thing I have to do is implement RTBH at the access edges
of our network. Each edge router is dual-homed to the core routers. I
was going to set up the core routers to act as RRs for the edge devices,
with each edge device peering with the pair of core routers in each POP
(but not the other access routers). Most of the access devices don't
have iBGP set up to announce the customer prefixes (most use the IGP)
but I'm taking care of that as I get to them. ClusterIDs on the core
routers have already been set appropriately.
The dilemma that I'm faced with is how best to use the RRs or if I
should even use them at all. My original back-of-a-napkin drawing had
the RRs propagating RTBH routes down to the access devices. Of course
the problem there is that an iBGP speaker won't propagate routes learned
from other iBGP speakers. I don't want to add the edges to the iBGP
mesh. The mesh would be unwieldy at that point; plus most of the edge
couldn't handle full tables (I wish they could so that I could implement
edge to edge MPLS).
One thought I had was to add the RTBH trigger router(s) in with the
small RR-to-access-device mesh. So the RTBH trigger router would have
dozens of peers but each access device would only have 3 (2 cores and
one RTBH router). I can't think of any problems with this method. The
RTBH trigger router does not pass any traffic so his chopped up views of
the network aren't a problem I don't think.
I'm probably over-thinking this problem. Is there a simple and more
elegant solution that I'm missing?
Thanks
Justin
More information about the cisco-nsp
mailing list