As Andy says, hierarchical route reflection is perfectly reasonable and used operationally, but needs to be approached with caution. The most basic configuration issue, of course, is that the different levels of clusters mst have cluster IDs. You definitely want to look at the most current route reflector RFC, http://www.ietf.org/rfc/rfc2796.txt which discusses some loop prevention issues -- there are nuances about, for example, intra-cluster to inter-cluster IGP metrics. >you can do for sure, but I'd approach it with caution - your "root" >route-reflectors, if you see what I mean, are going to get pretty heavily >loaded if there is significant transience out there. > >Remember that R-Rs nedd to accept updates from all clients, and flood them >out to all other neighbors (client or not). Imagine what would happen if >you have a two-layer hierarchy of RRs, whereby the clients at the bottom >pass on their updates to the mid-layer RRs, which in turn will pass on the >updates to the top-layer RRs, which have to flood out the updates.... > >Another possibility would be that route flaps might become amplified - ie >generate multiple withdraw/announce pairs which would propagate through the >network, impacting any flap-damping that may be inplemented. http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-00.txt > >What is normally done is to have a fully (iBGP - not neccesarily physical) >meshed backbone, with a pair of RRs at each major location, with them >feeding local RR clients from there. > >hth > >Andy Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=5609&t=5528 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
