[j-nsp] redistribute iBGP learned routes

[Matthias Brumm]

Hi!

Thanks for your insight. I would like to clean up our structure a bit,
so I will go with route-reflection.

Matthias

Am 22. April 2012 19:33 schrieb Wayne Tucker <wayne at tuckerlabs.com>:
> On Sun, Apr 22, 2012 at 9:56 AM, Matthias Brumm <matthias at brumm.net> wrote:
>> customer --- eBGP --- access router --- iBGP --- core router --- iBGP
>> --- edge router --- eBGP --- transit
>>
>> How would you establish this? I do not want an iBGP connection from
>> access to edge. The only way I see at the moment, is to configure
>> edge-routers as route-reflector-client, but that seems to be a rather
>> unclean setup.
>
> Your choices for IBGP are 1.) full mesh or 2.) set up route reflection
> (in the core or another device depending on what you've got to work
> with).
>
> Is there any particular reason you don't want IBGP between access and edge?
>
>
>> Should I redistriute the customers prefixes in OSPF
>> between access and core and advertise them from core to edge via iBGP?
>
> I wouldn't - especially if the customer isn't using a private ASN.
>
>
>> Maybe there is a policy-statement to achieve this?
>
> I'm not aware of any way to make a non-reflector router advertise
> prefixes to an IBGP peer that it learned from another IBGP peer.  Even
> if I did, I would neither use it nor recommend its use.
>
>> What would be the best practice here?
>
> small scale: full mesh
> medium scale (no firm definition - just a matter of when maintaining
> (n**2-n)/2 sessions gets to be troublesome for your environment):
> route reflectors
> large scale: lots of ways.. may involve route reflectors,
> confederations, MPLS and BGP-free core, etc.
>
> :w