[c-nsp] iBGP Route Reflection

[Mark Tinka]

On Tuesday 06 July 2010 08:53:54 pm 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.

If you can, try and have other routers running as your route 
reflectors. Yes, you can implement route reflection on your 
border routers, but a lot more policy configuration would be 
needed to account for that. It's not impossible, but can get 
hairy.

> 2.	All others routers inside the network will be clients
>  and will have a session with the two RRs only.

Yes.

The route reflectors should also peer with each other. 
Again, a tricky situation if your border routers are also 
your route reflectors, but a pretty standard one if they 
aren't.

>  I don't
>  think we will have non-clients routers; we want to avoid
>  full meshed routers as much as we can.

Route reflectors will get you there.

>  3.	The
>  configuration on the two RRs with all the clients will
>  be done with peer-groups.

Or if you're daring enough, session & policy templates :-).

Peer groups should be fine :-).

> Could you tell us if it's the correct way?

Many folk run route reflectors on their core routers, which 
is logical. We don't, since our core routers don't run BGP 
(for v4).

Whatever the case, if you can, separate your border routers 
from your route reflectors.

> The cluster should be configured only on the RRs or on
>  every router?

Just the route reflectors.

> This RR mechanism doesn't apply for the external routes,
>  right?

It does, because when external routes enter your network, 
they're now iBGP routes.

> Do you have any other suggestions? Something we should be
>  aware of?

If you choose to go for dedicated route reflectors, take 
them out of the forwarding path (Overload bit in IS-IS, or 
the equivalent in OSPF).

Use your route reflectors to originate your RIR allocations.

Hope this helps.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100712/d050085d/attachment.bin>