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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
