inline At 03:02 PM 4/9/2002 -0400, Howard C. Berkowitz wrote: > >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.
Was it ever discussed in any BGP spec? It's certainly not in 1771, nor 1267 as far as I know. > > > >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. Was just making the point that beyond OSPF-BGP interaction, I've never seen BGP-IGP synchronization described in any ietf documentation related to best practise BGP implementations. >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=40961&t=40741 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
