>Comments inline > >At 11:19 AM 4/9/2002 -0400, Chuck wrote: >>Ah, but there is this little thing called "the standard", and the standard >>requires that it be done the way it is because BGP SHOULD be advertising >>only REACHABLE nets. What would the internet be, if unreachable nets were > >advertised willy nilly? ;->
Agreed. That's one of the fundamental loop and thrashing mechanisms, with some minor exceptions for deliberate blackhole routes that relate to someone's own address block. > > >Sure.. BGP synchronization (particularly with OSPF) hasn't been on the BGP >standards track for a while. > >>I think it was Avi Freeman ( sp? ) who put it so poetically: ( and I am >>paraphrasing ) A BGP route is a promise. > >Putting BGP into the your IGP would be a threat > >>I haven't researched, but I would wager a guess that the "no synch" option >>was added in a later revision of the BGP standard based on real world > >experience. The earlier versions of BGP (and, for that matter, OSPF), did allow for the possibility of mutual redistribution. Experience, of course, showed that was a bad idea. Pervasive iBGP works much better. I wouldn't be surprised if (1) Juniper didn't implement sync because it was recognized by then that it was a bad idea and (2) Cisco couldn't drop it because people were using it. >It is a concession to human frailty in a protocol that requires > >perfection. It is also the start of the proverbial primrose path that can >>lead you to hell in a handbasket real fast, if you don't understand the >>differences between BGP operation and the behaviour of the other routing > >protocols. To the best of my recollection, synch is not in Draft 18 of the in-process RFC 1771 revision. > >I think synch, beyond OSPF-BGP interaction, is a vendor implementation >issue, and not actually described in BGPv4 (or v3 for that matter if i >recall correctly) Given that the OSPF-BGP interaction RFC has been declared "Historic", meaning obsolete, that's probably not good evidence. Many of those > > >>See what happens when you read too much Raymond Chandler? :-> >> >>Chuck >> >> >> >>""Peter van Oene"" wrote in message >>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > I don't disagree with most of your points, but really think synch should >>be >> > disabled in all cases at all times along with auto summary. It should be >> > disabled by default and indeed shouldn't even be included as a >>configurable >> > option. >> > >> > 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. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=40954&t=40741 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
