[c-nsp] Separating internal/customer routes into IGP/EGP

[Jee Kay]

On 03/11/06, Jee Kay <jeekay at gmail.com> wrote:
> I keep seeing people on here and other places recommending that your
> IGP should only ever carry your internal routes (loopbacks, transfers,
> etc) and you should run something like iBGP to carry customer routes
> that you learn/inject/blah.

Having had some interesting responses to this, I've run into something
that's causing me a bit of a problem..

Basically, our core consists of 6 devices which are fully iBGP meshed.
These are split into 3 pairs, each of which handle core and
distribution functions for a given location.

The problem I'm having is that after configuring the two devices at a
given location to peer with an edge device, and configuring the edge
device as an RR client, the RR does not then readvertise those routes
into the core iBGP mesh. From my understanding of iBGP/RR this is
actually the correct behaviour, but isn't what I want to end up with
:)

Just in case I'm being terribly obtuse, here's a rough ASCII art
version of my network:

     C1---C3
    /| \ / |\
PE1- |  X  | -PE2
    \| / \ |/
     C2---C4

Here, PE1 is a peers with C1/C2 and is an RR client of both. PE2 peers
with C3/C4 and is an RR client of both. However, C3/C4/PE2 never learn
PE1s routes, and vice versa in the other direction.

Without having to have the PE devices peer with every single RR on the
network, is there a way around this? Preferably as simply as possible
(ie avoiding confederations if possible, as they seem way overkill for
a network this size).

All of the examples I've come across that deal with redundant RRs
explain the need to use cluster IDs for each 'set' of RRs, but setting
different cluster IDs for C1/C2 and C3/C4 (ie C1/C2 are in cluster 1,
C3/C4 are in 2) didn't seem to make a huge amount of difference.

Thanks in advance,
Ras