Peter, ----- Original Message ----- From: "Peter van Oene" To: Sent: Tuesday, April 09, 2002 3:51 PM Subject: Re: iBGP full mesh ? [7:40741]
> inline > > > >I know that's how Juniper defaults its BGP synch. I agree that synch should > >be disabled by default, really do not think people will put a non-bgp > >speaking router in the middle of their network by design, of course, unless > >we are talking about using stuff like MPLS at the core and pushing BGP out > >to the edge. > > > >But I still do not like the fact that Juniper makes BGP synch > >non-configurable, why not giving users the knob? > > Hi Kent. Juniper makes routers positioned to play in SP networks. These > networks generally maintain routing information for thousands of > prefixes. Pushing these large volumes of routing information into an IGP > simply isn't a good idea. In general, any redistribution in either > direction between BGP and IGP's is frowned upon. Many routing > implementations will struggle greatly with 100k+ prefixes in OSPF (they > don't fit in IS-IS). I expect the folks at Juniper who wrote the BGP > implementation were mostly concerned with things people actually use. > I hope I did not give the impression the I am even remotely behind the idea of redistributing BGP into IGP. This draft http://search.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-03.txt is trying to lift the 30K routes limit. I actually hope the authors will give more explanation of the reasons they listed that can contribute to exceeding this limit in the draft. > I'm personally not aware of any situation where BGP synchronization would > represent the best solution to a given problem. To be honest, in the last > bunch of years, the only place I've even heard the feature discussed has > been in vendor certification forums where best practises (and reality for > that matter) seem secondary to passing tests. Agree, hope cisco can change the default to disable. > > Of note, building a BGP free core using MPLS for transport doesn't not > create a situation where external routing information external to the AS > needs to be passed into a non BGP routing domain in the same way that using > an IGP in the core would. > > Pete As you mentioned here that they are not the same way, I assume you meant that they are certainly not the same because if we have mpls at the core, the only thing we need is IGP and mpls, there will be no need for any external information in the core, in that case they are, of course, not the same. Hope I am not repeating or misreading you, maybe both? :-) Thanks Kent > > > > > > >Thanks > >Kent > > > > > > > At 11:28 AM 4/8/2002 -0400, you wrote: > > > >It's not default for the same reason why unicast rpf (antispoofing) is > > > >not default in ISO; because people are stupid, and under poor design, it > > > >could produce very undesirable and hard to troubleshoot results. In > > > >other words, if you don't know why you are disabling synchronization, > > > >don't do it. > > > > > > > >Take the following scenario: A multihop iBGP link between routers (A) > > > >and (B) in which a non-bgp IGP router (C) is routing packets between > > > >them. Both BGP links are advertising full tables to each other, and, > > > >under your suggested default config, would attempt to forward packets to > > > >destinations that router C has no clue about. Then what does router C > > > >do with these destinations? > > > > > > > >The answer, of course, is to set up a iBGP full mesh, and then to > > > >disable synchronization , and if you are smart, design your network so > > > >that your IGP learns only about downstream routes and set a default > > > >route up to the core of your network. > > > > > > > >Anyway, the point being, sync is enabled by default because you really > > > >should know what you are doing before you disable it. > > > > > > > >On Mon, 2002-04-08 at 10:44, MADMAN wrote: > > > > > I can think one one good reason why you would disable sync, you can't > > > > > redistribute 100K routes into ANY IGP. Why are you so concerned > about > > > > > disabling sync?? It should be default. > > > > > > > > > > Dave > > > > > > > > > > Jay wrote: > > > > > > > > > > > > BGP Rules of thumb: > > > > > > > > > > > > BGP advertised prefix must also exist in local IGP table. > > > > > > iBGP learned prefix must also exist in local IGP table > > > > > > -or use #no sync on iBGP learning router, but if you do, you'd > >sure > > > as > > > > > > hell better know why you disabled it. > > > > > > > > > > > > On Sun, 2002-04-07 at 09:22, Phil Barker wrote: > > > > > > > Hi Group, > > > > > > > > > > > > > > Hope someone can help out with this as I don4t have > > > > > > > access to my kit at the moment. > > > > > > > > > > > > > > I tried to set up my first BGP lab last week. > > > > > > > I configured a full iBGP mesh, three routers connected > > > > > > > in a triangle via serial lines. > > > > > > > > > > > > > > I set up (neighbour( statements on each router (Hope > > > > > > > Radia can forgive the extra vowel !!!) and advertised > > > > > > > the networks. > > > > > > > > > > > > > > I got the BGP table working but nothing was promoted > > > > > > > to the main routing table, and therefore could4nt ping > > > > > > > non directly connected interfaces. I tried various > > > > > > > approaches like putting a default route in and running > > > > > > > an IGP but still no promotion to the main table. > > > > > > > > > > > > > > Should this be possible with iBGP ? or is it a matter > > > > > > > of loop avoidance i.e the AS Numbers won4t be > > > > > > > prepended for the case of iBGP peers. > > > > > > > > > > > > > > Phil. > > > > > > > > > > > > > > __________________________________________________ > > > > > > > Do You Yahoo!? > > > > > > > Everything you'll ever need on one web page > > > > > > > from News and Sport to Email and Music Charts > > > > > > > http://uk.my.yahoo.com > > > > > -- > > > > > David Madland > > > > > Sr. Network Engineer > > > > > CCIE# 2016 > > > > > Qwest Communications Int. Inc. > > > > > [EMAIL PROTECTED] > > > > > 612-664-3367 > > > > > > > > > > "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=41056&t=40741 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
