I'm having trouble seeing this as good behavior. How does the iBGP peer that withdrew all those routes know if the route on the other peer has changed, perhaps for the worse? Let me restate the issue to make sure I understand what you're saying.
[AS1] [AS701] | | | | [R1]----------iBGP--------[R2] R1 learns a prefix from AS1, R2 learns the same prefix from AS701. They in turn advertise those prefixes to each other. R2, realizing the it just received an update that had a better path, issues a withdraw message to R1 for that prefix. In this current state, R2 has two paths in its BGP table but R1 only has one. If the routing information for that prefix changes, what happens? Let's say that AS1 stops advertising it to R1. Does R1 send a withdraw to R2, causing R2 to send an update at that point? Hmm...interesting. This makes sense. If the routing information changes for the worse on R1, it will send an update to R2. I'm assuming that R2 will then do another check against the information in the BGP table to determine if it should send a subsequent update back to R1. The more I think it through, the more sense it's starting to make. :-) Thanks for the info! I will file this into the category of things that are Good To Know (tm). John >>> "W. Alan Robertson" 2/5/02 2:40:30 PM >>> Folks, Just to let you know, I ran across what looked like a bug in Cisco's BGP code... Turns out, this is undocumented new behavior. We just deployed a pair of 3640s for one of our customers, for dual-router, dual-homed Internet connectivity. We are taking full tables from Genuity (AS 1), and Worldcom (AS 701). Each router was learning 104,000+ prefixes from each of the external peers, but the iBGP peering was acting really strange. One of the routers was learning the full table from the other, but the second router was only taking like 700 prefixes. When we cleared the internal peer (soft or hard), we could see the whole table being transferred... It would climb as though it were going to learn them all, and then as it approached 100,000 prefixes, it would rapidly drop back down to 700. I debugged the iBGP peer, and saw it issuing withdrawls for all of these routes. We opened a ticket with the TAC, and they initially believed it to be a bug as well. Upon further review, they came back and told us that this was the desired behavior in the newer code (We are running 12.0(20) on these boxes). In order to conserve memory, and processor, if an iBGP peer learns that another iBGP peer already has a better route to a specific prefix, it will issue a withdrawl to that peer for the prefix(es). I spent quite a while second guessing what seemed to be a very simple, straighforward configuration. I have done several near identical deployments in the past. I guess the moral is this: If you know your config is correct, and the router behavior is not what you expect, do not hesitate to call the TAC. I hope they are as helpful on Monday, when I call them from the CCIE Lab in RTP. ;) Regards... Alan Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34528&t=34521 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
