[c-nsp] iBGP Route Reflection

[Steve Bertrand]

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