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 <wa...@tuckerlabs.com>: > On Sun, Apr 22, 2012 at 9:56 AM, Matthias Brumm <matth...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp