iBGP behaviour

[laloperez]

Hi all,

I have a question regarding our BGP configuration that's getting me mad. We have two 7604 doing eBGP with three providers and iBGP between them.

This is our config for the iBGP peeering (some data changed to protect the innocent)

router1:

router bgp xxxx

no synchronization

no bgp fast-external-fallover

bgp log-neighbor-changes

network x.x.x.x mask 255.255.192.0

neighbor 10.1.1.253 remote-as xxxx

neighbor 10.1.1.253 description iBGP_R01_R02

neighbor 10.1.1.253 update-source Loopback0

neighbor 10.1.1.253 version 4

neighbor 10.1.1.253 next-hop-self

neighbor 10.1.1.253 soft-reconfiguration inbound

no auto-summary

router2:

router bgp xxxx

no synchronization

no bgp fast-external-fallover

bgp log-neighbor-changes

network x.x.x.x mask 255.255.192.0

neighbor 10.1.1.249 remote-as xxxx

neighbor 10.1.1.249 update-source Loopback0

neighbor 10.1.1.249 version 4

neighbor 10.1.1.249 next-hop-self

neighbor 10.1.1.249 soft-reconfiguration inbound

no auto-summary

Well, when I issue a sh ip bgp summ I've got that any of the iBGP peers have advertised only a fraction of the total BGP table routes, i.e., 180000 one and 30000 the other. In fact, if I do a sh ip bgp x.x.x.x, I can see that a prefix learned by both routers through the three carriers is passed only one way: from route1 to router2 OR from router2 to router1, but not both ways. In fact, I can see that the route marked as "best" in one router BGP table is passed to the other router, but the same route is not marked as best, is ignored and not passed to the iBGP peer.

Result of this is that I have not a good route decision, because both routes are not exchanging all the information they need to do a proper election.

¿Any help? ¿Some misconfig? ¿Am I loosing something in the way iBGP operates?

thank you

[laloperez]

Absolutely, yes :). In fact, this was my conclusion in the previous post. I think that in no place in traditional BGP docs is mentioned anything about this timing issue. From this, my initial confusion :)

Thank you all, guys. This conversation made me think deeper into the innards of BGP, and I think I understand better how it really works.

[lamav]

Lalo, after reading your post this morning, i see a bit better what your issue involves.

I think you want to see BGP converging so that you can understand the process. Thats great because thats how you really get a good understanding of how the protocol works.

When you can -- during off hours or in a lab -- use some debug commands to see BGP in action as it converges and stabilizes.

Victor

[laloperez]

Hi, Victor,

yes it's something like that. I can understand now that the BGP table i can see is a "stable" one, with all the interchanges made and such. In the first post I asumed that the lack of routes from any of the routers implied an incomplete decision making for the BGP process. But I didn't realize that for some routes I thought were incorrectly chosen based only on as-path and local-pref, there was a difference in the med sent from our peers and then the decision made sense. Now I have to manipulate that to improve that decision :)

I have a virtual lab (dynamips) and I'm going to give BGP a chance to self-explain :D

Best regards,

[lamav]

Good luck, Lalo.

Sorry it took us so long to sync up, but we made it! :-)

Victor

And thanks for all the ratings.