On 2010.07.06 08:53, Thierry wrote: > 1. The two main routers connected to the upstreams (both get full > internet table from them) will be Route Reflectors. We will create a cluster > on these two routers.
Since nobody responded yet, I'll put my neck on the line... Personally, I wouldn't use these upstream-connected devices as your RRs. I'd point one at one upstream and one at the other in order to provide edge filtering, and then let the next layer down perform the reflection (ie. dump the eBGP learnt routes into the next layer down via iBGP). My network is so small, I only have two layers... edge (access/distribution) and core. I let my two 'core' routers do reflection, and all edge devices (upstream connections and access routers) connect to both of them. This way, I get edge filtering, with the added benefit of centralized aggregation/route distribution. The upstream-facing routers are not clients... they are standard multi-homed peers to core that accept the pull-up routes, and feed in what the upstreams provide. > 2. All others routers inside the network will be clients and will have > a session with the two RRs only. I don't think we will have non-clients > routers; we want to avoid full meshed routers as much as we can. My network has to be this way (at this time). Many of my routers don't have enough interfaces to full-mesh. I used to put a switch in front of many of the routers and use sub-ints and vlans, but that became another point of failure, one more piece of hardware to manage/configure, and a whole lot of extra documentation. > 3. The configuration on the two RRs with all the clients will be done > with peer-groups. I don't know for sure if templates work with reflectors or not (I've never used them for the purpose), but do not overlook them, just in case they do provide benefit: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpct.html > Could you tell us if it's the correct way? Not knowing what your business model or your complete objective is, I can't ;) > The cluster should be configured only on the RRs or on every router? See Ivan's fantastic blog post regarding this (imho, anything that Ivan or Iljitsch van Beijnum have written on BGP is worth reading): http://wiki.nil.com/BGP_route_reflectors The way I do it is depicted in the diagram at the very end of the page, less the two non-clients that would be depicted at the top that face the upstreams. The RR clients do not need any additional information config-wise. Only the reflectors need a single line of extra config (in most cases). > This RR mechanism doesn't apply for the external routes, right? Yes, it does (if I understand your intention correctly). When reflecting, prefix lists are even more important than ever. However, they are always pre-configured on your gear before turning up a session anyway, so that shouldn't be an issue :) See Ivan's link I wrote above for further info. > Do you have any other suggestions? Something we should be aware of? Set up your pref-lists, route-maps and any other filters you see fit before letting loose. The reason I do it the way I do is because not all my client-access gear can support full routes (so I pass off default to them), but I want redundancy and consistency without requiring a full mesh. Steve ps. written in haste. corrections, feedback and criticism welcome _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/