[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